Bug#935127: bash: please make the build reproducible

[Matthias Klose]

On 10/20/20 10:13 AM, Holger Levsen wrote:
> Hi Matthias,
> 
> first: many thanks for uploading a fixed bash package!
> 
> second: the rest of this mail is not about bash anymore, so still mailing the
> bug is kind of wrong. I'm doing it anyway to keep references intact. (Feel
> free to just reply to the r-b-bugs list if you think thats better. or clone
> and reassign, dunno?)
> 
> so, about libgcc and the essential set...
> 
> On Fri, Oct 16, 2020 at 10:54:18AM +0200, Matthias Klose wrote:
>>>>> So, there are now only two packages in the Essential set that are
>>>>> unreproducible. I plan to work on the other package (Perl) shortly,
>>>>> but having Bash fixed in the archive itself would be very welcome
>>>>> and motivating withal.
>>>> really?  No libgcc in the essential set? yes, it would be motivating if you
>>>> would address the GCC issues upstream and not keeping a set of local patches.
> 
> about gcc:
> 
> a.) I don't think *we* (r-b) have local GCC/libgcc patches since 2018, instead
>     we are just using the gcc packages from Debian. We certainly have nothing
>     not in our repo (because it's been empty for a while, including all
>     of 2020).
>     If "we" have them in Debian, I'd very much appreciate a quick
>     pointer which of the 
>     https://sources.debian.org/src/gcc-10/10.2.0-15/debian/patches/
>     contain patches from us we should upstream?
> 
> b.) or am I/we miss something else?

I'm talking about

https://gcc.gnu.org/pipermail/gcc-patches/2017-July/479571.html
https://gcc.gnu.org/pipermail/gcc-patches/2017-August/480573.html

submitted upstream by Ximin Luo, not accepted in this form, and not part of the
Debian package either.  In the past the r-b effort used to build their own
compiler with a bunch of patches.  Is this still the case?

> about essential:
> 
> maybe/probably we (well, you and Chris) have been talking about different
> essential sets or definitions, because
> https://tests.reproducible-builds.org/debian/bullseye/amd64/pkg_set_essential.html
> does not contain GCC, even the build-essential pkg_set doesnt contain it,
> only https://tests.reproducible-builds.org/debian/bullseye/amd64/pkg_set_build-essential-depends.html,
> which might be a bug in how we calculate the pkg sets...
> 
> but then, I think the calculation is right, see the one line at
> https://salsa.debian.org/qa/jenkins.debian.net/-/blob/master/bin/reproducible_create_meta_pkg_sets.sh#L155
> which considers all binary packages which set "Essential: yes" (and then looks up 
> the source package that binary is coming from.) Or am I wrong?
> 
>>> Unfortunately I don't understand the hostility of this reply or how
>>> it is relevant to Bash.
>> Hostility?  You started speaking about "motivation" here.  If you need that,
>> fine.  But then why demotivate others...
> 
> I'm very sorry this discussion arrived here. And that's all I'm going to say
> about those 4 lines, except that we surely don't want to demotivate anyone. I'm also
> sure Chris feels this way and regrets that his words caused "harm" on you.
> 
> (and i'm not sure about the quotes around harm, demotivation is surely harm noone wants.)
> 
>> ... by keeping local patches and not working
>> on upstreaming those?  It's now years that the reproducible builds project
>> doesn't address some of it's more fundamental issue with compilers.
> 
> To repeat very clearly: we (*) are not aware which patches you are talking about
> and we would really appreciate pointers. And we surely want to upstream
> everything we do. And we very much appreciate help. (And reminders if needed.)
> 
> (*) I've asked around.. :)
> 
> And we, I, want everyone to be happy and motivated. And if we fail, we like to 
> know.
> 
> Last and not least: thanks for your time, support and all the work you put into
> maintaining these important packages! I very much hope together we can fix all
> the bugs which annoy us! Seriosly.
> 
>