[Pkg-lirc-maint] [PATCH 0/8] Send in Ubuntu delta in small mergable snippets

Stefan Lippers-Hollmann s.L-H at gmx.de
Fri Aug 7 20:12:58 UTC 2009


Hi

On Friday 07 August 2009, you wrote:
> Hey Stefan:
> 
> Thanks.
> 
> On Thu, Aug 6, 2009 at 18:53, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
[...]
> > [PATCH 1/8] ???
> >        seems to be missing in this patch series?
> 
> 
> Re-attaching.

Thank you, the mailing list doesn't seem to like this mail for some reason 
(probably size related).

As it seems this patch does mostly 2 things:
- nuking debconf for lirc-modules-source
	this is something I very much agree about
- switching the module buildsystem to dkms
	well, dkms has been uploaded to unstable recently and the first modules
	are switching over (drbd8-source and optionally openafs-modules-dkms)...
	So far I haven't seen a canonical recommendation other than 
	module-assistant for packaging kernel modules in Debian and given that
	the intention is to add lirc-modules-source to linux-modules-extra-2.6, 
	this switch would be detrimental to that goal (which also requires to 
	rename lirc-module-source to lirc-source for technical reasons).
	This needs further discussion with the other pkg-lirc team members, but
	the most I might see here, would be an option like openafs-modules-dkms,
	which offers both ways in separate binary source packages.

(on a very personal side note, I do not consider dkms a viable method to 
 ship kernel modules in Debian, as dpkg knows nothing about it, the 
 actually built modules are not transferable and, even worse, dkms builds
 as root without ever asking the user about it. I for one was pretty angry
 to get surprised by drbd8-source suddenly starting to compile on my 
 system, while I'm very cautious not to risk its integrity by doing 
 "unsafe" procedures as root - and there've been enough stories of bad 
 Makefiles replacing /dev/null with a regular file and similar unwanted 
 side effects. That said, dkms' biggest assets of semi-automatically 
 adapting to new kernels could be trivially ported to plain 
 module-assistant:
 - Vcs-Svn: svn://svn.berlios.de/fullstory/dmakms/trunk
 - Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/dmakms/trunk/
 - http://lists.debian.org/debian-devel/2008/10/msg00876.html
 but again, this is my very personal opinion)

[...]
> > [PATCH 7/8] Source lsb init functions in init script
> >        svn r354, additionally adding a dependency on lsb-base
> 
> Great thanks.  I'll merge your guy's accepted versions into Ubuntu.

Thank you.

> > [PATCH 8/8] Add udev support to lirc and init script
> >        not yet applied, it depends on lirc >= 0.8.4 and further changes
> 
> OK.

I'll look into this as soon as lirc 0.8.3-4 has hit testing/ squeeze, about
5 days with urgency=medium. I'm not sure yet if 0.8.5 or 0.8.6-pre1 are the
likely target - both will need patching. 0.8.5 for kernel >= 2.6.31, 
0.8.6-pre1 to support kernel << 2.6.31.

> > > Having just merged 0.8.5 in Ubuntu and realizing how much of a headache
> > it
> > > was, things need to improve :)
> >
> > This is unfortunately true, especially the debconf handling is an utter
> > mess and needs serious changing and other areas of the packaging aren't in
> > much better shape yet. Unfortunately the kernel modules aren't very likely
> > to go mainline anytime soon either...
> >
> Still got a whole lot of delta on the Ubuntu package, so I'll try to keep
> splitting it up and sending bits in.  I was reluctant to keep doing it
> previously until I got some reception by you guys.

Thank you, I really appreciate your efforts and again sorry about my 
late response to your last patch series.

> Once we're on a common set of code/packaging, it might be a good idea to
> store the Ubuntu branch on debian svn.  I've seen lots of success with this
> in the past with the X team.

Once we have a hal aware lirc version in svn, this is likely to be 
relatively easy to accomplish. DKMS might be a little problem, but can 
probably be worked around in the packaging.

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20090807/2f3c08a1/attachment.pgp>


More information about the Pkg-lirc-maint mailing list