ARM build of scalapack
Greetings, Can someone please build scalapack for arm? I tried (took about 20 hours on my netwinder), but am still bitten by bug 222536 -- which is not reproducible, except on my box where it always happens. :-( Since I just built octave2.1 and rmpi, this is the last arm build holding up a major transition of about 20 Beowulf packages. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mini-freeze for apt/libsigc++/gtkmm2.0
On Sun, Oct 16, 2005 at 11:16:14PM -0700, Steve Langasek wrote: > This is a quick note to let you know that things are nearly ready to allow > updates of apt, libsigc++1.2, gtkmm2.0, and related packages into etch as > part of the C++ ABI transition. At this point, the main blocker is perl, > which is expected to be a candidate for testing soon once a new upload takes > place to fix an arm build failure. Please don't upload any of these > packages to unstable without coordination with the release team until the > packages have successfully transitioned to etch. The status of your > packages can of course always be tracked using packages.qa.debian.org or > qa.debian.org/developer.php. This took much less time than expected -- these packages are now all in testing. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: libmysqlclient12 to libmysqlclient14 transition
>But I asked first back in july, JACK cheated the queue! :-))) Yes. So did libpng and openssl. KDE didn't, though, since it's part of the C++ transition, which is priority one. After the KDE stuff gets in, it will probably be safe to start transitions, since that will be 90% of the C++ transition. I can't speak for the release team, of course. Transitions probably should be queued up. freetype has a very early request for transitioning (June); libpcap has an early request for transitioning (July); tetex-3.0 has a July request; and you have a July request. Finally, libgsf has an October request. Of these, most of them look like they can safely happen at the same time. The only worrisome one is freetype, which might (will) interfere with other things, so the release team should make a decision about when to do it. I'm optimistic that KDE & friends will get in within a week. The current blockers I know about are: * upload of (built) qt-x11-free for hppa * build and upload of kdelibs on hppa * build and upload of kdebase on hppa * libpng: _either_ -- binNMUs of a great mass of KDE packages to prevent them from depending on new libpng (http://lists.debian.org/debian-release/2005/10/msg00185.html) _or_ -- binNMUs of packages preventing libpng from getting in (http://lists.debian.org/debian-release/2005/10/msg00177.html) -- building and uploading the GNOME 1 libraries and rushing them in (http://lists.debian.org/debian-release/2005/10/msg00185.html) -- then letting libpng in Feel free to help with any part of this :-) Stuff depending on new openssl will probably be deliberately broken if necessary to get KDE & friends in. Openssl shouldn't be a big problem though because it can go in ahead of its dependencies. -- Nathanael Nerode <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Plan for force-hint for KDE/JACK
On Tue, Oct 18, 2005 at 07:14:15PM -0400, Nathanael Nerode wrote: > easy enchant/1.1.6-1.1 myspell/1:3.0+pre3.1-16 abiword/2.4.1-1 > aiksaurus/1.2.1+dev-0.12-1 libwpd/0.8.3-1 writerperfect/0.7.0-4 I track that one. But it isn't yet ready. First abiword was stuck behind libpng which we tried to solve with binNMUs but those aren't installable due to the strict dependency on abiword-common. So we need either to request a sourceful upload from the maintainer or do a source-changing binNMU on sparc. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Plan for force-hint for KDE/JACK
Andreas Barth wrote: >On the other hand, we try to get some parts of Qt/KDE/jack in tonight. >Well, such runs usually take more than one try, but the situation will >probably look much better soon enough. I doubt that this is possible *tonight* without making much more breakage than you actually want to make, due to the stuff clogged behind libpng (bad libpng! Bad!) But below I have some hints which should get KDE/JACK in with fairly little breakage once the libpng and openssl clogs are cleared, and once kdelibs and kdebase build (hopefully within the week). There are also some immediate hints at the bottom of the message. -- So this is the proposed KDE/JACK hint. It will have to be a force-hint. This should replace the previous KDE/JACK/unixodbc/icu/libmusicbrainz /python-qt3 hints succesfully. It won't really be ready to go until the issues tying it into libpng and openssl are resolved though. (You'll have to remove the line-wrapping.) # Lots of old FTBFS, ties JACK to libsigc++, gtkmm remove ardour/0.9beta29-1 # Ties qt-x11-free into opensp and gnucash remove libaqbanking/1.5.99+1.6.0beta-1 # Aargh, new upload, and produces a udeb urgent wireless-tools/27+28pre10-1 unblock wireless-tools/27+28pre10-1 # new upload urgent wv2/0.2.2-3 # These are just to get output force qt-x11-free/3:3.3.5-1 force kdelibs/4:3.4.2-4 force kdebase/4:3.4.2-3 force gnuradio-core/2.5-5 force openscenegraph/0.9.9-7 force kxdocker/0.12-1 force amarok/1.3.3-1 force liboil/0.3.3-1 # The KDE/JACK/unixodbc/icu/libmusicbrainz/python-qt3 hint # need force-hint to force partial breakage in new kdesdk and old php4 force-hint qt-x11-free/3:3.3.5-1 jack-audio-connection-kit/0.100.0-4 arts/1.4.2-4 openexr/1.2.2-4 kdelibs/4:3.4.2-4 unixodbc/2.2.11-9 freetds/0.63-2 flac/1.1.2-3 id3lib3.8.3/3.8.3-4.2 icu/3.4-2 taglib/1.4-1 libmusicbrainz-2.1/2.1.1-4 dbus/0.23.4-7 xerces26/2.6.0-5 kdepim/4:3.4.2-2 geos/2.1.3-2 gdal/1.2.6-1.2 libkipi/0.1.2-1 libxbase/2.0.0-7.1 libtunepimp/0.3.0-9 libmodplug/1:0.7.5 kdebase/4:3.4.2-3 cppunit/1.10.2-4 kdemultimedia/4:3.4.2-2 gnuradio-core/2.5-5 xerces25/2.5.0-6 xbsql/0.11-4.1 sip4-qt3/4.3-1 qscintilla/1.6-2 ksimus/0.3.6-2-7 coin2/2.4.3-3 python-qt3/3.15-3 wv2/0.2.2-3 wireless-tools/27+28pre10-1 libaqbanking/1.5.99+1.6.0beta-1 kdesdk/4:3.4.2-2.1 qca/1.0-8 openscenegraph/0.9.9-7 openal/0.2005080600-2.1 licq/1.3.0-4 libpqxx/2.5.5-1 libdc0/0.3.7-3 kxdocker/0.12-1 kdegames/4:3.4.2-1 clalsadrv/1.0.1-3 dynamite/0.1-4 orange/0.3-2 unshield/0.5-3 libsidplay/1.36.59-4 sidplay-libs/2.1.1-3 liboil/0.3.3-1 # If you want to simplify things, gst-plugins0.8 and xsidplay drag # in libsidplay, sidplay-libs, and liboil. # synce-kde drags in dynamite, orange, and unshield. # ams drags in clalsadrv - # I also believe I've found some more hint combos which should work today: easy enchant/1.1.6-1.1 myspell/1:3.0+pre3.1-16 abiword/2.4.1-1 aiksaurus/1.2.1+dev-0.12-1 libwpd/0.8.3-1 writerperfect/0.7.0-4 easy maxdb-7.5.00/7.5.00.30-3 libdbd-maxdb-perl/7.5.00.32-1 php4-maxdb/7.5.00.30-1 # xdrawchem depends on qt-x11-free, will go back in with it remove xdrawchem/1.9.4-3 easy ghemical/1.90-2 libghemical/1.90-1 mpqc/2.2.3-2 openbabel/1.100.2-3 # Alternately, all of the above could be thrown into the KDE hint too # epiphany hasn't undergone the C++ transition remove epiphany/0.5.1-1 easy clanlib/0.6.5-1-3 clanbomber/1.05cdbs-2 pingus/0.6.0-8.2 trophy/1.1.3-3 -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libmysqlclient12 to libmysqlclient14 transition
* Christian Hammers ([EMAIL PROTECTED]) [051018 22:19]: > Hello > > On 2005-10-18 Nathanael Nerode wrote: > > > Release Team, please comment :-) > > > > Can you wait on this until the KDE/JACK transition goes through, new libpng > > gets into etch, and new openssl does too? > > But I asked first back in july, JACK cheated the queue! :-))) Yes. That's bad of jack. > Apropos, does the release team have a list of waiting transitions or should I > just bounce my last mail every couple of weeks when I see that the list is > getting quiet? We want to, but don't have currently, sorry. On the other hand, we try to get some parts of Qt/KDE/jack in tonight. Well, such runs usually take more than one try, but the situation will probably look much better soon enough. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Let's let lm-sensors, wxwindows2.4 in; and other thoughts
One removal should get lm-sensors in: # php4-rrdtool ties lm-sensors to php4 and that whole mess remove php4-rrdtool/1.04-11 easy lm-sensors/1:2.9.2-4 rrdtool/1.2.11-0.4 rrdcollect/0.2.3-2 (This is a prereq for getting KDE and company in.) One removal should likewise get wxwindows in: # Don't wait for subversion remove rapidsvn/0.8.0-3 # Don't wait for tipptrainer urgent tipptrainer/0.6.0-5 # (and the existing hint, but with rapidsvn removed) (This is a prereq for getting libpng in.) --- The other prereq for getting libpng in is letting the entire GNOME 1 cluster in, so that gdk-pixbuf can go in. Once the binNMU is uploaded * imlib can go in first * gnome-libs can go in by itself after imlib, I think * libcapplet can go in by itself after gnome-libs, I think The rest has to go in at once. # bonobo, gnome-print, gtkhtml need lots of builds, time easy gdk-pixbuf/0.22.0-10 bonobo/1.0.22-5 gnome-print/0.37-10 gtkhtml/1.1.10-8 --- Getting libpng in shouldn't be a prereq for KDE, but some stuff is kind of tied up with it. This means additional binNMU candidates: Source kdevelop3: kdevelop3 kdevelop3-plugins (arm; powerpc still needs to build the current source) Source kdesdk: cervisia kbabel kbugbuster kcachegrind kdesdk-kfile-plugins kdesdk-misc kmtrace kompare kspy kuiviewer libcvsservice0 poxml umbrello (alpha, i386, ia64, mips, mipsel, powerpc, sparc) ksensors (alpha, i386, ia64, mips, mipsel, powerpc, sparc) imagemagick (arm, m68k, sparc) -- for koffice okle (sparc) kcpuload (sparc) facturalux (m68k, so forget it) timidity (m68k, so forget it) konversation (sparc) rekall (sparc) -- also depends on libxbase, xbsql, which need to be added to the Master KDE hint (if it'll be a force-hint, just libxbase) superkaramba (ia64, s390) tellico (hppa) -- also not yet built on mips, depends on openssl on mipsel karamba (alpha, arm, ia64, m68k, mips, mipsel, powerpc) kpsk (alpha, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc) swscanner (everywhere except sparc) kbiff (alpha, arm, hppa, ia64, m68k, mips, mipsel, powerpc, s390) synce-kde (everywhere except arm) -- also depends on dynamite, orange, unshield, which would need to be added to the Master KDE hint klog (everywhere except hppa) kiosktool (everywhere, period) komba2 (everywhere) knetfilter (everywhere except arm) kaptain (everywhere) -- being removed, but axel has to be removed first droidbattles (everywhere) kexi (everywhere except arm and m68k) -- also waits for libpqxx, which has to go in with kexi potracegui (everywhere except s390) ktimetrace (alpha, i386, ia64, mips, mipsel, powerpc, sparc) apollon (everywhere except m68k and s390) kxdocker (alpha, i386, m68k, mips, mipsel, powerpc, sparc) krename (sparc) kvdr (arm, sparc) ...and certainly others I haven't spotted yet. It may make more sense to put GNOME 1 and libpng through first, though I really detest delaying KDE for these things. -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libmysqlclient12 to libmysqlclient14 transition
Hello On 2005-10-18 Nathanael Nerode wrote: > > Release Team, please comment :-) > > Can you wait on this until the KDE/JACK transition goes through, new libpng > gets into etch, and new openssl does too? But I asked first back in july, JACK cheated the queue! :-))) Apropos, does the release team have a list of waiting transitions or should I just bounce my last mail every couple of weeks when I see that the list is getting quiet? I found this nice page on the web, maybe you want to use it if you don't already:http://wiki.debian.org/OngoingTransitions bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libmysqlclient12 to libmysqlclient14 transition
Christian Hammers wrote: > Hello > > In Debian Sarge we had libmysqlclient12 from MySQL 4.0.x as main mysql > library in use. In Etch I already have MySQL 4.1 (libmysqlclient14) and > MySQL 5.0 (libmysqlclient15) which is still only release-candidate, so I'd > like to drop support for the 4.0 branch completely. > > Note though, that libmysqlclient10-dev from mysql (3.23.x), maintained by > Steve Langasek, which is also still present is left untouched because it > was released under LGPL instead of "GPL+FLOSS Exceptions" and thus be > preferred by some people. > > As we have recently introduced versioned symbols to libmysqlclient14 and > -15 the transition "should be easy"(tm) and done just by mass filing a bug > report and maybe after 2 weeks NMU the leftover packages. > > Maintainers: > Recompiling with build-deps set to libmysqlclient14-dev instead of > libmysqlclient12-dev should be enough. > > > The last published release schedule speaks of 2006 as release date. It > might be that MySQL 5.0 will be stable enough next summer to be shipped - > maybe at the cost that of some more necessary bugfix updates but the > benefit to only have one MySQL for the security support afterwards. > > Release Team, please comment :-) Can you wait on this until the KDE/JACK transition goes through, new libpng gets into etch, and new openssl does too? It has the potential to delay all of the above, which would suck badly. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BinNMUs wanted for libpng issues
Steve Langasek wrote: > On Tue, Oct 18, 2005 at 01:22:52AM -0400, Nathanael Nerode wrote: >> Please forward this whereever appropriate. >> The following packages were built against the libpng with overly strict >> shlibs on one or more architectures, and to ease testing transition >> problems, binNMUs are desired. > >> (See http://lists.debian.org/debian-release/2005/10/msg00149.html ) > >> libwxgtk2.4-dev (m68k, source is wxwindows) > > m68k is the one arch we can't do binNMUs on yet. We're also ignoring it > for testing transitions, so there's not really a hurry either. Hmm, is britney clever enough to notice that and allow libpng in? I guess so. >> libgdk-pixbuf2 (arm, source is gdk-pixbuf) > > Already been queued; it failed, given back again. Looks like it built. >> gif2png (arm) > > Queued. Arm is struggling to keep up right now, so it may take a bit for > a build to happen. Looks like it built. >> gdk-imlib11 (sparc, source is imlib) > > Also queued. Looks like it built. >> dillo (sparc -- but deserves rebuild on all arches for new openssl) > > only i386 and ia64 have a dependency on libssl0.9.7. Queued on these > three archs. > >> ygraph (arm, sparc) > > Also queued. > >> You know, that's a much shorter list than I thought it would be. > > http://bjorn.haxx.se/debian/testing.pl?staller=libpng suggests that > there's opportunity to add to this list, though I don't know how many of > these packages we need to worry about just yet. All of the ones I checked are indirect deps via one of the above packages. That was the pleasant surprise. -- Nathanael Nerode Random sig chooser not working today -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version 0.9.8a with symbol versioning released
On Mon, Oct 17, 2005 at 07:41:30PM +0200, Christoph Martin wrote: > I just uploaded openssl version 0.9.8a which features symbol versioning. > It will hit the archive in the next hours and get autobuilded. I think > we should do a proper anouncement to d-d(-a) about the upload and that > the maintainers should at least rebuild their shared library packages. I agree that it should be announced; however, I don't think we should be telling maintainers to reupload right now. Sourceful uploads may be very disruptive of the various ongoing transitions, and I think it's important to not give maintainers the wrong impression about where this is on the overall priority list: switching over to 0.9.8 should be RC for etch, but uploading right now may hold hundreds of RC bugfixes out of testing. We also now have the option of doing buildd recompilation-only binNMUs for library transitions, which are less disruptive than source uploads and should therefore be preferred whenever the package only needs a rebuild without source changes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: BinNMUs wanted for libpng issues
On Tue, Oct 18, 2005 at 01:22:52AM -0400, Nathanael Nerode wrote: > Please forward this whereever appropriate. > The following packages were built against the libpng with overly strict > shlibs on one or more architectures, and to ease testing transition problems, > binNMUs are desired. > (See http://lists.debian.org/debian-release/2005/10/msg00149.html ) > libwxgtk2.4-dev (m68k, source is wxwindows) m68k is the one arch we can't do binNMUs on yet. We're also ignoring it for testing transitions, so there's not really a hurry either. > libgdk-pixbuf2 (arm, source is gdk-pixbuf) Already been queued; it failed, given back again. > gif2png (arm) Queued. Arm is struggling to keep up right now, so it may take a bit for a build to happen. > gdk-imlib11 (sparc, source is imlib) Also queued. > dillo (sparc -- but deserves rebuild on all arches for new openssl) only i386 and ia64 have a dependency on libssl0.9.7. Queued on these three archs. > ygraph (arm, sparc) Also queued. > You know, that's a much shorter list than I thought it would be. http://bjorn.haxx.se/debian/testing.pl?staller=libpng suggests that there's opportunity to add to this list, though I don't know how many of these packages we need to worry about just yet. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
