Bug#565343: RM: bluez-gnome/testing-proposed-updates -- RORM; obsolete

[Luk Claes]

Package: ftp.debian.org
Severity: normal

Hi

Please remove this package from testing-proposed-updates as it interferes with 
the removal from the package from testing.

Cheers

Luk



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

Re: Bug#558412: binutils-dev: Please provide libbfd_pic.a

[Luk Claes]

Roberto C. Sanchez wrote:
> This did not seem to get any attention on debian-devel, so I am cross
> posting to debian-release.  I would really be interested to know if
> others think that the binNMU approach suggested by Matthias is
> acceptable and/or viable.

Unless it's an option to include oprofile into binutils source package,
I don't see what's wrong with the binNMU approach?

Cheers

Luk

> Roberto C. Sanchez wrote:
>> Matthias Klose wrote:
>>> tags 558412 + wontfix
>>> thanks
>>>
>>> On 28.11.2009 19:10, Roberto C. Sanchez wrote:
 Package: binutils-dev
 Version: 2.18.1~cvs20080103-7
 Severity: normal

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 In order to solve #537744 (filed against oprofile), it is necessary for
 binutils-dev to provide a libbfd_pic.a library.  This is like what is
 already done for libiberity_pic.a.
>>> won't fix. oprofile can be built using binary NMU's when the bfd version
>>> changes.
>> I am not sure that is really a viable solution.  What do others thing?
>> Is requiring a binNMU of oprofile each time that the bfd version changes
>> something that makes sense?
>>
>> Regards,
>>
>> -Roberto
>>
> 
> 


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

Re: Uploading linux-2.6

[Luk Claes]

Ben Hutchings wrote:
> There have been 2 upstream stable updates and one more (2.6.32.6) is due
> early this week.  As usual, these include some security fixes.
> Therefore I propose to upload with the changes from 2.6.32.6 once that's
> released.
> 
> (Still no stable ABI, sorry.)

If the ABI changed the package name will change, right? Will it become
trunk2?

Cheers

Luk


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

Re: Uploading linux-2.6

[Luk Claes]

Philipp Kern wrote:
> On Mon, Jan 25, 2010 at 11:48:04AM +0100, maximilian attems wrote:
>> On Mon, 25 Jan 2010, Luk Claes wrote:
>>> Ben Hutchings wrote:
>>>> There have been 2 upstream stable updates and one more (2.6.32.6) is due
>>>> early this week.  As usual, these include some security fixes.
>>>> Therefore I propose to upload with the changes from 2.6.32.6 once that's
>>>> released.
>>>>
>>>> (Still no stable ABI, sorry.)
>>> If the ABI changed the package name will change, right? Will it become
>>> trunk2?
>> no, trunk has no ABI guarantee.
>> you can bet that each upload has a different one.
>> once libata is used and the configs all set we can go for stable
>> numbering.
> 
> Sorry, but your package is in testing now.  Please bump the ABI number in
> whatever why you want, but you should.

I guess this means that the next version is no candidate for the release
unless it gets a stable ABI (versioning) and should block the kernel
from migrating for the time being?

Cheers

Luk


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

Re: Uploading linux-2.6

[Luk Claes]

Julien Cristau wrote:
> On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote:
> 
>> I guess this means that the next version is no candidate for the release
>> unless it gets a stable ABI (versioning) and should block the kernel
>> from migrating for the time being?
>>
> The 2.6.30 kernel and the current 2.6.32 one aren't candidates either,
> so I'm not sure what difference blocking the next one makes.

As always, what reaches testing is a candidate for stable when no better
version comes along.

Cheers

Luk


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

Re: nmu: x11-utils_7.5+1

[Luk Claes]

Julien Cristau wrote:
> On Sat, Jan 23, 2010 at 03:13:00 +0100, Julien Cristau wrote:
> 
>> nmu x11-xserver-utils_7.5+1 . i386 . -m "Rebuild in a clean environment"
>>
>> x11-xserver-utils/i386 seems to have been built in an environment with
>> libxxf86misc and libxp installed, so has picked up extra deps.  This
>> non-determinism is a minor bug in the package, but in the mean time
>> could you schedule a rebuild?
>>
> Same issue with x11-utils...
> 
> nmu x11-utils_7.5+1 . i386 . -m "Rebuild in a clean environment"

Scheduled.

Cheers

Luk


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

Bug#564142: RM: rails/2.2.3-1

[Luk Claes]

Moritz Muehlenhoff wrote:
> On Fri, Jan 08, 2010 at 07:43:11AM +0100, Luk Claes wrote:
>> Moritz Muehlenhoff wrote:
>>
>>> Please remove rails. It has open security issues, which haven't been
>>> acknowledged for six weeks.
>> removal hint added.
> 
> It has a few rdeps, which prevent the removal:

Indeed, what is the plan? Did you contact these maintainers and do they
all agree with removal?

Cheers

Luk

> Checking reverse dependencies...
> # Broken Depends:
> activeldap: libactiveldap-ruby1.8
> camping: camping
> libbarby-ruby: libbarby-ruby1.8
> libfeedtools-ruby: libfeedtools-ruby1.8
> librqrcode-ruby: librqrcode-ruby1.8
>  librqrcode-ruby1.9
> libwill-paginate-ruby: libwill-paginate-ruby1.8
> redmine: redmine
> 
> Dependency problem found.
> 
> Cheers,
> Moritz




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

Re: Ongoing Python Transition: related FTBFSes

[Luk Claes]

Matthias Klose wrote:
> On 28.01.2010 12:50, Cyril Brulebois wrote:
>> Scott Kitterman  (17/12/2009):
>>> I believe that we are getting close to uploading Python 2.6 to
>>> Unstable and dropping Python 2.4 as a supported Python version.  If
>>> we finish preparations in the next week, are there any ongoing
>>> transitions a python2.6/python- defaults upload would entangle that
>>> would cause the release team to want the uploads to be delayed?
>>
>> Hi,
>>
>> I'm not sure it's the proper thread to mention this, but from a quick
>> look, it sounds like related.
>>
>> FWIW, here are some FTBFSes I've reported lately, which look due to
>> this transition:
>>#567226: pysvn
> 
> that's a wrong report, pycxx needs binNMUed, then the package does build.

pycxx is an Architecture: all package and cannot be binNMUed as such, so
a sourceful upload is required.

Cheers

Luk


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

Re: Please binNMU gnome-phone-manager against new gnome-bluetooth

[Luk Claes]

Bertrand Marc wrote:
> Hello,
> 
> A new version of gnome-bluetooth is in unstable since 2009-10-11, and
> since then gnome-phone-manager is not installable (see [1]).
> Could you binNMU gnome-phone-manager to make it depend on the new
> version of gnome-bluetooth ?
> 
> nmu gnome-phone-manager_0.65-1 . -m 'Rebuild against new gnome-bluetooth'

scheduled

Cheers

Luk


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

Re: Introducing symbol versioning in FFmpeg

[Luk Claes]

Reinhard Tartler wrote:
> On Mi, Jan 27, 2010 at 19:52:35 (CET), Adam D. Barratt wrote:
> 
>> On Wed, 2010-01-27 at 07:54 +, Adam D. Barratt wrote:
>>> http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to
>>> be the list of packages potentially needing binNMUs.
>>>
>>> Excluding those packages which have either had sourceful uploads in the
>>> past day or so (e.g. vtk) or have already scheduled or completed binNMUs
>>> for python2.6 (e.g. picard) would be useful to avoid duplicated work and
>>> builds.
>> The list has now been updated to remove those packages which have had
>> rebuilds since the ffmpeg upload or have outstanding python2.6 binNMUs
>> scheduled for them (and in one case to include a binNMU for one
>> architecture where the python2.6 binNMU completed shortly before ffmpeg
>> was available on that architecture).
> 
> I guess you are already on it: ffmpeg has transitioned now to testing,
> so the binNMUs can be scheduled now.

binNMUs are being scheduled.

Cheers

Luk


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

Re: Please binNMU tangerine and banshee against fixed libtaglib-cil-dev

[Luk Claes]

Jo Shields wrote:
> Hello,
> 
> There was a bug in libtaglib-cil-dev (= 2.0.3.4+dfsg-1) that made
> packages built against it Depends: libtaglib2.0-cil (>= 2.0.3.3) instead
> of 2.0.3.4. Only three packages are affected (and one needs a sourceful
> upload). Rebuilding against 2.0.3.4+dfsg-2 fixes this bug. As
> taglib-sharp is Arch:all, no dep-wait is needed for it.
> 
> nmu tangerine_0.3.2.2-2 . i386 s390 armel sparc powerpc amd64 . -m
> 'rebuild against libtaglib-cil-dev 2.0.3.4+dfsg-2'
> nmu banshee_1.5.3-1 . i386 s390 armel sparc powerpc amd64. -m 'rebuild
> against libtaglib-cil-dev 2.0.3.4+dfsg-2'

scheduled

Cheers

Luk


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

Re: Heimdal migration and libpam-heimdal

[Luk Claes]

Russ Allbery wrote:
> I've finished the work to take advantage of the new -multidev packages and
> build libpam-heimdal from the same source package as libpam-krb5, which
> I'd like to get done for squeeze.  However, while getting ready to upload,
> I see that Heimdal currently hasn't migrated to testing.
> 
> Is there a transition in progress that I would delay by uploading a new
> libpam-heimdal?  Should I hold off until that migration is complete?

Yes, please wait till heimdal migrates.

Cheers

Luk


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

Re: python-wxgtk2.6

[Luk Claes]

Ryan Niebur wrote:
> Could wxwidgets2.6 please migrate to testing?
> 
> It fixes a grave bug (completely uninstallable on squeeze) that was a
> result of the python2.6 binnmus.

age-days hint set.

Cheers

Luk


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

Re: Hints for Debian Installer

[Luk Claes]

Otavio Salvador wrote:
> Hello RM team,
> 
> We'll need another debian-installer build since powerpc is broken; then
> we can use this opportunity to fix those issues as well.
> 
> Here goes a set of hints related to d-i:
> 
> unblock bogl/0.1.18-3.1
> unblock choose-mirror/2.32 # please age this one, it lacks few builds
> unblock console-setup/1.51
> unblock gtk+2.0/2.18.6-1   # gtk in testing is already broken for d-i
> unblock localechooser/2.24 # please age this one

It's unblock-udeb, all hints scheduled.

> Move to auto-section:
> 
> localization-config

done

Cheers

Luk


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

Re: Bug#568163: claws-mail_3.7.4-1_mips failed to build on mayr

[Luk Claes]

Ricardo Mones wrote:
> On Tue, 02 Feb 2010 22:44:49 +0200
> Teodor MICU  wrote:

>> The package claws-mail_3.7.4-1 has failed to build on mips and the cause
>> seems to be the CHROOT, not the source code. Because of this the package
>> did not migrate to "testing":
>> * 24 days old (needed 10 days).
>>
>> Probably a rebuild should be scheduled by the release team.
> 
>   I think these reschedules are done by the buildd maintainer not by the
>   release team, but I may be wrong. Cc'ing release for clarification (no
>   need to Cc me back, I'm subscribed).

Yes, rebuilds because of buildd issues are done by the buildd maintainer
which you can contact via @buildd.d.o.

>   Anyway a new upstream version has been uploaded yesterday, so no action
>   should be required right now on claws-mail.

Ok, so not doing anything :-)

Cheers

Luk


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

Re: PHP5 transition

[Luk Claes]

Raphael Geissert wrote:
> Hello,
> 
> We, as in the PHP maintainers, would like to upload PHP 5.3 to unstable.
> 
> The upload requires that every package that ships a php extension be binNMUed 
> (this would normally be detected by packages becoming uninstallable because 
> the old phpapi- won't be provided, but see below).
> 
> I will be filing bug reports against packages shipping a php extension but 
> not 
> properly depending on phpapi-*. A lintian check will also follow.
> Packages building php extensions *must* depend on phpapi-* alone (some 
> packages depend on php5-* | phpapi-* which is incorrect too -- even the 
> packages from src:php5 started to do that, but will be fixed on the next 
> upload 
> too).
> 
> The packages have already been uploaded to experimental. Please let us know 
> when we can upload to unstable.

Go :-)

Cheers

Luk


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

Re: Objective Caml 3.11.2 in Debian

[Luk Claes]

Stéphane Glondu wrote:
> Stéphane Glondu a écrit :
>> I've recompiled (on amd64) all relevant packages with the release
>> candidate (announced last Dec 29), and all problems have been sorted
>> out. As far as I am concerned, I see no objections in starting the
>> transition.
>>
>> However, release managers might have objections, so let's hear their
>> opinion first.
> 
> Any thought from the release team?

Go :-)

Cheers

Luk


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

Re: gscan2pdf REMOVED from testing

[Luk Claes]

Jeffrey Ratcliffe wrote:
> On Tue, Feb 02, 2010 at 04:39:33PM +, Debian testing watch wrote:
>> FYI: The status of the gscan2pdf source package
>> in Debian's testing distribution has changed.
>>
>>   Previous version: 0.9.29-1
>>   Current version:  (not in testing)
>>   Hint: 
>> # done 2009-11-22
> 
> I don't understand why gscan2pdf was removed. The grave bug has been
> closed. Does anyone have any insight? Will v0.9.30-2 hit testing in
> its current state?

It was removed more than 2 months ago. The bug was only closed way later.

The current package should hit testing in about 7 days AFAICS.

Cheers

Luk


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

Re: BinNMU for libjpeg8 transition

[Luk Claes]

Bill Allombert wrote:
> On Fri, Feb 05, 2010 at 09:40:22PM +0100, Bill Allombert wrote:
>> On Mon, Feb 01, 2010 at 03:27:06PM +0100, Bill Allombert wrote:
>>> jpeg8 is now in testing and libterralib and sdop has been fixed already,
>>> so I would like to start the transition by uploading a version of
>>> libjpeg8-dev that provides libjpeg-dev.
>> Accordingly, and unless directed otherwise, I will upload a version of
>> libjpeg8-dev that provides libjpeg-dev on Sunday.
> 
> Done in version libjpeg8-dev 8-2.

What's the reason there is a conflict? Are they having common files or
do you just want them to not be coinstallable?

Is libjpeg8-dev really API incompatible or is it just nice to have
another name?

Cheers

Luk


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

Re: BinNMU for libjpeg8 transition

[Luk Claes]

Julien Cristau wrote:
> On Wed, Feb 10, 2010 at 23:08:41 +0100, Bill Allombert wrote:
> 
>> It is API compatible. As I said, I have rebuilt locally the 311 packages
>> that build-depends on libjpeg62-dev against libjpeg8-dev, so there is no
>> risk of API incompatibility.
>>
> Then they shouldn't have different names.

Indeed or put it differently: if you want to change the name of the
package, it should provide libjpeg62-dev instead of conflicting with it.

Cheers

Luk


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

Re: BinNMU for libjpeg8 transition

[Luk Claes]

Bill Allombert wrote:
> On Wed, Feb 10, 2010 at 11:54:18PM +0100, Luk Claes wrote:
>> Julien Cristau wrote:
>>> On Wed, Feb 10, 2010 at 23:08:41 +0100, Bill Allombert wrote:
>>>
>>>> It is API compatible. As I said, I have rebuilt locally the 311 packages
>>>> that build-depends on libjpeg62-dev against libjpeg8-dev, so there is no
>>>> risk of API incompatibility.
>>>>
>>> Then they shouldn't have different names.
> 
> They do not: libjpeg-dev was libjpeg62-dev and now it is libjpeg8-dev.
> The problem is that some packages Depends on libjpeg62-dev instead of
> libjpeg-dev as they should.
> 
> libjpeg62-dev need to be kept for LSB compatibility.

Can you point me to the section that points to that need?

>> Indeed or put it differently: if you want to change the name of the
>> package, it should provide libjpeg62-dev instead of conflicting with it.
> 
> I do not disagree, and I could for example rename libjpeg62-dev to
> libjpeg6b-dev and update the conflict.

I still fail to see why you want a conflict. Either it should be
coinstallable or there should only be one version of the package IMHO.

> However I was told essentially not to do that in
> <20090918230812.ga26...@artemis.corp>
> <http://lists.debian.org/debian-release/2009/09/msg00216.html>
> Pierre Habouzit wanted packages build-depending on libjpeg-dev to
> transition first. Unfortunately the wrong 'Depends: libjpeg62-dev'
> need to be fixed first. I have reported bugs to that effect.

Indeed, to avoid the current mess...

Cheers

Luk


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

Re: ghc6 still fails to build on ia64; what to do?

[Luk Claes]

Kari Pahula wrote:
> I've been trying out various linker flags on merulo and finally found
> ones that got ghc6 to build on ia64.  Unfortunately, that didn't still
> work on the ia64 buildd.

> Both stages pass successfully on merulo.  On the buildd, the build
> fails right at the start of stage 2 with a segfault.  I tested the
> compiler on merulo by building a stage 3 compiler (ie. ghc built with
> the stage 2 compiler) which seems to be a pretty strong indication
> that I have a working compiler.
> 
> The lack of ghc6 on ia64 has kept it from testing since 6.10.1.  I
> never got it built with a 6.10 compiler but seems like we're pretty
> close to getting there with 6.12.  Is it impossible that there's
> something wrong with the buildd?  Could I just upload the package that
> I built on merulo?  Any advice on this?

Yes, you can upload the package that builds on merulo as you obviously
tested it quite well.

It is possible thqt there is something wrong with the buildd, though it
would be good to see if the haskell packages compile ok with the
compiler you built on merulo, so please upload and we could try to
rebuild ghc6 on the buildd afterwards.

Cheers

Luk


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

Re: BinNMU for libjpeg8 transition

[Luk Claes]

Sven Joachim wrote:
> On 2010-02-11 19:38 +0100, Luk Claes wrote:
> 
>> Bill Allombert wrote:
>>> libjpeg62-dev need to be kept for LSB compatibility.
>> Can you point me to the section that points to that need?
> 
> http://refspecs.freestandards.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html#LIBJPEG
> 
> It's the same in LSB 4.0.

So libjpeg62 has to be remained, though libjpeg62-dev does not have to
stay and could be provided by libjpeg8-dev like I proposed from the start.

Cheers

Luk


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

Re: BinNMU for libjpeg8 transition

[Luk Claes]

Bill Allombert wrote:
> On Thu, Feb 11, 2010 at 08:00:18PM +0100, Luk Claes wrote:
>> Sven Joachim wrote:
>>> On 2010-02-11 19:38 +0100, Luk Claes wrote:
>>>
>>>> Bill Allombert wrote:
>>>>> libjpeg62-dev need to be kept for LSB compatibility.
>>>> Can you point me to the section that points to that need?
>>> http://refspecs.freestandards.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html#LIBJPEG
>>>
>>> It's the same in LSB 4.0.
>> So libjpeg62 has to be remained, though libjpeg62-dev does not have to
>> stay and could be provided by libjpeg8-dev like I proposed from the start.
> 
> libjpeg62-dev have to stay for *building* LSB package. 

Right, though if you want to have that, you should have been clear from
the start.

> But anyway this whole discussion is a distraction. The only real issue is
> whether we transition all package build-depending on libjpeg*-dev at once, or
> whether we transition first the one that build-depend on libjpeg-dev.

Nope, the real issue is that you apparently want to do a messy
transition even when the Release Team wants to avoid that.

> In the first case, I rename the current libjpeg62-dev to libjpeg6b-dev and 
> change libjpeg8-dev to provide libjpeg62-dev and conflict with libjpeg6b-dev.
> 
> In the second case, we have to fix all packages that _Depends_ on 
> libjpeg62-dev to depend on libjpeg-dev instead.
> 
> Following the instructions given in 
> <http://lists.debian.org/debian-release/2009/09/msg00216.html>
> I implemented the second solution, but I have no objection with
> implementing the first one if the release team change its mind.

Noone is changing their mind, though instead of a normal transition you
want to include a non coinstallable extra development package which is a
complete mess. Renaming even more packages is not going to make it any
less a mess.

The choice is either to make sure we have coinstallability or to drop
one development package IMHO.

Cheers

Luk


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

Re: Please binNMU dpm and dpm-postgres against updated globus-ftp-client

[Luk Claes]

Mattias Ellert wrote:
> Hi!
> 
> The new version of globus-ftp-client bumps the soname from 1 to 2. For
> this reason dpm and dpm-postgre needs to be rebuilt with the new
> version. The other packages depending on globus-ftp-client have been
> updated.
> 
> nmu dpm_1.7.4.1-3 . ALL . -m 'Rebuild against updated globus-ftp-client.'
> dw dpm_1.7.4.1-3 . ALL . -m 'libglobus-ftp-client-dev (>= 5.2-1)'
> nmu dpm-postgres_1.7.4.1-3 . ALL . -m 'Rebuild against updated 
> globus-ftp-client.'
> dw dpm-postgres_1.7.4.1-3 . ALL . -m 'libglobus-ftp-client-dev (>= 5.2-1)'

Scheduled.

Cheers

Luk


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

[VAC] Now -> Now + 1 month

[Luk Claes]

Hi

To get some rest and peace of mind I'm having a vacation for 1 month.

I'm confident that you will be working on getting closer to a freeze
even without me and would be very happy if we could freeze soon after I
return!

I'm also confident that the Release Team members can cope without my
presence. Please direct any release related issues to them in my absence
I'm confident they will figure out a nice way of solving them.

Cheers

Luk


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

Re: Tcl/Tk plans for Squeeze

[Luk Claes]

Francesco P. Lovergine wrote:

> Currently we have three different releases of Tcl/Tk: 8.3, 8.4 and 8.5
> with major differences among them (e.g. 8.3 is not thread-enabled, 8.5
> has a new theme-enabled Tk, etc.). A new pre-release version 8.6 
> is already in experimental, too.
> 
> This is a mess we need to reduce.

Very much agreed.

> Dropping 8.3 will require migrating old strict rev-dep packages 
> to the new policy and possibly patching for using a modern Tcl (default
> or 8.4 at least). Eventually, some packages will be dropped, because too 
> ancient.
> Let them to go.

What's the status of dropping 8.3 aka what still needs to be done to
make that happen?

Cheers

Luk


-- 
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/4b9bbbfc.6020...@debian.org

Priorities

[Luk Claes]

Hi

I'm back from vacation.

I would like to make sure we focus on the priorities to get Squeeze out.

>From a first look there are these things:

- stop accepting new transitions and (help to) coordinate the
outstanding ones
- focus on RC bug handling by coordinating the organisation of formal
and informal BSPs and possible other ways of getting the RC bug count lower
- call for more volunteers to get momentum and spread the load
- train volunteers in reviewing package updates and bug squashing

Are there other things people think of or comments, please share them.

Is anyone volunteering to take responsability for any of the tasks involved?

Cheers

Luk


-- 
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/4b9bbf04.10...@debian.org

Re: parted unblock, and upcoming transition

[Luk Claes]

Colin Watson wrote:
> Could parted 1.8.8.git.2009.07.19-6 be unblocked, please?  It's needed
> to smooth the path for parted 2.2 in the near future.

unblocked.

> Speaking of which, I would like to upload parted 2.2 to unstable (it's
> currently in experimental) once 1.8.8.git.2009.07.19-6 reaches testing.
> The reason to try to get this into squeeze is that without it we won't
> properly support "Advanced Format" (i.e. >512-byte logical sectors) hard
> drives, which are becoming increasingly common.  There is an ABI
> transition involved, among the following source packages (maintainers
> CCed):
> 
>   devicekit-disks
>   fatresize
>   gnu-fdisk
>   gparted
>   libvirt
>   partconf
>   partitioner
>   partitionmanager
>   partman-base
>   pyparted
>   qtparted
>   udisks
> 
> I believe that all of these are trivial matters of changing
> build-dependencies, with the exception of fatresize which needs a fix to
> its configure script as well (already done upstream); some of these
> packages already had appropriate or nearly-appropriate versions in
> experimental, last I checked.
> 
> We might want to let devicekit-disks/udisks get into testing first, but
> after that's done, would it be convenient to the release team and to the
> other maintainers CCed here to start this transition?  I can supervise
> it, upload the d-i parts and the QA-maintained qtparted directly, and
> file bugs with patches as necessary for the others.

Please do hold your upload for now. We'll come back to you when the
moment is right.

Cheers

Luk


-- 
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/4b9bd991.3020...@debian.org

I'm resigning as Release Manager

[Luk Claes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

It's time to stop thinking I would be able to keep working as Release
Manager in this climate, I hereby resign as Release Manager.

Cheers

Luk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkudF7AACgkQ5UTeB5t8Mo0KKwCfWrxGSnPLvG/EpYEAJcI9w6Ga
gooAn3n5QIJgXn53STFBi9zwWo+VCHSA
=Z2WP
-END PGP SIGNATURE-


-- 
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/4b9d17b0.4050...@debian.org

Re: libmikmod/stable on hppa version problem

[Luk Claes]

On 07/15/2010 10:04 PM, Adam D. Barratt wrote:
> Hi,
> 
> On Thu, 2010-07-15 at 21:04 +0200, Thijs Kinkhorst wrote:
>> We have run into a problem with libmikmod on stable-security in the most 
>> recent DSA. That was released with the version number 3.1.11-a-6+lenny1, 
>> following the usual scheme. However, as it seems hppa had a version that 
>> used 
>> the old binNMU numbering scheme: 3.1.11-a-6.0.1, which is considered newer:
>> http://packages.debian.org/lenny/libmikmod2
> 
> [also visible on http://release.debian.org/proposed-updates/stable.html
> fwiw]
> 
>> Is there a way that we can solve this for hppa, or is the only way out a new 
>> DSA update for all 12 archs with only change a new version number?
> 
> I've been trying to think of an answer that doesn't necessitate a
> complete rebuild, but haven't come up with one thus far.
> 
> Any solution that involves a sourceful upload will need to be rebuilt on
> all architectures.  I'm not sure if the security archive / buildd setup
> makes it possible to only attempt to build a package on a restricted set
> of architectures; even if it does, as soon as the package is accepted in
> to proposed-updates the remaining architectures will then be auto-built
> for stable.

I guess that only a manual build of a binNMU old scheme on hppa will
save you from having a sourceful upload and rebuilds on all
architectures. Probably the hppa buildd admins (in Cc) can help here?

Cheers

Luk


-- 
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/4c3f831c.70...@debian.org

Re: libmikmod/stable on hppa version problem

[Luk Claes]

On 07/15/2010 11:57 PM, dann frazier wrote:
> On Thu, Jul 15, 2010 at 11:52:28PM +0200, Luk Claes wrote:
>> On 07/15/2010 10:04 PM, Adam D. Barratt wrote:
>>> Hi,
>>>
>>> On Thu, 2010-07-15 at 21:04 +0200, Thijs Kinkhorst wrote:
>>>> We have run into a problem with libmikmod on stable-security in the most 
>>>> recent DSA. That was released with the version number 3.1.11-a-6+lenny1, 
>>>> following the usual scheme. However, as it seems hppa had a version that 
>>>> used 
>>>> the old binNMU numbering scheme: 3.1.11-a-6.0.1, which is considered newer:
>>>> http://packages.debian.org/lenny/libmikmod2
>>>
>>> [also visible on http://release.debian.org/proposed-updates/stable.html
>>> fwiw]
>>>
>>>> Is there a way that we can solve this for hppa, or is the only way out a 
>>>> new 
>>>> DSA update for all 12 archs with only change a new version number?
>>>
>>> I've been trying to think of an answer that doesn't necessitate a
>>> complete rebuild, but haven't come up with one thus far.
>>>
>>> Any solution that involves a sourceful upload will need to be rebuilt on
>>> all architectures.  I'm not sure if the security archive / buildd setup
>>> makes it possible to only attempt to build a package on a restricted set
>>> of architectures; even if it does, as soon as the package is accepted in
>>> to proposed-updates the remaining architectures will then be auto-built
>>> for stable.
>>
>> I guess that only a manual build of a binNMU old scheme on hppa will
>> save you from having a sourceful upload and rebuilds on all
>> architectures. Probably the hppa buildd admins (in Cc) can help here?
> 
> I can certainly do a build/upload if someone points me to the binNMU
> old scheme process :)

AFAIK, it's a matter of updating the changelog with an entry with the
appropriate version (3.1.11-a-6+lenny1.0.1) and building the binary package.

Cheers

Luk


-- 
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/4c3f8702.9060...@debian.org

Re: libmikmod/stable on hppa version problem

[Luk Claes]

On 07/16/2010 12:09 AM, Luk Claes wrote:
> On 07/15/2010 11:57 PM, dann frazier wrote:
>> On Thu, Jul 15, 2010 at 11:52:28PM +0200, Luk Claes wrote:
>>> On 07/15/2010 10:04 PM, Adam D. Barratt wrote:
>>>> Hi,
>>>>
>>>> On Thu, 2010-07-15 at 21:04 +0200, Thijs Kinkhorst wrote:
>>>>> We have run into a problem with libmikmod on stable-security in the most 
>>>>> recent DSA. That was released with the version number 3.1.11-a-6+lenny1, 
>>>>> following the usual scheme. However, as it seems hppa had a version that 
>>>>> used 
>>>>> the old binNMU numbering scheme: 3.1.11-a-6.0.1, which is considered 
>>>>> newer:
>>>>> http://packages.debian.org/lenny/libmikmod2
>>>>
>>>> [also visible on http://release.debian.org/proposed-updates/stable.html
>>>> fwiw]
>>>>
>>>>> Is there a way that we can solve this for hppa, or is the only way out a 
>>>>> new 
>>>>> DSA update for all 12 archs with only change a new version number?
>>>>
>>>> I've been trying to think of an answer that doesn't necessitate a
>>>> complete rebuild, but haven't come up with one thus far.
>>>>
>>>> Any solution that involves a sourceful upload will need to be rebuilt on
>>>> all architectures.  I'm not sure if the security archive / buildd setup
>>>> makes it possible to only attempt to build a package on a restricted set
>>>> of architectures; even if it does, as soon as the package is accepted in
>>>> to proposed-updates the remaining architectures will then be auto-built
>>>> for stable.
>>>
>>> I guess that only a manual build of a binNMU old scheme on hppa will
>>> save you from having a sourceful upload and rebuilds on all
>>> architectures. Probably the hppa buildd admins (in Cc) can help here?
>>
>> I can certainly do a build/upload if someone points me to the binNMU
>> old scheme process :)
> 
> AFAIK, it's a matter of updating the changelog with an entry with the
> appropriate version (3.1.11-a-6+lenny1.0.1) and building the binary package.

Oh, I replied too fast: The version should be higher than
3.1.11-a-6.0.1, but have the changes of 3.1.11-a-6+lenny1, so it is a
bit more tricky. You'll have to start from the package for
3.1.11-a-6+lenny1, but will have to add/update the version to
3.1.11-a-6.0.2 or something similar.

Cheers

Luk


-- 
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/4c3f87c5.3090...@debian.org

Re: Releasability of the HPPA port

[Luk Claes]

On 08/07/2010 12:28 PM, Thibaut VARÈNE wrote:
> Le 7 août 2010 à 06:43, Philipp Kern a écrit :
>> On 08/06/2010 10:48 AM, Carlos O'Donell wrote:

> Finally, a silly question: looking at the bottom line of this chart, it seems 
> that Debian is "at risk" of becoming a x86/64(+ia64?)-only release[2]. Is it 
> actually the case? I don't mean to start a heated discussion here, but if I 
> "missed the memo", maybe others did too. The point is, if that's what Debian 
> is moving towards, then the current discussion is pretty moot, isn't it?

It looks that many ports have trouble to either have new affordable
hardware (so buildds can cope easily and porters have easy means to test
things) or have trouble to have upstream and/or Debian porters. So in
that regard Debian will be moving to supporting less ports unless that
changes AFAICS.

Note though that armel is a noticable exception were both new hardware
and new porters are easily found both upstream as well as within Debian.
In that regard I'm at least still hopeful for the mips ports.

hppa seems to be very borderline for the future due to a stand still for
hardware and a decrease in porters (upstream seems to work best when
it's similar to ia64 and already more difficult otherwise). The kfreebsd
ports seem to not have enough porting effort to have a clear progress
atm, though still look promising. powerpc and sparc seem to loose linux
users/porters due to only having expensive new hardware, Oracle is
probably not going to help in that respect. sparc seems to also miss
Debian porters to be able to move to sparc64 userland in a clean way.
s390 has always been special and would gain a lot of having some real
porters next to the current contributing users AFAICS.

Personally I'd love if Debian would be able to attract more porters so
we could keep supporting many architectures also in the future!

Cheers

Luk

PS: Feel free to correct me if my observation seems wrong or incomplete
for some port.


-- 
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/4c5d60bd.7000...@debian.org

Re: User-testing of testing?

[Luk Claes]

On 08/10/2010 03:43 PM, Stefano Zacchiroli wrote:
> On Tue, Aug 10, 2010 at 11:40:29AM +0100, Enrico Zini wrote:
>> So I was wondering if we shouldn't have a list of user-centered
>> "stable release goals", such as "open a PDF attachment in icedove",
>> "open an OpenDocument attachment in icedove", "watch youtube videos",
>> "copy a file to a USB key", which people trying a fresh testing
>> install could test.
> 
>> I however do not see an obvious way of collecting feedback for such user
>> tasks, or for having fights over which user tasks are the most
>> significant, without having people submit tasks to the release managers
>> and the release managers deciding which ones are worth making official,
>> which would be quite a burden to them.
>>
>> Are there ways to set up such a thing so that it mostly manages itself?
> 
> I don't know a specific answer on your questions, but I do have some
> lateral thinking/discussion to report. At DebConf10, I've spoken with
> Philipp Kern about how to invite our users to test Squeeze before we
> release it. We have agreed on the fact that we can do better than past
> releases on that and the rough idea was to send out a press release
> inviting willing users to do upgrades from Lenny to frozen Squeeze and
> report the issues they find. We discussed how the best moment to do that
> would have been post-freeze and it turns out that this is exactly *that*
> moment.
> 
> The TODO list to go forward with this is:
> 
> - Decide where user feedback will have to go; the obvious answer is the
>   BTS, but we need to decide whether reuse some existing (pseudo)
>   package or create a new one for the occasion. IMHO it should be
>   something quite obvious for the users such as "squeeze" or
>   "squeeze-upgrades" or something like that.

There is upgrade-reports just for that reason...

> - Draft a text to send out as press release, the title should probably
>   be something like "User testing sought to improve the quality of the
>   forthcoming Debian Squeeze". The debian-public...@lists.d.o is
>   wonderful for reviewing this kind of stuff, but we need first to
>   decide the content of the press release. I propose the following main
>   points:
> 
>   - please test upgrades from lenny to (frozen) squeeze
>   - please test ISOs/d-i

This is especially a good idea once d-i beta is released...

Some of the issues that will be found for upgrading or for installing
will just have to be fixed, others probably need to be documented in the
Release Notes.

> I believe that what you are looking for can later on be extracted from
> user reports ... but of course we will need to find out a group of
> Debian volunteers to do that triaging. The latter can probably be found
> easily if the release team agrees on sending (later on) a specific call
> for help via d-d-a (I'm kind of reluctant to add such duty to the
> release team, given that they will be super-busy in the near future with
> unblock requests and in getting the RC bug count down).

This is mainly the difficult part from previous experiences, though I
hope it will be easier to find volunteers this time! :-)

Cheers

Luk


-- 
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/4c61bff0.6070...@debian.org

Re: User-testing of testing?

[Luk Claes]

On 08/10/2010 11:55 PM, Stefano Zacchiroli wrote:
> On Tue, Aug 10, 2010 at 11:09:04PM +0200, Luk Claes wrote:
>>> - Decide where user feedback will have to go; the obvious answer is the
>>>   BTS, but we need to decide whether reuse some existing (pseudo)
>>>   package or create a new one for the occasion. IMHO it should be
>>>   something quite obvious for the users such as "squeeze" or
>>>   "squeeze-upgrades" or something like that.
>> There is upgrade-reports just for that reason...
> 
> Oh, right, I apologize for my ignorance of that package.  What is the
> appropriate way to tag upgrade reports so that we can easily filter on
> lenny->squeeze upgrades or alternatively filter out past unrelated
> reports?

I guess it would be best if they get a tag lenny or get closed when they
are not about upgrades to squeeze.

Cheers

Luk


-- 
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/4c61cba7.6070...@debian.org

Re: Seeking for advice regarding keepalived

[Luk Claes]

On 08/14/2010 09:04 AM, Alexander Wirt wrote:
> Hi folks, 

Hi Alexander

> some time ago I uploaded keepalived 1.2.0 to debian because it was the first
> (development) version with ipv6 support for ipvs. I thought/hoped development
> would be faster so that we have a working/stable version with ipv6 for
> squeeze. Unfortunatly that wasn't the case. I don't think 1.2.0 should be
> released with squeeze, but I also don't want to release without keepalived
> since several people rely on it. 
> 
> So I see two options here: 
> 
> - Upload 1:1.1.17 to unstable/testing (that was the latest version in squeeze
>   before 1.2.0)
> 
> - Upload 1:1.1.19 to unstable/testing (that is a bugfix release which
>   contains some wanted bugfixes.) 
> 
> The second option would be my preferred one. 
> 
> What do you think? 

At my work place we are using 1.1.19 as we really needed some bugfixes
which were not in 1.1.15 nor 1.1.17. It works stable and we did not have
any issues up to now.

So personally I would go for 1.1.19, so unless there are objections
please do upload that one.

Cheers

Luk


-- 
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/4c6648cb.7050...@debian.org

Re: bugs in the unofficial RC bug tracker @ turmzimmer

[Luk Claes]

On 08/15/2010 04:46 PM, Lucas Nussbaum wrote:
> Hi,

Hi

> I investigated some differences between http://bts.turmzimmer.net/details.php
> and what UDD sees, and found out that the unofficial RC bug tracker
> seems to be missing quite a lot of bugs.
> 
> The main problem seems to be that it doesn't know about the 'src:'
> syntax (examples: #577321, #577364).
> 
> It also seems wrong about other bugs, though it's harder to understand
> what it does wrong in those cases.

I guess some of them can be explained by the seemingly missing support
for multiple source versions in unstable (aka it seems to take the first
one it encounters).

> If someone is interested in rewriting the unofficial RC bug tracker
> using UDD, I could provide some help with the SQL part.

aba: what do you think?

Maybe it's also time to make it an official service?

Cheers

Luk


-- 
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/4c68011f.50...@debian.org

Re: Unblock brltty?

[Luk Claes]

On 08/16/2010 05:21 PM, Samuel Thibault wrote:
> Adam D. Barratt, le Sat 14 Aug 2010 10:09:38 +0100, a écrit :
>> The icu transition is ready to go, but currently stalled by brllty which
>> is blocked because of its udeb.
>>
>> As I understand it, the udeb does not use icu
> 
> It doesn't indeed.
> 
>> so should be safe to unblock in that regard; could we do so please?
> 
> Brltty should be fine to unblock.

unblocked

Cheers

Luk


-- 
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/4c696d61.2090...@debian.org

udeb unblock: partman-base [Re: udeb unblocks: netcfg, libdebian-installer]

[Luk Claes]

On 08/21/2010 05:41 PM, Otavio Salvador wrote:
> "Adam D. Barratt"  writes:
> 
>> busybox recently migrated to testing; this new version apparently has an
>> incompatibility with the netcfg version currently in testing, so we were
>> asked by Aurelien whether it would be possible to migrate netcfg as
>> well.
> 
>> netcfg is on the "cannot automatically migrate without approval" udeb
>> list and, in order to migrate it, the new version of libdebian-installer
>> (which is also on the "needs approval" list) would also have to migrate
>> at the same time.
> 
> ack for netcfg and libdebian-installer.

What about partman-base (and rescue which Christian kind of acked)?

Cheers

Luk


-- 
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/4c7039bc.30...@debian.org

Re: udeb unblock: partman-base [Re: udeb unblocks: netcfg, libdebian-installer]

[Luk Claes]

On 08/21/2010 10:40 PM, Luk Claes wrote:
> On 08/21/2010 05:41 PM, Otavio Salvador wrote:
>> "Adam D. Barratt"  writes:
>>
>>> busybox recently migrated to testing; this new version apparently has an
>>> incompatibility with the netcfg version currently in testing, so we were
>>> asked by Aurelien whether it would be possible to migrate netcfg as
>>> well.
>>
>>> netcfg is on the "cannot automatically migrate without approval" udeb
>>> list and, in order to migrate it, the new version of libdebian-installer
>>> (which is also on the "needs approval" list) would also have to migrate
>>> at the same time.
>>
>> ack for netcfg and libdebian-installer.
> 
> What about partman-base (and rescue which Christian kind of acked)?

Got an ack from otavio on IRC.

Cheers

Luk


-- 
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/4c704331.4010...@debian.org

Re: Please unblock istanbul 0.2.2-8

[Luk Claes]

On 08/24/2010 03:16 PM, Luca Bruno wrote:
> Hi,
> istanbul/0.2.2-8 fixes two RC bugs and had already aged in sid without
> further reports, please unblock it. debdiff attached.

It has already migrated due to my unblock earlier today :-)

Cheers

Luk


-- 
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/4c73c68b.6040...@debian.org

Bug#594873: RM: picprog/testing-proposed-updates -- ROP; not suitable for s90

[Luk Claes]

Package: ftp.debian.org
Severity: normal

Hi

Please remove picprog from testing-proposed-updates, it's up-to-date in testing 
apart from the binary on s390 which the porter/buildd admin marked as 
Not-For-Us.

Cheers

Luk



-- 
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/20100830102247.20492.12632.report...@station.luk.local

Bug#594875: RM: tijmp/testing-proposed-updates -- ROP; NFU on several arches

[Luk Claes]

Package: ftp.debian.org
Severity: normal

Hi

Please remove tijmp from tpu its binaries are deemed unusable by the 
porter/buildd admin.

Cheers

Luk



-- 
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/20100830102522.20797.86455.report...@station.luk.local

Bug#594877: RM: usbview/testing-proposed-updates -- ROP; NFU on s390

[Luk Claes]

Package: ftp.debian.org
Severity: normal

Hi

Please remove usbview from tpu, it's binaries are deemed unusable by the 
porter/buildd admin.

Cheers

Luk



-- 
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/20100830102638.20847.47623.report...@station.luk.local

Re: Request for approval of FAI 3.4.1

[Luk Claes]

* Michael Prokop  wrote:

> Ok, 3.4.0 went through NEW (thanks) and I just uploaded 3.4.1 with
> the mentioned bugfix to unstable.
>
> Please approve fai 3.4.1 for squeeze.

unblocked

Cheers

Luk


-- 
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/4c7bbd0f.8070...@debian.org

Bug#592300: future unblock: xz-utils/4.999.9beta+20100810-1

[Luk Claes]

Adam D. Barratt wrote:

>> In any case, please get back to us once the package has reached its
10 days.
>
> The xz-utils package has reached its 10 days.

unblocked, not closing bug as you still seem to speak about other changes?

Cheers

Luk



-- 
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/4c7bc6f2.6050...@debian.org

Re: Unfreezing pdl_2.4.7+dfsg-1

[Luk Claes]

> Moin,
> just finished an upload of a new (minor) upstream PDL version, package
built
> fine on all architectures.
> This release fixes many bugs (most tracked on upstream's sf.net tracker),
> brings big improvements on the documentation side, and has a more reliable
> test suite.
> Could you unfreeze pdl_2.4.7+dfsg-1 to get it into the squeeze release?

unblocked

Cheers

Luk


-- 
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/4c83a039.6030...@debian.org

Re: redmine 1.0.1-1 : stable release for 1.0 version

[Luk Claes]

> i just uploaded redmine 1.0.1-1 to debian/unstable, which is a very
> significant release :
>* Upstream update, fixes many 1.0.0 RC bugs, see :
>  http://www.redmine.org/versions/show/21
>* Patch for libi18n-ruby 0.4.1 support. (Closes: #592672)
>* Postinst note should be an error. (Closes: #591220)
>* Update translations. (Closes: #591072, #591219, #591235, #591268,
>  #591308, #591689, #591716, #592371)
>* Fix /usr/share/doc/redmine/examples/apache2-* to work with
>  libapache2-mod-fcgid >= 2.3.5 (LP: #620392)
>* Rephrase web server configuration section in README.Debian (LP:
#620412)

unblocked

Cheers

Luk


-- 
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/4c83cd63.5090...@debian.org

Re: Re: Freeze exception for gdc-4.3

[Luk Claes]

On Sun, 2010-08-22 at 17:54 +0100, Iain Buclaw wrote:
>> On 22 August 2010 16:20, Adam D. Barratt 
>> wrote:
[...]
>> The diffstat between the testing and unstable packages is
>>
>>  824 files changed, 133190 insertions(+), 141498 deletions(-)
>>
>> which is practically unreviewable.  Ignoring whitespace
>> changes in the
>> diff reduces it to
>>
>>  767 files changed, 82109 insertions(+), 90417 deletions(-)
>>
>> which is still very high.
>>
>>
>> The source tarball also houses the GDC D2 project too. And the diff
>> will have shown all the major updates to that frontend and it's
>> accompanying libraries, which includes the dmd2, phobos2 and druntime
>> directory. To my count, this accounts for 560 of those files. None of
>> which are used in the building of D1.
>
> That certainly reduces the diff substantially; thanks.  It leaves us
> with [1]
>
>  209 files changed, 13659 insertions(+), 22012 deletions(-)
>
> which is still a significant quantity of changes.

unblocked

Cheers

Luk


-- 
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/4c83dacb.8090...@debian.org

Re: Re: strongswan update to 4.4.x

[Luk Claes]

> On Thursday 26 August 2010 22:18:23 Mehdi Dogguy wrote:
>> Trying to see how it looks like, I ended up with a big diff.
>>
>>  489 files changed, 27220 insertions(+), 11439 deletions(-)
>>
>> Is there any sane way to review this?
>
> Maybe the best way would be to contact upstream. In my experience, Martin
> Willi and Andreas Steffen are very willing to actively interact with
us. They
> might be able to provide a detailed info on what has changed from
4.3.x to
> 4.4.1 and which impact this might have on stability.
>
> In general, it certainly seems to me that 4.4.x is more stable in
practice
> than 4.3.x.

unblocked

Cheers

Luk


-- 
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/4c8d2df4.7040...@debian.org

Re: ublocks for security fix uploads

[Luk Claes]

On 09/13/2010 05:55 AM, Michael Gilbert wrote:
> Hi,

Hi

> Please unblock the following packages that fix security issues:
> 
> unblock cacti/0.8.7g-1
> unblock drupal6/6.18-1
> unblock iceape/2.0.7-1
> unblock iceweasel/3.5.12-2

all unblocked

> unblock libgdiplus/2.6.7-3

unblocked and aged to 5 days

> unblock phpmyadmin/4:3.3.7-1

unblocked 2 days ago by Adam

> unblock python2.6/2.6.6-3

unblocked

> unblock python3.1/3.1.2+20100829-1

unblocked and aged to 20 days

> unblock ruby1.9.1/1.9.2.0-1

unblocked and aged to 20 days due to massive changes

> unblock sssd/1.2.1-4

unblocked

> unblock strongswan/4.4.1-3

unblocked yesterday

> unblock sudo/1.7.4p4-2 (this should be hinted in faster since it was 
> mistakenly uploaded with low priority)

No, I changed the aging, because there are a lot more changes than
fixing the security issue.

> unblock webkit/1.2.4-1

unblocked 7 days ago by Julien

> unblock kdegraphics/4:4.4.5-2 (note this also needs djvulibre hinted at a 
> higher urgency)
> unblock djvulibre/3.5.23-3

unblocked, djvulibre aged to 5 days

Cheers

Luk


-- 
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/4c8dbe97.60...@debian.org

Re: Preparation of fixes to 6.0.1

[Luk Claes]

On 02/18/2011 09:02 AM, Philipp Kern wrote:
> On Fri, Feb 18, 2011 at 06:33:39AM +0100, Christian PERRIER wrote:
>> Quoting Otavio Salvador (ota...@ossystems.com.br):
 'Urgent bug fixes', or something to that effect?
>>> They're not only bug fixes but also database updates and like.
>>> Important system updates?
>> One might argue that they're not important as well (think about the
>> updates we plan to do for iso-codes). Actually "volatile" was very
>> well suited, indeed..:-)
> 
> They won't be pushed through -updates, no?  Normal updates are included into
> stable through point releases.

AFAICT -updates should be used when changes should be pushed to users
right now aka even before a point release.

So all in -updates would be included in the point release together with
other things accepted in proposed-updates.

Cheers

Luk


-- 
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/4d5ef06b.9000...@debian.org

Re: Bits from the Release Team - Kicking off Wheezy

[Luk Claes]

Hi

Below an update of the release goals I advocated and some thoughts on
others.

> Release Goals
> -
> As a first step towards establishing release goals for wheezy, we will
be reviewing
> each of the goals which we had for squeeze [RDO:SGoals] to see which
have been achieved and which
> may no longer be relevant for other reasons.
>
> If you are listed as the proponent for a goal in the above list,
please feel free to
> provide a status update on progress towards completing it and whether
you believe it is
> relevant for the wheezy cycle.  You can also e-mail us to propose a
new goal, including
> a description of the goal and an indication of how progress on the
issues may be tracked
> (e.g. a pointer to a set of appropriate user-tagged bugs).

# bootperformance
  Advocate: Petter Reinholdsen and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/BootPerformance

The main part of this goal was achieved, though there are some possible
improvements both regarding boot reliability and boot performance that
could still be aimed for.

Regarding reliability I'm doing some work regarding NFS, though one of
the main outstanding issues is the race between availability of the
network devices and the end of the network init script AFAICS. It would
also not be a bad idea to have a discussion on whether the default init
system should change to one that is more suitable to guarantee the
reliability of the boot like upstart or systemd.

Regarding boot performance there is quite some work done by Ubuntu in
different packages, so maybe it would not be bad to have a look at how
Ubuntu and Debian could get more in sync on that.

# package quality
  Advocate: Holger Levsen and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality

This is a never ending goal of sustaining our packages quality by
improving our tests and following up closely... so needless to say that
I would still advocate this one.

# remove obsolete libraries
  Advocate: Barry deFreese and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs

This worked quite well and should continue so we can get rid of obsolete
libraries IMHO. One of the main candidates are the old db libraries,
though there are also still some old gnome libraries and without doubt
others.

> We're also after new goals! I know that expressions of interest in
multiarch and
> tdebs have already been indicated, but if you have something you would
want to
> see happen for Wheezy, please let us know. The release team itself will be
> suggesting some as part of the review above.

I'm definitely in favour of having multiarch finally happen!

For the IPv6 and LFS legacy release goals I think it would be best if we
would welcome massive (automatic?) tests to find all of the outstanding
issues and get them fixed finally!

I would welcome a review of essential, required and standard though I
don't know if many would welcome such an initiative which could
potentially have quite some impact without much visible gain. Anyway
it's something which should happen in the beginning of the cycle (after
a discussion with both the involved maintainers as well as the
developers body at large) or not at all IMHO.

Cheers

Luk


-- 
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/4d936684.2050...@debian.org

Re: Number of berkeley db packages reduction

[Luk Claes]

On 04/05/2011 02:55 PM, Ondřej Surý wrote:
> Hi,
> 
> I would like to coordinate reduction of BDB packages since I took the
> unhappy job (as I could expect) to maintain BDB in Debian after Clint
> have orphaned them.
> 
> The main issue which I have encountered (in cyrus-imapd) is that the
> change from 4.x to 5.x introduces code changes, because the packages
> check for 4 + something version number. The fix is easy (I can help
> with that if needed), but it still some work which needs to be done.

In principal the reduction of bdb packages is a very good idea! Though
care should be taken to better choose which versions are shipped:
openldap for instance really needs a fast one.

Best would probably be to have one of each major user (like cyrus-imapd
and openldap, but maybe also some others) of bdb involved in testing new
packages before they get uploaded to unstable? So both the build and
usage can be tested before random packages start to use it.

Cheers

Luk


-- 
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/4d9b4dc0.7070...@debian.org

Bug#568141: release.debian.org: Latest point release hard to follow / confusing

[Luk Claes]

On 05/14/2011 10:44 AM, Helge Kreutzmann wrote:
> Hello Julien,
> On Sat, May 14, 2011 at 10:33:21AM +0200, Julien Cristau wrote:
>> This is still about the fact that you're expecting all debian.org
>> resources to be in sync at point release time.  I don't think that's
>> reasonable, the release process is complicated enough as it is.  Please
>> don't reopen.
>  
> I'm not saying it is easy, I'm not saying that this is a "must fix",
> I'm not saying someone is to blame, etc.
> 
> But you are saying: "This is a problem (bug) but I don't want to see a
> report about it?" I belived that Debian is not hiding problems. And,
> the bts has a tag called "wontfix" to indicate a problem a fix cannot
> be found.
> 
> I hope you can enlighten me why this problem should not be documented
> in the bts.

There currently are mails to inform people of upcoming point releases
and mails to announce point releases when everything is available on the
mirror network. What is it that you are still missing and what exactly
can be done to get that fixed?

Cheers

Luk



-- 
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/4dce5ceb.7020...@debian.org

Bug#568141: release.debian.org: Latest point release hard to follow / confusing

[Luk Claes]

On 05/14/2011 05:13 PM, Helge Kreutzmann wrote:
> Hello Luk,
> On Sat, May 14, 2011 at 12:43:55PM +0200, Luk Claes wrote:
>> On 05/14/2011 10:44 AM, Helge Kreutzmann wrote:
>>> On Sat, May 14, 2011 at 10:33:21AM +0200, Julien Cristau wrote:
>>>> This is still about the fact that you're expecting all debian.org
>>>> resources to be in sync at point release time.  I don't think that's
>>>> reasonable, the release process is complicated enough as it is.  Please
>>>> don't reopen.
>>>  
>>> I'm not saying it is easy, I'm not saying that this is a "must fix",
>>> I'm not saying someone is to blame, etc.
>>>
>>> But you are saying: "This is a problem (bug) but I don't want to see a
>>> report about it?" I belived that Debian is not hiding problems. And,
>>> the bts has a tag called "wontfix" to indicate a problem a fix cannot
>>> be found.
>>>
>>> I hope you can enlighten me why this problem should not be documented
>>> in the bts.
>>
>> There currently are mails to inform people of upcoming point releases
>> and mails to announce point releases when everything is available on the
>> mirror network. What is it that you are still missing and what exactly
>> can be done to get that fixed?
> 
> It is currently not clear which pages are current and which pages are
> out of date regarding version numbers after point updates.
> 
> A fix could be some note on e.g. http://packages.debian.org/ that the
> version numbers after point releases might be (slightly) out of date
> and that in case of doubt http://packages.qa.debian.org/ should be
> used.

This has nothing to do with release.debian.org, but with syncs the
website and QA teams are responsible of AFAICT.

> Another fix was proposed in my initial bug report (why is nobody
> reading this?) already:
>  My suggestion: First update www.debian.org (*with* version numbers)
>  and then push the update out to the mirrors. And secondly unify the
>  versions given in http://packages.debian.org/XXX and
>  http://packages.qa.debian.org/XXX (and in the latter also where the
>  latest one is printed).

The website update should only happen once the mirrors are populated
according to the mirror team which makes perfectly sense to me.

> Hope this clarifies.
> 
> Do you agree to reopen this bug now? (After having explained the initial 
> report again and having proposed two possible solutions)

I'm afraid you'll get nowhere by reopening the bug. The sync scripts for
packages.debian.org and packages.qa.debian.org are suboptimal in that
they show out-of-date information also when there is no point release.
So that might be something to look at by the website and/or QA teams.

> P.S. And of course, adding version numbers in the NEWS on
> www.debian.org, e.g. News/2010/20100130.wml, would also solve the
> immediate problem ...

That might be possible, though would need some better integration of the
tools (patches are probably welcome) and coordination with the press
team that they are fine with the changes.

Cheers

Luk



-- 
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/4dcea2df.6070...@debian.org

Re: Uploading linux-2.6 (2.6.39-2)

[Luk Claes]

On 06/05/2011 06:01 AM, Ben Hutchings wrote:
> I intend to upload linux-2.6 to unstable early this week.  This will
> include stable update 2.6.39.1 and restoration of aufs support for use
> in Debian Live.
> 
> Stable update 2.6.39.1 includes an ABI change, so we will probably have
> to change the binary package names.

Ok, looks fine. Go ahead with the upload.

Cheers

Luk


-- 
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/4deb33ec.2020...@debian.org

Re: SAT based britney - formalisation of the problem

[Luk Claes]

On 07/01/2011 10:25 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 29 Jun 2011, Ralf Treinen wrote:
>> In fact, from out point of view the DIMACS format or MAX-SAT input
>> format are already a specific encoding technique, and we think that
>> one should first find a logical specification of what exactly one
>> tries to achieve, before thinking about a specific encoding into
>> MAX-SAT or whatever other solver technology.
> 
> But we're looking into having some concrete prototype in the short term
> and I don't think that this kind of formalization will help us in that
> regard. And I don't really see the expected benefits of this approach
> either...
> 
>> Another element of the precise specification would be: one wants to
>> have a maximal solution. What precisely is the sense of maximality here?
>> Maximal number of binary packages? Maximal number of source packages? Should
>> there be a way to give more weight to more "important" packages?
> 
> It would be nice to take the popularity into account indeed and give them
> priority in terms of migration.
> 
> But really this is just a cherry on the top. If we already get something
> working that gives a coherent set of package that can move without manual
> hints, it would be great.

That's already an option in britney2. This SAT based design seems
overcomplex due to all the special casing AFAICT. I also don't buy that
a Conflicts relationship should be special instead of a plain one like now.

I won't stop anyone from experimenting with a SAT based solution, though
from a release point of view, I think it would be better to start using
britney2 and kill its bugs (which unfortunately will take some time
AFAICS) before diving into a SAT based adventure.

Cheers

Luk


-- 
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/4e0e42b6.2070...@debian.org

Re: security support for lenny / upgrades from lenny to wheezy

[Luk Claes]

On 07/05/2011 03:45 PM, Camaleón wrote:
> On Sun, 03 Jul 2011 12:30:03 +0200, Jochen Schulz wrote:
> 
>> [Please Cc me, I am not subscribed.]
>>
>> Hi,
>>
>> I am forwarding a discussion from debian-user. I'd love to hear an
>> official statement about this. AFAICS, this issue hasn't been 
>> explicitly addressed yet and at least one person from debian-user 
>> expects to be able to skip squeeze.
> 
> (...)
> 
> That one person must be "me".
> 
> Yes, I was the one who recently sent the announcement notice to d-u
> mailing list (it seemed to me that nobody was aware of it...) and would 
> be nice to know what's the official possition on this matter.
> 
> As I didn't read any other notice about this, I expected the statatement
> made on 2009 still applies. If no, an additional notice stating the new
> plans would be more than desiderable so people can smoothly deploy their
> install strategies.
> 
> I expected that Lenny (now "oldtstable") is still getting security 
> fixes until Wheezy is released, and once out, it gets dropped.

The rule is that a release is supported up to the next release + 1 year
unless the release after the next one comes earlier. So for Lenny that
would mean until release date of Squeeze + 1 year (February 6th 2012)
unless Wheezy would be released earlier. Obviously Wheezy won't be
released before, so Lenny is supported until Febrary next year.

Cheers

Luk


-- 
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/4e134cf3.3060...@debian.org

Re: [RFC] Use of Built-Using in debian-installer

[Luk Claes]

On 07/30/2011 06:23 AM, Otavio Salvador wrote:
> Hello,

Hi Otavio

> During this night I got some nice progress on the stuff planned to
> debian-installer. I am adding the generated control file for review
> and comments.
> 
> Basically it gather all udebs included on the initrd and puts this
> information in the Built-Using field of the binary package.
> 
> Comments, welcome :-)

Great start, though Built-Using expects source packages instead of
binary (or udeb) packages.

Cheers

Luk


-- 
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/4e3416ec.3060...@debian.org

Re: Changes to Debian Installer release process

[Luk Claes]

On 07/28/2011 01:18 PM, Otavio Salvador wrote:
> I used some of Debcamp and Debconf time this year to discuss the
> Debian Installer release process with some people and after talking
> with many people it seems we agreed on the following changes on Debian
> Installer release process and it would be interesting to receive
> feedback on those to see if anyone see a problem we didn't notice yet.

Great, lets make d-i as easy to handle as general packages (or at least
almost ;-))!

> * Official uploads to be built against unstable

Sounds good.

>  * Linux kernel udebs to be built from linux source package

Also looks good.

>  * Debian Installer daily builds to be done from source uploads
> 
>The daily builds will use the archive source for building so every
> time we do a change in unstable in a module that is included in initrd
> it will trigger a binNMU in all architectures replicating what we have
> in daily builds. When source changes in debian-installer source
> package are done, a new source upload will be required.

Do the daily builds only uncover issues from building the initrd? A.k.a.
will changes in packages other than the one in the initrd only have an
effect on the install via genuine downloading from the archive at the
time of the install?

>  * Debian Installer experimental builds
> 
>With Linux kernel udebs built from linux source we have the
> possibility to get the installer built against the development kernel
> that will be available on experimental and this is quite important to
> us to be able to test all this before it is available in unstable to
> avoid bad surprises for us and users. This will also be a handy tool
> for us to play with not well tested or finished stuff without breaking
> installer to end users.

Sounds good!

>  * Use of britney to handle package and installer migration
> 
>This is the end of the process and some details are yet unknown how
> this is going to happen however but our goal is to make it happen
> since it will alleviate a lot the amount of work to make Debian
> Installer release to happen.

Super!

> It is important to notice that it is not a single-man effort but a
> coordinate and shared effort of Debian Kernel, Debian Release and
> Debian Installer teams to get all this done. Those changes are not
> going to happen at once but in a progressive process and at the end
> this is going to make the installer release process easier to
> understand and handle.

Right, lets go for it!

Cheers

Luk


-- 
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/4e341d9a.1040...@debian.org

Re: binNMUs?

[Luk Claes]

On 08/01/2011 08:22 PM, Julien Cristau wrote:
> On Mon, Aug  1, 2011 at 15:37:43 +0200, Andreas Barth wrote:
> 
>> e.g.  https://wiki.ubuntu.com/MultiarchSpec#Binary_NMUs for ubuntus
>> way to handle it.
>>
> Well.  Ubuntu doesn't have binNMUs, so they don't have to "handle" it at
> all.

Why could wb not handle the case where one tries to binNMU on one arch
where it should be done on all archs without changing binNMU formats?

Or am I missing something?

Cheers

Luk


-- 
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/4e37190b.7060...@debian.org

Re: Changes in release goals for Wheezy

[Luk Claes]

Hi Scott

On 08/02/2011 05:39 AM, Scott Kitterman wrote:
> As the drafter of the proposed release goal for Python [1],  I will confess 
> some surprise when I read on d-d-a [2] that this had been dropped for Wheezy 
> without being involved any discussion or at least notification.   Regardless, 
> it's the release team's call, so it's gone.

It was marked not suitable as a release goal. I understood that to mean
that transitions are tracked anyway, without the need to be a release goal.

> I'm somewhat unsure how to proceed.

Why would it being named a release goal or not need to change expectations?

> There is a fair bit of work to get python2.7 as the default and only python 
> for Wheezy.  There is both a transition bug [3] and a usertag [4] (yes, I 
> know 
> some consolidation is needed) and additional testing needed.  Without a 
> release goal, which would permit developers interested in Python in Debian 
> treat these bugs as if they were RC and to NMU to work towards this goal, the 
> only options I see are:

Hmm, I thought there would also be a python3?

Anyway there are about 25 packages blocking the transition. As it is
clear that python2.7 will become the default and only python2 (unless
anyone is questioning this??!), it would make sense to promote these
bugs to RC already even if python2.6 is currently still the default.

> a.  Wait until maintainers address these issues

Never a good idea to wait for others to do the work. We are all
volunteers, though if one has time and energy it's way better to try to
help (binNMUs, patches, contacting upstream...) instead of just waiting.

> b.  Upload python-defaults making python2.7 default so these become true RC 
> bugs.

I would first have a look at what would be the real impact if none of
the blocking bugs would get resolved: What would it mean to remove all
of the ones that are not fixed and their reverse dependencies from testing?

> I'm also anticipating that developers (all of whom have limited time 
> available) will reasonably read this decision as meaning fixing these bugs is 
> a 
> lower priority (in fact, I think that instead of Important, they should 
> probably be Wishlist now).

I fail to see why it would be demoted as a transition as well? So I
don't see any reason why the bugs should have a lower priority than
important.

> I would appreciate knowing how the release team expects this to work?  I 
> asked 
> about this on Niels Thykier suggested I write an email instead.

Above I've given my understanding of how it should work. It would be
good if someone could confirm or comment.

Cheers

Luk


-- 
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/4e379981.5090...@debian.org

Re: binNMUs?

[Luk Claes]

On 08/02/2011 10:50 AM, Raphael Hertzog wrote:
> On Mon, 01 Aug 2011, Luk Claes wrote:
>> Why could wb not handle the case where one tries to binNMU on one arch
>> where it should be done on all archs without changing binNMU formats?
> 
> Maybe they try to tackle the "binNMU arch: all packages" problem at the
> same time?

Well, that's a different problem AFAICS. Though the solution might
indeed work for both scenarios.

Cheers

Luk


-- 
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/4e37c319.6010...@debian.org

Bug#642390: pu: package ipmitool/1.8.11-2+squeeze1

[Luk Claes]

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

Hi

Ok if I upload an updated ipmitool with the following patch?

diff -u ipmitool-1.8.11/debian/patches/series ipmitool-1.8.11/debian/pa
tches/series
--- ipmitool-1.8.11/debian/patches/series
+++ ipmitool-1.8.11/debian/patches/series
@@ -2,0 +3 @@
+fix_sdr_segfault
only in patch2:
unchanged:
--- ipmitool-1.8.11.orig/debian/patches/fix_sdr_segfault
+++ ipmitool-1.8.11/debian/patches/fix_sdr_segfault
@@ -0,0 +1,13 @@
+diff -Nur ipmitool-1.8.11/lib/ipmi_sdr.c ipmitool-1.8.11.fix/lib/ipmi_sdr.c
+--- ipmitool-1.8.11/lib/ipmi_sdr.c 2009-02-25 21:38:52.0 +0100
 ipmitool-1.8.11.fix/lib/ipmi_sdr.c 2011-08-10 18:21:26.0 +0200
+@@ -1828,7 +1828,7 @@
+   printf("ns  | %2d.%1d | ",
+  sensor->entity.id,
+  sensor->entity.instance);
+-  if (IS_SCANNING_DISABLED(rsp->data[1]))
++  if (rsp && IS_SCANNING_DISABLED(rsp->data[1]))
+   printf("Disabled");
+   else
+   printf("No Reading");
+

Cheers

Luk



-- 
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/20110922053724.14111.9760.report...@station.luk.local

Bug#642390: pu: package ipmitool/1.8.11-2+squeeze1

[Luk Claes]

On 09/22/2011 07:55 PM, Adam D. Barratt wrote:
> tag 642390 + squeeze confirmed
> thanks
> 
> On Thu, 2011-09-22 at 07:37 +0200, Luk Claes wrote:
>> Ok if I upload an updated ipmitool with the following patch?
>>
>> diff -u ipmitool-1.8.11/debian/patches/series ipmitool-1.8.11/debian/pa
>> tches/series
>> --- ipmitool-1.8.11/debian/patches/series
>> +++ ipmitool-1.8.11/debian/patches/series
>> @@ -2,0 +3 @@
>> +fix_sdr_segfault
> 
> I'd have preferred a full debdiff but yes, please go ahead; thanks.

Ok, I'll remember for next time :-)

Uploaded and through unchecked into p-u-new.

Cheers

Luk



-- 
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/4e7ba0a6.4040...@debian.org

Re: Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Luk Claes]

On 10/03/2011 07:20 PM, Philipp Kern wrote:
> On Mon, Sep 05, 2011 at 12:46:13PM -0400, Sam Hartman wrote:
>>> "Adam" == Adam D Barratt  writes:
>> Adam> The krb5 package was uploaded and I've (somewhat belatedly)
>> Adam> marked it for acceptance at the next dinstall.  What's the
>> Adam> status of the nfs-utils upload?
>> My guess is they were waiting for krb5.
>> Remember they have to increase build-depends for the krb5 you just
>> accepted.
> 
> AFAICS this now missed the 6.0.3 point release.

Upstream did some changes related to this which should fix it in
unstable for the squeeze -> 2.6.35 kernel range. Kernels afterwards
should not have the problem.

It would be good if someone could confirm that it is really fixed in
unstable now.

Cheers

Luk


-- 
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/4e8a1530.9060...@debian.org

Re: Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Luk Claes]

On 09/12/2011 08:24 PM, Adam D. Barratt wrote:
> On Mon, 2011-09-05 at 12:46 -0400, Sam Hartman wrote:
>>> "Adam" == Adam D Barratt  writes:
>>
>>
>> Adam> The krb5 package was uploaded and I've (somewhat belatedly)
>> Adam> marked it for acceptance at the next dinstall.  What's the
>> Adam> status of the nfs-utils upload?
>>
>> My guess is they were waiting for krb5.
>> Remember they have to increase build-depends for the krb5 you just
>> accepted.
> 
> If it requires a versioned build-dependency, then both packages could
> just have been uploaded at the same time.  Even if we accepted them both
> from p-u-NEW together, the buildds would have put nfs-common in to the
> "build-deps uninstallable" state until the necessary version of krb5 was
> available.

Anyway, uploaded now.

Cheers

Luk


-- 
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/4ea7b134.60...@debian.org

Perl transition blockers: candidates for testing removal

[Luk Claes]

Hi

The following packages block the perl transition and will become testing
removal candidates soon unless the bugs get fixed:

* ifeffit (#648839)
* uwsgi (#640347)
* libdbd-interbase-perl (#648857)
* libcrypt-gcrypt-perl (#634598)
* prima (#628500)
* nginx (#649061)
* libsignatures-perl (#636132)
* libpgplot-perl (#648842)

* libtokyocabinet-perl (#649060): maybe mipsel binary should be removed?
* genders (#646286): patch ready, maybe NMU?
* openscap (#649063): maintainer said he would upload today
* libdbd-sybase-perl (#629255): maintainer, this is your ping

* openldap (#649062): won't be removed, please help fixing it!!!

Progress can be seen on the transition tracker page [1]. Currently it
looks worse than the above as some builds (mainly powerpc) are not
uploaded yet.

Cheers

Luk

[1] http://release.debian.org/transitions/html/perl5.14.html


-- 
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/4ec694fc.9010...@debian.org

Re: Perl transition blockers: candidates for testing removal

[Luk Claes]

On 11/18/2011 08:56 PM, Julien Cristau wrote:
> On Fri, Nov 18, 2011 at 20:52:48 +0100, gregor herrmann wrote:
> 
>>> * genders (#646286): patch ready, maybe NMU?
>>
>> Uploaded in the meantime.
>>
> Uploaded, but still broken.

Maybe the patch was applied without running the autotools?

Cheers

Luk


-- 
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/4ec6dade.60...@debian.org

Re: Please unblock ptex-bin 3.1.10+0.04b-2.1

[Luk Claes]

Sven Hoexter wrote:
> Hi,
> please unblock ptex-bin 3.1.10+0.04b-2.1, this should resolve #503543.

already unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: please hint git-buildpackage 0.4.40 into testing

[Luk Claes]

Guido Günther wrote:
> Hi,
> please allow git-buildpackage into testing. The changes between 0.4.36
> and 0.4.40 were mostly documentation and bugfixes. 0.4.40 is needed to
> work properly with Git 1.6 (which plenty of people will switch to during
> lenny's lifecycle).

0.4.43 unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: approval for planned upload of policyd-weight 0.1.14.17-5

[Luk Claes]

Jan Wagner wrote:
> Hi Neil,
> 
> On Tuesday 11 November 2008 18:59, Neil McGovern wrote:
>> All ok, please upload and ping when it's approaching time for an
>> unblock.
> 
> the package was uploaded 3 days ago.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Freeze exception for libgeo-ipfree-perl/0.2-7

[Luk Claes]

gregor herrmann wrote:
> Hi release team,
> 
> I'd like to ask for a freeze exception for libgeo-ipfree-perl, 0.2-7.
> 
> This version fixes #505736 - outdated and incorrect country data file.
> 
> Summary:
> libgeo-ipfree-perl contains a country data file (with mappings
> between IP address ranges and countries). The version in the package
> before 0.2-7 was both outdated and incorrect, and made the whole
> package rather useless.
> 
> 0.2-7 now ships a newly generated ipscountry.dat; all other changes
> are kept to the necessary minumum.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: t-p-u upload for mxallowd

[Luk Claes]

Niko Tyni wrote:
> Hi release team,
> 
> as discussed earlier, mxallowd needs a tpu upload due to an uncoordinated
> libnetfilter-queue sid upload.
> 
> The maintainer asked me to handle this, so here's the proposed debdiff(s).
> 
> The first, very short one is against the current sid version (1.6b-2)
> already unblocked by Luk but invalidated by libnetfilter-queue.
> 
> The second one is the complete diff against the current lenny version
> (1.6a-2).
> 
> Please ack and I'll upload.

ack :-)

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Some unblock requests, again

[Luk Claes]

Josselin Mouette wrote:

> gnome-settings-daemon (2.22.2.1-2) unstable; urgency=low
> 
> gnome-power-manager (2.22.1-4) unstable; urgency=low
> 
> gksu (2.0.0-6) unstable; urgency=low
> 
> epiphany-browser (2.22.3-8) unstable; urgency=low
> 
> fontconfig (2.6.0-2) unstable; urgency=low

All unblocked (version in unstable)

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: unblock request munin 1.2.6-8

[Luk Claes]

Holger Levsen wrote:
> Hi,
> 
> please unblock munin 1.2.6-8, it has been sitting in sid for ten days without
> collecting any new errors. 1.2.6-8 only contains some polishing and trivial
> fixes which make it function nicer and/or safer.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#475737: remove otrs2 from lenny?

[Luk Claes]

Thomas Viehmann wrote:
> Hi,
> 
> given that there seems to be limited interest in fixing the #475737 (3
> weeks since reopen without further comments), how about removing otrs2
> from lenny?

I'll have a look at fixing it.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: unblock requests for rails 2.1.0-6

[Luk Claes]

Adam Majer wrote:
> Please unblock rails 2.1.0-6
> 
> There is a small upstream security fix included in that release. Debian
> patch is available on git [1]. There is also an upstream announcement of
> the security patch on Google Groups [2].

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: please unblock tor 0.2.0.32-1

[Luk Claes]

Peter Palfrader wrote:
> Hi,
> 
> I would like to get tor 0.2.0.32-1 into lenny.
> 
> It's a new upstream version of the current stable tree.  That means it
> only saw bugfixes and no new features.
> 
> At least one of the fixes is a security fix in the traditional sense:
> Tor didn't properly drop supplementary group entries on startup.  See
> the changelog for a list of other bug fixes.

unblocked, set age-days to 8

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please consider unblock kernel-package/11.013

[Luk Claes]

Manoj Srivastava wrote:
> Hi,
> 
> This version corrects a bug that caused kernel images on sparc
>  to fail, and that bug is in testing as well. This closes a RC bug. (It
>  has just been uploaded with a high urgency, with a one line change, the
>  other changes have been in the archive for 9 days)
> 
> Other changes include:
>  a) A new french translation (documentation)
>  b) A lower bound on the po41 build dependency to ease backports, 
>  c) Handling in kernel Xen code
>  d) Include the full set of headers for the x86 architecture.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for fakeroot_1.11

[Luk Claes]

dann frazier wrote:
> hey,
>  fakeroot_1.11 fixes a bug that prevents eclipse from building from
> source. Since fakeroot is used by sbuild on our buildds, a fakeroot
> update is necessary to ensure that we can rebuild eclipse updates
> for lenny.
> 
> I'm not a fakeroot maintainer, but the maintainer is ok with this:
> 
>  Clint: looks like eclipse built everywhere, you wanna
> ask d-release for a lenny exception?
>  dannf: no, but feel free

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#501253: Reappear on 0.7.19

[Luk Claes]

close 501253
thanks

Eugene V. Lyubimkin wrote:
> Deng Xiyue wrote:
>> Followup-For: Bug #501253
>>
>> reopen 501253
>> found 501253 0.7.19
>> thanks
>>
>> Now apt-utils 0.7.19 brings back libdb4.4 again, at least on i386.
>> Hope it's just a unclean build environment.  If it is the case, it'll
>> be great for apt maintianers to consider using clean chroot like
>> pbuilder so that it won't happen again.
> Arrgh. Again...
> 
> Thanks for reporting.
> 
> Dear release managers, please schedule rebuild:
> 
> apt_0.7.19, Rebuild against newer libdb fixes #501253, (?), i386

binNMU scheduled. One cannot automatically fix a bug in a binNMU, so
closing this bug now.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exceptions for texlive-extra

[Luk Claes]

Norbert Preining wrote:
> Hi all,
> 
> I guess you know the game, more license clean ups occurred in TeX Live:
> 
> The following happened from .dfsg.9 to .dfsg.10:
> 
> blacklist=removed from distribution (.orig.tar and bin debs):
>  - cellular
>  - cmastro
>  - china2e
> 
> OTOH, I reinstantiated calligra which got its license clean up, and add
> an entry to the list of licenses.
> 
> Finally, I also added some more license statements which we collected
> and I forgot to add till now.
> 
> And one more suggests to get some things working, nothing important.
> 
> Please unblock.

already unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unblock request: kpax 20080304-2

[Luk Claes]

Barry deFreese wrote:
> Hi,
> 
> Please unblock kpax 20080304-2.  Fixes RC bug.  Here is a debdiff of the
> changes:

Already unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: security issue unblocks

[Luk Claes]

Thijs Kinkhorst wrote:
> Hi,
> 
> Please unblock:
> 
> squirrelmail/2:1.4.15-4

> pdns/2.9.21.2-1

both unblocked

> Please accept from t-p-u:
> 
> redhat-cluster/2.20080801-4+lenny1

approved

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please unblock electric_8.07-2

[Luk Claes]

Onkar Shinde wrote:
> Hi,
> 
> Can you please unblock package 'electric' version 8.07-2?
> 'electric' was previously orphaned and removed from unstable/testing.
> It has been recently updated and brought under debian-java team
> umbrella.

Sorry, it's way too late to reintroduce packages into testing.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please unblock python-django 1.0.2-1

[Luk Claes]

Chris Lamb wrote:
> Hi -release,
> 
> Please unblock python-django 1.0.2-1. The associated changelog entry is:

> This is an upstream bugfix release with over 200 bug fixes [0], contains no
> new features and has no known backwards compatible changes [1] [2].

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for update Drgeo package in Lenny

[Luk Claes]

Francisco García wrote:
> Hello,
> I would like to update the package Drgeo [1] in lenny. I have
> made a NMU with this package fixing some bugs, and made some
> important improvements.
> One of the bugs I have closed has grave severity.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please unblock lxrandr and lxterminal for lenny

[Luk Claes]

Andrew Lee wrote:
> Dear Release Managers,
> 
> Please unblock lxrandr and lxterminal. The lxrandr closes #492509 and added
> a patch to solve the LVDS output cannot detect current resolution problem.
> And lxterminal closes #503388 and adjust it's priority for alternatives
> system.

both unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unblock iceweasel-l10n 3.0.4+debian-1

[Luk Claes]

Daniel Baumann wrote:
> Hi,
> 
> please unblock iceweasel-l10n 3.0.4+debian-1.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unblock request: genpower 1.0.5-2.3

[Luk Claes]

Barry deFreese wrote:
> Hi,
> 
> Please unblock genpower 1.0.5-2.3.  Mainly for the piuparts bug fix
> (#455026) but it also contains a few other small bugfixes.  Here are the
> changelog entries (Yes I messed up the first upload):

unblocked

cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for xserver-xorg-input-evdev

[Luk Claes]

Julien Cristau wrote:
> Hi,
> 
> xf86-input-evdev 2.0.8 is a bugfix release, see the upstream changelog
> below.  I'd like to see xserver-xorg-input-evdev/1:2.0.8-1 in lenny.
> 
> Most of the changes are due to a fix for resume, where the driver might
> have to reopen the device file, and make sure that it's still the same
> device as before suspend.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please unblock rsyslog 3.18.5-1

[Luk Claes]

Michael Biebl wrote:
> Hi release team,
> 
> please consider unblocking rsyslog 3.18.5-1.

> Although it is a new (bugfix only) upstream release, the actual code changes 
> are
> very small, as you can see from the attached debdiff. About 3/4 are
> documentation updates.
> 
> The upstream changes contain about a dozen bug fixes, two of them have already
> been reported against the BTS (#503940, #505991). Both are important bug 
> fixes.
> As the actual code changes are very small, I decided against backporting the
> fixes (for one, it would require additinal work and there is always the chance
> of screwing up a backport fix)
> 
> The packaging related changes are also important. Especially the fixes for
> #491672 and #500569.
> 
> Given that rsyslog is now our default syslog for new installations, I expect
> that people will also start migrating to rsyslog for old installations, so the
> fix for #491672 will ensure a smooth upgrade.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please hint util-vserver 0.30.216~r2772-5 [was: handling util-vserver regression]

[Luk Claes]

Micah Anderson wrote:
> Hi folks,
> 
> I've decided to go ahead and backport the pieces necessary to solve the
> RC bugs that exist due to the capability problems, the disabled cron and
> the kernel regression.
> 
> So, at your earliest convenience, please hint in 0.30.216~r2772-5 of
> util-vserver. 

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: redhat-cluster tmpfile fixes

[Luk Claes]

Stefan Fritsch wrote:
> Hi,
> 
> please accept redhat-cluster 2.20080801-4+lenny1 which I have just
> uploaded to testing-proposed-updates:
> 
>* Fix several tmpfile race conditions, among them CVE-2008-4192 and
>  CVE-2008-4579. (Closes: #496410)

approved

cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#502234: nvidia-cg-toolkit: perl runtime warnings during upgrade

[Luk Claes]

Andres Mejia wrote:
> On Thursday 23 October 2008 04:04:26 am Marc 'HE' Brockschmidt wrote:
>> "Andres Mejia" <[EMAIL PROTECTED]> writes:
>>> I have a fix for this (and similar issues I found with perlcritic)
>>> ready for upload. Could an exception be made for this kind of fix?
>> Patch? If this is a one-liner or something similar, I approve of getting
>> rid of the annoying warnings.
>>
>> Marc
> 
> I took care of this problem by taking care of the gentle warning produced by 
> Perl::Critic. It's not a one-liner, but I thought the other lines could pose 
> a problem in the future anyway, so I corrected them as well.
> 
> Just in case it's already been forgotten, I'm asking for a freeze exception 
> on 
> nvidia-cg-toolkit (2.0.0015.deb3).

unblocked

cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: list of possible QA hints

[Luk Claes]

Filippo Giunchedi wrote:
> On Fri, Nov 28, 2008 at 11:54:06AM +0100, Filippo Giunchedi wrote:
>> Hi,
>> is it possibile to hint those QA packages?
>>
>> The list contains packages with supposedly small changes (usually only in 
>> debian
>> revision). 
> 
> having a closer look there are only a few worth having:
> 
> rplay: 2300 popcon insts
> Closes: 389067 437921

Many changes for little gain: not unblocked.

> nedit 1600 popcon insts
> Closes: 431973

> tla 1100 popcon insts
> Closes: 493702

both unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please unblock chkrootkit 0.48-8

[Luk Claes]

Giuseppe Iuculano wrote:
> Hi,
> 
> please consider unblocking chkrootkit 0.48-8, it introduces several bug fixes.

unblocked

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]