gap migration to testing

[Bill Allombert]

Dear release team,

I would like gap 4.9.3 to enter testing before I upload gap 4.10.0 to
unstable. Unfortunately it seems to be stuck due to autopkgtests
of other packages that are failing but that are fixed in unstable.

Could something be done do about that ?

Thanks in advance for your answers,
Bill.

Re: Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Bill Allombert]

On Thu, Jun 15, 2017 at 03:16:17PM +0200, Cyril Brulebois wrote:
> Julien Cristau  (2017-06-15):
> > It sounds like openjdk-8 added two Breaks recently, one or both of
> > which are causing trouble, and none of which fix anything as bad as
> > this.  So I think we should remove the Breaks on tzdata-java from
> > openjdk-8-jdk-headless, and remove the Breaks on ca-certificates-java
> > from openjdk-8-jre-headless.  Would that fix the current issue?
> > 
> > From what I can see #863820 is at most a normal-severity issue.  Not
> > upgrading some packages is way way better than a failed upgrade.
> 
> I'm currently building an updated openjdk-8 with the attached changes
> to see what the upgrade-desktop test cases would look like.
> 
> Note: I've chosen to remove the “Breaks: ${jrehl:Breaks}” line from
> debian/control* so that I'm only touching these files, since d/rules
> seems to only set it to tzdata-java anyway, depending on the target
> dist.
> 
> I'll report the results afterwards, but as mentioned on IRC, even if
> that looks good in the end, fewer than 2 days to become confident it
> won't regress in other cases is really short. :(

It would be really nice if we could remove the circular dependency 
between openjdk-8 and ca-certificate before the release, otherwise
the stretch to buster upgrade will be a nightmare.
It always much easier to add circular dependency than to remove them.

Cheers,
Bill.

Bug#841911: transition: pari

[Bill Allombert]

On Tue, Oct 25, 2016 at 11:16:43AM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 25/10/16 10:48, Bill Allombert wrote:
> > On Tue, Oct 25, 2016 at 12:19:29AM +0200, Emilio Pozuelo Monfort wrote:
> >> Hi,
> >>
> >> On 24/10/16 13:44, Bill Allombert wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: transition
> >>>
> >>> Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
> >>> stable version, which bump the soname of libpari-gmp-tls4 to
> >>> libpari-gmp-tls5.
> >>>
> >>> libpari-gmp-tls5 is in the NEW queue.
> >>>
> >>> There are very few packages that build against libpari (I found only
> >>> two: lcalc and eclib).
> >>
> >> Do they build against the new version?
> > 
> > Yes, we checked that already.
> 
> Cool, go ahead then.

libpari-gmp-tls5 has cleared the NEW queue, so I have uploaded it to
unstable.

Cheers,
-- 
Bill. <ballo...@debian.org>

Imagine a large red swirl here. 

Bug#841911: transition: pari

[Bill Allombert]

On Tue, Oct 25, 2016 at 12:19:29AM +0200, Emilio Pozuelo Monfort wrote:
> Hi,
> 
> On 24/10/16 13:44, Bill Allombert wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
> > stable version, which bump the soname of libpari-gmp-tls4 to
> > libpari-gmp-tls5.
> > 
> > libpari-gmp-tls5 is in the NEW queue.
> > 
> > There are very few packages that build against libpari (I found only
> > two: lcalc and eclib).
> 
> Do they build against the new version?

Yes, we checked that already.

Cheers,
-- 
Bill. <ballo...@debian.org>

Imagine a large red swirl here. 

Bug#841911: transition: pari

[Bill Allombert]

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

Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
stable version, which bump the soname of libpari-gmp-tls4 to
libpari-gmp-tls5.

libpari-gmp-tls5 is in the NEW queue.

There are very few packages that build against libpari (I found only
two: lcalc and eclib).

Ben file:

title = "pari";
is_affected = .depends ~ "libpari-gmp-tls4" | .depends ~ "libpari-gmp-tls5";
is_good = .depends ~ "libpari-gmp-tls5";
is_bad = .depends ~ "libpari-gmp-tls4";

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Bill. 

Imagine a large red swirl here. 

Bug#772183: unblock: libjpeg6b/1:6b2-2

[Bill Allombert]

On Mon, Mar 16, 2015 at 11:09:10PM +0100, Niels Thykier wrote:
 Hi Bill,
 
 Just to make it clear:
 
  * You seem to be making the case that we have lost the ability to
produce (truly) LSB compliant binaries and the tech-ctte were not
fully informed about the true scope of the consequences of their
resolution.

No I am not making this case, because again, the CTTE referal is unrelated to
libjpeg62.  The CTTE did not statue on the removal of libjpeg62 from stable,
ans so did not have to consider this issue, or any other.

 * As it is, I currently consider this to be end of topic for me.
   Short of the tech-ctte reopening the case, I am /not/ expecting to
   reply to any further comments to this thread/topic.

What I have been asking for is a rationale for removing a package that has been
in stable for more than 15 years without any prior notice.

So are you suggesting I request the CTTE to ask you to publish a rationale for 
the
removal of libjpeg62 ?

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150319235242.ga31...@pari.math.u-bordeaux1.fr

Bug#772183: unblock: libjpeg6b/1:6b2-2

[Bill Allombert]

On Sat, Mar 14, 2015 at 11:22:17AM +0100, Niels Thykier wrote:
 On 2015-02-23 17:49, Niels Thykier wrote:
  Control: tags -1 wontfix
  
  [...]
  
  As debated in #774737, we will only be shipping with one implementation
  of libjpeg, so I am afraid I will have to decline this request.

Hello Niels,

The release team has yet to provide a rationale for this decision.
It is quite unprecedented for the release team to reject a package without
providing a justification.

IJG libjpeg62 has been in Debian for more than 15 years.
IJG libjpeg62 is still required for building LSB packages. Without it, jessie 
will not be usable
for building LSB packages.

Cheers,
Bill


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150314131238.ga29...@pari.math.u-bordeaux1.fr

Bug#772183: unblock: libjpeg6b/1:6b2-2

[Bill Allombert]

On Sat, Mar 14, 2015 at 04:58:37PM +0100, Niels Thykier wrote:
 On 2015-03-14 14:12, Bill Allombert wrote:
  On Sat, Mar 14, 2015 at 11:22:17AM +0100, Niels Thykier wrote:
  On 2015-02-23 17:49, Niels Thykier wrote:
  Control: tags -1 wontfix
 
  [...]
 
  As debated in #774737, we will only be shipping with one implementation
  of libjpeg, so I am afraid I will have to decline this request.
  
  Hello Niels,
  
  The release team has yet to provide a rationale for this decision.
  It is quite unprecedented for the release team to reject a package without
  providing a justification.
  
 
 Hi Bill,
 
 We (the RT and security team) have on numerous occasions chosen to only
 ship and support at most one implementation of a given
 interface/program/etc.  It happens on a regular basis.

Indeed, but this stay exceptional event and in all case so far some rationale
were provided. This is not the case here.  People ask me what happened and I
cannot answer.

  IJG libjpeg62 has been in Debian for more than 15 years.
  IJG libjpeg62 is still required for building LSB packages. Without it, 
  jessie will not be usable
  for building LSB packages.

 You mean to say that:
 
  1. our lsb packages will FTBFS/be uninstallable in Jessie in the
absence of libjpeg62?
 
  2. libjpeg62-turbo does not implement the [LSB 4.1 SPEC]?

No I do not mean any of these. libjpeg62-turbo can be used to execute LSB 
binaries.
However to compile true LSB binaries (that can run on non libjpeg-turbo LSB 
system) still
require IJG libjpeg62, because libjpeg-turbo pull in extra symbols.

 AFAICT, it cannot be 1) given that the lsb packages seems to depend on
 libjpeg62-turbo.  So I am guessing you mean 2)?  In which case, you seem
 to have failed to mention this to the tech-ctte when the issue was
 brought before them in [#717076].
   At least a quick search suggests that only Simon McVittie ever
 mentions LSB.  Though by all means, please prove me wrong if I missed it
 - I did not re-read the entire thread.
 
 If you indeed failed to mention it, then I suggest you ask the tech-ctte
 to reconsider their position.  Our decision will remain unchanged unless
 the tech-ctte amends their decision.

The question the CTTE was referred is unrelated to libjpeg62, and the CTTE did 
not
ask for my input.

Given its history, I never fancied there was actual plan to remove libjpeg62
from stable.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150314173334.ga5...@pari.math.u-bordeaux1.fr

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

On Wed, Feb 04, 2015 at 08:54:16PM +0100, Niels Thykier wrote:
 I am sorry you feel that way.  I assumed that you were aware, given that
 you replied to the tech-ctte decision in which our statement was
 included (in fact, you retained it in quoted part of your reply).

My understanding was and is still that the CTTE overrided the release team on
this point.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150204202818.GC23377@yellowpig

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

On Fri, Jan 23, 2015 at 08:02:38AM +0100, Niels Thykier wrote:
 I am afraid I do not see how removing libjpeg9 from testing is
 inconsistent with the tech-ctte decision. 

You need to reread the full decision in context.

 The very first item of their
 resolution text states that:
 
  1. [...] The release team does not want to have more than one libjpeg
 implementation.

This is in the Whereas part, not in the Therefore. Thus this is what the
release team want, but not necessarily what the TC has decided.

 Then further down, they follow up with:
 
 10. The Technical Committee resolves that libjpeg-turbo should
 become the libjpeg implementation in Debian, [...]

And this is the case now. However the TC did not say all other libjpeg
implementations need to be removed from testing.
Indeed wheezy includes both libjpeg6b and libjpeg8 so there is a 
precedent for that. At the very least it is customary to provide old
libraries in the next release as part of the oldlibs section.

Then the TC gives a detailed view fo what should happens:

12. Implementing the decision in 10 above will require removing
Provides: libjpeg-dev from libjpeg8, since such a virtual
package must be provided by only one real package at a time.
Therefore the Provides should be removed from the libjpeg8
package - in accordance with the transition plan -
notwithstanding the libjpeg8 maintainer's preference that
libjpeg8 should remain as the default libjpeg.  This change
should be made by the libjpeg8 maintainer; if the change is not
made within a reasonable time it should be done in an NMU by the
libjpeg-turbo maintainer.

This is an unambiguous statement that they only intent the Provides:
libjpeg-dev of libjpeg8 to be removed and not the whole package, otherwise
they would have stated it directly (in particular since removing libjpeg8
automatically remove the Provides making it a non-issue).
The text shows they anticipate the existence of multiple 'real libjpeg*-dev
packages' but only one providing libjpeg-dev.

And in any case, the release team never communicated to me their intent to
remove libjpeg6b, libjpeg8 and libjpeg9 from jessie. I only learned about
it in January from the archive notification. And so far no rationale has been
given.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150201230435.GA4545@yellowpig

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

On Thu, Jan 29, 2015 at 08:32:58PM +0100, Niels Thykier wrote:
 Control: tags -1 moreinfo
 
 On 2015-01-28 00:34, Bill Allombert wrote:
  On Fri, Jan 23, 2015 at 08:02:38AM +0100, Niels Thykier wrote:
  Hi,
 
  Could you list the features that the turbo-variant is missing, which are
  present in the current version of libjpeg-progs from Wheezy?  Are there
  any lacking features beyond the SmartScale feature?
  
  Yes, there are a number of missing features, most importantly,
  libjpeg8 libjpeg-progs produces more accurate colors by using a higher 
  quality
  sampling. cjpeg and djpeg also provide options for better quality control.
  
  The SmartScale extension is essentially a way to store the scaling 
  parameter in
  the JPEG image so that you do not to specify it when uncompressing the file.
  But you can use the scaling code without ever creating an actual JFIF file 
  with the
  SmartScale extension (e.g. when converting to a raster format).
  
  Cheers,
  
 
 As far as I am informed, regular jpegs encoded with libjpeg6 and
 libjpeg7 in general can be decoded by libjpeg-turbo.  Therefore, there
 should not be an incompatibility issue there.  The sole exception should
 be the use of non-standard DCT block sizes (i.e. any other than 8x8),
 which are only supported by the IJG version of libjpeg.

I agree.

 I am still not convinced that this is sufficient to turn over the
 decision to only have one libjpeg implementation in Jessie.

The two previous Debian releases had several libjpeg implementations.
Why this change and why now ? I find rather unfair that I spend time packaging
libjpeg9 to be told several month later than it would not be included in
stable for some unspecified reason.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129194037.GA30687@yellowpig

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

On Fri, Jan 23, 2015 at 08:02:38AM +0100, Niels Thykier wrote:
 Hi,
 
 Could you list the features that the turbo-variant is missing, which are
 present in the current version of libjpeg-progs from Wheezy?  Are there
 any lacking features beyond the SmartScale feature?

Yes, there are a number of missing features, most importantly,
libjpeg8 libjpeg-progs produces more accurate colors by using a higher quality
sampling. cjpeg and djpeg also provide options for better quality control.

The SmartScale extension is essentially a way to store the scaling parameter 
in
the JPEG image so that you do not to specify it when uncompressing the file.
But you can use the scaling code without ever creating an actual JFIF file with 
the
SmartScale extension (e.g. when converting to a raster format).

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150127233450.GA1407@yellowpig

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

Control: tags -1 -moreinfo

On Thu, Jan 22, 2015 at 05:39:46PM +0100, Niels Thykier wrote:
 Control: tags -1 moreinfo
 
 Hi Bill,
 
 Please forgive me if I misunderstood something; I was not too involved
 in the libjpeg transition.
 
 It is my understanding that there is all utilities / services provided
 by libjpeg-progs is also provided by the turbo variant of same of
 package.  With libjpeg-turbo replacing libjpeg8, I cannot see the issue?

Hello Niels,

The libjpeg-turbo package provides an older version of theses tools which have
less capabilities than what is in wheezy already (and this is even more true
when compared with the jessie version). In particular the libjpeg-turbo version
is unable to process files that could be readn and generated by the wheezy
version.

Accordingly wheezy systems with libjpeg-progs will not have libjpeg-progs
replaced by libjpeg-turbo-progs automatically when upgrading to jessie.

Furthermore, removing this package would be inconsistent with the decision
of the CTTE which called only for the removal of the Provides: libjpeg-dev
by libjpeg8, but not of the actual libjpeg8-dev package, and neither for
the wholesale removal of libjpeg8.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150122181552.GB30786@yellowpig

Bug#774737: unblock: libjpeg9/1:9a-2

[Bill Allombert]

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

Please allow libjpeg9 back in jessie.

The removal of libjpeg9 implies the removal of libjpeg-progs
which is in wheezy and used by a number of users, thus it
is not unused. It would be disruptive for wheezy to miss it.

Concerning bug #773232, it is spurious. This is a bug in a different pakage
which was fixed a long time ago. I dealt with it immediatly but somehow I
forgot to close it/reassign it, and I offer my apology for that. At this point
I was in holiday and forgot about it and I did not receive a reminder until
today.  This is done now.

unblock libjpeg9/1:9a-2

Thanks for your understanding,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150106222555.GA1318@yellowpig

Bug#773547: unblock: gap/4r7p5-2

[Bill Allombert]

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

Please unblock package gap to fix bug #772869

gap (4r7p5-2) unstable; urgency=low

  * gap-core.triggers: use interest-noawait. Thanks Guillem Jover.
Closes: #772869

 -- Bill Allombert ballo...@debian.org  Sun, 14 Dec 2014 20:35:04 +0100

(If for some reason you disagree with Guillem about the severity of this bug,
please adjust the severity instead.)

unblock gap/4r7p5-2

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
diff -Nru gap-4r7p5/debian/changelog gap-4r7p5/debian/changelog
--- gap-4r7p5/debian/changelog  2014-07-03 19:04:27.0 +0200
+++ gap-4r7p5/debian/changelog  2014-12-14 20:35:28.0 +0100
@@ -1,3 +1,10 @@
+gap (4r7p5-2) unstable; urgency=low
+
+  * gap-core.triggers: use interest-noawait. Thanks Guillem Jover.
+Closes: #772869
+
+ -- Bill Allombert ballo...@debian.org  Sun, 14 Dec 2014 20:35:04 +0100
+
 gap (4r7p5-1) unstable; urgency=low
 
   * New upstream release
diff -Nru gap-4r7p5/debian/gap-core.triggers gap-4r7p5/debian/gap-core.triggers
--- gap-4r7p5/debian/gap-core.triggers  2009-02-16 11:41:15.0 +0100
+++ gap-4r7p5/debian/gap-core.triggers  2014-12-14 20:35:45.0 +0100
@@ -1,2 +1,2 @@
-interest /usr/share/gap
-interest /usr/lib/gap
+interest-noawait /usr/share/gap
+interest-noawait /usr/lib/gap

Bug#773547: unblock: gap/4r7p5-2

[Bill Allombert]

On Fri, Dec 19, 2014 at 06:45:12PM +, Jonathan Wiltshire wrote:
 On Fri, Dec 19, 2014 at 07:33:00PM +0100, Bill Allombert wrote:
  Please unblock package gap to fix bug #772869
 
 Already unblocked by Niels on 16th Dec, please check excuses output first
 next time.

Sorry...

I received an email with
gap 4r7p5-1 is marked for autoremoval from testing on 2015-01-18
and I thought it meant I was required to request the unblock.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141219185629.GA26605@yellowpig

Bug#772183: unblock: libjpeg6b/1:6b2-2

[Bill Allombert]

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

Dera release team,

Please unblock package libjpeg6b (and unstuck it from NEW).

libjpeg6b binaries were hijacked by the libjpeg-turbo source package, but this
have been resolved. So I made a new libjpeg6b upload so that the libjpeg6b
binaries get rebuilt. However this caused libjpeg6b to be directed to the NEW
queue, which is still there. So it missed the freeze deadline

Given that libjpeg6b is in wheezy, and the package was fully expected to be
released in jessie before it was hijacked, I would appreciate if you would
unstuck it. 

unblock libjpeg6b/1:6b2-2

Thanks for your understanding,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141205224723.GA10277@yellowpig

Bug#771434: unblock: debian-policy/3.9.6.1

[Bill Allombert]

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

Please unblock package debian-policy

This fix a FTBFS with emacs 24.4 that did not occu with emacs 24.3

debian-policy (3.9.6.1) unstable; urgency=low

  * Fix FTBFS with emacs 24.4. Thanks to David Bremner da...@tethera.net
for the help. Closes: #769219

 -- Bill Allombert ballo...@debian.org  Mon, 17 Nov 2014 11:55:55 +0100

I join the full diff. Note that there is two useless files that are removed 
(they were included by mistake in the previous upload, sorry about that).

unblock debian-policy/3.9.6.1

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
diff -Nru 
debian-policy-3.9.6.0/0001-All-packages-using-Perl-vendorarch-directory-need-a-.patch
 
debian-policy-3.9.6.1/0001-All-packages-using-Perl-vendorarch-directory-need-a-.patch
--- 
debian-policy-3.9.6.0/0001-All-packages-using-Perl-vendorarch-directory-need-a-.patch
   2014-06-13 21:38:13.0 +0200
+++ 
debian-policy-3.9.6.1/0001-All-packages-using-Perl-vendorarch-directory-need-a-.patch
   1970-01-01 01:00:00.0 +0100
@@ -1,51 +0,0 @@
-From 007c07db2c549adef83b0c9019d90746117bd7df Mon Sep 17 00:00:00 2001
-From: Niko Tyni nt...@debian.org
-Date: Fri, 30 May 2014 14:10:22 +0300
-Subject: [PATCH] All packages using Perl vendorarch directory need a perlapi-*
- dependency
-
-Having $Config{vendorarch} change between Perl major versions (for
-multiarch or other reasons) implies that packages using it need a strict
-dependency on those versions of perl-base that have a compatible search
-path (@INC).
-
-The vast majority of these packages are binary (XS) modules, where we
-already require a dependency on the virtual package perlapi-*, provided
-by perl-base. The name of this virtual package will change when the
-interface between the Perl interpreter and the modules changes.
-
-If we consider @INC part of that interface, we can use the existing
-mechanism also for the few nonbinary modules using $Config{vendorarch}.
-This is a new requirement that currently affects six packages in
-the archive.

- perl-policy.sgml | 9 +
- 1 file changed, 5 insertions(+), 4 deletions(-)
-
-diff --git a/perl-policy.sgml b/perl-policy.sgml
-index c23f7c3..12cd82c 100644
 a/perl-policy.sgml
-+++ b/perl-policy.sgml
-@@ -388,14 +388,15 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/lt;tmpgt;
-   /sect1
- 
-   sect1 id=binary_modules
--headingBinary Modules/heading
-+headingBinary and Other Architecture Dependent Modules/heading
- p
-   Binary modules must specify a dependency on either
-   packageperl/package or packageperl-base/package with
-   a minimum version of the packageperl/package package
--  used to build the module, and must additionally depend on
--  the expansion of
--  packageperlapi-$Config{debian_abi}/package using
-+  used to build the module. Additionally, all binary modules
-+  (regardless of their installation directory) and any other modules
-+  installed into tt$Config{vendorarch}/tt must depend on the
-+  expansion of packageperlapi-$Config{debian_abi}/package using
-   the ttConfig/tt module. If tt$Config{debian_abi}/tt
-   is empty or not set, tt$Config{version}/tt must be used.
- /p
--- 
-2.0.0.rc4
-
diff -Nru debian-policy-3.9.6.0/debian/changelog 
debian-policy-3.9.6.1/debian/changelog
--- debian-policy-3.9.6.0/debian/changelog  2014-09-17 20:03:26.0 
+0200
+++ debian-policy-3.9.6.1/debian/changelog  2014-11-17 11:56:18.0 
+0100
@@ -1,3 +1,10 @@
+debian-policy (3.9.6.1) unstable; urgency=low
+
+  * Fix FTBFS with emacs 24.4. Thanks to David Bremner da...@tethera.net
+for the help. Closes: #769219
+
+ -- Bill Allombert ballo...@debian.org  Mon, 17 Nov 2014 11:55:55 +0100
+
 debian-policy (3.9.6.0) unstable; urgency=low
 
   [ Bill Allombert ]
diff -Nru debian-policy-3.9.6.0/debian/control 
debian-policy-3.9.6.1/debian/control
--- debian-policy-3.9.6.0/debian/control2014-09-17 20:02:32.0 
+0200
+++ debian-policy-3.9.6.1/debian/control2014-11-17 11:46:37.0 
+0100
@@ -10,7 +10,7 @@
debiandoc-sgml (= 1.1.47),
docbook-dsssl,
docbook-xml,
-   emacs-nox|emacs,
+   emacs-nox (= 24.4) | emacs (= 24.4),
groff,
jade,
links | elinks,
diff -Nru debian-policy-3.9.6.0/patch debian-policy-3.9.6.1/patch
--- debian-policy-3.9.6.0/patch 2014-07-30 15:46:36.0 +0200
+++ debian-policy-3.9.6.1/patch

Re: Bug#769273: bsdutils: Dependency on libsystemd0 violates policy

[Bill Allombert]

On Wed, Nov 12, 2014 at 03:04:56PM +0100, Andreas Henriksson wrote:
 Hello Tim Wootton, release-team, et.al.!
 
 Thanks for your bug report.
 
 On Wed, Nov 12, 2014 at 11:00:16AM +, Tim Wootton wrote:
  Package: bsdutils
  Version: 1:2.25.2-2
  Severity: serious
  Justification: Policy 2.5
  
  Dear Maintainer,
  
  libsystemd0 dependancy violates constraint at the end of section 2.5
  of the policy manual that requires packages not depend on packages
  with lower priority.
 
 This (general) problem has been discussed (several times?) on
 debian-devel already and as far as I remember and understood it was that
 raising the priority of the relevant systemd binary packages could be
 done but it did not solve any *practical* problem. Instead it seemed
 easier to just fix policy. I guess that's where everyone lost
 interest

It is well settled that priority changes are done throught the distribution
override file and not in the package control file and thus, an error of
priority is not a RC bug in the package.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112143511.GA5446@yellowpig

Bug#754988: Bug#763360 closed by Ondřej Surý ond...@sury.org

[Bill Allombert]

On Tue, Oct 07, 2014 at 10:31:45AM +0200, Ondřej Surý wrote:
 On Mon, Oct 6, 2014, at 21:14, Bill Allombert wrote:
   Version: 1:1.3.1-4
  
   My understanding is that this bug can be now closed as
   the libjpeg-progs are not built from src:libjpeg-progs and
   libjpeg62* binary package names has been accepted now.
  
  Excellent news! When do you plan to upload a version libjpeg-turbo that
  does not hijack libjpeg62 anymore ?
 
 JFTR I will list the consequences of any renaming that would happen:
 
 1. libjpeg-turbo62 (as an example) would still contain shared library
 libjpeg.so.62, thus it needs to Conflicts/Provides: libjpeg62, same
 applies for the libjpeg62-dev package vs libjpeg-turbo62-dev
 (Conflicts/Provides: libjpeg62-dev)

You are painting a bleaker picture than what is really required.
Since the package are fully compatible, the conflict is easily avoided by
moving some files a bit and then using the alternative system. 

When do you plan to operate the renaming ?

I need to reupload libjpeg62 with a bumped epoch before the freeze.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141009224642.GA12136@yellowpig

Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages

[Bill Allombert]

On Fri, Oct 03, 2014 at 03:03:09PM +0200, Andreas Barth wrote:
 I hope we could leave it as that for the upload - nobody has a time
 machine to undo the upload, but we could try to make it better now and
 discuss where we should go.

Ok, let's focus on libjpeg-progs, since I do not think there is a disagreement
about it. What would you propose as a course of action that allow either
libjpeg8 or lijpeg9 to provide libjpeg-progs with minimal disruption to the
archive ?

While libjpeg-progs 1:1.3.1-4 does not build libjpeg-progs, rmadison 
libjpeg-progs
still report
 libjpeg-progs | 8d-1+deb7u1 | wheezy  | amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 libjpeg-progs | 1:1.3.1-3   | jessie  | all
 libjpeg-progs | 1:1.3.1-3   | sid | all

Thus somehow the offending binary package has not been removed from the archive.

Cheers, 
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141004184831.GA10362@yellowpig

Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages

[Bill Allombert]

On Fri, Oct 03, 2014 at 01:41:02AM +0200, Emilio Pozuelo Monfort wrote:
 On 30/09/14 11:32, Bill Allombert wrote:
 On Mon, Sep 29, 2014 at 08:55:16PM +0200, Ondřej Surý wrote:
 Bill,
 
 I am very sorry that I have not Cced everything related to the
 libjpeg-transition
 to you. I have honestly believed that you and everyone else involved was
 following the transition plan as mentioned in #717076#225. As for the
 takover
 of the libjpeg62* packages it was discussed in the transition plan bug
 #754988.
 
 The CTTE made it clear I was only required to remove the Provides: 
 libjpeg-dev
 It did not authorise you to hijack the libjpeg8 and libjpeg62 binaries, and
 you should not have made a plan that required it.
 
 Hijacking binary packages that are still provided by other sources is 
 extremely
 crude. At the minimum, you should have waited for me to stop providing them
 before uploading to unstable.
 
 Please abide by the CTTE decision and revert that.  You cannot ask me to obey
 the CTTE decision while blatantly disregarding it.
 
 You have been bullying me from the start, but this tops it all.
 
 This comment makes me sad...
 
 I don't know how not hijacking a package that is in old libs, that
 should have been removed from the archive a long time ago, and that
 is not going to be installable anyway even if it's not hijacked is
 going to be any useful, but oh well...
 
 You seem to think that Ondřej did this in bad faith, but it just

Bad faith ? No I do not think so.

 seemed like the sensible thing to do, and I didn't see any problem
 with the proposed plan. After all, libjpeg62 had been long
 deprecated in favor of libjpeg8. Neither of us thought you would
 care about libjpeg62 anymore...

... and neither of you bothered to ask me.
libjpeg62 is required for compatibility with the LSB.
libjpeg62-dev is required for building LSB packages.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141003101421.GA27230@yellowpig

Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages

[Bill Allombert]

On Fri, Oct 03, 2014 at 12:37:09PM +0200, Emilio Pozuelo Monfort wrote:
 seemed like the sensible thing to do, and I didn't see any problem
 with the proposed plan. After all, libjpeg62 had been long
 deprecated in favor of libjpeg8. Neither of us thought you would
 care about libjpeg62 anymore...
 
 ... and neither of you bothered to ask me.
 
 I would have thought you would be following the ctte bug and you
 would have seen the transition bug, which was mentioned in there.
 But I could have certainly added an explicit Cc. Sorry for that.

In any case, you should have noticed I did not sent email confirming I was
ready for this.

 libjpeg62 is required for compatibility with the LSB.
 libjpeg62-dev is required for building LSB packages.
 
 Both of those are provided by libjpeg-turbo, with 100% compatible
 ABI. So what is the problem with LSB compliance? Does the LSB
 require that libjpeg.so.62 be the IJG version of the library, and
 that it be shipped in a libjpeg62 .deb package?
 
 AFAICS from reading 
 http://refspecs.linuxfoundation.org/LSB_3.1.1/LSB-Desktop-generic/LSB-Desktop-generic/toclibjpeg.html,
 what is required is a library with SONAME libjpeg.so.62 implementing
 those symbols and having those headers. AFAIK, libjpeg-turbo's
 libjpeg62 does that, so we should still be LSB-compliant. Isn't that
 right?

It still would be prudent to keep the plain old libjpeg62 in Debian so
that people can rebuild their code with the original libjpeg62.a for
debugging purpose, especially if the transition is done so close to the
freeze. I had received enquiries from people running ubuntu how they can
rebuild their apps without libjpeg-turbo because it interfered with debugging.

In any case I do not see any benefit for libjpeg-turbo to provide them, except
to create confusion.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141003224719.GB5477@yellowpig

Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages

[Bill Allombert]

On Mon, Sep 29, 2014 at 08:55:16PM +0200, Ondřej Surý wrote:
 Bill,
 
 I am very sorry that I have not Cced everything related to the
 libjpeg-transition
 to you. I have honestly believed that you and everyone else involved was
 following the transition plan as mentioned in #717076#225. As for the
 takover
 of the libjpeg62* packages it was discussed in the transition plan bug
 #754988.

The CTTE made it clear I was only required to remove the Provides: libjpeg-dev
It did not authorise you to hijack the libjpeg8 and libjpeg62 binaries, and
you should not have made a plan that required it.

Hijacking binary packages that are still provided by other sources is extremely
crude. At the minimum, you should have waited for me to stop providing them
before uploading to unstable.

Please abide by the CTTE decision and revert that.  You cannot ask me to obey
the CTTE decision while blatantly disregarding it.

You have been bullying me from the start, but this tops it all.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140930093241.GA12328@yellowpig

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

[Bill Allombert]

On Fri, Aug 15, 2014 at 06:31:39PM +0200, Michael Biebl wrote:
 Am 15.08.2014 18:10, schrieb Michael Biebl:
  Am 15.08.2014 17:47, schrieb Gerrit Pape:
  Severity: serious
  Justification: Policy 2.5
 
 [..]
 
  That this rule is violated in hundreds of cases [1] clearly shows that
  there is something wrong which needs to be addressed in a more idiomatic
  way.
 
  [1] https://qa.debian.org/debcheck.php?dist=sidlist=priorityarch=ANY
 
 Gerrit, I see you started filing RC bugs for this.

Please do not report RC bug for this. Priorities are adjusted by the FTP master
team by batch using the overrides file. There is no need to report bugs against
the packages.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815165144.GB27464@yellowpig

Bug#752244: pu: package libjpeg8/8d-1

[Bill Allombert]

On Sun, Jun 22, 2014 at 07:27:14PM +0100, Adam D. Barratt wrote:
 Control: tags -1 + pending
 
 On Sat, 2014-06-21 at 19:00 +0100, Adam D. Barratt wrote:
  On Sat, 2014-06-21 at 19:04 +0200, Bill Allombert wrote:
   On Sat, Jun 21, 2014 at 04:11:10PM +0100, Adam D. Barratt wrote:
On Sat, 2014-06-21 at 16:57 +0200, Bill Allombert wrote:
 The fix is available in version 8d-2 and 6b1-4 in testing which are
 otherwise identical to version 8d-1 and 6b1-3 in stable.
 I join the debdiff.
 
 Please advise to proper procedure for upload.

Please version the packages as 8d-1+deb7u1 / 6b1-3+deb7u1, use wheezy
as the changelog distribution, build the packages on a wheezy system or
suitable chroot and upload; thanks.
   
   OK, I have uploaded 8d-1+deb7u1. Could you check I did not make anything
   wrong before I upload 6b1-3+deb7u1 ?
  
  The debdiff looks fine to me and our automatic installability tests
  didn't flag any issues.
 
 Both uploads flagged for acceptance; thanks.

I like to thank you for your quick replies to my enquiries.
It allowed me to complete this in a single day.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140622195415.GA14400@yellowpig

Bug#752244: pu: package libjpeg8/8d-1

[Bill Allombert]

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

Dear Release team,

I have been requested by the security team to update libjpeg8 and libjpeg6b1
in stable to fix CVE-2013-6629 and CVE-2013-6630. (see #729867).
The fix is available in version 8d-2 and 6b1-4 in testing which are
otherwise identical to version 8d-1 and 6b1-3 in stable.
I join the debdiff.

Please advise to proper procedure for upload.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
diff -Nru libjpeg8-8d/debian/changelog libjpeg8-8d/debian/changelog
--- libjpeg8-8d/debian/changelog	2012-01-29 19:51:42.0 +0100
+++ libjpeg8-8d/debian/changelog	2013-12-03 23:07:33.0 +0100
@@ -1,3 +1,10 @@
+libjpeg8 (8d-2) unstable; urgency=high
+
+  * Apply upstream patch to fix CVE-2013-6629 and CVE-2013-6630. 
+closes: #729867.
+
+ -- Bill Allombert ballo...@debian.org  Mon, 02 Dec 2013 23:11:23 +0100
+
 libjpeg8 (8d-1) unstable; urgency=low
 
   * The Lucas release
diff -Nru libjpeg8-8d/debian/patches/fix-CVE-2013-6629_6630 libjpeg8-8d/debian/patches/fix-CVE-2013-6629_6630
--- libjpeg8-8d/debian/patches/fix-CVE-2013-6629_6630	1970-01-01 01:00:00.0 +0100
+++ libjpeg8-8d/debian/patches/fix-CVE-2013-6629_6630	2013-12-02 23:07:35.0 +0100
@@ -0,0 +1,108 @@
+Index: libjpeg8-8d/jdmarker.c
+===
+--- libjpeg8-8d.orig/jdmarker.c	2013-12-02 22:27:12.205907726 +0100
 libjpeg8-8d/jdmarker.c	2013-12-02 23:07:21.300024752 +0100
+@@ -240,7 +240,7 @@
+ /* Process a SOFn marker */
+ {
+   INT32 length;
+-  int c, ci;
++  int c, ci, i;
+   jpeg_component_info * compptr;
+   INPUT_VARS(cinfo);
+ 
+@@ -278,11 +278,27 @@
+ cinfo-comp_info = (jpeg_component_info *) (*cinfo-mem-alloc_small)
+ 			((j_common_ptr) cinfo, JPOOL_IMAGE,
+ 			 cinfo-num_components * SIZEOF(jpeg_component_info));
+-  
+-  for (ci = 0, compptr = cinfo-comp_info; ci  cinfo-num_components;
+-   ci++, compptr++) {
++
++  for (ci = 0; ci  cinfo-num_components; ci++) {
++INPUT_BYTE(cinfo, c, return FALSE);
++/* Check to see whether component id has already been seen   */
++/* (in violation of the spec, but unfortunately seen in some */
++/* files).  If so, create fake component id equal to the   */
++/* max id seen so far + 1. */
++for (i = 0, compptr = cinfo-comp_info; i  ci; i++, compptr++) {
++  if (c == compptr-component_id) {
++	compptr = cinfo-comp_info;
++	c = compptr-component_id;
++	compptr++;
++	for (i = 1; i  ci; i++, compptr++) {
++	  if (compptr-component_id  c) c = compptr-component_id;
++	}
++	c++;
++	break;
++  }
++}
++compptr-component_id = c;
+ compptr-component_index = ci;
+-INPUT_BYTE(cinfo, compptr-component_id, return FALSE);
+ INPUT_BYTE(cinfo, c, return FALSE);
+ compptr-h_samp_factor = (c  4)  15;
+ compptr-v_samp_factor = (c )  15;
+@@ -305,7 +321,7 @@
+ /* Process a SOS marker */
+ {
+   INT32 length;
+-  int i, ci, n, c, cc;
++  int c, ci, i, n;
+   jpeg_component_info * compptr;
+   INPUT_VARS(cinfo);
+ 
+@@ -328,24 +344,38 @@
+   /* Collect the component-spec parameters */
+ 
+   for (i = 0; i  n; i++) {
+-INPUT_BYTE(cinfo, cc, return FALSE);
+ INPUT_BYTE(cinfo, c, return FALSE);
+-
++
++/* Detect the case where component id's are not unique, and, if so, */
++/* create a fake component id using the same logic as in get_sof.   */
++for (ci = 0; ci  i; ci++) {
++  if (c == cinfo-cur_comp_info[ci]-component_id) {
++	c = cinfo-cur_comp_info[0]-component_id;
++	for (ci = 1; ci  i; ci++) {
++	  compptr = cinfo-cur_comp_info[ci];
++	  if (compptr-component_id  c) c = compptr-component_id;
++	}
++	c++;
++	break;
++  }
++}
++
+ for (ci = 0, compptr = cinfo-comp_info; ci  cinfo-num_components;
+ 	 ci++, compptr++) {
+-  if (cc == compptr-component_id)
++  if (c == compptr-component_id)
+ 	goto id_found;
+ }
+ 
+-ERREXIT1(cinfo, JERR_BAD_COMPONENT_ID, cc);
++ERREXIT1(cinfo, JERR_BAD_COMPONENT_ID, c);
+ 
+   id_found:
+ 
+ cinfo-cur_comp_info[i] = compptr;
++INPUT_BYTE(cinfo, c, return FALSE);
+ compptr-dc_tbl_no = (c  4)  15;
+ compptr-ac_tbl_no = (c )  15;
+-
+-TRACEMS3(cinfo, 1, JTRC_SOS_COMPONENT, cc,
++
++TRACEMS3(cinfo, 1, JTRC_SOS_COMPONENT, compptr-component_id,
+ 	 compptr-dc_tbl_no, compptr-ac_tbl_no);
+   }
+ 
+@@ -461,6 +491,8 @@
+ if (count  256 || ((INT32) count)  length)
+   ERREXIT(cinfo, JERR_BAD_HUFF_TABLE);
+ 
++MEMZERO(huffval, SIZEOF(huffval)); /* pre-zero array for later copy */
++
+ for (i = 0; i  count; i++)
+   INPUT_BYTE(cinfo, huffval[i], return FALSE);
+ 
diff -Nru libjpeg8-8d/debian/patches/series libjpeg8-8d/debian/patches/series
--- libjpeg8-8d/debian/patches/series	2011-07-08 23:06:32.0 +0200
+++ libjpeg8-8d/debian/patches/series	2013-12-02 23:21:46.0 +0100
@@ -1,2 +1,3 @@
 use

Bug#752244: pu: package libjpeg8/8d-1

[Bill Allombert]

On Sat, Jun 21, 2014 at 04:11:10PM +0100, Adam D. Barratt wrote:
 Control: tags -1 + wheezy confirmed
 Control: clone -1 -2
 Control: retitle -2 pu: package libjpeg62/6b1-3
 
 On Sat, 2014-06-21 at 16:57 +0200, Bill Allombert wrote:
  I have been requested by the security team to update libjpeg8 and libjpeg6b1
  in stable to fix CVE-2013-6629 and CVE-2013-6630. (see #729867).
 
 In that case there need to be two bugs; cloning.
 
  The fix is available in version 8d-2 and 6b1-4 in testing which are
  otherwise identical to version 8d-1 and 6b1-3 in stable.
  I join the debdiff.
  
  Please advise to proper procedure for upload.
 
 Please version the packages as 8d-1+deb7u1 / 6b1-3+deb7u1, use wheezy
 as the changelog distribution, build the packages on a wheezy system or
 suitable chroot and upload; thanks.

OK, I have uploaded 8d-1+deb7u1. Could you check I did not make anything
wrong before I upload 6b1-3+deb7u1 ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140621170414.GA17522@yellowpig

Re: First autoremovals happen in about 8 days

[Bill Allombert]

On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:
 Hi,
 
 This is a friendly reminder.  If you are listed below, then the listed
 packages of yours will be automatically removed from testing within 15
 days.  The first batch of automatic removals will happen in about 8
 days.
 
 Please remember that fixing your RC bug(s) can sometimes be as
 simple as correcting the metadata of the bugs (see also #725321[0]) or
 (where inflated) downgrade the severity of the bug.
 
 This mail was a one-time public service annoucement; I *do not*
 intend to send out reminders in the future.  Remember that you can
 pull the same data from [1] or [2].

I am concerned that in the event a package is removed from testing,
the people most interested with restoring the package will miss the
removal, since the package will stay installed on their systems.
This, then, cause stable releases to be missing packages that users
are depending on, which reduce the value of the distribution.

This is not a new problem, and it is not entirely clear whether such
early removal will reduce or increase this issue. However we should
address it if we want Debian stable releases to be something users
can rely on.

So while it is possible that the _maintainer_ is not needing a friendly
remainder, other interested third-party might.

Cheers,
Bill.


-- 
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/20131007220421.ga17...@master.debian.org

ports and multiarch

[Bill Allombert]

On Thu, Sep 19, 2013 at 10:38:29AM +0200, Niels Thykier wrote:
 We also got a number of people interested in architectures not currently
 in unstable.  These are:
 
   alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD)
   arm64: Wookey (DD)
   parisc/hppa: Helge Deller (!DD)
   ppc64: Steven Gawroriski (!DD)
   sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD)

We should add official support for ppc64 and maybe sparc64 at least for use
as a multiarch extension to ppc/sparc, even if we do not have time to make a 
full
port. Otherwise the introduction of multiarch will likely result in a regression
of functionnality on ppc system.

Indeed, lib64* packages are superceded by multiarch and often are removed
due to file conflict with the multi-arch equivalent. However this leads
to a regression for nominally-32bit but 64bit-capable architectures that
do not have a 64bit suit to draw from. 

This is especially an issue for ppc, which has a fast 64bit arithmetic.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


-- 
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/20130930212206.ga5...@master.debian.org

Bug#697589: unblock: gnome-menus/3.4.2-7

[Bill Allombert]

On Tue, Feb 19, 2013 at 08:30:15PM +0100, Bill Allombert wrote:
 On Tue, Feb 19, 2013 at 07:15:11PM +, Jonathan Wiltshire wrote:
  On Thu, Feb 14, 2013 at 08:47:16PM +0100, Josselin Mouette wrote:
   Le vendredi 25 janvier 2013 à 13:52 +0100, Josselin Mouette a écrit : 
Le lundi 07 janvier 2013 à 11:41 +0100, Josselin Mouette a écrit : 
 gnome-menus (3.4.2-7) unstable; urgency=low
 
   * gnome-menus.postinst: clean up the desktop files once upon 
 upgrades, 
 in order to get rid of files generated by a buggy script.

Ping?
  
  Sorry you've been waiting. On the basis that Julien downgraded #696530 to
  normal this isn't strictly RC; conversely, menu-xdg has considerable
  popcon.
  
  As I understand it the problem shows up when update-menus is run as a user.
  Bill, is that an unusual thing to do or would you expect it from many
  users?
 
 I would says this is rather unusual for GNOME users.

I like to add that if they do not like the result of running update-menus, they
can revert it by running update-menus --remove, or they can configure menu not
to use menu-xdg by doing mkdir ~/.menu-methods

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


--
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/20130220173951.GC21084@yellowpig

Bug#697589: unblock: gnome-menus/3.4.2-7

[Bill Allombert]

On Tue, Feb 19, 2013 at 07:15:11PM +, Jonathan Wiltshire wrote:
 On Thu, Feb 14, 2013 at 08:47:16PM +0100, Josselin Mouette wrote:
  Le vendredi 25 janvier 2013 à 13:52 +0100, Josselin Mouette a écrit : 
   Le lundi 07 janvier 2013 à 11:41 +0100, Josselin Mouette a écrit : 
gnome-menus (3.4.2-7) unstable; urgency=low

  * gnome-menus.postinst: clean up the desktop files once upon 
upgrades, 
in order to get rid of files generated by a buggy script.
   
   Ping?
 
 Sorry you've been waiting. On the basis that Julien downgraded #696530 to
 normal this isn't strictly RC; conversely, menu-xdg has considerable
 popcon.
 
 As I understand it the problem shows up when update-menus is run as a user.
 Bill, is that an unusual thing to do or would you expect it from many
 users?

I would says this is rather unusual for GNOME users.
I will close #696530 anyway. The level of animosity displayed in this report
makes it the only option.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


--
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/20130219193015.GA14877@yellowpig

Bug#691789: unblock: popularity-contest/1.56

[Bill Allombert]

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

Dear release team

Please unblock package popularity-contest 1.56.
This is an l10n upload to add debconf translations.
Here the changelog:

popularity-contest (1.56) unstable; urgency=low

  [ Christian Perrier ]
  [ Debconf translations ] 
  * Latvian (Rūdolfs Mazurs).  Closes: #674661
  * Lithuanian (Rimas Kudelis).  Closes: #675629
  * Galician (Jorge Barreiro).  Closes: #676988
  * Welsh (Daffyd Tomos).
  * Uyghur (Sahran).  Closes: #627009

 -- Bill Allombert ballo...@debian.org  Tue, 25 Sep 2012 21:13:44 +0200

unblock popularity-contest/1.56

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


--
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/20121029173743.GA12665@yellowpig

Re: state of libjpeg transition

[Bill Allombert]

On Wed, Jun 13, 2012 at 08:50:54PM +0200, Julien Cristau wrote:
 On Sun, Jun 10, 2012 at 18:19:20 +0200, Bill Allombert wrote:
 
  Dear release team,
  
  I have NMUed most of the remaining packages that build-depended on 
  libjpeg62-dev.
  
  I think the only remaining packages are:
compiz-fusion-plugins-main
kphotoalbum
  
 AFAICT there's also
 - netgen

The version of netgen in testing does not build-depends on libjpeg62-dev.

 - crystalspace (not in testing, so meh)
 - fgfs-atlas

RC buggy

 - libicns

The binaries does not use libjpeg

 - qcam
This seems one of the most obsolete package in the archive:
Only available for i386.
From the synopsis:
 Note that nowadays there is support in the 2.2 kernels for this camera in
 the video4linux project, which is probably better than this.
From the changelog (2006):
* Wondering if anyone actually uses this anymore...

 - eagle (non-free, don't care much)
 - seaview (same)
 - teamspeak-client (same)

At least I am not going to NMU non-free packages.

Thanks for your check,

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20120613192741.GE32597@yellowpig

state of libjpeg transition

[Bill Allombert]

Dear release team,

I have NMUed most of the remaining packages that build-depended on 
libjpeg62-dev.

I think the only remaining packages are:
  compiz-fusion-plugins-main
  kphotoalbum

but they seems quite old.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20120610161920.GA6938@yellowpig

proposed binNMU for libjpeg transition

[Bill Allombert]

Dear Debian release team,

In the interest of moving forward with the libjpeg8 migration, I suggest to
binNMU packages that depends on libjpeg62 but do not Build-Depends (directly)
on libjpeg62-dev

Please find the list below assuming my computation are correct.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
aeskulap 0.2.2b1-8
aterm 1.0.1-7
burgerspace 1.9.0-3
digikam 2:1.9.0-3
dvdauthor 0.7.0-1.1
emboss 6.3.1-6
flatzebra 0.1.5-4
freedroid 1.0.2+cvs040112-2
freedroidrpg 0.14.1-1
gnudatalanguage 0.9.1-1
h5utils 1.12.1-1
jmagick 6.2.6-0-8
leptonlib 1.68-4
libparagui1.1 1.1.8-3.1
logstalgia 1.0.3-2
nagios3 3.2.3-3
oggvideotools 0.8-1
open-font-design-toolkit 1.0-3
pdl 1:2.4.7+dfsg-2
pfstools 1.8.1-2
photoprint 0.4.1-4
plplot 5.9.5-4
pygdchart2 0.beta1-3.4
ruby-rmagick 2.13.1-5
sdlbasic 0.0.20070714-3
sdlperl 2.2.5-1
sunclock 3.56-9
tesseract 2.04-2.1
wv 1.2.4-2
x11vnc 0.9.12-1
xpaint 2.9.1.4-3
xsidplay 2.0.3-3

binNMU for libjpeg8 migration (2nd try)

[Bill Allombert]

Dear release team,

In the interest of moving forward with the libjpeg8 migration,
I suggest to binNMU packages that build-depends on libjpeg-dev but still depends
on libjpeg62.

Please find the list below assuming my computation are correct.

Furthermore how do you like to proceed with the remaining packages that 
Build-Depends
on libjpeg62-dev ? Should I report bugs for all of them ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
afterstep 2.2.11-4
analog 2:6.0-19
ayttm 0.6.3-2
dcraw 8.99-1
djvulibre 3.5.24-8
epm 4.2-1
ffmpegthumbnailer 2.0.6-4
fgfs-atlas 0.3.1-2
flightgear 2.0.0-4
fox1.6 1.6.44-1.1
freeimage 3.10.0-4
gargoyle-free 2010.1-2
ghostscript 9.02~dfsg-3
gimp 2.6.11-3
gle-graphics 4.2.2-4
gnash 0.8.10~git20110618-3
gnustep-gui 0.18.0-5
graphviz 2.26.3-7
gthumb 3:2.13.1-1
htmldoc 1.8.27-5
imagemagick 8:6.6.9.7-5
imlib2 1.4.4-1
inventor 2.1.5-10-15
jhdf 2.6.1-2
jpegoptim 1.2.3-2
kipi-plugins 1.9.0-2
libmatchbox 1.9-8
libmng 1.0.10-2
libopenraw 0.0.8-3
libphash 0.9.4-1.1
librasterlite 1.0-3
libterralib 4.0.0-2
libtk-img 1:1.3-release-9
libvncserver 0.9.7-3
mathgl 1.11.2-1
metapixel 1.0.2-7
mupdf 0.8.15-1
netsurf 2.7-2
nip2 7.24.1-2
nxcomp 3.2.0-7-1.1
ocropus 0.3.1-3
pekwm 0.1.12-2
pike7.8 7.8.352-dfsg-4
plucker 1.8-33
poppler 0.16.7-2
prima 1.28-1
r-base 2.13.1-1
remmina-plugins 0.9.2-2
sdl-image1.2 1.2.10-2.1
shoes 0.r396-5
simgear 2.0.0-4
ssvnc 1.0.28-1
steghide 0.5.1-9
swi-prolog 5.10.4-2
thunar-vfs 1.2.0-3
tiff 3.9.5-1
uvccapture 0.5-1
vips 7.24.5-4
vxl 1.14.0-8
wings3d 1.4.1-1
wmaker 0.92.0-8.2
xjig 2.4-13
xmhtml 1.1.7-15
xtel 3.3.0-11
ygraph 0.16~cvs20090218-1
ziproxy 3.1.3-1


signature.asc
Description: Digital signature

binNMU for libjpeg8 migration

[Bill Allombert]

Dear release team,

In the interest of moving forward with the libjpeg8 migration,
I suggest to binNMU packages that build-depends on libjpeg-dev but still depends
on libjpeg62.

Please find the list below assuming my computation are correct.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
afterstep 2.2.11-4
analog 2:6.0-19
ayttm 0.6.3-2
blender 2.58-svn37702-1
dcraw 8.99-1
djvulibre 3.5.24-8
epm 4.2-1
ffmpegthumbnailer 2.0.6-4
fgfs-atlas 0.3.1-2
flightgear 2.0.0-4
fox1.6 1.6.44-1.1
freeimage 3.10.0-4
gargoyle-free 2010.1-2
ghostscript 9.02~dfsg-3
gimp 2.6.11-3
gle-graphics 4.2.2-4
gnash 0.8.10~git20110618-3
gnustep-gui 0.18.0-5
grace 1:5.1.22-10
graphviz 2.26.3-7
gthumb 3:2.13.1-1
htmldoc 1.8.27-5
iceape 2.0.14-4
imagemagick 8:6.6.9.7-5
imlib2 1.4.4-1
inventor 2.1.5-10-15
jhdf 2.6.1-2
jpegoptim 1.2.3-2
kipi-plugins 1.9.0-2
libmatchbox 1.9-8
libmng 1.0.10-1
libopenraw 0.0.8-3
libphash 0.9.4-1.1
librasterlite 1.0-3
libreoffice 1:3.3.3-4
libsfml 1.6+dfsg1-2
libterralib 4.0.0-2
libtk-img 1:1.3-release-9
libvncserver 0.9.7-3
mathgl 1.11.2-1
metapixel 1.0.2-7
mupdf 0.8.15-1
netsurf 2.7-2
nip2 7.24.1-2
nxcomp 3.2.0-7-1.1
ocropus 0.3.1-3
paraview 3.8.1-3
pekwm 0.1.12-2
php5 5.3.6-13
pike7.8 7.8.352-dfsg-4
player 3.0.2+dfsg-2.1
plucker 1.8-33
poppler 0.16.7-2
prima 1.28-1
qt4-x11 4:4.7.3-5
r-base 2.13.1-1
remmina-plugins 0.9.2-2
sdl-image1.2 1.2.10-2.1
shoes 0.r396-5
simgear 2.0.0-4
ssvnc 1.0.28-1
steghide 0.5.1-9
thunar-vfs 1.2.0-3
tiff 3.9.5-1
uvccapture 0.5-1
vdr-plugin-xineliboutput 1.0.6+cvs20110417.2013-1
vips 7.24.5-4
vxl 1.14.0-8
wings3d 1.4.1-1
wmaker 0.92.0-8.2
xjig 2.4-13
xmhtml 1.1.7-15
xtel 3.3.0-11
ygraph 0.16~cvs20090218-1
ziproxy 3.1.3-1

Re: Bug#634194: libtiff4-dev: Depends on libjpeg-dev even though library is linked against libjpeg62

[Bill Allombert]

On Tue, Jul 19, 2011 at 05:30:02PM +0200, Lucas Nussbaum wrote:
 On 18/07/11 at 20:05 +0200, Julien Cristau wrote:
  On Sun, Jul 17, 2011 at 19:59:50 +0200, Bill Allombert wrote:
  
   On Sun, Jul 17, 2011 at 08:25:08AM -0700, Daniel Schepler wrote:
Package: libtiff4-dev
Version: 3.9.5-1
Severity: normal

As the subject says, libtiff4 currently depends on libjpeg62, while 
libtiff4-dev 
depends on libjpeg-dev which is only provided by libjpeg8-dev.  So 
there's a 
version mismatch there.
   
   Hello Daniel,
   
Perhaps all that's needed is a binary-only NMU of the tiff source 
package -- it 
looks like it builds fine against libjpeg8 with the current 
Build-Depends.
   
   Yes, only a binary-only NMU is required. 
   
  Does the temporary mismatch cause any actual issue?
 
 50 to 100 packages failed to build in my latest rebuild because of that.

Could you point to some of them ? 
I know about 62 packages with conflicting build-dependency but this is 
unrelated to
this discrepancy. (At least a binary-only NMU of libtiff4 would not fix that).

Cheers,
Bill.


-- 
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/20110719160947.GK24411@yellowpig

Re: Bug#634194: libtiff4-dev: Depends on libjpeg-dev even though library is linked against libjpeg62

[Bill Allombert]

On Sun, Jul 17, 2011 at 08:25:08AM -0700, Daniel Schepler wrote:
 Package: libtiff4-dev
 Version: 3.9.5-1
 Severity: normal
 
 As the subject says, libtiff4 currently depends on libjpeg62, while 
 libtiff4-dev 
 depends on libjpeg-dev which is only provided by libjpeg8-dev.  So there's a 
 version mismatch there.

Hello Daniel,

 Perhaps all that's needed is a binary-only NMU of the tiff source package -- 
 it 
 looks like it builds fine against libjpeg8 with the current Build-Depends.

Yes, only a binary-only NMU is required. 

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20110717175950.GM2519@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jul 07, 2011 at 08:33:18PM +0200, Julien Cristau wrote:
 On Thu, Jul  7, 2011 at 15:47:27 +0200, Bill Allombert wrote:
 
  There still remain 15 packages dependending on libjpeg62-dev, however I am 
  not sure it
  is worth delaying the transition more. Maybe I should just upload the new 
  packages.
  
 Yes, I think so.  The remaining packages can be NMUed as needed if they
 start blocking stuff.

OK, so I uploaded the packages.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/2011070826.GI19440@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jun 09, 2011 at 11:43:40PM +0200, Julien Cristau wrote:
 On Thu, Jun  9, 2011 at 23:13:03 +0200, Bill Allombert wrote:
 
  Given the large legacy of libjpeg62, it is probably safer to keep it.
  Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
  confusing. I will report bug to packages that Depends on libjpeg62-dev
  as a first step.
  
 Alright, thank you.

I have prepared the new packages. They are at
http://people.debian.org/~ballombe/jpeg

There still remain 15 packages dependending on libjpeg62-dev, however I am not 
sure it
is worth delaying the transition more. Maybe I should just upload the new 
packages.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110707134727.GD19440@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jun 09, 2011 at 10:38:37PM +0200, Julien Cristau wrote:
 Hi Bill,
 
 sorry for the delay in getting back to you.
 
 On Sat, Apr 30, 2011 at 16:29:17 +0200, Bill Allombert wrote:
 
  One issue with this transition is that a number of packages still depends 
  on 
  libjpeg62-dev instead of libjpeg-dev. This might cause packages to have 
  uninstallable
  build-dependency until they are fixed.
  
 I guess that depends if we need to keep building some things against
 libjpeg62.  If not, maybe libjpeg62-dev can become a dummy transitional
 package for libjpeg8-dev.  If yes, then those packages depending on
 libjpeg62-dev should have bugs filed (probably at important severity
 for now).

Given the large legacy of libjpeg62, it is probably safer to keep it.
Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
confusing. I will report bug to packages that Depends on libjpeg62-dev
as a first step.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110609211303.GA24685@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jun 09, 2011 at 11:43:40PM +0200, Julien Cristau wrote:
 On Thu, Jun  9, 2011 at 23:13:03 +0200, Bill Allombert wrote:
 
  Given the large legacy of libjpeg62, it is probably safer to keep it.
  Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
  confusing. I will report bug to packages that Depends on libjpeg62-dev
  as a first step.
  
 Alright, thank you.

Done, 18 bugs reported, #629960 to #629978 minus #629971.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110609220257.GA31035@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Mon, Mar 21, 2011 at 01:53:03PM +0100, Julien Cristau wrote:
 On Sun, Mar 13, 2011 at 11:13:08 +0100, Bill Allombert wrote:
 
  On Fri, Mar 11, 2011 at 03:33:42PM +0100, Julien Cristau wrote:
   Hi Bill,
   
   On Sat, Mar  5, 2011 at 18:08:21 +0100, Bill Allombert wrote:
   
Dear release team,

I would like to proceed with the libjpeg8 transition. What are your 
plan ?

   #547393 is marked as blocked by a number of other bugs.  Can you check
   with the maintainers of the affected packages?
  
  I could, but consider that:
  #592925 is fixed, #582417 is not really a bug and the others seems to have
  unresponsive maintainers, it looks like a loss of time.
 
 They'll still need to be fixed when we make the switch, since some of
 them are libraries with a non-trivial number of reverse dependencies.
 Of course one option could be to make them build-depend on
 libjpeg62-dev, but if the maintainers are unresponsive you should be
 prepared to NMU.

One issue with this transition is that a number of packages still depends on 
libjpeg62-dev instead of libjpeg-dev. This might cause packages to have 
uninstallable
build-dependency until they are fixed.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110430142917.GF2835@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Fri, Apr 29, 2011 at 10:13:53PM +0200, Julien Cristau wrote:
  They'll still need to be fixed when we make the switch, since some of
  them are libraries with a non-trivial number of reverse dependencies.
  Of course one option could be to make them build-depend on
  libjpeg62-dev, but if the maintainers are unresponsive you should be
  prepared to NMU.
  
 hmm, I didn't see an answer to that.  :/

Sorry, I got distracted by an unexpected popcon.debian.org failure.

 Either way we should probably get this started at this point, so please
 feel free to upload at your convenience.

Fine. How should I proceed ? Should I upload both libjpeg6b and libjpeg8 with
libjpeg-dev pointing to libjpeg8-dev ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110430202759.GA17342@yellowpig

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Fri, Mar 11, 2011 at 03:33:42PM +0100, Julien Cristau wrote:
 Hi Bill,
 
 On Sat, Mar  5, 2011 at 18:08:21 +0100, Bill Allombert wrote:
 
  Dear release team,
  
  I would like to proceed with the libjpeg8 transition. What are your plan ?
  
 #547393 is marked as blocked by a number of other bugs.  Can you check
 with the maintainers of the affected packages?

I could, but consider that:
#592925 is fixed, #582417 is not really a bug and the others seems to have
unresponsive maintainers, it looks like a loss of time.
What is more problematic is the numbers of packages that embed a copy of 
libjpeg6b,
but this is mostly na independant issue.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110313101308.GG29043@yellowpig

libjpeg8 transition.

[Bill Allombert]

Dear release team,

I would like to proceed with the libjpeg8 transition. What are your plan ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20110305170821.GH17663@yellowpig

Bug#609805: unblock: popularity-contest/1.50

[Bill Allombert]

On Sun, Jan 23, 2011 at 09:27:52AM +0100, Christian PERRIER wrote:
 Quoting Mehdi Dogguy (me...@debian.org):
 
  Do you intend to fix that in unstable? Did you submit a bug so that it's
  kept under someone's radar?
  
  In any case, like what jcristau said… so closing this bugreport.
 
 Rah, apologies for not doing so... I just reported #610840 and
 committed the fix in popcon's SVN.
 
 Bill, could you upload?

Done, but I will let you deal with the release team if need be.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



--
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/20110124171733.GE8863@yellowpig

Bug#609805: unblock: popularity-contest/1.50

[Bill Allombert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package popularity-contest 1.50

This update only adds debconf translation in Serbian.

popularity-contest (1.50) unstable; urgency=low

  [ Christian Perrier ]
  * Pre-Depend on debconf (= 1.5.34) to properly handle Serbian (Latin)
debconf translation
  * Translations:
- Serbian (Janos Guljas).  Closes: #600123
- Serbian in Latin script (Janos Guljas).  Closes: #600124

 -- Bill Allombert ballo...@debian.org  Thu, 23 Dec 2010 12:24:36 +0100

unblock popularity-contest/1.50

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20110112155649.ga19...@yellowpig

Bug#606509: unblock: gap/4r4p12-2

[Bill Allombert]

On Sun, Dec 12, 2010 at 07:14:18PM +, Adam D. Barratt wrote:
 On Thu, 2010-12-09 at 22:17 +0100, Bill Allombert wrote:
  Please unblock package gap. I have made this upload to fix an FTBFS on 
  kfreebsd-i386
  and kfreebsd-amd64.
 
 Have the resulting packages been tested on kfreebsd-*?

I built and tested them on asdfasdf.debian.net before uploading them.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20101212194307.gd2...@yellowpig

Bug#606509: unblock: gap/4r4p12-2

[Bill Allombert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package gap. I have made this upload to fix an FTBFS on 
kfreebsd-i386
and kfreebsd-amd64. Also I added -fno-strict-aliasing to CFLAGS to avoid some 
runtime
issues with gcc-4.4 on some platforms. I tried to keep the change minimal.

Here the changelog:
gap (4r4p12-2) unstable; urgency=low

  * debian/rules:
- add -fno-strict-aliasing to CFLAGS to avoid issues with newer gcc.
  * src/sysfiles.c:
- Prefer termios.h over sgtty.h. This fix a build failure on kfreebsd.

 -- Bill Allombert ballo...@debian.org  Thu, 25 Nov 2010 11:07:30 +0100

unblock gap/4r4p12-2

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20101209211735.ga19...@yellowpig

Bug#603512: unblock: popularity-contest/1.49

[Bill Allombert]

On Sun, Nov 14, 2010 at 09:24:25PM +, Adam D. Barratt wrote:
 On Sun, 2010-11-14 at 21:48 +0100, Bill Allombert wrote:
  Please unblock package popularity-contest before the release.
 [...]
  I have kept 1.49 only in sid for some times so that we can gather separate
  statistics for sid and squeeze users.
 
 Does before the release mean you don't want it unblocked /now/?

Well, if you can keep it blocked for one more week without hassle, it would
be perfect, otherwise just unblock it now.

Thanks,
Bill.



-- 
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/20101115171217.gc5...@yellowpig

Bug#603512: unblock: popularity-contest/1.49

[Bill Allombert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package popularity-contest before the release.

Version 1.49 is a documentation/translation only update.
It changes the script popcon.pl but this script is installed
in /usr/share/doc and should count as documentation.

I have kept 1.49 only in sid for some times so that we can gather separate
statistics for sid and squeeze users.
(i.e. testing: 19630 reports, unstable: 3921 reports).

Here the changelog:

popularity-contest (1.49) unstable; urgency=low

  [ Bill Allombert ]
  * popcon.pl:
- sync with popcon.debian.org version: add source (max) ratings.
  * debian/control:
- Build-Depends: raise debhelper version to (=5) to match compat.
- Updated Standards-Version from 3.8.1 to 3.9.1.  No change needed.

  [ Christian Perrier ]
  * Translations:
- Telugu. Closes: #544044
- Italian (Milo Casagrande).  Closes: #559503
- Simplified Chinese (♦ ♦ ♦ ).
- Slovenian (Vanja Cvelbar).  Closes: #570103
- Persian added (Vahid Ghaderi).  Closes: #587010,#587078
- Kazakh (Sarsenov D.).  Closes: #587100
- Bosnian (Safir Secerovic).

 -- Bill Allombert ballo...@debian.org  Sat, 09 Oct 2010 19:13:27 +0200

unblock popularity-contest/1.49

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



--
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/20101114204803.ga27...@yellowpig

Bug#602565: unblock: menu-l10n/0.20101027

[Bill Allombert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package menu-l10n

unblock menu-l10n/0.20101027

menu-l10n is a purely translation package that contains translation for the 
Debian menu
system. Since the Debian menu system entries can be changed at any time by any 
package,
the translations need to be done during the freeze.

Here the changelog.

menu-l10n (0.20101027) unstable; urgency=low

  * Squeeze Translation update:
- Added: Hungarian translation by Attila Szervác
- Updated: French translation by Christian Perrier (Closes: #599546)

 -- Bill Allombert ballo...@debian.org  Wed, 27 Oct 2010 22:21:58 +0200

menu-l10n (0.20101006) unstable; urgency=low

  * Squeeze Translation update:
- Added: French translation by Christian Perrier (Closes: #597598)
- Updated: German translation by Chris Leick (Closes: #599086)
  * Bump Standards-Version to 3.9.1

 -- Bill Allombert ballo...@debian.org  Wed, 06 Oct 2010 10:43:55 +0200

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



--
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/20101105224339.ga31...@yellowpig

status of libjpeg6b1 transition

[Bill Allombert]

Dear Debian release team,
I would like to enquire about the status of the libjpeg6b1 transition.

According to my computation, there 512 binaries packages in squeeze that link 
against libjpeg62,
466 of them have been rebuild against libjpeg6b1. So it remains 46 packages 
that did not.
This corresponds to the 17 source packages, assumong I did not miss anything.

abiword
cegui-mk2
emboss
hdf5
jpeginfo
jpegoptim
jpegpixi
lsb
open-font-design-toolkit
pyabiword
seaview
spandsp
uvccapture
vdr
warsow
wings3d
xmame

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Bug#598333: unblock: menu/2.1.44

[Bill Allombert]

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

Please unblock package menu 2.1.44 which has been in unstable for more than 10 
days.
This update only contains translations and documentation fixes.

Here the changelog:

menu (2.1.44) unstable; urgency=low

  * The Bordeaux release.
  * Handling of l10n by Christian Perrier:
+ Menu sections translations:
  - Estonian added. Closes: #582243
+ Programs translations:
  - Estonian added.
+ su-to-root translations:
  - Estonian added.
  * debian/control:
- Suggests menu-l10n.
- Bump Standards-Version to 3.9.1.
  * Fix spelling error in /usr/share/menu/README.
Thanks to Filipus Klutiero. Closes: #592114

 -- Bill Allombert ballo...@debian.org  Mon, 06 Sep 2010 16:48:27 +0200

unblock menu/2.1.44

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



-- 
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/20100928103751.ga17...@yellowpig

Re: Transition: libjpeg6b with versionned symbols

[Bill Allombert]

On Wed, Jun 30, 2010 at 12:41:14PM +0100, Julien Cristau wrote:
 I'd say just bump it to 6b1 to avoid spurious ld.so warnings.  If
 there's no other change than the versioning in the new libjpeg then it
 will go in testing in 10 days so shouldn't hold up too much stuff.

I reached the same conclusion. I just uploaded it.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20100630132550.gj13...@yellowpig

Re: Transition: libjpeg6b with versionned symbols

[Bill Allombert]

On Thu, Jun 24, 2010 at 11:05:54AM +0100, Julien Cristau wrote:
 On Sat, Jun  5, 2010 at 01:28:46 +0200, Bill Allombert wrote:
 
  A new upstream release that provides versionned symbols has been released
  (6b1) and I have prepared the Debian packages. This release has an updated
  build system which is already a big improvement.
  
 Please feel free to upload this to unstable so reverse dependencies can
 start picking up the versioned symbols.

OK. Should I bump the shlibs version (to 'libjpeg62 (=6b1)' ) so that it is
easy to check whether a package was rebuild against the new libjpeg6b1 ?

Maybe I can bump it to something innocuous like 'libjpeg62 (=6b)' to avoid
introducing a spurious versionned depends.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20100628161445.gi23...@yellowpig

Re: Transition: libjpeg6b with versionned symbols

[Bill Allombert]

On Sun, Jun 13, 2010 at 07:21:07PM +0100, Adam D. Barratt wrote:
 On Sat, 2010-06-05 at 01:28 +0200, Bill Allombert wrote:
  On Thu, May 20, 2010 at 11:57:42AM +0200, Julien Cristau wrote:
   On Wed, May 19, 2010 at 19:54:25 +0200, Bill Allombert wrote:
   
Well, at this stage I have discussed with upstream. There is a new (non
Debian specific) tarball prepared that provides versionned symbols by
default.

I will try to contact other libjpeg maintainers in other distributions.

   Thanks a lot, Bill.
  
  A new upstream release that provides versionned symbols has been released
  (6b1) and I have prepared the Debian packages. This release has an updated
  build system which is already a big improvement.
 
 Thanks for this.  I assume that the new upstream release maintains the
 libjpeg62 soname?

Yes, it is totally identical to 6b in all respect outside versionned symbols.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20100613193759.gg27...@yellowpig

Re: Transition: libjpeg6b with versionned symbols

[Bill Allombert]

On Thu, May 20, 2010 at 11:57:42AM +0200, Julien Cristau wrote:
 On Wed, May 19, 2010 at 19:54:25 +0200, Bill Allombert wrote:
 
  Well, at this stage I have discussed with upstream. There is a new (non
  Debian specific) tarball prepared that provides versionned symbols by
  default.
  
  I will try to contact other libjpeg maintainers in other distributions.
  
 Thanks a lot, Bill.

A new upstream release that provides versionned symbols has been released
(6b1) and I have prepared the Debian packages. This release has an updated
build system which is already a big improvement.

Gentoo and Arch have moved to libjpeg8 but they are source distributions, so
they handle ABI breakage more easily.  Mandriva has already moved to libjpeg8
and did not had much trouble with it (though the versionned symbols clash
caused chromium upstream binary to crash). 
Also I found out that Adobe flash plugin is not linked (dynamically) with
libjpeg, so there is probably not much binary-only plugins dynamically linked
against non-symbols versionned libjpeg62 in use.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Transition: libjpeg6b with versionned symbols

[Bill Allombert]

On Tue, May 18, 2010 at 09:50:29PM +0200, Julien Cristau wrote:
 On Tue, May 18, 2010 at 21:13:25 +0200, Bill Allombert wrote:
 
  Dear Debian release team,
  
  I like to do a transition to libjpeg6b-with-versionned symbols before
  the freeze to open the possibility for moving to libjpeg8 in squeeze+1.
  
 Has there been any attempt to discuss the libjpeg/LSB issues with
 upstream, other distributors and/or the LSB folks?

Well, at this stage I have discussed with upstream. There is a new (non
Debian specific) tarball prepared that provides versionned symbols by
default.

I will try to contact other libjpeg maintainers in other distributions.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


-- 
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/20100519175425.gf1...@yellowpig

Transition: libjpeg6b with versionned symbols

[Bill Allombert]

Dear Debian release team,

I like to do a transition to libjpeg6b-with-versionned symbols before
the freeze to open the possibility for moving to libjpeg8 in squeeze+1.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: JPEG 8 transition

[Bill Allombert]

On Mon, Mar 15, 2010 at 01:03:19AM +0100, Julien Cristau wrote:
 On Mon, Mar 15, 2010 at 00:29:45 +0100, Bill Allombert wrote:
 
  On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote:
   * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]:
   I fear I need to agree with you. We should have libjpeg62 with
   symbols, recompile every package build-depending on libjpeg*-dev after
   that till the release, and then move to libjpeg8 (or whatever it is)
   at the begining of the squeeze+1-cycle (and we can be sure nothing
   breaks because of the symbols).
  
  Ok so I have experimented with a libjpeg62 source with versionned symbols,
  It works fine but for an annoying problem:
  
 Bill, see slrnhni28d.nfa.nos...@sshway.ssh.pusling.com.  It doesn't
 look like there's any way we can switch gtk and qt to libjpeg8 while
 (non symbol versioned) libjpeg62 is mandated by LSB (unless we decide to
 ignore the LSB).

I do not think this is technically true. For example a program
linked with Qt-linked-with-libjpeg62 should work fine when used with
Qt-linked-with-libjpeg8 because LSB-mandated Qt interface does not
export the raw libjpeg interface to the program. The same is true for
gtk.

However this would probably break some binary-only software that are
not strictly LSB compliant.

So I am considering the following transition plan:

1) We transition to libjpeg62+versioned-symbol (libjpeg62vs  for short)
for squeeze. This should not break the LSB except maybe for the warnings
I mentionned above, but this is a minor issue.

2) We should be able to get other distributions to follow suite and the
LSB to be updated to require libjpeg62vs. Since both forward and
backward compatibility is preserved, and versioned symbols are
technically superior, this should be possible.

3) Once some binary-only softwares have been rebuild against libjpeg62vs, then
it should be safe to move to libjpeg8.

Is there a better plan ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


signature.asc
Description: Digital signature

Re: Bits from the Release Team: What should go into squeeze?

[Bill Allombert]

On Sun, Mar 14, 2010 at 09:42:58PM +0100, Philipp Kern wrote:
 Dear fellow developers,
 
 We would like to know what needs attention, what bugs still need to be
 fixed in your package before squeeze is released, which features or new
 upstream versions you want to see in squeeze which are not ready yet.
 Furthermore we would like to get an overview of the remaining transitions
 that need to be done.

I like to point your attention to the libjpeg8 transition. I have no
problem deferring the libjpeg8 transition to squeeze+1, but we should
have a clear plan for this transition before the freeze so at least 
libjpeg62 can be ajusted to make the transition to libjpeg8 less
painful.

I'd like to use this opportunuity to apologize for the trouble I caused with
libjpeg8. I was so afraid that packages would FTBFS with libjpeg8 that I
ignored the other failure mode.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: JPEG 8 transition

[Bill Allombert]

On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote:
 * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]:
 I fear I need to agree with you. We should have libjpeg62 with
 symbols, recompile every package build-depending on libjpeg*-dev after
 that till the release, and then move to libjpeg8 (or whatever it is)
 at the begining of the squeeze+1-cycle (and we can be sure nothing
 breaks because of the symbols).

Ok so I have experimented with a libjpeg62 source with versionned symbols,
It works fine but for an annoying problem:

If you compile-time link a binary with libjpeg62 w/ versionned symbols, and try
to run-time link it with libjpeg62 w/o versionned symbols, then the dynamic
linker output a warning:

cjpeg: /usr/lib/libjpeg.so.62: no version information available (required by 
cjpeg)

Normally this should not be an issue for Debian, but this will cause problems
for people wanting to build LSB package on Debian: when run on as non Debian
LSB-compliant platform, the binaries will generate linker warning, which can
cause problems. Maybe we will have to provide an extra package with the
non-versionned libjpeg62.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
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/20100314232945.gb7...@yellowpig

Re: JPEG 8 transition

[Bill Allombert]

On Sun, Feb 14, 2010 at 12:17:42PM +0100, Andreas Barth wrote:
 * Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [100214 10:19]:
  The second step would be to fix packages that Build-Depend on 
  'libjpeg62-dev'
  to Build-Depend on 'libjpeg-dev' instead, but that might make theirs
  build-dependencies unsatisfiable until they have been fixed. Again, please 
  do
  not make them Build-Depend on 'libjpeg8-dev', or 
  'libjpeg-dev|libjpeg62-dev' or
  'libjpeg-dev|libjpeg8-dev' or other combinaisons.  
 
 Sorry, but that's *way* too messy. Why don't you answer the mails we
 send you before sending something out to d-d-a? This single action
 will delay the release of Squeeze for a couple of weeks.

Which one ? I think I replied to every single mail from debian-release
that deserved an answer.

 I'm totally annoyed by the lack of coordination, generating
 unnecessary work etc.

So do I, in the other way. At least the email to d-d-a improved that,
and I do not think following its recommendation can make anything worse.

 Can we please come to an plan how to fix that mess which doesn't
 involve the upload of more than 200 source packages and ties them to
 this transition? How about making (at least for the moment)
 libjpeg62-dev an transition-only package to libjepg8-dev? That would
 allow us to at least not block so many packages.  (We can always at
 a later moment change that back - or have lintian warnings that
 build-depends on libjpeg62-dev should be dropped, or have an
 libjpeg62real-dev, or whatever - but now we need to get the archive
 and the testing migration operational again.)

I proposed to do that on debian-release already, but this was rejected.

So I will state it a last time:
I propose to upload the libjpeg6b source package that generate 
libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload 
libjpeg8 source package that generate a libjpeg8-dev that provides
both libjpeg62-dev and libjpeg-dev. 
Do the release team want me to do that ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: BinNMU for libjpeg8 transition

[Bill Allombert]

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.

 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.

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.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: BinNMU for libjpeg8 transition

[Bill Allombert]

On Thu, Feb 11, 2010 at 07:38:18PM +0100, Luk Claes wrote:
 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?

http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html
Library:libjpeg
SONAME:   libjpeg.so.62

So if you want to build LSB packages, you need libjpeg62-dev.

  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.

The conflict is needed because they both install the file
/usr/include/jpeglib.h.

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

I am not sure what you means, but I proposed to do thing differently:
to rename libjpeg62-dev to libjpeg6b-dev and to have libjpeg8-dev
provide libjpeg62-dev, but this was not accepted because
that would mean that packages build-depending on libjpeg-dev and
libjpeg62-dev had to transition at the same time. So libjpeg8-dev 
does not provide  libjpeg62-dev and that lead to the current situation which
require to fix packages that _Depends_ on libjpeg62-dev first.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

[Bill Allombert]

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. 

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.

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.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: BinNMU for libjpeg8 transition

[Bill Allombert]

On Wed, Feb 10, 2010 at 10:53:17AM +0100, Sven Joachim wrote:
 On 2010-02-09 23:39 +0100, 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.
 
  Please trigger binNMU for the following packages that build-depends on
  libjpeg-dev (and not libjpeg62-dev|libjpeg-dev) for rebuilding against
  libjpeg8-dev 8-2:
 
  imagemagick  7:6.5.8.3-1
  inventor  2.1.5-10-14
  kwwidgets  1.0.0~cvs20090825-4
  libphash  0.8.1-1
  libsfml  1.5+repack1-3
  libterralib  3.3.1-8
  mathgl  1.9-2
  nxcomp  3.2.0-7-1.1
  openscenegraph  2.8.2-2
  ossim  1.7.21-1
  pike7.6  7.6.112-dfsg-1
  poppler  0.12.2-2.1
  prima  1.28-1
  shoes  0.r396-5
  slicer  3.4.0~svn10438-4
  steghide  0.5.1-9
  tipptrainer  0.6.0-16
  vino  2.28.1-2.1
  vtk  5.4.2-4
  vxl  1.13.0-2
  xen-3  3.4.2-2
  xjig  2.4-13
  xnc  5.0.4-4
 
 Are any of these packages actually buildable now?  For instance,

This is a good question. Please postpone the binNMU.
I will report the full list of packages that are actually buildable,
and the the list of -dev package that Depends on libjpeg62-dev.

 anything that depends on libtiff4?-dev is not, because libtiff4-dev
 depends on libjpeg62-dev.  Neither is anything that depends on
 libgtk2.0-dev, because of the dependency chain
 libgtk2.0-dev - libcairo2-dev - libdirectfb-dev - libjpeg62-dev.

Fortunately, while there are a large number of packages that Depends on
libjpeg62-dev, only a small number are causing conflicts.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

[Bill Allombert]

On Wed, Feb 10, 2010 at 11:12:08AM +0100, Bill Allombert wrote:
  Are any of these packages actually buildable now?  For instance,
 
 This is a good question. Please postpone the binNMU.

Also, it appears my list was truncated.

 I will report the full list of packages that are actually buildable,
 and the the list of -dev package that Depends on libjpeg62-dev.

The following package should be fine for a binNMU: I did a test-build with
pbuilder on i386 this morning.

dcraw 8.86-1
grace 5.1.22-2
hasciicam 1.0-1
htmldoc  1.8.27-4.1
inventor 2.1.5-10-14
libsfml  1.5+repack1-3
nxcomp   3.2.0-7-1.1
steghide 0.5.1-9
vtk  5.2.1-14
xjig 2.4-13

  anything that depends on libtiff4?-dev is not, because libtiff4-dev
  depends on libjpeg62-dev.  Neither is anything that depends on
  libgtk2.0-dev, because of the dependency chain
  libgtk2.0-dev - libcairo2-dev - libdirectfb-dev - libjpeg62-dev.
 
 Fortunately, while there are a large number of packages that Depends on
 libjpeg62-dev, only a small number are causing conflicts.

Here the list of packages that cause conflicts due to dependencies on
libjpeg62-dev:

libcupsimage2-dev
libdirectfb-dev
libdjvulibre-dev
libgd2-noxpm-dev
libgdal1-dev
libhdf5-serial-dev
libqt3-mt-dev
libsane-dev
libsdl-image1.2-dev
libtiff4-dev
libwmf-dev
libwraster3-dev

They should be updated to Depends and Build-Depends on libjpeg-dev instead.
Unfortunately that is likely to cause packages build-depending on libjpeg62-dev
to fail to build, so they will need to be fixed too.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

[Bill Allombert]

On Wed, Feb 10, 2010 at 10:45:50PM +0100, Luk Claes wrote:
 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?

Both libjpeg8-dev and libjpeg62-dev contains the same filenames, with
different content (e.g. /usr/lib/libjpeg.a)

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

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.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

BinNMU for libjpeg8 transition

[Bill Allombert]

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.

Please trigger binNMU for the following packages that build-depends on
libjpeg-dev (and not libjpeg62-dev|libjpeg-dev) for rebuilding against
libjpeg8-dev 8-2:

imagemagick  7:6.5.8.3-1
inventor  2.1.5-10-14
kwwidgets  1.0.0~cvs20090825-4
libphash  0.8.1-1
libsfml  1.5+repack1-3
libterralib  3.3.1-8
mathgl  1.9-2
nxcomp  3.2.0-7-1.1
openscenegraph  2.8.2-2
ossim  1.7.21-1
pike7.6  7.6.112-dfsg-1
poppler  0.12.2-2.1
prima  1.28-1
shoes  0.r396-5
slicer  3.4.0~svn10438-4
steghide  0.5.1-9
tipptrainer  0.6.0-16
vino  2.28.1-2.1
vtk  5.4.2-4
vxl  1.13.0-2
xen-3  3.4.2-2
xjig  2.4-13
xnc  5.0.4-4

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Upcoming libjpeg8 transition

[Bill Allombert]

On Mon, Feb 01, 2010 at 03:27:06PM +0100, Bill Allombert wrote:
 On Wed, Jan 20, 2010 at 12:52:48AM +0100, Bill Allombert wrote:
  On Mon, Jan 11, 2010 at 02:01:44PM +0100, Bill Allombert wrote:
   Dear Debian release team,
   
   I like to proceed with the libjpeg8 transition, skipping libjpeg7 
   entirely.
   
   libjpeg8 packages are in the NEW queue. I have rebuild the 271 packages 
   that
   Build-Depends on libjpeg-dev and libjpeg62-dev against libjpeg8-dev and I 
   will soon send to the BTS the 7 FTBFS I found.
  
  I would like to do a status update:
  libjpeg8 is now in unstable and built everywhere.
  I have reported the FTBFS with libjpeg8:
  
  graphicsmagick   #565922
  libgd-gd2-noxpm-perl #565919
  libgd-gd2-perl   #565920
  libterralib  #565322
  motion   #565325
  sdop #565921
  zoneminder   #565326
 
 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.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Upcoming libjpeg8 transition

[Bill Allombert]

On Wed, Jan 20, 2010 at 12:52:48AM +0100, Bill Allombert wrote:
 On Mon, Jan 11, 2010 at 02:01:44PM +0100, Bill Allombert wrote:
  Dear Debian release team,
  
  I like to proceed with the libjpeg8 transition, skipping libjpeg7 entirely.
  
  libjpeg8 packages are in the NEW queue. I have rebuild the 271 packages that
  Build-Depends on libjpeg-dev and libjpeg62-dev against libjpeg8-dev and I 
  will soon send to the BTS the 7 FTBFS I found.
 
 I would like to do a status update:
 libjpeg8 is now in unstable and built everywhere.
 I have reported the FTBFS with libjpeg8:
 
 graphicsmagick   #565922
 libgd-gd2-noxpm-perl #565919
 libgd-gd2-perl   #565920
 libterralib  #565322
 motion   #565325
 sdop #565921
 zoneminder   #565326

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.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Upcoming libjpeg8 transition

[Bill Allombert]

On Mon, Jan 11, 2010 at 02:01:44PM +0100, Bill Allombert wrote:
 Dear Debian release team,
 
 I like to proceed with the libjpeg8 transition, skipping libjpeg7 entirely.
 
 libjpeg8 packages are in the NEW queue. I have rebuild the 271 packages that
 Build-Depends on libjpeg-dev and libjpeg62-dev against libjpeg8-dev and I 
 will soon send to the BTS the 7 FTBFS I found.

I would like to do a status update:
libjpeg8 is now in unstable and built everywhere.
I have reported the FTBFS with libjpeg8:

graphicsmagick   #565922
libgd-gd2-noxpm-perl #565919
libgd-gd2-perl   #565920
libterralib  #565322
motion   #565325
sdop #565921
zoneminder   #565326

(All of them are easy to fix).

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Upcoming libjpeg8 transition

[Bill Allombert]

Dear Debian release team,

I like to proceed with the libjpeg8 transition, skipping libjpeg7 entirely.

libjpeg8 packages are in the NEW queue. I have rebuild the 271 packages that
Build-Depends on libjpeg-dev and libjpeg62-dev against libjpeg8-dev and I 
will soon send to the BTS the 7 FTBFS I found.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: development plans for the squeeze cycle

[Bill Allombert]

 Heya,
 
 As announced on dda [RT1], we want to get an impression when releasing
 Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
 2009, and some developers have noted that their planned changes wouldn't be
 possible in this time frame. 

Unfortunately, a lot of developers are in holiday in August so it is not a very 
good time for gathering opinions.

 So, to find out when releasing would work for most people, I've just
 send out a heap of mails to some specific teams who maintain larger
 packages, but I would also love to hear answers from other developers:
 
 Do you have any big changes planned? How much time would they take, and
 what consequences are there for the rest of the project?
 
 How many big transitions will the upcoming changes cause? When should those
 happen? Can we do something to make them easier?

My main issue is that a freeze in December imply a squeeze release about one
year after lenny release. Unless the security team commit to support lenny two
years after the release of squeeze, this means a total security support for
lenny of only 2 years, which is too short. Another unrelated problem is that
the period of testing-security support might overlap with etch security support,
which might be difficult for the security team.

I think I remember a proposal of allowing upgrades to skip a release. This
would imply that the oldstable release is security-supported for some time
after the newstable release is released. In any case I do not think we have
sufficient resources to test such upgrades. We are already barely able to test
standard upgrades. Just to give an example: squeeze coreutils is incompatible
with etch 2.6.18 kernel, so it is not possible to upgrade etch to squeze
without first upgrading the kernel.

Cheers,
Bill.


signature.asc
Description: Digital signature

Re: libjpeg62-dev - libjpeg-dev transition

[Bill Allombert]

On Sat, Sep 19, 2009 at 01:08:12AM +0200, Pierre Habouzit wrote:
 On Sat, Sep 19, 2009 at 12:04:32AM +0200, Bill Allombert wrote:
  Dear developers,
  
  There is a new version of libjpeg in the archive (JPEG7), but is it
  not yet cleared for building packages against it.
  
  If your package Build-Depends on libjpeg62-dev, please change to 
  'libjpeg-dev'
  (without the 62) to ease the transition.
 
 Err no, please don't.

The fact that some packages Build-Depends on libjpeg62-dev is merely an 
historical artefact.

 First I'd like to see packages already build-depending on libjpeg-dev to
 be rebuilt against a libjpeg7 that provides libjpeg-dev.

Actually, I have already done a test-rebuild of all the packages that
build-depends on libjpeg62-dev or libjpeg-dev against a modified libjpeg7-dev
that provide both libjpeg62-dev and libjpeg-dev, and there is only six FTBFS
five of them being just test-suite update, and I send a patch for the sixth
(netpbm) in the BTS.

I can provide you the logs if you want.

 _Only then_ you will open a mass bug on all packages that b-d on
 libjpeg62-dev to ask them to move to libjpeg-dev instead, so that the
 transition remains manageable.

The set of packages build-depending on libjpeg-dev instead of libjpeg62-dev is
pretty random, and the distinction will only bring confusion, with most
packages ending depending on both libraries.

A better plan is to start to rebuild the libraries packages that depend
on libjpeg and then rebuild the other packages against them.

 I'm not sure if we're ready for this transition yet though, I'll let luk
 or other RA/RM check if now is the best moment to do so.

In any case, I do not plan to start this transition just now, there are more
things to check first.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: libjpeg62-dev - libjpeg-dev transition

[Bill Allombert]

On Sat, Sep 19, 2009 at 01:01:38PM +0200, Pierre Habouzit wrote:
 On Sat, Sep 19, 2009 at 11:47:35AM +0200, Bill Allombert wrote:
  Actually, I have already done a test-rebuild of all the packages that
  build-depends on libjpeg62-dev or libjpeg-dev against a modified 
  libjpeg7-dev
  that provide both libjpeg62-dev and libjpeg-dev, and there is only six FTBFS
  five of them being just test-suite update, and I send a patch for the sixth
  (netpbm) in the BTS.
 
 That' be great (if not already done) to open important bugs on those
 packages please, so that we can track that down.

This the summary of the result:

1) FTBFS in sid with libjpeg62-dev anyway:
avifile:  FTBFS #526536
blender:  FTBFS #545622
crystalspace: FTBFS #543082
dillo:FTBFS #515271  
emacs22:  FTBFS #545497
emacs23:  FTBFS #545379
fgfs-atlas:   FTBFS #545593
gqcam:FTBFS #515314
graphviz: FTBFS #542979
hdf-eos5: FTBFS #545833
kaffe:FTBFS #529872
ntop: FTBFS #527757
openvrml: FTBFS #490334, #534055
paintlib: FTBFS #546167
player:   FTBFS #524746
rezound:  FTBFS #529952, #529967
slony1:   FTBFS #536929
vegastrike:   FTBFS #530483, #537005
stage:uninstallable build-dep-#524746

2) Package too large to be tested:
openoffice.org: too large

3) Package that fail to compile:
netpbm-free:  patch #546416

4) Package that build but fail test-suite:
sdop: testsuite
graphicsmagick:   testsuite
libgd-gd2-noxpm-perl: testsuite
libgd-gd2-perl:   testsuite

5) a small number (~5) of packages need to be updated to be compatible
with libjpeg7 raw interface (this is a one-line change). I will 
report bugs.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Re: libjpegv7 transition

[Bill Allombert]

On Tue, Aug 11, 2009 at 01:50:17PM +0200, Pierre Habouzit wrote:
 On Sun, Aug 09, 2009 at 10:20:37PM +0200, Bill Allombert wrote:
  On Tue, Aug 04, 2009 at 07:21:17PM +0200, Luk Claes wrote:
   Bill Allombert wrote:
   
   Please upload to experimental so we get an idea on the possible impact
   and have it NEW processed etc, TIA.
  
  Actually I uploaded libjpeg7 to sid one month ago. It is still in the NEW
  queue. It does not provides libjpeg-dev and so should be safe for sid.
 
 Geez, 1 month, okay, do ping us when it enters testing please, so that
 we can do the first part of the transition (the -dev one).

libjpeg7 just entered testing today.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: libjpegv7 transition

[Bill Allombert]

On Tue, Aug 04, 2009 at 07:21:17PM +0200, Luk Claes wrote:
 Bill Allombert wrote:
 
 Please upload to experimental so we get an idea on the possible impact
 and have it NEW processed etc, TIA.

Actually I uploaded libjpeg7 to sid one month ago. It is still in the NEW
queue. It does not provides libjpeg-dev and so should be safe for sid.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Re: libjpegv7 transition

[Bill Allombert]

On Sun, Jun 14, 2009 at 09:30:33PM +0200, Pierre Habouzit wrote:
 On Sun, Jun 14, 2009 at 08:22:04PM +0100, Jurij Smakov wrote:
  On Sun, Jun 14, 2009 at 07:30:17PM +0200, Pierre Habouzit wrote:
   On Sun, Jun 14, 2009 at 03:48:28PM +0200, Bill Allombert wrote:
Dear release team,

libjpeg v7 is likely to be released at the end of June.
A prerelease tarball is available.

This version is ABI-incompatible with libjpeg6b.
However it should be fully API compatible.
To avoid symbol conflicts with libjpeg v6, the symbols are versionned..

This means the transition should be relatively safe but will involve
a lot of packages.

How do you want me to proceed ?
   
   Unless I'm mistaken, those packages only build-depends on libjpeg-dev:
   Package: analog
   Package: blender
   Package: dcraw
   Package: exactimage
   Package: fbi
   Package: ffmpegthumbnailer
   Package: fgfs-atlas
   Package: freej
   Package: fsviewer
   Package: ghostscript
   Package: gnash
   Package: grace
   Package: grace6
   Package: hasciicam
   Package: htmldoc
   Package: igstk
   Package: inventor
   Package: mathgl
   Package: nxcomp
   Package: openscenegraph
   Package: pike7.6
   Package: poppler
   Package: prima
   Package: shoes
   Package: ssystem
   Package: steghide
   Package: tipptrainer
   Package: xen-3
   Package: xen-unstable
   Package: xjig
   Package: xnc
   
   Those build-depend on libjpeg62-dev | libjpeg-dev:
   Package: csmash
   Package: djvulibre
   Package: epm
   Package: flightgear
   Package: iceape
   Package: libmng
   Package: metapixel
   Package: simgear
   Package: uvccapture
   Package: wine
   Package: xmhtml
   Package: ygraph
   
   And a vast majority of packages build-depend on libjpeg62-dev (that is
   roughly 220 packages if I'm correct).
   
   IOW, I'd say, first you can upload a new libjpeg in a new source
   package, that doesn't provide libjpeg-dev for now, so that we can clear
   NEW and FTBFS-es and stuff like that.
  
  I have little experience in stuff like this but as the new libjpeg is
  fully API compatible, couldn't the new dev package just have
  'Provides: libjpeg62-dev'? Then it should still be possible to do binNMUs
  without requiring sourceful uploads of all packages build-depending on
  it. The bugs to switch to libjpeg-dev as build-dep would still need to
  be filed, but they could be wishlist.
  
  AFAIK, that's how the transition from libltdl3 to libltdl7 was handled.
 
 It could work, though doing it one step at a time is probably wise. I
 expect far more problems with libjpeg than with libltdl, but I may be
 wrong and I'm just paranoid.

Given the history of the code I am confident breakage will be minimal.
(looks for the latest DSA on libjpeg).

 And FWIW, breaking something like 10 years of binary compatibility, when
 the glibc provides all you need to deal with symbol versioning, and
 you're as pervasive as libjpeg, is hell.

I suppose it can be safely argued that breaking binary compatibility once 
in ten years is better than breaking them every years.

 We will probably need to keep a libjpeg62 around in squeeze btw, as it's
 likely that some external stuff will require it...

That makes sense.

In anycase, libjpeg7 has been released now and is ABI incompatible with
libjpeg6b (and carry a new soname and is versionned).

What do you want me to do at this point?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

libjpegv7 transition

[Bill Allombert]

Dear release team,

libjpeg v7 is likely to be released at the end of June.
A prerelease tarball is available.

This version is ABI-incompatible with libjpeg6b.
However it should be fully API compatible.
To avoid symbol conflicts with libjpeg v6, the symbols are versionned.

This means the transition should be relatively safe but will involve
a lot of packages.

How do you want me to proceed ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


signature.asc
Description: Digital signature

Re: libjpegv7 transition

[Bill Allombert]

On Sun, Jun 14, 2009 at 08:01:21PM +0200, Bastian Blank wrote:
 On Sun, Jun 14, 2009 at 03:48:28PM +0200, Bill Allombert wrote:
  This version is ABI-incompatible with libjpeg6b.
  However it should be fully API compatible.
  To avoid symbol conflicts with libjpeg v6, the symbols are versionned.
 
 In the current version, the symbols are not versioned. So this does not
 hold as Base symbols match always.

So what do you suggest ? What is the impact ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Please unblock menu 2.1.41 (l10n update)

[Bill Allombert]

Dear Release team,

please unblock menu 2.1.41 for a l10n-only update:

menu (2.1.41) unstable; urgency=low

  * The true bubulle never burst release
  * Handling of l10n by Christian Perrier:
+ Menu sections translations:
  - Brazilian Portuguese updated by Eder Marques. Closes: #494159
  - Georgian added by Aiet Kolkhi. Closes: #498422
  - Greek updated by Emmanuel Galatoulas. Closes: #498463
  - Catalan updated by Jordi mallach. Closes: #499298
  * l10n: menu sections translation into Croatian updated by Josip Rodin,
Closes: #498055.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Please unblock menu/2.1.40

[Bill Allombert]

Hello,

Please unblock menu 2.1.40 which was uploaded the 24/07/2008 and closes
bug #489040 (issue with dpkg trigger handling).

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 


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

Re: Should su-to-root be shipped in a separate package?

[Bill Allombert]

On Wed, Mar 05, 2008 at 05:27:12PM -0600, Raphael Geissert wrote:
Please also remember that xdg-utils is Priority: optional while 
  debianutils
is Essential: yes, Priority: required; meaning that if packages were to
use 'xdg-su-wrapper' they would have to Depend on xdg-utils pulling yet 
  an
other package.
 
 
  This is a very weak argument: packages that implement XDG menus should
   really depend on xdg-utils (but of course not packages simply providing
   .desktop files).
 
 The proposal also includes .desktop files so I don't really see the
 point of your statement, specially because I find pointless to depend
 on xdg-utils just because you ship a given file (which I'm 100% sure
 the package can perfectly live and work without it).

I do not understand your sentence.

I was claiming that window managers/Desktop environment implementing XDG
menu should depend on xdg-utils. This way, packages only providing
.desktop files can assume that xdg-utils will be installed when needed
without a dependency. 

But other than that what do you think about moving su-to-root to
debianutils?
 
 
  Given what is su-to-root, I do not think it make sense to have it be
   Essential: yes. It is almost never used.
 
 Probably because not very much people know about it and because there
 has been no concensus on what to use as a su wrapper.

There is certainly a consensus to use it for (Debian) menu entry and it
is seldom used.

Cheers,
Bill.


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

Re: Should su-to-root be shipped in a separate package?

[Bill Allombert]

On Sun, Mar 02, 2008 at 11:58:49AM -0600, Raphael Geissert wrote:
 Bill Allombert wrote:
 
 Which as far as I'm aware of it doesn't exist.

It used to. Actually su-to-root desktop guessing code was lifted from
the script in xdg-menu. I do not know why it was removed, thought it
was not very good.

 IMHO we can not just 'give up' because there's no common way to do it; if in
 the feature xdg-utils ships such kind of wrapper su-to-root could simply
 check for it and use it instead.

The Exec field of .desktop file is specified byt the XDG menu draft, and
should follow the XDG draft, and not distribution-specific
indiosyncrasy. Discuss the issue on the XDG list.

 Please also remember that xdg-utils is Priority: optional while debianutils
 is Essential: yes, Priority: required; meaning that if packages were to
 use 'xdg-su-wrapper' they would have to Depend on xdg-utils pulling yet an
 other package.

This is a very weak argument: packages that implement XDG menus should
really depend on xdg-utils (but of course not packages simply providing
.desktop files).

 But other than that what do you think about moving su-to-root to
 debianutils?

Given what is su-to-root, I do not think it make sense to have it be
Essential: yes. It is almost never used.

I do not like the idea of moving su-to-root outside of menu source
because there are people using menu outside Debian and they would
be inconvenienced if the tarball does not contain su-to-root anymore.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

Re: Should su-to-root be shipped in a separate package?

[Bill Allombert]

On Thu, Feb 21, 2008 at 09:25:40PM +0100, Daniel Baumann wrote:
 so.. what is the status of this? bill, do you intend to hand over
 su-to-root to debianutils?

At tis point, I do not intend to do that, no.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 


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

Re: Should su-to-root be shipped in a separate package?

[Bill Allombert]

On Sun, Feb 03, 2008 at 02:59:11PM -0600, Raphael Geissert wrote:
 Hello Bill,
 
 Some weeks ago I proposed a new release goal which goal is to use su-to-root 
 instead of a custom *su wrapper in menu and .desktop files[1].
 
 As Armin Berres stated on his message[2] there are some 
 dependencies/recommends/suggests that need to be considered first.
 Since su-to-root is currently just a shell script I would your opinion on 
 whether su-to-root (and its translations and documentation of course) should 
 be shipped in a separate package so making the move to su-to-root only 
 requires a Depends: su-to-root which would be shipped as arch: all, instead 
 of a dependency on menu which is arch any.

I do not think it is a good idea to use su-to-root inside .desktop file,
because this would make such .desktop file Debian-specific (and thus
would not be integrated upstream). Instead a freedesktop approved
remplacement to su-to-root should be provided by xdg-utils. 

 This would have the benefit of making su-to-root OR depend, instead of just 
 suggest, on the several packages which provide a su* wrapper ensuring its 
 functionality.

Given that su-to-root can use plain su which is Essential: yes, I do not
see the advantage of such OR depend which will always be satisfied.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 


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

Re: Allow newer rggobi into etch?

[Bill Allombert]

On Mon, Feb 12, 2007 at 07:52:42AM -0600, Dirk Eddelbuettel wrote:
 On Mon, Feb 12, 2007 at 01:47:25PM +0100, Julien Cristau wrote:
  On Mon, Feb 12, 2007 at 06:12:28 +, Dirk Eddelbuettel wrote:
  
   Is there a way for me to access a testing machine for builds?
   
  There's debootstrap, which can create testing chroots.
 
 That is entirely orthogonal to my question, so let me repeat:  any
 testing machhines I can log into?

I am not sure if it is what you ask for, but most port machine include
a testing chroot, so you can just login and do 'dchroot testing'.
(at least it works on pergolesi and paer).

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

Re: gcj-4.1_4.1.1-20 and gcc-4.1_4.1.1-21 for testing

[Bill Allombert]

On Mon, Dec 11, 2006 at 09:14:51AM +0100, Matthias Klose wrote:
 Please consider for testing:
 
 gcc-4.1:
 
 4.1.1ds2-20 is for four weeks in the archive without regressions
 report to the BTS, -21 fixes important bugs for non-release archs.
 Maybe Lucas could rebuild the testing archive with the -20 or -21
 packages before letting theis version into testing.
 
 gcc-4.1 (4.1.1ds2-21) unstable; urgency=high
 
   * Enable -pthread for GNU/Hurd (Michael Banck). Closes: #400031.
   * Update the m68k-fpcompare patch (Roman Zippel). Closes: #401585.
 
  -- Matthias Klose [EMAIL PROTECTED]  Sun, 10 Dec 2006 12:35:06 +0100
 
 gcc-4.1 (4.1.1ds2-20) unstable; urgency=low
 
   [Matthias Klose]
   * Update to SVN 20061115.
 - Fix PR tree-optimization/27891, ICE in tree_split_edge.
   Closes: #370248, #391657, #394630.
 - Fix PR tree-optimization/9814, duplicate of PR tree-optimization/29797.
   Closes: #181096.
   * Apply the libjava/net backport from the redhat/gcc-4_1-branch.
   * Apply proposed patch for PR java/29805.

I suggest we approve it because at this point it is more likely there
are packages in Etch that FTBFS with -19 than packages in Etch that
FTBFS with -21 since -20/-21 were used to build packages that went to
Etch.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

Re: upload of missing binary packages to Etch

[Bill Allombert]

On Thu, Dec 21, 2006 at 03:22:31AM -0800, Steve Langasek wrote:
 On Thu, Dec 14, 2006 at 06:35:48PM +0100, Bill Allombert wrote:
 
  Etch is frozen but some architectures have been ignored for testing
  propagation in the past.
 
  1) is there a convenient way to get the list of source packages that lack 
  binary packages for some architectures in Etch but that include such binary
  packages (with different version) in Sid?
 
 So far as I know, there is not; sounds like you'd need to do a bit of new
 scripting.

But madison is not available currently and brute-forcing the Packages
seems rather awkward, especially when a single SQL query would do the
trick.

Any better idea ?

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large blue swirl here. 


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

Re: upload of missing binary packages to Etch

[Bill Allombert]

On Thu, Dec 21, 2006 at 02:58:27PM +0100, Marc 'HE' Brockschmidt wrote:
 Bill Allombert [EMAIL PROTECTED] writes:
  But madison is not available currently and brute-forcing the Packages
  seems rather awkward, especially when a single SQL query would do the
  trick.
 
 madison is available for you. You have access to ftp-master, where the
 projectb is (naturally) up-to-date and can be used.

So first thing, I was not aware that ftp-master had been moved to ries.
Secondly, ries does not actually carry madison, but there is dak
and dak ls should do the same thing.

Thanks a lot!

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large blue swirl here. 


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

Re: Bug#402179: [Bug-tar] Race condition in GNU tar test-suite

[Bill Allombert]

On Tue, Dec 19, 2006 at 11:32:30AM -0700, Bdale Garbee wrote:
 On Tue, 2006-12-19 at 15:46 +, Alex Owen wrote:
 
  This patch should fix the problem. I guess the opotions are to aply
  this patch to 1.16 or package 1.16.1. I guess applying the patch is
  the better option if we wnat to fix this for etch.
 
 It's not clear to me that we need to disturb etch to fix this.  It's
 just a race in a regression test, and I *think* 1.16 is built for all
 the architectures that matter for etch release, isn't it?  If not, I'm
 certainly willing to apply the patch and upload this.

I would very much like that patch to be applied in Etch.
Non-deterministic packages build failures cause large waste of time.

Thanks in advance,

Cheers,
--
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

Re: fvwm1, bug 392814, version 1.24r-51 fixes problem with UTF-8 locales

[Bill Allombert]

On Sat, Dec 16, 2006 at 10:31:12PM -0800, Steve Langasek wrote:
 Based on the bug log, I guess fvwm will continue to be usable in iso8859-1
 locales, which is roughly the case today anyway, and the added patch will
 also get utf8 locales working as long as they use a latin1 subset of
 characters for the menus?

In fact, if the characters are not latin1 compatible, then update-menus
will not translate the menu, so the menu will be in ASCII-7bit.

(I personnally tested the packages and I approve the unblocking.)

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

Re: Packages rename and conffiles

[Bill Allombert]

On Mon, Dec 11, 2006 at 11:28:34AM +, Ian Jackson wrote:
 Steve Langasek writes (Re: Packages rename and conffiles):
  What position do you think we should take on this issue?  If there's no
  known solution that avoids conffile prompts with both the old and new
  versions, and given that there's no good systematic way to arrange for one
  version of dpkg or the other to be installed at the time of upgrade,
  perhaps it's best to favor the new dpkg?
 
 The ideal solution would be a general arrangement that ensured that
 upgrades from release A to B were always done with the package
 management system from B (backported, presumably).

So are you planning to provide such a backport ? Without it we will have
to investigate others solutions. 

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.


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

upload of missing binary packages to Etch

[Bill Allombert]

Dear Release team,

Etch is frozen but some architectures have been ignored for testing
propagation in the past.

1) is there a convenient way to get the list of source packages that lack 
binary packages for some architectures in Etch but that include such binary
packages (with different version) in Sid?

2) Is there a possibility to upload such missing binaries ?

Thanks in advance,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large blue swirl here. 


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