pkgsrc: plenty of software for QNX ... and bb10 ?

[karawitan]

Someone ready to take use pkgsrc as a source of packages for BB10 ?

https://forums.crackberry.com/developers-lounge-f9/pkgsrc-more-6000-open-source-apps-libraries-blackberry-10-os-857820/#post11594074

https://github.com/NetBSD/pkgsrc.git
ftp://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.5.0_head_20110826

How do we clone only a subset of the huge pkgsrc repository using git ?

Maybe this repo is more appropriate, as it's QNX specific
https://github.com/vocho/qnxpkgsrcmirror

[vaskas]

Another source to look at is https://github.com/termux/termux-packages/tree/master/packages. There is similarity in a way that all packages are being cross-compiled. You can learn a lot from their scripts.

[vaskas]

@Berryamin do you mind adding your git-based patching workflow to https://github.com/BerryFarm/berrymuch/wiki/Porting ?

[karawitan]

@vaskas git workflow in progress: https://github.com/BerryFarm/berrymuch/wiki/Git-Workflow-Draft

[csalg]

I have been looking into this recently. Here are some notes on what I have done:

1. Cross compilation of packages is documented only for NetBSD, but I suspect it will probably work for a Linux device with a pkgsrc tree already installed. Anyway, I tried simply compiling bmake from our docker image but it barks at me that there is no MK or MKSRC directory. As I would later find out, this the first thing the pkgsrc bootstrap generates.
2. My next stop was git cloning https://github.com/vocho/qnxpkgsrcmirror to the device. That doesn't work because git is broken for http and https for now. So I wget the zip to the documents folder and unzipped that. That takes ages and a I lost patience when the first HEAD_640 was fully unzipped.
3. Right, so now it's just a matter of going to pkgsrc/bootstrap under that HEAD_640 and following the instructions. Actually, there are some options we need to pass to ./bootstrap, they can be seen calling ./bootstrap --help. I did PREFIX=$NATIVE_TOOLS ./bootstrap --unprivileged --prefix $NATIVE_TOOLS 2>> build.log >> build.log.
4. bmake won't build like this because it has hardcoded paths in its own bootstrap under ../devel/bmake/files/boot-strap. So the $NATIVE_TOOLS prefix has to be added to those paths...

Anyway, this will build bmake and some other stuff and will fail trying to build sed (after... ahem.. two hours or something like that). However although the build process does not complain of the hardcoded paths, bmake itself is broken because it still looks for things in the wrong places...

HOWEVER, I noticed that the paths problem in 4) is fixed in HEAD_660, i.e. that boot-strap doesn't look for /bin/pwd but just pwd. I am now building from HEAD_660 and it hasn't barked at me. Ideally, bmake will build without hard-coded paths and we won't even need to patch anything.

So yeah, it's doable. If someone wants to try to install a pkgsrc tree in our docker image and attempt to cross compile here are some warnings. The ./bootstrap script does lots of things so it should still remain the center of the build process. For cross compiling there is no way to pass our own flags to the make calls inside the different bootstrap procedures, so this might have to be patched (e.g. by prefixing with an environment variable, or maybe by declaring a make alias or some other trick...). Other than that, it seems to respect the prefix argument passed, so it might build just fine in a host computer.