Opened 8 weeks ago

Closed 7 weeks ago

Last modified 7 weeks ago

#175 closed defect (fixed)

Request for a Complete Tarball Including Submodules for FreeBSD Port Update

Reported by: ehaupt@… Owned by: pulkomandy
Priority: major Milestone: 2.10
Component: GrafX2 Version: 2.9
Keywords: tarball freebsd port src Cc:


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 =
[submodule "tests/pic-samples"]
        path = tests/pic-samples
        url =

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)

grafx2-2.9.log (69.8 KB ) - added by ehaupt@… 8 weeks ago.
build log #1

Download all attachments as: .zip

Change History (15)

comment:1 by PulkoMandy, 8 weeks ago


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:

I will update the documentation to mention this.

comment:2 by ehaupt@…, 8 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.


comment:3 by PulkoMandy, 8 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:

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 ehaupt@…, 8 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:

comment:5 by PulkoMandy, 8 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 ehaupt@…, 8 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 ehaupt@…, 8 weeks ago

Maybe create a 'dist' Makefile target that creates a tarball including all the dependencies.

comment:8 by PulkoMandy, 8 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 PulkoMandy, 8 weeks ago

You can now use this download link:

It should include recoil and 6502 sources and work for "offline" builds. Let me know if that works for you.

by ehaupt@…, 8 weeks ago

Attachment: grafx2-2.9.log added

build log #1

comment:10 by ehaupt@…, 8 weeks ago

It still calls curl and jq during build (see attachment: build log #1) and therefore fails.

comment:11 by PulkoMandy, 7 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:12 by ehaupt@…, 7 weeks ago

That one works, thank you. I have updated the FreeBSD port accordingly.

comment:13 by PulkoMandy, 7 weeks ago

Resolution: fixed
Status: newclosed

comment:14 by PulkoMandy, 7 weeks ago

Milestone: 3.02.10
Note: See TracTickets for help on using tickets.