#175 closed defect (fixed)
Request for a Complete Tarball Including Submodules for FreeBSD Port Update
Reported by: | Owned by: | pulkomandy | |
---|---|---|---|
Priority: | major | Milestone: | 2.10 |
Component: | GrafX2 | Version: | 2.9 |
Keywords: | tarball freebsd port src | Cc: |
Description
I was looking to update the FreeBSD port with the latest release of grafx2-v2.9.tar.gz available on your download page.
Upon reviewing the contents of the tarball, I noticed it lacks the .gitmodules necessary for a complete setup:
# cat .gitmodules [submodule "tools/8x8fonts/font8x8"] path = tools/8x8fonts/font8x8 url = https://github.com/dhepper/font8x8 [submodule "tests/pic-samples"] path = tests/pic-samples url = https://gitlab.com/GrafX2/pic-samples.git
While I could manually check out these submodules, compile my own tarball, and host it for the FreeBSD port, I would much prefer to use a tarball downloaded directly from the original source.
Could you please provide a complete tarball that includes all the necessary submodules? Such a version would be highly beneficial for all packagers and greatly simplify the update process.
Thank you for considering this request.
Attachments (1)
Change History (15)
comment:1 by , 2 weeks ago
comment:2 by , 2 weeks ago
Thank you for clarifying. I've reviewed how GrafX2 builds from the src/
directory and found that it uses curl
commands in the Makefile
to automatically fetch the latest versions of dependencies from URLs. This keeps the software up-to-date with the latest libraries, which is beneficial during development.
However, such network operations during the build process are problematic because they conflict with the guidelines in the FreeBSD Porter's Handbook. This issue extends beyond FreeBSD, as many other systems that package software from source also disable network access in sandboxed (1) build environments to ensure security and stability. This means that any attempt to access the network during the build will fail in these environments.
For release source tarballs, it’s crucial to avoid network operations and pin dependencies to specific versions to ensure consistent, reliable builds. This approach aligns with best practices for software distribution, helping maintain a predictable and secure build process.
(1) https://docs.freebsd.org/en/books/porters-handbook/quick-porting/#porting-testing
comment:3 by , 2 weeks ago
Yes, two files are currently downloaded from their respective upstream if they are not found in the source directory: 6502.c (from redcode) and recoil.c. These could be handled as normal dependencies, except they are not currently packaged anywhere.
If you provide them in some other way and they are present in the source directory at the time of build, the provided version will be used, and no download will happen.
The links for these are:
https://downloads.sourceforge.net/project/recoil/recoil/6.4.2/recoil-6.4.2.tar.gz
https://github.com/redcode/6502/releases/download/v0.1/6502-v0.1.tar.xz
For recoil, you can disable it by building with NORECOIL (at the cost of having less support for unusual file formats loading). Unfortunately for the 6502 code interpreter there doesn't seem to be a way to disable it currently.
I will see if I can generate an archive including these files.
comment:4 by , 2 weeks ago
I can definitely work around the recoil dependencies. They are installed via separate port as a build dependency.
The most problematic part are the curl statements. As curl and networking is unavailable in the build sandbox.
In this poudriere log (FreeBSD package build sandbox) you can see the problematic sections:
https://critical.ch/people/1a9e28cf-060c-11ef-9d11-10bf48e1088e/grafx2-2.9.log
comment:5 by , 2 weeks ago
They are installed via separate port as a build dependency.
Is that available somewhere? If recoil starts to be packaged as a library, I can make GrafX2 use that. But I need some package to test against.
The most problematic part are the curl statements. As curl and networking is unavailable in the build sandbox.
Yes, I have understood that (I am not completely unfamiliar with how these things work, I maintain packages for Haiku which has similar rules).
As I said, one option for now is to provide the needed files beforehand (if your packaging system supports building one package from multiple source archives), or just wait until I can fix the issue and provide an archive including all the needed files.
comment:6 by , 2 weeks ago
Apologies for the confusion. The recoil code is not available as an independent library. The existing FreeBSD port uses the bundled code found in grafx2-2.8.3091-HEAD-src.tgz.
comment:7 by , 2 weeks ago
Maybe create a 'dist' Makefile target that creates a tarball including all the dependencies.
comment:8 by , 2 weeks ago
There's already one but I forgot to use it when making the release (it's been a long time since the previous release). However, I'm not sure if it was updated since the inclusion of recoil and 6502.
I will check all this, I don't really need help with it, I know what to do. Just give me a few hours to investigate it and build a new archive.
comment:9 by , 2 weeks ago
You can now use this download link: https://pulkomandy.tk/projects/GrafX2/downloads/80
It should include recoil and 6502 sources and work for "offline" builds. Let me know if that works for you.
comment:10 by , 2 weeks ago
It still calls curl
and jq
during build (see attachment: build log #1) and therefore fails.
comment:11 by , 2 weeks ago
Mh, yes, there was another thing missing. The 3rdparty/ directory needs to not exist, and the makefiles rules check for that (it's a bit strange to do it that way, but I'm not sure there is a better way in makefiles).
So, here is a 3rd attempt at generating the release archivem hopefully it should work this time:
comment:13 by , 2 weeks ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:14 by , 2 weeks ago
Milestone: | 3.0 → 2.10 |
---|
Hello,
I think these files should not be needed if you don't use the vendored dependencies (which I assume you will not use when packaging for distribution in a packaged system, you want to use the system versions of SDL, etc).
To do this, you can use the makefile in the src/ directory instead of the toplevel one. It will not try to rebuild the font from the "source" PNG files, and instead use the already generated ones that are in the archive.
For example here is the recipe used in Haiku:
https://github.com/haikuports/haikuports/blob/c633bb3b1858d8f8758ae2cd7e6daac5aa44fa49/media-gfx/grafx2/grafx2-2.9.recipe#L2
I will update the documentation to mention this.