Re: [Buildroot] [PATCH v2 5/5] package/xz: convert to cmake build

[Peter Seiderer via buildroot <buildroot@buildroot.org>]

Hello Yann,

On Wed, 26 Jun 2024 21:32:20 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Peter, All,
> 
> (To avoid confusion: Yann@home speaking here)
> 
> On 2024-06-26 10:36 +0200, Peter Seiderer via buildroot spake thusly:
> > On Tue, 25 Jun 2024 13:11:12 +0200, yann.morin@orange.com wrote:  
> > > On 2024-06-25 11:56 +0200, MORIN Yann INNOV/IT-S spake thusly:  
> > > > On 2024-06-12 15:57 +0200, Peter Seiderer via buildroot spake thusly:  
> > > > > Convert to cmake build with the following autoconf options without
> > > > > direct equivalent cmake option:  
> > >
> > > The autotools build system is still operational, and still works. So,
> > > what was the rationale behind that change?
> > >
> > > Was that a defence against another backdooring attempt? If so, I think
> > > it should have been stated clearly in the commit log. Also, we can be as
> > > paranoid as we want, but it is possible to inject a similar backdoor
> > > in cmake as was injected in autotools, so switching to cmake just for
> > > this reason is not rally sufficient...  
> > 
> > No, as the first suggestion ([1], marked as RFC - missed the RFC marking in
> > patch set version v2) predates the backdoor detection (but migrating away from
> > autoconf/automake was discusses as one measure for backdoor avoidance),
> > my motivation was the following passage from the NEWS file ([2]):
> > 
> >         - The CMake-based build is now close to feature parity with the
> >           Autotools-based build. Most importantly a few tests aren't
> >           run yet. Testing the CMake-based build on different operating
> >           systems would be welcome now. See the comment at the top of
> >           CMakeLists.txt.
> > 
> > And the amount of work done for the cmake build system seems to hint
> > that xz is moving away from autoconf/automake towards the cmake system...  
> 
> Note that there is also some effort toward a meson-based buildsystem:
>     https://github.com/tukaani-project/xz/pull/120
> 
> > > Note: the issue I hit can be solved by passing ENABLE_NLS=OFF in the
> > > host variant; we don't really require translations, so we can
> > > unconditionally turn it off.  
> > 
> > Seems my intermediate step from 'package/xz: determine all autoconf options'
> > and '--enable-nls' unconditionally for the host variant was wrong...,  
> 
> Also, forcibly setting BUILD_SHARED_LIBS=OFF for the target is probably
> wrong. And using the target options for the host is equivalently very
> wrong.
> 
> > care to send a patch (as you can reproduce the failure)?  
> 
> Yann@work provided a very sinple way to reproduce the issue:
> 
>     $ ./utils/docker-run
>     (docker) $ make defconfig
>     (docker) $ make host-xz

Ups, seems I was to quick reading your first e-mail (and skipped
this lines)...

> 
> So you could at least try that to reproduce on your side.

Fails on my side (using podman intead of docker):

	>>> host-pkgconf 1.6.3 Downloading
	mkdir: cannot create directory ‘/pkgconf’: Permission denied

> 
> He also provided a suggestion to turn NLS=OFF, but that was suposedly
> not needed in your case, so there is something to investigate.
> 
> When maintainers apply patches, they accept that it may break something
> down the line, so it is not a problem that a patch had issues; they
> guess the contributor tested as best as they could, and the
> reviewer-committer do their best as well, so it was good to be applied.
> 
> However, when maintainers apply patches, they also expect contributors
> to own their changes, and that they are pro-active in trying to fix
> their change that caused the breakage, without swinging the effort to
> someone else without at least trying to reproduce and investigate on
> their side. After all, the contributor is in the best position to
> investigate: they know the purpose of the change, and they have the
> knowledge of the tests they did, so they know where to look at.
> 
> If maintainers can't rely on that expectation, then they can get very
> chilly about applying patches as they know any breakage might not be
> acted upon, and that the burden of fixing it will pile upon them to
> increase the existing load...
> 
> Again, it is not a problem that the patch broke something; without
> trying, we can know. There is absolutely no blame on you at all for that
> patch! We are very happy for your contributions! :-)
> 
> Still, this carelessness in handling a breakage is a bit disapointing...
> 
> Anyway, I have now reverted that patch, as it was exposing another issue
> with host-python3 (https://gitlab.com/buildroot.org/buildroot/-/issues/5)

Yes, reverting the patch seems to be the best solution for the moment...

Maybe although reverting 'package/xz: explicitly specify all autoconf options'
(and 'package/xz: enable year2038 option') as I used the same
'HOST_XZ_CONF_OPTS = $(XZ_CONF_OPTS)...' pattern here?

Regards,
Peter

> 
> When the cmake buildsystem is official, then do not hesitate to resubmit
> an improved patch, based on the commit that was initially applied. If
> you hit a road-block, do not hesitate to ask for further help, of
> course!
> 
> Thank you!
> 
> Regards,
> Yann E. MORIN.
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot