Building a package that Build-Depends on pmake and uses it in its debian/rules build targets in a clean bullseye chroot completely fails with: bmake: no system rules (sys.mk). stracing shows that, despite the -m option being passed by the pmake wrapper, it still accesses /usr/share/mk/. I’ve not yet tested whether bookworm+ are also affected.
Dixi quod… Hm, but I just tested with pmake_1.111-3.2_armel.deb from the archive, and it also failed. Is it possible that it doesn’t work right under qemu-user? (Which would also be possibly devastating…) Or under cowbuilder (same)? bye, //mirabilos
Control: severity -1 normal Control: tags -1 moreinfo Please give me a more specific example. I’ve tested pmake and it works on its own.
Control: severity -1 normal Control: tags -1 moreinfo Please give me a more specific example. I’ve tested pmake and it works on its own.
El 15/8/24 a las 22:49, Thorsten Glaser escribió: If yes: Can you provide an example of package in the described set? I ask because I rebuilt the whole of bullseye one month ago, and among the few packages still pending to be reported, none of them uses bmake. Thanks.
Santiago Vila dixit: No, pmake. https://debr.mirbsd.org/repos/wtf/dists/bullseye/wtf/Pkgs/host/ Yeah, this is not uploaded to Debian proper. I use pmake quite a lot, though. bye, //mirabilos
retitle 1078772 pmake: “bmake: no system rules (sys.mk).” under qemu-user severity 1078772 important thanks Dixi quod… Apparently, this is it, so it doesn’t break for everyone. My Pi 1 running armel is apparently building this fine, if sloooooooooooooowly. bye, //mirabilos