Making "auto decruft" easier for us and the release team

[Alexander Reichle-Schmehl]

Hi!

I think that the decrufting of our archive is done rather suboptimal for 
both of us, the ftp-team as well as the release-team.  I'm not yet sure, 
how things can be done easier, so I guess the best thing to start 
discussing it, is describing how things are don currently.



So, what is this decrufting thing?  From our point of view, it's keeping 
the archive clean.  Let's image a source package foo 1.0-1 builds a 
binary package libfoo1-dev and libfoo1.  The binary packages then get 
renamed to libfoo2-dev and libfoo2.  When the new package 2.0-1 is 
uploaded to unstable, the ftp-team get's a mail, telling us, something 
similar to the following:



==
* source package foo version 2.0-1 no longer builds
  binary package(s): libfoo1, libfoo1-dev
  on 
  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by foo)" -s unstable 
-a  -p -R -b libfoo1 libfoo1-dev

==

When some ftp member reads that mail (and has time and dinstall isn't 
running), he can try that command.  Sometimes the dependency checks 
don't find any packages (build-)depending on the gone packages, they get 
removed and everyone is happy.



The problems arise, when there are still some packages (build-)depending 
on the binary packages to be removed.  I guess the correct thing for 
broken build-depends is to fill RC bugs against the affected packages, 
as they are (defacto) FTBFS.


The broken depends however are a bit trickier (and now the release team 
get's involved).


Currently, I
a) request binnmus for the packages, if I think that the problem will be 
solved by that.  So far the release team (Hi Adam!) acted quite quick on 
them, the dependencies where gone, and a couple of dinstalls later, I 
could remove the obsolete binary packages.  The cruft is gone, everyone 
is happy.
b) Ignore the decruft requests, when I already know that the release 
team is aware of the transition (e.g. libao2).  As I do that by memory, 
I might be wrong about that.
c) Ignore the decruft request, if it's to complicate to understand the 
problem (and the solution) within a short time frame, and try to hope 
that it is gone, after the next dinstall run.  (I do that, when I do 
some ftp work to fill the time till the next meeting ;)


I confess that "solutions" b) and c) are suboptimal, as they leave cruft 
in the archive and preventing packages from migrating to testing.  See 
today's irc log from #debian-release for example:
libimobiledevice droped libimobiledevice0, some packages depend in it. 
I requested some binnmus to solve that, but forgot one package in my 
binnmus bug report.  And as I remembered, that I did request binnmus for 
that problem, I ignored the decruft request and neither did asked for 
the correct binmu, nor did the removal of the obsolete package.



So, how to we get things done easier?  I think we need some easier way 
to tell the release team, what decruft stuff is currently pending due to 
some broken packages, so that they can request the correct binnmus (or 
ignore them, to avoid getting ongoing transitions tangled together), or 
even tell us to ignore them, as it only affects unrelated architectures.




For reference, currently the pending auto-cruft removals are:

* source package clalsadrv version 2.0.0-2 no longer builds
  binary package(s): libclalsadrv1
  on 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,s390,sparc

  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by clalsadrv)" -s 
unstable -a 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,s390,sparc 
-p -R -b libclalsadrv1


# Broken Depends:
aeolus: aeolus [mipsel]
ams: ams [alpha]
jaaa: jaaa [amd64 mipsel]
japa: japa [amd64 mipsel]


* source package gcc-4.1 version 4.1.2-29 no longer builds
  binary package(s): g++-4.1 libmudflap0-dev libstdc++6-4.1-dbg 
libstdc++6-4.1-dev libstdc++6-4.1-pic
  on 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,powerpc,s390,sparc

  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by gcc-4.1)" -s 
unstable -a 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,powerpc,s390,sparc 
-p -R -b g++-4.1 libmudflap0-dev libstdc++6-4.1-dbg libstdc++6-4.1-dev 
libstdc++6-4.1-pic


# Broken Depends:
libgenome: libgenome-1.3-0-dev
pinball: pinball-dev

# Broken Build-Depends:
omniorb4: g++-4.1


* source package gjs version 0.6-1 no longer builds
  binary package(s): libgjs0
  on 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,powerpc,s390,sparc

  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by gjs)" -s unstable 
-a 
alpha,amd64,armel,hppa,hurd-i386,i386,ia64,kfreebsd-amd64,kfreebsd-i386,mips,powerpc,s390,sparc 
-p -R -b libgjs0


# Broken Depends:
gnome-shell: gnome-shell


* source package kfreebsd-7 version 7.3-1 no longer builds
  binary package(s): kf

Bug#578744: nmu: eclipse_3.5.2-2

[Niels Thykier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
User: release.debian@packages.debian.org
Usertags: binnmu

  nmu eclipse_3.5.2-2 . ALL . -m "Rebuild against sat4j to pick up new location 
of sat4j."

Hi

sat4j moved its jar files in 2.1.1-3, since eclipse records the location at 
build time,
we need a rebuild of eclipse-platform to get the new locations recorded.

~Niels

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20100422124845.4673.5279.report...@getsu.thykier.net

Re: Making "auto decruft" easier for us and the release team

[Torsten Werner]

Hi,

Alexander Reichle-Schmehl schrieb:
> The problems arise, when there are still some packages (build-)depending
> on the binary packages to be removed.  I guess the correct thing for
> broken build-depends is to fill RC bugs against the affected packages,
> as they are (defacto) FTBFS.

I've given up on filing bug reports because they got closed without
fixing the problem.

> So, I'm open for ideas how to improve the "workflow" and making it
> easier for the release team and us (especially for me ;)

We could add an option --verbose to cruft-report that actually runs the
suggested commands with the --no-action option added (but only if the
command is actually doing an rdep check). Everyone could see the details
at  as soon as we
enable --verbose for the dinstall run. The release team may schedule
binNMUs as needed.

Cheers,
Torsten


-- 
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/4bd06328.2030...@debian.org

Pushing the iPhone/iPod stack into Squeeze

[Julien BLACHE]

Hi,

It looks like the iPhone/iPod stack will need some hints to make it to
Squeeze. The stack comprises libplist, libimobiledevice, ifuse and
usbmuxd.

Currently the blocker seems to be libimobiledevice; it looks like a hint
is needed as libiphone needs to be replaced by libimobiledevice in
Squeeze (it's been renamed, obvious reasons...).

What should have been a seamless and entirely self-contained transition
fell victim to portability issues in libplist, a rogue upload of a newer
libimobiledevice version complete with a soname bump and GNOME packages
starting to use the stack while we weren't looking. As a consequence,
GNOME now depends on the stack, so it really badly needs to make it to
Squeeze.

If the RT can look into this, I'll help coordinate any further actions
required to get things into shape.

Thanks,

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/877hnzfpnp@sonic.technologeek.org

Re: Pushing the iPhone/iPod stack into Squeeze

[Josselin Mouette]

Le jeudi 22 avril 2010 à 17:55 +0200, Julien BLACHE a écrit : 
> What should have been a seamless and entirely self-contained transition
> fell victim to portability issues in libplist, a rogue upload of a newer
> libimobiledevice version complete with a soname bump and GNOME packages
> starting to use the stack while we weren't looking. As a consequence,
> GNOME now depends on the stack, so it really badly needs to make it to
> Squeeze.

As far as GNOME is concerned, only gvfs is affected, and it should not
be a blocker for any of the other planned transitions. 

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: Pushing the iPhone/iPod stack into Squeeze

[Adam D. Barratt]

Hi,

On Thu, 2010-04-22 at 17:55 +0200, Julien BLACHE wrote:
> It looks like the iPhone/iPod stack will need some hints to make it to
> Squeeze. The stack comprises libplist, libimobiledevice, ifuse and
> usbmuxd.

usbmuxd has already transitioned, fwiw.

> Currently the blocker seems to be libimobiledevice; it looks like a hint
> is needed as libiphone needs to be replaced by libimobiledevice in
> Squeeze (it's been renamed, obvious reasons...).

A more immediate issue is the libimobiledevice{0,1} rename.
libimobiledevice0 needs decrufting, which can't currently occur as
ipheth still depends on the old library.  BinNMUs for that were
scheduled earlier today and a quick test run suggests that a simple hint
should be all that's needed once those are available.

Regards,

Adam


--
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/1271958001.32043.164.ca...@kaa.jungle.aubergine.my-net-space.net

Re: Pushing the iPhone/iPod stack into Squeeze

[Julien BLACHE]

"Adam D. Barratt"  wrote:

Hi,

> usbmuxd has already transitioned, fwiw.

Yes, it's low enough in the stack that it wasn't affected by the
libplist issues.

> A more immediate issue is the libimobiledevice{0,1} rename.
> libimobiledevice0 needs decrufting, which can't currently occur as
> ipheth still depends on the old library.  BinNMUs for that were

ipheth is not in testing yet, so I did not mention it here. Thanks for
the binNMU.

> scheduled earlier today and a quick test run suggests that a simple hint
> should be all that's needed once those are available.

Looks like that'll do, indeed. Thanks!

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/8739ynfk3f@sonic.technologeek.org

Bug#577777: marked as done (RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3)

[Debian Bug Tracking System]

Your message dated Thu, 22 Apr 2010 20:35:14 +0100
with message-id 
<1271964914.32043.1549.ca...@kaa.jungle.aubergine.my-net-space.net>
and subject line Re: Processed: Removal request for apq-postgresql (testing)
has caused the Debian Bug report #57,
regarding RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3
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.)


-- 
57: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=57
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: apq-postgresql
Version: 3.0~b1-1
Severity: normal

I am filing this bug pursuant to
http://wiki.debian.org/ftpmaster_Removals before asking for the
removal myself.

The packages apq-postgresql and apq in testing block the removal of
gnat-4.3 (#573022) from testing.

The version of apq-postgresql in unstable has one release-critical
bug (#570887) with a known, easy fix but no upload in sight.

If you think you will not have time to upload a fix for the RC bug,
please ask that apq and apq-postgresql be removed from testing.  This
will not affect the packages in unstable but will allow the removal
of gnat-4.3 and thereby close 3 release-critical bugs open against
gnat-4.3.

If you agree with the removal from testing, please send a mail to
cont...@bugs.debian.org with the following commands:

retitle X RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3
reassign X release.debian.org
user release.debian@packages.debian.org
usertags X rm
clone X -1
retitle -1 RM: apq (testing); RoM; blocks removal of gnat-4.3
usertags -1 rm
thanks

replacing X with the number of this bug.

-- 
Ludovic Brenta.




--- End Message ---
--- Begin Message ---
Hi,

On Wed, 2010-04-14 at 16:12 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > retitle 57 RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3
> Bug #57 [apq-postgresql] Please remove apq-postgresql and apq from 
> testing (RC bugs)
> Changed Bug title to 'RM: apq-postgresql (testing); RoM; blocks removal of 
> gnat-4.3' from 'Please remove apq-postgresql and apq from testing (RC bugs)'
[...]
> > retitle -1 RM: apq (testing); RoM; blocks removal of gnat-4.3
> Bug #577791 [release.debian.org] RM: apq-postgresql (testing); RoM; blocks 
> removal of gnat-4.3
> Changed Bug title to 'RM: apq (testing); RoM; blocks removal of gnat-4.3' 
> from 'RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3'

When you reassign bugs like this, it's often helpful to mail the
receiving maintainer as well; otherwise all they get is the result of
the control@ mail, which can often get lost amongst other mails.

In this case, apq and apq-postgresql have now migrated and gnat-4.3 is
no longer in testing.  I'm therefore closing both bugs.

Regards,

Adam

--- End Message ---

Bug#577791: marked as done (RM: apq (testing); RoM; blocks removal of gnat-4.3)

[Debian Bug Tracking System]

Your message dated Thu, 22 Apr 2010 20:35:14 +0100
with message-id 
<1271964914.32043.1549.ca...@kaa.jungle.aubergine.my-net-space.net>
and subject line Re: Processed: Removal request for apq-postgresql (testing)
has caused the Debian Bug report #577791,
regarding RM: apq (testing); RoM; blocks removal of gnat-4.3
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.)


-- 
577791: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577791
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: apq-postgresql
Version: 3.0~b1-1
Severity: normal

I am filing this bug pursuant to
http://wiki.debian.org/ftpmaster_Removals before asking for the
removal myself.

The packages apq-postgresql and apq in testing block the removal of
gnat-4.3 (#573022) from testing.

The version of apq-postgresql in unstable has one release-critical
bug (#570887) with a known, easy fix but no upload in sight.

If you think you will not have time to upload a fix for the RC bug,
please ask that apq and apq-postgresql be removed from testing.  This
will not affect the packages in unstable but will allow the removal
of gnat-4.3 and thereby close 3 release-critical bugs open against
gnat-4.3.

If you agree with the removal from testing, please send a mail to
cont...@bugs.debian.org with the following commands:

retitle X RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3
reassign X release.debian.org
user release.debian@packages.debian.org
usertags X rm
clone X -1
retitle -1 RM: apq (testing); RoM; blocks removal of gnat-4.3
usertags -1 rm
thanks

replacing X with the number of this bug.

-- 
Ludovic Brenta.




--- End Message ---
--- Begin Message ---
Hi,

On Wed, 2010-04-14 at 16:12 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > retitle 57 RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3
> Bug #57 [apq-postgresql] Please remove apq-postgresql and apq from 
> testing (RC bugs)
> Changed Bug title to 'RM: apq-postgresql (testing); RoM; blocks removal of 
> gnat-4.3' from 'Please remove apq-postgresql and apq from testing (RC bugs)'
[...]
> > retitle -1 RM: apq (testing); RoM; blocks removal of gnat-4.3
> Bug #577791 [release.debian.org] RM: apq-postgresql (testing); RoM; blocks 
> removal of gnat-4.3
> Changed Bug title to 'RM: apq (testing); RoM; blocks removal of gnat-4.3' 
> from 'RM: apq-postgresql (testing); RoM; blocks removal of gnat-4.3'

When you reassign bugs like this, it's often helpful to mail the
receiving maintainer as well; otherwise all they get is the result of
the control@ mail, which can often get lost amongst other mails.

In this case, apq and apq-postgresql have now migrated and gnat-4.3 is
no longer in testing.  I'm therefore closing both bugs.

Regards,

Adam

--- End Message ---

NEW changes in proposedupdates

[Archive Administrator]

Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_alpha.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_amd64.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_armel.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_hppa.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_i386.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_mips.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_mipsel.changes
  ACCEPT
Processing changes file: apache2-mpm-itk_2.2.6-02-1+lenny3+b1_powerpc.changes
  ACCEPT


-- 
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/e1o52rs-0001pd...@ries.debian.org