Re: Status of haproxy for upcoming wheezy release
❦ 7 avril 2013 02:34 CEST, Julien Cristau jcris...@debian.org : your email. I am not using the 1.4.x branch and therefore cannot say if 1.4.15 is usable. Here is what I propose: - We release with 1.4.15 with your proposed patches (I think the release team will be OK) in #674447 and #704611. I have discussed a bit with Willy (upstream) and he would like that we don't ship haproxy 1.4.15 with Debian. He would prefer no haproxy at all than this old version that he considers as unfit for the release (even with the two fixes above). Hinted for removal. Thanks! I plan to bring the appropriate discussion to debian-devel@ after the release. Christo, would you be willing to accept me as a co-maintainer? -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan Plauger) pgpVKvBdlImz1.pgp Description: PGP signature
Re: d-i wheezy rc2 preparation, take 1
Current summary for this “take 1”: Cyril Brulebois k...@debian.org (06/04/2013): Things I'd like to see merged: - netcfg (preseed bug -- fixed in git -- and iw installation); awaiting some bits of review for the wireless-* settings part. Phil, maybe? - tasksel: install n-m for gnome; awaiting a reply from debian-cd@. - manual: Samuel, time for another upload? All those still need an answer. Thanks to Christian and release managers for the other points. Mraw, KiBi. signature.asc Description: Digital signature
d-i wheezy rc2 preparation, take 2
Hello folks, here's another set of queries. Please hurry those into testing: - apt-setup/1:0.79 l10n + apt-setup/multiarch unbreakage. Even if AFAICT it's undocumented, keeping nonworking cruft looks like a bad idea since we can avoid it with a tiny patch. - choose-mirror/2.45 Kindly uploaded by Christian according to the take 1 mail. - rootskel-gtk/1.27 Fix theme=dark; not sure why it wasn't migrated already, but I guess it doesn't matter much, probably failed to ask for it. And also those (l10n only): - cdebconf/0.182 - network-console/1.43 - partman-basicmethods/52 - partman-crypto/57 - partman-efi/36 - partman-partitioning/91 - partman-target/82 - preseed/1.58 Thanks already! Mraw, KiBi. signature.asc Description: Digital signature
Re: d-i wheezy rc2 preparation, take 2
On 2013-04-07 13:23, Cyril Brulebois wrote: Hello folks, here's another set of queries. Please hurry those into testing: - apt-setup/1:0.79 l10n + apt-setup/multiarch unbreakage. Even if AFAICT it's undocumented, keeping nonworking cruft looks like a bad idea since we can avoid it with a tiny patch. - choose-mirror/2.45 Kindly uploaded by Christian according to the take 1 mail. - rootskel-gtk/1.27 Fix theme=dark; not sure why it wasn't migrated already, but I guess it doesn't matter much, probably failed to ask for it. Done ... And also those (l10n only): - cdebconf/0.182 - network-console/1.43 - partman-basicmethods/52 - partman-crypto/57 - partman-efi/36 - partman-partitioning/91 - partman-target/82 - preseed/1.58 Thanks already! Mraw, KiBi. ... and done. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51615bdb.4020...@thykier.net
Re: Bug#695224: Locale::Maketext versioning in perl package
On 2013-04-02 21:15, Niko Tyni wrote: On Sun, Mar 31, 2013 at 05:46:12PM +0100, Dominic Hargreaves wrote: There is a problem with the perl package, as discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695224#55 onwards, whereby the application of the security fix in that ticket now causes double-escaping problems where people workaround the problem by escaping themselves, when they detect an earlier Locale::Maketext by version number. I am slightly wary about importing the new (1.23) version of Locale::Maketext as I mentioned in that bug already, but my fears may be unfounded. Could you comment about whether you would accept such a change in wheezy at this time? (I can't really decide whether it's RC or not). FWIW, it looks clear to me that the only functional changes in the patch are the $VERSION increments in the .pm files. The rest is documentation and test cases, and the only important $VERSION is most probably the main one in Locale/Maketext.pm. Indeed. While that change itself is trivial, it has action-at-distance effects - otherwise this wouldn't be an issue at all. I think the risk potential is mostly in breaking something that's trusting Module::CoreList (dh-make-perl and lintian come to mind, CPAN.pm and CPANPLUS.pm might be affected somehow too?), and that it's not a very big risk but still a real one. Lintian uses a precomputed static list. It would at worst lead to false-negatives for package-superseded-by-perl (i.e. no tag when one should have been there). I suspect dh-make-perl will have a similar case with using the cpan variant instead of the core variant in dependencies (though I only gave it a quick scan). I would suspect that any application code using Module::CoreList would still have to account for the cpan version being present? [...] In this specific case, upgrading Locale::Maketext fully to 1.23 in wheezy would probably have been the right thing to do if we had anticipated these issues. But we didn't, and it seems very late in the release process to do it now. Also, I can't really see us applying anything but the targeted fix for squeeze. I am tempted to take this fix for Wheezy and be done with it. Can (one of) you please check up on CPAN.pm/CPANPLUS.pm ? I see Fedora/RedHat also upgraded their Locale::Maketext modules without incrementing $VERSION (I checked the patches in RHEL 6 / Perl 5.10.1 and Fedora Core 16 17 / Perl 5.14.3). So it looks like even if we do try to fix this for wheezy, applications still have to check for features rather than versions to stay on the safe side. Okay, sounds like it will be fine with leaving Squeeze as is then. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516162be.80...@thykier.net
Re: d-i wheezy rc2 preparation, take 1
Cyril Brulebois, le Sat 06 Apr 2013 10:21:20 +0200, a écrit : - manual: Samuel, time for another upload? Yep, will do. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130407123213.GA7681@type
Bug#704900: nmu: librevisa_0.0.20130404-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu librevisa_0.0.20130404-2 . amd64 . -m Rebuild in a clean sid environment. Package: libvisa0 Source: librevisa Version: 0.0.20130404-2 Architecture: amd64 Depends: ..., libc6 (= 2.15), ... Once again a package was built in experimental or Ubuntu and uploaded to sid. Andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130407123052.8814.71933.report...@cake.ae.cs.uni-frankfurt.de
Bug#704520: RM: midgard2-core/10.05.7.1-1 php5-midgard2/10.05.7-1
user release.debian@packages.debian.org usertags 677795 + wheezy-will-remove thanks On 2013-04-02 13:13, Didier Raboud wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi dear Release Team, hi dear midgard2-core and php5-midgard2 maintainers, as explained in http://bugs.debian.org/677795#67 , I think midgard2-core (and it's only build-rdep, php5-midgard2) should get removed from testing: As I read it, the package had several packaging-related issues summing up to that serious bug, filed two weeks before the freeze. Since then, in September, a package supposedly fixing these issues has been uploaded and queued in NEW [0]; it hasn't been liberated from NEW yet. From here, I see three ways forward: a) a new package enters unstable, and then Wheezy, but that seems unlikely; b) midgard2-core and php5-midgard2 are removed from Wheezy, thereby removing the RC bug. c) that bug either gets downgraded to non-RC severity, or tagged wheezy-ignore by the release team. As I think the concerns originally leading to the severity of that bug are correct, I would rather be of the opinion to drop the two packages. As you see, I think that as this point, b) is the only reasonable choice. Cheers, OdyX [...] We have not accepted new (binary) packages in Wheezy for quite a while. So option a) is indeed very unlikely. As it is, I am inclined to agree with OdyX's observations, so I am tagging the bug as will-remove for now. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5161670a.4060...@thykier.net
Bug#704900: marked as done (nmu: librevisa_0.0.20130404-2)
Your message dated Sun, 07 Apr 2013 16:03:20 +0100 with message-id 1365347000.29666.11.ca...@jacala.jungle.funky-badger.org and subject line Re: Bug#704900: nmu: librevisa_0.0.20130404-2 has caused the Debian Bug report #704900, regarding nmu: librevisa_0.0.20130404-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 704900: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704900 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu librevisa_0.0.20130404-2 . amd64 . -m Rebuild in a clean sid environment. Package: libvisa0 Source: librevisa Version: 0.0.20130404-2 Architecture: amd64 Depends: ..., libc6 (= 2.15), ... Once again a package was built in experimental or Ubuntu and uploaded to sid. Andreas ---End Message--- ---BeginMessage--- On Sun, 2013-04-07 at 14:30 +0200, Andreas Beckmann wrote: nmu librevisa_0.0.20130404-2 . amd64 . -m Rebuild in a clean sid environment. Package: libvisa0 Source: librevisa Version: 0.0.20130404-2 Architecture: amd64 Depends: ..., libc6 (= 2.15), ... Once again a package was built in experimental or Ubuntu and uploaded to sid. Scheduled. Regards, Adam---End Message---
Bug#683847: marked as done (unblock: sgml-base/1.26+nmu4)
Your message dated Sun, 07 Apr 2013 17:46:57 +0100
with message-id 1365353217.29666.16.ca...@jacala.jungle.funky-badger.org
and subject line Re: Bug#683847: unblock: sgml-base/1.26+nmu4
has caused the Debian Bug report #683847,
regarding unblock: sgml-base/1.26+nmu4
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
683847: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683847
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block -1 by 683844
Dear release team,
Please
unblock sgml-base/1.26+nmu4
The version intends to fix all remaining RC bugs of sgml-base:
#678902: sgml-base needs to Pre-Depend on dpkg 1.16.4
#676717: sgml-base produces broken super catalog when packages are in
rc state
The patch is the same as attached to the respective bug logs. The
pre-dependency has been discussed with -devel and deemed appropriate,
because the dpkg maintainers will not be able to provide the necessary
dpkg feature (since they failed to reply in a timely manner). The
intrusive part of parsing catalogs has been contributed and reviewed by
Jakub Wilk. The patch also removes some useless and annoying messages as
requested by Julien Cristau.
The attached .debdiff is between wheezy and the not yet sponsored sid
version. The sponsorship bug #683844 blocks this bug.
Helmut
diff -Nru sgml-base-1.26+nmu3/debian/changelog
sgml-base-1.26+nmu4/debian/changelog
--- sgml-base-1.26+nmu3/debian/changelog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/debian/changelog2012-06-27 21:04:29.0
+0200
@@ -1,3 +1,16 @@
+sgml-base (1.26+nmu4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * update-catalog --update-super ignores catalogs referencing non-existent
+files. (Closes: #676717) Thanks to Jakub Wilk for contributing the parser.
+ * Remove warning about rebuilding packages as it may confuse users.
+ * Quieten update-catalog during trigger and postinst, to avoid warnings for
+packages in rc state.
+ * Pre-Depend on dpkg = 1.16.4 (Closes: #678902). Removed dependency on
+dpkg = 1.14.18. sgml-base highlights a bug in dpkg's trigger processing.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 21 Jun 2012 16:09:07 +0200
+
sgml-base (1.26+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru sgml-base-1.26+nmu3/debian/control sgml-base-1.26+nmu4/debian/control
--- sgml-base-1.26+nmu3/debian/control 2012-05-28 13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/control 2012-06-27 20:38:49.0 +0200
@@ -11,7 +11,8 @@
Priority: optional
Architecture: all
Conflicts: sgml-data (= 0.02), sgmltools-2 (= 2.0.2-4)
-Depends: ${perl:Depends}, dpkg (= 1.14.18)
+Depends: ${perl:Depends}
+Pre-Depends: dpkg (= 1.16.4)
Suggests: sgml-base-doc
Description: SGML infrastructure and SGML catalog file support
This package creates the SGML infrastructure directories and provides
diff -Nru sgml-base-1.26+nmu3/debian/sgml-base.postinst
sgml-base-1.26+nmu4/debian/sgml-base.postinst
--- sgml-base-1.26+nmu3/debian/sgml-base.postinst 2012-05-28
13:58:23.0 +0200
+++ sgml-base-1.26+nmu4/debian/sgml-base.postinst 2012-06-22
17:22:31.0 +0200
@@ -61,12 +61,12 @@
fi
## --
-update-catalog --update-super
+update-catalog --quiet --update-super
ln -sf /var/lib/sgml-base/supercatalog /etc/sgml/catalog
fi
if [ $1 = triggered ]
then
-update-catalog --update-super
+update-catalog --quiet --update-super
fi
## --
diff -Nru sgml-base-1.26+nmu3/tools/update-catalog
sgml-base-1.26+nmu4/tools/update-catalog
--- sgml-base-1.26+nmu3/tools/update-catalog2012-05-28 21:11:52.0
+0200
+++ sgml-base-1.26+nmu4/tools/update-catalog2012-06-27 21:04:45.0
+0200
@@ -4,6 +4,7 @@
## --
## Copyright (c) 2001-2004 Ardo van Rangelrooij
## Copyright (c) 2012 Helmut Grohne
+## Copyright (c) 2012 Jakub Wilk
##
## This is free software; see the GNU General Public Licence version 2
## or later for copying conditions. There is NO warranty.
@@ -138,8 +139,6 @@
print Invocation of dpkg-trigger failed with status $?.\n;
print Forcing update of the super catalog...\n;
update_super;
-} else {
-print update-catalog: Please rebuild the
Bug#704729: unblock: alsa-base/1.0.25+3 (pre-approval)
Am 05.04.2013 06:50, schrieb Jordi Mallach: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I've prepared an update for alsa-base, to deal with a conffile fuckup that happened moths ago and unfortunately got unnoticed by me until recently. The rough story is: alsa-base, until +1, was doing Weird Shit™ with its handling of /etc/default/alsa, which wasn't even a conffile. When I got rid of all of that in +2, I accidentally got the new conffile renamed to /e/d/alsa-base due to using debhelper to install it. The script that sources it wasn't updated to look in the new location, and of course users were left with the old conffile and the new one in the filesystem. The updated package tries to fix this for people upgrading from squeeze and also for current testing users which already have both files. As briefly mentioned on IRC, the alternative to switching to /etc/default/alsa-base, is to keep the old /etc/default/alsa configuration file (which is used in squeeze) and simply remove /etc/default/alsa-base for sid users. Unless there is a good reason to switch to the new name, I'd just keep the old one. Jordi, is there a reason why this option was not considered? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#704934: unblock: gnome-session/3.4.2.1-4 gdm3/3.4.1-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, The screen reader is currently not working in GDM, this is a regression from squeeze. I've looked into the problem (bug #689559) and have fixed it. The problem is that since around 3.0, gdm doesn't support a directory to place .desktop files that are autostarted in the gdm session. My patches fix this: - by adding support to gnome-session (new --start option) so that we can specify a directory (/usr/share/gdm/greeter/autostart/) that will contain .desktop files to be started in the gdm session (the current --autostart option overrides session loading so it's not an option, and I didn't want to modify its behaviour in case something else uses it). - by making gdm specify that directory so that .desktop files in it are started, and adding a file for orca (if orca is not installed nothing will happen and gdm has traditionally shipped that file for orca, that's why I added it to gdm and not to orca) - by adding a menu entry to the panel in the gdm greeter so that one can start/stop the screen reader. One issue is that the new menu entry in gdm has a translatable string (Screen Reader). Since gdm has that string, I could copy the translations from it. I understand that it's quite late in the freeze, but since a11y is very important, I think this needs to be fixed. I wouldn't mind postponing it till the release is done and including this in a point release if needed. WDYT? Thanks, Emilio gdm3.debdiff Description: application/extension-debdiff gnome-session.debdiff Description: application/extension-debdiff
Re: d-i wheezy rc2 preparation, take 1
Updated summary: Cyril Brulebois k...@debian.org (07/04/2013): Cyril Brulebois k...@debian.org (06/04/2013): Things I'd like to see merged: - netcfg (preseed bug -- fixed in git -- and iw installation); awaiting some bits of review for the wireless-* settings part. Phil, maybe? RMs, please unblock/urgent the recently uploaded: netcfg/1.108 I'll probably take care of uploading d-i once the testing update has reached the mirrors. - tasksel: install n-m for gnome; awaiting a reply from debian-cd@. Either way (fix in tasksel, or fix in debian-cd), not a blocker for a d-i upload; Steve will answer that in the upcoming days. - manual: Samuel, time for another upload? I'm uploading it right now; not a blocker for a d-i upload anyway. Mraw, KiBi. signature.asc Description: Digital signature
Bug#702278: busybox upload
I'm pinging this bug, as we're getting seriously out of time. Now, I guess, we should either let the whole thing go (it has already been unblocked for, only d-i block remains), or mark the relevant bugs as non-RC for wheezy. Thanks, /mjt 25.03.2013 15:38, Michael Tokarev wrote: Let me start from scratch please. I wasn't aware of this bugreport/discussion, and I made a mistake by not filing a proper unblock request when I uploaded the busybox package with all the fixes. So here are descriptions of every change. A sort of a fore-word first. Busybox is kind of unusual package in a way that it re-implements functionality of various existing packages. Base debian system uses other implementations of the same functionality usually. So from this PoV, any busybox bug is not that important for a user's debian system, since a typical user does not use any busybox applets at all. Busybox _is_ used on almost every end-user system because it provides the set of basic *nix utilities for initramfs, and it is used in debian-installer. But these are very restricted environments with much better defined components and much less chance to have a combination which triggers one or another bug. So, any bug in busybox which does not affect basic initramfs or d-i functionality directly can't be important enough for whole debian system, so to say. On the other hand, sometimes, since busybox is almost always installed and available on any debian system, it gets used by users in various much less restricted environments, which leads to situations where the bugs are actually gets hit. This is minority of users (again, so to say). So this is about whenever we really care about this minority or not, _plus_ about _possible_ issues in d-i or initramfs. Another source of unusuality comes from the fact that busybox implements a ton of _independent_ applets, so that a change in one does not affect anything else (if we don't count changes in, say, memory layout which triggers bugs elsewhere - this has already happened at least once during wheezy development cycle, when we discovered bug with unaligned memory access which was hidden because the objects were actually aligned properly before we changed something unrelated in memory). So, back to the changes. busybox (1:1.20.0-8) unstable; urgency=low * grep-fix-grep--Fw-not-respecting-the--w-option.patch - implement fgrep -w correctly (Closes: #695862) As has been said before, this is a feature fix. It is not. The problem initially has been raized in some other package which had initramfs hook which didn't work. I don't remember which package it was, the context was that it tried to find some CPU feature by grepping /proc/cpuinfo with -w flag to grep, used to remove false positives, and it didn't work. (/proc/cpuinfo is just an example, I don't really remember what it was). This is one of these bugs which makes other, unrelated components fails in unexpected and difficult to debug ways. The fix is somewhat large, because it had to deal with logic of operations in grep applet. On the plus side, it comes with additional testcases which checks for this issue, and there are lots of other grep-related testcases already present. Unfortunatly busybox debian package still does not run any testcases during build (this is on my TODO list of first things to do for jessie), but having in mind the situation (deep freeze) and importance of the applet I ran provided and a few more testcases against the resulting grep on x86, ppc and mips platforms (on debian porterboxes) manually to ensure the fix does not break anything else and actually fixes the bug. If you ask me, this is about the same importance as #686502, but it is less obvious. This grep-w bug does not lead to data loss directly, the problem is that we can't rely on grep doing the right thing when we use it in a familiar, natural way - like when we try to fix a false positive by adding -w _somewhere else_ (in some other package that is), and it stops working. That's why it isn't a feature fix, busybox claimed to support grep-w but it does not work. What we're fixing here mostly is about _further_ d-i or initramfs changes (including possibility to have these changes in wheezy too) which looks completely correct and obvious but don't work in practice. Plus some random rare end-users usage of busybox grep, of these are exists. What we risk here is almost nothing, at least according to my tests on several platforms. * xz-support-concatenated-xz-streams.patch (Closes: #686502) This is the main RC bug currently filed against busybox. The rationale for it being RC is because it causes _silent_ data loss when decompressing certain kinds of XZ streams. Again, the severuty can be argued for sure, due to whole nature of busybox as a second-kind sitizen as mentioned at the beginning of this mail. First, not everyone is
Re: d-i wheezy rc2 preparation, take 1
On 2013-04-08 02:02, Cyril Brulebois wrote: Updated summary: Cyril Brulebois k...@debian.org (07/04/2013): Cyril Brulebois k...@debian.org (06/04/2013): Things I'd like to see merged: - netcfg (preseed bug -- fixed in git -- and iw installation); awaiting some bits of review for the wireless-* settings part. Phil, maybe? RMs, please unblock/urgent the recently uploaded: netcfg/1.108 I'll probably take care of uploading d-i once the testing update has reached the mirrors. Unblocked. Btw, I am not sure how important choose-mirror is, but it didn't migrate last night (AFAICT it is built, just missing a signature + upload on ia64). [...] Mraw, KiBi. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51625622.5060...@thykier.net
