Re: give back consolekit
+ Michael Biebl (Mon, 20 Jul 2009 02:26:49 +0200): Hi, consolekit has been failing on sparc due to the broken debhelper. This is fixed now, so let's try again: gb consolekit_0.3.0-3 . sparc Done. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Removal of remaining packages using GTK 1.2
libjsw All removed From a very quick look, at least some remained, eg. libjsw above: trying: -gtk+1.2 skipped: -gtk+1.2 (5 - 399) got: 16+0: i-16 * i386: epigrass, etalk, gpsim-led, gpsim-logic, gspiceui, gtalk, gtkglarea5, gtkglarea5-dev, gwave, jscalibrator, libguilegtk-1.2-0, libguilegtk-1.2-dev, python-visual, xemacs21-gnome-mule, xemacs21-gnome-mule-canna-wnn, xemacs21-gnome-nomule Eg. jscalibrator belongs to libjsw, which wasn't removed because it has one unrelated reverse dependency, searchandrescue. Thanks for looking into this, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
+ Hubert Chathi (Tue, 26 May 2009 22:35:38 -0400): I uploaded gorm.app and price.app a couple weeks ago. I should be uploading the other two soon (IIRC, gworkspace and gnustep-dl2 depended on other packages being built). Sorry, I was on vacation last week, so I did not build/upload those packages yet. Okay. Please note however that the new GNUstep already migrated to unstable thanks to those two packages having been Bin-NMUed, so there's less of a hurry. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Open MPI 1.3 transition
+ Manuel Prinz (Sat, 04 Apr 2009 21:14:57 +0200): Dear release team, Hello, Manuel. between versions 1.2 and 1.3 the ABI of Open MPI broke. The next upload will fake an SONAME change by changing the library package name. I had contact with Adeodata Simo about this (see bug #510845). Since the upload will break dependant packages, I'd like to coordinate the upload with you. Currently, the next upload will fix the following bugs: 519725, 520597, 517543, 510845, 515116, 512616, and 522153. (4 serious, 1 important.) The current package can be found in our SVN repository. I rebuild all dependant packages in a sid chroot with the new Open MPI package installed. There were no build errors. Since the API stays stable, recompilation will fix the packages. Okay, thanks for pursuing this, let's go forward with it. Please upload and let us know when you have done so. Unfortunately this will get tied to the ongoing petsc transition, which is blocked by a couple RC bugs on petsc4py and libmesh, but I think we'll be able to sort that out, or do removals. Thanks for your patience. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU seahorse-plugins on amd64
+ Josselin Mouette (Wed, 27 May 2009 13:03:05 +0200): Hi, I have inadvertently built seahorse-plugins/amd64 on a machine with some experimental packages, and it ends up with a wrong dependency. Could you please rebuild it? nmu seahorse-plugins_2.26.1-1 . amd64 . -m 'Rebuild in a clean unstable environment' Done. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU apache2-mpm-itk
+ Stefan Fritsch (Mon, 25 May 2009 21:30:08 +0200): Hi, please binNMU apache2-mpm-itk in unstable to build with apache2-src 2.2.11-5. Thanks. Done. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint glest, glest-data
+ Ansgar Burchardt (Sun, 24 May 2009 18:56:04 +0200): Hi, please add hints for glest/3.2.2-1 and glest-data/3.2.1-1 so they can migrate to testing. Hint added, thanks. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Sun, 24 May 2009 22:41:31 -0500): Hi, Hello! On Fri, May 22, 2009 at 01:35:24PM +0200, Adeodato Sim?? wrote: + Steve M. Robbins (Fri, 22 May 2009 00:37:15 -0500): * a mass bug filing for packages build-depending on versioned packages to build-depend on the un-versioned ones instead Not yet done. Okay; there're 11 of such packages AFAICS. I hope you'll be able to file the bugs at some point in the future, though it's not the most urgent of tasks. I'll put this on my TODO list. Great, thanks. * an automatic rebuild of those packages already build-depending on the un-versioned ones (from Boost 1.34), and file bugs for those that fail I used rebuildd locally to build all such packages (99 by my reckoning) and found 69 succeed, while 30 fail to build. I have just started going through the log files and have filed bugs for two of those. I have just gone through all the build logs. I previously sent you a list of successes, but I need to add one more: csound. See the end of this email for the complete list of successes. The failures all have bugs filed against them; see below. Nearly half of the failures did not appear to be caused by Boost and often there was already a bug filed, which I simply quote here. The remainder have a bug filed by me. Excellent work, thank you. Me, I've scheduled the required rebuilds. Note that they are not all the packages in The Successes below, since many of those do build-depend on boost, but don't depend on it at run time. Hence, it was necessary to know which ones of them FTBFSed, but it's not necesssary to rebuild them now. (I didn't realize in time such was the case, many packages build-depending on boost and not depending at run time on it. Should I have remembered, I would've let the periodic archive rebuilds deal with the FTBFSes, and asked you to rebuild only the ones with run-time dependnecies, sorry about that.) Most of the Boost-related bugs are due to the fact that we dropped single-threaded library variants, which caught any packages that don't use the -mt variant. A couple just need updated build-deps. Four packages may need non-trivial changes; I didn't investigate too far. This is much better success than I had expected. I suggest we can remove Boost 1.34.1 now. What do you think? I think it's fine, please file an RM bug against ftp.debian.org, pointing to this message if necessary. Breakage is similar to that of any other library transition. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#530001: compiz-core: compiz and compizconfig-settings-manager indirectly conflict
+ Julien Cristau (Sat, 23 May 2009 01:50:58 +0200): On Fri, May 22, 2009 at 12:41:12 -0600, Al Khaef wrote: Hi. all of the below applies to debian squeeze compizconfig-settings-manager (as well as fusion-icon and some other compiz-related packages) requres libcompizconfig0, and compiz-core has the following dependency: Breaks: libcompizconfig0 ( 0.8.0) However, in suqeeze, (0.7.6-1) is the latest available. Therefore, none of these other packages can be installed, and compizconfig can't be run. This is due to a bug in britney (the tool that handles package migration to testing), which doesn't handle Breaks, I think. Hopefully libcompizconfig will migrate to testing soon, in the mean time you can install the version from unstable. It looks like this is stalled because protobuf waits for java stuff on hppa, and failed to build on ia64. sigh. CCing -release to make sure they're aware of the breakage in squeeze. Ugh. Ok, since the blockers seem like will take time to sort out, I've added a hint to allow libcompizconfig to migrate without hppa/ia64. Hopefully it'll succeed. Thanks for the notice, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: SuiteSparse 3.2.0-3.3.0 transition
+ Rafael Laboissiere (Sun, 10 May 2009 14:57:15 +0200): The upstream authors of SuiteSparse have released version 3.3.0. If we package this version for Debian, we will have to go through another library transition since the package will be named libsuitesparse-3.3.0. I gave a try at this new version and proposed [1] to split the libraries shipped in this package into individual packages, as has been done for COLAMD in the past (package name libcolamd-3.2.0). I'm sorry it took so long to get back to you. What you propose sounds sane to me if you're willing to do the effort. With libcolamd split out already, hence openoffice.org not being part of a suitesparse transition more than when strictly necessary, it is less of a pressing issue (since the rest of suitesparse's reverse dependencies have a less complex dependency graph), but you're very welcome to do so. Please, tell us how we should procceed with this transition. I would guess that binNMUs would be enough but I am not sure about the upgradability of the whole thing. Yes, Bin-NMUs should be enough. I see there are appropriate Replaces in place, and I think that should be enough. I *think* the Conflicts are not necessary, and I'm not sure whether they hurt or not; upgrdability has never been my strong point, and in any case they're very common practice. Please upload at your convenience, and get back to us for Bin-NMUs. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libbulletml transition
+ Peter De Wachter (Wed, 13 May 2009 00:44:40 +0200): Hi, Hello, I'm planning to upload a new version of the bulletml library. This version will drop its dependency on Boost. The current version uses Boost only for boost::shared_ptr, but the same thing exists in the C++ standard library these days (std::tr1::shared_ptr). This causes an API change, and hence a new soname. Bulletml has the following reverse dependencies. I've tested them, they all build and work with the new bulletml. mu-cade parsec47 rrootage torus-trooper tumiki-fighters val-and-rick Hm, sorry for the delay. Please upload at your earliest convenience and let us know when you've done so. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ptlib/ opal transition proposal - NEW libpt2.6.2 libopal3.6.2
+ Mark Purcell (Sun, 24 May 2009 17:48:13 +1000): Hi, ptlib and opal have NEW upstream releases with a soname bump: Propose NEW packages libpt2.6.2 libopal3.6.2 and binNMU of the remaining rdepend ekiga. Please go ahead and let us know when you have uploaded. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please block sed 4.2-1
+ Andreas Metzler (Sat, 09 May 2009 09:05:02 +0200): Please stop sed from migration to testing until a to-be-uploaded version of exim4 (i.e. = 4.69-10.1) that has a workaround for the bug has reached lenny. exim4 4.69-11 is now in testing, so I've removed the block hint against sed. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please do a binNMU for unicap on sparc
+ Andres Mejia (Fri, 22 May 2009 17:56:58 -0400): Hello! Please do a binNMU for unicap on sparc. Right now, the unicap libraries and -dev packages are uninstallable on sparc because it depends on an unavailable version of the ffmpeg-debian libraries, due to a bug that was in ffmpeg-debian. This bug has been resolved with ffmpeg-debian-4:0.5+svn20090420-2. See bug #527350. I already spotted this a couple days ago and scheduled it. It's now built, and waiting for the buildd admin to upload it. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gnome-volume-manger 2.24.1-3~squeeze1 for t-p-u
+ Michael Biebl (Thu, 21 May 2009 23:38:20 +0200): So it seems, 2.24.1-3~squeeze1 never made it into testing. But as nautilus has migrated now, it's not longer necessary anyway. Please drop/reject 2.24.1-3~squeeze1 now and unblock 2.24.1-3 again. Ok, hint for 2.24.1-3~squeeze1 dropped, 2.24.1-3 unblocked. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Fri, 22 May 2009 00:37:15 -0500): Hello again, Adeodato, Hello! * a mass bug filing for packages build-depending on versioned packages to build-depend on the un-versioned ones instead Not yet done. Okay; there're 11 of such packages AFAICS. I hope you'll be able to file the bugs at some point in the future, though it's not the most urgent of tasks. * an automatic rebuild of those packages already build-depending on the un-versioned ones (from Boost 1.34), and file bugs for those that fail I used rebuildd locally to build all such packages (99 by my reckoning) and found 69 succeed, while 30 fail to build. I have just started going through the log files and have filed bugs for two of those. I see. Do you suggest we remove boost now or wait for the 30 failures to be fixed? I suggest you provide me with the list of packages that succeeded, so that I can schedule Bin-NMUs at least for those. I could also schedule all of them, and trust that the buildd admins will file the bugs for the failures. Or is there some deeper investigation that it's good to perform for each of the failures? I???m foreseeing this won???t be a cup of tea, but it???s something that has to be done just once. With a bit of luck, we???ll get rid of at least boost 1.34 and 1.35, and ideally 1.37 as well. Then, when Boost 1.39 comes along, please contact us again, and we???ll figure out how to proceed. Boost 1.39 is already out ... :-) Heh, I see. Well let's get rid of 1.34 first, by rebuilding against 1.38, and go from there, ack? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Erlang transition to 1:13.b
+ Sergei Golovan (Thu, 21 May 2009 10:19:00 +0400): Hi! Please, hint erlang, couchdb, ejabberd, libsdl-erlang, wings3d and yaws to testing. This should finish transition to Erlang 13.b.1. Done. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
+ Yavor Doganov (Fri, 15 May 2009 11:22:24 +): В Sat, 02 May 2009 20:32:22 -0400, Hubert Chathi написа: Has new upstream version -- will upload shortly, no bin-NMU needed: - gnustep-dl2 - gorm.app - gworkspace - price.app Hubert/Gürkan: The transition is going on nicely now that the hppa/ powerpc troubles are resolved. There are only a few packages waiting to be built and/or uploaded (mostly hppa). Could you please upload these soon? Alternatively, we can ask the release team to schedule binNMUs and postpone the new upstream uploads after the transition (this seems like a faster and safer route to me). I believe only gorm.app needs a sourceful upload (#527659). I confirm the transition is ready except by these four packages. Should I be scheduling Bin-NMUs for these packages after all? Yavor, is the gorm.app upload something you could take care of, or somebody else could? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
+ Yavor Doganov (Fri, 22 May 2009 16:14:00 +0300): On Fri, May 22, 2009 at 02:41:39PM +0200, Adeodato Simó wrote: - gnustep-dl2 - gorm.app - gworkspace - price.app I confirm the transition is ready except by these four packages. gorm.app and price.app were uploaded (and built/installed everywhere already). Ah, yes. It's only that my test britney did not migrate them because they're not old enough to migrate. Should I be scheduling Bin-NMUs for these packages after all? Among the team members only Hubert can upload, but I read in his blog that he's on VAC for a week (don't know since when). I'm not involved in the packaging of both gworkspace.app and gnustep-dl2, so I definitely do not want to overwrite whatever changes they've made (these packages are not in our team repo). So, risking Hubert's/Gürkan's anger, I suggest to schedule binNMUs for gnustep-dl2 and gworkspace.app. AFAICS the worst thing that can happen is some extra load on the buildds if Hubert uploads them before the migration is over + a release team member having to reset age-days accordingly. (And some extra delay, of course.) Okay, I've scheduled the Bin-NMUs. Buildds can certainly cope with that at the moment. The other tiny blockers are lynkeos.app on ia64 (to be uploaded), and charmap.app on mips (stuck in Built state for far too long). Yes, I had these under my radar and have been addressed already (i.e., uploaded). Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please binNMU a number of libevent reverse dependencies
+ Philipp Kern (Thu, 21 May 2009 12:18:24 +0200): [ Looks like we missed this in the GNOME and KDE mess? dato, could you ] [ add that to the transitions tracker? ] It was there already: https://buildd.debian.org/transitions/summary.html#libevent There was something fishy about this transition I wanted to investigate, but didn't get around to it. I'm sorry I didn't communicate that's why it was seemingly stalled (but not forgotten). I did them now too. Let's hope for the best... Ok, cheers. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: And now for the GNOME transition
+ Mirco Bauer (Thu, 21 May 2009 17:33:28 +0200): * gnome-do/armel: I've set up a dep-wait on the new gnome-desktop-sharp2, which I'll ask ftpmasters to re-inject (so, Mirco, no need to re-upload) Re-inject? You mean the gnome-desktop-sharp2 -4 upload that was rejected? That one doesn't contain the fix that gnome-do/armel needs, only my local -4 has that. Oh, I see. In that case, please upload your version now, the block is no longer in place. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gnome-volume-manger 2.24.1-3~squeeze1 for t-p-u
+ Michael Biebl (Sat, 16 May 2009 00:26:09 +0200): Hi release team, hi dato! as discussed on IRC, here is a short email regarding gnome-volume-manager: Unfortunately the current version of g-v-m in testing is slightly broken, as it has automounting disabled (which is done in newer versions = 2.24 of nautilus). I failed to get this version blocked from entering testing together with the new nautilus, which is caught up in the big GNOME transition. I thus prepared a new version 2.24.1-3 for sid which now has a Conflicts nautilus ( 2.24) and a version for squeeze (in t-p-u) which reenables automounting and has Conflicts against nautilus (= 2.24), to ensure a proper upgrade path. Please accept 2.24.1-3~squeeze1 into testing. Unblocked, should go with the next britney run. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Plib 1.8.5
+ Bradley Smith (Tue, 12 May 2009 22:55:13 +0100): Hi, Now that all the reverse depending packages have been sorted out, the transition can proceed, so I've just uploaded plib 1.8.5 to unstable. Release team, please can you binNMU all reverse depends of plib1.8.4c2? Thanks. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please allow emboss, embassy-domainatrix, embassy-domalign in Testing.
+ Charles Plessy (Thu, 14 May 2009 22:53:26 +0900): Hello, release team. The emboss package version 6 provides the libajax6 and libnucleus6 libraries, that are needed by the latest embassy* packages. All of them are in Unstable. Can you hint them in Testing? I've added a hint, will ensure that it works. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#528527: Package candidate for removal for GNOME transition
+ Arnaud Fontaine (Wed, 13 May 2009 15:48:38 +0200): I am quite busy at the moment with my exams but I think I can upload version 1.0.1 of gwget before the end of the week-end (I hope that would be ok this way?). This new upstream version ships support for epiphany 2.26, thus fixing this RC bug. That's excellent, Arnaud. Thank you for your effort, and good luck with your exams! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package candidate for removal for GNOME transition
Hello, gwget2, evolution-rss, evolution-jescs and icewm are all RC buggy and are being considered for removal in order to get GNOME 2.24/26 migrate to testing. I note that the RC bugs of gwget2 and evolution-jescs have only been filed minutes ago, so if the maintainers express they intend to upload very soon, effort will be put in getting it built quickly and in time in order for it not to be removed. However, the RC bugs have existed unfiled for more than a week, so we'll also take that into account if everything else gets ready. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: wacom-tools binNMU
+ Julien Cristau (Wed, 13 May 2009 15:11:11 +0200): Hi, wacom-tools was built against an old xorg-server on a few archs. It needs binNMUs on alpha hppa ia64 and sparc to get xserver-xorg-input-wacom installable again. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xf86-input-tslib binNMU
+ Julien Cristau (Wed, 13 May 2009 15:59:57 +0200): Hi, xf86-input-tslib was built against an old xorg-server on a few archs. It needs binNMUs on alpha hppa ia64 and sparc to get xserver-xorg-input-tslib installable again. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
libkexiv2, kdegraphics, and libkexiv2-7-dev
Hello, KDE people.
I notice kdegraphics 4.2.2 provides a libkexiv2-7 binary, which is is a
higher SONAME than the one provided by the libkexiv2 source package
both in unstable and experimental. Does this mean the libkexiv2 source
package, together with its libkexiv2-{3,5} and libkexiv2-dev binary
packages, should be removed from unstable and experimental?
Additionally, I notice kdegraphics 4.2.2 provides libkexiv2-7-dev
instead of libkexiv2-dev. Is there a reason for this? I realize it has
very few reverse dependencies, but unless there's a reason for it, I
think it'd be much better if the old libkexiv2-dev could be preserved.
(We can talk about when would be the best timing to change it back.)
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Pushing kde4 into testing
(Bcc Debian Edu: please search for libqt-perl in this message.)
+ Sune Vuorela (Mon, 11 May 2009 23:29:14 +):
Short version: We need to act now before we get caught with the new
boost things, kde4 looks better now that I expected - and better than I
expect it to be within the next month or so.
Everything of KDE4 that uses boost will fail with the new boost-defaults
as kde4 has checks for explicit versions, and 1.38 is not in the list of
versions it knows about.
Maybe the best thing is to push everything now, let some things be
broken for a while and then fix up afterwards.
A bit of things is unbuilt on hppa and mips*, as they as you all know
have been having issues lately and haven't fully recovered.
The alternative is that we wait and pushes newer kde packages to
unstable and hope everything is better in a month, with whatever
blockings that will give.
It is also unclear if other or same archs will be at a different
condition later on.
Longer version:
Adeodato identified some issues (quoted - and my comments added)
Moste of this will be a story about omelettes and eggs and how long to
wait for maintainers to consider how to fix their issues.
|Packages rendered uninstallable by KDE4 and that don't seem to have a
|fixed version in unstable:
All these issues have existed in unstable for a little more than a
month.
|bulmages-common (= 0.11.1-2): FAILED
|The following constraints cannot be satisfied:
| bulmages-common (= 0.11.1-2) depends on kpdf {NOT AVAILABLE}
Maintainer will fix one day in the future - Remove it from testing
now, it should easy flow back once it is fixed.
Bulmages is a spanish accounting program for small businesses.
Users who really needs it can get bulmages from stable.
This is #522584, which I thought had not been filed; my fault. The bug
has been open for more than a month at RC severity: I gave maintainer
one last notice, will remove if necessary.
|digikam-doc (= 0.9.5-1): FAILED
|The following constraints cannot be satisfied:
| digikam-doc (= 0.9.5-1) depends on khelpcenter {NOT AVAILABLE}
Let's remove this temporarily, it is documentation for the kde3 edition
of digikam/lenny anyways.
Maintainer says: remove it for now.
Okay.
|knights (= 0.6-8.2): FAILED
|The following constraints cannot be satisfied:
| knights (= 0.6-8.2) depends on kdebase-kio-plugins {NOT AVAILABLE}
Package unmaintained and up for adoption - and haven't had a maintainer
upload since 2007.
Unless we start NMU'ing / QA uploading it, it will stay broken.
Let us remove it from testing for now, hoping for a adopter.
Would you care to file an RC bug at least? But I'm okay with removing
this one.
|opensync-plugin-kdepim (= 0.22-3): FAILED
|The following constraints cannot be satisfied:
| opensync-plugin-kdepim (= 0.22-3) depends on libkcal2b (= 4:3.5.8) {NOT
AVAILABLE}
Maintainer aware and have had more than a month to fix it, including
finding patches over in fedora-land. Maintainer will fix within weeks or
months. I'm not suer it is worth waiting for. A fixed version will go
easy to testing once ready.
Fixed version uploaded by the maintainer. Should be built everywhere
soon.
|taskjuggler (= 2.4.1-1): FAILED
|The following constraints cannot be satisfied:
| taskjuggler (= 2.4.1-1) depends on libkcal2b (= 4:3.5.9) {NOT AVAILABLE}
Taskjuggler will be fixed one day. Maintainer is aware and have been it
since around lenny release. Maintainers are part of the debian kde team.
A fixed version (either using libical directly, or by removing the kcal
features) should easy go back to testing once ready
Care you file an RC bug? Please ask the maintainers to state their
plans, saying it'll be removed if they don't react soon. (I'm aware
you've probaby been in contact with the maintainers by IRC or whatever,
but bugs are more easily found by other teams, particularly the RT;
please remember that.)
|soundkonverter-amarok (= 0.3.8-2): FAILED
|The following constraints cannot be satisfied:
| soundkonverter-amarok (= 0.3.8-2) depends on libqt0-ruby1.8 {NOT AVAILABLE}
This is bound to go anyways - at latest when amarok goes amarok2, so let
us just kill it now.
Well, soundkonverter-amarok is not alone: there's also the soundkonverter
binary package, which seems it would do just fine. Can you file an RC bug
with the same comment as with taskjuggler?
|lurker (= 2.1-13): FAILED
|The following constraints cannot be satisfied:
| lurker (= 2.1-13) depends on libmimelib1c2a (= 4:3.5.9) {NOT AVAILABLE}
This is the only one I feel a bit sorry for. The debian maintainer have
been working hard and is still working towards providing a mimelib he
can use for lurker. I hope for it to come one day soon, but it will need
a NEW roundtrip.
I'll leave libmimelib1c2a/4:3.5.9-5 around in testing, so it won't be
necessary to remove it. If there's a reason that won't work, please let
me know.
|libqt-perl (= 3.008-4): FAILED
|The following
Re: libkexiv2, kdegraphics, and libkexiv2-7-dev
+ Sune Vuorela (Tue, 12 May 2009 12:08:20 +0200):
On Tuesday 12 May 2009 11:50:53 Adeodato Simó wrote:
Hello, KDE people.
I notice kdegraphics 4.2.2 provides a libkexiv2-7 binary, which is is a
higher SONAME than the one provided by the libkexiv2 source package
both in unstable and experimental. Does this mean the libkexiv2 source
package, together with its libkexiv2-{3,5} and libkexiv2-dev binary
packages, should be removed from unstable and experimental?
Additionally, I notice kdegraphics 4.2.2 provides libkexiv2-7-dev
instead of libkexiv2-dev. Is there a reason for this? I realize it has
very few reverse dependencies, but unless there's a reason for it, I
think it'd be much better if the old libkexiv2-dev could be preserved.
(We can talk about when would be the best timing to change it back.)
The {3,5} ones are kde3 based libraries where the 7 is the kde4 based edition.
At the time of packaging, it was unclear (and I'm still not fully sure) when
everything will be ready and moved to kde the kde4 versions.
Well, there's nothing left in unstable depending on the -3 one, but at
the same time it's FTBFSing against the new exiv2, so I was thinking
that iff its final destination is to get removed, I'd do the exiv2
transition without a recompiled libkexiv2 (which is possible since no
package depends on both libexiv and libkexiv). If its final destination
is not RM, then the FTBFS has to be fixed before exiv2/KDE4 can go
forward. Which one is it?
I'm not sure there is much gain in keeping libkexiv2-dev, except for pure
aestethical reasons. There should be no way to move from -{3,5} to -7
without
major source changes.
Right, but when eg libkexiv2-7 gets bumped to libkexiv2-8, what are you
going to do with the development package name? One would want to be able
to schedule Bin-NMUs, etc.
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
+ Yavor Doganov (Mon, 11 May 2009 12:59:44 +0300): 4.3.3-9 is available now on all powerpc buildds, AFAICS. Could you please give back gnustep-base/1.19.0-2 on powerpc? Done. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Sun, 10 May 2009 22:15:38 -0500): On Sun, May 10, 2009 at 12:21:10PM +0200, Adeodato Sim?? wrote: Could you prepare a mail to d-d-a, [ ... ] Sure. I'll work on it presently. Seen, thanks you! boost1.38 managed to get built on mips in the second try after I gave it back, but it failed again on hppa; any insight on that? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Sat, 09 May 2009 09:55:15 -0500): On Sat, May 09, 2009 at 12:09:17PM +0200, Adeodato Sim?? wrote: + Adeodato Sim?? (Mon, 04 May 2009 18:18:46 +0200): Okay, please make a second upload of boost-defaults already (it's okay to upload multiple versions to NEW), particularly because of the second issue you mention (the packages not being arch:any). I've started seeing some FTBFSes because of packages having moved to boost1.38, and reverse build-dependencies of these staying with the unversioned -dev packages. Is there an ETA for this upload? Thanks! Done. It should hit the NEW queue shortly. Great, thanks. It's been accepted already, you should have received mail about that. :-) Could you prepare a mail to d-d-a, explaining that we're back to unversioned development packages for Boost, and that everybody should be looking into build-depending on these? In particular, this needs mentioning: * everybody who's depending on versioned pacakges should look into moving to the unversioned packages; if they were using boost 1.38 already, this implies no change and it'll just work; if they were using an earlier version, it'll imply making sure the package builds with 1.38 when uploading * if they were still using unversioned packages, it would be great if they could verify whether the packages continue to build with 1.38 now, and make an upload if that's not the case. Bin-NMUs will be scheduled later on, and it'll be great if the maintainers have had an opportunity to check for failures and fix them already. And then, include a list of maintainers for both groups. If you can't take care of such post, please let me know and somebody from the Release Team will take care. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527976: eog on squeeze on powerpc has un-resolveable dependency on libgnome-desktop-2-7
+ Josselin Mouette (Sun, 10 May 2009 00:18:48 +0200): Le samedi 09 mai 2009 à 17:31 -0400, Rick Thomas a écrit : eog: Depends: libgnome-desktop-2-7 which is a virtual package. Apparently some packages are still depending on libgnome-desktop-2-7 in sid. I hope you already have a tool to list such things, so I won’t try to list them. Right, though libgnome-desktop-2-7 was not properly registered. Could you please schedule appropriate binNMUs? Scheduled some, and then did a batch of give-backs, and clearing and setting of dep-waits, http://bit.ly/8fmsi. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please block sed 4.2-1
+ Andreas Metzler (Sat, 09 May 2009 09:05:02 +0200): sed's behavior has changed in respect to using non-ASCII chars as a pattern delimiter. Previously sed -e 's§text§replacement§' worked no matter which locale was used. (The § being represented in ISO-8859-1 encoding, not as a two-byte UTF-8 character.) Now with version 4.2 sed's unicode support seems to grown, it now sees the §, realizes it is neither ASCII nor a valid UTF-8 character and throws an error message: sed: -e expression #1, char 2: delimiter character is not a single-byte character This breaks exim4 for anybody running an UTF-8 locale who has fine-tuned the locale configuration by setting not just LANG but LC_CTYPE (or LC_ALL). See #527445. Please stop sed from migration to testing until a to-be-uploaded version of exim4 (i.e. = 4.69-10.1) that has a workaround for the bug has reached lenny. Could sed 4.2 gain an appropriate Breaks: exim4-whatever ( foo)? But, since britney does not grok Breaks yet, I've added a block, okay. And, in any case, can exim4 stop using non-ASCII as a delimiter? Or is there really *no* ASCII delimiter left that would be used for the expression at and? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Adeodato Simó (Mon, 04 May 2009 18:18:46 +0200): Okay, please make a second upload of boost-defaults already (it's okay to upload multiple versions to NEW), particularly because of the second issue you mention (the packages not being arch:any). I've started seeing some FTBFSes because of packages having moved to boost1.38, and reverse build-dependencies of these staying with the unversioned -dev packages. Is there an ETA for this upload? Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please binNMU monotone for botan transition
+ Zack Weinberg (Wed, 06 May 2009 12:55:20 -0700): Hello, Zack (and keysafe maintainers). Hi, per the appended bug report, monotone needs to be recompiled to pick up the new libbotan soname. Please schedule: nmu monotone_0.43-3 . ALL . -m Recompile with botan-devel 1.8.2 dw monotone_0.43-3 . ia64 mips mipsel sparc . -m 'libbotan1.8-dev (= 1.8.2-1)' This closes bug #527314. I have verified that the package builds with the new library. monotone and keysafe certainly need to be rebuilt against the new version of botan, since the SONAME has changed. However, the libbotan1.8 binary package name should have been renamed in the process of bumping the SONAME (Bug#527461), and I won't be scheduling Bin-NMUs of either package until that has happened. The reason for not scheduling the Bin-NMUs is that they would be freely migrating to testing, which still has Botan 1.8.1, and then the bug would happen there in addition to unstable (not only botan 1.8.2 didn't rename the binary package, it also has a bogus shlibs file!). However, I realize having this situation in unstable is inconvenient, so you may make sourceful uploads of monotone and keyfile in order to get them rebuilt. The point is that, independently of you taking up on this offer or not, I'll block migration of these pacakges to testing until the issue is fixed in botan, just in case; so you may as well upload. (New source versions can easily be blocked from migration, Bin-NMUs can't be.) Cheers, -- Forwarded message -- Package: monotone Version: 0.43-3 Severity: grave Justification: renders package unusable libbotan1.8 was recently upgraded from 1.8.1 to 1.8.2. $ mtn mtn: error while loading shared libraries: libbotan-1.8.1.so: cannot open shared object file: No such file or directory $ ldd /usr/bin/mtn ... libbotan-1.8.1.so = not found ... $ ls -l /usr/lib/libbotan*.so -rw-r--r-- 1 root root 2905232 2009-05-04 03:58 /usr/lib/libbotan-1.8.2.so lrwxrwxrwx 1 root root 17 2009-05-06 13:07 /usr/lib/libbotan.so - libbotan-1.8.2.so Monotone needs to be rebuilt against the new Botan 1.8.2. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: give back drivel on mips and mipsel ?
+ Neil Williams (Tue, 05 May 2009 09:28:12 +0100): drivel failed on mips and mipsel due to problems installing libgnomeui-0 - can those builds be tried again please? Given back. (That's what is meant by giving back, yes?) Yes. P.S.: Please use debian-wb-t...@lists.debian.org next time, thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian CUPS transition in progress
Hello, Martin-Éric. You wrote on Planet (http://bit.ly/TUFYI): Since Lenny was the first Debian release to feature CUPS under its new package naming strategy, I started going through 'rdepends' results to see which packages in Squeeze still present dependencies for *cupsys* packages. Much to my amazement, there's quite many. If you are the maintainer of a package that still has those dependencies, please fix them ASAP. Alternately, if you're aware of any favorite package that does, please do not hesitate at filing a patch to help the maintainer update their debian/control. Comes June 2009, transitional CUPS packages will be removed from our debian/control. As a maintainer interested in dropping transitional packages from a package of yours, the onus is on you to communicate and coordinate with your reverse dependencies to get such obsolete dependencies to disappear. Planet Debian *does* *not* constitute an appropriate forum for such communication. Given the small set of packages involved, at least at this stage, you should be filing bugs against the following packages directly, asking that they stop depending on libcupsys2-dev, and start depending on libcups2-dev instead: libfox1.4-dev libfox-1.6-dev libqt3-mt-dev And this package should depend on cups-bsd instead of cupsys-bsd: gpr Additionally, you should ensure that the following packages get rebuilt before dropping the transitional libcupsys2 package, eg. by asking the release team to schedule Bin-NMUs for you: rezound python-cups (libfox1.4)| (libfox-1.6-0) | Would be solved by the sourceful upload mentioned above I hope you will be filing the required bug reports now, and will ensure they are fixed before dropping the transitional packages (with NMUs, if necessary). Do not hesitate to reply if you have any doubts about the process, or ask any of your co-maintainers, particularly Martin Pitt. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming QOF transition
+ Neil Williams (Sun, 03 May 2009 10:00:00 +0100): Hello, Neil. I propose to: 1. Upload libqof1 0.7.5-2 (or possibly an upstream 0.7.6-1 branch) that creates a new package, qof-data to comply with Policy 8.2 and a set of new virtual packages (qof-backend-xml and qof-backend-sqlite - possibly qof-backend-gda) that are Provide:'d by the new backend plugins. (Applications depending on libqof1 or libqof2 are free to choose the storage mechanism used by QOF by specifying at least one backend and allowing the user to specify an access method like file:// or sqlite://). 2. Upload new upstream versions of gpe-expenses and pilot-qof that depend on the virtual backend package(s) instead of the actual backend names to make pilot-qof and gpe-expenses binNMU safe for the imminent QOF transition. Fix the issue with libqofexpensesobjects0 in the same gpe-expenses upload by adding a new package, libqofexpensesobjects-data. 3. Wait for Goedson to get a new release of gnotime into Debian with the upstream patches for libqof2, if that hasn't happened before packages from 1 and 2 clear NEW. 4. Upload libqof2 (QOF 0.8.0) and ask for binNMU's of gnotime, pilot-qof and gpe-expenses. Stages 1 and 2 will involve trips through NEW (the new upstream release of pilot-qof also introduces a few new packages). Please advise whether any of these stages need to wait for current or upcoming transitions and whether the plan itself is acceptable. The plan sounds sensible. gnotime depends on the new libtool, but it's not that worrysome, since I plan for libtool to migrate soon. Additionally, have you considered going directly for libqof2 (0.8.0) in step #1? You'd save one roundtrip to NEW altogether, and I don't think it'd be much of a bad decision, plus by delaying #2 and #3 until #1 clears from NEW, you can completely do without Bin-NMUs (not that this matters much, either). Your choice, anyway. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU ocsigen/1.1.0-2
+ Stéphane Glondu (Wed, 06 May 2009 13:08:08 +0200): Hello, nmu ocsigen_1.1.0-2 . ALL . -m 'Recompile with ocaml-sqlite3 1.4.0' This would close #527224. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: krb5 transation: krb5 1.7
+ Sam Hartman (Mon, 04 May 2009 18:30:31 -0400): That was the goal, although I'm suspecting that reality will be a bit more difficult. Some symbols have had their versions increased in the 1.7 packages because new flags were added to the functionality. So, it's possible that if some of the BIN NMUs take until after krb5 1.7 hits unstable, their shlibdeps may end up higher than is strictly necessary. Aah, there's always a fine print. :-) In that case, would you mind holding off your krb5 upload by, say, a week, as to give a bit of time for most Bin-NMUs to build against 1.6? I'm happy for this period to be fixed (one week), instead of making it dependant of the percentage of Bin-NMUs successfully built. But given the current state of transitions in unstable, it would help a lot having krb5 be as small as possible. So, I think that we can make this a really small transition, but perhaps not empty. Unfortunately, it looks like some of the BIN NMUs are failing and some of the failures use symbols with newer versions. For example it seems like cvsnt FTBFS on all arches. cvsnt's failure seems to be caused by #506801, which should be trivial to fix. More puzzling is the openssh build failure on mipsel. In that case, deny_severity from tcp-wrappers is causing a problem. It's a weak symbol exported by libwrap, that is often redefined by the application. sshd does in fact redefine the symbol, but the mipsel linker complains about a non-dynamic reference to a dynamic symbol. I *think* the mipsel linker is wrong here, but if so, that may prove ugly to fix. Ugh, I'll try to find a mipsen person to ask to. However those are the only problems I'm seeing in the builds that have completed so far, so I think this is going to be relatively painless. In particular, the cups builds seem to be going well; so do the SASL builds. Those are the ones with the most rdeps. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: krb5 transation: krb5 1.7
+ Sam Hartman (Tue, 05 May 2009 08:31:40 -0400): Adeodato In that case, would you mind holding off your krb5 Adeodato upload by, say, a week, as to give a bit of time for Adeodato most Bin-NMUs to build against 1.6? I'm happy for this I'm sorry.I ran the dput for the krb5 upload this morning before checking mail and it had already hit accepted by the time I got to my Debian mail queue. Okay, no worries. I don't think I can pull it from accepted. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: give back drivel on mips and mipsel ?
+ Cyril Brulebois (Tue, 05 May 2009 13:40:30 +0200):
| Setting up libgnomevfs2-common (1:2.24.1-1) ...
| Traceback (most recent call last):
| File /usr/sbin/gconf-schemas, line 82, in module
| pids=os.popen('pidof gconfd-2').readlines()[0].split()
| OSError: [Errno -89] Unknown error 4294967207
What makes you think trying again will help?
That's caused by a kernel bug on the mipsen buildds. It's not fixed, but
a workaround has been introduced in glibc 2.9-9 or so that enables popen()
et al. to work again. :-)
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: library transition proposal exiv2/ libexiv2-5
+ Mark Purcell (Sun, 03 May 2009 18:17:17 +1000): Dato, Thanks for the green light. Have now uploaded libexiv2-5 to unstable and (almost) installed on all archs. BinNMU's required for rdepends against the obsolete libexiv2-4: Bin-NMUs scheduled. We have tools to calculate the list of packages to rebuild, so unless there's something particular to mention about any of them (don't Bin-NMU X because foo, or X and Y need a rebuild, but X depends on Y), you need not mention anything else than please schedule the Bin-NMUs. :-) Also there's no need to CC the affected packages, unless there's something the maintainers need to be aware of. + Bernd Zeimetz (Sun, 03 May 2009 12:01:53 +0200): merkaartor was uploaded yesterday late in the evening, so a binNMU is probably not necessary, at least not on all archs. Unfortunately I didn't see this mail before uploading it, otherwise I would have waited a bit to make sure it builds against the new exiv2 everywhere. bzed dato: btw I think it would make sense to set a depwait on libexiv2-5 for those arches where merkaartor is not yet built to make sure it builds in the right order Only powerpc had not built libexiv2-5 by the time you uploaded merkaartor. Fortunately, libexiv2-4 had been decrufted already, so the build on powerpc failed; I've given it back now. (Additionally, it's not very worrysome if an architecture builds your package against the old library; scheduling an addditional Bin-NMU is quite cheap.) Thanks both, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Sun, 03 May 2009 00:44:42 -0500): I see you've uploaded boost-defaults already. In your previous mail, you asked whether it was okay to upload already, or if we needed to wait until the latest boost1.38 would migrate to testing. Um, yeah ... I was a bit impatient and did the upload after asking but before receiving your answer. Sorry about that. Okay, no problem. I gave you a detailed explanation of the circumstances in which it was okay to upload already, but it seems to me (at least, by looking at the SVN repository; I don't have access to the actual files as uploaded to ftp-master) that the second of these conditions has not been met, nor I received any indication about the first one. That's unfortunate, but hopefully mipsel will manage to build boost1.38/1.38.0-5 before boost-defaults clears out of NEW, and we'll be safe. Yeah, that would be good. Or I can make another upload of boost-defaults, with the build-dependency versioned as you suggested (the second iff). I plan to make a second upload of boost-defaults anyway, since the first uses arch:all and no build-depends. Okay, please make a second upload of boost-defaults already (it's okay to upload multiple versions to NEW), particularly because of the second issue you mention (the packages not being arch:any). Thanks! P.S.: Any insight on the boost1.38 failure on mips? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint enet, blockattack
+ Ansgar Burchardt (Sat, 02 May 2009 23:34:14 +0200): Hi, please add hints for enet/1.2-3 and blockattack/1.3.1-3 so they can migrate to testing. Hint added, and thanks for mailing -- I'm sorry nobody was around on IRC to answer you. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for libgladeui
+ Josselin Mouette (Mon, 04 May 2009 18:15:01 +0200): Hi, glade-3 3.6 is now in unstable. Could you please schedule binNMUs for the reverse dependencies of libgladeui? Bin-NMUs of anjuta, libgnomedb3 and libxfcegui4 scheduled, with appropriate dep-waits on libgladeui-1-9. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
+ Hubert Chathi (Sat, 02 May 2009 20:32:22 -0400): On Mon, 30 Mar 2009 20:28:34 +0200 Adeodato Simó d...@net.com.org.es wrote: The poppler transition is almost ready, and the popplerkit.framework upload you made to fix the linkage issue has been built everywhere. This means you can go forward with starting the GNUstep transition in unstable, but we won’t schedule Bin-NMUs for popplerkit.framework until poppler has been done, if that’s okay with you. Please come by when you’ve uploaded to unstable and Bin-NMUs are needed. Sorry, I'm about a month late. I've been rather busy... The new GNUstep libraries are in unstable. Here are the packages that build-depend on the GNUstep libraries: Need bin-NMU: (depends on ... indicates build-dependencies within this set) All scheduled, with appropriate dep-waits for the 5 packages that included dependency information. I hope I didn't botch it up. By the way, are gnustep-netclasses and pantomime1.2 in the same situation popplerkit.framework used to be, that is, using GNUstep libraries but not linking against them? Has new upstream version -- will upload shortly, no bin-NMU needed: - gnustep-dl2 - gorm.app - gworkspace - price.app None of these scheduled. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
+ Adeodato Simó (Mon, 04 May 2009 19:25:42 +0200): Has new upstream version -- will upload shortly, no bin-NMU needed: - gnustep-dl2 - gorm.app - gworkspace - price.app None of these scheduled. Note, however, that not all the new GNUstep libraries are available on hppa and powerpc. You may want to hold uploading these until gnustep-back has been successfully built there, or bump build-depends version constraints, or come by for a dep-wait once you've uploaded. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
+ Yavor Doganov (Mon, 04 May 2009 22:12:10 +0300): Adeodato Simó wrote: By the way, are gnustep-netclasses and pantomime1.2 in the same situation popplerkit.framework used to be, that is, using GNUstep libraries but not linking against them? Yes, they are, plus renaissance. Will be fixed for the next transition. Okay. (Hubert, the gnustep-base powerpc issue is due to #523869, I believe.) I gave it back a bit earlier, so as it seems it should succeed now. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: krb5 transation: krb5 1.7
+ Sam Hartman (Mon, 04 May 2009 13:08:34 -0400): Adeodato I say we go ahead without introducing an oldlibs Adeodato package, and we Bin-NMU the affected packages. Then, if Adeodato the transition gets very hairy, we'll migrate the new Adeodato libraries to testing but retaining libkrb53 there with Adeodato britney, as we've done for some other transitions Adeodato already. The risk, as always, are applications that Adeodato could end up loading both new and old libraries at the Adeodato same time, but the same risk exists with a package in Adeodato oldlibs AFAICT. Briefly, agreed, although I don't think the risk of applications loading the same libs exists. In detail: The libkrb53 package has no overlapping libraries with libraries in any package in unstable. We're removing two libraries entirely; the sonames of interfaces that were public in Kerberos 1.6 have not changed in 1.7. Binary compatibility is retained except for applications that link against libkrb4.so.2 or libdes425.so.3. So, I don't think we have a risk of applications loading libraries from libkrb53 that are also elsewhere. Ah, okay, thanks for the explanation. I'm very much afraid I didn't have the time to follow the thread on -devel about this migration, which I suppose would have given me a more solid understanding of the issues at hand. (libkadm5srv became libkadm6srv and libkadm5clnt became libkadm6clnt. These are private interfaces in 1.6 and public interfaces in 1.7. The only thing in unstable that links to them are the krb5 source package and libauthen-krb5-admin-perl, which I mentioned in my first mail.) Adeodato Can you let us know when you have uploaded to unstable? I'll write back and let you know when I've uploaded. However, that should not stop you doing bin NMUs. As of 1.6.dfsg.4~beta1-9 (-13 is in unstable and testing) packages built against libkrb5-dev will not depend on libkrb53. That is, ywith the exception of libauthen-krb5-admin-perl, anything you bin NMU today will not require a rebuild after 1.7 hits unstable. Ah, but that's wonderful, since it means there's no really a transition in the britney sense, where all packages have to migrate at the same time. Rather on the contrary, rebuilt packages (except libauthen-krb5-admin-perl) can migrate to testing and their own pace, and krb5 itself will follow together with libauthen-krb5-admin-perl, after all of the rest has migrated. I've scheduled all required Bin-NMUs. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: proposed update of texlive-base for lenny
+ Norbert Preining (Mon, 04 May 2009 22:36:55 +0200): - current texlive-base in unstable is version 2007.dfsg.2-4 - proposed update would be 2007.dsfg.2-1~lenny1 So I guess the .orig.tar.gz should not be included in the upload as it is already present in the archive, right? That's correct, do not include the .orig.tar.gz in this case. Sorry for the probably stupid question and all the best Well, uploading 70MB in vain would have been way more stupid. ;-) Ciao, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
+ Yavor Doganov (Mon, 04 May 2009 23:34:53 +0300): Adeodato Simó wrote: + Yavor Doganov (Mon, 04 May 2009 22:12:10 +0300): (Hubert, the gnustep-base powerpc issue is due to #523869, I believe.) I gave it back a bit earlier, so as it seems it should succeed now. Unfortunately it failed again because the fix for the above bug is in gcc-4.3/4.3.3-8 which is not yet built and installed on powerpc. Ah, I see. I'll look into giving it back once -8 is available in powerpc and the chroots have been upgraded. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming QOF transition - re-sending
I'll reply to the -release bits of this mail in due curse, but for now: I tried sending this to debian-release Sun, 3 May 2009 10:00:00 +0100 Message-Id: 2009050310.0ca5c3e9.codeh...@debian.org but it still hasn't appeared. Re-sending to the list and to Adeodato, just in case. BCC'ing myself to see what might be going on. I'm not sure what kind of access you have to mail.technocool.net. It seems it's your smarthost, and it's where your message spent more than 5 hours before it was successfully delivered to lists.debian.org. If you have access to the logs of that server, you should be able to assess what went wrong. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Thu, 30 Apr 2009 09:28:12 -0500): On Tue, Apr 28, 2009 at 11:10:41PM +0200, Adeodato Simó wrote: Let's make the unversioned development packages arch:any, and build-depend on libboost1.38-dev. That way, even if the intent is to only bump the major version when eg. boost1.39 is built everywhere, it should be less problematic (ie. no uninstallable -dev) if it gets done before, either on purpose or accidentally. I have done as you asked. However, I don't understand (a) what is the issue you are concerned about, and (b) how this change prevents it. If you don't mind, could you expand on this? I think this may benefit others, as 2 of the 3 -defaults packages I looked at as examples use arch:all. Sure, I'll try to explain better. The point is making it difficult to produce development packages that end up being uninstallable in some architecture. So, for example, if one uploads arch:all packages switching to boost1.39, but boost1.39 is not built in mips and mipsel, no package build-depending on boost can be built on those arches. If, on the other hand, that new boost-defaults package build-depends on boost1.39, it ensures that the new development packages won't appear on mips and mipsel until boost1.39 itself is built there. Admittedly, the plan is only to switch boost-defaults when boost1.39/etc is built in all arches and migrated to testing. But there can be oversights when uploaded, so this adds a small protection (particularly once you implement debian/control.in or equivalent). I see you've uploaded boost-defaults already. In your previous mail, you asked whether it was okay to upload already, or if we needed to wait until the latest boost1.38 would migrate to testing. I gave you a detailed explanation of the circumstances in which it was okay to upload already, but it seems to me (at least, by looking at the SVN repository; I don't have access to the actual files as uploaded to ftp-master) that the second of these conditions has not been met, nor I received any indication about the first one. That's unfortunate, but hopefully mipsel will manage to build boost1.38/1.38.0-5 before boost-defaults clears out of NEW, and we'll be safe. Did the above explanations help in any way regarding your inquiry? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: krb5 transation: krb5 1.7
+ Sam Hartman (Tue, 21 Apr 2009 15:54:06 -0400): Hello, Sam, sorry for the delay on getting back to you, and thanks for coordinating with us. Around a month ago, I had discussions of a transition to the krb5 package on debian-devel. The steps so far have been something that hasn't broken anything and I believe has been fairly low impact. However I'd like the release team's review for the next part and advice on one of two directions. Basically, the libkrb53 package is being split and will eventually go away. Upstream is dropping support for the 1980's era Kerberos 4, so I need to drop the krb4 libraries. I've done the library split keeping libkrb53 . However I'd like to move 1.7 into unstable, which means that libkrb53 needs to either go away or be produced by an oldlibs package based off the 1.6 sources. Anything that gets built now will not end up depending on libkrb53, but there are a large number of packages that do depend on libkrb53 in unstable. so, the question is whether we should BIN NMU those packages, or whether I should produce a krb5-1.6 source package to go into oldlibs for a while to keep libkrb53 around. I'm happy to do the oldlibs package especially if it lets me get krb5 1.7 into unstable significantly faster. I'm not happy to maintain the oldlibs package in a stable release; if we create such a package we should expect it to go away say sometime later this year. Unrelatedly, when Kerberos 1.7 goes into unstable, libauthen-krb5-admin-perl will break and require a source patch; I'm happy to coordinate with the maintainers of that package and supply a patch. I say we go ahead without introducing an oldlibs package, and we Bin-NMU the affected packages. Then, if the transition gets very hairy, we'll migrate the new libraries to testing but retaining libkrb53 there with britney, as we've done for some other transitions already. The risk, as always, are applications that could end up loading both new and old libraries at the same time, but the same risk exists with a package in oldlibs AFAICT. Can you let us know when you have uploaded to unstable? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Testing removals for GTK 1.2 removal
+ Moritz Muehlenhoff (Sun, 26 Apr 2009 10:17:05 +0200): On Fri, Apr 24, 2009 at 10:52:13AM +0200, Adeodato Simó wrote: + Moritz Muehlenhoff (Wed, 22 Apr 2009 19:05:38 +0200): Or maybe I'm misunderstanding you and uninstallable packages are removed automatically from testing? On the contrary, it’s gtk1.2 and imlib that britney won’t remove from testing as long as they have reverse dependencies in testing (ie., britney won’t let a removal to leave uninstallables around). So the options indeed are doing a mass-removal by hand, and then packages that get fixed get back in once they depend on gtk2; or to delay the mass-removal, and only perform it after a reasonable period in which gtk1.2 reverse dependencies have had some time to get ported. Well, that reasonable time frame were the last, umm, five years :-) Removing the remaining packages from testing rather speeds things up, e.g. gringotts has been fixed shortly after it was removed from testing a few days ago. If Luk doesn't object, we'll do a mass-removal during May. CC'ing Luk. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: library transition proposal exiv2/ libexiv2-5
+ Mark Purcell (Fri, 24 Apr 2009 09:30:26 +1000): Dato, Hello, Mark. Any news? I'm awfully sorry for the embarrassing delay: I never seemed to find the time to sit down to look at this. Theoretically speaking, the exiv2 transition will have to go together with KDE4 because of gwenview. However, I'm open to untying them if KDE4 would block exiv2 from migrating. Thanks a lot for your patience and cooperation, and let us know when you have uploaded to unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
+ Mike Hommey (Tue, 28 Apr 2009 22:42:52 +0200): webkit D-W on libsoup2.4-dev libsoup2.4 D-W on libproxy-dev libproxy FTBFS because libwebkit-dev isn't installable (at least hppa, mips) I just thought I'd drop you a note about that. I'm told Mike was looking into this, but it indeed looks like circular Build-Dependencies... The possible long-term solution is to split libJavaScriptCore out of libwebkit, but I don't see that happening in the very near future, a future where we can get these builds to happen quickly. The best I can see for a short-term solution would be to disable the webkit plugin in libproxy, and possibly enable the mozjs one to avoid losing the .pac parsing functionality, but then I'm not sure how webkit will like it. Mike, Emilio, can you coordinate so that any sensible solution is implemented reasonably soon? A good number of packages build-depend on libsoup, and none of them will be buildable. Plus the webkit transition can't go forward without it, of course. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
+ Stefano Zacchiroli (Tue, 28 Apr 2009 22:16:26 +0200):
On Tue, Apr 28, 2009 at 09:45:41PM +0200, Adeodato Simó wrote:
Anyway, the exact list of Bin-NMUs is rather uninteresting. More
interesting can be, I think, the current list of known transitions
against which the Release Team works, which you were pointed at on
IRC later:
https://buildd.debian.org/transitions/summary.html
Is that page linked from anywhere? I've looked into the most obvious
(to me) places (e.g., {buildd,release}.d.o), but I failed to find it.
I'm afraid I'm not very keen on touching the HTML on either of those
sites until we have something sane on them (say, an ikiwiki instance).
As a bonus, Google found this for me:
http://wiki.debian.org/OngoingTransitions which looks a bit
outdated.
I deleted all content on that page, and added a page to the new URL. At
least now it's linked from *somewhere* (apart from the /topic in #d-r). ;-)
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Testing-watch bounces
+ Henning Makholm (Mon, 27 Apr 2009 23:32:54 +0200): However, I notice that bounces for undeliverable notification emails from the system still go to my private mail server. This is not a big deal -- I'm just procmailing them into oblivion -- but I'd like it to stop nontheless, for the sake of privacy and general cleanliness. The culprit seems to this line $command = '/usr/lib/sendmail -t -f makholm+logsahenning.makholm.net' ; near the top of trile/mailout in the release.git tree. Could someone with appropriate access rigthts please remove the -f option and its argument? Thanks. I've amended that line to set the envelope-sender to nore...@release.d.o [1]. Sorry that we didn't spot and change this earlier, and thanks for having created trille in the first place. :-) Ciao, [1]: http://git.debian.org/?p=debian-release/release-tools.git;a=commitdiff;h=045772 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
(Bcc: -devel) + Cyril Brulebois (Tue, 28 Apr 2009 21:09:53 +0200): Heya folks, after Ari asked on #dd, I was wondering where one can track the currently planned binNMUs, so that I could answer his “when will webkit stuff be rebuilt?” question. Is vorlon's page on ftp-master still the reference? (Old link I have in my bookmarks, but I bet it'd rather be somewhere on r.d.o). No, there is no list of scheduled Bin-NMUs. Hopefully there'll be one with the new buildd pages in the medium-term future, but at the moment there is none. Anyway, the exact list of Bin-NMUs is rather uninteresting. More interesting can be, I think, the current list of known transitions against which the Release Team works, which you were pointed at on IRC later: https://buildd.debian.org/transitions/summary.html If something's not on that list, we don't know about it. At the moment we don't know about webkit: nobody has informed us about it. (I've added it now.) For each transition, it is said if has Bin-NMUs pending to be scheduled or not. This has false positives (i.e., sometimes the Needs another Bin-NMU round: yes is not true), but well, it works okay most of the time. The thing is, if it's on that page, they'll get scheduled. Now, I've looked at the current Dep-Wait's (I think you usually trigger binNMUs when the build is available on all archs, or you use Dep-Wait's), but I've noticed the following chain: (seen on hppa, mips, sparc, possibly others) webkit D-W on libsoup2.4-dev libsoup2.4 D-W on libproxy-dev libproxy FTBFS because libwebkit-dev isn't installable (at least hppa, mips) I just thought I'd drop you a note about that. I'm told Mike was looking into this, but it indeed looks like circular Build-Dependencies... Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-boost-devel] Upload of Boost 1.38
+ Steve M. Robbins (Fri, 24 Apr 2009 00:29:04 -0500): Hello release team, Hello, On Fri, Mar 20, 2009 at 09:13:34PM +0100, Adeodato Sim?? wrote: Once boost1.38 is built in all architectures and migrated to testing, we can proceed with the boost-defaults plans, see below about this. OK, boost1.38 is built and in testing, so I'm preparing boost-defaults now. I've got a preliminary package of it at http://svn.debian.org/wsvn/pkg-boost/boost-defaults/trunk/#_boost-defaults_trunk_ For the love of Pete I couldn't get a show me the file contents option with that link. I resorted to ViewSVN. Basically all it has is a control file with unversioned -dev packages that depend on the corresponding 1.38-dev package. I'd appreciate it if you would give it a glance and see whether I've missed something. Let's make the unversioned development packages arch:any, and build-depend on libboost1.38-dev. That way, even if the intent is to only bump the major version when eg. boost1.39 is built everywhere, it should be less problematic (ie. no uninstallable -dev) if it gets done before, either on purpose or accidentally. I realize that most other -defaults generate control from a template and substitute in the version string; I plan to do the same when 1.39 comes out. Okay, please do that. That way, the hypothetical accidental upload mentioned above would get to build-depend on libboost1.39-dev and not on libboost1.38-dev because the uploader forgot to update it. Are there other improvements I could make? Not that I can think of, apart from the arch:any bit, and the build-dependency. I suggest that we get started by introducing boost1.38 in unstable, and once it has migrated to testing, start the migration work. This means: * an initial upload of boost-defaults providing versionless -dev package names pointing at the 1.38 packages After creating boost-defaults, I realized that the existing libboost1.38-dev package has an unversioned conflict with libboost-dev (currently from boost 1.34.1) so I could not install the new libboost-dev from boost-defaults. I uploaded a new version of boost1.38 where the conflict is now versioned and local testing suggests this solves my problem. Unfortunately, however, the new upload fails to compile on a few architectures (ICE on s390, MPI problem on MIPS). Thus, while boost 1.38.0-3 is in testing, the new -4 upload will not migrate until such problems are fixed. Shall I go ahead and upload boost-defaults anyway or would you prefer to wait until the latest boost 1.38 hits testing? Iff packages built against libboost1.38-dev 1.38.0-4 generate dependencies that are satisfiable in testing (ie., that don't require -4), you can upload iff you make the build-dependency of boost-defaults on libboost1.38-dev versioned = 1.38.0-4. Otherwise we'd have uninstallable -dev packages, which we do not want. Please note there are *two* iff. :-) I'm unsure what is causing the failure on mips. Do you have any ideas? But the mipsen buildds are having toolchain troubles, so it may be worth delaying investigations until those are fixed, which should happen during this week. P.S. After boost-defaults is uploaded, the archive will have two source packages (boost, boost-defaults) that both produce the binary package libboost-dev. Won't that cause a problem? Does something need to be adjusted to allow this? Frank already replied and his answer is canonical since he's ftpteam. Quoting from http://lists.debian.org/debian-release/2009/03/msg00345.html: | This seems like a reasonable proposal. Do you forsee that we can | upload boost-defaults to sid with boost 1.34.1 (also providing | versionless -dev packages) still in the archive? When does 1.34.1 get | removed? | | Yes, it’s technically feasible, and boost 1.34.1 would get removed once | it would have no reverse dependencies left. (If a boost 1.34 upload was | needed, though, it would have not to include the -dev packages.) So, it'll all work fine if a further upload of boost 1.34 is not needed; you'll have to disable creation of -dev packages in 1.34 if it is. Summary of this mail: * please make the suggested changes on boost-defaults and come by for a final review. Thanks for your work, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gcc-4.4 gcj-4.4/java-common uploads to unstable
Marc, Luk, what's the status of the mipsen experimental autobuilders?
How could we get gcc-4.4 to be tried on them before it gets uploaded to
unstable?
It'd be very inconvenient to have gcc-4.4 unable to migrate quickly to
testing due to an hypothetical nasty FTBFS on mipsen, because of the
shlib bumps (and package takeover) Matthias comments.
Cheers,
+ Matthias Klose (Mon, 27 Apr 2009 00:18:40 +0200):
Planning a gcc-4.4 upload for unstable for next week. It's not a
transition (not changing any GCC defaults), but is likely to delay
transitions of other packages due to new symbols in the various GCC
runtime libraries. For now I'm not aware of any regressions in the
runtime libraries, however builds for mips* are still outstanding. I
would appreciate access to a fast mips* machine, or a build log for
the current gcc-4.4 package in experimental.
gcj-4.4 welcomes back hppa as a java architecture. gcj-4.3 is
available on hurd-i386. Besides kfreebsd, java is now available on all
architectures. For unstable, I plan to change the java-common defaults
to point to opendjk for all hotspot archs, and to gcj-{jre*,jdk} when
these packages are in testing. I'd like to have some feedback about
the java default for the non-hotspot openjdk archs first before moving
those to openjdk; both debian-java and the openjdk co-maintainer seem
to be pretty dead/mia.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint shorewall6 and shorewall-{common,perl,shell}
+ Roberto C. Sánchez (Mon, 27 Apr 2009 14:54:21 -0400):
It appears that shorewall6 and shorewall-{common,perl,shell} are all
stuck and cannot migrate. Please manually hint into testing.
I've added a hint, will keep an eye on it.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: give back for gnome-mount and eiciel
+ Michael Biebl (Fri, 24 Apr 2009 17:59:48 +0200): Hi, Hello, Michael. please give back the following packages. Their build dependencies should be available by now: gb eiciel_0.9.6.1-3 . mipsel gb gnome-mount_0.8-2 . mipsel No, the build-dependencies of these (libnautilus-extension-dev 2.20) are not available on mipsel, because nautilus is not built there yet. The problem is that nautilus have a bogus dep-wait on eel2, which is no longer correct. So, what I’ve done is give back nautilus on mipsen, which will allow eiciel and gnome-mount to be built once nautilus/mipsen is built an uploaded. Those packages are part of the nautilus transition, so it's good to have them ready when nautilus is ready. Please mail debian-wb-t...@lists.debian.org for wanna-build requests next time, thanks in advance! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Give-back for NM related packages
+ Michael Biebl (Wed, 22 Apr 2009 18:52:01 +0200): Hi, due to latest transitions in gtk, pango and gconf, a few of the NM related packages failed to build due to unmet b-deps. This should be fixed by now. Please give back: gb network-manager-openvpn_0.7.1-1 . mips gb network-manager-pptp_0.7.1-1 . mips powerpc All other network-manager-* packages have been built successfully though not all of them are uploaded yet. Hopefully they will be soon, to finally finish the NM testing transition. Apparently you built these on porter machines or similar already. Unfortunately, and if I’m not mistaken, network-manager is tied to GNOME 2.26 via gnome-main-menu, and I don’t know how it’d work out having gnome-main-menu in testing depend against libnm-util0, trying to communicate with a network-manager that it’s 0.7 already. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#525511: dvdauthor: depends on obsolete package libmagick10
+ Ben Hutchings (Sat, 25 Apr 2009 14:17:33 +0100): On Fri, 2009-04-24 at 23:50 -0500, Drake Wilson wrote: Package: dvdauthor Version: 0.6.14-3+b2 Severity: important Just what it says on the tin: dvdauthor in sid depends on libmagick10, but that package is no longer available in sid. This should be fixable with a binNMU: nmu dvdauthor_0.6.14-3 . ALL . -m 'Rebuild against libmagickcore2 (Closes: #525511)' Bah. I actually scheduled Bin-NMUs for the imagemagick transition on April 11th, but I did a mistake and most of them need to be scheduled again. Done that now, including dvdauthor. (The mistake was that I scheduled the Bin-NMUs before the obsolete packages were decrufted, which was fatal in this case because Provides were involved. I actually knew about this, but it seems I didn’t remember when scheduling them.) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Testing removals for GTK 1.2 removal
+ Moritz Muehlenhoff (Wed, 22 Apr 2009 19:05:38 +0200): Or maybe I'm misunderstanding you and uninstallable packages are removed automatically from testing? On the contrary, it’s gtk1.2 and imlib that britney won’t remove from testing as long as they have reverse dependencies in testing (ie., britney won’t let a removal to leave uninstallables around). So the options indeed are doing a mass-removal by hand, and then packages that get fixed get back in once they depend on gtk2; or to delay the mass-removal, and only perform it after a reasonable period in which gtk1.2 reverse dependencies have had some time to get ported. We’ll think about it. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
udev 0.141-1 migration
Marco, you mentioned release action was needed for udev and hal to migrate together ASAP. However, you didn’t mention that libvolume-id’s SONAME had been bumped, in which case we would’ve detected earlier that redhat-cluster also needed a rebuild against this new SONAME. I’ve scheduled Bin-NMUs for redhat-cluster now, but unfortunately this will delay udev’s migration for at least two or three days. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev 0.141-1 migration
+ Marco d'Itri (Tue, 21 Apr 2009 11:20:00 +0200): On Apr 21, Adeodato Simó d...@net.com.org.es wrote: you mentioned release action was needed for udev and hal to migrate together ASAP. However, you didn???t mention that libvolume-id???s SONAME had been bumped, in which case we would???ve detected earlier that redhat-cluster also needed a rebuild against this new SONAME. I only knew about hal, the testing pages did not report redhat-cluster. The testing pages are useful to see how to proceed once all packages have been rebuilt, but they're useless at assessing what packages need a rebuild. That's why I suggested it's better to always mention a library transition is involved. Anyway, redhat-cluster has been successfully rebuilt everywhere and is just waiting for the buildd admins to sign the changes files. After that udev should be able to migrate shortly. https://buildd.debian.org/~luk/status/package.php?p=redhat-cluster Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#456133: qiv imlib
+ Bart Martens (Sat, 18 Apr 2009 13:01:46 +0200): On Fri, 2009-04-17 at 10:09 +0200, Adeodato Simó wrote: I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? Good plan. I just uploaded pqiv Aha. I’m CCing Andreas Metzler, though he problably read your mail via -release or something: he managed to file ITP #524569 roughly an hour before you filed #524578, but since he said “I am not stuck on maintaining this myself”, he’ll hopefully not mind you having prepared and uploaded your own as well. I chose to package pqiv without Conflicts/Provides/Replaces qiv. At least for now. Yes, I think not going Conflict/Provides/Replaces for now is a good choice (people can try it without uninstalling qiv, etc.). Just remember to do the dance if qiv doesn’t make it to Squeeze after all. I see that qiv upstream has a new developer, so maybe the imlib problem in qiv gets solved before squeeze freeze. http://www.klografx.net/qiv/ Qiv is not longer supported by me (Adam Kopacz), please visit the new Homepage: spiegl.de/qiv http://spiegl.de/qiv/ qiv.a...@spiegl.de Ah, that’s great; ideally both maintainers of qiv and pqiv should be made aware one of another if it hasn’t happened already. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524120: transitions.yaml handling: the PTS needs to grok finished transitions
+ Mark Hymers (Wed, 15 Apr 2009 19:39:53 +0100): On Wed, 15, Apr, 2009 at 11:04:18AM +0200, Stefano Zacchiroli spoke thus.. On Wed, Apr 15, 2009 at 10:25:40AM +0200, Adeodato Simó wrote: I see the PTS as the consumer of the YAML file. There can be, theoretically, other consumers and basically you are implicitly proposing that all consumers implement the cleanup upon migration logics. FWIW, Adam Barrat (thanks!) just prodded me on IRC about this, remembering me that devscripts contains another consumer of that YAML file (/usr/bin/transition-check), which is affected by the very same problem. In a sense, that strengthen my feeling that the solution should be FTP master side, let's gather some more comments ... As I've just mentioned to Dato and Luk on #-release, we've no objection to cleaning up the file at each dinstall and have a patch for it if they're happy for us to apply it. They're just discussing it now (I assume checking that it won't have any unwanted side effects from their side). Right. I thought about it, and please do implement such cleaning on each dinstall, and we can close this bug when the code is in place. Additionally, it’d be great if a mail could be sent for each transition that gets automatically cleaned, but it’s not a requisite. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMU for libthai/libdatrie transition
+ Theppitak Karoonboonyanan (Fri, 17 Apr 2009 14:25:24 +0700): Dear release team, libdatrie has bumped soname from libdatrie0 to libdatrie1, and the new libthai in unstable has modified its *.pc and *.la to hide the direct libdatrie link from its rdepends. So, its rdepends should be rebuilt to get rid of that direct link and avoid symbol conflicts. Please schedule binNMU for the libdatrie transition via libthai for this package: m17n-lib All other libthai rdepends have already been sourcefully uploaded. m17n-lib has also seen a recent sourceful upload, so no Bin-NMUs are necessary: http://packages.qa.debian.org/m/m17n-lib/news/20090415T103206Z.html Also, please notify the release team about transitions as soon as possible, and preferably before uploading to unstable. Having libdatrie0 disappear from unstable while pango1.0 still linked against it has rendered a big part of the archive unbuildable while we wait for pango1.0 to get rebuild, and that’s rather unfortunate because it slows down our job enormously. Thanks for your work, though. :-) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Testing removals and freeze requests:
+ Luk Claes (Fri, 17 Apr 2009 08:08:13 +0200): imlib 1.9.15-7 Waiting for kdegraphics to be migrated to testing, before scheduling for removal from testing. Please do remind us when that happens :-) What about icewm and, to a lesser extent, qiv? libnet0 1.0.2a-7 Removal from testing scheduled. Barry, would it make sense to file a RM against ftp.debian.org as well? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#456133: qiv imlib
+ Bart Martens (Mon, 13 Apr 2009 11:20:05 +0200): At this point, the most recent upstream version of qiv still needs the old imlib. Where to go from here ? Possible options: 1. Barry is working with upstream to get qiv updated to no longer need the old imlib. Let's appreciate Barry's efforts by giving Barry some more time to finish this effort. 2. We could replace qiv by pqiv, which is a program that more or less behaves like qiv. 3. Removal from Debian, although popcon reveals that there are still quite some users. I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMU for libthai/libdatrie transition
+ Theppitak Karoonboonyanan (Fri, 17 Apr 2009 15:17:00 +0700): On Fri, Apr 17, 2009 at 2:44 PM, Adeodato Simó d...@net.com.org.es wrote: m17n-lib has also seen a recent sourceful upload, so no Bin-NMUs are necessary: http://packages.qa.debian.org/m/m17n-lib/news/20090415T103206Z.html Please still consider scheduling the binNMU, anyway, as it's still directly linked against libdatrie1, which I'd like to get rid of. The sourceful m17n-lib upload was done before the recent change to libthai.la, which totally got rid of -ldatrie. Aah, good catch, thanks. Scheduled a Bin-NMU on amd64, i386, powerpc, and sparc, which are the arches that built m17n-lib/1.5.4-1 fast enough as to not pick up the fixed libthai. And pango1.0/armel as well. Also, please notify the release team about transitions as soon as possible, and preferably before uploading to unstable. Having libdatrie0 disappear from unstable while pango1.0 still linked against it has rendered a big part of the archive unbuildable while we wait for pango1.0 to get rebuild, and that’s rather unfortunate because it slows down our job enormously. It's my misunderstanding that the previous preparation by changing libthai.pc in unstable was enough for pango to be free from libdatrie0, as it was the case for other packages like scim-thai and gtk-im-libthai before. But that turned out to be wrong. Unfortunately, I forgot the fact that libthai-dev still ships libthai.la, not really for linking purpose, but to only satisfy Thai KDE users' needs, as kdelibs 3 requires *.la to dlopen()! So, I've recently updated libthai.la to get rid of the problem. I was about to request for binNMU but the binNMU for pango was quick enough. So, I just waited for buildd to finish the builds on some archs before requesting m17n-lib. The thing is that it’s infinitely better to rebuild pango1.0 and make it depend on libdatrie1, and then rebuild it again once libthai was fixed in order to make the dependency go away completely, than to wait and rebuild it only once when a fixed libthai is available. Because with the former way you don’t render it uninstallable at any point, but with the latter you do. Of course, you weren’t supposed to be aware of this, since it’s rather specific knowledge, so no blame is involved. :-) Sorry for the inconvenience. Things didn't go as planned. I'll contact release team sooner next time for similar case. That’s great, thanks. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMU for libthai/libdatrie transition
+ Loïc Minier (Fri, 17 Apr 2009 13:24:15 +0200):
On Fri, Apr 17, 2009, Adeodato Simó wrote:
No big worries. It’s very likely I would’ve missed myself the fact that
pango1.0 would be rendered uninstallable for a while with that scheme.
And thanks for pushing for decreasing the spurious linkage in the archive!
Not sure who you were saying that to, but I did raise that we should
avoid the transition; perhaps I should have used stronger words
The message you linked does not talk about avoiding the libdatrie
transition at all, but about not propagating it to packages that do not
depend on it. That would’ve resulted (well, has resulted) in pango1.0
not being part of the transition, so that’s what I thanked you about,
but I can hardly see how we could’ve skipped the transition. But I’m
afraid I haven’t read all the thread.
On Fri, Apr 17, 2009, Adeodato Simó wrote:
The thing is that it’s infinitely better to rebuild pango1.0 and make it
depend on libdatrie1, and then rebuild it again once libthai was fixed
in order to make the dependency go away completely, than to wait and
rebuild it only once when a fixed libthai is available. Because with the
former way you don’t render it uninstallable at any point, but with the
latter you do.
I think you're mixing libdatrie and libthai above, not sure; I was
proposing to:
- change libthai/unstable to not cause linkage on libdatrie
- rebuild pango against that to drop the datrie dep
- upload new datrie
- rebuild libthai against it
Yes, but that’s not the way it happened AFAIK. The order was more like
(enumerating the above four items): 1, 3, 4, 2 or so, which did render
pango1.0 uninstallable. Your proposed order is of course much better,
because you don’t do spurious rebuilds and pango1.0 doesn’t get
uninstallable; I was merely pointing out that, with the given order of
uploads as they happened, spurious rebuilds would have been better than
uninstallability of pango1.0. I hope I explained myself clearly.
Of course, you weren’t supposed to be aware of this, since it’s rather
specific knowledge, so no blame is involved. :-)
Theppitak is upstream for datrie and libthai as well
Well, I meant knowledge of the Debian environment in order to know what
order of events is preferable. You, for example, proposed a very good
order, but for some reason it was not followed. With the order of
uploads as they happened and AIUI, Theppitak thought it was better to
rebuild pango1.0 only once a fixed libthai.{pc,la} was available, which
I think it’s a very reasonable guess of what’s best, but it is actually
not.
I hope this cleared up things a bit. It’s just too sad the delay this
imposes in several of our ongoing transitions, but as I said, no blame
is involved AFAIC.
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
+ William Pitcock (Fri, 17 Apr 2009 04:49:58 -0500): On Fri, 2009-04-17 at 16:25 +0800, Thomas Goirand wrote: Luk Claes wrote: I'm afraid it's too invasive to be included, though I would propose to upload it to backports.org. Then can the current broken version of yum be removed of Stable? It makes absolutely no sense to keep a software that doesn't work in the distribution. I call bollocks here. I am using the version of yum in stable right now to yield perfectly working virtual machine filesystems. How is it broken when it is working as expected on production servers? Please do not drop d-release from CC. How do you expect for the package not to be removed if you prevent relevant information from reaching the appropriate team? Omnipresent Release Managers? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dw wesnoth_1:1.6.1-1 . hppa sparc . -m 'libgl1-mesa-dri (= 7.4-2)'
+ Gerfried Fuchs (Thu, 16 Apr 2009 07:44:16 +0200): libgl1-mesa-dri isn't built on happa and sparc yet neither, so I propose to just copy the dw from alpha for those archs: dw wesnoth_1:1.6.1-1 . hppa sparc . -m 'libgl1-mesa-dri (= 7.4-2)' Done. Please use debian-wb-t...@lists.debian.org in the future. (Yes, I saw your line on IRC about the wanna-build.txt document in release.d.o, and it’s been in the TODO for a while now, but thanks nevertheless. :-) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for new QScintilla2
+ Torsten Marek (Wed, 15 Apr 2009 00:21:00 +0200): Hi, Hello, Torsten. QScintilla2 2.3.2 has been uploaded to unstable, which includes a SONAME change. Please schedule the following binNMUs: nmu universalindentgui_0.8.1-1.2 . * . -m 'Rebuild against QScintilla 2.3.2' nmu kscope_1.9.2-1 . * . -m 'Rebuild against QScintilla 2.3.2' nmu tora_2.0.0-3 . * . -m 'Rebuild against QScintilla 2.3.2' dw universalindentgui_0.8.1-1.2 kscope_1.9.2-1 tora_2.0.0-3 . ALL -amd64 . -m 'libqscintilla2-5 (= 2.3.2-1.1)' All scheduled. (Note that we have tools to generate those “nmu” lines automatically just giving the name of the transition, so it’s not necessary for maintainers to spell them out. On the other hand, if it’s some other request than “all Bin-NMUs for transition X”, then we do appreciate them.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524120: transitions.yaml handling: the PTS needs to grok finished transitions
+ Stefano Zacchiroli (Wed, 15 Apr 2009 10:02:55 +0200): On Tue, Apr 14, 2009 at 11:56:51PM +0200, Adeodato Simó wrote: The way it works is that the Release Team specifies a target package/version combination that must migrate to testing, and all listed packages are blocked until that version or a later one migrates. When that happens, the block is automatically lifted, i.e. dak no longer rejects uploads. It’d be good if the PTS could gain support for doing the same. Hum, I wonder whether the PTS is the right place where to fix that. Ideally, my preferred solution would be a way, release manager side, that automatically cleans up the YAML file when transitions are done. This is not (only :-)) because it would you that do the work rather then us :-), but rather because I see the PTS as the consumer of the YAML file. There can be, theoretically, other consumers and basically you are implicitly proposing that all consumers implement the cleanup upon migration logics. If you have strong reasons for not implementing the cleanup your side, I have no objection fixing the PTS the way you proposed. Let me know. There is code in dak that can do the cleaning up, but it’s not triggered automatically, i.e., some release person has to run a command by hand. I perfectly get whan you mean, though I’m unsure what could be done about it: AFAIK, the file not being cleaned in a fully automated fashion is in case there could be any mistakes with the cleanup, plus it really can’t be cronned by anybody else than ftpmaster because the setup is done by handing sudo access to the command to members of the release team. Maybe it should be indeed automatically cleaned up. Let’s put this bug on hold until we can figure that out. Cc'ing -release and ftpmaster@ in case they have any comments. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for gnome-desktop, again
+ Josselin Mouette (Tue, 14 Apr 2009 20:59:31 +0200): Hi, Hello, Joss. as requested on IRC, I have uploaded gnome-desktop 2.26.1 to unstable. This means the package name changes (again), to libgnome-desktop-2-11. Please schedule binNMUs all reverse dependencies with appropriate dep-waits, Scheduled. except for quick-lounge-applet, which needs a new upstream. The scripts detected that it’s on Failed state, and didn’t offer to rebuild it. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for libgps transistion
+ Bernd Zeimetz (Tue, 14 Apr 2009 11:21:12 +0200): please schedule binNMUs for the transition of libgps17 to libgps18. The following packages are affected: kdeedu gosmore s3d gaia viking geoclue A dep-wait for libgps-dev (= 2.39-1) is needed. You don't need to schedule a binNMU for geoclue, as I'll sponsor an upload with several bugfixes within the next few days. Also kdeedu needs an additional dep-wait on libgl1-mesa-dri (= 7.4-2). Scheduled all except geoclue and gosmore, which (as I mentioned on IRC) build-depends on libgpsd-dev, but doesn’t seem to have any dependency on it. Waiting for news on this. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for libgps transistion
+ Adeodato Simó (Tue, 14 Apr 2009 11:55:43 +0200): Scheduled all except [...] gosmore, which (as I mentioned on IRC) build-depends on libgpsd-dev, but doesn’t seem to have any dependency on it. Waiting for news on this. bzed dato: ok you can drop gpsmore from the list, they're doing their own connectiong stuff bzed which will fail one day... but well... Fine. So all needed Bin-NMUs in place. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Hint apache2/apache2-mpm-itk/apr-util
+ Stefan Fritsch (Mon, 13 Apr 2009 12:18:24 +0200): Hi, these packages need to enter testing at the same time: apr-util 1.3.4+dfsg-1 apache2 2.2.11-3 apache2-mpm-itk 2.2.11-01-1+b1 (2.2.11-01-1 on mipsel) This is now done. I wanted to do it whilst paying attention that the three of them migrated in the same run, so I went ahead an forced apr-util without waiting for the downgrade of #521899. For this reason, downgrading it is no longer necessary. apr-util will later get a Breaks: apache2.2-common 2.2.11-3, but AIUI this is not supported yet. Please do that soon. AFAIK, it’s only Britney that doesn’t grok Breaks, but having it in place already makes perfect sense. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU bogofilter
+ Pierre Habouzit (Tue, 14 Apr 2009 00:15:01 +0200): Hello, Tokyocabinet bumped its soname, and bogofilter is a rdep. nmu bogofilter_1.2.0-1 . * . -m 'Rebuild against libtokyocabinet5' Scheduled, though amended changelog entry to read libtokyocabinet8. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Propagation stable - {testing,unstable} and udebs
Hello, With the recent first point release of Lenny, the known version constraint “stable testing unstable” became endangered, since a lot of packages saw updates in unstable whilst they still hadn’t been updated in unstable or, more commonly, in testing. The release team agreed with ftpmaster that at the time of the point release, stuff would be propagated from stable to testing and/or unstable as appropriate as to continue meeting the version constraints. This is generally a safe thing to do. So, for example, linux-2.6 was upgraded from 2.6.26-13 to 2.6.26-15, which came via stable. As there was a d-i respin, a lot of udeb packages were uploaded as well, that now fail to meet the version check. ftpmaster has asked us to look into fixing these as well, that is, to migrate them from stable to testing. These are mostly the linux-kernel-di-* packages, plus oldsys-preseed. Apparently ftpmaster has already propagated all the linux-kernel-di-* packages to unstable (albeit the old binaries seem to have been left around). So, please be so kind to answer the following questions. Is it okay to: * put oldsys-preseed 3.2lenny1 udeb in lenny, replacing 3.2? * put all *-2.6.26-2-* kernel and module udebs in testing, REPLACING THEIR 2.6.26-1 COUNTERPARTS. * drop the *-2.6.26-1-* kernel and module udebs from unstable, now that the 2.6.26-2 are there. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU gnome-main-menu 0.9.12-2
+ Luca Falavigna (Sun, 12 Apr 2009 16:12:26 +0200): Hello, Hello, Luca. Actually, gnome-main-menu and libslab0 from gnome-main-menu source packages are uninstallable on i386 and other architectures due to missing libgnome-desktop-2. A binNMU is required to fix this. nmu gnome-main-menu_0.9.12-2 . hppa i386 ia64 mipsel powerpc sparc . -m 'Rebuild against libgnome-desktop-2.7' I’ll delay this a bit, because I want to migrate network-manager first, and it’s marginally better if I don’t do this rebuild in unstable until that happens. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition from libmysqlclient15 to libmysqlclient16
+ Norbert Tretkowski (Tue, 07 Apr 2009 11:05:05 +0200): Hi, Hello, Norbert. I plan to move MySQL 5.1 from experimental to unstable really soon now, MySQL 5.0 will be dropped from Debian at the same time. This means 215 packages need to be rebuild. There should be no changes necessary on these packages, a simple rebuild should do it. libmysqlclient15 and libmysqlclient16 come from different packages, so I guess this means mysql-dfsg-5.1 can migrate to testing while still having mysql-dfsg-5.0 there, making the transition not as painful. There is, however, the concern of libmysqlclient15 and libmysqlclient16 getting both loaded into a process’ space, oh well. Anyway, if the above is correct, please let us know when you’ve uploaded to unstable. If something’s wrong, please get back to us on that. By the way, it’s 118 source packages that need a rebuild, which is always the interesting figure, rather than the number of binary packages involved. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please unblock reportbug-ng
+ Bastian Venthur (Thu, 09 Apr 2009 14:53:16 +0200): rng tries to include the output of bugscript automatically into the mail. But if the output is too long to fit in a single mailto URL it recognizes the situation, puts the output in a temporary file and puts a message into the mail pointing to the tempfile and asking the user to attach this file. rng would attach those file automatically if I'd know how to do it. So basically rng provides the output in most cases automatically but in some cases, like xorg, the user has to do a manual step. I see. Well, putting the output of bugscript in the URL sounds scary. Have you investigated about using the xdg-email(1) command, from the xdg-utils package? It allows to invoke the configured mailer for the user (it has some logic to detect what’s the user’s preferred MUA), and it takes options like --body and --attach. Maybe it is better, maybe it is not. Yes, rng already uses xdg-email as default, unfortunately --attach does not work reliable across the different mailclients, so rng has to use the mailto-hack until the BTS supports a different method of submitting bugreports. Okay. Anyway, I meant to ask: now that reportbug has a graphical interface and, particularly, a Python library, what are your plans for rng in the future, during this release cycle? I intend to keep on developing on rng. Keep it bugfree and further enhance the usability. I plan to implement developer-features like sending control-messages to rename, reassign bugs etc. Regarding reportbug. It's nice to see that it finally has a GUI but the current state of this GUI leaves much room for improvements. So I don't see a reason to drop rng, if that was your question. No, my question was not about dropping rng, but whether you’re planning on using the newly-available python-reportbug API to avoid code duplication, and to work with the reportbug maintainers to make said API meet your needs as an alternative-to-reportbug implementation author. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please unblock reportbug-ng
+ Bastian Venthur (Sat, 11 Apr 2009 10:30:00 +0200): Adeodato Simó schrieb: No, my question was not about dropping rng, but whether you’re planning on using the newly-available python-reportbug API to avoid code duplication, and to work with the reportbug maintainers to make said API meet your needs as an alternative-to-reportbug implementation author. I would have to have a look at it since I currently don't know what python-reportbug actually provides. If it covers a lot of rng's needs I will probably use this instead of my own implementation if it's possible. I'm sure reportbug could also benefit a lot from my code since rng uses SOAP for ages instead of HTML parsing. Okay. It’d be very good to do that, so I’d appreciate if you would do that, with a net benefit of python-reportbug getting improved, and rng not duplicating functionality. What about rng, why is it still blocked? I was planning on unblocking it and let you know once we finished off this ongoing conversation. Unblocked now, we’ll see how it goes. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please unblock reportbug-ng
+ Adeodato Simó (Sat, 11 Apr 2009 10:56:11 +0200): What about rng, why is it still blocked? I was planning on unblocking it and let you know once we finished off this ongoing conversation. Unblocked now, we’ll see how it goes. So it seems I was too fast with this: http://lists.debian.org/debian-release/2009/04/msg00123.html http://bugs.debian.org/523578 So, you said it *should* work, but it doesn’t seem to be working *reliably*. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for the GNOME transitions
+ Josselin Mouette (Wed, 08 Apr 2009 00:34:34 +0200): Hi, Hello! totem-pl-parser transition: - brasero_0.8.0-3 Done. gnome-desktop transition: - avant-window-navigator_0.3.2-1 - awn-extras-applets_0.3.2.1-1 - compiz_0.8.2-1 (probably only on amd64) - deskbar-applet_2.24.3-1 - desktop-data-model_1.2.5-1 - eog_2.24.3.1-1 - galeon_2.0.6-2.1 - gnome-launch-box_0.2-1.1 - gnome-mag_1:0.15.4-1 - gnome-utils_2.24.1-2 - icewm_1.2.37-1 - quick-lounge-applet_2.12.5-5 Done, except: - beagle_0.3.9-2 since AFAIK it FTBFSes due to Build-Depending on libgnome2.0-cil (which has been dropped in favour of libgnome2.24-cil). both of them: - gnome-python-desktop_2.24.1-1 Done. - tracker_0.6.92-1 This one got a sourceful upload that seems that managed to arrive in time, though I’m unsure if the dep-waits are correct: https://buildd.debian.org/~luk/status/package.php?p=tracker nautilus extension path change: - diff-ext_0.2.3-3 - eiciel_0.9.6.1-2 - evince_2.24.2-2 - gksu_2.0.2-2 - nautilus-actions_1.4.1-1 - nautilus-share_0.7.2-4 - seahorse-plugins_2.24.1-3 All scheduled, except eiciel, which had a version mismatch (0.9.6.1-3 uploaded a couple days ago). It had bumped build-dep on libnautilus-extension-dev, so it should be fine. No need to schedule the rest of them, they need sourceful uploads, many of which have already occurred. Okay, great. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint pygobject
+ Josselin Mouette (Wed, 08 Apr 2009 16:02:07 +0200): pygobject is ready to enter testing, but it needs to be hinted to migrate together with pygtk and pygtksourceview. Hint added, should make it in the next run. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint some shorewall* packages
+ Roberto C. Sánchez (Wed, 08 Apr 2009 16:15:47 -0400): It apears that the following shorewall* packages require manual hinting: shorewall-common shorewall-perl shorewall-shell shorewall6 Please allow them to propogate to testing. Hint added, will make sure they migrate. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-openmpi-maintainers] Open MPI 1.3 transition
+ Manuel Prinz (Thu, 09 Apr 2009 01:08:40 +0200): Am Samstag, den 04.04.2009, 21:14 +0200 schrieb Manuel Prinz: [ Upload of Open MPI ] since I have not heared back yet, are you OK with me uploading Open MPI to unstable? Or is there another prodecure I should follow? Please wait for a bit until we can get to your message. It usually takes us some time until we get to the most recent mails on the list. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please unblock reportbug-ng
+ Bastian Venthur (Sat, 21 Mar 2009 14:27:58 +0100): rng tries to include the output of bugscript automatically into the mail. But if the output is too long to fit in a single mailto URL it recognizes the situation, puts the output in a temporary file and puts a message into the mail pointing to the tempfile and asking the user to attach this file. rng would attach those file automatically if I'd know how to do it. So basically rng provides the output in most cases automatically but in some cases, like xorg, the user has to do a manual step. I see. Well, putting the output of bugscript in the URL sounds scary. Have you investigated about using the xdg-email(1) command, from the xdg-utils package? It allows to invoke the configured mailer for the user (it has some logic to detect what’s the user’s preferred MUA), and it takes options like --body and --attach. Maybe it is better, maybe it is not. Anyway, I meant to ask: now that reportbug has a graphical interface and, particularly, a Python library, what are your plans for rng in the future, during this release cycle? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
