Re: GMP transition: 4.3.2 to 5.0.1?
On Mon, Mar 21, 2011 at 08:22:15PM +0100, Julien Cristau wrote: > On Sat, Mar 19, 2011 at 13:23:41 -0500, Steve M. Robbins wrote: > > 1. Upload gmp4, as described above. In progress, will upload shortly. > > 2. Upload gmp introducing libgmp-dev as the real package, providing > >virtual packages libgmp3-dev and libgmp10-dev. > > > > Is this accurate? Anything else? > > > I don't think 2 is necessary, or at least not right now. It's fairly > independent as far as I can tell, and it's a cosmetic issue more than > anything else. As far as I can tell, the only advantage of having "libgmp-dev" as real rather than virtual is so that packages can version their build-dep. Given that libgmp-dev is new, I'd agree it is not pressing. However, I've since learned that ghc and mlton both build-depend on themselves as well as libgmp3-dev. Further, mlton has a versioned build-dep on libgmp3-dev so the least painful way forward is to have libgmp3-dev become non-virtual once again. For this reason, I plan to upload a new gmp with non-virtual libgmp3-dev as a dummy package that depends on libgmp-dev. I might as well make libgmp-dev non-virtual at the same time. Let me know if this raises any concerns. Thanks, -Steve signature.asc Description: Digital signature
Bug#619221: nmu: calibre_0.7.44+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Calibre needs rebuild against the sip-api update: nmu calibre_0.7.44+dfsg-1 . ALL . -m "Rebuild against python-sip 4.12.1-1 (Closes: #616372)" Regards, Kanru - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-rc4+ (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2IEFEACgkQsbdbXzZcx6LxNwCgv8d17aJe3MB480qy7lj3x29i PDgAn0HDL+6Fj900Zap98SrFu0w5ciwH =JcfR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322025829.15564.94524.report...@anar.kanru.info
Bug#613735: Acknowledgement (transition: gobject-introspection)
On 22/03/11 00:21, Julien Cristau wrote: > On Sun, Mar 20, 2011 at 21:42:04 +, Emilio Pozuelo Monfort wrote: > >> We don't necessarily need to involve gtk+2.0 and libsoup2.4 in this >> transition, >> as I've got gir-repository to build gir1.2 packages. Most of the other stuff >> don't probably need to be transitioned together, as migrating >> gobject-introspection won't break them, and they have no rdeps, so the >> transition would most probably involve: >> >> clutter-1.0 >> gir-repository >> gobject-introspection >> gstreamer0.10 >> json-glib >> webkit >> seed >> epiphany-extensions-more >> > Looks like seed got uploaded recently, but it won't reach testing before > the gmp stuff is resolved (hopefully soonish). If you don't need that > in testing before the move to gir1.2, I think we can go ahead with this. > We should have gmp taken care of before that lot is ready. Great! There's no hurry for seed to migrate, so I've started the transition. In one or two days everything should have been uploaded, and then we can start the fun of build failures et al. Cheers, Emilio -- 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/4d87f083.9010...@debian.org
Re: libexiv2-9 -> libexiv2-10 transition proposal
On Tue, Mar 1, 2011 at 00:12:11 +1100, Mark Purcell wrote: > I have uploaded the new libexiv2-10 to experimental and would now like > to propose the transition. [...] > > Reverse Depends: > ufraw > ufraw-batch > gimp-ufraw > libstreamanalyzer0 > shotwell > rawstudio > qtpfsgui > python-pyexiv2 > merkaartor > libextractor-plugins > krename > kphotoalbum > krita > libkexiv2-8 > gwenview > kdebase-runtime > hugin > hugin-tools > gthumb > gpscorrelate > gpscorrelate-gui > gnome-commander > libgexiv2-0 > geeqie > geeqie-gps > libexiv2-dev > libexiv2-dbg > exiv2 > Did the API change? Did the reverse dependencies get test-built (and tested) with the new libexiv2? Cheers, Julien -- 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/20110322002504.gt3...@radis.liafa.jussieu.fr
Bug#613735: Acknowledgement (transition: gobject-introspection)
On Sun, Mar 20, 2011 at 21:42:04 +, Emilio Pozuelo Monfort wrote: > We don't necessarily need to involve gtk+2.0 and libsoup2.4 in this > transition, > as I've got gir-repository to build gir1.2 packages. Most of the other stuff > don't probably need to be transitioned together, as migrating > gobject-introspection won't break them, and they have no rdeps, so the > transition would most probably involve: > > clutter-1.0 > gir-repository > gobject-introspection > gstreamer0.10 > json-glib > webkit > seed > epiphany-extensions-more > Looks like seed got uploaded recently, but it won't reach testing before the gmp stuff is resolved (hopefully soonish). If you don't need that in testing before the move to gir1.2, I think we can go ahead with this. We should have gmp taken care of before that lot is ready. Cheers, Julien -- 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/20110322002120.gs3...@radis.liafa.jussieu.fr
Re: gnome-pilot transition?
Sorry for not answering earlier. On Mon, Feb 14, 2011 at 23:37:13 +, Neil Williams wrote: > gnome-pilot is orphaned but there is a new upstream release, I'm > looking at a QA upload (as I did the last one). Ubuntu have packaged it > but not changed the package name. Formerly it was libgnome-pilot2 but > now that library has a SONAME of 5 and the library package includes two > other libraries, SONAME 3 and SONAME 4. > > ./usr/lib/libgpilotd.so.5 > ./usr/lib/libgpilotdcm.so.4 > ./usr/lib/libgpilotdconduit.so.3 > It's usually better to have each library in a separate package. Makes it possible to handle an SONAME bump in one of them and not the others. > AFAICT the only reverse dependency is gnome-pilot-conduits which I've > also updated, but won't upload yet. > > Changes are in SVN: > > http://svn.debian.org/wsvn/collab-maint/ext-maint/gnome-pilot/trunk/?op=log > > http://svn.debian.org/wsvn/collab-maint/ext-maint/gnome-pilot-conduits/trunk/?op=log > > I propose to change gnome-pilot to build libgnome-pilot5_2.32.0-1 which > will have to go through NEW. > > Are there any problems with this mini-transition if gnome-pilot-conduits > is not uploaded until gnome-pilot has cleared NEW? (Neither package can > migrate without the other as migrating new gnome-pilot will break > installations of existing gnome-pilot-conduits.) > Looks like that's blocked by 1) gnome-pilot FTBFS on kfreebsd-* 2) #614489 in gnome-pilot-conduits Cheers, Julien -- 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/20110322000945.gr3...@radis.liafa.jussieu.fr
Bug#619191: nmu: nettle transition
On Mon, Mar 21, 2011 at 22:51:56 +0100, Magnus Holmgren wrote: > A recent new version of nettle was recently updated, introducing some API > and ABI changes. nettle doesn't have many rdepends, but these exist (and > require no source changes): > > nmu chiark-utils_4.1.28+nmu2 . ALL . -m "Rebuild against nettle 2.1 > (libnettle4)" > nmu chiark-tcl_1.1.0+nmu2 . ALL . -m "Rebuild against nettle 2.1 (libnettle4)" > nmu rdup_1.0.5-1 . ALL . -m "Rebuild against nettle 2.1 (libnettle4)" > Scheduled. Note that xorg-server also uses libnettle.a (for the debian installer), hopefully that doesn't need source changes either. What about the other reverse dependencies? - lsh-utils - pike7.6 - rdfind (I see you've uploaded pike7.8 for this transition) Cheers, Julien -- 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/20110321224023.gp3...@radis.liafa.jussieu.fr
Bug#619191: nmu: nettle transition
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal A recent new version of nettle was recently updated, introducing some API and ABI changes. nettle doesn't have many rdepends, but these exist (and require no source changes): nmu chiark-utils_4.1.28+nmu2 . ALL . -m "Rebuild against nettle 2.1 (libnettle4)" nmu chiark-tcl_1.1.0+nmu2 . ALL . -m "Rebuild against nettle 2.1 (libnettle4)" nmu rdup_1.0.5-1 . ALL . -m "Rebuild against nettle 2.1 (libnettle4)" -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: GMP transition: 4.3.2 to 5.0.1?
On Sat, Mar 19, 2011 at 13:23:41 -0500, Steve M. Robbins wrote:
> So, given that the incompatibility between GMP 4 and 5 is removing a
> couple of public functions, you believe it is safe to have the shared
> libs coexist in the archive?
>
It looks that way.
> That's fine. Can you help me work out the specific steps I should
> take now?
>
> In your previous message, you suggest to re-introduce gmp 4.3.2 as a
> separate source package (e.g. gmp4), building *only* the libgmp3c2
> binary package.
>
Right.
> Raphael Geissert has requested also to change gmp to build libgmp-dev
> as a real package. I would also make it provide libgmp10-dev because
> that package name was used in experimental and a few packages are now
> using it.
>
> In addition, I made the new -dev package also provide libgmp3-dev
> because of the strange situation of the Haskell compiler ghc [1]. My
> intention was for that to be temporary and remove it once ghc got
> bootstrapped everywhere. In another of your messages you say
>
> Again, the -dev package needs to keep providing libgmp3-dev
> anyway, so changing the build-deps is unnecessary churn.
>
> What did you mean by this? Do you mean that the new -dev package
> needs to continue providing libgmp3-dev forever? Or did you mean that
> since it is presently providing it, there is no need to change all the
> build-deps at once; just let things alone until such time that we
> remove this "provides"?
>
The latter. There's no hurry to drop the Provides, and keeping it
reduces the disruption in the archive since it means the move from
libgmp3-dev to libgmp{,-10}-dev can be staged over a longer period.
> Assuming you meant the latter, here is my understanding of the
> next steps:
>
> 1. Upload gmp4, as described above.
> 2. Upload gmp introducing libgmp-dev as the real package, providing
>virtual packages libgmp3-dev and libgmp10-dev.
>
> Is this accurate? Anything else?
>
I don't think 2 is necessary, or at least not right now. It's fairly
independent as far as I can tell, and it's a cosmetic issue more than
anything else.
As I mentioned in my previous mail it may be a good idea to investigate
linking the libgmp's with -Bsymbolic to ensure that internal symbols are
looked up in the right library. Not a blocker though, so we can
probably leave that aside until/unless issues pop up if you prefer.
Thanks for your work, and let me know if anything's unclear still.
Cheers,
Julien
--
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/20110321192215.gj3...@radis.liafa.jussieu.fr
Bug#547393: libjpeg8 transition.
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. > What is more problematic is the numbers of packages that embed a copy of > libjpeg6b, > but this is mostly na independant issue. > Let's keep this separate. Cheers, Julien -- 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/20110321125303.gf3...@radis.liafa.jussieu.fr
Bug#619117: perl 5.12 transition
Package: release.debian.org Owner: p...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition On Sun, Mar 20, 2011 at 23:10:27 +, Dominic Hargreaves wrote: > On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote: > > I would like to register an interest in carrying out a perl transition > > soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This > > transition has already been in preparation for some time, and I think > > we are in a good position to schedule this now. This is the first major > > transition I've been involved in (I've recently become a co-maintainer > > of the perl package), so please bear with me if I miss anything out. > > You can see the transition tracking bugs at [1]. > > [snip rest of mail] > > Hi, > > I wondered whether anyone had had a chance to look at scheduling this > in yet, of if there's a better way to go about this? > Sorry, not yet. Filing as a bug so we don't drop it. Roughly how many packages does the move to 5.12 involve, and how many would need source uploads? Thanks, Julien -- 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/20110321124248.ge3...@radis.liafa.jussieu.fr
