I've noticed this too, I think it's a regression unrelated to my attempts at the qemu-user-static 5.0 builds. Especially considering that none of my efforts there have made it into the repos yet :)

It is concerning though, and we should look into this with urgency.

i didnt suggest that it was related to your work this week - its
been broken for maybe 2 weeks now - i was hoping that it was
because of qemu5 entering arch; but our helpers being
incompatible, and needing an upgrade

more than concerning, it is preventing any arm packages from
being built, unless gnutoo does them on his SBCs - all of the
icu dependents need rebuilding now; preventing ARM system from
being upgraded without removing them - even if gnutoo can build
them all, the hungry ice-* critters will put quite a hurtin' on
those 2GB boards - also blender - it could be two weeks before
he could complete all of those

i have icedove armv7h almost ready - it took only 3000
minutes to complete on beefcake - it may be possible to rescue it
though with -R, if we can get this problem fixed - thats why
figured it was worth building, even though i knew it would fail

Some ARM builds works for me on real hardware (TBS2910 with fully free boot).

So if you want me to build a large number of packages I can probably do that, but in that case you should expect me to just run the build and potentially report the error at best as I don't have time to fix every package that don't build or just bump a revision.

Another option would be that I could (temporarily) give SSH access on a Lime2 (Allwinner A20, 1G of RAM), but I would need to prepare it in some special way (add another rootfs, put it on a separate network, Enable SSH remote access through Tor for easy and fast setup).

I don't need that board all the time as I'm building packages on another one, but I'll probably need it when I can find the time to work on bootloader packages again to update u-boot (and extlinux.conf as we have a bugreport about it).

As for the importance of this bug, having the ability to build on an emulator is crucial, as we might need huge quantity of RAM to build things, not everyone has an ARM board, and we can bootstrap things from x86 this way.

For instance I didn't participate much on the ppc64le port because I didn't want to rely on having access to real hardware for quick help.

It would be interesting to have the other way around too (enable to build x86 packages on ARM) but for that we need to build qemu-static and I didn't have the time to finish packaging the dependencies for ARM yet.

On Wed, 27 May 2020 23:03:54 +0000 labs@parabola.nu wrote:

So if you want me to build a large number of packages

large number of packages - yes all of
these: https://labs.parabola.nu/issues/2071

if you could easily queue them all to build unattended, that
would definitely help shorten the list

not everyone has an ARM board

BTW, who has one? afaik, you (GNUtoo), oaken-source, ovruni and I. I'd like to know if some devs need temporary access to real ARM hardware, so I can enable my Banana Pi to give it to anyone who needs it. The other option is that anyone who needs to build "X" package for ARM, tells me so I just fetch the update in abslibre and build it (I've done this many times with cups-filters)

just yesterday, GNUtoo setup a lime2 for that same purpose -
there is a REAMDE and SSH keys on winston under ~/gnutoo/ for
connecting to it

its not a complete permanent solution though - some packages
will need so much RAM, that the builds would take forever on real
hardware

as for which ones need building, there is a list on the bug
tracker of the packages which were broken by 'icu' - probably
most of those could be built on hardware, other than the ice*
critters

I found the solution in this Arch Linux ARM thread

The fakeroot binary installed in the ARM chroot must be built with TCP IPC (by passing --with-ipc=tcp instead of sysv, see its PKGBUILD). Just tested it and worked.

Now, I wonder if we should blacklist fakeroot due to this technical reason? or should we simply rebuild fakeroot with a higher pkgrel for armv7h, without blacklisting it? because building a separate fakeroot-tcp would be more painful, as it would conflict fakeroot from base-devel

I've added the PKGBUILD to abslibre, so if anybody wants to try it:

https://git.parabola.nu/abslibre.git/tree/libre/fakeroot

im very glad someone found the cause of this

it would not need a higher pkgrel nor to be blacklisted - it would only need to be in libre - there can be duplicate packages with the identical name and version, in different repos - anything in libre will always take priority over repos with lower priority, even if the version in libre were lower, that package would get installed

its the same trick as the [nonsystemd] repo - those do not need .nonsystemd added to the pkgrel - it would work the same without that

Not really, unless you've it set up from the first moment. If you migrate, then for pacman to consider it an update it needs to detect it has a higher pkgrel, otherwise it will think it's the same package and that it's updated, so it won't do anything. That's why we put .parabola or .par in [libre] packages' pkgrel (when they are rebuilt Arch packages).

BTW, I noticed that when building fakeroot --with-ipc=tcp it requires passing the -N flag to libremakepkg for `make check` to work, as it depends in a network connection, and then all packages built with that fakeroot will also need network connection, else it fails with:

==> Entering fakeroot environment...
libfakeroot: connect: Network is unreachable

In this point I'm thinking about this as a temporary solution, as it solves the problem but not perfectly. I'll also give a try to fakeroot-ng too see if it's functional --with-ipc=sysv so it can work offline. In the very last case I would check pseudo, or other fakeroot alternative.

Regarding where to put this new build, maybe that could be one of our personal repos? then it would be a matter of adding it in the ARM chroots' pacman.conf and upgrading their packages. Meanwhile I'll be adding working packages in the abslibre only.

EDIT: fakeroot-ng is not supported for armv7h :/

that archarm thread suggests that the root cause of this, is a change in the kernel config - wouldnt it be simpler to revert that change for the ARM kernels, or at least one of them?

The user who found the fakeroot trick says that he suspects it may be a kernel thing, not that it certainly is. If that was the problem, then it wouldn't be a thing with ARM kernels as clean armv7h librechroots do not install kernels.

I don't think it is. I checked the abslibre log, and the kernel version that coincided with the beginning of this issue was linux-libre 5.6.12, the previous kernel was 5.6.7. Maybe I could check if it helps, but I think it won't.

none of the librechroots have kernels - the host kernel is always used

bill-auger wrote:

none of the librechroots have kernels - the host kernel is always used

sure, it's just because of what you said:

wouldnt it be simpler to revert that change for the ARM kernels

On Mon, 13 Jul 2020 14:41:17 +0000 labs@parabola.nu wrote:

packages built with that fakeroot will also need network
connection, else it fails with:

==> Entering fakeroot environment...
libfakeroot: connect: Network is unreachable

there is a similar PKGBUILD in the AUR - that one does not do
the make check - that is what i have done in the past, when i
encounterd that situation with other packages - it is the only
significant difference from the arch PKGBUILD - i removed the
make check bits from the PKGUILD and renamed it to the AUR name
'fakeroot-tcp', and added provides=(fakeroot); which should
prevent any version confusion

to make that work, libremakepkg will need to be modified to
explicitly install 'fakeroot-tcp' in the chroot, and everyone
will need to re-create their ARM chroots

i made the necessary changes to libretools - those are the top
two commits of the 'wip-2020-07-12' branch if you want to try
them out - they are minor - you can just apply them onto you
local files

https://git.parabola.nu/packages/libretools.git/log/?h=wip-2020-07-12

i have not tried any of this yet - thats what i plan to do next
- i never fully tested the chanegs that remove the exclude the
systemd packages from the chroots; so there quite a bit to test
before committing to all the changes

if this works out, that is, if it solves this problem and causes
no new problems for the other arches, those changes can be added
to the libremakepkg package permanently

`make check` doesn't work without the sed modifications I added in prepare(), and the AUR fakeroot-tcp doesn't have it, so I assume that's the reason why its maintainer didn't put it. Plus, that error appears even if not running `make check`, as my fakeroot build was done without running check()

On Tue, 14 Jul 2020 14:55:15 +0000 labs@parabola.nu wrote:

sure, it's just because of what you said:

wouldnt it be simpler to revert that change for the ARM
kernels

yer right - i did not think that through all the way - if it
could be solved with the kernels, it would need to be all
kernels, or make it clear to everyone that only some kernels will
be able to build ARM packages

if fakeroot-tcp works out, it looks like an easy package to
maintain - whatever works best

armv7h builds inside librechroot started working for me after doing this:
https://pagure.io/abslibre/pull-request/4#comment-130400

I didn't use any patched packages from the comments above. Everyting is from the official repos, just packages related to static QEMU were built from the AUR. I didn't check if it makes any difference, but I built them against updated linux-libre-api-headers-5.8.1_gnu.

Megver83 wrote:

I've been testing QEMU 7 and it solves this issue, even the pacman error saying that / is read-only in the armv7h chroot. I'm going to upgrade the related packages.

just noticed it is in [libre-testing], why isn't it in [libre]? I'll move it soon, unless someone gives a good reason for not doing it yet