[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

All,

Here is the session 4 of the patchwork cleanup. For those who haven't
followed previous sessions, here is a quick recap: every session we'll
be posting the list of the 10 oldest patches, with the original patch
contributors in copy. During two weeks, we have the opportunity to
discuss the patch, whether it is still necessary or not, how it should
be changed to be merged.

In particular, I'm interested in knowing if the original contributor is
still interested by the patch, or if someone else is interested in
adopting the patch and sending an updated version, or if the patch no
longer makes sense due to other changes made in Buildroot.

All patches that have not received any comment or attention before the
deadline will be removed from patchwork. This is aggressive, but we have
many 'dead' patches sitting in patchwork, and this cannot work.

Deadline for this session is December 20.

Below are the 10 oldest patches (obtained with a slightly modified
version of pwclient):
[ pwclient list -s New -n 14 ] (and skip Delegated patches)


lua: remove shared library feature
Arnout Vandecappelle <arnout@mind.be>
http://patchwork.ozlabs.org/patch/197028

perl: fix build
Francois Perrad <fperrad@gmail.com>
http://patchwork.ozlabs.org/patch/198013

libatomic_ops version update 7.3alpha2 old version 1.2 does not
compiles with modern gcc and utils
Alexander Khryukin <alexander@mezon.ru>
http://patchwork.ozlabs.org/patch/198133

[1/1] mesa3d: build with host library with python support
Noel vellemans <noel.vellemans@visionbms.com>
http://patchwork.ozlabs.org/patch/198840

[07/10] libffi: make thread support optional
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
http://patchwork.ozlabs.org/patch/199883

busybox: needs linux-pam dependency added if using custom busybox
.config & busybox login applet
Stefan Fr?berg <stefan.froberg@petroprogram.com>
http://patchwork.ozlabs.org/patch/199891

[RESEND,2/2] wpa_supplicant: rework .config file editing
Arnout Vandecappelle <arnout@mind.be>
http://patchwork.ozlabs.org/patch/207037

[4/4] gstreamer: replace gst-ffmpeg with gst-libav
bogdan at nimblex.org
http://patchwork.ozlabs.org/patch/207431

[1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
Gary Coulbourne <bear@bears.org>
http://patchwork.ozlabs.org/patch/207507

[2/2] dbus: fix permissions of the installed launch helper
Gary Coulbourne <bear@bears.org>
http://patchwork.ozlabs.org/patch/207508


Thanks for your input,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Yann E. MORIN]

Thomas, All,

On 2013-12-22 21:46 +0100, Thomas De Schampheleire spake thusly:
> Here is the session 4 of the patchwork cleanup.
[--SNIP--]
> lua: remove shared library feature
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/197028

This one is being revived as part of the LuaRocks infrastrucutre by
Francois, which we're currently working on:
    http://lists.busybox.net/pipermail/buildroot/2013-December/085243.html

So I'll mark as 'superseded'.

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 22 Dec 2013 21:46:32 +0100, Thomas De Schampheleire wrote:

> perl: fix build
> Francois Perrad <fperrad@gmail.com>
> http://patchwork.ozlabs.org/patch/198013

Let's see what Fran?ois says about this one.

> [1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
> Gary Coulbourne <bear@bears.org>
> http://patchwork.ozlabs.org/patch/207507

This is still needed: our DBus version is old.

> [2/2] dbus: fix permissions of the installed launch helper
> Gary Coulbourne <bear@bears.org>
> http://patchwork.ozlabs.org/patch/207508

We can mark this one as superseded: Peter fixed it in
aab3a0ba792f33aae66757f0e5c3fc67e41104ec.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Yann, Thomas,


On Mon, Dec 23, 2013 at 8:51 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Sun, 22 Dec 2013 21:46:32 +0100, Thomas De Schampheleire wrote:
>
>> perl: fix build
>> Francois Perrad <fperrad@gmail.com>
>> http://patchwork.ozlabs.org/patch/198013
>
> Let's see what Fran?ois says about this one.
>
>> [1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
>> Gary Coulbourne <bear@bears.org>
>> http://patchwork.ozlabs.org/patch/207507
>
> This is still needed: our DBus version is old.
>
>> [2/2] dbus: fix permissions of the installed launch helper
>> Gary Coulbourne <bear@bears.org>
>> http://patchwork.ozlabs.org/patch/207508
>
> We can mark this one as superseded: Peter fixed it in
> aab3a0ba792f33aae66757f0e5c3fc67e41104ec.
>

Thanks a lot for the feedback! Patches marked accordingly...

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[François Perrad]

2013/12/23 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Thomas De Schampheleire,
>
> On Sun, 22 Dec 2013 21:46:32 +0100, Thomas De Schampheleire wrote:
>
>> perl: fix build
>> Francois Perrad <fperrad@gmail.com>
>> http://patchwork.ozlabs.org/patch/198013
>
> Let's see what Fran?ois says about this one.
>

Now, perl is built with perl-cross.
So, this patch could be rejected.

Fran?ois.

>> [1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
>> Gary Coulbourne <bear@bears.org>
>> http://patchwork.ozlabs.org/patch/207507
>
> This is still needed: our DBus version is old.
>
>> [2/2] dbus: fix permissions of the installed launch helper
>> Gary Coulbourne <bear@bears.org>
>> http://patchwork.ozlabs.org/patch/207508
>
> We can mark this one as superseded: Peter fixed it in
> aab3a0ba792f33aae66757f0e5c3fc67e41104ec.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

On Mon, Dec 23, 2013 at 1:18 PM, Fran?ois Perrad
<francois.perrad@gadz.org> wrote:
> 2013/12/23 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>> Dear Thomas De Schampheleire,
>>
>> On Sun, 22 Dec 2013 21:46:32 +0100, Thomas De Schampheleire wrote:
>>
>>> perl: fix build
>>> Francois Perrad <fperrad@gmail.com>
>>> http://patchwork.ozlabs.org/patch/198013
>>
>> Let's see what Fran?ois says about this one.
>>
>
> Now, perl is built with perl-cross.
> So, this patch could be rejected.

Ok, thanks for the feedback. Marked as such in patchwork...

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi all,

Here is the conclusion from this patchwork session.
Due to the holidays I did not sent an intermediate reminder, so if you
are still interested in any of these patches just let me know.

On Sun, Dec 22, 2013 at 9:46 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> All,
>
> Here is the session 4 of the patchwork cleanup. For those who haven't
> followed previous sessions, here is a quick recap: every session we'll
> be posting the list of the 10 oldest patches, with the original patch
> contributors in copy. During two weeks, we have the opportunity to
> discuss the patch, whether it is still necessary or not, how it should
> be changed to be merged.
>
> In particular, I'm interested in knowing if the original contributor is
> still interested by the patch, or if someone else is interested in
> adopting the patch and sending an updated version, or if the patch no
> longer makes sense due to other changes made in Buildroot.
>
> All patches that have not received any comment or attention before the
> deadline will be removed from patchwork. This is aggressive, but we have
> many 'dead' patches sitting in patchwork, and this cannot work.
>
> Deadline for this session is December 20.
>
> Below are the 10 oldest patches (obtained with a slightly modified
> version of pwclient):
> [ pwclient list -s New -n 14 ] (and skip Delegated patches)
>
>
> lua: remove shared library feature
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/197028
>

Included in luarocks patchset, so this one is superseded now.

> perl: fix build
> Francois Perrad <fperrad@gmail.com>
> http://patchwork.ozlabs.org/patch/198013

Rejected as per feedback of Francois.

>
> libatomic_ops version update 7.3alpha2 old version 1.2 does not
> compiles with modern gcc and utils
> Alexander Khryukin <alexander@mezon.ru>
> http://patchwork.ozlabs.org/patch/198133

No feedback, marked as rejected.

>
> [1/1] mesa3d: build with host library with python support
> Noel vellemans <noel.vellemans@visionbms.com>
> http://patchwork.ozlabs.org/patch/198840

The changes in this patch have been applied with another one:
http://git.buildroot.org/buildroot/commit/?id=517e5395a187d9c6b7dc322ee15f7b75f5ffe7fc
so this patch is marked as superseded.

>
> [07/10] libffi: make thread support optional
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> http://patchwork.ozlabs.org/patch/199883

No feedback, marked as rejected.

>
> busybox: needs linux-pam dependency added if using custom busybox
> .config & busybox login applet
> Stefan Fr?berg <stefan.froberg@petroprogram.com>
> http://patchwork.ozlabs.org/patch/199891

No feedback, marked as rejected.

>
> [RESEND,2/2] wpa_supplicant: rework .config file editing
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/207037

No feedback, but the patch seems sane and still releant, so I'm
hesitant to mark it as rejected.
I'll mark it as 'delegated to me' in the mean time, but maybe Arnout:
could you rebase if needed and resend? Thanks.

>
> [4/4] gstreamer: replace gst-ffmpeg with gst-libav
> bogdan at nimblex.org
> http://patchwork.ozlabs.org/patch/207431

No feedback, rejected.

>
> [1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
> Gary Coulbourne <bear@bears.org>
> http://patchwork.ozlabs.org/patch/207507

No feedback, rejected.

>
> [2/2] dbus: fix permissions of the installed launch helper
> Gary Coulbourne <bear@bears.org>
> http://patchwork.ozlabs.org/patch/207508

Superseded by:
http://git.buildroot.org/buildroot/commit/?id=aab3a0ba792f33aae66757f0e5c3fc67e41104ec

Thanks all for your input,

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

On Sun, Jan 5, 2014 at 11:21 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
[..]
>>
>> [1/2] dbus: bump dbus version from 1.4.24 to current 1.6.8
>> Gary Coulbourne <bear@bears.org>
>> http://patchwork.ozlabs.org/patch/207507
>
> No feedback, rejected.

Sorry, this was incorrect. There was feedback from ThomasP stating
this was still needed.

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 5 Jan 2014 11:21:33 +0100, Thomas De Schampheleire wrote:

> > libatomic_ops version update 7.3alpha2 old version 1.2 does not
> > compiles with modern gcc and utils
> > Alexander Khryukin <alexander@mezon.ru>
> > http://patchwork.ozlabs.org/patch/198133
> 
> No feedback, marked as rejected.

I think bumping the version of a package is often useful, so I'm not
sure I would mark this patch as rejected. Or if no one is pushing to
bump libatomic_ops, then we should just assume no one cares, and
therefore there's no point in keeping the patch around?

> > [07/10] libffi: make thread support optional
> > Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > http://patchwork.ozlabs.org/patch/199883
> 
> No feedback, marked as rejected.

It's weird because I don't see libffi build failures in the
autobuilders, even though there is one no thread ARM toolchain in the
configurations.

> > [4/4] gstreamer: replace gst-ffmpeg with gst-libav
> > bogdan at nimblex.org
> > http://patchwork.ozlabs.org/patch/207431
> 
> No feedback, rejected.

I'm a little bit concerned about how we reject patches here. Maybe
replacing gst-ffmpeg by gst-libav makes sense and should be done? If we
don't keep the patch around, we'll have no way to remember that it
should be done at some point in the future. I admit that by doing
this, we'll never shrink the list of pending patches, but I have the
feeling that we might be missing useful ideas.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi Thomas,

On Mon, Jan 6, 2014 at 6:05 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> > [07/10] libffi: make thread support optional
>> > Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> > http://patchwork.ozlabs.org/patch/199883
>>
>> No feedback, marked as rejected.
>
> It's weird because I don't see libffi build failures in the
> autobuilders, even though there is one no thread ARM toolchain in the
> configurations.
>

It's weird indeed, maybe this has been changed in a newer version of libffi?
In any case, if there are no failures anymore, we could forget about
this patch, until this problem would pop up again.

>> > libatomic_ops version update 7.3alpha2 old version 1.2 does not
>> > compiles with modern gcc and utils
>> > Alexander Khryukin <alexander@mezon.ru>
>> > http://patchwork.ozlabs.org/patch/198133
>>
>> No feedback, marked as rejected.
>
> I think bumping the version of a package is often useful, so I'm not
> sure I would mark this patch as rejected. Or if no one is pushing to
> bump libatomic_ops, then we should just assume no one cares, and
> therefore there's no point in keeping the patch around?
>
>> > [4/4] gstreamer: replace gst-ffmpeg with gst-libav
>> > bogdan at nimblex.org
>> > http://patchwork.ozlabs.org/patch/207431
>>
>> No feedback, rejected.
>
> I'm a little bit concerned about how we reject patches here. Maybe
> replacing gst-ffmpeg by gst-libav makes sense and should be done? If we
> don't keep the patch around, we'll have no way to remember that it
> should be done at some point in the future. I admit that by doing
> this, we'll never shrink the list of pending patches, but I have the
> feeling that we might be missing useful ideas.

I grouped these two because the bottom line is the same: what to do
with patches that did not receive feedback?

It's true that simply rejecting these patches just to make the list
smaller is not the best solution.
I think we need some kind of adopt-a-patch principle if we ever want
these patches to be integrated. For some of the patches from the
cleanups, I marked it as 'delegated to me' so we wouldn't forget. This
was either because the original author gave feedback, or in the case
of wpa_supplicant because I felt that we should keep the patch. I hope
to find some time sooner or later (ideally within the 2014.02 cycle)
to verify them and resubmit.

However, I cannot do this for all patches. For example, I'm not
familiar with gstreamer at all, so I couldn't tell whether the
replacement of gst-ffmpeg with gst-libav makes sense or not, which
side-effects it may have for users, etc. If there are other developers
that have a better view on it, then please step forward. It would
indeed be a pity to lose these patches if they are relevant for
someone.

For this cycle, there was no response on these patches, hence the rejection.
Based on your latest feedback, we could change this rejection into a
delegation, to you or someone else. What do you say?

Specifically for libatomic_ops: it seems there is a github repo now:
https://github.com/ivmai/libatomic_ops/
where a 7.4.0 version is available. What about going that route then?
Are you, or someone else, interested in taking this delegation?

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Bogdan Radulescu]

Hi,

Regarding the http://patchwork.ozlabs.org/patch/207431 patch.
GStreamer switched from ffmpeg to libav a while ago and newer versions
don't have the ffmpeg package.
http://gstreamer.freedesktop.org/releases/gst-libav/0.11.90.html
http://gstreamer.freedesktop.org/src/gst-ffmpeg/gst-ffmpeg-1.x-README.txt

gst-ffmpeg was last updated almost two years ago.

Even though irrelevant, the situation of ffmpeg and libav is explained here:
http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

The patch was used in production so it's tested.

I think it would be a step back if this patch is discarded.

Best regards,
Bogdan


On Mon, Jan 6, 2014 at 12:16 PM, Thomas De Schampheleire <
patrickdepinguin@gmail.com> wrote:

> Hi Thomas,
>
> On Mon, Jan 6, 2014 at 6:05 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >> > [07/10] libffi: make thread support optional
> >> > Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> > http://patchwork.ozlabs.org/patch/199883
> >>
> >> No feedback, marked as rejected.
> >
> > It's weird because I don't see libffi build failures in the
> > autobuilders, even though there is one no thread ARM toolchain in the
> > configurations.
> >
>
> It's weird indeed, maybe this has been changed in a newer version of
> libffi?
> In any case, if there are no failures anymore, we could forget about
> this patch, until this problem would pop up again.
>
> >> > libatomic_ops version update 7.3alpha2 old version 1.2 does not
> >> > compiles with modern gcc and utils
> >> > Alexander Khryukin <alexander@mezon.ru>
> >> > http://patchwork.ozlabs.org/patch/198133
> >>
> >> No feedback, marked as rejected.
> >
> > I think bumping the version of a package is often useful, so I'm not
> > sure I would mark this patch as rejected. Or if no one is pushing to
> > bump libatomic_ops, then we should just assume no one cares, and
> > therefore there's no point in keeping the patch around?
> >
> >> > [4/4] gstreamer: replace gst-ffmpeg with gst-libav
> >> > bogdan at nimblex.org
> >> > http://patchwork.ozlabs.org/patch/207431
> >>
> >> No feedback, rejected.
> >
> > I'm a little bit concerned about how we reject patches here. Maybe
> > replacing gst-ffmpeg by gst-libav makes sense and should be done? If we
> > don't keep the patch around, we'll have no way to remember that it
> > should be done at some point in the future. I admit that by doing
> > this, we'll never shrink the list of pending patches, but I have the
> > feeling that we might be missing useful ideas.
>
> I grouped these two because the bottom line is the same: what to do
> with patches that did not receive feedback?
>
> It's true that simply rejecting these patches just to make the list
> smaller is not the best solution.
> I think we need some kind of adopt-a-patch principle if we ever want
> these patches to be integrated. For some of the patches from the
> cleanups, I marked it as 'delegated to me' so we wouldn't forget. This
> was either because the original author gave feedback, or in the case
> of wpa_supplicant because I felt that we should keep the patch. I hope
> to find some time sooner or later (ideally within the 2014.02 cycle)
> to verify them and resubmit.
>
> However, I cannot do this for all patches. For example, I'm not
> familiar with gstreamer at all, so I couldn't tell whether the
> replacement of gst-ffmpeg with gst-libav makes sense or not, which
> side-effects it may have for users, etc. If there are other developers
> that have a better view on it, then please step forward. It would
> indeed be a pity to lose these patches if they are relevant for
> someone.
>
> For this cycle, there was no response on these patches, hence the
> rejection.
> Based on your latest feedback, we could change this rejection into a
> delegation, to you or someone else. What do you say?
>
> Specifically for libatomic_ops: it seems there is a github repo now:
> https://github.com/ivmai/libatomic_ops/
> where a 7.4.0 version is available. What about going that route then?
> Are you, or someone else, interested in taking this delegation?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140106/c3c04121/attachment-0001.html>

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi Bogdan,

Sorry for the late reply...

On Mon, Jan 6, 2014 at 11:48 AM, Bogdan Radulescu <bogdan@nimblex.net> wrote:
> Hi,
>
> Regarding the http://patchwork.ozlabs.org/patch/207431 patch.
> GStreamer switched from ffmpeg to libav a while ago and newer versions don't
> have the ffmpeg package.
> http://gstreamer.freedesktop.org/releases/gst-libav/0.11.90.html
> http://gstreamer.freedesktop.org/src/gst-ffmpeg/gst-ffmpeg-1.x-README.txt
>
> gst-ffmpeg was last updated almost two years ago.
>
> Even though irrelevant, the situation of ffmpeg and libav is explained here:
> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
>
> The patch was used in production so it's tested.
>
> I think it would be a step back if this patch is discarded.
>

Thanks a lot for your feedback. The info you gave is very interesting.
In fact, it's the type of information that would be suitable for the
commit message, as it gives the rationale for the switch.

Based on your feedback, I agree we shouldn't throw away this patch.
Would it be possible for you to rebase the patch based on latest
buildroot and resubmit? In the mean time some of the code changed, for
example the multimedia directory is removed now. If you have time, I
think this would be the fastest and best solution, as you are the
original author.

Awaiting your feedback, I'll already mark it as 'Delegated to me', so
that the patch is not forgotten.

Thanks,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi Bogdan,

On Mon, Jan 20, 2014 at 4:48 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Bogdan,
>
> Sorry for the late reply...
>
> On Mon, Jan 6, 2014 at 11:48 AM, Bogdan Radulescu <bogdan@nimblex.net> wrote:
>> Hi,
>>
>> Regarding the http://patchwork.ozlabs.org/patch/207431 patch.
>> GStreamer switched from ffmpeg to libav a while ago and newer versions don't
>> have the ffmpeg package.
>> http://gstreamer.freedesktop.org/releases/gst-libav/0.11.90.html
>> http://gstreamer.freedesktop.org/src/gst-ffmpeg/gst-ffmpeg-1.x-README.txt
>>
>> gst-ffmpeg was last updated almost two years ago.
>>
>> Even though irrelevant, the situation of ffmpeg and libav is explained here:
>> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
>>
>> The patch was used in production so it's tested.
>>
>> I think it would be a step back if this patch is discarded.
>>
>
> Thanks a lot for your feedback. The info you gave is very interesting.
> In fact, it's the type of information that would be suitable for the
> commit message, as it gives the rationale for the switch.
>
> Based on your feedback, I agree we shouldn't throw away this patch.
> Would it be possible for you to rebase the patch based on latest
> buildroot and resubmit? In the mean time some of the code changed, for
> example the multimedia directory is removed now. If you have time, I
> think this would be the fastest and best solution, as you are the
> original author.
>
> Awaiting your feedback, I'll already mark it as 'Delegated to me', so
> that the patch is not forgotten.

Please have a look at this thread:
http://lists.busybox.net/pipermail/buildroot/2014-January/087200.html
It seems that there is a patch addressing the same issue but in a
different way is already included in buildroot.
It would be great if you and Bernd could check what is still needed
from your patch.

Thanks,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Bogdan Radulescu]

Hello guys,

Unfortunately I am not using buildroot at the moment and it would probably
be a while until I would be able to test and rebase this.
It would be great if you could have a look at my old patches and see what
can be reused from it.

What was wrong with http://patchwork.ozlabs.org/patch/207431/ ?

Best regards,
Bogdan


On Mon, Jan 20, 2014 at 10:28 PM, Thomas De Schampheleire <
patrickdepinguin@gmail.com> wrote:

> Hi Bogdan,
>
> On Mon, Jan 20, 2014 at 4:48 PM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
> > Hi Bogdan,
> >
> > Sorry for the late reply...
> >
> > On Mon, Jan 6, 2014 at 11:48 AM, Bogdan Radulescu <bogdan@nimblex.net>
> wrote:
> >> Hi,
> >>
> >> Regarding the http://patchwork.ozlabs.org/patch/207431 patch.
> >> GStreamer switched from ffmpeg to libav a while ago and newer versions
> don't
> >> have the ffmpeg package.
> >> http://gstreamer.freedesktop.org/releases/gst-libav/0.11.90.html
> >>
> http://gstreamer.freedesktop.org/src/gst-ffmpeg/gst-ffmpeg-1.x-README.txt
> >>
> >> gst-ffmpeg was last updated almost two years ago.
> >>
> >> Even though irrelevant, the situation of ffmpeg and libav is explained
> here:
> >> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
> >>
> >> The patch was used in production so it's tested.
> >>
> >> I think it would be a step back if this patch is discarded.
> >>
> >
> > Thanks a lot for your feedback. The info you gave is very interesting.
> > In fact, it's the type of information that would be suitable for the
> > commit message, as it gives the rationale for the switch.
> >
> > Based on your feedback, I agree we shouldn't throw away this patch.
> > Would it be possible for you to rebase the patch based on latest
> > buildroot and resubmit? In the mean time some of the code changed, for
> > example the multimedia directory is removed now. If you have time, I
> > think this would be the fastest and best solution, as you are the
> > original author.
> >
> > Awaiting your feedback, I'll already mark it as 'Delegated to me', so
> > that the patch is not forgotten.
>
> Please have a look at this thread:
> http://lists.busybox.net/pipermail/buildroot/2014-January/087200.html
> It seems that there is a patch addressing the same issue but in a
> different way is already included in buildroot.
> It would be great if you and Bernd could check what is still needed
> from your patch.
>
> Thanks,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140125/04653873/attachment.html>

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi Bogdan,

On Sat, Jan 25, 2014 at 12:50 PM, Bogdan Radulescu <bogdan@nimblex.net> wrote:
> Hello guys,
>
> Unfortunately I am not using buildroot at the moment and it would probably
> be a while until I would be able to test and rebase this.
> It would be great if you could have a look at my old patches and see what
> can be reused from it.
>
> What was wrong with http://patchwork.ozlabs.org/patch/207431/ ?


I don't think it's a question of what would have been wrong with that patch.
It's just that another developer submitted a different patch,
seemingly addressing the same problem, and probably not realizing that
a year back you already wrote a patch that was still sitting in
patchwork.

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

Hi Thomas,

On Mon, Jan 6, 2014 at 11:16 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Thomas,
>
> On Mon, Jan 6, 2014 at 6:05 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>> > [07/10] libffi: make thread support optional
>>> > Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>> > http://patchwork.ozlabs.org/patch/199883
>>>
>>> No feedback, marked as rejected.
>>
>> It's weird because I don't see libffi build failures in the
>> autobuilders, even though there is one no thread ARM toolchain in the
>> configurations.
>>
>
> It's weird indeed, maybe this has been changed in a newer version of libffi?
> In any case, if there are no failures anymore, we could forget about
> this patch, until this problem would pop up again.
>
>>> > libatomic_ops version update 7.3alpha2 old version 1.2 does not
>>> > compiles with modern gcc and utils
>>> > Alexander Khryukin <alexander@mezon.ru>
>>> > http://patchwork.ozlabs.org/patch/198133
>>>
>>> No feedback, marked as rejected.
>>
>> I think bumping the version of a package is often useful, so I'm not
>> sure I would mark this patch as rejected. Or if no one is pushing to
>> bump libatomic_ops, then we should just assume no one cares, and
>> therefore there's no point in keeping the patch around?
>>
>>> > [4/4] gstreamer: replace gst-ffmpeg with gst-libav
>>> > bogdan at nimblex.org
>>> > http://patchwork.ozlabs.org/patch/207431
>>>
>>> No feedback, rejected.
>>
>> I'm a little bit concerned about how we reject patches here. Maybe
>> replacing gst-ffmpeg by gst-libav makes sense and should be done? If we
>> don't keep the patch around, we'll have no way to remember that it
>> should be done at some point in the future. I admit that by doing
>> this, we'll never shrink the list of pending patches, but I have the
>> feeling that we might be missing useful ideas.
>
> I grouped these two because the bottom line is the same: what to do
> with patches that did not receive feedback?
>
> It's true that simply rejecting these patches just to make the list
> smaller is not the best solution.
> I think we need some kind of adopt-a-patch principle if we ever want
> these patches to be integrated. For some of the patches from the
> cleanups, I marked it as 'delegated to me' so we wouldn't forget. This
> was either because the original author gave feedback, or in the case
> of wpa_supplicant because I felt that we should keep the patch. I hope
> to find some time sooner or later (ideally within the 2014.02 cycle)
> to verify them and resubmit.
>
> However, I cannot do this for all patches. For example, I'm not
> familiar with gstreamer at all, so I couldn't tell whether the
> replacement of gst-ffmpeg with gst-libav makes sense or not, which
> side-effects it may have for users, etc. If there are other developers
> that have a better view on it, then please step forward. It would
> indeed be a pity to lose these patches if they are relevant for
> someone.
>
> For this cycle, there was no response on these patches, hence the rejection.
> Based on your latest feedback, we could change this rejection into a
> delegation, to you or someone else. What do you say?
>
> Specifically for libatomic_ops: it seems there is a github repo now:
> https://github.com/ivmai/libatomic_ops/
> where a 7.4.0 version is available. What about going that route then?
> Are you, or someone else, interested in taking this delegation?

Any further feedback on this?

Thanks,
Thomas

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 20 Jan 2014 16:58:03 +0100, Thomas De Schampheleire wrote:

> > Specifically for libatomic_ops: it seems there is a github repo now:
> > https://github.com/ivmai/libatomic_ops/
> > where a 7.4.0 version is available. What about going that route then?
> > Are you, or someone else, interested in taking this delegation?
> 
> Any further feedback on this?

You can probably assign this patch to me, so that I take care of
bumping libatomic_ops in the future.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Patchwork oldest patches cleanup #4 (deadline January 5)

[Thomas De Schampheleire]

On Tue, Jan 28, 2014 at 6:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 20 Jan 2014 16:58:03 +0100, Thomas De Schampheleire wrote:
>
>> > Specifically for libatomic_ops: it seems there is a github repo now:
>> > https://github.com/ivmai/libatomic_ops/
>> > where a 7.4.0 version is available. What about going that route then?
>> > Are you, or someone else, interested in taking this delegation?
>>
>> Any further feedback on this?
>
> You can probably assign this patch to me, so that I take care of
> bumping libatomic_ops in the future.

Ok, thanks. I delegated the patch to you now...