What to do when debian testing migration stalls?

Questions about software.
User avatar
hushpuppy
Posts: 91
Joined: 02 Mar 2013 12:47

What to do when debian testing migration stalls?

Postby hushpuppy » 10 May 2014 16:42

As end-users, we know we're always going to get stuck with packages that are not up-to-date most of the time. I know there has to be a cut-off point somewhere, so waiting 4 months for a security update is normal. But, what can we do when a package gets stuck in testing migration?

Usually, there's a 10 day delay. When it get's to 80+, I begin to wonder :?

From http://packages.qa.debian.org/a/aegisub.html
todo

A new upstream version is available: 3.1.3, you should consider packaging it.
Some strings of this package need translation. You should check the l10n status report for more information.

problems

The package has not yet entered testing even though the 10-day delay is over. Check why.

testing migration

excuses:
86 days old (needed 10 days)
out of date on armel: aegisub, aegisub-dbg, aegisub-l10n (from 3.0.4-2)
aegisub (source, i386, amd64, armel, armhf, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x) has new bugs!
Updating aegisub introduces new bugs: #739385.
Not considered
What is really annoying is the latest stable version is 3.1.3, released April 6, 2014. According to Debian, it's 2.1.9-1 which is two year's old. There are two outstanding bugs: 1 related to an out-dated version, the other related to the armel platform from 6 months ago.

I have two questions:
  1. Is there anything simple that can be done to get a package unstuck?
  2. Is there a simple way to get a maintainer booted off Debian?
Ohne Musik wäre das Leben ein Irrtum (Without music, life would be a mistake) - Friedrich Nietzsche

User avatar
zerozero
Posts: 5373
Joined: 10 Feb 2013 23:37
Location: West Midlands, England
Contact:

Re: What to do when debian testing migration stalls?

Postby zerozero » 10 May 2014 23:21

a couple considerations
hushpuppy wrote:According to Debian, it's 2.1.9-1 which is two year's old.
you are referring to the information here http://packages.qa.debian.org/a/aegisub.html
stable as in debian stable (wheezy);
it lists the available versions of the package in each debian release.

===
the other related to the armel platform from 6 months ago.
https://lists.debian.org/debian-devel-a ... 00000.html
that is a problem, yes.
armel is (again) a releasable arch so if it doesn't build in armel it (most probably) won't be in debian.
hushpuppy wrote:I have two questions:
1. no, not simple :roll: closing (or helping to close) the bugs;
2. even harder :cry: see if s/he needs help; and if you can provide it.

last resource:
grab the package from sid and be happy :mrgreen:
bliss of ignorance

User avatar
hushpuppy
Posts: 91
Joined: 02 Mar 2013 12:47

Re: What to do when debian testing migration stalls?

Postby hushpuppy » 12 May 2014 18:59

zerozero wrote:a couple considerations
hushpuppy wrote:According to Debian, it's 2.1.9-1 which is two year's old.
you are referring to the information here http://packages.qa.debian.org/a/aegisub.html
stable as in debian stable (wheezy);
it lists the available versions of the package in each debian release.

===
1. no, not simple :roll: closing (or helping to close) the bugs;
2. even harder :cry: see if s/he needs help; and if you can provide it.

last resource:
grab the package from sid and be happy :mrgreen:
Hey zerozero, thank you. But I don't even have a clue what armel is. Since 3.04 - which has the armel bug - there has been 3.10, 3.11, 3.12, and 3.13. There is no indication I can see that these have even been tried.

All I see is maintainers leaving packages to rot. Sid is at 3.1.2-1; 3.1.3 was released April 6. libass4 which is basically what aegisub is a front end for, migrated to testing 2013-10-26. Look at the timeline:
[2013-10-26] libass 0.10.1-3 MIGRATED to testing (Britney)
[2013-10-19] Accepted 0.10.2-1 in experimental (low) (Alessio Treglia)
It doesn't help that they haven't noticed that libass has moved from code.google.com to github. And the latest libass is 011.2, which is libass5, which will have to be a separate package because of dependency issues.

I had similar issues last freeze, and all the dependencies were months out of date, too. I guess the only solution is to compile it from scratch.

ETA:Actually, 0.10.2 is libass5. Since libass4 and libass5 are incompatible, I believe they should be separate packages. Presumably it is up to a Debian maintainer to notice this and create/rename the libass page to libass4 (which is, after all, the name of the package), and create a new libass5 for the latest version.
Ohne Musik wäre das Leben ein Irrtum (Without music, life would be a mistake) - Friedrich Nietzsche

User avatar
MoldMe
Posts: 58
Joined: 01 May 2014 09:37

Re: What to do when debian testing migration stalls?

Postby MoldMe » 12 May 2014 23:12

Another alternative might be to track Unstable, but then that negates the stability of SolydXK.

CrunchBang -- Siduction -- SolydBang (Openbox, Tint2, most of XFCE4 removed, CrunchBang scripts)

User avatar
zerozero
Posts: 5373
Joined: 10 Feb 2013 23:37
Location: West Midlands, England
Contact:

Re: What to do when debian testing migration stalls?

Postby zerozero » 13 May 2014 09:05

hushpuppy wrote:Hey zerozero, thank you. But I don't even have a clue what armel is.

Hello :)
armel: arm is included in the releasable archs for Jessie.
how this affects you here?
any given lib has to build in all releasable archs and have no RC bugs to be included in the upcoming jessie-stable;
aegisub fails to build fron source in armel > https://bugs.debian.org/cgi-bin/bugrepo ... bug=739385
hushpuppy wrote:ETA:Actually, 0.10.2 is libass5. Since libass4 and libass5 are incompatible, I believe they should be separate packages. Presumably it is up to a Debian maintainer to notice this and create/rename the libass page to libass4 (which is, after all, the name of the package), and create a new libass5 for the latest version.
that situation is already solved (or solved-to-be :mrgreen: )
the package presently in experimental is libass5 (0.10.2-1)
https://packages.debian.org/experimental/libass5
while in jessie/sid (same version atm) is libass4
https://packages.debian.org/jessie/libass4
and, yes, it's the same package (builds from the same source)
https://packages.debian.org/search?sear ... rds=libass

===
hushpuppy wrote:I had similar issues last freeze, and all the dependencies were months out of date, too. I guess the only solution is to compile it from scratch.
compiling it might be one option, this >> http://forums.solydxk.nl/viewtopic.php?f=9&t=2769 might be another.
bliss of ignorance


Return to “Software”

Who is online

Users browsing this forum: No registered users and 13 guests