[Pkg-lirc-maint] LIRC package status/new maintainer offer

[Stefan Lippers-Hollmann]

Hi

On Friday 19 November 2010, Eric Sharkey wrote:
> On Tue, Nov 16, 2010 at 9:29 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
> > If you didn't notice yet, squeeze is in deep freeze by now - which means
> > uploading a new (vastly different) upstream version for a package with a
> > shared library used by ~40 rdepends doesn't really qualify as freeze
> > excemption.
> 
> Of course.  Squeeze will be going out with the older LIRC packages,
> but that shouldn't stop you from uploading to unstable.  If you have a
> new version ready, it should go in unstable as soon as it is ready.
> (Developer's Reference 4.6.4.1.)

You seem to interpret the definition of "freeze" and its effect on 
uploading to unstable differently than the release team and prior 
history in handling these freezes. Again, lirc ships a shared library 
with ~40 (fortunately unversioned) rdepends and breaks the ABI between 
kernel modules and userspace. Additionally lirc devices requiring 
kernel support (be it staging or ir_core) depend on kernel >= 2.6.36 
(linux-image-2.6.36-trunk-${localversion} >= 2.6.36-1~experimental.1), 
which is not present in *unstable* and - like lirc 0.9~ - will not be, 
before the freeze gets lifted. This doesn't preclude an upload to 
*experimental*, except that the package needs to be adapted to a 
current standards versions (policy) - and we're back at the debconf 
abuse, which makes the package NOT_ready, yet).

> > Looking at the package's Vcs-Svn header¹, you'll notice that trunk
> > packaging is at 0.9.0~pre1 and barely out-of-date, with the last
> > changes committed just a week ago.
> 
> Well, great, but that doesn't really do anyone much good.  Debian
> users shouldn't need to build from svn.

I am not addressing a Debian user here, but a Debian Developer who
is proposing to take over the package. lirc in unstable is not
without faults, but it does work in unstable/ testing and there are
no security bugs known at this moment - while there is a new RC bug
introduced by newer upstream versions (FTBS on kfreebsd-amd64 and 
kfreebsd-i386, which only got fixed a little over a week ago; hurd-i386
remaining FTBS, but not RC).

> > So why hasn't a new upstream version been uploaded before:
> [lots of reasons]
> 
> Ok, but these do seem like solvable problems, not something that
> should delay upgrades for years.  What I've been doing for the last

Everything is solvable, but it needs someone actually doing it. If you 
look at upstream and the package Vcs, it is even in the process of 
being solved. The pace certainly is far from perfect and help more than
appreciated, but I'm repeating myself.

> year or so (and advising other Debian users to do on the MythTV Users
> mailing list) is to pull lirc packages out of the Ubuntu repository

That is your decision, not one I would take or support, but well.

> and install them by hand with dpkg.  This is a sad condition to be in.
>  The Ubuntu packages are more up to date and seem to just work on
> Debian, but I certainly haven't tested installing them on systems
> which had lirc installed on woody.
> 
> > There have been several offers for help (and if you look at "recent"
> > bugreports, you'll notice pretty specific issue lists in my answers)
> > over the last 2 years, but none of these materialized into any kind of
> > commits or patches and the existing member list of the alioth project
> > has little overlap with reality, so please forgive me, if I'm slightly
> > sceptical; but help is definately appreciated at any layer.
> 
> When I wrote to you the first time offering to help, I never received
> a response.  That was over a year ago (Oct 29, 2009).  If you want to

I tend to ignore private mails not CC'ed to BTS or public mailing 
lists, which contain little more than the question when's the next 
upload going to happen and are phrased in a 'motivating' way.

> stay as maintainer for LIRC that's certainly fine by me, but there
> needs to be some real progress.

I care more about lirc being functional and improving, than my name 
being associated to it. Given that so far lirc has been neglected for a
long time, I'm trying to fill a void - at the pace I can provide - and 
welcome any further help.

> If you want help testing, start uploading packages into
> unstable/experimental and I'll test them.  If you need more testers
> with a wider variety of hardware, I'll find them.  (The MythTV users
> mailing list would be a good place to solicit volunteers.)

Testing and improving the handling of hotpluggable devices is certainly
needed, but only once the packaging is in a shape to be uploaded (which
means as soon as the debconf abuse, see below, is resolved).

> Let me know what you would like me to do.  Your "What can (and needs)
> to be done now" list is good, but I'd rather get more explicit
> direction.

...and I thought my list was pretty specific, however the most 
problematic issue is:

E: lirc: no-debconf-config
N:
N:   The package contains a "templates" file in its control area but has no
N:   corresponding "config" script. This is occasionally OK, but is usually
N:   an error.
N:   
N:   Severity: important, Certainty: possible
N:
"s/\(Certainty\:[ \t]\).*/\1 painfully true and a real problem/"

Which is one of the reasons behind "Standards-Version: 3.7.2" - and 
even that is "optimistic", given that the debconf handling is not only 
violating policy, but is also plain broken since sarge.

> At the moment I have an iMon Ultrabay, an HD Home Run, and an MCEUSB
> device that I can use for testing.

Fine, mceusb is /the/ device class that will require most /manual/ 
changes from its users - as being one of the first devices ported over 
to ir_core, which changes configuration and general mantra (in 
particular when 'unexpected' remotes (custom encoding) join the 
stage) completely.

Regards
	Stefan Lippers-Hollmann