From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Patchwork cleanup, 10 patches to look at
Date: Sun, 26 Mar 2017 23:53:20 +0200 [thread overview]
Message-ID: <20170326235320.448e802a@free-electrons.com> (raw)
Hello,
I'd like to again restart the patchwork cleanup effort. There are
numerous patches in patchwork that I'm not sure what we want to do
with.
Here is a list of 10 patches that we need to take a decision on. If no
decision is taken in the next 2 weeks, I'll mark them as Rejected.
* 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 ?
* 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?
* 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?
* e2fsprogs: keep util-linux's fsck if chosen
https://patchwork.ozlabs.org/patch/696634/
This fixes a real bug, but even Maxime who submitted the patch is
not too happy with the proposal. Could someone look into this?
* 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 ?
* 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?
* fakedate: simplify logic
https://patchwork.ozlabs.org/patch/725396/
* linux-tools/perf: fix build for MIPS by using the right emulation on
LD
https://patchwork.ozlabs.org/patch/729154/
* package/pkg-download.mk: add gitlab helper
https://patchwork.ozlabs.org/patch/736382/
* linux: Add CIP SLTS easy selection option
https://patchwork.ozlabs.org/patch/736383/
Please help taking decisions about those patches.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next reply other threads:[~2017-03-26 21:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-26 21:53 Thomas Petazzoni [this message]
2017-03-27 12:35 ` [Buildroot] Patchwork cleanup, 10 patches to look at Arnout Vandecappelle
2017-03-27 13:43 ` Andrey Smirnov
2017-03-28 20:25 ` Thomas Petazzoni
2017-04-03 10:42 ` [Buildroot] libintl static linking issues - yet another spin Arnout Vandecappelle
2017-04-03 11:01 ` Thomas Petazzoni
2017-04-03 11:25 ` Arnout Vandecappelle
2017-04-03 12:11 ` Thomas Petazzoni
2017-04-03 12:30 ` Waldemar Brodkorb
2017-04-03 12:45 ` Arnout Vandecappelle
2017-04-03 13:02 ` Thomas Petazzoni
2017-04-03 14:12 ` Arnout Vandecappelle
2017-04-01 16:52 ` [Buildroot] Patchwork cleanup, 10 patches to look at Thomas Petazzoni
2017-04-02 3:04 ` Carlos Santos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170326235320.448e802a@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox