Bug#572839: transition: graphviz
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal *** Please type your report below this line *** Hi, I sent the following to the list last week but didn't get a response - maybe it fell through the cracks? If so, that might have been my fault for failing to file it as a bug report - so allow me to rectify that now ... Cheers, David. --- Hi Release Team, Graphviz 2.26.3 has been in experimental for just about a month and we (as in the graphviz maintainers) now feel it is ready for uploading to unstable. This involves a transition as the existing libgraphviz4 package has been split into separate packages for each library and two libraries have soname bumps. Once uploaded it looks like BinNMUs will be required for the following packages. imagemagick python-pygraphviz anjuta-extras ggobi flowcanvas When would you like us to upload? Cheers, David. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) -- 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/4b92e28b.1070...@eclecticdave.com
Linear Algebra Libraries
Hello, I am planning to upload some modifications in the way Linear Algebra Libraries BLAS / LAPACK and ATLAS are handle in Debian. These libraries are very used by many scientific software. They didn't have many attentions during the last few years and ATLAS in unstable is in a pretty bad shape (old version, plenty of bugs, hard to use ...) I described what I am planning to do in this wiki page: http://wiki.debian.org/DebianScience/LinearAlgebraLibraries and my changes have been tested. There will be no need of transition since the ABI remains the same and is pretty stable (it is very common to switch between BLAS and LAPACK implementation) and the the impact should be low. I would like your opinion on these uploads. Sylvestre -- 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/1267895381.6366.1115.ca...@zlarin
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Marco Túlio Gontijo e Silva writes: > Excerpts from Marc 'HE' Brockschmidt's message of Sáb Mar 06 06:26:43 -0300 > 2010: >> This seems a bit more problematic than I originally assumed. >> >> Consider for example agda on sparc: >> https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 >> sparc is not a fast architecture, but also not the slowest one supported >> by Debian. In this case, it failed to build the package because a single >> file needed more than 500 minutes to compile. If this is indeed not due >> to a bug, but expected behaviour, it seems not supportable anymore. > It seems that the build time of agda for some arches grew very much with > ghc6-6.12.1, specially hppa and sparc: > > agda 2.2.6-2 2.2.6-3 > > hppa 04:57:19 60:57:00+ > kfreebsd-i386 00:17:10 00:11:39 > mips 02:35:19 03:54:06 > mipsel 02:34:59 04:04:43 > powerpc00:26:37 00:27:16 > s390 00:47:49 02:00:55 highlight-kate was rebuilt again today on s390, leading to this: [26 of 61] Compiling Text.Highlighting.Kate.Syntax.Java ( Text/Highlighting/Kate/Syntax/Java.hs, dist-ghc6/build/Text/Highlighting/Kate/Syntax/Java.p_o ) virtual memory exhausted: Cannot allocate memory I can't believe that this is not a bug. Marc -- BOFH #302: microelectronic Riemannian curved-space fault in write-only file system pgpwUT8fAjKkV.pgp Description: PGP signature
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Hi Marc. Excerpts from Marc 'HE' Brockschmidt's message of Sáb Mar 06 06:26:43 -0300 2010: > Joachim Breitner writes: > > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: > >> Joachim Breitner writes: > >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 > >> > . -m "rebuild against changed pcre-light ABI" > >> Done. Got lost in the cracks somehow. Do you know why its hitting > >> timeouts on other archs? Is this something we could fix? > > Probably just because it needs a lot of memory and CPU power, and the > > other arches have difficulties compiling the package in time. > > This seems a bit more problematic than I originally assumed. > > Consider for example agda on sparc: > https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 > sparc is not a fast architecture, but also not the slowest one supported > by Debian. In this case, it failed to build the package because a single > file needed more than 500 minutes to compile. If this is indeed not due > to a bug, but expected behaviour, it seems not supportable anymore. It seems that the build time of agda for some arches grew very much with ghc6-6.12.1, specially hppa and sparc: agda 2.2.6-2 2.2.6-3 hppa 04:57:19 60:57:00+ kfreebsd-i386 00:17:10 00:11:39 mips 02:35:19 03:54:06 mipsel 02:34:59 04:04:43 powerpc00:26:37 00:27:16 s390 00:47:49 02:00:55 sparc 03:23:58 08:33:05+ For ghc6 this didn't happened; when the time grew, it grew not very much: ghc6 6.10.4-1 6.12.1-12 alpha 13:05:04 14:40:30 amd64 01:24:19 01:31:30 armel 100:47:35 127:04:23 hppa 12:25:45 16:08:58 kfreebsd-i386 01:21:37 02:14:17 mips 20:03:36 15:31:51 mipsel 20:03:22 16:25:52 powerpc04:59:03 03:25:32 s390 07:20:55 03:24:32 sparc 50:23:08 07:22:11 Maybe this is related to something in the agda's code interaction with the new version of ghc6 in hppa and sparc; possibly a bug somewhere. > How should slower archs (like mips*, armel) handle such packages? Is > splitting this up in smaller files an option? Splitting in smaller files is not very different from what I proposed in debian-haskell of using a verbose build. The good option in this case would be adding --ghc-options=-v2 to Setup configure. I think that, if these packages are not going to be dropped for these arches, this is a good enough workaround. At least it seems to me to be better than what's being used now: watcher.sh (#571824). Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva -- 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/1267876809-sup-8...@zezinho
Re: Timeouts
Hi, Am Samstag, den 06.03.2010, 10:26 +0100 schrieb Marc 'HE' Brockschmidt: > Joachim Breitner writes: > > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: > >> Joachim Breitner writes: > >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 > >> > . -m "rebuild against changed pcre-light ABI" > >> Done. Got lost in the cracks somehow. Do you know why its hitting > >> timeouts on other archs? Is this something we could fix? > > Probably just because it needs a lot of memory and CPU power, and the > > other arches have difficulties compiling the package in time. > > This seems a bit more problematic than I originally assumed. > > Consider for example agda on sparc: > https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 > sparc is not a fast architecture, but also not the slowest one supported > by Debian. In this case, it failed to build the package because a single > file needed more than 500 minutes to compile. If this is indeed not due > to a bug, but expected behaviour, it seems not supportable anymore. How > should slower archs (like mips*, armel) handle such packages? Is > splitting this up in smaller files an option? Even if possible, I’m not sure if that would help: Having more smaller files will give more output on the build log, but still take the very long time it takes. If the package requires too much resources for such an architecture to build, maybe it’s an indication that these architectures are also a too weak to use the package, and therefore there would be no loss to drop support for these packages on the affected arches (i.e. remove any existing old builds and add the files to N-F-U)? At least until a user on these arches complains? 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
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Joachim Breitner writes: > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: >> Joachim Breitner writes: >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 . >> > -m "rebuild against changed pcre-light ABI" >> Done. Got lost in the cracks somehow. Do you know why its hitting >> timeouts on other archs? Is this something we could fix? > Probably just because it needs a lot of memory and CPU power, and the > other arches have difficulties compiling the package in time. This seems a bit more problematic than I originally assumed. Consider for example agda on sparc: https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 sparc is not a fast architecture, but also not the slowest one supported by Debian. In this case, it failed to build the package because a single file needed more than 500 minutes to compile. If this is indeed not due to a bug, but expected behaviour, it seems not supportable anymore. How should slower archs (like mips*, armel) handle such packages? Is splitting this up in smaller files an option? Marc -- BOFH #89: Electromagnetic energy loss pgptN3nqOvnIz.pgp Description: PGP signature
