[RC-Bug-A-Day] Day 15
For today, a debian/copyright bug in tct was fixed.
For today, a debian/copyright bug in tct was fixed.
I sponsored (ugh!) a new ia32-libs today, which means we now are 4 RC down.
Note: I really hate this package.
For today: 469552 was downgraded for probably be a user problem and ktranslator was removed due to 469552. I know that the latter wasn't RC for very long (a couple of days at least) but the maintainer should have detect the criticity of the problem himself (the package is mostly unusable because he can't find some of its plugins or sth like that) and is totally unresponsive.
I'm pleased to announce that we went under the 400 bugs in lenny (according to turmzimmer) and around 250 bugs that are present in both lenny and sid (which is the "real" amount of bugs to fix).
Today's paid work ate all my time, so my RC/RG bug squashing was only made of uploading other's work.
Thanks again to Kartik and Kumar.
Today saw the removal (from testing) of:
All in all, that's 5 RC bugs that aren't in lenny anymore.
Note: I've been pretty busy today, I've seen mails to ask NMU sponsoring for RC/RG bugs, I will have a look, don't worry.
For today, 464893 was downgraded partly because gksu works fine for me for a long time, hence critical was completely overestimated, and partly because no matter how hard I try to reproduce the bug I can't. If you do, please follow up on the bug log.
Also, a new sponsored NMU for gnomesword (bug#461959), thanks to Kumar again :)
Today's work:
Today, after Cyril Brulebois, and Sylvestre Ledru, Kumar Appaiah contacted me with ready NMUs that I sponsored right away:
About my work:
Though, python-central had the brilliant idea to generate ~35 FTBFSes, so this week of RC-Bug-A-Day balance isn't brilliant:

On the other hand, we're almost under 100 g++-4.3 FTBFS, wich is a third of what it was 10 days ago, good job people !
The interface was subtly broken for quite some time, because of a broken w-b synchronization script. It's fixed again, so those who stopped using it because it lagged for months can use it again, and know that I'm the one to prod if it's broken.
Also, a nice unknown feature is that if you want the state of $package in experimental, the following alias DWYM[1]:
http://experimental.debian.net/$package
[1] It's not a new feature, it's here for a long time, but few people actually know about it
While working on an stlport4.6 still not done ldbl128 transition (430305) I got bitten by 434691.
Of course, as stlport4.6 is a dead beast, only used by Debian's OOo (upstream uses an internal 4.5 tree), no patch exists yet. And Ubuntu didn't noticed the breakage yet either. So I'm with this on my hands:
g++-4.1 builds fine:
artemis# g++-4.1 -fdiagnostics-show-option -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o
g++-4.2 and g++-4.3 don't:
artemis# g++-4.2 -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o complex.cpp:27: error: 'float _STL::abs(const _STL::complex<float>&)' is not declared in '_STL' complex.cpp:32: error: 'double _STL::abs(const _STL::complex<double>&)' is not declared in '_STL' complex.cpp:39: error: 'long double _STL::abs(const _STL::complex<long double>&)' is not declared in '_STL'
artemis# g++-4.3 -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC complex.cpp -c -o ../lib/obj/GCC/ReleaseD/complex.o complex.cpp:27: error: 'float _STL::abs(const _STL::complex<float>&)' is not declared in '_STL' complex.cpp:32: error: 'double _STL::abs(const _STL::complex<double>&)' is not declared in '_STL' complex.cpp:39: error: 'long double _STL::abs(const _STL::complex<long double>&)' is not declared in '_STL'
Help for this particular problem would be much appreciated, because I see absolutely nothing wrong in that code (with my limited C++ skills I shall say).
EDIT: seems like I found the issue with a lot of luck, some using .... crack was causing the issue. So all in all, I fixed two RC bugs today even if I have to delay the NMU because of OOo-related transitions for a while.
I stupidly fell asleep last night, so there was no Day 6 yesterday.
Today, I sponsored 2 NMUs prepared by Sylvestre Ledru for two g++-4.3 FTBFS. If you're not a DD and that you have NMU ready for bugs like the g++-4.3 FTBFSes, I'll gladly sponsor them. I'll just need that you put the dsc files (with the corresponding diff.gz and also orig.tar.gz) available e.g. on Debian mentors.
Today, I cheated a bit, and used my Release Assistant super powers, and removed from testing 2 packages with long standing RC bugs and no activity from the maintainers:
See my hint file:
#20080319 # 467096 remove traverso/0.42.0-1 # 243363 remove xcruise/0.30-8
edit: twinkle removal was a bit hasty, I totally missed that the bug wasn't RC from the beginning. And as a second thought I'm not either sure it's really RC.
Nothing really exciting today, though 1 RC fixed, and a g++-4.3 FTBFS at the same time.
Since there aren't only serious grave and critical bugs we have to fix for the release, the RM Team spontaneously decided to make a front attack to the g++-4.3 FTBFSes.
All in all we did probably more than 110 to 120 NMU to fix g++-4.3 FTBFS bugs. Our champion is definitely Marc Brockschmidt who uploaded 50 packages. I NMUed 22, and also did one QA upload. Add to that 5 sponsored NMUs for Cyril Brulebois, and one for Arthur Loiret who happens to be my NM, and fixed one of those bugs for his T&S. There are still twice as many to fix, those are really easy bugs to deal with, just give it a try !
I'd like to thank Cyril Brulebois for his awesome work on the g++-4.3 release goal. A shame that he's still elmo-ed, as he wrote more than 150 patches, and could have uploaded them himself if not still waiting for his account. Shame on us.
Simon, really, get a grip:
┌─(9:56)──<~/dev/libc/glibc-package 2.7>── └[artemis] du debian/patches 2,9M debian/patches
Let's have a look:
And so on. OTOH I don't think we are really forking the glibc, it's "just" that upstream doesn't care about many of the problem we care about (e.g. "embedded crap[1]" like mips or arm).
Go ask xorg packaging team, go ask moizilla packaging team, go ask OOo.org people go ask any team with a complex enough upstream (especially the ones we have to patch around a lot to make them use system libraries instead of internal copies) before asserting anything like "integrating quilt is a step in the wrong direction because it carves into stone that we are forking packages".
[1] upstreams wording
Today's bugs:
debian/changelog is not RC (or we have kind of a problem since there are quite some packages with this issue afaict).debian/copyright using the machine parseable proposal to please our DPL as it's one of his packages after all :P… keeps the release away.
That's why, following Sesse last year, I started to work on (at least), one RC bug a day.
If I do that alone, and that no new RC bugs are opened[1], we will release in 460 days; now if 10 DD do the same, it becomes 46…
FWIW, today, I made Luk (Claes) reassign and downgrade #470453 and sent a DELAYED/2 NMU for #470002. And you, what did you do for the release ?
[1] har har har