Running with -j2 got me further but still it failed…Any ideas?
i think i found it…on the recipe a line on the PROVIDES section should be cmd:wine$secondaryArchSuffix = $portVersion …yet if i am correct i dont understand why the recipe worked for @Begasus…i ran haikuporter in strict mode (-S)
1 Like
This explains the “POLICY ERROR:”, if you turn of strict mode you will get “POLICY WARNINGS” instead. 
Or add the cmd’s in the recipe like:
PROVIDES="
wine$secondaryArchSuffix = $portVersion
cmd:wine = $portVersion
cmd:function_grep.pl
cmd:msidb
cmd:msiexec
cmd:notepad
cmd:regedit
cmd:regsvr32
cmd:widl
cmd:wine64
cmd:wineboot
cmd:winebuild
cmd:winecfg
cmd:wineconsole
cmd:winecpp
cmd:winedbg
cmd:winedump
cmd:winefile
cmd:wineg++
cmd:winegcc
cmd:winemaker
cmd:winemine
cmd:winepath
cmd:wineserver
cmd:wmc
cmd:wrc
"
If i correct the error and execute hp again will it recompile everything or it will make only the package?
You can skip the “build” by using “hp wine -F”, this jumps to INSTALL() part of the recipe. But mostly if a package is “build” it will just check the presence of the compiled files and then moves to INSTALL(), this doesn’t work for some projects though, no idea why. So using -F if build went fine should do the trick
1 Like
I was able to create hpkg and install it (using -j2)…Now i am at the same situation as @Begasus.I see the following driver loading error…Any ideas?
1 Like
perhaps the “driver” is the windowing driver, iirc x512 created a new haiku native driver called winehaiku.drv, prior to that winex11.drv + xlibe seems to have been the solution.
1 Like
@Wildman the 10.6 patchset contains dlls/winehaiku.drv folder and it’s files…I will check if that’s properly created
I have a question that may sound silly… Why git patches are used inside Haikuporter?
Isn’t a traditional patch (command) file simpler in its structure?
That question isn’t silly at all,in fact I was thinking exactly the same thing when I first saw Haikuports.
I still haven’t found an answer,and maybe it’s as simple as “the guy who created Haikuports decided to do it this way”,I don’t know.
Sometimes I make packages for OpenIndiana (a OpenSolaris fork) and there we have a “patches” folder for every port were .patch files can be placed.
There you can have multiple patch files that do different things and/or touch different parts of the code,which makes that system really nice to work with,even for large projects with big patchsets.
What I know for sure is that,now that we already have thousands of packages,nobody is going to rewrite all patches to a new format,as that would be a lot of work.
That’s basically how it works now except that haikuporter defaults to creating git patchsets. There are many ports that have plain patch files and even multiple patch files that get applied. The ones with multiple patch files usually contain upstream patches that do not need to be in the patchset because they do not need to be submitted back upstream. I think one of the reasons for patchsets as the default is because it makes tracking things that need to be upstreamed easier and allows for leaving notes in the commit message of the patch.
1 Like
Oh,I didn’t know that plain .patch files are also supported here,that’s really nice 
Now i saw that Haikuporter supports both operations. If you provide -G it will not create a git repo and use patch instead.
Using -G is nice for large projects, untill you want/need to make changes and extract the patch with -e, maybe using patch command works in there, but I’m used in extracting the patchsets with haikuporter.
For Kasts there was a bug in latest release (25.04.0), so I didn’t push a release for Haiku, upstream was noticed and a fix was made, grabbiing the upstream MR and backporting that to the latest release as a patch in the recipe fixed this for us. One way of using upstream “fixes”.
The main reason for using git is to implement the -e/–extract-patchset command.
This allows a workflow where you start writing a recipe, see that it breaks, modify the sourcecode of the project until it works.
To implement this without git, you would need to extract a second copy of the sources, to compare with the modified one.
This workflowis quite convenient because pretty much every ported software will require some amount of patching for Haiku. Some of us don’t ever try to compile software outside of haikuporter, when testing a new piece of software, start with writing a recipe and extract the patches after you got it working. With plain patch files, that would not be as easy. I’m not even sure what the workflow with patch files would be.
Do you generate them with diff? What do you diff against? How do you make sure to not lose track of what you changed? Do you edit the pachfiles manually?
2 Likes
If you see haikuporter/HaikuPorter/Source.py at master · haikuports/haikuporter · GitHub 3 modes are supported depending on using -G parameter and the extension of the file.
(git am,git patch and patch).
When creating patchfiles,I extract the source archive twice: to source/ and to source.orig/.
Then I can create a patch file using gdiff -Nru source.orig source (or something like that) and later split the created patchfiles into multiple parts if it makes sense.
For example could create patches/link_to_libnetwork.patch and patches/fix_compiler_errors.patch,or I keep one big file as patches/solaris_support.patch.
To understand what was changed and why that was needed,comments can be added to the patchfiles,but most of the times you easily understand it by reading the patch itself.
Yes,I do edit patchfiles manually and that speeds things up a lot.
Unlike Git,GNU patch doesn’t rely on checksums and requires only the patched lines plus three lines above and below it to be identical in the new version to find the location to patch again.
That means most patches apply to updates without requiring a change at all,and those which don’t apply can,in most cases,be fixed by changing a single line that has changed in the new source.
It happens very rarely that a patched area changed so much that a completely new patch needs to be created.
Reusing old patches saves me a lot of time.
this is the command that let’s you in theory define drivers…still no luck though
wine reg.exe add HKCU\Software\Wine\Drivers /v Graphics /d wayland,X11 … and if you start like this you get wayland mode DISPLAY=: wine notepad.exe
…in my system i get memory errors like 002c:err:virtual:try_map_free_area mmap() error Bad address, range 0x7fffff410000-0x7ffffffe2000, unix_prot 0x7.
I saw yesterday that the equivalent porting effort of Wine on Freebsd (which has some similarities with Haiku) is at Wine 10.0 for the stable version and at Wine 10.5 for wine-devel.
I know that Freebsd has X11 and 32 bit development libraries so this justifies the version differences.
Just out of curiosity the configure options for Wine 10.0 are quite different freebsd-ports/emulators/wine/Makefile at main · freebsd/freebsd-ports · GitHub
Recently many of the Wine configure options are available in Haikuports (e.g wayland devel libs,sdl2) e.g i am experimenting with enabling --with-wayland… The configure script refuses to find headers and .so for it even i installed them in /boot/system/develop…I tried using LDFLAGS and CFLAGS but it did not work… Maybe pkg-config would help better…? Please advise