From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] List of pending patches: what to do?
Date: Wed, 31 Jul 2013 14:51:57 -0300 [thread overview]
Message-ID: <51F94EBD.7060309@zacarias.com.ar> (raw)
In-Reply-To: <20130731191415.545f7dff@skate>
On 07/31/2013 02:14 PM, Thomas Petazzoni wrote:
> http://patchwork.ozlabs.org/patch/155498 New: add lava-test package
I managed to get this working with modifications and the python fixes
(which are already in the tree).
However from what i've seen it doesn't seem useful for anything by
itself, it's a testing framework with the builtins being pretty
ubuntu-specific (and requiring a ton of other deps).
Not sure what to do about it, it's not an out-of-the-box experience, it
requires extensive tweaking to do anything useful.
> http://patchwork.ozlabs.org/patch/165542 [V2] p910nd: Add p910nd lightweight printserver
I'll rebase and give this one a try.
> http://patchwork.ozlabs.org/patch/172171 avahi: only install default.script/S05avahi-setup.sh if not present in fs skeleton
I'm generally against initscript conditionals - after all who says it'll
have the same sequence number or name in the skeleton?
Post-build script IMHO.
Otherwise a global option "don't install initscripts" might fit, however
i've been using the script just fine for ages now.
> http://patchwork.ozlabs.org/patch/178526 syslinux: fix host build with newer Linux headers
Version bump might be fitting, it's up to 6.01 now.
> http://patchwork.ozlabs.org/patch/185522 eaccelerator
> http://patchwork.ozlabs.org/patch/186837 Add config for PHP eaccelerator package. Signed-off-by: Dallas Clement <dallas.a.clement@gmail.com>
Not really an embedded-y package, eaccelerator and similar packages like
xcache are basically intermediate opcode caches for the php
interpreter/files.
Basically you set aside an X amount of RAM (in the 2-digit MiB range
usually) for that and successive hits get a good speed boost because
they don't need to be re-interpreted again and again.
This is a feature included in the PHP 5.5.x release, however i doubt
we'll be bumping soon to it, 5.4.x is a better fit for now since 5.3.x
is getting unsupported status soon.
Widely used for big PHP deployments with many page hits - so i'm hmm
about it and eventually it'll go away with PHP 5.5
And it's tied up to PHP 5.3.x so it will block a 5.4.x or 5.5.x update
unless we use the main git branch (no release yet, upstream is somewhat
dead).
> http://patchwork.ozlabs.org/patch/196141 uClibc: install libc.so even if BR2_PREFER_STATIC_LIB is enabled
We should really "mv BR2_PREFER_STATIC_LIB BR2_STATIC_BUILD" or so as
you've mentioned before - you either want or don't (want) a static build.
> http://patchwork.ozlabs.org/patch/198127 automake version update 1.12.4
for-2013.12 i'll revisit bumping automake, at the moment i'd say no, and
since there are newer versions "deferred" or "superseeded" would be
appropiate.
> http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
> http://patchwork.ozlabs.org/patch/243445 [4/6] libcurl: bump to version 7.30.0
These depend on the generic package cleanups and some autotools package
audits (maybe fixes). I've deferred them already, they're on my TODO
list and i'll send new appropiate patches when it's done, for-2013.12.
libcurl security patches are already in the tree so there's no rush.
Regards.
next prev parent reply other threads:[~2013-07-31 17:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
2013-07-31 17:18 ` Thomas Petazzoni
2013-07-31 20:44 ` Yann E. MORIN
2013-08-01 5:39 ` Thomas Petazzoni
2013-07-31 17:51 ` Gustavo Zacarias [this message]
2013-08-01 5:50 ` Thomas Petazzoni
2013-07-31 20:45 ` Thomas De Schampheleire
2013-07-31 20:57 ` Yann E. MORIN
2013-08-01 5:59 ` Thomas Petazzoni
2013-08-01 20:24 ` Yann E. MORIN
2013-07-31 20:55 ` Yann E. MORIN
2013-08-01 6:04 ` Thomas Petazzoni
2013-07-31 22:13 ` Samuel Martin
2013-07-31 22:20 ` Yann E. MORIN
2013-08-01 16:23 ` Thomas Petazzoni
2013-08-01 21:30 ` Samuel Martin
2013-08-02 8:33 ` Thomas De Schampheleire
2013-08-02 8:50 ` Thomas Petazzoni
2013-08-02 9:09 ` Thomas De Schampheleire
2013-08-02 9:10 ` Thomas Petazzoni
2013-08-02 9:27 ` Thomas De Schampheleire
2013-08-12 21:01 ` Arnout Vandecappelle
2013-08-01 2:52 ` Danomi Manchego
2013-08-01 6:13 ` Thomas Petazzoni
2013-08-01 20:14 ` Yann E. MORIN
2013-08-01 6:54 ` Simon Dawson
2013-08-01 7:41 ` Thomas Petazzoni
2013-08-01 16:16 ` Thomas Petazzoni
2013-08-02 8:10 ` Jérôme Pouiller
2013-08-02 11:11 ` Patrick Ziegler
2013-08-02 11:17 ` Thomas Petazzoni
2013-08-19 10:35 ` Luca Ceresoli
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=51F94EBD.7060309@zacarias.com.ar \
--to=gustavo@zacarias.com.ar \
--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