Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2024/07/02/rootskel_1.136_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240702;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240702&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Control: severity -1 normal
Control: tag -1 + moreinfo

rootskel 1.137 seems to build fine. Can you check?

Chris

severity 1074711 important
retitle 1074711 rootskel: FTBFS randomly: ln: failed to create symbolic link '/<<PKGBUILDDIR>>/debian/rootskel//etc/mtab': No such file or directory
thanks

El 20/10/24 a las 19:36, Chris Hofstaedtler escribió:

Hi. This is not a false positive, it's yet another "ftbfs randomly" bug:

https://tests.reproducible-builds.org/debian/logs/unstable/amd64/rootskel_1.137.build2.log.gz

( Note: You will see that I'm raising to important this and other "ftbfs randomly" bugs.
   The reason is that IMO bugs like this one are candidates for proposed-updates
   if they happened to slip into a stable release, and Release Managers require that
   the bugs to be fixed in p-u have to be important or higher ).

Thanks.

Well. If it fails only in pbuilder or schroot, then thats a valid
bug, but also not so interesting anymore.

I imagine the pbuilder env does not have /proc/mounts?

No objection.

Chris

El 20/10/24 a las 21:55, Chris Hofstaedtler escribió:

I imagine it has, but I don't think that having or not having /proc/mounts
is the reason for this package to fail randomly.

(I have the feeling that maybe you are trying to simplify this too much,
without taking in account all the available data).

I know for sure that Lucas Nussbaum uses sbuild with schroot and file-based
chroots, and AFAIK reproducible-builds use pbuilder.

So, if a bug which Lucas reported with version 1.136 also happened in
reproducible-builds with version 1.137 (same error message), my preliminary
conclusion is that the bug is still there, it happens randomly, and it may
happen with both methods of building.

In fact, the official buildds are moving to sbuild + unshare. For "buildability"
purposes, the main difference is that some packages which build ok with
sbuild + file backend may still fail with sbuild + unshare (for example,
those trying to access Internet), but I have yet to see a package which
builds ok with unshare but fails with sbuild + file-based chroot.

So, for all purposes (if we just look at the building method), any bug
reported by Lucas using his setup may happen in the buildds as well
(if that's your concern).

Thanks.

* Santiago Vila <sanvila@debian.org> [241020 22:40]:

Possible.

I'm just concerned because we're looking at "ln -fs" failing, and
the other involved parts seem relatively simple.

Maybe something very strange is going on, but that needs someone who
can repro the failure to investigate it.

Chris

El 20/10/24 a las 23:19, Chris Hofstaedtler escribió:
this is one of the 800 packages which FTBFS (either always or randomly)
when built with make --shuffle:

https://people.debian.org/~sanvila/make-shuffle/

(Note to self: I have to announce that some day).

So this is most surely a Makefile bug, and very likely
using "make --shuffle" will "amplify" the probability
of the failure to happen.

I even have a personal theory or suggestion to deal with
those bugs: Forget for a while about reproducing them and
just try to prove that the Makefile is "correct" (in a
"mathematical sense", i.e. try to prove that it will always
do what is supposed to do) using rubber duck debugging.

Since we know the Makefile is buggy, any attempt at proving its
correctness should fail, hopefully at the point where the Makefile
bug becomes self-evident.

(Also: I've just tried dpkg-buildpackage in a chroot with make 4.4.1
at /usr/bin and GNUMAKEFLAGS=--shuffle in the environment, and the
failure rate is very high indeed. I think everybody will be able
to reproduce it that way. Just try it.)

Thanks.

tags 1074711 patch
thanks

Hi.

The attached patch works for me.
It just serializes things a little bit.

The problem is that the author wrote this:

foo: bar1 bar2 bar3

with the idea that bar1 would be done first, then bar2 and then bar3,
but Makefiles do not really work that way.

For the long explanation:

https://trofi.github.io/posts/238-new-make-shuffle-mode.html

(that's the post where the author explains make --shuffle)

Thanks.