[Buildroot] Patchwork cleanup, week #22

[Yann E. MORIN <yann.morin.1998@free.fr>]

Thomas, All,

On 2016-06-01 23:26 +0200, Thomas Petazzoni spake thusly:
> Our patchwork currently has ~270 patches pending, so we need to do
> something to clean up the backlog of patches. To do this, I will try to
> revive an initiative that was started by Thomas De Schampheleire a few
> years ago, which had proven to be useful.

Thanks for re-starting this! :-)

>  1/ package/libgpg-error: bump to version 1.21
>     http://patchwork.ozlabs.org/patch/562100/
> 
>     I don't really have any comments, other than the fact that it is
>     super annoying for a package with so many dependencies to start
>     having architecture dependencies. Could someone refresh and
>     validate this patch?

Hmm... Fact is, upstream has not been very responsive to the proposal
for dumping the architecture detection:

    http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21150
    http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21176

They don't even seem to understand the problem... :-(

So, either we get stuck with the current version, but as Gustavo
noticed, that would preclude updtating libgcrypt, or we bump and have to
suffer this arch limitation...

>  3/ RFC: adding customizable linux logo
>     http://patchwork.ozlabs.org/patch/577638/
> 
>     This creates a "Linux extension" to easily customize the Linux
>     logo. Do we care? The current implementation assumes imagemagick is
>     available on the host, which probably isn't good. Probably the
>     customlogo package is not needed, and convert the image to the
>     appropriate format can be done directly in the
>     CUSTOMLOGO_PREPARE_KERNEL hook.
> 
>     Do we want such a feature?

Well, we can certainly accept that, but as I replied, let's just expect
the user to provide already rendered ppm/pbm images.

However, the ppm/pbm files are just text file. A user could provide a
patch to change the logo, and we already have the necessary infra to
apply patches...

>  6/ Makefile: Fix overlay overwriting everything
>     http://patchwork.ozlabs.org/patch/581463/
> 
>     A problem with the merged /usr option, and when the rootfs overlay
>     contains specific directories. Discussion has happened, no decision.

As already pointed out, this is supposedly fixed. I replied to Maxime,
askign him that he confirms the fix we already have works for him and if
so, that he marks his patch as superseded in patchwork.

>  7/ apply-patches.sh: handle any file name as *.patch
>     http://patchwork.ozlabs.org/patch/595693/

I am absolutely not decided on that one. Surely, it has the potential to
cause quite some harm...

>  10/ The remaining "help text" related patches from Yann
>      http://patchwork.ozlabs.org/patch/596393/
>      http://patchwork.ozlabs.org/patch/596396/
>      http://patchwork.ozlabs.org/patch/596397/
>      http://patchwork.ozlabs.org/patch/596398/
>      http://patchwork.ozlabs.org/patch/596399/
>      http://patchwork.ozlabs.org/patch/596395/
> 
>      Do we want this?
> 
>      I like the general idea personally, but I continue to dislike the
>      fact that the formatting is enforced at the infra level, with this
>      weird syntax. I'd prefer packages to simply contribute a
>      HELP_CMDS, or register a hook, where they can use "echo" to display
>      whatever they want.

I have been thinking about that one. As I asid, I'm not too fond of
letting packages handle their own formatting. But I can understand that
you do not like it (why? ;-] ).

So, I'll rework the series shortly. In the meantime, I've marked it as
changes-requested in patchwork.

Regards,
Yann E. MORIN.

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