Bug#789864: transition: libgdata22
Am 25.06.2015 um 03:10 schrieb Emilio Pozuelo Monfort: Control: tags -1 confirmed On 25/06/15 01:16, Michael Biebl wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a slot for a small transition. libgdata bumped the soname from 19 → 22. The new package is available in experimental and built everywhere. I've rebuilt all rdeps, and I didn't get any build failures, so only a round of binNMUs should be necessary. If there is no conflict with another ongoing transition, it should be good to go. You can go ahead. Thanks Emilio. libgdata is uploaded and has been built everywhere (aside from sparc and hurd). So you can schedule the binNMUs now. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#789365: transition: ghc-7.8
On 24/06/15 16:12, Joachim Breitner wrote: Hi, Am Dienstag, den 23.06.2015, 15:05 +0200 schrieb Joachim Breitner: * leksah ought to be removed from testing: https://bugs.debian.org/789521 ✓ These two migrated back as there's no RC bug on them. I've re-added the removal hint, but please file a bug. gitit aged, and the ppc64el binNMUs are now done. This should go in tonight if nothing else pops up. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bd627.9020...@debian.org
Bug#787668: transition: qtbase-opensource-src
Hi! The following qtconnectivity-opensource-src's packages will not longer build on !linux due to bluez not being available there: libqt5bluetooth5, libqt5nfc5, qml-module-qtbluetooth, qml-module-qtnfc, qtconnectivity5-dbg, qtconnectivity5-dev, qtconnectivity5-examples Should I file a bug to ftp masters to get them removed from testing or is something you also manage yourselfs? Thanks in advance, Lisandro. -- Combata las características. Si una característica no es absolutamente esencial, descártela, especialmente si tiene el mismo efecto que se puede alcanzar mediante la combinación de otras características. Andrew S. Tanenbaum, de su libro Computer Networks Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#787668: transition: qtbase-opensource-src
Hola Lisandro, On 25/06/15 14:56, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! The following qtconnectivity-opensource-src's packages will not longer build on !linux due to bluez not being available there: libqt5bluetooth5, libqt5nfc5, qml-module-qtbluetooth, qml-module-qtnfc, qtconnectivity5-dbg, qtconnectivity5-dev, qtconnectivity5-examples Should I file a bug to ftp masters to get them removed from testing or is something you also manage yourselfs? Neither kfreebsd nor hurd are in testing, so that doesn't matter for migration purposes. However, if the packages are never going to be built again, you probably want them removed from unstable. For that, file an RM bug against ftp.debian.org specifying the architectures they should be removed from. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c0649.1000...@debian.org
Bug#789077: ruby2.2 transition: binNMUs round 3
On 25/06/15 15:00, Antonio Terceiro wrote: Hi, These packages used to FTBFS, but will now build fine with the new version of gem2deb in unstable. Please binNMU them: ruby-fast-stemmer ruby-blockenspiel ruby-fast-xs ruby-levenshtein raspell ruby-rdiscount ruby-hiredis ruby-rinku ruby-fftw3 ruby-github-markdown ruby-rjb ruby-multibitnums ruby-password ruby-raindrops ruby-rpatricia ruby-gsl ruby-kgio All scheduled. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c07e8.2070...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: Thanks for the report. I have looked at the wiki page, but it's not entirely clear to me how the libstdc++ transition will go, so I have a few questions to better understand it. - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). - Will those libraries need to migrate all at the same time with libstdc++, or could libstdc++/gcc-5 migrate first, and then the libraries can slowly migrate independently? libstdc++/gcc-5 can migrate first (and it already is). the dual ABI build only adds an ABI, doesn't remove one). Depending on which packages really depend on catching the std::system_error exception, and adding these to libstdc++6:Breaks, you have a small set which may need transitioning at the same time. I was talking with the boost maintainers to do a boost version bump at the same time. My main concern with all this is if we'll have a huge transition with lots of libraries been renamed and having to migrate at the same time with their rdeps. yes, but I can't see a good way around it. What I heard from other distros is that they handle this just with a rebuild. Of course Debian can do this as well, but it probably will make partial upgrades not working. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558be3f9.6000...@debian.org
Bug#789077: ruby2.2 transition: binNMUs round 3
Hi, These packages used to FTBFS, but will now build fine with the new version of gem2deb in unstable. Please binNMU them: ruby-fast-stemmer ruby-blockenspiel ruby-fast-xs ruby-levenshtein raspell ruby-rdiscount ruby-hiredis ruby-rinku ruby-fftw3 ruby-github-markdown ruby-rjb ruby-multibitnums ruby-password ruby-raindrops ruby-rpatricia ruby-gsl ruby-kgio -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Bug#789869: marked as done (nmu: spark_2012.0.deb-9)
Your message dated Thu, 25 Jun 2015 11:45:31 +0200 with message-id 558bcdbb.9050...@debian.org and subject line Re: Bug#789869: nmu: spark_2012.0.deb-9 has caused the Debian Bug report #789869, regarding nmu: spark_2012.0.deb-9 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.) -- 789869: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789869 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu spark_2012.0.deb-9 . ALL . -m Rebuild against swi-prolog 7.2.0 looks like swi-prolog started a small transition, the virtual package swi-prolog-vm-2 was bumped to swi-prolog-vm-3. The autotracker does not seem to catch such changes ... Andreas ---End Message--- ---BeginMessage--- On 25/06/15 02:12, Andreas Beckmann wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu spark_2012.0.deb-9 . ALL . -m Rebuild against swi-prolog 7.2.0 looks like swi-prolog started a small transition, the virtual package swi-prolog-vm-2 was bumped to swi-prolog-vm-3. The autotracker does not seem to catch such changes ... swi-prolog had failed on mipsel. Gave it back and it built fine. spark binNMUed, thanks for noticing. Cheers, Emilio---End Message---
Re: preparing for GCC 5, especially libstdc++6
On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c21dd.2070...@debian.org
Bug#787668: transition: qtbase-opensource-src
On 25/06/15 18:45, Lisandro Damián Nicanor Pérez Meyer wrote: We are ready to binNMU gammaray and musescore. Done. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c3120.5050...@debian.org
Bug#787668: transition: qtbase-opensource-src
We are ready to binNMU gammaray and musescore. qtcreator shpuld receive a source upload soon, pyqt5 is building and we need pyqt5 done in order to binNMU calibre. -- perezmeyer: Gus no tiene inet :-( PabloOdorico: oh perezmeyer: te mando una copia de lo que hagamos esta noche PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#787668: transition: qtbase-opensource-src
On Thursday 25 June 2015 23:20:45 Lisandro Damián Nicanor Pérez Meyer wrote: Just because IRC is not the official way of doing this: we are ready to binNMU calibre. Which you already did. You are wonderfull :) -- Ud. está viendo a la persona que ven nuestros clientes. Leyenda pegada en el espejo de una empresa. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#787668: transition: qtbase-opensource-src
Just because IRC is not the official way of doing this: we are ready to binNMU calibre. -- ...man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons. Douglas Adams, The hitchhikers' guide to the galaxy Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: preparing for GCC 5, especially libstdc++6
On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558ca482.3090...@debian.org
Bug#789365: marked as done (transition: ghc-7.8)
Your message dated Fri, 26 Jun 2015 02:56:05 +0200 with message-id 558ca325.6030...@debian.org and subject line Re: Bug#789365: transition: ghc-7.8 has caused the Debian Bug report #789365, regarding transition: ghc-7.8 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.) -- 789365: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789365 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear release team, we (the Debian Haskell Group) has been working hard to get everything in order for GHC 7.8 to migrate to testing (and top open the way for 7.10 in unstable :-)). We have had regular status reports on the haskell mailing list. Now we are getting close enough for the migration to happen that I believe we should include you in status updates and notifications, and also because you can probably help. Please CC debian-hask...@lists.debian.org in mails to this bug, to keep everyone up-to-date. - From what I can tell, there are these blockers: * Packages in NEW Mostly gitit, which has an added binary file: https://ftp-master.debian.org/new/gitit_0.10.7-1.html The other two haskell packages in NEW do not seem to be testing relevant, so this is looking good. * Package removals There are a large number of Haskell package removales scheduled for unstable, but most of them are stalled, as there are still old binaries and sources depending on these packages. This is mostly due to sparc not keeping up, which is mostly due to nettle not building there: http://bugs.debian.org/789013 I’m not sure what to best do here. Since sparc is not a release architecture, this should not hold up the release, but technically it does. Maybe the removals can be added as hints to britney? Will that interact properly with the auto-hinter? * leksah Despite multiple calls on the mailing list, no contributor was willing and able to fix that package in reasonable time. I suggest you remove haskell-leksah and haskell-leksah-server from testing (on the grounds that the maintenance situation makes it not suitable for a Debian stable release). This should unblock this situation. * shake not building on powerpc This is a weird issue: https://lists.debian.org/debian-haskell/2015/06/msg00043.html As this is an almost leave package, I suggest to remove haskell-shake and haskell-hoogle on powerpc for now, and hence disentangle this problem from the transition. I’m still looking for volunteers to investigate this issue. * Other out of date packages, mostly mips and mipsel I keep watching https://release.debian.org/transitions/html/haskell.html and I believe most problems are solved there. When today's upload and binNMUs have built everywhere there might be a package or two which no longer build on mips/mipsel (due to lack of TemplateHaskell support) and can be solved by a removal on these architectures. * Some packages need to age As usual. Is there a way for you, or better, me, to see if this list is exhaustive? Some kind of „what if when“ britney run where I can feed some removals and age-override hints and see what the auto-hinter+britney does? Thanks, Joachim - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-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 Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlWFP1EACgkQ9ijrk0dDIGwGRwCfadFimFcT8DQDlLWLOyYOQyI7 WKsAoKbqayqfnth3z5DWcvgRx3gnNGSP =OBHB -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- On 25/06/15 12:21, Emilio Pozuelo Monfort wrote: On 24/06/15 16:12, Joachim Breitner wrote: Hi, Am Dienstag, den 23.06.2015, 15:05 +0200 schrieb Joachim Breitner: * leksah ought to be removed from testing: https://bugs.debian.org/789521 ✓ These two migrated back as there's no RC bug on them. I've re-added the removal hint, but please file a bug. gitit aged, and the ppc64el binNMUs are now done. This should go in tonight if nothing else pops up. And it did: ghc| 7.8.4-9 | testing | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x Cheers, Emilio---End Message---
Bug#789864: transition: libgdata22
On 25/06/15 22:53, Michael Biebl wrote: Am 25.06.2015 um 03:10 schrieb Emilio Pozuelo Monfort: Control: tags -1 confirmed On 25/06/15 01:16, Michael Biebl wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a slot for a small transition. libgdata bumped the soname from 19 → 22. The new package is available in experimental and built everywhere. I've rebuilt all rdeps, and I didn't get any build failures, so only a round of binNMUs should be necessary. If there is no conflict with another ongoing transition, it should be good to go. You can go ahead. Thanks Emilio. libgdata is uploaded and has been built everywhere (aside from sparc and hurd). So you can schedule the binNMUs now. Done. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558ca40e.6000...@debian.org
Bug#789365: Re: Bug#789365: transition: ghc-7.8
This may need a binNMU: haskell-trifecta (1.4.3-1 to 1.5.1.3-4) Maintainer: Debian Haskell Group 9 days old (needed 5 days) libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-charset-dev-0.3.7.1-1690c libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-comonad-dev-4.2.5-c2e64 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-lens-dev-4.6.0.1-21811 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-reducers-dev-3.10.3.1-db618 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-semigroups-dev-0.15.3-77447 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-charset-prof-0.3.7.1-1690c libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-comonad-prof-4.2.5-c2e64 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-lens-prof-4.6.0.1-21811 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-reducers-prof-3.10.3.1-db618 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-semigroups-prof-0.15.3-77447 It looks like a binnmu for haskell-trifecta has already been scheduled on ppc64el but it's in BD-Uninstallable. haskell-trifecta build-depends on: - ppc64el:libghc-parsers-dev (= 0.12.1) ppc64el:libghc-parsers-dev depends on missing: - ppc64el:libghc-charset-dev-0.3.7.1-1690c It looks like haskell-parsers was not binnmud on ppc64el when it was binnmud on other architectures for a new version of haskell-charset. Checking dose.debian.net it appears it's build-depends are also uninstallable (though this information may be out of date). https://qa.debian.org/dose/debcheck/src_unstable_main/1435122003/packages/haskell-parsers.html#8fad47a6199cea33228738dfa0983c1c src:haskell-parsers (0.12.1.1-3) [PTS] [ctrl] ? libghc-charset-dev (= 0.3) libghc-charset-dev (0.3.7.1-2+b1) [PTS] [ctrl] ? libghc-semigroups-dev-0.15.3-77447 MISSING Checking haskell-charset it appears it has been binnmu'd for the new semigroups on all architectures but the ppc64el build was built much later than the others.
Bug#789133: transition: ocaml 4.02.2
Le 23/06/2015 23:45, Eric Cooper a écrit : I've updated approx to version 5.5-2 to fix the build failure due to deprecation of String.create in 4.02. Thank you. So I'd appreciate it if someone could build it from the master branch of git.debian.org/git/pkg-ocaml-maint/packages/approx.git and upload it. Done. BTW, I still believe -warn-error is good engineering practice, even though it's inconvenient during transitions like this. So rather than turn it off completely, I turned off only the warning due to deprecated features. It might be good for development or continuous integration, where upstream is in charge of fixing things. But for software uploaded to Debian, I don't think it's the Debian maintainer's job to fix all new warnings a package may trigger. That's why I think -warn-error (especially -warn-error A) should not be used in released software. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558b98fd.4040...@debian.org
Re: ppc64el missing on https://release.debian.org/transitions/
On 25/06/15 10:00, Joachim Breitner wrote: Hi, especially Mehdi, subject says it all: Is there a good reason ppc64el is not tracked on https://release.debian.org/transitions/html/haskell.html ? (I missed the pending problem about trifecta because of that.) The haskell ben file was overriding the list of architectures, and that was outdated. arm64 was also missing, and s390 was still listed. Instead of fixing those, I've just removed the architectures override so that the tracker uses our default architectures from the global ben config. Looks like haskell-parsers also has problems on ppc64el. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bbcaa.8090...@debian.org
Bug#789365: transition: ghc-7.8
Hi, Am Donnerstag, den 25.06.2015, 02:53 +0200 schrieb Emilio Pozuelo Monfort: This may need a binNMU: haskell-trifecta (1.4.3-1 to 1.5.1.3-4) Maintainer: Debian Haskell Group 9 days old (needed 5 days) libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-charset-dev-0.3.7.1-1690c libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-comonad-dev-4.2.5-c2e64 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-lens-dev-4.6.0.1-21811 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-reducers-dev-3.10.3.1-db618 libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-semigroups-dev-0.15.3-77447 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-charset-prof-0.3.7.1-1690c libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-comonad-prof-4.2.5-c2e64 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-lens-prof-4.6.0.1-21811 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-reducers-prof-3.10.3.1-db618 libghc-trifecta-prof/ppc64el unsatisfiable Depends: libghc-semigroups-prof-0.15.3-77447 it had a binNMU waiting, but a binNMU on haskell-parsers was required to unblock this. Done. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
ppc64el missing on https://release.debian.org/transitions/
Hi, especially Mehdi, subject says it all: Is there a good reason ppc64el is not tracked on https://release.debian.org/transitions/html/haskell.html ? (I missed the pending problem about trifecta because of that.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: preparing for GCC 5, especially libstdc++6
On 16/06/15 23:37, Matthias Klose wrote: Hi, it's time to prepare for GCC 5 as the default compiler in unstable. Compared to earlier version bumps, the switch to GCC 5 is a bit more complicated because libstdc++6 sees a few ABI incompatibilities, partially depending on the C++ standard version used for the builds. libstdc++6 will support two ABI's, the classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI (currently enabled in experimental as the default ABI). - the majority of packages using c++98 or earlier c++ standards should just continue to work. - In GCC 4.9 and earlier versions the libstdc++6 C++11 support was still marked as experimental, and upstream doesn't (and didn't in the past) guarantee c++11 ABI compatibility across major GCC versions. It worked somehow ok in the past, however it won't this time. - some c++98 code won't work when parts are built using GCC 4.9, and some parts with GCC 5 (see PR66145 upstream). Unfortunately due to PR66145 we already have an incompatible libstdc++6 (at least for some packages) in testing/unstable, which was only seen after the first packages were rebuilt and issues like #784655 were reported. My goal is to make the GCC version bump in early July, and use the time until then to prepare libstdc++6 depending packages to get ready for GCC 5, and avoiding version bumps for C++ libraries until this time. Details for the whole transition are outlined in https://wiki.debian.org/GCC5 I'd appreciate feedback for this plan, clarify the wiki page, and would like to post a finalized plan next week to d-d-a, and file appropriate transition bugs next week. Hi Matthias, Thanks for the report. I have looked at the wiki page, but it's not entirely clear to me how the libstdc++ transition will go, so I have a few questions to better understand it. - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? - Will those libraries need to migrate all at the same time with libstdc++, or could libstdc++/gcc-5 migrate first, and then the libraries can slowly migrate independently? My main concern with all this is if we'll have a huge transition with lots of libraries been renamed and having to migrate at the same time with their rdeps. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bc883.1060...@debian.org
Bug#789133: transition: ocaml 4.02.2
On 22/06/15 19:15, Stéphane Glondu wrote: Le 22/06/2015 15:59, Emilio Pozuelo Monfort a écrit : Or if you can give a more detailed explanation of what will happen after ocaml is uploaded, binNMUs are scheduled, and we have ~30 packages that are holding the transition. I say we remove them from testing. dak rm -Rn -s testing shows that all missing packages + ceve gnudatalanguage nbdkit psfex scamp can be removed from testing together. Tbh I'm not thrilled about removing that many packages, but given most of them are maintained by the ocaml team, I may be alright with it. It'd be good to reduce the number as much as possible though. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bcaee.6060...@debian.org
Bug#789876: marked as done (nmu: leftovers from libplist, libvncserver, nettle transitions in experimental)
Your message dated Thu, 25 Jun 2015 10:37:21 +0200 with message-id 558bbdc1.8080...@debian.org and subject line Re: Bug#789876: nmu: leftovers from libplist, libvncserver, nettle transitions in experimental has caused the Debian Bug report #789876, regarding nmu: leftovers from libplist, libvncserver, nettle transitions in experimental 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.) -- 789876: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789876 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal Tags: experimental User: release.debian@packages.debian.org Usertags: binnmu Some leftovers in experimental from transitions that are completed in sid: nmu libgpod_0.8.3-4 . ALL . experimental . -m Rebuild against libplist 1.12 nmu libimobiledevice_1.2.0+dfsg-1 . experimental . -m Rebuild against libplist 1.12 nmu libusbmuxd_1.0.10-1 . experimental . -m Rebuild against libplist 1.12 nmu usbmuxd_1.1.0-1 . experimental . -m Rebuild against libplist 1.12 nmu krdc_4:14.12.2-1 . experimental . -m Rebuild against libvncserver 0.9.10. nmu krfb_4:14.12.3-1 . experimental . -m Rebuild against libvncserver 0.9.10. nmu knot_1.99.1-1 . experimental . -m Rebuild against nettle 3.1.1 Andreas ---End Message--- ---BeginMessage--- On 25/06/15 03:11, Andreas Beckmann wrote: Package: release.debian.org Severity: normal Tags: experimental User: release.debian@packages.debian.org Usertags: binnmu Some leftovers in experimental from transitions that are completed in sid: nmu libgpod_0.8.3-4 . ALL . experimental . -m Rebuild against libplist 1.12 nmu libimobiledevice_1.2.0+dfsg-1 . experimental . -m Rebuild against libplist 1.12 nmu libusbmuxd_1.0.10-1 . experimental . -m Rebuild against libplist 1.12 nmu usbmuxd_1.1.0-1 . experimental . -m Rebuild against libplist 1.12 nmu krdc_4:14.12.2-1 . experimental . -m Rebuild against libvncserver 0.9.10. nmu krfb_4:14.12.3-1 . experimental . -m Rebuild against libvncserver 0.9.10. nmu knot_1.99.1-1 . experimental . -m Rebuild against nettle 3.1.1 You're missing the architecture list from most commands. All done, thanks for this. Emilio---End Message---
