Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
smartlist could not be built reproducibly.

This is because the choplist binary contains the current user via the
LISTID define. Given that has been the build user's username for many
years (?), I suspect it makes no difference what value this actually
has, but patch attached that sets it to "list" (ie. to match the name
of uid 38).

 [0] https://reproducible-builds.org/


Regards,

Chris Lamb wrote:

Gentle ping on the above?


Regards,

I'm not interested in working on reproducible issues anymore
(including accepting patches) as far as there are any packages
in stable with unfixed FTBFS bugs on them.

Sorry.

El 14/9/20 a las 11:54, Chris Lamb escribió:

According to this page:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/smartlist.html

the package is already reproducible.

Am I missing anything?

Thanks.

Sorry, I said:

Ok, it's reproducible only in bullseye, bookworm and unstable on amd64,
and not reproducible on i386.

But I don't understand how the patch might fix that, since the patch
does not depend on the architecture.

Could we postpone this until I switch to dh? (which I plan to do before the freeze)

Thanks.

tags 970278 + moreinfo
tags 970278 - patch
thanks

Hi. To summarize: I'd appreciate a more detailed explanation about why
the patch is needed (if it's needed at all at this point).

Note: I have just switched to dh, which means the build now uses
dh_strip_nondeterminism (I guess this always helps).

Thanks.

Santiago Vila wrote:

Hm, the difficulty here is that the packaging and the surrounding
toolchain has changed quite a bit since we filed this bug, and we
don't keep historical archives of diffoscope output.

Looking again at my patch, however, what I believe was happening in
the past was that the build user (or similar) was being embedded into
a binary or in some configuration file. This doesn't appear to be
happening anymore on amd64 in our testing framework, and neither does
it occur locally on my amd64 laptop. What I can say is that smartlist
was definitely unreproducible on my laptop back in 2020, otherwise I
would not have filed a patch.

As to why it remains unreproducible on i386 today, I can't immediately
see why that is happening. But I don't think it's related to the
rationale I gave above. I therefore think keeping this "- patch" and
"+ moreinfo" is correct.


Regards,

El 7/2/23 a las 22:30, Chris Lamb escribió:

Seems fair to me.

Thanks a lot.

Hello.

This is an old bug for which I still don't have a fix. I wonder if you would have some
time to look at this and propose a patch (preferably by email).

I have to make a release in the following days to fix the build with gcc-14. If I can also
fix this bug, the better.

The package is currently labeled as unreproducible on trixie and unstable for armhf,
but I am unable to make sense of this:

https://tests.reproducible-builds.org/debian/dbd/bullseye/armhf/smartlist_3.15-25.diffoscope.html

In case you want to work on unstable (where the package does not build), this is my work
in progress, where I already have a fix ready:

https://salsa.debian.org/sanvila/smartlist-not-yet/

On the other hand, if we can determine that it's not reproducible due to reasons which
are outside of our control (i.e. which do not depend on the package itself), I'd like
to close the bug.

Thanks.

Hi Santiago,

My reproducibility testing framework on my local machine is crusty
enough that testing an arbitrary Git repo is actually quite difficult.
I should probably work on this sometime, but there hasn't been enough
call for me to fix that.

Could you simply go ahead with the upload of smartlist to unstable?
I'll then very happily look back at this bug and make a better
determination on all the questions to mention below.

Best wishes,

Chris

El 29/7/24 a las 15:45, Chris Lamb escribió:

Ok, I went ahead and did the upload, since it fixes a FTBFS bug
and don't want the autoremoval to happen.

So I change my request to just "please take a look when you can".

In fact, I tried to reproduce this myself yesterday in an arm64 machine
using an armhf chroot, but I did not manage to make the reprotest tool
to work, and I ended up removing the machine (ok, I agree this is vague
and should have asked for help somewhere quoting the exact error message...).

I have identified this commit in the upstream git which has a potential to fix
the issue, because it affects lines of code which are close to the ones
reported by diffoscope output.

https://github.com/BuGlessRB/procmail/commit/ea5c916fd540b57ba33920f479e6701abad1d88e

But I don't think I will be able to test this theory without some help
to reproduce the problem, everything I need is to know what
variable variation is the one making the build to be different.

Thanks.

Santiago Vila wrote:


ACK this. I will look at this new version once it's picked up by our
automated testing framework.


Regards,

Chris Lamb wrote:

Despite neither of us making any conscious change to bring this about,
smartlist looks reproducible now, so I'm happy to close this bug.
(Indeed, doing so via 970278-done@b.d.o.)

Thanks for bringing this bug back to my attention.


Regards,

reopen 970278
thanks

Only on amd64, arm64 and i386.

On armhf (after I fixed the FTBFS-with-gcc-14 bug)
it's still not reproducible:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/smartlist.html

and more importantly, the QA page for smartlist still says it's not:

https://tracker.debian.org/pkg/smartlist

I spent some time trying to see what happened on armhf,
and got stuck, but if somebody tells me exactly the variable
that makes the build to be different, I can test the patch I
mentioned earlier (I already have an armhf chroot to test).

So, thanks for your consideration, but I would prefer to have this
fixed, mainly because I already invested some time on it and I feel
we are very close.

I don't mind anymore that the bug is open as wishlist, really.
Just please do not consider an item in your todo list if
you don't plan to work on it.

Thanks.

Santiago Vila wrote:

Ah, I didn't spot that. Unfortunately, I don't have armhf hardware to
hand, but perhaps Vagrant can help narrow this down a little.


Regards,

I was not able to reproduce the issue in my test setup, though our test
infrastructure has consistently been showing unreproducibility since
2020-09-24 on armhf.

I think the original reported issue is definitely fixed, but there is
some other outstanding issue with armhf specifically...

My hunch is differing kernel, as some of the armhf builds run with an
arm64 kernel and some with a regular armhf kernel... I will try to do
some more involved tests to verify if that is the issue.

The i386 builds used to also have a 32-bit and 64-bit kernel variation,
but some time ago they were switched to only build with a 64-bit kernel,
which might explain why this used to also be an issue on i386, but not
longer appears to be.

live well,
  vagrant

Well, I was able to reproduce a difference running one build with an
arm64 kernel one with an armhf kernel, but have not identified exactly
what triggers the difference...

It is not embedded kernel *version*, as that actually does vary on the
amd64 tests.reproducible-builds.org infrastructure where it is
consistently reproducible.

I suspect there is some architecture-specific kernel-dependent
difference.

On second look, I am noticing the diffoscope differences include some
references to __time64@plt ...

live well,
  vagrant

...

Running the build under linux32 with an arm64 kernel does not work
around the issue... still ends up being different from a build performed
with an armhf kernel.

live well,
  vagrant

El 6/8/24 a las 23:52, Vagrant Cascadian escribió:

Thanks for testing! So, if I understood, the variable which makes the build
to be different is the kernel, is this right?

Since you can reproduce the difference, can you test the branch
I've just set as default here, called wip-202408-reproducible?

https://salsa.debian.org/sanvila/smartlist-not-yet/

Ideally, I'd like to reproduce this myself, but I only have access
to "pure" arm64 systems on which I can put an armhf chroot.
Is it too difficult to cross-grade it to a "native" armhf system?

Thanks.

That patch did not fix the underlying issue.

The userland is easy enough with multi-arch, but to use arm64 hardware
with a 32-bit kernel you need a kernel built for that hardware... which
is an uncommon configuration. Raspberry PI tends to have such kernels,
though I think they are not typically built in Debian proper.

At the moment, I am building each test build on different hardware, one
natively 32-bit and one running in a 32-bit armhf chroot with the host
system running a 64-bit kernel (which is similar to the
tests.reproducible-builds.org infrastructure).

I forget if the official Debian buildd infrastructure has a mix of
64-bit and 32-bit hardware... it may have moved to only 64-bit hardware
with 32-bit chroots.

live well,
  vagrant