Re: binNMU request for mysql-ruby
On 16/01/07 at 23:22 -0800, Steve Langasek wrote: On Wed, Jan 10, 2007 at 03:40:24PM +0100, Lucas Nussbaum wrote: A binNMU of [mysql-ruby] is needed, so that it picks up new constants in libmysqlclient15-dev. i386 is affected for sure - I'm not sure about other archs: since the i386 package was built by the maintainer, it might be the only one affected. Rebuilding it on all archs would be safer... Sorry, do you have a reference for what problem this is supposed to fix? New constants doesn't tell me what's wrong with the current version, nor whether this applies to the testing or unstable versions or both. See #407250. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#407132: hal: Circumvents invoke-rc.d (and thus policy-rc.d) in postinst
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 407132 serious thanks Sjoerd Simons wrote: On Tue, Jan 16, 2007 at 01:29:12PM +0100, Jonas Smedegaard wrote: I can only interpret the dbus subscript as indirectly being part of the `/etc/init.d/*' initscripts. Maybe, but is is _not_ managed by sysvinit but by the dbus init scripts, thus it can't use invoke-rc.d. While i agree it's not as nice it coulde be, i don't see a real solution untill we get an init system that properly supports events The dbus init scripts _are_ subscripts of sysvinit scripts. Policy describes how system daemons should be started only through the use of invoke-rc.d, and the dbus subscripts are in fact started that way. hal restarts one of those subscripts directly, which causes problems for systems relying on policy-rc.d. I agree that it is problematic, and I do not claim to have a solution. But that does not change the severity of this bug. As I wrote, I believe it makes sense to ignore this bug for the upcoming release. But it is wrong to lower severity! CC'ed debian-release to have a third opinion. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrfMHn7DbMsAkQLgRAs97AJ4qxDmsaGB6wHbfblBNC22lo9dPDwCfVvk+ /oTsJKIz3lcLR9vikK5oPwQ= =o5fZ -END PGP SIGNATURE-
Re: Accepted vlc 0.8.6-svn20061012.debian-3 (source i386 all)
Hi Sam,
On Thu, Jan 11, 2007 at 10:32:10PM +, Sam Hocevar wrote:
vlc (0.8.6-svn20061012.debian-3) testing-proposed-updates; urgency=high
Reviewing this now, I have a few problems with parts of the diff that I'd
like your help clearing up.
- 020_notify.diff includes a patch to prepend DATA_PATH to
/usr/share/pixmaps/vlc.png. Why? This isn't documented in the
changelog, and doesn't make any sense to me anyway.
- patch-documentation-0.8.6debian-0.8.6a.diff contains:
+@@ -150,7 +150,13 @@
+ char *psz_server = 0;
+ int i_result;
+
+-if( !p_access-b_force ) return VLC_EGENERIC;
++if( !p_access-psz_access || (
++strncmp( p_access-psz_access, rtsp, 4 )
++strncmp( p_access-psz_access, pnm, 3 )
++strncmp( p_access-psz_access, realrtsp, 8 ) ))
++{
++return VLC_EGENERIC;
++}
+
+ p_access-pf_read = NULL;
+ p_access-pf_block = BlockRead;
How is this a documentation fix?
- 000_bootstrap.diff seems to be enabling maintainer mode by default. Why
is this a) appropriate, and b) necessary? Are you certain that there are
no possibilities of timestamp skew here that would cause a FTBFS on
autobuilders when autofoo are not installed? (The answer here appears to
depend on the order in which the patches are applied, which I haven't
analyzed.)
- patch-missing-locks-0.8.6debian-0.8.6a.diff: is playlist_LockDelete() a
superset of playlist_Delete()?
- patch-sanitise-javascript-0.8.6debian-0.8.6a.diff: why is it /wrong/ to
escape \ characters here?
- patch-badly-initialised-data-0.8.6debian-0.8.6a.diff:
+@@ -450,8 +450,8 @@ static void default_clut_init( decoder_t
+ }
+
+ p_sys-default_clut.c_4b[i].Y = RGB_TO_Y(R,G,B);
+-p_sys-default_clut.c_4b[i].Cr = RGB_TO_U(R,G,B);
+-p_sys-default_clut.c_4b[i].Cb = RGB_TO_V(R,G,B);
++p_sys-default_clut.c_4b[i].Cr = RGB_TO_V(R,G,B);
++p_sys-default_clut.c_4b[i].Cb = RGB_TO_U(R,G,B);
+ p_sys-default_clut.c_4b[i].T = T;
+ }
+
this reverses the initialization of the .Cr and .Cb elements, and in fact,
disagrees with an immediately preceeding section of the same patch. Can
you explain? (It does agree with an immediately /following/ section of
the patch, so perhaps it's the first section that's wrong?)
The debdiff also includes changes specific to architectures which aren't
releasing with etch, and are apparently not planning to do their own
rebuilds of etch, and even includes added patches from unstable that have
only been disabled in the patch sequence file. This makes for a very
time-consuming diff to review, and certainly leaves me less confident that I
haven't overlooked any regressions. I would be much more comfortable
letting this straight into testing if this weren't the case.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock kqemu, second try
Hi Daniel, On Wed, Jan 10, 2007 at 09:18:06PM +0100, Daniel Baumann wrote: Daniel Baumann wrote: sceduled for the batch upload tomorrow. with some delay, but uploaded now. Could you please explain this part of the diff? --- kqemu-1.3.0~pre9/debian/control.modules.in +++ kqemu-1.3.0~pre9/debian/control.modules.in @@ -7,7 +7,7 @@ Package: kqemu-modules-_KVERS_ Architecture: any -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common Recommends: qemu (= 0.8.1) Provides: kqemu-modules Description: kqemu modules for Linux (kernel _KVERS_). Also, + + mkdir debian/kqemu-common/dev + mknod debian/kqemu-common/dev/kqemu c 250 0 + chmod 0666 debian/kqemu-common/dev/kqemu + this is a policy violation. You're not allowed to ship device nodes in a package. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock smartlist 3.15-19
smartlist (3.15-19) unstable; urgency=medium * Updated README.exim for exim4. Renamed to README.exim4. Closes: #375554. * Updated QuickStart so that it refers to README.exim4. * Do not chown var/list/.procmailrc in debian/fakeroot-workaround, as it is a symlink and we don't want to change the owner of the pointed file. -- Santiago Vila [EMAIL PROTECTED] Thu, 4 Jan 2007 15:39:06 +0100 Items 1 and 2 are purely documentation updates. Item 3 is required to fix an unreported binary package does not match source package bug, as chown has changed behaviour since the last smartlist upload. [ i.e. chown on a now changes b if a is a symlink to b ] Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock qpsmtpd 0.32-5
Devin Carraway [EMAIL PROTECTED] writes: qpsmtpd_0.32-5 adds a patch to fix Bug#389025, in which the use of multiple paths to find qpsmtpd's plugins caused breakage. Unblocked. Marc -- Fachbegriffe der Informatik - Einfach erklärt 144: Maxmimale Entfernung zweier Hubs 12800 km. (Roger Schwendker) pgpDjIAbLxjlC.pgp Description: PGP signature
Re: Please allow squid-2.6.5-4 fixes security bug #407202
Luigi Gangitano [EMAIL PROTECTED] writes: please allow the just uplaoded squid-2.6.5-4. Only changes are two upstream patches for security issues. Bug #407202. Ref. CVE-2007-0248. Unblocked. Marc -- Fachbegriffe der Informatik - Einfach erklärt 35: Hacker Randal Schwartz (nach Intel) pgp28KoCjsBV8.pgp Description: PGP signature
Re: Please unblock smartlist 3.15-19
Santiago Vila [EMAIL PROTECTED] writes: smartlist (3.15-19) unstable; urgency=medium Woah, still not dead. Unblocked. Marc -- BOFH #43: boss forgot system password pgpoiXlFElcjE.pgp Description: PGP signature
Re: Please unblock kqemu, second try
On Wed, Jan 17, 2007 at 12:25:23PM +0100, Daniel Baumann wrote: Steve Langasek wrote: -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common this is like all the newer modules are declaring their depends to the kernel. it has no effect as linux-image is pulled in anyway by this. This AFAIK only applies to kernels which are built by the kernel team. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock kqemu, second try
Bastian Blank [EMAIL PROTECTED] writes: On Wed, Jan 17, 2007 at 12:25:23PM +0100, Daniel Baumann wrote: Steve Langasek wrote: -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common this is like all the newer modules are declaring their depends to the kernel. it has no effect as linux-image is pulled in anyway by this. This AFAIK only applies to kernels which are built by the kernel team. Well it looks right to me since it would allow the user to install the module without the linux-image on a domU, for example. Am I missing something? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock kqemu, second try
On Wed, Jan 17, 2007 at 12:34:52PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: On Wed, Jan 17, 2007 at 12:25:23PM +0100, Daniel Baumann wrote: Steve Langasek wrote: -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common this is like all the newer modules are declaring their depends to the kernel. it has no effect as linux-image is pulled in anyway by this. This AFAIK only applies to kernels which are built by the kernel team. Well it looks right to me since it would allow the user to install the module without the linux-image on a domU, for example. Am I missing something? Yes. This prevents users who install a kernel with 'make menuconfig make ad infinitum ...' from using this package at all. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock kqemu, second try
Roberto C. Sanchez [EMAIL PROTECTED] writes: On Wed, Jan 17, 2007 at 12:34:52PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: On Wed, Jan 17, 2007 at 12:25:23PM +0100, Daniel Baumann wrote: Steve Langasek wrote: -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common this is like all the newer modules are declaring their depends to the kernel. it has no effect as linux-image is pulled in anyway by this. This AFAIK only applies to kernels which are built by the kernel team. Well it looks right to me since it would allow the user to install the module without the linux-image on a domU, for example. Am I missing something? Yes. This prevents users who install a kernel with 'make menuconfig make ad infinitum ...' from using this package at all. But in this case the users would use module-assistant or compile the package by hand using kqemu-source and not the built module. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock kqemu, second try
On Wed, Jan 17, 2007 at 01:34:44PM -0200, Otavio Salvador wrote: But in this case the users would use module-assistant or compile the package by hand using kqemu-source and not the built module. My mistake. I didn't see that the subject only concerned kqemu. Thanks for setting me straight. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
why is alpha a release candidate?
So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. Well, the one-and-only alpha buildd has been down for apparently ten days and does not respond to ping, and I don't recall seeing anything from the alpha team on debian-release or debian-devel. Please correct me if this is inaccurate. It seems to me that, in a freeze, we should be ruthless about such a situation. We have in the past had serious problems with archs that have suddenly-bogus buildds in the freeze, and this requirement of buildd redundancy was created specifically to avoid this problem. Now we are being bitten by it. Alpha needs to either, it seems to me, get back up to 95% right away, and say why the situation was allowed to coast along for nearly two weeks, or be dropped as a release arch. Or, we could just decide that the release criteria don't really matter, even when the very situations they were designed to prevent come up. Thomas signature.asc Description: This is a digitally signed message part
please allow gnucash-2.0.2-3 into testing
I've uploaded 2.0.2-3 to fix the open release critical bug for gnucash and do minor cleanup after the incorrect NMU of last month. Please allow it into testing once the regular five-day delay is over, and please do not force it to wait for the absent alpha autobuilder to catch up. Thomas signature.asc Description: This is a digitally signed message part
Re: why is alpha a release candidate?
Thomas Bushnell BSG wrote: So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. Well, the one-and-only alpha buildd has been down for apparently ten days and does not respond to ping, and I don't recall seeing anything from the alpha team on debian-release or debian-devel. Please correct me if this is inaccurate. The machine is currently being moved to a new location, fwiw. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why is alpha a release candidate?
Thomas Bushnell BSG a écrit : So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. The release critera also require a developer-available machine. This is not the case for the alpha architecture. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please remove drbd8 from testing
Dear release team, the drbd8 package is a prerelease version of the upcoming drbd 0.8 release. so it doesn't belong into testing. I added an RC bug to the package to make sure it stays out of testing. thanks philipp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please consider twisted and twisted-words for testing
please consider twisted and twisted-words for testing: twisted (2.4.0-3) unstable; urgency=medium * twisted/python/versions.py: Update to work with subversion 1.4. Closes: #405141. * python-twisted-core: Don't suggest python-wxgtk2.4 anymore. Closes: #391994. twisted-words (0.4.0-2) unstable; urgency=medium * Fix command in menu file (/usr/bin/im). Closes: #368491. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please add drbd0.7 to testing again
Hello release team, My AM just upload a fixed version of drbd0.7, which contains contains a fix for RC bug #405529. The bug was fixed a while ago, but my AM was too busy with other things ;-) thanks philipp hug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I upload sqlalchemy 0.3.3-2 to unstable? (will you unblock it?)
Marc 'HE' Brockschmidt wrote: Piotr Ozarowski [EMAIL PROTECTED] writes: reported? No, but python-turbogears users who are using SQLAlchemy (SQLObject is default) and MySQL will need it. So this will only affect users of a special, non-default flavour? Let me cite Michael Bayer - upstream author talking about 0.3.2: | Of the biggest importance is a connection pool fix where the close () method | on ConnectionFairy (a humorously ephemeral Proxy) that returns its | connection to the pool removes its own reference to the connection when its | completed (0.2 was fine with this, somehow it got whacked in 0.3); otherwise, | when its __del__ method is called it tries to close again, issuing a second | rollback on the connection. when that connection is already at work in | another thread, well, you can figure out what can happen there. and I'm pretty sure that TurboGears users will use threads with MySQL even with SQLObject set as default, see Gustavo's mail Michael Bayer: | If you're on the 0.3 series in any production systems, this release should be | mandatory. I can report an important bug to BTS, isolate the fix and try to upload fixed 0.3.1-3, but almost every line from upstream changelog contains fix word, so I would be very happy if I could upload 0.3.3. As an addition let me say that there will be no problems with upgrade from Sarge (SA was introduced in Etch) and that it is really well tested (no regression - tested with unit tests and by lots of users). -- :wq! pgp76m0cJiDu5.pgp Description: PGP signature
Please unblock mkvmlinuz 30
Hi, I made an upload of mkvmlinuz which adds a translation, fixes a silent failure, and fixes an arithmetic syntax error. To my mind, the other changes are pretty harmless... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Please unblock tenshi 0.4-1.1
(the first version of this mail was inadvertently sent as a followup to one of my other unblock mails, and thus may have esapced the very clever eye of our release managers.or maybe there's just another reason which I ignore. Anyway, just in case, I send this unblock request again. Apologies if the first oen was indeed noticed but just being processed) The 0.4-1.1 NMU of tenshi was initially intended to fix debconf l10n issues. Then I discovered that the package is using debconf to display a blatantly abusive note. Then I discovered an RC issue. And finally, I noticed a lintian warning about the provided init script not having a LSB header (something very likely to become a lenny release goal) As a consequence, I ended up with the following changelog: tenshi (0.4-1.1) unstable; urgency=low * Non-maintainer upload to fix an RC bug and longstanding debconf abuse * Include the includes-active in directories created under /etc/tenshi * Remove the debconf note. Closes: #357596 This also removes the need for translations. Sorry to the Czech translator. Closes: #360284 This also fixes the incorrect debconf dependency that was blocking the cdebconf transition. * Lintian fix: - Add a LSB header to the init script Please notive that I inadvertently forgot closing the RC bug report (#407105) which I will do manually (with version tracking). Could you please unblock all this? -- -- signature.asc Description: Digital signature
Re: why is alpha a release candidate?
On Wed, 2007-01-17 at 18:36 +0100, Martin Schulze wrote: Thomas Bushnell BSG wrote: So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. Well, the one-and-only alpha buildd has been down for apparently ten days and does not respond to ping, and I don't recall seeing anything from the alpha team on debian-release or debian-devel. Please correct me if this is inaccurate. The machine is currently being moved to a new location, fwiw. That's fascinating. It was not mentioned on either mailing list I described, and it still doesn't affect the point. It's not reasonable for the release to be inconvenienced because the machine is being moved; that kind of thing is *exactly why* we have the requirement to have more than one buildd. If the requirement is going to be ignored, even in the case where it is in the middle of things, then let's not have the requirement at all. Thomas signature.asc Description: This is a digitally signed message part
Re: why is alpha a release candidate?
On Wed, Jan 17, 2007 at 06:38:05PM +0100, Aurelien Jarno wrote: Thomas Bushnell BSG a écrit : So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. The release critera also require a developer-available machine. This is not the case for the alpha architecture. Somebody ping on Paul Cupis: I gave him two dual Alpha 833 rack mount servers for use. It's quite possible he's not using one. Andy -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please consider python2.4 and python2.4-doc for testing
please consider python2.4 and python2.4-doc currently in unstable for testing: python2.4 (2.4.4-2) unstable; urgency=medium * Cleanup build-conflicts. Closes: #394512. * Match the smtplib documentation with the code and the docstring. Closes: #333150. * idle: Honor the Cancel action in the save dialog. Closes: #299092. * Recognize other browsers: www-browser, x-www-browser, firefox, iceweasel, iceape. Closes: #330223. * Fix some unsafe 64-bit mmap methods, backport from 2.5. Closes: #340661. * python2.4-dev: Add a python2.4-config script (backport from 2.5). python2.4-doc (2.4.4-2) unstable; urgency=medium * Match the smtplib documentation with the code and the docstring. Closes: #333150. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock kqemu, second try
On Wed, Jan 17, 2007 at 12:34:52PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: On Wed, Jan 17, 2007 at 12:25:23PM +0100, Daniel Baumann wrote: Steve Langasek wrote: -Depends: linux-image-_KVERS_ +Depends: linux-modules-_KVERS_, kqemu-common this is like all the newer modules are declaring their depends to the kernel. it has no effect as linux-image is pulled in anyway by this. This AFAIK only applies to kernels which are built by the kernel team. Well it looks right to me since it would allow the user to install the module without the linux-image on a domU, for example. Am I missing something? Er, and how is that, when linux-image-* is the only package in the archive providing linux-modules-*? I simply have no idea what the linux-modules-* virtual package is supposed to mean. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please consider dak and nautilus-python for testing
two NMUs, the packages are currently not in testing; no RC reports for unstable: dak (1.0-8.2) unstable; urgency=medium * NMU * Remove build dependency on versioned python version with an unversioned. Closes: #403357. * Convert to updated python policy, using python-central. Closes: #380800. nautilus-python (0.4.3-1.1) unstable; urgency=low * NMU. * Upload to unstable. * Drop dependency on python2.3, lowering severity of #373465. ^^^ the package was just rebuilt, not converted to the updated python policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(Bad) results of running piuparts over the whole archive
Hi, First of all, I am sorry to come up with this so late in the release process. While it is very easy for me to generate data (it only took a few hours to generate this data using ~30 nodes from the Grid'5000 platform), I am clearly not able to process it as fast as it is generated. I really think we should work on this, and create a small team of people interested in analyzing such data, so I stop being the bottleneck... I ran piuparts two times, both times ignoring all failed tests other than failed commands (installations / removals). The first time, I only installed the packages, so a successful test means that the package was installed successfully. The second time, I did a normal piuparts run, installing and removing the pakage. Numbers: 173 packages failed to install (failed during run 1). This includes a lot of false positives. Documenting those would be great, but is a tedious task. Also, I had a package (piuparts-hangers) installed to avoid installing packages that are known to cause piuparts to hang. 332 packages installed OK, but failed to remove. I believe that the number of false positives amongst those is very low (probably under 20%). Of course, it doesn't mean 332 possible RC bugs, since some packages failed because of others (e.g bacula failed because bacula-common). Popular reasons include: 149 /usr/share/debconf/confmodule: No such file or directory 44 (userdel|deluser): command not found 17 update-inetd: command not found 5 ucf: command not found 4 (groupdel|delgroup): command not found All logs are available on http://people.debian.org/~lucas/logs/2007/01/16/ What do we do with that ? In another piuparts campaign at the end of last year, I filed quite a lot of bugs, but voluntarily ignored missing depends on packages of priority = important, and missing depends on ucf (which is prio:optional), just to keep the number of failures manageable. Should we concentrate on finding important failures (packages with missing depends|pre-depends on packages with priority important), or do we want to consider all those bugs RC ? Depending on the outcome, I could generate data specific to what we want to find, to avoid some/most of the log reviewing. Also, to avoid duplicating efforts, please don't start randomly filing bugs about this. If we decide on processing those failures now, we should figure out a way to do that efficiently (maybe a wiki page on wiki.d.o ?). Lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock xlockmore 1:5.22-1.2
xlock can crash when used in combination with certain smartcard-reading PAM modules, libpam-p11 and libpam-opie. Such a crash will result in leaving the screen unlocked without having been authenticated: #318123 and #399003. Version -1.2 prohibits these crashes from occuring by having added a conflict. This is not the best fix possible, but is IMHO superior to not having xlockmore available at all. The maintainer agrees with this workaround, and also believes the current version would be suitable for release. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock chillispot 1.0-3.1
This NMU for that package, which I uploaded a few seconds ago, fixes all the pending debconf l10n bugs. I guess it therefore qualifies for being unblocked. -- signature.asc Description: Digital signature
Please unblock vrms 1.12-0.1
This NMU for that package, which I uploaded a few seconds ago, fixes all the pending debconf l10n bugs. I guess it therefore qualifies for being unblocked. signature.asc Description: Digital signature
Re: why is alpha a release candidate?
On Wed, Jan 17, 2007 at 09:21:07AM -0800, Thomas Bushnell BSG wrote: So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. Yes, it gets marked in yellow because this requirement has in practice been waived as a hard requirement for release qualification, replaced by the softer principle of if you don't have buildd redundancy and the buildd goes down and this begins to negatively affect the release process, we reserve the right to drop your arch from the release. So far, I don't believe that this particular outage has substantially hindered the release. Although the buildd has been down for about 10 days now, it's still above the panic lines on both http://buildd.debian.org/stats/graph2-quarter-big.png and http://buildd.debian.org/stats/graph-quarter-big.png, and has caused only moderate delays for release-critical updates. Of course, I have a conflict of interest here as an alpha porter, so ultimately I'll defer to Andi if he thinks it's become a problem; but in general we're unlikely to cut a port from the release at this late stage without some pretty serious, long-term problems. Well, the one-and-only alpha buildd has been down for apparently ten days and does not respond to ping, and I don't recall seeing anything from the alpha team on debian-release or debian-devel. Please correct me if this is inaccurate. The release team was apprised of the buildd's status even before it went offline. It seems to me that, in a freeze, we should be ruthless about such a situation. In practice, the volume of release-critical bugfixes during a freeze is so small that even an outage of this length doesn't have a major impact on the release. After 10 days, alpha is blocking a little more than a dozen RC bugfixes -- which is less than either the kernel (which holds up d-i RC2) or iceweasel. The point of the arch requirements is to facilitate a release, not to penalize architectures. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please consider dak and nautilus-python for testing
Quoting Matthias Klose ([EMAIL PROTECTED]): two NMUs, the packages are currently not in testing; no RC reports for unstable: dak (1.0-8.2) unstable; urgency=medium * NMU * Remove build dependency on versioned python version with an unversioned. Closes: #403357. * Convert to updated python policy, using python-central. Closes: #380800. Immediately after this NMU enters testing, I plan another one, as part of my blitz l10n NMU campaign. This NMU would fix all pending debconf l10n bugs (and there are a lot of these). Given the special importance of dak, please object ASAP in case you find this inappropriate. signature.asc Description: Digital signature
Please unblock newpki-server 2.0.0+rc1-6.1
This NMU for that package, which I uploaded a few seconds ago, fixes all the pending debconf l10n bugs (only one.but that was the French translation, yikes). While building the package, I noticed that it doesn't depend on po-debconf while it uses it in debian/rules, so I added that package to the Build-Depends. I also added a very basic LSB header to the init script I guess it therefore qualifies for being unblocked. signature.asc Description: Digital signature
Re: why is alpha a release candidate?
On Wed, 2007-01-17 at 13:47 -0800, Steve Langasek wrote: Of course, I have a conflict of interest here as an alpha porter, so ultimately I'll defer to Andi if he thinks it's become a problem; but in general we're unlikely to cut a port from the release at this late stage without some pretty serious, long-term problems. What if a security build needs to be made in these ten days? signature.asc Description: This is a digitally signed message part
Re: why is alpha a release candidate?
On Wed, Jan 17, 2007 at 02:55:30PM -0800, Thomas Bushnell BSG wrote: On Wed, 2007-01-17 at 13:47 -0800, Steve Langasek wrote: Of course, I have a conflict of interest here as an alpha porter, so ultimately I'll defer to Andi if he thinks it's become a problem; but in general we're unlikely to cut a port from the release at this late stage without some pretty serious, long-term problems. What if a security build needs to be made in these ten days? I imagine this was intended as a rhetorical question, since there have already been security updates in the past few days. And yes, they're missing Alpha builds. :( noah signature.asc Description: Digital signature
suggesting the final numpy-1.0 release for testing
please consider numpy-1.0.1, plus depending packages for testing; testing currently has the numpy-1.0 release candidate 1; between rc1 and rc2 upstream did make some ABI incompatible changes, see [1] and [2]. The Debian Scipy Team would like to see the packages with the final 1.0 ABI in testing. The packages are now in unstable for a while, plus new subminor versions for scipy and matplotlib. The maintainers of all depending packages have tested the packages in unstable on at least one architectures and did not find any regressions. The following packages would be affected: python-numpy 1:1.0rc1-1 - 1:1.0.1-1 python-scipy 0.5.1-3 - 0.5.2-0.1 matplotlib 0.87.5-2.2 - 0.87.7-0.1 pyqwt 4.2.1-3 - 4.2.1-4 python-networkx0.32-2 (already approved in [3]) thanks, Matthias [1] http://lists.alioth.debian.org/pipermail/deb-scipy-devel/2006-December/000133.html [2] http://www.scipy.org/ReleaseNotes/NumPy_1.0 [3] http://lists.debian.org/debian-release/2007/01/msg00520.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock openbsd-inetd
openbsd-inetd (0.20050402-4) unstable; urgency=medium * Fix inetd to build on hurd. (Closes: #393829) * Accept UDP connections on all ports. (Closes: #389854) * Try harder to remove the netkit-inetd conffiles and kill the old inetd to prevent postinst failing. (Closes: #386469) -- Marco d'Itri [EMAIL PROTECTED] Sat, 6 Jan 2007 18:33:42 +0100 -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock netbase
netbase (4.28) unstable; urgency=medium * Added /etc/networks. (Closes: #399293) * etc-services: removed alias nameserver (53) because it is a duplicate. (Closes: #392739) * etc-services: added sge_qmaster (6444), sge_execd (6445), git (9418/tcp). (Closes: #401955, #402741) * etc-services: renamed suucp from 4013 to 4031 which is the correct port number assigned by IANA. -- Marco d'Itri [EMAIL PROTECTED] Sat, 6 Jan 2007 16:54:34 +0100 -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock ppp
ppp (2.4.4rel-4) unstable; urgency=low
[ Eddy Petri??or ]
* Using provider as the pppoe profile name in ppp-udeb so that the
connection starts after reboot and to integrate better with ppp helpers.
* Implemented idempotency in ppp-udeb by following the pid file generated
by pppd and bringing down interfaces which were rised by ppp-udeb.
* Improved some conditions which were problematic in concentrator detection.
* Deal elegantly with resolv.conf when using peer dns in ppp-udeb.
* Really detect if the interfaces were raised before ppp-udeb probed.
* Added a ppp-udeb.dirs file.
* Revert the gratuitous type change to note for ppp/detect_progress.
(Closes: #395197)
* Fix some mistakes in ppp-udeb.postinst which could have caused some of the
strange issues seen during early tests. (Closes: #395187)
* Updated debconf translation: ro.
[ Marco d'Itri ]
* Pass the command line arguments to the ip*-{up,down} scripts.
(Closes: #378810)
* Updated debconf translations: de, ru. (Closes: #396035, #397169)
* Improved bash completion. (Closes: #397037)
-- Marco d'Itri [EMAIL PROTECTED] Tue, 14 Nov 2006 12:52:29 +0100
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock module-init-tools
module-init-tools (3.3-pre4-1) unstable; urgency=medium * New upstream release, only bug fixes. * Added patch cmdline_opts_fix to prevent passing command line options to modules depended on. From Altlinux. (Closes: #336205) * Added patch format_64bit_fix to fix a possible bug on some 64 bit architectures. From Altlinux. * Moved modprobe.conf to modprobe.d/ in the udeb to stop ignoring other files in the directory. -- Marco d'Itri [EMAIL PROTECTED] Sat, 6 Jan 2007 16:01:00 +0100 -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock udev
Still not perfect, but better than the version currently in testing and I will need to upload the new one soon. udev (0.103-2) unstable; urgency=medium * permissions.rules: consider all block devices on usb, ieee1394, mmc and pcmcia buses to be removable. (Closes: #402622, #402649) * Added patch selinux_fix from Russell Coker to correctly label symlinks. Already applied upstream. (Closes: #401695) * Added patch m32r_syscalls by Kazuhiro Inaoka to fix inotify support on m32r systems. Already applied upstream. (Closes: #401826) * initramfs.premount premount: create the db directory before starting udevd, to catch some early kernel-generated events (this has no practical effect since the events will be immediately retriggered). Apply the same change to the init script. (Closes: #402320) * persistent-net-generator.rules: ignore ath* devices with type=802 because they have the same MAC address of the normal interface and cause write_net_rules to write a new bogus rule every time. (Closes: #404983) * net.agent: improve robustness by checking sysfs instead of the ifstate file and removing the timeout. Patch and testing by Joey Hess. (Closes: #403804, #403805) * postinst: deal correctly with pipes and sockets in subdirectories of /dev when being installed for the first time. (Closes: #404476) * New patch raid_endianess_fix backported from upstream udev 104. * New debconf templates: da, es, pt_BR, gl, ja, cs. (Closes: #400789, #402924, #402927, #403547, #404577, #405316, #405834) -- Marco d'Itri [EMAIL PROTECTED] Mon, 8 Jan 2007 02:41:01 +0100 -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock tcp-wrappers
tcp-wrappers (7.6.dbs-12) unstable; urgency=high * Fixed the match_port patch to not break matching on daemon names in a corner case (when request-server-sin has not been initialised by the caller). Patch courtesy of Janusz Krzysztofik. (Closes: #405342) * New debconf translations: ro, es. (Closes: #393514, #401908) -- Marco d'Itri [EMAIL PROTECTED] Mon, 8 Jan 2007 01:37:59 +0100 -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock kernel-package/10.066
Hi, I have just uploaded a version of kernel package that contains updated spanish man page translations, as well as typographical corrections. It also contains a number of bug fixes, which correct real problems in the package; and in each case I have tried to balance the upside with potential impact on things like official kernel images and the installer (none of the changes should impact either subsystem). The fixes include adding missing arch specific scripts to the header packages on ia64; required for third party compiles; and the lack of which makes the headers package on ia64 useless. Also unblocked are header, doc, and manual packages for Xen and UML, which make it possible for users to compile third party modules for their virtual machines; since the official packages do not use make-kpkg for xen/uml; this does not impact them, and since these are new packages that users can create, there is no regression. Also includes a tightened dependency on coreutils, so images compiled on Etch will pull in a version of coreutils on Sarge that allows the postinst to work. Details below. manoj kernel-package (10.066) unstable; urgency=high * Bug fix: kernel-package: Enable -source and -headers packages for Xen kernels, thanks to Ian Campbell. This is a simple change, and should have minimal impact on any other package, or on current user built packages. The upside is that the previously disabled packages are enabled for Xen and UML variants, allowing people to build third party modules for Xen adn UML variations -- and even if these were to break (they do not, in my testing), there is no regression. In the future, the image and modules packages will be separated, to allow for host/guest installs. Official kernel images do not use make-kpkg to build kernel or uml images, so the official images or debian-installer are not impacted either. (Closes: #390881). * Bug fix: kernel-package: postinst link_in_boot value set by image_in_boot, thanks to Niall Walsh. This was an out-and-out cut and paste error; and the fix is very simple (remove offending line). The downside is minimal, and current implementation is just wrong. (Closes: #405081). * Update spanish manual pages, thanks to Rudy Godoy. He also provided patches for spelling errors and style flaws in the English man pages. * Bug fix: Typos in manpage, thanks to Goswin Brederlow (Closes: #402155). * Bug fix: kernel-package: default stem inconsistent with documentation, thanks to Lionel Elie Mamane(Closes: #400697). * Bug fix: 'man kernel-img' typo: messgaes, thanks to A. Costa(Closes: #397379). * Bug fix: 'man kernel-pkg' typos: Mutualy and theversion, thanks to A. Costa (Closes: #397378). * Bug fix: make-kpkg clean: leaves scripts/package/Makefile.kpkg-dist behind, thanks to Yann Dirson. This was a simple typo, which prevented the naming back scripts/package/Makefile.kpkg-dist to scripts/package/Makefile -- making clean not restore the package to original state after running build/clean. There is little downside to this typo fix; we rename the Makefile, and we should be restoring it in clean. (Closes: #397518). * Bug fix: kernel-package: linux-headers doesn't inclue arch-specific scripts, thanks to dann frazier. When trying to compile external modules on on IA64/McKinley ItaniumII, the Makefile in arch/ia64/ needs some scripts from arch/ia64/scripts/ directory. These scripts were not so far being shipped. On non ia64, this has no impact on the headers package built; on ia64 the changes are required for the headers package to have any value.(Closes: #405494). * Bug fix: kernel-package: kernel image cant be installed when vmlinuz link is already, thanks to Kai Sassmannshausen. Actually, the problem was not depending on a new enough version of coreutils. See Below. (Closes: #407128). * Bug fix: kernel-package: dependency problem: kernel package installation uses a invalid option of readlink, thanks to Kai Sassmannshausen. In release version 10.063, I cleaned up the postinst as while I was at it, going with readlink -q -m instead of the built in version. Since -m was a flag not present in Sarge's coreutils, this means the generated image files should have a versioned dependency on coreutils. The previous versioned dependency was not strict enough, updated to a version that works. (Closes: #407130). -- Don't expect people to keep in step--it's hard enough just staying in line. Manoj Srivastava [EMAIL PROTECTED]
Please unblock gidentd 0.4.5-7.3
This NMU for that package, which I uploaded a few seconds ago, fixes the following, related to debconf/po-debconf: gidentd (0.4.5-7.3) unstable; urgency=low * Non-maintainer upload to fix a longstanding l10n-related issue * Remove the debconf template which was: - a useless and ivasive note - outdated as talking about a pre-sarge version Closes: #374413, #388896, #381312, #382230 * Lintian fixes: - Provide a very basic LSB header to the init script This was first intended as a debconf l10n update, but it turned out that the only debconf template is that annoying useless note, which deals with a pre-sarge version of the package. I also added a basic LSB header to the init script as I alredy did for some other packages previously, during that blitz l10n NMU campaign. signature.asc Description: Digital signature
