Hi On Friday 18 September 2009, Jeremy Yoder wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.8.6-0ubuntu1~ppa9 of my > package "lirc".
Errrm, last I knew "lirc" was still maintained by the lirc maintainer team
<pkg-lirc-ma...@lists.alioth.debian.org>, of which I was sure to be a
member. Neither do I see any mail from you on the BTS, nor the
afforementioned packaging mailing list (nor #pkg-lirc for that matter).
That said, the last lirc maintainer upload happened just 5 weeks ago and
couldn't migrate to testing until this very week (buildd downtime for
mipsel).
As member of the lirc maintainer team for Debian, I strongly reject this
hijacking attempt.
> This is a MAJOR update from 0.8.4/5 (both in LIRC itself and in the
> debian/* files). I'm aware that it's still an Ubuntu package and I'm
Yes, lirc >= 0.8.4 is a major update, requiring a careful migration path
from the historic packaging to a hal based device detection (for a subset
of hotpluggable devices) and special caution in regards to the required
changes to its inherited debconf (mis-)handling.
> not sure what I need to change to fix that... Pointer/tips welcome!
> I'd be happy to make any changes and re-upload if necessary.
>
> It builds these binary packages:
> liblircclient-dev - infra-red remote control support - client library
> development fil
> liblircclient0 - infra-red remote control support - client library
> lirc - infra-red remote control support
> lirc-modules-source - infra-red remote control support - kernel modules
This silently switches lirc-modules-source from module-assistant, Debian's
canonical method of distributing out-of-tree modules for the Linux kernel,
to DKMS, which would require lots of discussion before even thinking about
it as well.
> lirc-x - infra-red remote control support - X utilities
>
> The package appears to be lintian clean.
It's everything but lintian clean (the current package in Debian is
neither, due to historicial issues, but to change this is part of our
current packaging efforts) and even adds new lintian issues:
W: lirc-modules-source: executable-not-elf-or-script
./usr/src/lirc-0.8.6/drivers/lirc_streamzap/lirc_streamzap.c
W: lirc-modules-source: command-with-path-in-maintainer-script postrm:9
/usr/bin/ucf
E: lirc-modules-source: depends-on-obsolete-package suggests: kernel-source
I: lirc: hyphen-used-as-minus-sign usr/share/man/man8/lircd.8.gz:123
W: lirc: postinst-uses-db-input
Furthermore it ignores recent changes in Debian's packaging and would
(re-)introduce a FTBS on kFreeBSD-{amd64,i386} (#540742).
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/l/lirc
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.8.6-0ubuntu1~ppa9.dsc
>
> I would be glad if someone uploaded this package for me.
NACK.
Regards
Stefan Lippers-Hollmann
Post scriptum: I don't see you in Ubuntu's packaging changelog, with whose
maintainer we are in contact, either, therefore I'd suggest
you to try contacting respective Debian and/ or Ubuntu
maintainers first, before trying to hijack a package. Help
with maintaining lirc is always appreciated, but it's not
done with slapping in a new upstream tarball and ignoring
the migration path.
signature.asc
Description: This is a digitally signed message part.
