[Buildroot] Report of Buildroot developer meeting FOSDEM 2019

[Buildroot] Report of Buildroot developer meeting FOSDEM 2019

[Arnout Vandecappelle]

 Hi all,

 Beginning of this week we had the Buildroot developer meeting attached to
FOSDEM in Brussels. You can find the full report of the meeting on [1]. Here are
a few highlights.

* We are particularly proud of the reduction of the patchwork backlog. We
started out at more than 300, and we ended at just above 170. The majority of
those patches indeed have been accepted, for a total of 157 commits to master.

* We prepared an application for Google Summer of Code.

* We took decisions on a few infrastructural issues: making sure the git backend
produces reproducible tarballs by using the pax archive format (Yann started
working on an implementation for that); drop the idea of Config.in.host for all
packages; a simple solution for reliable packages-file-list.txt (Yann posted a
patch for that); drop support for version selection in Qt5 after the 2019.02
release.

* The openssl bump to 1.1.1 was merged. This has led to an enormous number of
autobuilder failures. Patches that fix it are very welcome!

 Regards,
 Arnout


[1] https://elinux.org/Buildroot:DeveloperDaysFOSDEM2019#Meeting_report

[Buildroot] git tarball hashes [was: Report of Buildroot developer meeting FOSDEM 2019]

[Arnout Vandecappelle]

On 07/02/2019 23:51, Arnout Vandecappelle wrote:
> making sure the git backend
> produces reproducible tarballs by using the pax archive format (Yann started
> working on an implementation for that)

?I realized while writing this: how does this approach fix the instability of
gzip? Or do we assume that that was a one-off?


?Regards,
?Arnout

[Buildroot] git tarball hashes [was: Report of Buildroot developer meeting FOSDEM 2019]

[Thomas Petazzoni]

On Thu, 7 Feb 2019 23:55:24 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> On 07/02/2019 23:51, Arnout Vandecappelle wrote:
> > making sure the git backend
> > produces reproducible tarballs by using the pax archive format (Yann started
> > working on an implementation for that)  
> 
> ?I realized while writing this: how does this approach fix the instability of
> gzip? Or do we assume that that was a one-off?

Which gzip issue are you talking about ? I think we never had a
*version* issue with gzip, only with installations where gzip is a
symlink to pigz.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] git tarball hashes [was: Report of Buildroot developer meeting FOSDEM 2019]

[Arnout Vandecappelle]

On 08/02/2019 08:54, Thomas Petazzoni wrote:
> On Thu, 7 Feb 2019 23:55:24 +0100
> Arnout Vandecappelle <arnout@mind.be> wrote:
> 
>> On 07/02/2019 23:51, Arnout Vandecappelle wrote:
>>> making sure the git backend
>>> produces reproducible tarballs by using the pax archive format (Yann started
>>> working on an implementation for that)  
>>
>> ?I realized while writing this: how does this approach fix the instability of
>> gzip? Or do we assume that that was a one-off?
> 
> Which gzip issue are you talking about ? I think we never had a
> *version* issue with gzip, only with installations where gzip is a
> symlink to pigz.

 Ah yes indeed, and someone (Yann?) observed that the output generated by gzip
has been stable since the dawn of the universe.

 Sorry for the noise.

 Regards,
 Arnout

[Buildroot] git tarball hashes [was: Report of Buildroot developer meeting FOSDEM 2019]

[Yann E. MORIN]

Arnout, All,

On 2019-02-08 10:16 +0100, Arnout Vandecappelle spake thusly:
> On 08/02/2019 08:54, Thomas Petazzoni wrote:
> > On Thu, 7 Feb 2019 23:55:24 +0100
> > Arnout Vandecappelle <arnout@mind.be> wrote:
> > 
> >> On 07/02/2019 23:51, Arnout Vandecappelle wrote:
> >>> making sure the git backend
> >>> produces reproducible tarballs by using the pax archive format (Yann started
> >>> working on an implementation for that)  
> >>
> >> ?I realized while writing this: how does this approach fix the instability of
> >> gzip? Or do we assume that that was a one-off?
> > 
> > Which gzip issue are you talking about ? I think we never had a
> > *version* issue with gzip, only with installations where gzip is a
> > symlink to pigz.
> 
>  Ah yes indeed, and someone (Yann?) observed that the output generated by gzip
> has been stable since the dawn of the universe.

Yeah, I tried versions back to 1.2.4, released in 1993, and the output
is strictly identical. To be sure, I just re-did the test right now, and
yeah, it works:

    $ /bin/gzip --version |head -1
    gzip 1.6
    $ /bin/gzip -n -c -9 - <gzip-1.2.4.tar |sha1sum
    889f641f3dd4333065ae94281b1420b965a7f32a  -

    $ ./gzip-1.2.4/gzip --version 2>&1 |head -1
    gzip 1.2.4 (18 Aug 93)
    $ ./gzip-1.2.4/gzip -n -c -9 - <gzip-1.2.4.tar |sha1sum
    889f641f3dd4333065ae94281b1420b965a7f32a  -

So, Woo! for reproducibility! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'