Re: d-i wheezy rc2 preparation, take 1

[Philipp Kern]

On Mon, Apr 08, 2013 at 07:31:14AM +0200, Niels Thykier wrote:
> 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).

Apr  8 06:41:50 buildd-uploader[14181]: Set to Uploaded(sid): choose-mirror_2.45

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: d-i wheezy rc2 preparation, take 1

[Niels Thykier]

On 2013-04-08 02:02, Cyril Brulebois wrote:
> Updated summary:
> 
> Cyril Brulebois  (07/04/2013):
>> Cyril Brulebois  (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

Bug#702278: busybox upload

[Michael Tokarev]

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
> 

Re: d-i wheezy rc2 preparation, take 1

[Cyril Brulebois]

Updated summary:

Cyril Brulebois  (07/04/2013):
> Cyril Brulebois  (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#704934: unblock: gnome-session/3.4.2.1-4 gdm3/3.4.1-7

[Emilio Pozuelo Monfort]

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

Bug#704729: unblock: alsa-base/1.0.25+3 (pre-approval)

[Michael Biebl]

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#683847: marked as done (unblock: sgml-base/1.26+nmu4)

[Debian Bug Tracking System]

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
--- Begin Message ---
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   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

Bug#704900: marked as done (nmu: librevisa_0.0.20130404-2)

[Debian Bug Tracking System]

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
--- Begin Message ---
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 ---
--- Begin Message ---
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#704520: RM: midgard2-core/10.05.7.1-1 php5-midgard2/10.05.7-1

[Niels Thykier]

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: nmu: librevisa_0.0.20130404-2

[Andreas Beckmann]

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

Re: d-i wheezy rc2 preparation, take 1

[Samuel Thibault]

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

Re: Bug#695224: Locale::Maketext versioning in perl package

[Niels Thykier]

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 
>> 
>> 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 2

[Niels Thykier]

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

d-i wheezy rc2 preparation, take 2

[Cyril Brulebois]

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 1

[Cyril Brulebois]

Current summary for this “take 1”:

Cyril Brulebois  (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

Re: Status of haproxy for upcoming wheezy release

[Vincent Bernat]

 ❦  7 avril 2013 02:34 CEST, Julien Cristau  :

>> > 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