Re: please allow debian-edu-install 0.675 into testing

2009-06-13 Thread Pierre Habouzit
On Fri, Jun 12, 2009 at 05:56:39PM -0300, Otavio Salvador wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Vagrant Cascadian vagr...@freegeek.org writes:
 
  please allow debian-edu-install 0.675 into testing, which is blocked from
  migrating due to it's udebs. i do not believe the udebs are used in a 
  default
  install, and thus shouldn't impact debian-installer.
 
 No objection

hinted
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature


Re: please unblock libpng 1.2.37-1 pciutils 1:3.1.2-5 (both with udebs)

2009-06-13 Thread Pierre Habouzit
On Fri, Jun 12, 2009 at 05:55:57PM -0300, Otavio Salvador wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Aníbal Monsalve Salazar ani...@debian.org writes:
 
  please unblock libpng 1.2.37-1 pciutils 1:3.1.2-5 (both with udebs)
 
  Changes: 
   libpng (1.2.37-1) unstable; urgency=low
   .
 * New upstream release
 
  Changes:
   pciutils (1:3.1.2-5) unstable; urgency=medium
   .
 * Update pci.ids with snapshot dated 2009-06-02 03:15:01
 
 No objection

hinted
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature


Re: Please hint eglibc/2.9-13 into testing

2009-06-10 Thread Pierre Habouzit
On Wed, Jun 10, 2009 at 11:49:52AM +0200, Aurelien Jarno wrote:
 Hi,
 
 eglibc/2.9-13 is ready to move into testing. It fixes 2 RC bugs, and
 does not introduce any known bug. Could you please hint it?

d-i people ?


-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature


Re: hint cryptsetup/2:1.0.6+20090405.svn49-1 for debian/squeeze

2009-06-08 Thread Pierre Habouzit
On Mon, Jun 08, 2009 at 04:51:02PM +0200, Jonas Meurer wrote:
 hey again,
 
 On 02/06/2009 Jonas Meurer wrote:
  cryptsetup/2:1.0.6+20090405.svn49-1 has been in unstable for 59 days now
  without migrating to testing. I guess that this is due to the udeb it
  creates. It would be great if you could hint it for migration to
  testing/squeeze.
  
  here's the relevant changelog:
 
 is there a reason why this request has been ignored so far? can I do
 anything about it?
 
 i've cc'ed debian-kernel now, as cryptsetup creates a udeb, and their
 option might be relevant.

It's debian-boot you want to Cc
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: hint cryptsetup/2:1.0.6+20090405.svn49-1 for debian/squeeze

2009-06-08 Thread Pierre Habouzit
On Mon, Jun 08, 2009 at 04:58:06PM +0200, Pierre Habouzit wrote:
 On Mon, Jun 08, 2009 at 04:51:02PM +0200, Jonas Meurer wrote:
  hey again,
  
  On 02/06/2009 Jonas Meurer wrote:
   cryptsetup/2:1.0.6+20090405.svn49-1 has been in unstable for 59 days now
   without migrating to testing. I guess that this is due to the udeb it
   creates. It would be great if you could hint it for migration to
   testing/squeeze.
   
   here's the relevant changelog:
  
  is there a reason why this request has been ignored so far? can I do
  anything about it?
  
  i've cc'ed debian-kernel now, as cryptsetup creates a udeb, and their
  option might be relevant.
 
 It's debian-boot you want to Cc

Though as udeb migration is manual, ther eis no reason not to unblock.

Done, sorry for the query having been lost.
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: freeze exception: freetype, RC bug but includes udeb

2008-08-22 Thread Pierre Habouzit
On Fri, Aug 22, 2008 at 02:38:16PM +, Otavio Salvador wrote:
 Steve Langasek [EMAIL PROTECTED] writes:
 
  This is a request for a freeze exception on freetype 2.3.7-1, just uploaded
  to unstable to fix RC bug #487101.
 
  The full debdiff is attached.
 
  This is a straightforward fix, but freetype provides a udeb, so I'm asking
  here before unblocking.
 
 No objection

unblocked
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpaGcvdlUMmB.pgp
Description: PGP signature


Re: Please unblock loop-aes-utils 2.13.1-4

2008-08-22 Thread Pierre Habouzit
On Fri, Aug 22, 2008 at 11:06:57AM +, Max Vozeler wrote:
 Hi release team,
 
 please unblock loop-aes-utils 2.13.1-4; the only change in -4
 is an RC bugfix. CCing -boot because it includes an udeb.

  unblocked as soon as d-i acks.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp7J0vlNRQHP.pgp
Description: PGP signature


Re: Freeze exception request for directfb 1.0.1-11

2008-08-18 Thread Pierre Habouzit
On Mon, Aug 18, 2008 at 12:38:20PM +, Fathi Boudra wrote:
 Hi,
 
 Could you please unfreeze libdirectfb 1.0.1-11 ?
 
 It fixes 2 bugs:
 - unicode key handling (bug #401296) usefull for Debian graphical installer.
 - DirectFb fails to start in usual case (RC bug #493899).

unblocked.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpJ6IwkOP1xp.pgp
Description: PGP signature


Re: Freeze exception request for directfb 1.0.1-11

2008-08-18 Thread Pierre Habouzit
On lun, aoû 18, 2008 at 12:57:14 +, Pierre Habouzit wrote:
 On Mon, Aug 18, 2008 at 12:38:20PM +, Fathi Boudra wrote:
  Hi,
  
  Could you please unfreeze libdirectfb 1.0.1-11 ?
  
  It fixes 2 bugs:
  - unicode key handling (bug #401296) usefull for Debian graphical installer.
  - DirectFb fails to start in usual case (RC bug #493899).
 
 unblocked.

  err no not yet, if debian-boot agrees, there is a udeb.



-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp7vgBfxtGhn.pgp
Description: PGP signature


Re: Unblocks for l10n NMUs (one needing D-I team approval)

2008-08-17 Thread Pierre Habouzit
On Sat, Aug 16, 2008 at 03:30:30PM +, Christian Perrier wrote:
 I think I went over all l10n NMUs I uploaded during last weeks and
 found the following:
 
 With udebs, needing D-I team approval:
 
 console-setup/1.27:
* Add a template for the main menu item name.
* Translation updates
  No objection from my part.

 Regular updates, with a few more minor things:
  all unblocked.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpwA4LIeqv2R.pgp
Description: PGP signature


Re: Please unblock beep (udeb), translation updates

2008-08-16 Thread Pierre Habouzit
On Sat, Aug 16, 2008 at 04:48:42PM +, Gerfried Fuchs wrote:
 Hi!
 
  Please unbock beep, the update contains mostly of translation
 additions/updates due to some rewrite suggestion I received. Futhermore
 it also contains some lintian cleanups, but no other changes.

  fine with me if d-i people agree.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpSpibTU0A73.pgp
Description: PGP signature


Re: Allow localechooser to propagate to testing

2008-08-03 Thread Pierre Habouzit
On Sat, Aug 02, 2008 at 06:59:45AM +, Christian Perrier wrote:
 localechooser 2.04 fixes a few things for D-I but that should normally
 be included as part of a normal D-I release.
 
 *However*, it also drops the need for iso-codes-udeb and will
 therefore make the need for that udeb useless, which would in turn
 simplify the work of iso-codes maintainers (see recent unblock request
 by Tobias).
 
 When I discussed that with him in mid-July, Frans Pop agreed that the
 best way to fix this was uploading localechooser 2.04 and have it
 enter testing so that an iso-codes package without the udeb can be
 uploaded to unstable and then enter testing.
 
 So, technically speaking, that was prepared before the
 freeze..:-)...However, for this to happen, we needed to:
 
 - have iso-codes enter testing (it contains several important changes
 in lists and translations and iso-codes maintainers wanted to secure
 them out)
 - have localechooser enter testing
 - build a new iso-codes without the udeb
 - have it enter testing
 
 So, now I think we should request for 2). If the D-I RM agrees, could
 localechooser be hinted for testing, please?

I'd like to have the d-i people opinion on the disruptiveness of that
first. Not building an udeb for iso-codes now that it's unblocked for
testing would be fine.

If i'm correct localechooser is mostly (if not only) used during d-i, so
d-i people opinion matters more than ours. I will follow them on this.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp0TRrCsZb1y.pgp
Description: PGP signature


Re: Please allow multipath-tools and multipath-tools-initramfs into lenny

2008-08-01 Thread Pierre Habouzit
On Thu, Jul 31, 2008 at 09:25:52AM +, Guido Günther wrote:
 Hi,
 
 Changes to multipath-tools 0.4.8-11:
 
   RC Bug:
   * [4f8a5d1] Call multipath via udev on block device add/change events This
 helps slow devices when either /etc/init.d/multipath-tools-boot or the
 initramfs script are being run although the devices are not ready yet.
 (Closes: #489850) - many thanks to Janusz Dziemidowicz for his suggestions
 and testing
   
   Robustness:
   * [3dadace] use the full path to dmsetup so we don't have to worry about
 $PATH
   * [33642da] update initramfs during postinst/postrm (Closes: #477839)
 
   Upgrade Path:
   * [41391c9] Conflict on etch's multipath-tools-initramfs - together with the
 multipath-tools-initramfs NMU from Bernd Zeimetz this provides a clean
 upgrade path from etch to lenny for multipath-tools-initramfs users.
 
   Translation:
   * [5cbb079] add swedish debconf translation (Closes: #492107) - thanks to
 Martin Ågren
 
   Cleanup:
   * [12639e9] redo quilt patches - no code changes
 
 The numbers in braces give the git commit id's $ID. The patches can be
 seen at:
   http://git.debian.org/?p=pkg-lvm/multipath-tools.git;a=commit;h=$ID
 
 Please allow this package into lenny there were no code changes on the
 upstream code and there are no reverse dependencies. The udeb isn't an
 issue since multipath support isn't part of d-i.
 
 Changes to multipath-tools-initramfs 1.0.1+nmu1:
 
 This package is obsoleted by multipath-tools-boot (from
 multipath-tools). Bernd NMUed the package to allow for a clean upgrade
 patch from etch. Multipath-tools-initramfs as of 1.0.1 isn't installable
 in sid/lenny.

  I believe this package has an udeb, but it's fine by me if d-i agrees.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBCht8t36Jq.pgp
Description: PGP signature


Re: Allow debian-edu-install to propagate to testing

2008-08-01 Thread Pierre Habouzit
On Fri, Aug 01, 2008 at 12:21:54PM +, Otavio Salvador wrote:
 Petter Reinholdtsen [EMAIL PROTECTED] writes:
 
  Hi.  The current debian-edu-install package in unstable (0.672) got
 
 No objection

unblocked

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQLLJwZhTmI.pgp
Description: PGP signature


Re: Please allow multipath-tools and multipath-tools-initramfs into lenny

2008-08-01 Thread Pierre Habouzit
On Fri, Aug 01, 2008 at 12:21:13PM +, Otavio Salvador wrote:
 Pierre Habouzit [EMAIL PROTECTED] writes:
  On Thu, Jul 31, 2008 at 09:25:52AM +, Guido Günther wrote:
   Changes to multipath-tools 0.4.8-11:
I believe this package has an udeb, but it's fine by me if d-i agrees.
 No objection

unblocked.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpqEyekOy1yP.pgp
Description: PGP signature


Re: grub 0.97-44

2008-07-29 Thread Pierre Habouzit
On Mon, Jul 28, 2008 at 08:11:39PM +, Robert Millan wrote:
 
 Hi,
 
 The PTS indicates that 0.97-42/0.97-43 wouldn't migrate normally, so I'm
 forced to merge my request with the one for -44 (even though -42 and -43
 don't meet the criteria, since they were uploaded before the freeze).
 
 Anyway, please consider approving grub 0.97-44.

  Ack if d-i has no issues with it.



-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpWLDm2bMnTX.pgp
Description: PGP signature


Re: Selection of kernel for Lenny

2008-07-08 Thread Pierre Habouzit
On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
 On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
  * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
   Changing kernel at this point of the release would be too destructive,
   so unless there is a big fat problem in the .25 that the .26 should fix
   and is unbackportable (does such a beast even exist ?) I'm rather
   opposed to it. Note that the asm/page.h mess is still not fixed thanks
   to hppa.
   
   Disclaimer: it's my own opinion, I did not check what other Release Team
   member think about this.
  
  I agree with you, at least with my current informations.
 
 please read the changelog trunk on all the 2.6.26 fixes.

  Huh, that's not really our work, you as the maintainer should help us
understand why we would like to deal with 3 months of FTBFS *right now*.
Not to mention the libata changes fjp talks about, that would probably
break many upgrades and for which there is no known solution.

 we have allways stated that .26 will be the release kernel.

  The sole mail from the kernel team that I can find is[0]. We've seen
no updates from you since AFAICT. Given the content of the mail, and its
age, I don't see how we can know that.

 I don't understand why this would come as a surprise.

  I'll start with reminding you that the toolchain is frozen and that
the kernel is part of it.

  Now could you explain how changing kernel for a new upstream, with the
well known fact that one needs to wait for the .2/.3 to have a decent
working kernel (IOW in at least 2/3 weeks after the release) is not a
disruptive change[1]?  Add testing migration to that, plus tied
transitions, then I expect a really good rationale from you to explain
why a 6-8 weeks delay in the toolchain freeze (IOW in the release
process) is acceptable and needed[2].

  The fact that you're unable to understand that is quite worrying.


  [0] http://lists.debian.org/debian-release/2007/04/msg00189.html

  [1] e.g. have you done full scale archive rebuilds to show that a new
  linux-libc-dev won't at least cause dozens of FTBFS like the
  2.6.25 did ?

  [2] and I'm pretty sure the d-i crew has alike reservations.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp0bgV1QrYgd.pgp
Description: PGP signature


Re: Selection of kernel for Lenny

2008-07-08 Thread Pierre Habouzit
On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote:
 On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote:
  On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote:
   On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:
* Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]:
 Changing kernel at this point of the release would be too destructive,
 so unless there is a big fat problem in the .25 that the .26 should 
 fix
 and is unbackportable (does such a beast even exist ?) I'm rather
 opposed to it. Note that the asm/page.h mess is still not fixed thanks
 to hppa.
 
 Disclaimer: it's my own opinion, I did not check what other Release 
 Team
 member think about this.

I agree with you, at least with my current informations.
   
   please read the changelog trunk on all the 2.6.26 fixes.
  
Huh, that's not really our work, you as the maintainer should help us
  understand why we would like to deal with 3 months of FTBFS *right now*.
  Not to mention the libata changes fjp talks about, that would probably
  break many upgrades and for which there is no known solution.
 
 right so the 2.6.26 summary:
 * closes 50 bugs on upload (mostly 2.6.25 regressions)

  I'm really afraid with the number of bugs it'll open though.

 * has upstream coordination with xen and openvz

  Does this mean that dom0 will work with .26 ? If yes, then maybe .26
is really worth considering. If not, this is quite moot.

 * is the first version with kernel debugger
 * much better laptop support (wireless, uvc,..)
 * kvm ported to IA64, PPC and S390

   we have allways stated that .26 will be the release kernel.
  
The sole mail from the kernel team that I can find is[0]. We've seen
  no updates from you since AFAICT. Given the content of the mail, and its
  age, I don't see how we can know that.
 
 right to debian-release that was the last time we got asked to give a
 statement. in discussion on d-kernel and with d-boot we allways stated
 to work on 2.6.26 for Lenny.

  Well, we did asked for updates from core teams in our mails to d-d-a
numerous times without our prior nagging, which was clearly meant to
avoid this kind of communication issues.

  For the rest I assume the release team will have to discuss things a
bit further.

[1] e.g. have you done full scale archive rebuilds to show that a new
linux-libc-dev won't at least cause dozens of FTBFS like the
2.6.25 did ?
 
 there are statements from waldi and vorlon to consider the 2.6.25
 linux-libc-dev status as frozen.

  Well, that's a sine qua non condition. L-L-Dev breakages are horrible,
and we just cannot aford one. It does not mean that I consider .26 to be
a clever idea right now, but a l-l-d breakage would be a plain no-go.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp25s3AHL4sy.pgp
Description: PGP signature


Re: Selection of kernel for Lenny

2008-07-07 Thread Pierre Habouzit
On Mon, Jul 07, 2008 at 04:19:01PM +, Aurelien Jarno wrote:
 Frans Pop a écrit :
  Se IMO we should take a real good look at .25 and .26 and check what's 
  new, what's important for Lenny and what's risky, and maybe check if some 
  things we do want could be backported.
 
 As the release team is Cc:ed, I just want to make sure it is aware that
 switching to 2.6.26 possibly means changes to userland, and thus freeze
 exceptions. A few examples:
 
 - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to
 removed headers. Change have been needed in various packages including
 glibc.
 - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently
 FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know
 yet which change causes the problem, I am down to a 600 lines diff.
 - I have recently uploaded a new version of lm-sensors needed to support
 2.6.26 kernels.
 
 That said I neither opposed nor in favor of a switch to 2.6.26, I just
 want to emphasize that it can have a bigger impact than expected on the
 release planning.

Changing kernel at this point of the release would be too destructive,
so unless there is a big fat problem in the .25 that the .26 should fix
and is unbackportable (does such a beast even exist ?) I'm rather
opposed to it. Note that the asm/page.h mess is still not fixed thanks
to hppa.

Disclaimer: it's my own opinion, I did not check what other Release Team
member think about this.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpW6qRtyhIbh.pgp
Description: PGP signature


Re: Testing removal policy (was: Mechanism in place...)

2008-06-29 Thread Pierre Habouzit
On Sun, Jun 29, 2008 at 07:51:59PM +, Frans Pop wrote:
 On Friday 27 June 2008, Pierre Habouzit wrote:
  Well, the thing is, we have quite a clear policy, which is to remove
  (not in period of a freeze of course) packages that are:
    * leaf packages ;
    * RC buggy ;
    * for more than 20 days ;
    * with absolutely no movement from the maintainer.
 
 But that is not what you are doing!

  It is what I am doing at least.

 Let's take resolvconf as example (rather randomly: just because it was 
 mentioned on d-devel).
 - It is listed at rank ~2200 in popcon's installed, but at 854 in the
   vote column, which means it is a rather popular package. It may
   _technically_ be a leaf package, but it is obviously an important
   package to *our users*.
 - Another reason this is not just any leaf package is that it is
   referenced in the bind9 postinst script (or is bind9 an unimportant
   leaf package too?).
 - The RC bug that caused the removal (#477752) was filed on 25 Apr and it
   was fixed in VCS *the next day*, and tagged pending. How the hell does
   that qualify as absolutely no movement from the maintainer?
 - IMO the RC bug in itself, although technically RC, does not affect the
   usability of the package sufficiently to justify removal from testing.

  I'm not the one that removed the package, and I don't know the
rationale behind this removal.

 IMO a responsible Release Manager would have sent a friendly reminder to 
 the maintainers to please upload the pending fix. My guess is however 
 that the RM never even looked at the BR, but just blindly ran some
 remove buggy packages from testing script.

  This is what I do when I've seen movement from the maintainer, which
is something that tag + pending qualifies for, you can easily find
examples of that, but thanks for the flame anyways.

 I also feel the current removal policy is counter-productive. Why? Because 
 it _reduces_ the visibility of RC bugs rather than increasing it. Only 
 very few people get informed of which particular packages are removed 
 from testing, and the relevant bugs then drop of lists that active bug 
 squashers use to select issues to work on.
 
 IMO Steve's suggestion makes a huge amount of sense because his proposal 
 would actually raise awareness of RC issues that need help. It's a huge 
 pity that you just reject it out of hand.

  Please, the RC bug list is trivial to find, I've posted it a lot of
time already, and there are tools to at least find the list of RC bugs
that:
  * are not fixed in unstable (because we don't remove if it's fixed in
unstable) ;
  * are more than 20 days old ;
  * are RC.

  This list is roughly 120 bugs long, and it's available to anyone[0].
I'm sure it's fairly trivial to intersect this list with a leaf packages
list, and here it is. Knock yourself out.

 I'm very grateful to Adeodato for the work he's done on getting the do 
 not remove functionality implemented, but it is extremely sad that that 
 functionality is needed at all. IMO the fact that it _is_ needed says a 
 lot about the quality of the current release management effort.

  You're sad that we don't (in the release team) know every single
internal piece of d-i ? Well too bad then. I'm glad we have this in
place because now I don't have to worry about a mistake. But I assume
it's easier to be the jerk in the conversation, and completely overlook
the huge task that is doing a good job in the release team. Everyone
expect us to know every single bit of anything that makes Debian works,
and heellooo we don't, because no one humanly can. So we need help. And
yes, the fact that we develop these tools says a lot about the release
management: we care.


On Fri, Jun 27, 2008 at 08:31:24PM +, Joey Hess wrote:
 Another case is NTP, which was kicked out of testing for a
 licensing bug, causing much grief to be reported on debian-user.

  FWIW I was the one asking the removal: upstream has a fix that is
backportable, not trivially, but that is. And there is openntpd that is
a drop in replacement for most desktop users (and I assume that testing
users aren't really servers, that would need the additionnal features
ntp provides and openntpd has not). Here is my rationale.


  Again, like I proposed it before, I'm ready to work with people who
care about testing usability and can focus on bugs that hinder the
release. So far, lot of noise has been made, and the sole new help I've
seen came from lucas.


  [0] 
http://bts.turmzimmer.net/details.php?bydist=bothsortby=srcpackagesignhinted=onignclaimed=onignnew=onignmerged=onignnonfree=onignbritney=onignotherfixed=onnew=20refresh=1800


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpfDJMgQo3CS.pgp
Description: PGP signature


Re: Mechanism in place to prevent some packages from being removed from testing

2008-06-27 Thread Pierre Habouzit
On Wed, Jun 25, 2008 at 01:05:26PM +, Steve McIntyre wrote:
 On Wed, Jun 25, 2008 at 02:51:52PM +0200, Adeodato Simó wrote:
 
 details of tasksel-related checking
 
 Thanks for this, much appreciated. I've been pondering too on this
 issue, wondering if we could/should give more warning to (all) qDDs
 about upcoming removals. Would it be useful / possible to have a
 weekly summary mailed to debian-devel listing packages that are marked
 for possible removal, giving (maybe) 2 weeks notice? That way
 maintainers and DDs get more warning about removals of packages that
 they care about, and a countdown. It *might* push maintainers a little
 more to get fixes uploaded. There's a little naming-and-shaming here,
 which could make the difference.

  Well, the thing is, we have quite a clear policy, which is to remove
(not in period of a freeze of course) packages that are:
  * leaf packages ;
  * RC buggy ;
  * for more than 20 days ;
  * with absolutely no movement from the maintainer.
With that anyone interested in providing such a list can do it.

  If we also add a 15 days warning, then the maintainer should get a
warning at day 5, which is overkill. And packages where the maintainer
didn't manage to answer to an RC bug report in 20 days is a package
where it's really unlikely to see this evolve with what you ask, because
they won't read it more. Lucas already sends montly mails about RC bugs.
I don't think it change things for a minute.

  Like I said numerous time when we discussed this issue, I prefer to be
there and ready to help people that fixed a package make it enter back
into testing if the migration isn't trivial, with all the hints that are
needed.


  Note that less than a week after having been removed, mplayer and lilo
have been fixed. It's fun to see how easy it is to fix unsolvable bugs
with the proper incentive.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpSMThXeOUwZ.pgp
Description: PGP signature


Re: klibc 1.5.10

2008-06-16 Thread Pierre Habouzit
On Mon, Jun 16, 2008 at 12:42:36AM +, maximilian attems wrote:
 hello,
 
 please unblock klibc 1.5.10-1

done

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpr4Prc8AVTd.pgp
Description: PGP signature


Re: Testing transition for console-setup 1.24

2008-06-16 Thread Pierre Habouzit
On Sun, Jun 15, 2008 at 06:02:16PM +, Christian Perrier wrote:
 console-setup is currently frozen because it provides a udeb.
Done



-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp5C8zrhtrZM.pgp
Description: PGP signature


Re: Please unfreeze openssh 1:4.7p1-12

2008-06-08 Thread Pierre Habouzit
On Sun, Jun 08, 2008 at 04:30:25PM +, Colin Watson wrote:
 openssh (1:4.7p1-9 to 1:4.7p1-12)
 Maintainer: Debian OpenSSH Maintainers
 Too young, only 9 of 10 days old
 Not touching package, as requested by freeze (contact debian-release if 
 update is needed)
 Not considered
 
 Could you please unfreeze this? The updates are mostly a long series of
 fairly minor adjustments following the recent OpenSSL security update
 mitigation work.
 
 CCing debian-boot since this contains udebs so requires a d-i RM ack.

  I think there is a D-I beta release pending so it'll remain blocked
until d-boot acks it.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgphuM2vkzCJW.pgp
Description: PGP signature


Re: Hints for Debian Installer related packages

2008-02-09 Thread Pierre Habouzit
On Sat, Feb 09, 2008 at 03:58:46AM +, Otavio Salvador wrote:
 Hello RM team and Jeroen,
 
 RM team, please add a block for etch-support source package and add
 following hints:
 
 unblock console-data/2:1.05-1
 unblock e2fsprogs/1.40.5-2
 unblock nbd/1:2.9.9-6
 unblock xfsprogs/2.9.5-1

  done

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpG6EViQClnv.pgp
Description: PGP signature


Re: Please unblock directfb/1.0.1-6

2008-02-03 Thread Pierre Habouzit
On Sun, Feb 03, 2008 at 11:06:13PM +, Otavio Salvador wrote:
 Guillem Jover [EMAIL PROTECTED] writes:
 
  Hi,
 
  Please unblock directfb/1.0.1-6. The sparc binaries are still missing,
  though.
 
 No objection

done

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgph4a3Qzktau.pgp
Description: PGP signature


Re: Please unblock cdebootstrap

2008-01-26 Thread Pierre Habouzit
On Sat, Jan 26, 2008 at 01:02:15PM +, Otavio Salvador wrote:
 Bastian Blank [EMAIL PROTECTED] writes:
 
  Hi
 
  Please unblock cdebootstrap/0.4.4.
 
 No objection.

done
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp8paWAxtJow.pgp
Description: PGP signature


Re: hints for udeb

2008-01-26 Thread Pierre Habouzit
On Sat, Jan 26, 2008 at 12:15:18PM +, Otavio Salvador wrote:
 Hello RM team,
 
 Please add following hints:
 
 unblock mdadm/2.6.4-1
done

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpD11loTYm6C.pgp
Description: PGP signature


Re: hints for debian installer related packages

2008-01-24 Thread Pierre Habouzit
On Wed, Jan 23, 2008 at 07:15:46PM +, Otavio Salvador wrote:
 Hello,
 
 I'd like to ask for following hints to be added:
 
 urgent debootstrap/1.0.8
 unblock debootstrap/1.0.8
 unblock installation-report/2.31
 unblock libaio/0.3.106-8
 unblock multipath-tools/0.4.8-7
 unblock user-setup/1.17
done.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp2Xwi0oFy5v.pgp
Description: PGP signature


Re: removal of svenl from the project

2006-03-15 Thread Pierre Habouzit
Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit :
 Hi,

 I am going through the expulsion process to have Sven Luther removed
 from the project.  The process is outlined here:
 http://lists.debian.org/debian-devel-announce/2005/08/msg5.html
, and I have already completed step 1.

I strongly oppose to such an expulsion.

what is wrong with you ? are you gone completely insane or what ?

I know Sven may sometimes be a bit overpresent in some trolls, he also 
may answer too quick, without having read the mail he answers to 
correctly enough. But AFAICT, I've always seen him apologies when he 
did so (I can provide links if you can't believe me…).

If you want to expulse any DD that taunts a release manager, a 
ftp-master or a debian sys-admin, hey, please begin with the recent 
thread about the NEW queue beeing stuck again. There is a lot of DDs 
that need you to rule about them.


The project is really going insane.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpyGpPRRghdD.pgp
Description: PGP signature


Re: removal of svenl from the project

2006-03-15 Thread Pierre Habouzit
Le Mer 15 Mars 2006 15:05, Andres Salomon a écrit :
 On Wed, 2006-03-15 at 11:25 +0100, Pierre Habouzit wrote:
  Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit :
   Hi,
  
   I am going through the expulsion process to have Sven Luther
   removed from the project.  The process is outlined here:
   http://lists.debian.org/debian-devel-announce/2005/08/msg5.h
  tml , and I have already completed step 1.
 
  I strongly oppose to such an expulsion.

 It amazes me that people oppose expulsion, but are perfectly happy to
 allow the DAMs to decide whether or not a NM is to be let into the
 project.  Why do we trust the DAM's judgement in one scenario but not
 the other?

  what is wrong with you ? are you gone completely insane or what ?

 I'm tired of discussions immediately degrading into personal insults.

just so that we are clear, I consider your first mail a personal insult 
already, especially given that your decision is based on irc logs.

Using the irc logs of a pissed person for the ground of an expulsion 
process is either (I'll let you choose):
 * a complete lack of dignity ;
 * the result of a fascist mind (so that I can win my Godwin point) ;
 * that you are a saint, since you feel comfortable with blaming people
   that release pressure on IRC.

sarcasm
oh and btw, as you noted it, I attacked you personnaly, maybe you should 
begin a procedure to expulse me.
/sarcasm

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpv3p8SA8Y4u.pgp
Description: PGP signature