Processed: affects 656839
Processing commands for cont...@bugs.debian.org: > affects 656839 src:linphone Bug #656839 [release.debian.org] transition: linphone libexosip2 libosip2 Added indication that 656839 affects src:linphone > thanks Stopping processing here. Please contact me if you need assistance. -- 656839: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656839 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.132832272612668.transcr...@bugs.debian.org
Processed: affects 656829
Processing commands for cont...@bugs.debian.org: > affects 656829 src:exiv2 Bug #656829 [release.debian.org] transition: exiv2 - libexiv2-9 -> libexiv2-11 Added indication that 656829 affects src:exiv2 > thanks Stopping processing here. Please contact me if you need assistance. -- 656829: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656829 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.132832268312602.transcr...@bugs.debian.org
Processed: block 653871 with 658549
Processing commands for cont...@bugs.debian.org: > block 653871 with 658549 Bug #653871 [release.debian.org] transition: libzip Was not blocked by any bugs. Added blocking bug(s) of 653871: 658549 > thanks Stopping processing here. Please contact me if you need assistance. -- 653871: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653871 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.132830994628506.transcr...@bugs.debian.org
Re: RFS: libconfig (requires transition)
On Mon, Jan 30, 2012 at 23:08:17 +, Jonathan McCrohan wrote: > This is my first upload which requires a transition, and I am unsure > of what happens next. It seems common for packages to be uploaded to > experimental for a time prior to the actual transistion to allow other > maintainers update their packages accordingly. I was wondering will > this be the case with this transition? > For the record, we talked on irc, and Jonathan will upload a new version with the -dev package changed to experimental, so reverse deps can be tested against that. Cheers, Julien signature.asc Description: Digital signature
Bug#648775: marked as done (transition: mono 2.10)
Your message dated Fri, 03 Feb 2012 22:11:32 + with message-id <1328307092.2771.2.ca...@jacala.jungle.funky-badger.org> and subject line Re: Bug#648775: Mono 2.10 Transition has started (was Re: Bug#648775: transition: mono 2.10) has caused the Debian Bug report #648775, regarding transition: mono 2.10 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.) -- 648775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648775 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: transition Dear Release Team, [ re-filing as a bug per jcristau ] We'd like to start the Mono transition[0,0.5] soon. The packages have been aged in experimental for some time now, and this transition has also taken place in Another Place with no notable badness. Following the RT's request for a dry run (Model 3 in [0.5]), Julian Taylor did a test rebuild[1] of all rdepends and to the best of our knowledge we have resolved the outstanding issues so that all that should be required are no-change rebuilds or uploads from experimental to unstable, as well as one removal of a package not yet ported (dlr-languages). Roughly, the plan will be * Upload all of mono & cli-common from experimental to unstable * Upload build tools (nant) * Remove mono-debugger * Get LO bindings disabled * No-change rebuild / binNMU all applications against the 4.0 profile * No-change rebuild / binNMU all libraries against the 4.0 profile, in leaf-first order The reason for this ordering is because 4.0 executables can load 2.0 libraries but not vice-versa. A great deal of packages are pure managed code, so arch:all and will therefore require sourceful uploads. You can see the results of our testing at [2]. Please let us know when we can go ahead. Cheers, on behalf of the Debian Mono Group, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] [0] http://release.debian.org/transitions/html/mono.html [0.5] http://wiki.debian.org/Teams/DebianMonoGroup/Mono210Transition [1] http://alioth.debian.org/~jtaylor-guest/logs/ [2] http://wiki.debian.org/Teams/DebianMonoGroup/Mono210TransitionTODO --- End Message --- --- Begin Message --- On Mon, 2012-01-30 at 12:57 +, Adam D. Barratt wrote: > On 16.01.2012 06:33, Mirco Bauer wrote: > > Alright, I have uploaded Mono 2.10.5-2 and cli-common 0.8 to > > unstable. This officially starts the Mono 2.10 transition in Debian > > I mentioned most of the below on #debian-release over the weekend, but > thought it might be easier to document it in the transition bug as well. > From a base of this morning's britney result, with a bunch of urgents > and a force-hint applied, the end result of attempting to get the > transition done now appears to be that the following packages have > issues: [...] > * s390: >- libvirtuoso5.5-cil > - virtuoso-opensource needs to stop building CIL packages on s390; > #657781 Jo's NMU for this is still pending, so this is indeed broken for a short time. In the meantime: mono | 2.10.5-2 | testing | source I think we can call this done, and let the slides be basically truthful. ;-) Regards, Adam --- End Message ---
Bug#653195: transition: libarchive
I haven't seen any activity with evolution 3.2 / libgdata 0.10 transition. Should the transition of libarchive still wait? -- ~ Andres -- 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/CAPM41nP7kLupjZMi++eadA4cLHp66+W=vv6gk2z78xxpo50...@mail.gmail.com
Processed: your mail
Processing commands for cont...@bugs.debian.org: > submitter 653195 ! Bug #653195 [release.debian.org] transition: libarchive Changed Bug submitter to 'Andres Mejia ' from 'Andres Mejia ' > End of message, stopping processing here. Please contact me if you need assistance. -- 653195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653195 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.132830452324732.transcr...@bugs.debian.org
Proposed update for ecl package
[Please CC, not subscribed to debian-release.] Hi, I would like to propose following changes for ecl package in Squeeze, please have a look at the attached debdiff. -- Regards, Aron Xu diff -u ecl-9.6.1/debian/changelog ecl-9.6.1/debian/changelog --- ecl-9.6.1/debian/changelog +++ ecl-9.6.1/debian/changelog @@ -1,3 +1,14 @@ +ecl (9.6.1-1squeeze2) stable; urgency=low + + * Team upload for stable release update. + * debian/postrm: removed. +We introduced this scripted when using clc, but since it's gone +since Squeeze, the script will remove /usr/bin/ecl during +upgrade, renders the package not usable for any user upgrading +from older version. (Closes: #613484). + + -- Aron Xu Sat, 04 Feb 2012 01:34:41 +0800 + ecl (9.6.1-1squeeze1) testing; urgency=low * Non-maintainer upload. reverted: --- ecl-9.6.1/debian/postrm +++ ecl-9.6.1.orig/debian/postrm @@ -1,36 +0,0 @@ -#! /bin/sh -# postrm script for series -# -# see: dh_installdeb(1) - -set -e - -# summary of how this script can be called: -#* `remove' -#* `purge' -#* `upgrade' -#* `failed-upgrade' -#* `abort-install' -#* `abort-install' -#* `abort-upgrade' -#* `disappear' overwrit>r> -# for details, see /usr/share/doc/packaging-manual/ - -case "$1" in - purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) -rm /usr/bin/ecl 2> /dev/null || true -rm /usr/lib/ecl/*.o 2> /dev/null || true -;; - -*) -echo "postrm called with unknown argument \`$1'" >&2 -exit 0 - -esac - -# dh_installdeb will replace this with shell code automatically -# generated by other debhelper scripts. - -#DEBHELPER# - - signature.asc Description: Digital signature
Bug#657288: transition: gdcm
On 02.02.2012 20:55, Mathieu Malaterre wrote: On Thu, Feb 2, 2012 at 9:13 PM, Adam D. Barratt wrote: On Wed, 2012-01-25 at 11:13 +0100, Mathieu Malaterre wrote: GDCM 2.2.0 introduces a new ABI, as seen on #655783 and al. Since API (whatever that means for C++) is preserved, would it be a good time to - move gdcm 2.2.0 from experimental to unstable Apparently the lack of an explicit "no" - having waited less than a week - was taken as an implicit "yes". That's unfortunate, given that it means that the gdcm transition is now tied together with the mono transition which we were very close to finishing. [...] I completely understand your point and I will not upload any new gdcm. In any case if you decide to revert to gdcm 2.0 watch very carefully for #657288 since it introduce a change in the API without any SONAME bump. Thanks. I suspect that's not the bug number you intended to reference though. I initially made the very first upload of gdcm 2.2 because of #657779, which I thought would help in the mono transition. Fixing the bug helped, yes. The SONAME bump not so much. :-) I choose to upload directly 2.2.0 (vs a gdcm 2.0.19) since it clearly state the SONAME bump and I assume this would make the life of everybody else much easier. In particular I assumed having gdcm 2.2 would help the ITK4 transition, also debated on debian-release [1]. It may make ITK4 easier; we'll see. What it looks like we'll end up doing is pushing the new gdcm in to testing much earlier than we normally would, to get the mono transition finished; britney allows us to keep the shared libraries for both 2.0 and 2.2 in testing while we sort out the reverse-dependencies. We'll then look at finishing off the gdcm transition. 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/156abc65387928c2eed7381c70626...@mail.adsl.funky-badger.org