[Buildroot] Patchwork cleanup, 10 patches to look at
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Tue Mar 28 20:25:25 UTC 2017
Hello,
On Mon, 27 Mar 2017 14:35:46 +0200, Arnout Vandecappelle wrote:
> > * avahi: link with libintl if libglib2 is enabled
> > https://patchwork.ozlabs.org/patch/683732/
> >
> > My plan is to enable the stub libintl in uClibc-ng and stop having
> > all those linking issues with libintl from gettext. The only
> > drawback would be that there would no longer be "translation"
> > support with uClibc: the libintl implementation in uClibc-ng is
> > really just a stub.
> >
> > Thoughts ?
>
> I think having internationalization support can still be useful in a
> Buildroot/uClibc based system, e.g. to support translation of a custom CLI UI.
> So using the stub implementation unconditionally sounds like a bad idea.
>
> How about instead making gettext/intl support depend on !static? That's also a
> catch-all solution, but a lot less aggressive.
Indeed, that's a solution. This solves the static linking issues, but
by getting rid of libintl from gettext entirely, I was hoping to remove
all the BR2_NEEDS_GETTEXT/BR2_NEEDS_GETTEXT_IF_LOCALE stuff.
But yes, I can understand that i18n support can be useful in a uClibc
based system.
However, the !static dependency then needs to be propagated to all
places where libintl is used, but only if uClibc is used. It's a bit of
a nightmare :-/
> > * qemu: allow to build statically
> > https://patchwork.ozlabs.org/patch/692667/
> >
> > We normally don't want to have special options for each package to
> > build them statically. Should we make an exception for Qemu?
>
> I see something like this like having package options that do little more than
> selecting other packages, like BR2_PACKAGE_PHP_EXT_BZIP2. It's something we want
> to avoid, but sometimes there are good reasons to do it.
>
> So for Qemu and also for Docker I do think it makes sense to have static as a
> per-package option.
ACK, so I'll apply the patch from Jérôme.
> > * infra: fix 'packages-file-list.txt' with TLP
> > https://patchwork.ozlabs.org/patch/694519/
> >
> > Adds a lock around the installation step of packages, to make
> > top-level parallel build still generate a correct list of files per
> > package.
> >
> > Gustavo, what is your plan regarding this?
> >
> > Others: should we merge this?
>
> I don't think this is the proper approach. The proper approach is map/reduce,
> i.e. generate the pieces in per-package files and collect them together in a
> final gathering stage. Obviously, this requires a per-package target first, but
> that's anyway the way we want to go.
>
> I thought someone already made that comment but I can't find it in that thread...
OK, so I'll mark the patch as Rejected.
> > * linux-headers: Account for LINUX_OVERRIDE_SRCDIR
> > https://patchwork.ozlabs.org/patch/713927/
> >
> > I think I am against this patch, because if the user sets
> > LINUX_OVERRIDE_SRCDIR, then suddenly he will see his kernel headers
> > being rebuilt as well.
> >
> > Arnout ?
>
> Well, as you can see in the discussion thread, I argued against it, asked for a
> stronger argument for it, but none was forthcoming.
>
> However, my conclusion was that we should either apply this, or fix the
> documentation so that it explains that HEADERS_SAME_AS_KERNEL doesn't apply if
> LINUX_OVERRIDE_SRCDIR (or LINUX_SITE_METHOD = local) is set.
I'm also not a big fan of this patch. I prefer if LINUX_OVERRIDE_SRCDIR
really only affects the linux package, to me it's just applying the
principle of least surprise.
> > * python-lxml: allow build as host package
> > https://patchwork.ozlabs.org/patch/722644/
> >
> > Host package not used anywhere. Discussed at length during the
> > previous BR meeting. What do we do?
>
> The conclusion at BR meeting was unfortunately not clear, but we definitely
> said that we would be more lenient towards this kind of addition. So I'd say we
> accept it (with a Config.in.host entry, though).
ACK.
> > * package/pkg-download.mk: add gitlab helper
> > https://patchwork.ozlabs.org/patch/736382/
>
> I'm not a fan of adding helpers (in fact, I think the github helper should
> die). For gitlab, however, the URL construction is indeed a bit peculiar and it
> differs a lot from the URL a user normally sees (adding that &filename= thing),
> so it does make sense to have it. Since I couldn't decide, I didn't reply :-)
Nothing in Buildroot currently fetches its source code from Gitlab.
This change was proposed for the CIP long-term kernel version, but
according to
https://wiki.linuxfoundation.org/civilinfrastructureplatform/start:
"""Check the 4.4 CIP kernel repository, mirrored in Gitlab"""
So in fact their primary kernel repository is
https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git/, not
the one on gitlab. And additionally, their gitlab mirror is apparently
not working as expected:
https://lists.cip-project.org/pipermail/cip-dev/2017-March/000167.html.
So I guess we should use the git.kernel.org repository instead.
And I still think the BR2_LINUX_KERNEL_LATEST_CIP_VERSION_BRANCH option
is not good, as it uses the "latest" version available, which makes the
build non-reproducible. I argued about this with Angelo, but I was a
bit alone against Angelo on the matter. Could some other folks give
their opinion so that we can resolve the debate?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
More information about the buildroot
mailing list