Bug#650601: Re: Bug#650601: transition: libpng 1.5
Hi, 2012/6/27 Julien Cristau : > On Wed, Jun 27, 2012 at 08:45:03 +0900, Nobuhiro Iwamatsu wrote: > >> Hi, >> >> I am still correcting FTBFS. >> However, almost packages can shift to libpng 1.5. >> May I upload libpng 1.5 to unstable? >> > Absolutely not. OK. Does that already mean that it is too late in wheezy? Best regards, Nobuhiro -- Nobuhiro Iwamatsu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabmqnvkciqb-xelrqr50smxvbg3oxmebfb94p55q+ea9krp...@mail.gmail.com
Removing yesod-stuff on powerpc for wheezy?
Dear release team, for the recent Haskell migration (thanks for that) we had to remove some packages from testing (on all architectures) because there is a problem with haskell-cryptocipher on powerpc. It is likely that there will be no fix available in time for the release. I think our users are better served with yesod on at least most architectures in wheezy than on none at all. My suggestion is hence to remove haskell-cryptocipher and all its reverse dependencies on powerpc from unstable. As nothing new will be uploaded the packages should then migrate easily to testing. Is that ok with you? If so, I’ll ask the ftp-masters for removal. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#679438: marked as done (nmu: libphone-ui-shr_0.1+git20110827-3)
Your message dated Thu, 28 Jun 2012 19:18:50 +0100 with message-id <1340907530.31879.8.ca...@jacala.jungle.funky-badger.org> and subject line Re: Bug#679438: nmu: libphone-ui-shr_0.1+git20110827-3 has caused the Debian Bug report #679438, regarding nmu: libphone-ui-shr_0.1+git20110827-3 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 679438: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679438 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libphone-ui-shr_0.1+git20110827-3 . ALL . -m "Rebuild against libnl3" libphone-ui-shr is currently the only remaining package still depending on libnl2. All other packages either still use libnl1 or have been upgraded to libnl3. I don't think we should ship with three libnl versions in wheezy. A simple rebuild of libphone-ui-shr will make it use libnl3 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Thu, 2012-06-28 at 19:35 +0200, Michael Biebl wrote: > nmu libphone-ui-shr_0.1+git20110827-3 . ALL . -m "Rebuild against libnl3" > > libphone-ui-shr is currently the only remaining package still depending > on libnl2. All other packages either still use libnl1 or have been > upgraded to libnl3. I don't think we should ship with three libnl > versions in wheezy. > > A simple rebuild of libphone-ui-shr will make it use libnl3 Scheduled. Regards, Adam --- End Message ---
Bug#679041: transition: wireshark
On Thu, 2012-06-28 at 07:36 -0400, Eloy Paris wrote: > On 06/28/2012 04:43 AM, Bálint Réczey wrote: > > In the past we managed the "transition" ourselves by quickly updating > > netexpect after wireshark. > > Since netexpect does not have too many users yet and netexpect is the > > only package > > depending on wireshark it seemed to be a better solution over > > involving the release team. > > Should we always open a transition bug? > > Last time, for the Wireshark 1.4 to 1.6 transition, we were not close to > a freeze, but Bálint and I coordinated the transition just like we did > this time. The end result was the same -- all packages and their > dependencies hitting unstable on the same day. For most of the release cycle, that will likely work fine, yes; although unless netexpect actually requires source changes, you could save yourself some work and just ask us to binNMU it. However, when the freeze is known to be very close and the upload doesn't occur until nearly three weeks _after_ the already publicised "talk to us /now/ or your transition is unlikely to make wheezy" time point, then co-ordination amongst yourselves is not sufficient. If it weren't for upstream's published support calendar, there's a reasonable chance that 1.8 might not have made it, given when the release team were asked. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340907164.31879.6.ca...@jacala.jungle.funky-badger.org
Processed: RM: libnl2 -- ROM; obsolete, unmaintained
Processing commands for cont...@bugs.debian.org: > reassign 671931 ftp.debian.org Bug #671931 [libnl2] libnl2 should not be released in wheezy Bug reassigned from package 'libnl2' to 'ftp.debian.org'. Ignoring request to alter found versions of bug #671931 to the same values previously set Ignoring request to alter fixed versions of bug #671931 to the same values previously set > retitle 671931 RM: libnl2 -- ROM; obsolete, unmaintained Bug #671931 [ftp.debian.org] libnl2 should not be released in wheezy Changed Bug title to 'RM: libnl2 -- ROM; obsolete, unmaintained' from 'libnl2 should not be released in wheezy' > block 671931 by 679438 Bug #671931 [ftp.debian.org] RM: libnl2 -- ROM; obsolete, unmaintained 671931 was not blocked by any bugs. 671931 was not blocking any bugs. Added blocking bug(s) of 671931: 679438 > thanks Stopping processing here. Please contact me if you need assistance. -- 671931: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671931 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134090564010543.transcr...@bugs.debian.org
Bug#679438: nmu: libphone-ui-shr_0.1+git20110827-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libphone-ui-shr_0.1+git20110827-3 . ALL . -m "Rebuild against libnl3" libphone-ui-shr is currently the only remaining package still depending on libnl2. All other packages either still use libnl1 or have been upgraded to libnl3. I don't think we should ship with three libnl versions in wheezy. A simple rebuild of libphone-ui-shr will make it use libnl3 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628173540.14964.69470.report...@pluto.milchstrasse.xx
NEW changes in proposedupdates
Processing changes file: bcfg2_1.0.1-3+squeeze2_amd64.changes Rejecting. REJECT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ski6w-0004pm...@franck.debian.org
Re: [pkg-bacula-devel] Bug#677700: bacula-director-mysql: fails to upgrade from testing - Table 'bacula.Version' doesn't exist
Hi there! On Sun, 24 Jun 2012 19:04:19 +0200, Adam D. Barratt wrote: > On Sun, 2012-06-24 at 15:52 +0200, Luca Capello wrote: >> On Sat, 16 Jun 2012 11:49:34 +0200, Andreas Beckmann wrote: >> > during a test with piuparts I noticed your package fails to upgrade from >> > 'wheezy'. >> > It installed fine in 'wheezy', then the upgrade to 'sid' fails. >> >> Actually, I was not able to install bacula-director-mysql_5.0.3-1+b1 on >> a clean wheezy (CD-1_20120618-04:55; d-i_20120508) with the default >> mysql-server, i.e. 5.5: > > Andreas's log also shows that failure: [...] > I'm therefore marking the bug as found in the version in testing, as > trying to install that on a current wheezy will already fail. (The > offending syntax appears to be fixed in a mysql-5.5 patch in bacula > 5.2.) Thank you for the notice, I did not completely read Andreas's log, my fault. > If anyone has a /working/ 5.0.3 install that they could try upgrading to > 5.2.6, that would be helpful, just to confirm. FWIW I have already planned to test that during DebCamp. Thx, bye, Gismo / Luca pgphBSCxG4jdE.pgp Description: PGP signature
Re: grass 6.4.2-2 not migrating
On 28.06.2012 13:46, Touko Korpela wrote: Looks like grass is not migrating to testing. http://release.debian.org/migration/testing.pl?package=grass Does binNMU on i386 help? grass doesn't need binNMUing, and qgis already was. It looks like libgdal-grass could do with a binNMU indeed; scheduled. Note that the binNMUs are needed on all architectures, not just i386. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e013ca1cc3b8a4839fb095b09963e...@mail.adsl.funky-badger.org
Re: grass 6.4.2-2 not migrating
On 28/06/12 14:46, Touko Korpela wrote: Looks like grass is not migrating to testing. http://release.debian.org/migration/testing.pl?package=grass Does binNMU on i386 help? No, libgdal-grass needs to be binNMUed because it wasn't built in a clean/up-to-date chroot. Scheduled. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fec5503.3080...@dogguy.org
grass 6.4.2-2 not migrating
Looks like grass is not migrating to testing. http://release.debian.org/migration/testing.pl?package=grass Does binNMU on i386 help? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628124602.GA11864@lisko
Re: RFC: syslog-ng 3.3.6 & ivykis in Wheezy
Hi! As far as I remember, I have not received any response to this yet, so I'll give a short update: Gergely Nagy writes: > Since the freeze is approaching, I would like to ask for a freeze > exception beforehand, to be able to push a new version of syslog-ng into > Wheezy, one that instead of embedding a forked & heavily patched version > of ivykis (a third party library), would use the separately packaged, > upstream version of the library. I still wish to do this, and the new syslog-ng 3.3.6 will be a bug fix release over 3.3.5, with a reasonably small diff. (Well, not so small, becuase migrating from forked ivykis to upstream adds quite a bit of search & replace noise, but apart from that!). > I'm writing to this list due to two reasons: first, the syslog-ng > release will likely happen after the freeze started (I'm guessing ~2-3 > weeks from now). I now estimate it to next week, there's only two bugs left to fix + some packaging things - but it is certain that a release will not happen before the freeze. > There are no reverse deps, nor reverse build-deps of libsyslog-ng-dev, > and I know of no user of it outside of Debian, either, so this part > should be safe too. This is still the case, and ivykis 0.30 is in unstable, 0.29 is in testing already (syslog-ng needs >= 0.30, but I see no reason why it wouldn't migrate). > This experimental upload can be done before the freeze (assuming ivykis > gets released this week, and the package goes through NEW within a few > days), and an upload to unstable would be done when 3.3.6 is released, > most probably post-freeze. Technically, an upload of syslog-ng to experimental may be possible, but this close to the freeze, and with me wanting 3.3.6 in wheezy, I don't really see the point. > At that time, I would appreciate if we'd get a freeze exception, and > syslog-ng 3.3.6 could migrate to testing, and be part of wheezy, along > with ivykis. Ivykis appears to be fine as far as the freeze is concerned, but seeing as syslog-ng 3.3.6 will not make it before the freeze date, I'd like to ask for a freeze exception. -- |8], with his syslog-ng upstream hat on -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq8jzlvo.fsf@algernon.balabit
Bug#679041: transition: wireshark
Hi all, On 06/28/2012 04:43 AM, Bálint Réczey wrote: [...] 2012/6/27 Adam D. Barratt : Can we schedule binNMUs for netexpect, or does it require any source changes? Eloy will upload the new netexpect package soon. I uploaded to unstable new netexpect packages built against the new Wireshark 1.8.0 packages yesterday as soon as I saw that Wireshark 1.8.0 had been accepted into unstable. Note that 1.8.0~rc1-1 has been uploaded to the NEW queue weeks ago... [1] In that case, I'm not entirely sure why the transition bug wasn't raised "weeks ago"... nor what the logic is behind not having uploaded the release version already, given that the upstream schedule claims it was released a week ago. In the past we managed the "transition" ourselves by quickly updating netexpect after wireshark. Since netexpect does not have too many users yet and netexpect is the only package depending on wireshark it seemed to be a better solution over involving the release team. Should we always open a transition bug? Last time, for the Wireshark 1.4 to 1.6 transition, we were not close to a freeze, but Bálint and I coordinated the transition just like we did this time. The end result was the same -- all packages and their dependencies hitting unstable on the same day. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fec41ca.9010...@chapus.net
Patch for #660260 (gnudatalanguage FTBFS) from upstream may come only after the freeze
Hi, I know it's late, but after quite some prodding by me and others, upstream of gnudatalanguage is finally working on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660260 Unfortunately so far the first two patch versions I received from upstream didn't completely solve this issue. They asked in their last mail if this is "critical for this week", which makes me suspect that they may not be able to produce a complete patch in time for the freeze on Saturday. Since all three bugs which are currently open against gnudatalanguage are the same issue (2x FTBFS, merged; 1x uninstallable), gnudatalanguage has no other known issues and was in testing before the above issue for over half a year without any other issues. So it'd be nice to know if the release team in principle would grant a freeze exception (of course subject to the final debdiff) for an upload of gnudatalanguage to fix this issue. The necessary patch -- based on what has been[1] and will be committed for this issue in the upstream CVS repo -- will likely only remove one file, patch the Makefile to no more compile or link that file, and update a few files to use functions from plplot instead of those from the removed file. It seems currently that only two source code file to need such a modification. [1] http://gnudatalanguage.cvs.sf.net/viewvc/gnudatalanguage/gdl/src/Makefile.am?r1=1.62&r2=1.63&sortby=date http://gnudatalanguage.cvs.sf.net/viewvc/gnudatalanguage/gdl/src/plotting_surface.cpp?r1=1.6&r2=1.8&sortby=date Current build failures suggest that also plotting_xyouts.cpp needs to be modified. Upstream also patched (or rather checked in a generated) Makefile.in, but since since autoreconf/dh_autoreconf is used in the package, patching Makefile.in should not be necessary there. TIA Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628114235.gv3...@sym.noone.org
Re: Next upload 2012-06-26 (dpkg 1.16.5)
On Tue, Jun 26, 2012 at 02:01:47AM +0300, Touko Korpela wrote: > On Sun, Jun 24, 2012 at 11:25:11PM +0300, Touko Korpela wrote: > > On Wed, Jun 20, 2012 at 07:32:20AM +0200, Guillem Jover wrote: > > > I'm planning to upload dpkg 1.16.5 to unstable on the 26th, to be able > > > to finish cleaning up some pending changes I've locally and to give > > > some time for the initial wave of translation updates once I've sent > > > the call. Given that there's no exact date for the freeze yet, I'm not > > > sure if I'm on borrowed time, that's why I'm CCing the release team. I > > > could probably advance the upload by few days though. > > > > > > I'll be doing a first push today. The remaning things I'll be finishing > > > up next are at least the strings cleanup left out from the 1.16.4 > > > release, the cross-multiarch patches, part of the changelog binNMU > > > solution, and some other multiarch related improvements. > > > > I think it would be good to let 1.16.4.3 migrate before next > > upload, because it has some (RC) fixes good to have in testing. > > dpkg 1.16.4.3 is now 8/10 days old It migrated now. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679041: transition: wireshark
2012/6/27 Adam D. Barratt : > tag 679041 + pending > thanks > > On Tue, 2012-06-26 at 19:16 +0200, Bálint Réczey wrote: >> 2012/6/26 Mehdi Dogguy : >> > On 26/06/2012 00:10, Bálint Réczey wrote: >> >> I'd like to upload the latest version of wireshark to unstable. >> >> Updating from 1.6.8 to 1.8.0 brings a new ABI with a new soname for >> >> all the libs. Having Wireshark 1.8.x in Wheezy is important because >> >> upstream's support for 1.6.x ends on June 7, 2013 [1] and Wireshark >> >> needs regular security updates. > [...] >> > Thanks for letting us know. Unfortunately, we think that this update >> > came a tad late because we are >that< near to freeze and the update >> > seems quite large. >> This is why i don't want to risk backporting security fixes from 1.8.x to >> 1.6.x. > > I have to admit to not being happy with the size of the diff at this > late stage, but it seems the lesser of the available evils. The 1.8 > package was accepted from NEW a short while ago by our friendly > ftp-team. Thanks! The Wireshark project uses pretty advanced techniques for ensuring code quality including three different static code analyzers, building for platforms and fuzz testing every build. There are still security issues found in the code base time to time, but with more than 2 million lines of C code it would be hard to avoid those completely. All in all I'm convinced that having 1.8.x in Wheezy in the right decision. > > Can we schedule binNMUs for netexpect, or does it require any source > changes? Eloy will upload the new netexpect package soon. ... > >> Note that 1.8.0~rc1-1 has been uploaded to the NEW queue weeks ago... [1] > > In that case, I'm not entirely sure why the transition bug wasn't raised > "weeks ago"... nor what the logic is behind not having uploaded the > release version already, given that the upstream schedule claims it was > released a week ago. In the past we managed the "transition" ourselves by quickly updating netexpect after wireshark. Since netexpect does not have too many users yet and netexpect is the only package depending on wireshark it seemed to be a better solution over involving the release team. Should we always open a transition bug? Cheers, Balint -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cak0odpy4nabv4mqhy+vjmfvmqnqksntt+wtwzm99ka63jca...@mail.gmail.com
Re: ruby-rubymail (NEW) and sup-mail
On 28.06.2012 08:27, Per Andersson wrote: Refrasing my original (still unanswered) question: Will whatever was uploaded to NEW before the freeze be processed or was that already frozen before the freeze? That's mostly at the ftp team's discretion, although I'd expect packages with e.g. soname changes to get confirmed with the release team before they were accepted at this stage. In any case, ruby-rubymail appears not to be in NEW any more so I assume it's been processed. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6ce97e30445e2fc52d55174ce3480...@mail.adsl.funky-badger.org
Re: Xmms2 in new
On 27.06.2012 08:18, Rémi Vanicat wrote: xmms2 is in new[1] and might not do it for freeze, and I was wondering which option I should follow. For the record, it appears that xmms2 was accepted from NEW about 90 minutes after the above mail, so it doesn't look like there's anything particular that needs handling here at the moment. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7f522617830907e18ec4ab4d0174e...@mail.adsl.funky-badger.org
Re: ruby-rubymail (NEW) and sup-mail
Hi! On Wed, Jun 27, 2012 at 5:10 PM, Julien Cristau wrote: > On Tue, Jun 26, 2012 at 21:15:17 +0200, Per Andersson wrote: > >> Hi! >> >> The RC bug #678269 is filed against sup-mail because it fails >> running with Ruby 1.8. [0] >> > 1.8 or 1.9? The current sup-mail fails to run with 1.9.1. >> [0] http://bugs.debian.org/678269 >> >> A while back ago I adopted sup-mail and have recently fixed >> so it runs with Ruby 1.9.1, which is now default in Debian. >> >> In the process of fixing sup-mail for Ruby 1.9.1 I have also >> adopted librmail-ruby1.8 and moved to the new Ruby policy >> and gem2deb packaging. >> >> sup-mail is not uploaded yet though since it depends on >> ruby-rubymail which is in NEW. >> > If you need NEW to fix RC bugs, it's usually a sign that you're doing it > wrong. Can't sup-mail be made to work with the current librmail-ruby? Probably so. There are many changes and I have transitioned almost all sup-mail's dependencies to the new ruby policy (so they run under Ruby 1.9.1). It happens that ruby-rubymail was not uploaded until a few days ago because of people's lack of time (IANADD). It might be possible to make it all run under Ruby 1.8, I don't know. But I would rather not go down that road when I now have gone through all the trouble (quite much actually) to fix everything so it runs under Ruby 1.9.1. Refrasing my original (still unanswered) question: Will whatever was uploaded to NEW before the freeze be processed or was that already frozen before the freeze? -- Per -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabyrxsqp_++gzuxod0mzdozkkv1csrubs+rm09hwomzua9z...@mail.gmail.com
