[Buildroot] Towards 2015.05-rc1

[Buildroot] Towards 2015.05-rc1

[Thomas Petazzoni]

Hello,

We're about 10 days from cutting 2015.05-rc1, so we have only 10 days
left to merge new features, new packages, major changes. Please let me
know which (big) changes you'd like to see merged.

On my list, there is at least:

 - The mandatory hashes series from Yann/Arnout.

 - The external-deps/source/source-check/legal-info fixes series from
   me.

Also, if you are worried about smaller things being merged, please make
sure to review and test the corresponding patches. If your patches
didn't get attention, try to convince someone else to review/test your
patches.

Thanks,

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

[Buildroot] Towards 2015.05-rc1

[Bernd Kuhls]

Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20150419220053.2c1d5b62 at free-electrons.com:

> We're about 10 days from cutting 2015.05-rc1, so we have only 10 days
> left to merge new features, new packages, major changes. Please let me
> know which (big) changes you'd like to see merged.

Hi,

if possible and time allows for all involved persons I would like to see the 
libudev series stuff in the next buildroot release. 

Regards, Bernd

[Buildroot] Towards 2015.05-rc1

[Thomas Petazzoni]

Bernd,

On Sun, 19 Apr 2015 22:14:24 +0200, Bernd Kuhls wrote:

> if possible and time allows for all involved persons I would like to see the 
> libudev series stuff in the next buildroot release. 

As far as I remember, someone needs to take over this series, no? I
believe you originally authored it, then Yann took over, then Peter
proposed to take over but did not resend it as far as I know.

On my side, I am still a bit concerned by the usefulness of this
series. The use cases you have are anyway running big things (Kodi,
etc.) so I'm not sure why running udevd or not makes a big difference.
It does seem a lot of additional complexity for not such a huge
benefit.

Can you convince me otherwise?

Thanks,

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

[Buildroot] Towards 2015.05-rc1

[Arnout Vandecappelle]

On 19/04/15 22:00, Thomas Petazzoni wrote:
> Hello,
> 
> We're about 10 days from cutting 2015.05-rc1, so we have only 10 days
> left to merge new features, new packages, major changes. Please let me
> know which (big) changes you'd like to see merged.
> 
> On my list, there is at least:
> 
>  - The mandatory hashes series from Yann/Arnout.

 This one is actually still missing handling user-specified downloads, like
custom U-Boot version or custom Linux version. That said, most of the series
(barring the last one) could be applied as far as I'm concerned. Although I
notice now that I forgot to add my acks to my repost :-)

> 
>  - The external-deps/source/source-check/legal-info fixes series from
>    me.

 IIRC there was still something major missing in this series as well, wasn't there?


 Another series that I'd like to see is the IPv6 deprecation, and size-stats.
But I guess I should do some review there :-)


 Regards,
 Arnout


> 
> Also, if you are worried about smaller things being merged, please make
> sure to review and test the corresponding patches. If your patches
> didn't get attention, try to convince someone else to review/test your
> patches.
> 
> Thanks,
> 
> Thomas
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Towards 2015.05-rc1

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Bernd,
 > On Sun, 19 Apr 2015 22:14:24 +0200, Bernd Kuhls wrote:

 >> if possible and time allows for all involved persons I would like to see the 
 >> libudev series stuff in the next buildroot release. 

 > As far as I remember, someone needs to take over this series, no? I
 > believe you originally authored it, then Yann took over, then Peter
 > proposed to take over but did not resend it as far as I know.

Yes, sorry - I haven't forgotten about it, but I haven't been able to
find time for it yet. Realisticly seen, I probably won't be able to make
it within the next 10 days.

 > On my side, I am still a bit concerned by the usefulness of this
 > series. The use cases you have are anyway running big things (Kodi,
 > etc.) so I'm not sure why running udevd or not makes a big difference.
 > It does seem a lot of additional complexity for not such a huge
 > benefit.

I agree that it is a tradeoff. In the worst case it can be handled in a
post-build script.

My own usecase was to use libinput for some keyboard/mouse/touchscreen
handling on a small system and disliking the udevd dependency.

-- 
Bye, Peter Korsgaard

[Buildroot] Towards 2015.05-rc1

[Bernd Kuhls]

Peter Korsgaard <peter@korsgaard.com> wrote in
news:87sibutq0q.fsf at dell.be.48ers.dk: 

>>>>>> "Thomas" == Thomas Petazzoni
>>>>>> <thomas.petazzoni@free-electrons.com>
>>>>>> writes: 
> 
> > Bernd,
> > On Sun, 19 Apr 2015 22:14:24 +0200, Bernd Kuhls wrote:
> 
> >> if possible and time allows for all involved persons I would like to
> >> see the libudev series stuff in the next buildroot release. 
> 
> > As far as I remember, someone needs to take over this series, no? I
> > believe you originally authored it, then Yann took over, then Peter
> > proposed to take over but did not resend it as far as I know.
> 
> Yes, sorry - I haven't forgotten about it, but I haven't been able to
> find time for it yet. Realisticly seen, I probably won't be able to make
> it within the next 10 days.
> 
> > On my side, I am still a bit concerned by the usefulness of this
> > series. The use cases you have are anyway running big things (Kodi,
> > etc.) so I'm not sure why running udevd or not makes a big difference.
> > It does seem a lot of additional complexity for not such a huge
> > benefit.
> 
> I agree that it is a tradeoff. In the worst case it can be handled in a
> post-build script.
> 
> My own usecase was to use libinput for some keyboard/mouse/touchscreen
> handling on a small system and disliking the udevd dependency.
> 

Hi Peter, hi Thomas,

my plan is to provide a Kodi package for an existing distro (www.fli4l.de)
which uses buildroot to compile its binaries and uses this option: 

BR2_ROOTFS_DEVICE_CREATION_STATIC=y

and CONFIG_MDEV=y in busybox.config

These settings forbid enabling udev which blocks mesa3d, and therefore
kodi, on x86. 

Regards, Bernd

[Buildroot] Towards 2015.05-rc1

[Arnout Vandecappelle]

On 04/19/15 23:02, Thomas Petazzoni wrote:
> Bernd,
> 
> On Sun, 19 Apr 2015 22:14:24 +0200, Bernd Kuhls wrote:
> 
>> if possible and time allows for all involved persons I would like to see the 
>> libudev series stuff in the next buildroot release. 
> 
> As far as I remember, someone needs to take over this series, no? I
> believe you originally authored it, then Yann took over, then Peter
> proposed to take over but did not resend it as far as I know.
> 
> On my side, I am still a bit concerned by the usefulness of this
> series. The use cases you have are anyway running big things (Kodi,
> etc.) so I'm not sure why running udevd or not makes a big difference.
> It does seem a lot of additional complexity for not such a huge
> benefit.

 Since udev rules are IMHO a lot more complicated than mdev rules and you
usually don't need that complexity in embedded systems, I think there really is
a case to be made for avoiding full udev. Of course, it's always possible to
remove the udev start script in a post-build script (which effectively makes
udev dead code), but it is definitely nice to know which packages will work
without udev running. So that's what I would like this libudev stuff to do.

 For example, I have one system that used to be based on mdev. Now we have to
add modem-manager to it, and modem-manager depends on udev. So I've enabled
udev, but now I have to replace the mdev rules with udev rules and I probably
also have to get rid of some of the default udev rules which are not appropriate.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Towards 2015.05-rc1

[Gustavo Zacarias]

On 04/22/2015 07:18 PM, Arnout Vandecappelle wrote:

>  Since udev rules are IMHO a lot more complicated than mdev rules and you
> usually don't need that complexity in embedded systems, I think there really is
> a case to be made for avoiding full udev. Of course, it's always possible to
> remove the udev start script in a post-build script (which effectively makes
> udev dead code), but it is definitely nice to know which packages will work
> without udev running. So that's what I would like this libudev stuff to do.
> 
>  For example, I have one system that used to be based on mdev. Now we have to
> add modem-manager to it, and modem-manager depends on udev. So I've enabled
> udev, but now I have to replace the mdev rules with udev rules and I probably
> also have to get rid of some of the default udev rules which are not appropriate.

There's also usbutils which now requires the udev hwdb and libudev.
I expect to see this kind of requirement for other packages in the
future, the latest pciutils for example benefits with the same trickery,
and though it still works without it i wonder for how long.
Regards.