Bug#570488: RM: ocaml-batteries/0.20090405+beta1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello, Please remove ocaml-batteries from testing. It currently fails to build from source (#569455). Although this is easily fixed, upstream project leader has changed, and so did other aspects of this project. There is a new upstream release being working on. But we don't want the version currently in testing to be released. Thanks in advance, -- Stéphane -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (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/20100219085735.6731.69565.report...@korell.glondu.net
Re: Bug#570346: nmu: gnucash_2.2.9-4
Hi, Am Donnerstag, den 18.02.2010, 23:22 + schrieb Adam D. Barratt: > On Thu, 2010-02-18 at 23:58 +0100, Joachim Breitner wrote: > > Am Donnerstag, den 18.02.2010, 12:58 +0100 schrieb Marc 'HE' Brockschmidt: > > > Micha Lenk writes: > > > > nmu gnucash_2.2.9-4 . ALL . -m "Rebuilt against libgoffice-0.8 to > > > > account for uncoordinated soname bump (closes: #570152)" > [...] > > > I've scheduled binNMUs for all r-deps of goffice that haven't been > > > rebuild since its last upload: > > > abiword gnucash nip2 > > > > maybe you did not fetch all, the amd64 package of gnucash, version > > 2.2.9-4, is also broken and needs a rebuild. > > That rebuild was indeed scheduled earlier today; gnucash_2.2.9-4+b1 on > amd64 depends on "libgoffice-0-8 (>= 0.8.0)" and was installed in to the > archive during the 19:52 dinstall tonight. ok, then maybe something is broken with https://buildd.debian.org/status/package.php?p=gnucash because only 2.2.9-4 is listed for amd64? 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: Dies ist ein digital signierter Nachrichtenteil
Bug#570488: marked as done (RM: ocaml-batteries/0.20090405+beta1-5)
Your message dated Fri, 19 Feb 2010 11:29:03 + with message-id <1266578943.5435.5139.ca...@kaa.jungle.aubergine.my-net-space.net> and subject line Re: Bug#570488: RM: ocaml-batteries/0.20090405+beta1-5 has caused the Debian Bug report #570488, regarding RM: ocaml-batteries/0.20090405+beta1-5 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.) -- 570488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570488 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: rm Hello, Please remove ocaml-batteries from testing. It currently fails to build from source (#569455). Although this is easily fixed, upstream project leader has changed, and so did other aspects of this project. There is a new upstream release being working on. But we don't want the version currently in testing to be released. Thanks in advance, -- Stéphane -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Fri, 2010-02-19 at 09:57 +0100, Stéphane Glondu wrote: > Please remove ocaml-batteries from testing. It currently fails to > build from source (#569455). Although this is easily fixed, upstream > project leader has changed, and so did other aspects of this project. > > There is a new upstream release being working on. But we don't want > the version currently in testing to be released. Removal hint added. Regards, Adam --- End Message ---
Re: Bug#570346: nmu: gnucash_2.2.9-4
Hi, On Fri, 2010-02-19 at 12:25 +0100, Joachim Breitner wrote: > Am Donnerstag, den 18.02.2010, 23:22 + schrieb Adam D. Barratt: > > On Thu, 2010-02-18 at 23:58 +0100, Joachim Breitner wrote: > > > maybe you did not fetch all, the amd64 package of gnucash, version > > > 2.2.9-4, is also broken and needs a rebuild. > > > > That rebuild was indeed scheduled earlier today; gnucash_2.2.9-4+b1 on > > amd64 depends on "libgoffice-0-8 (>= 0.8.0)" and was installed in to the > > archive during the 19:52 dinstall tonight. > > ok, then maybe something is broken with > https://buildd.debian.org/status/package.php?p=gnucash > because only 2.2.9-4 is listed for amd64? It's a feature. Both /status/package.php and /pkg.cgi only display binNMUs until they're uploaded, and then revert to the source version. This is a side-effect of the fact that wanna-build only stores the binNMU information during the time between the binNMU being scheduled and it being uploaded; the wanna-build commands used to build the pages therefore only output references to the binNMU version during that time. https://buildd.debian.org/build.cgi?pkg=gnucash shows logs for all versions of the package, including binNMUs. 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/1266579742.5435.5238.ca...@kaa.jungle.aubergine.my-net-space.net
HPPA and Erlang packages
Hi release managers! I'd like to ask you about what to do with Erlang and its reverse dependencies on hppa architecture. The problem is that there's a bug with fork()+exec() which makes erlang FTBFS (and the currently built packages are broken as well) on hppa (see [1], [2]). It seems to be very complicated (as it's known and hasn't been fixed for about a three months) and prevents new Erlang packages migration to testing. So, what to do with Erlang in testing and unstable? I'd prefer to remove erlang and its reverse dependencies from both testing and unstable for hppa architecture (all the packages don't work anyway, and nobody uses them, given that there's no bugreports). After the bug will be fixed, all the packages will be eventually rebuilt. [1] http://lists.debian.org/debian-hppa/2009/12/msg00035.html [2] http://article.gmane.org/gmane.linux.ports.parisc/2403 Cheers! -- Sergei Golovan -- 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/f60b7eb61002190427g2aee0658p685d94ace2462...@mail.gmail.com
Re: Bug#570346: nmu: gnucash_2.2.9-4
Hi, Am Freitag, den 19.02.2010, 11:42 + schrieb Adam D. Barratt: > > ok, then maybe something is broken with > > https://buildd.debian.org/status/package.php?p=gnucash > > because only 2.2.9-4 is listed for amd64? > > It's a feature. > > Both /status/package.php and /pkg.cgi only display binNMUs until they're > uploaded, and then revert to the source version. This is a side-effect > of the fact that wanna-build only stores the binNMU information during > the time between the binNMU being scheduled and it being uploaded; the > wanna-build commands used to build the pages therefore only output > references to the binNMU version during that time. > > https://buildd.debian.org/build.cgi?pkg=gnucash shows logs for all > versions of the package, including binNMUs. hmm, thanks for the information. This is a recent change, isn’t it? Is the information reverted when package is uploaded, or when it’s installed? I.e. is there a time frame where I would not know about a binNMUed package from either the archive or the wanna-build dump? /me finds this all very confusing, especially WRT to handling binNMU campaigns. I was about to check whether https://buildd.debian.org/stats/amd64-dump.txt.gz also lacks the binNMU data, but it seems like that file has not been updated since somewhen in January. Will that file be available eventually? Thanks, 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: Dies ist ein digital signierter Nachrichtenteil
Bug#570512: https://buildd.debian.org/stats/ not updated
Package: release.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, it seems that https://buildd.debian.org/stats/ is not updated any more since about January. It would be nice to get those dumps working again. Thanks, Joachim - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkt+k7IACgkQ9ijrk0dDIGzg5wCgpqfRNKhjhjKzffCFGdFCzaQ0 UtEAniNkT7CtIgWWv5wFrTqWzxRBX70L =zrA1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100219133546.4806.49519.report...@kirk.ehbuehl.net
Processed: Re: Bug#570512: https://buildd.debian.org/stats/ not updated
Processing commands for cont...@bugs.debian.org: > reassign 570512 buildd.debian.org Bug #570512 [release.debian.org] https://buildd.debian.org/stats/ not updated Bug reassigned from package 'release.debian.org' to 'buildd.debian.org'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- 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.12665881246649.transcr...@bugs.debian.org
Bug#570512: https://buildd.debian.org/stats/ not updated
reassign 570512 buildd.debian.org thanks Hi, On Fri, 2010-02-19 at 14:35 +0100, Joachim Breitner wrote: > it seems that https://buildd.debian.org/stats/ is not updated any more > since about January. It would be nice to get those dumps working again. The stats are handled by the buildd team; reassigning. Cheers, 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/1266588120.17524.23.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Bug#570346: nmu: gnucash_2.2.9-4
[This was answered on IRC, but for completeness...] On Fri, 2010-02-19 at 13:58 +0100, Joachim Breitner wrote: > Am Freitag, den 19.02.2010, 11:42 + schrieb Adam D. Barratt: > > > ok, then maybe something is broken with > > > https://buildd.debian.org/status/package.php?p=gnucash > > > because only 2.2.9-4 is listed for amd64? > > > > It's a feature. > > > > Both /status/package.php and /pkg.cgi only display binNMUs until they're > > uploaded, and then revert to the source version. This is a side-effect > > of the fact that wanna-build only stores the binNMU information during > > the time between the binNMU being scheduled and it being uploaded; the > > wanna-build commands used to build the pages therefore only output > > references to the binNMU version during that time. > > > > https://buildd.debian.org/build.cgi?pkg=gnucash shows logs for all > > versions of the package, including binNMUs. > > hmm, thanks for the information. This is a recent change, isn’t it? It's certainly been the behaviour for as long as I can remember. > Is the information reverted when package is uploaded, or when it’s > installed? I.e. is there a time frame where I would not know about a > binNMUed package from either the archive or the wanna-build dump? The binNMU information is removed when the package is installed. To be precise, when wanna-build processes a Packages file which contains either the binNMU or a newer version. (It's also removed when the package is marked not-for-us and in a few other circumstances but none of those affect the Uploaded / Installed boundary afaics). > /me finds this all very confusing, especially WRT to handling binNMU > campaigns. > > I was about to check whether > https://buildd.debian.org/stats/amd64-dump.txt.gz > also lacks the binNMU data, but it seems like that file has not been > updated since somewhen in January. Will that file be available > eventually? This is now #570512. 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/1266588422.17524.64.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#570462: marked as done (nmu: second round for the php5 transition)
Your message dated Fri, 19 Feb 2010 20:17:09 +0100 with message-id <87aav5doi2@solon.marcbrockschmidt.de> and subject line Re: Bug#570462: nmu: second round for the php5 transition has caused the Debian Bug report #570462, regarding nmu: second round for the php5 transition 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.) -- 570462: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570462 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 Hi, Please schedule the following binNMUs: nmu xcache wikidiff2 . alpha hppa armel mips ia64 powerpc mipsel sparc . -m "Rebuild against PHP 5.3" dw xcache wikidiff2 . alpha hppa armel mips ia64 powerpc mipsel sparc . -m "php5-dev (>= 5.3.1-3)" nmu ffmpeg-php graphviz . alpha armel mips mipsel ia64 powerpc sparc . -m "Rebuild against PHP 5.3" dw ffmpeg-php graphviz . alpha armel mips mipsel ia64 powerpc sparc . -m "php5-dev (>= 5.3.1-3)" nmu ossp-uuid . armel mips mipsel sparc . -m "Rebuild against PHP 5.3" dw ossp-uuid . armel mips mipsel sparc . -m "php5-dev (>= 5.3.1-3)" nmu xapian-bindings . mips mipsel sparc . -m "Rebuild against PHP 5.3" dw xapian-bindings . mips mipsel sparc . -m "php5-dev (>= 5.3.1-3)" nmu mapserver ming sqlrelay php-imagick . ALL . -m "Rebuild against PHP 5.3" dw mapserver ming sqlrelay php-imagick . ALL . -m "php5-dev (>= 5.3.1-3)" The php-ps binNMU FTBFS on powerpc due to a libtiff.a error. Please give it back if it has been fixed already. And that should be it. There are still some packages that need to be updated because they FTBFS because of the (not-so-)new API: php-adodb (mine, will try to fix it during the WE), php-ssh2, php-imlib, zeroc-ice, php-clamav, php-apc. Another upload of php5 will follow as soon as the current version is built and installed on mips* (so that the binNMUs can be built there), to fix the RC bug affecting parallel building and possibly some regressions. Should that new Debian revision be uploaded with urgency=medium? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net signature.asc Description: This is a digitally signed message part. --- End Message --- --- Begin Message --- Raphael Geissert writes: > nmu xcache wikidiff2 . alpha hppa armel mips ia64 powerpc mipsel sparc . -m > "Rebuild against PHP 5.3" > dw xcache wikidiff2 . alpha hppa armel mips ia64 powerpc mipsel sparc . -m > "php5-dev (>= 5.3.1-3)" > > nmu ffmpeg-php graphviz . alpha armel mips mipsel ia64 powerpc sparc . -m > "Rebuild against PHP 5.3" > dw ffmpeg-php graphviz . alpha armel mips mipsel ia64 powerpc sparc . -m > "php5-dev (>= 5.3.1-3)" > > nmu ossp-uuid . armel mips mipsel sparc . -m "Rebuild against PHP 5.3" > dw ossp-uuid . armel mips mipsel sparc . -m "php5-dev (>= 5.3.1-3)" > > nmu xapian-bindings . mips mipsel sparc . -m "Rebuild against PHP 5.3" > dw xapian-bindings . mips mipsel sparc . -m "php5-dev (>= 5.3.1-3)" > > nmu mapserver ming sqlrelay php-imagick . ALL . -m "Rebuild against PHP 5.3" > dw mapserver ming sqlrelay php-imagick . ALL . -m "php5-dev (>= 5.3.1-3)" All done. > The php-ps binNMU FTBFS on powerpc due to a libtiff.a error. > Please give it back if it has been fixed already. Already done. > There are still some packages that need to be updated because they FTBFS > because of the (not-so-)new API: php-adodb (mine, will try to fix it during > the WE), php-ssh2, php-imlib, zeroc-ice, php-clamav, php-apc. Have bugs been filed about this? > Another upload of php5 will follow as soon as the current version is built and > installed on mips* (so that the binNMUs can be built there), to fix the RC bug > affecting parallel building and possibly some regressions. > > Should that new Debian revision be uploaded with urgency=medium? low is OK. If it should become a problem, we can always reduce the waiting period later on. Marc -- Fachbegriffe der Informatik - Einfach erklärt 287: Palestinänsertipper 1 Anschlag pro Minute. (Bodo Eggert) pgpR1I3QEzI5X.pgp Description: PGP signature --- End Message ---
Re: ghc6 still fails to build on ia64; what to do?
Joachim Breitner writes: > Am Sonntag, den 14.02.2010, 14:46 +0100 schrieb Marc 'HE' Brockschmidt: >> Well, building of -9 failed again, so I guess the bootstrapping is not >> the only problem. Note that merulo is slightly newer than caballero >> (Madison core vs. the older McKinley core), so the differences we are >> seeing might be related to this. Perhaps someone from the ia64 porters >> could shed some light on this? > Are there porters on d-release, or should someone actually notify them > about this problem? The latter, I guess. > Assuming nobody steps up to fix this, or nobody is able to, what is the > plan B: Somewhen the Haskell packages will be ready on the other arches > (there are issues to sort out until then, but solvable ones). Will we > just remove the ia64 haskell packages then? If the ia64 porters don't step up to do their job, we will first start removing binary packages that are not ported and will then start to consider dropping ia64 as a release arch. That's the worst-case scenario which wouldn't make me happy at all. ia64 hardware is, after all, still actively developed, so people using and porting to it should be around. Marc -- BOFH #19: floating point processor overflow pgprJOzD4pBY4.pgp Description: PGP signature
NEW changes in proposedupdates
Processing changes file: polipo_1.0.4-1+lenny1_i386.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_alpha.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_amd64.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_arm.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_armel.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_hppa.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_ia64.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_mips.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_mipsel.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_powerpc.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_s390.changes ACCEPT Processing changes file: polipo_1.0.4-1+lenny1_sparc.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_i386.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_alpha.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_amd64.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_arm.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_armel.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_hppa.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_ia64.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_mips.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_mipsel.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_powerpc.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_s390.changes ACCEPT Processing changes file: php5_5.2.6.dfsg.1-1+lenny6_sparc.changes ACCEPT -- 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/e1niytv-gk...@ries.debian.org
Bug#570594: Haskell binNMUs
Package: release.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Release Team, for Haskell libraries we now have a system of provides and depends in place that guarantees that an ABI change in one of the packages makes broken reverse dependencies uninstallable, similar to what the ocaml people do. We were not using it from the start for dependencies on the packages that are bundled in the compiler package "ghc6", such as base. Unfortunately, the ABI hash of this package changed for some arches at some point, breaking all previously built packages and causing lots of FTBFS on the buildds. Such a change is expected to happen very rarely, but we want to be prepared. Therefore, from ghc6-6.12.1-10 on, ghc6 also provides virtual packages corresponding to the ABIs contained in them. We need all haskell library packages to be rebuild with ghc6-6.12.1-10. The following list is a collection of binNMUs and build-ordering depwaits to cause such a rebuild. It does not give back any packages state Build-Attempted, though. I’ll go through that list tomorrow... Thanks for scheduling, Joachim nmu cpphs_1.9-2 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw cpphs_1.9-2 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu ghc6_6.12.1-9 . i386 kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw ghc6_6.12.1-9 . amd64 hppa i386 mips mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu gtk2hs_0.10.1-4 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw gtk2hs_0.10.1-4 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-mtl-dev (>> 1.1.0.2-10)' nmu haskell-alut_2.1.0.2-2 . amd64 armel i386 sparc kfreebsd-amd64 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-alut_2.1.0.2-2 . amd64 armel i386 sparc kfreebsd-amd64 . -m 'ghc6 (>= 6.12.1-10), libghc6-openal-dev (>> 1.3.1.3-2), libghc6-opengl-dev (>> 2.2.3.0-2)' nmu haskell-arrows_0.4.1.2-1 . amd64 armel i386 powerpc sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-arrows_0.4.1.2-1 . amd64 armel i386 powerpc sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-stream-dev (>> 0.4.1-1)' nmu haskell-bzlib_0.5.0.0-3 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-bzlib_0.5.0.0-3 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu haskell-curl_1.3.5-3 . amd64 armel hppa i386 s390 sparc kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-curl_1.3.5-3 . amd64 armel hppa i386 s390 sparc kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-network-dev (>> 2.2.1.7-1)' nmu haskell-dataenc_0.13.0.2-1 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-dataenc_0.13.0.2-1 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu haskell-fgl_5.4.2.2-2 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-fgl_5.4.2.2-2 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-mtl-dev (>> 1.1.0.2-10)' nmu haskell-glut_2.1.1.2-2 . amd64 armel i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-glut_2.1.1.2-2 . amd64 armel i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-opengl-dev (>> 2.2.3.0-2)' nmu haskell-haskell-src_1.0.1.3-2 . amd64 hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-haskell-src_1.0.1.3-2 . amd64 hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu haskell-hgl_3.2.0.2-1 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-hgl_3.2.0.2-1 . amd64 armel hppa i386 powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10), libghc6-x11-dev (>> 1.5.0.0-2)' nmu haskell-html_1.0.1.2-3 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-html_1.0.1.2-3 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu haskell-hunit_1.2.2.1-1 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'Rebuild with ghc6-6.12.1-10' dw haskell-hunit_1.2.2.1-1 . amd64 armel hppa i386 mipsel powerpc s390 sparc kfreebsd-amd64 kfreebsd-i386 . -m 'ghc6 (>= 6.12.1-10)' nmu haskell-language-c_0.3.1.1-2 . amd64
Bug#570462: nmu: second round for the php5 transition
On Friday 19 February 2010 13:17:09 Marc 'HE' Brockschmidt wrote: > Raphael Geissert writes: > > The php-ps binNMU FTBFS on powerpc due to a libtiff.a error. > > Please give it back if it has been fixed already. > > Already done. Looks like it failed again. > > There are still some packages that need to be updated because they FTBFS > > because of the (not-so-)new API: php-adodb (mine, will try to fix it > > during the WE), php-ssh2, php-imlib, zeroc-ice, php-clamav, php-apc. > > Have bugs been filed about this? For php-adodb, php-ssh2, php-imlib, php-clamav, and php-apc: yes. The zeroc-ice build failure appears to be just that the package was built against php < 5.3 but with a patch that requires 5.3 (no compatibility with old versions was added to the patch). Since we anyway need it to be built against 5.3 please give it back on mipsel and sparc. > > Another upload of php5 will follow as soon as the current version is > > built and installed on mips* (so that the binNMUs can be built there), to > > fix the RC bug affecting parallel building and possibly some regressions. > > > > Should that new Debian revision be uploaded with urgency=medium? > > low is OK. If it should become a problem, we can always reduce the > waiting period later on. > Ok. I was mostly worried about the time it would take to get it built on all the architectures, but I now see that mips* seem to be doing better. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net signature.asc Description: This is a digitally signed message part.
