Bug#806815: pkg-lirc team seems unmaintained
Hi all, sorry for the long delay.
Some new points for Alec (added him in the loop, and also the RFS bug
@Alec, please look at the review below, it is really complete, and report back when you have addressed the points.
@Alexander, can you please make Stefan admin of pkg-lirc?
this way Stefan will make the final decision about accepting/rejecting new members according to the quality of the new
lirc packages.
(EDIT: he is already an admin, thanks a lot!)
@Stefan, would you please help and review the package on mentors (after the points below are fixed?)
I can sponsor the package, but I'll leave to you any final decision about this sponsoring.
@Alec, I can follow up on libirman if needed, just ask me, I'll wait for objections there :)
thanks a lot to you all,
have a nice new year!
Gianfranco
Il Lunedì 21 Dicembre 2015 7:19, Stefan Lippers-Hollmann <s.l-h@gmx.de> ha scritto:
Hi
[ it's late and I'll be on the road again for the next couple of days
before christmas, so I might miss some finer details of this mail,
although it already got longer than I hoped ]
On 2015-12-18, Gianfranco Costamagna wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Ector, Sven and Stefan,
>
> I write to you because $somebody (upstream) is doing a lot of work, to
> fix lirc and libirman packages, and to finally put them again
>
> into a good state.
I certainly didn't have a lot time since early summer (which is slowly
normalizing), but I don't quite agree that the lirc packaging would be
in a bad state - at least not from a Debian centric look (I certainly
understand that lirc upstream wants the latest and greatest and might
disagree).
We certainly are behind the current upstream version (and it looks worse
than it is, as 0.9.0~pre1 with the upstream patches included in the Debian
package is actually equivalent to the released version of 0.9.0, except
for the version bump and tiny, no-op, build-system tweaks), but the post
0.9.1 upstream changes are extremely disruptive, they are good (and many
of them have been needed), but very disruptive (liblirc{,}-client0 is
no more --> transition (sourceful uploads) of all rdeps needed, the new
plugin structure needs checking with multi-arch, .la removal (static
linking), new/ different config file format). While we need to update,
doing this in a hurry simply isn't an option - and there isn't really a
problem with the current lirc version in Debian.
At least the current version of lirc 0.9.0~pre1 builds in current
unstable, works with all kernels >= 2.6.37 (including linux-next), is
compatible with Debian's userland (unstable and experimental) and doesn't
really have any important bugs that would need quick attention.
> In order to make the packages "upgradable" he created an upgrade
> script, converting stuff from the old and Debian specific configuration
Until lirc >= 0.9.1, this config migration was a headache[0] for me
(especially as the packaging svn already did a migration to a different
config file/ ~format (/etc/default/lirc.conf) on request of the previous
upstream, Jarod Wilson, before this new /etc/lirc/lirc_options.conf was
even under consideration); fortunately this never hit the archive. But
with lirc >= 0.9.2, the library split changes are actually worse to get
sorted.
> to the new upstream and fedora configuration (this will drop the long
> old debian delta, even if it will be a little painful, or at least
> manual).
>
> I asked him to join the team, but I failed so far, because seems that
> the team is almost not active anymore.
I can't help with that, as I'm just a member of pkg-lirc and not an
admin.
> So I'm asking you permission to NMU the packages (there is still a lot
> of work to do, and they won't be ready for some time), or (better
> solution for sure)
It took me a while to find the actual thing supposed as a lirc NMU, but
I strongly advise against uploading lirc_0.9.4~alpha-1.1.dsc from
mentors[1]. As I've just found it, I can't claim to have given it a
proper review yet, nor have I tested the actual upgrade helpers, but from
a very first glance (in the order I've found it, unsorted).
- major library transition (needs a migration approval from the release
team and serious checking with liblircclient-dev's reverse
build-dependencies in Debian
- debian/control is pretty much butchered up, those things (besides
needlessly changing the package split in several areas) aren't exactly
serious - and easily fixable, but the current changes under proposal
are bad.
- weird/ useless debian/install (the source creates multiple binaries, so
this gets ignored)
- the Breaks/ Replaces logic is broken and against Debian policy.
- debian/copyright, while better (not better, just updated for post
0.9.0) than the current version in the archive, it is a regression
compared to the current state in the packaging svn (I have the changes
needed for 0.9.1 locally (svn is just bad for testing incomplete
changes), but 0.9.2+ needs further copyright auditing).
- library/ SONAME fun, uploading this would establish an instant grave RC
bug
debian/liblirc0.install: usr/lib/*/lib*.so.*
this expands to:
lrwxrwxrwx 1 20 /usr/lib/x86_64-linux-gnu/libirrecord.so.0 -> libirrecord.so.0.0.0
-rwxr-xr-x 1 110088 /usr/lib/x86_64-linux-gnu/libirrecord.so.0.0.0
lrwxrwxrwx 1 16 /usr/lib/x86_64-linux-gnu/liblirc.so.0 -> liblirc.so.0.0.0
-rwxr-xr-x 1 477552 /usr/lib/x86_64-linux-gnu/liblirc.so.0.0.0
lrwxrwxrwx 1 23 /usr/lib/x86_64-linux-gnu/liblirc_client.so.0 -> liblirc_client.so.0.3.0
-rwxr-xr-x 1 128312 /usr/lib/x86_64-linux-gnu/liblirc_client.so.0.3.0
lrwxrwxrwx 1 23 /usr/lib/x86_64-linux-gnu/liblirc_driver.so.0 -> liblirc_driver.so.0.0.0
-rwxr-xr-x 1 249240 /usr/lib/x86_64-linux-gnu/liblirc_driver.so.0.0.0
all shipped by the new liblirc0 binary package
- it's FTBS by build-depending on module-init-tools; admittedly,
module-init-tools has only been removed from unstable yesterday.
I haven't checked the source why this new version suddenly build-depends
on kmod, but this smells like another (potentially upstream-) bug
- it's FTBS due to some hardcoded (not using Debian helpers) python3
packaging changes (haven't investigated this yet)
- the maintainer scripts (rather its changes) are totally broken and
seriously break policy (RC), besides not even working in theory.
- the sysv initscript(s) has been dropped (while I sympathize, as far as
I understand the ctte decision, gratuitous removal of sysvinit support
would constitute a serious policy violation); I have spent lots of
effort on retaining and making it cooperate with the systemd units in
the packaging svn - so that part exists and works. While I'm not looking
forward into actually spending more effort on future sysv initscript
maintenance, I made sure that it works before deploying systemd units in
the packaging.
- given that this packaging is FTBS (the python stuff), I haven't
completely confirmed it yet, but I have a hunch that new installations
(non-migrated) would start irexec (and the other dæmons, lircd and
lircmd, but those don't constitute much of a problem) unconditionally
by default - which is fatal in case of irexec (serious logspam, if no
device is connected, think multiple GBs in syslog within days and lots
of useless CPU churn).
- I haven't tested this particular version, but changes in >=0.9.1 break
building on kfreebsd (and hurd); admitted kfreebsd-{amd64,i386} are
no longer release architectures (and hurd never was/ might need bigger
changes from the hurd porters to actually work, both at all and with new
upstream versions).
so at least this version is absolutely unfit for uploading anywhere,
besides that ftp-master (binary-NEW is needed for lirc >= 0.9.2) would
flat out reject it.
Now that I've found your mail on debian-mentors-request@l.d.o[2], let me
add two further notes:
- Build-Conflicts: libirman
while libirman is apparently under the pkg-lirc umbrella, it has never
actually been adopted by mjj29 or me[4]. libirman 0.45 has completely
changed the build-system (from something custom to autotools, so
definately to the better), so the existing packaging is useless and
needs to be redone (basically) from scratch. While this should be
straight forward, I have no ability to test this and would rather
prefer to drop libirman from Debian than updating it; unfortunately
lirc has (had?) no simple --disable-irman configure flag, so the
build-conflicts is the most straight-forward solution (I've made sure
that no package other than lirc still uses it, if libirman actally
gets adopted by someone using it, there's no problem with retaining
support for it <-- I'm not maintainer/ uploader for libirman, so it's
not up to me to approve a new maintainer or NMU).
lirc links against libirman-dev to gain support for irman based IR
receivers[3], these are relatively high priced serial-only devices -
which barely serve no purpose these days (hard enough to find a modern
system with a native serial port (USB serial adaptors don't work) and
even back in the days "homebrew" serial adaptors (powered by the
staging lirc_serial module) were much cheaper, more flexible and more
common). As far as lirc is concerned, if configure finds libirman-dev
present on the system, it links against it and thereby gains support
for these particular devices, if libirman-dev is not installed, lirc
continues to build fine and just doesn't support this device class.
- the Ubuntu delta... Ubuntu has done lots of custom hacks and
extensions of the -for lirc >= 0.9.1 useless- hardware.conf syntax[4],
which certainly made their clientele happy, but makes the migration
to upstream's new lirc_options.conf configuration even harder, for no
gain to Debian. This should be solved by someone who uses and cares
about Ubuntu, there is nothing relevant to Debian (most changes are
useless with these new systemd units and lirc_options.conf).
> to add him to uploaders and make the package actively maintained again.
>
>
> He is a good guy with nice packaging skills, and being upstream makes
> things so easier for everybody.
I'd certainly appreciate any help with lirc[6], but I'm not sure that
he's familiar enough with Debian packaging at the moment to do large
(of the scope he's apparently looking for) packaging changes yet.
> Please let me know if you can add him to the repository again.
>
> (ccing formorer because of the unmaintained team).
To the best of my knowledge, none of the other listed members/ admins
of the pkg-lirc packaging team has been working on lirc since at least
2007; unfortunately mjj29 has retired from Debian recently.
If you have any particular questions, I'm also reachable via IRC in
#pkg-lirc (oftc), which might be easier than writing this kind of long/
convoluted mails. Since mjj29 retired, #pkg-lirc is effectively vacated,
with only me being present (albeit from 3 different systems), but I
tend to be available in late/ very-late UTC/ CET timezones.
> Cheers!
Regards
Stefan Lippers-Hollmann
[0] not difficult, but a large state machine with lots of special
casing --> busywork
[1] http://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.9.4~alpha-1.1.dsc
[2] <[🔎] 75525845.409013.1450362165475.JavaMail.yahoo@mail.yahoo.com>
[3] http://www.intolect.com/irmandetail.htm
[4] neither of us owns these devices and they were and are
overpriced for what they offer
[5] at least in the past, I haven't revisited their recent (last 6-9
months) changes
[6] or any other package I'm involved with
Reply to: