gap migration to testing

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

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

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

Bug#841911: transition: pari

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

Bug#841911: transition: pari

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

Bug#841911: transition: pari

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug#771434: unblock: debian-policy/3.9.6.1

. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. + * debian/rules clean: remove stamp-h1 + * debian/copyright: fix download URL + + -- Bill Allombert ballo...@debian.org Thu, 05 Dec 2013 23:43:52 +0100 + libjpeg6b (6b1-3) unstable; urgency=low * Add multiarch support (similar to libjpeg8). closes: #642079 diff -Nru libjpeg6b-6b1/debian

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

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

Re: First autoremovals happen in about 8 days

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.

ports and multiarch

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

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

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

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

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

Bug#691789: unblock: popularity-contest/1.56

[ 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

Re: state of libjpeg transition

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

state of libjpeg transition

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

proposed binNMU for libjpeg transition

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.

binNMU for libjpeg8 migration (2nd try)

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

binNMU for libjpeg8 migration

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

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

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

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

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

Bug#547393: libjpeg8 transition.

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

Bug#547393: libjpeg8 transition.

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#547393: libjpeg8 transition.

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

Bug#547393: libjpeg8 transition.

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#547393: libjpeg8 transition.

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

Bug#547393: libjpeg8 transition.

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

Bug#547393: libjpeg8 transition.

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

libjpeg8 transition.

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

Bug#609805: unblock: popularity-contest/1.50

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,

Bug#609805: unblock: popularity-contest/1.50

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

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

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

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

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

Bug#603512: unblock: popularity-contest/1.49

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

Bug#603512: unblock: popularity-contest/1.49

[ 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

Bug#602565: unblock: menu-l10n/0.20101027

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

status of libjpeg6b1 transition

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

Bug#598333: unblock: menu/2.1.44

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

Re: Transition: libjpeg6b with versionned symbols

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

Re: Transition: libjpeg6b with versionned symbols

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

Re: Transition: libjpeg6b with versionned symbols

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

Re: Transition: libjpeg6b with versionned symbols

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

Re: Transition: libjpeg6b with versionned symbols

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

Transition: libjpeg6b with versionned symbols

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

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

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

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

Re: JPEG 8 transition

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

Re: JPEG 8 transition

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

Re: BinNMU for libjpeg8 transition

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

Re: BinNMU for libjpeg8 transition

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

Re: BinNMU for libjpeg8 transition

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

Re: BinNMU for libjpeg8 transition

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

Re: BinNMU for libjpeg8 transition

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

Re: BinNMU for libjpeg8 transition

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

BinNMU for libjpeg8 transition

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

Re: Upcoming libjpeg8 transition

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

Re: Upcoming libjpeg8 transition

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

Re: Upcoming libjpeg8 transition

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

Upcoming libjpeg8 transition

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

Re: development plans for the squeeze cycle

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

Re: libjpeg62-dev - libjpeg-dev transition

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

Re: libjpeg62-dev - libjpeg-dev transition

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

Re: libjpegv7 transition

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

Re: libjpegv7 transition

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

Re: libjpegv7 transition

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

libjpegv7 transition

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

Re: libjpegv7 transition

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

Please unblock menu 2.1.41 (l10n update)

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

Please unblock menu/2.1.40

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

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

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

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

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

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

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,

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

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

Re: Allow newer rggobi into etch?

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,

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

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

Re: upload of missing binary packages to Etch

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

Re: upload of missing binary packages to Etch

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

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

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

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

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

Re: Packages rename and conffiles

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

upload of missing binary packages to Etch

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)

  1   2   >