Graphviz 2.26.3 (transition)
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. -- 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/4b8af296.9060...@eclecticdave.com
Re: RC severity for Python 2.6 related bugs
On Sun, Feb 28, 2010 at 23:11, Vincent Bernat wrote: > I also tend to believe that there are a lot of packages that will just > fail to run with Python 2.6 but will have no problem to build, because > for most packages, building just means to copy files in the right > location. The later we switch to Python 2.6, the more difficult it will > be to catch those bugs. I absolutely agree with this (even though, for those packages that byte-compile the files they install, it's a smaller problem) and I fear there are several situations where there are hidden bugs only discovered with (long) *usage* of a system with 2.6 as default: waiting to do the switch, doesn't help to release a better squeeze, only a worst and buggier one. Additionally, as a side note, unstable is "unstable" by definition: its users knows it, and if something breaks in it, it will either be fixed or not in stable, so "break users apps" problem is less appealing (even though it exists). Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/8b2d7b4d1002281450h79524b79j3e99c410dcec...@mail.gmail.com
Re: RC severity for Python 2.6 related bugs
OoO Vers la fin de l'après-midi du dimanche 28 février 2010, vers 16:46, Josselin Mouette disait : >> It would be far easier to let Python 2.6 be the default, then file (or >> upgrade) serious bugs and solve them in a week or two. > Yeah sure, let’s knowingly break dozens of packages by switching instead > of fixing them before and make it painless for users. Sorry, I really don't see any relation between FTBFS and breaking a package. I don't have any handy stat to support my claims (and I don't maintain enough Python packages to turn this affirmation into an universal one), but there are packages that fail to build from sources because they are not able to run unittests but work fine with Python 2.6 as default. Therefore, we get RC bugs for packages that build fine (with current default Python) and run fine (with all supported Python). I also tend to believe that there are a lot of packages that will just fail to run with Python 2.6 but will have no problem to build, because for most packages, building just means to copy files in the right location. The later we switch to Python 2.6, the more difficult it will be to catch those bugs. -- NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE NON-FLAMMABLE, IS NOT A CHALLENGE -+- Bart Simpson on chalkboard in episode BABF13 pgpcXtVD4k8Td.pgp Description: PGP signature
Re: Frozen haskell packages?
* Joachim Breitner (nome...@debian.org) [100228 18:17]: > although the haskell packages are not really close to a transitional > state yet (armel just built the compiler, mips and mipsel haven’t yet), > I had a look at the haskell packages on > http://bts.turmzimmer.net/details.php. I did not see any surprising > problems, but I was wondering why the packages haskell-hsh and > haskell-hsql have a [FROZEN] prepended. Is this something left-over from > a previous transition? Does this need action? Ignore the FROZEN please, that's an bug in the script. I probably should just remove that part. Cheers, Andi -- 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/20100228181219.gx19...@mails.so.argh.org
Bug#571972: Please binNMU promoe/0.1.1-1 and xmms2-scrobble/0.4.0-1 against xmms2 0.7DrNo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please rebuild these two packages against xmms2 0.7DrNo. All other xmms2 clients needs to be patched to support 0.7DrNo. nmu promoe/0.1.1-1 . ALL . -m "Rebuild against xmms2 0.7DrNo." nmu xmms2-scrobbler/0.4.0-1 . ALL . -m "Rebuild against xmms2 0.7DrNo." dw promoe/0.1.1-1 xmms2-scrobbler/0.4.0-1 . ALL . -m 'libxmmsclient-dev (>= 0.7DrNo)' Thanks. -- 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/20100228172224.17504.47999.report...@deep-thought
Frozen haskell packages?
Hi release team, although the haskell packages are not really close to a transitional state yet (armel just built the compiler, mips and mipsel haven’t yet), I had a look at the haskell packages on http://bts.turmzimmer.net/details.php. I did not see any surprising problems, but I was wondering why the packages haskell-hsh and haskell-hsql have a [FROZEN] prepended. Is this something left-over from a previous transition? Does this need action? Also, it seems that we will not get a solution for ia64. Is there a problem with removing the ia64 haskell packages from testing now, or should we do it as late as possible? (Assuming that this is actually the correct thing to do.) 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: OK to update Boost defaults?
[please cc me on replies] Marc, I appreciate the rapid feedback. On Sun, Feb 28, 2010 at 12:09:51PM +0100, Marc 'HE' Brockschmidt wrote: > "Steve M. Robbins" writes: > > So, three questions: > > > > 1. Is it appropriate to change boost-defaults now (from a transitions > >point of view)? > > No. We are currently trying to work out the hdf5 and ghc6 transitions > and have enormous buildd backlogs on mips*, making a binNMU campagain > for long-building packages (and let's face it, most of boost users take > more than a few seconds to build...) a problem right now. OK, so what's the process now? I just uploaded a new revision 1.42.0-2 so it will be at least 10 more days until it transitions. Shall I wait for that and ping you again? Or will you put Boost in a "transitions queue" and let me know when you are ready for the boost-defaults change? Regards, -Steve signature.asc Description: Digital signature
Bug#548642: transition: liblo
As far as I can tell, no reverse build-dep of liblo is involved in the current ghc or hdf transitions. Can we upload new liblo to unstable and schedule binNMUs? csound dssi fluidsynth-dssi freej hexter jackbeat* jamin ll-scope nekobee qtractor rosegarden* sineshaper* whysynth wsynth-dssi xsynth-dssi * These packages need sourceful uploads because they build-depend on a versioned liblo0-dev. Bugs have already been filed for these (530852, 530859 and 571961). -- Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part
Re: RC severity for Python 2.6 related bugs
* Jonathan Wiltshire (deb...@jwiltshire.org.uk) [100228 17:19]: > On Sun, Feb 28, 2010 at 04:46:09PM +0100, Josselin Mouette wrote: > > Le dimanche 28 février 2010 à 15:29 +0100, Vincent Bernat a écrit : > > > It would be far easier to let Python 2.6 be the default, then file (or > > > upgrade) serious bugs and solve them in a week or two. > > > > Yeah sure, let’s knowingly break dozens of packages by switching instead > > of fixing them before and make it painless for users. > > I think we need to do both before we end up running out of time. I > propose that we upgrade/file bugs as serious so that they get maintainer > attention where possible, and allow (let's say) 7 days to react. > > After this time, Python 2.6 should become default in sid and all such bugs > are NMU candidates. If nothing else gets maintainer's attention, this will. Such bugs *are* as of today NMU candidates, if they are marked important or serious and have an working patch for longer than 7 days. Switching the default should be done when it's ready. Switching the default too early will only increase work load but doesn't allow us to reach the goal earlier. Trust us, we want to see python2.6 as default in squeeze. This however only works step by step. Cheers, Andi -- 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/20100228163921.gw19...@mails.so.argh.org
Re: RC severity for Python 2.6 related bugs
Jonathan Wiltshire (28/02/2010): > I think we need to do both before we end up running out of time. I > propose that we upgrade/file bugs as serious so that they get > maintainer attention where possible, and allow (let's say) 7 days to > react. What about providing with patches instead of only playing around with severity? *That* would help things going forward… Mraw, KiBi. signature.asc Description: Digital signature
Re: RC severity for Python 2.6 related bugs
On Sun, Feb 28, 2010 at 04:46:09PM +0100, Josselin Mouette wrote: > Le dimanche 28 février 2010 à 15:29 +0100, Vincent Bernat a écrit : > > It would be far easier to let Python 2.6 be the default, then file (or > > upgrade) serious bugs and solve them in a week or two. > > Yeah sure, let’s knowingly break dozens of packages by switching instead > of fixing them before and make it painless for users. I think we need to do both before we end up running out of time. I propose that we upgrade/file bugs as serious so that they get maintainer attention where possible, and allow (let's say) 7 days to react. After this time, Python 2.6 should become default in sid and all such bugs are NMU candidates. If nothing else gets maintainer's attention, this will. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- 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/20100228161932.ga32...@lupin.powdarrmonkey.net
Re: RC severity for Python 2.6 related bugs
* Josselin Mouette (j...@debian.org) [100228 16:50]: > Le dimanche 28 février 2010 à 15:29 +0100, Vincent Bernat a écrit : > > It would be far easier to let Python 2.6 be the default, then file (or > > upgrade) serious bugs and solve them in a week or two. > > Yeah sure, let’s knowingly break dozens of packages by switching instead > of fixing them before and make it painless for users. That's the reason why the release team prefers (and has decided) that such bugs are serious (using their delegation powers). Cheers, Andi -- 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/20100228155812.gv19...@mails.so.argh.org
Re: RC severity for Python 2.6 related bugs
Le dimanche 28 février 2010 à 15:29 +0100, Vincent Bernat a écrit : > It would be far easier to let Python 2.6 be the default, then file (or > upgrade) serious bugs and solve them in a week or two. Yeah sure, let’s knowingly break dozens of packages by switching instead of fixing them before and make it painless for users. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RC severity for Python 2.6 related bugs
On Sun, Feb 28, 2010 at 15:29, Vincent Bernat wrote: > OoO Pendant le journal télévisé du samedi 27 février 2010, vers 20:19, > Luca Falavigna disait : > >> after some discussions on #debian-python, I'd like to propose >> increasing severity of Python 2.6 related bugs [1] to serious. > > Well, I disagree. Python 2.6 is not the default. Packages are currently > built with Python 2.5 and do not fail to build in a current pbuilder. I tend to concur: they should be RC when 2.6 is the default, which is still not, for no reason. > We > already had a bunch of bug reports about packages not building with > Python 2.6 as default a few months ago and it was a mess to setup a > pbuilder to build with Python 2.6 as default [1]. The solution is easier > now but not documented (to the best of my knowledge). It still needs manual setup, and it's not so known how to do, and of course there was no support from python maintainer in at least setting 2.6 as default in experimental, just to help people debug and fix those bugs. I've asked this in late December, no reply came, (but it's so difficult is to change 5 lines in debian/rules of python-default to help releasing with 2.6 as default...). > I am also still lost why Python transition communication is done in > debian-release@ and not in debian-pyt...@. Because Python maintainer is unable to communicate, with anyhow. The only audience he cares a bit is the Release Team. debian-python is completely ignored by him. > debian-python@ contains posts > like "Why default python is not 2.6 yet?" that got not really answered > because the transition seems to be managed behind the scene. the transition is simply not handled by the Python maintainer. It is handled by the people he ignores by filing bugs, preparing patches and NMU, and interacting with RT for binNMUs. Often it is done on irc, so no public trace is left. > It would be far easier to let Python 2.6 be the default, then file (or INDEED! > upgrade) serious bugs and solve them in a week or two. Most bug FTBFS > reports that I received for my Python packages is related to the build > process and does not hinder the package from working with Python 2.6. I > think this is the case for most simple packages because the hard work is > done by python-support. That's why setting 2.6 should have set as default *ages* ago: did anyone hear from Python maintainer about it (even after kind and less-kind queries)? Of course, no, thank you... Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/8b2d7b4d1002280739q2941b4d0l3e0c311913ac6...@mail.gmail.com
Bug#571949: marked as done (nmu: liblouisxml_2.1.0-1)
Your message dated Sun, 28 Feb 2010 15:08:57 + with message-id <1267369737.22579.681.ca...@kaa.jungle.aubergine.my-net-space.net> and subject line Re: Bug#571949: nmu: liblouisxml_2.1.0-1 has caused the Debian Bug report #571949, regarding nmu: liblouisxml_2.1.0-1 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.) -- 571949: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571949 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 Hello, liblouis has changed its ABI and thus the library package name. liblouisxml now needs to be rebuilt against the new library (it is the only package using it). nmu liblouisxml_2.1.0-1 . ALL . -m "Rebuild against the new liblouis2" Thanks -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Hi, On Sun, 2010-02-28 at 14:57 +0100, Samuel Thibault wrote: > liblouis has changed its ABI and thus the library package name. > liblouisxml now needs to be rebuilt against the new library (it is the > only package using it). > > nmu liblouisxml_2.1.0-1 . ALL . -m "Rebuild against the new liblouis2" Scheduled. Regards, Adam --- End Message ---
Processed: block 571359 with 571949
Processing commands for cont...@bugs.debian.org: > block 571359 with 571949 Bug #571359 [src:dots] dots: FTBFS: Unsatisfiable build-dependency: liblouisxml-bin: Depends: liblouis0 but it is not installable Was not blocked by any bugs. Added blocking bug(s) of 571359: 571949 > 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.126736634131121.transcr...@bugs.debian.org
build-priorities usage changed -> use large values
Hi,
I just multiplied all build-priorities with 100. Reason behind that is
that there is an patch that will add different priorities. So please
replace any usage of "1" with "100" etc. (Of course, you could use
more fine-granular dependencies as well - feel free to do that. But
don't be surprised if they start to have an different effect on the
sort order than you used to be.)
Re the patch:
There are two new fields in --info. Also there are two new sort
options, C and W. C sorts by the new algorithm, W by waiting time.
Sorting default is (unchanged) PScpsn, which means build-priority,
(>= standard?), already built in the past, priority, section, name
(and the first non-equal criterion is used to sort).
The values for C are a sum of
priority: required: 50, important: 40, standard: 30, optional: 5
section: libs: 4, devel: 2
component: contrib: -10, non-free: -20
notes: uncompiled: 20, out-of-date: 40, partial: 40
("partial" as this was the case up to now - don't think we still use
that)
Also, up to 6 full waiting days increase the sum by 2 for each waiting
day.
To that value any permanent and current build priority is added (both
if both exist).
The packages are then sort by numbers.
(To see the order I would propose add -OCWn to list=needs-build, which
means calculated order, waiting days, name.)
Comments? (Please avoid having -release in your follow up.)
Cheers,
Andi
--
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/20100228151506.gu19...@mails.so.argh.org
Re: RC severity for Python 2.6 related bugs
OoO Pendant le journal télévisé du samedi 27 février 2010, vers 20:19, Luca Falavigna disait : > after some discussions on #debian-python, I'd like to propose > increasing severity of Python 2.6 related bugs [1] to serious. Well, I disagree. Python 2.6 is not the default. Packages are currently built with Python 2.5 and do not fail to build in a current pbuilder. We already had a bunch of bug reports about packages not building with Python 2.6 as default a few months ago and it was a mess to setup a pbuilder to build with Python 2.6 as default [1]. The solution is easier now but not documented (to the best of my knowledge). I am also still lost why Python transition communication is done in debian-release@ and not in debian-pyt...@. debian-python@ contains posts like "Why default python is not 2.6 yet?" that got not really answered because the transition seems to be managed behind the scene. It would be far easier to let Python 2.6 be the default, then file (or upgrade) serious bugs and solve them in a week or two. Most bug FTBFS reports that I received for my Python packages is related to the build process and does not hinder the package from working with Python 2.6. I think this is the case for most simple packages because the hard work is done by python-support. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557925 -- BOFH excuse #447: According to Microsoft, it's by design pgpFHtbMpYG6J.pgp Description: PGP signature
Bug#571949: nmu: liblouisxml_2.1.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, liblouis has changed its ABI and thus the library package name. liblouisxml now needs to be rebuilt against the new library (it is the only package using it). nmu liblouisxml_2.1.0-1 . ALL . -m "Rebuild against the new liblouis2" Thanks -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100228135718.ga30...@const.famille.thibault.fr
Re: RC severity for Python 2.6 related bugs
* Luca Falavigna (dktrkr...@debian.org) [100227 20:19]: > after some discussions on #debian-python, I'd like to propose > increasing severity of Python 2.6 related bugs [1] to serious. > > Some Release Team members already stated they want Python 2.6 for > Squeeze, and having more focus on those bugs gives interested developers > more chances to provide patches and eventually prepare NMUs. Normally we don't want that as NMUing important bugs is allowed as well as with RC bugs, and people who want something to change should be prepared to do the work for it. However, given the very good past record of the python people on providing bug fixes and NMUing (and that many issues are already resolved), I think this is the exception of the rule. In other words: yes, please go ahead. (I just assume that you all will continue to work on bug fixes, NMUs etc.) Thanks for your great work on python. Cheers, Andi -- 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/20100228114547.gt19...@mails.so.argh.org
Re: [stable] please approve upload of liblog-handler-perl 0.45-1+lenny1 fixing #502853
-=| Adam D. Barratt, Sat, Feb 27, 2010 at 12:13:45PM + |=- > On Sat, 2010-02-27 at 11:56 +0200, Damyan Ivanov wrote: > > Please approve the upload of liblog-handler-perl/0.45-1+lenny1. > > This would fix a grave bug, #502853 in stable. > > Please go ahead. Uploaded. Thanks! signature.asc Description: Digital signature
Re: swath outdated on mipsel
* Marc 'HE' Brockschmidt (h...@ftwca.de) [100228 12:05]: > Theppitak Karoonboonyanan writes: > > swath 0.4.0-4 appears to build succesfully on mipsel buildd [1] but it's not > > installed yet [2]. What can I do to get it into testing? > > It just needed the build admin to sign the build log. That happened now, > the package has been uploaded and installed into the archive. In this case, the log was lost. Mailing $a...@buildd.d.o is more appropriate (but I cleaned up logs a bit now). Cheers, Andi -- 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/20100228114254.gs19...@mails.so.argh.org
Re: binNMUs for hdf5
Thomas Weber writes: > On Mon, Feb 22, 2010 at 01:39:32PM +0100, Marc 'HE' Brockschmidt wrote: >> Thomas Weber writes: >> > please schedule the following binNMUS: >> Done. > Now, two more > > nmu octave-communications . ALL . -m "Rebuild against hdf5" > dw octave-communications . ALL . -m "octave-signal (>= 1.0.10-2)" > > nmu octave-econometrics . ALL . -m "Rebuild against hdf5" Scheduled, thanks for the note. Marc -- Fachbegriffe der Informatik - Einfach erklärt (221:leistungsbezogene Entlohnung) Der Vertriebler, der das Produkt verkauft bekommt das doppelte von dem Entwickler, das das Produkt entworfen und programmiert hat. (Juergen Ernst Guenther) pgpk0IdTnolA0.pgp Description: PGP signature
Re: gettext, autopoint and cvs
Santiago Vila writes: > I've decided to implement "Plan B" anyway: create autopoint as an > empty package which depends on gettext and cvs, as doing so will not > break packages currently having cvs in their build-depends. Then will > submit normal bugs asking to change their build-depends. Thanks, this will make this easier for the release team. You may file them as important, though. You may want to use user-tags to mark these bugs, for easier tracking of the transition. > Depending on how fast those bugs are fixed, we can decide about making > this transition a release goal or not. Yes, I guess so. Marc -- Fachbegriffe der Informatik - Einfach erklärt 32: Vaporware Dampf, den man der Konkurrenz macht. (nach Peter Berlich) pgpHuCt58BqXi.pgp Description: PGP signature
Re: OK to update Boost defaults?
"Steve M. Robbins" writes: > So, three questions: > > 1. Is it appropriate to change boost-defaults now (from a transitions >point of view)? No. We are currently trying to work out the hdf5 and ghc6 transitions and have enormous buildd backlogs on mips*, making a binNMU campagain for long-building packages (and let's face it, most of boost users take more than a few seconds to build...) a problem right now. > 2. If so, is it a problem to have boost-defaults point to a version >not yet in testing? Yes, this could complicate matters. > 3. If so, would you advise waiting for 1.42 to transition, or >to update to 1.41 now then update to 1.42 when it does transition? No, please switch to 1.42 directly. Marc -- Fachbegriffe der Informatik - Einfach erklärt 217: geräteunabhängig Sieht nirgends gut aus. Ist nicht Herstellers Schuld. (Dietz Proepper) pgpA5FIJ3F8ih.pgp Description: PGP signature
Re: swath outdated on mipsel
Theppitak Karoonboonyanan writes: > swath 0.4.0-4 appears to build succesfully on mipsel buildd [1] but it's not > installed yet [2]. What can I do to get it into testing? It just needed the build admin to sign the build log. That happened now, the package has been uploaded and installed into the archive. Marc -- BOFH #241: _Rosin_ core solder? But... pgp2NvfPkZQib.pgp Description: PGP signature
OK to update Boost defaults?
Hi Release Team, [Please cc me on replies, thanks] I have prepared an update to boost-defaults. I'd like some guidance as to whether it is appropriate to upload now. At present, boost-defaults points to 1.40. Since Boost 1.42 is uploaded and built on most architectures, I am considering leapfrogging 1.41 and setting defaults to 1.42. So, three questions: 1. Is it appropriate to change boost-defaults now (from a transitions point of view)? 2. If so, is it a problem to have boost-defaults point to a version not yet in testing? 3. If so, would you advise waiting for 1.42 to transition, or to update to 1.41 now then update to 1.42 when it does transition? Thanks, -Steve P.S. The boost-defaults strategy was hashed out on debian-release in the Spring of 2009. See threads starting at: http://lists.debian.org/debian-release/2009/03/msg00147.html http://lists.debian.org/debian-release/2009/04/msg00251.html http://lists.debian.org/debian-release/2009/05/msg00011.html signature.asc Description: Digital signature
