Re: Constantly Usable Testing BoF @ DebConf10
> I'd like to invite any Release and FTP team members who are attending > DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am. Im not sure I can attend this using the stream, maybe, we will see. But twerner is around in NYC, he might attend it. > The purpose of the BoF is to finally explore whether it would make sense > to implement the Constantly Usable Testing idea[1], ways to do it, and > get feedback and advice from teams that could be affected by it. > So it would be great to have some dak and britney wranglers to give advice > on topics like: > * Snapshotting testing. > * How to support upgrades from old testing snapshots to current testing? > * Installability/usability of testing. Issues like important packages > being temporarily removed due to RC bugs. > * Does testing get enough testing? Would having users use CUT improve > that and help the quality of stable releases, or the opposite? For dak side - it is not too hard to add another suite, exported to the public or not. What bothers most is the size of a dists/ dir: 32M experimental 1.9Glenny 4.0Mlenny-proposed-updates 3.3Gsid 401Msqueeze 2.0Msqueeze-proposed-updates If we copy testing as is, then thats another 400mb hit there on index files that regularly change. Can we go without contents files? Thats already 200mb. (The pure size isn't a problem, in a tree that has hundreds of gigs, but dists/ is what changes a lot, compared to files in pool/ and that gets a good part of traffic on the mirrors. And our snapshot archive also has to store all the indexes... Having less == good). (And if we can also start this suite not having any bz2 index files, that would be doubly good. They are a pure waste of space, gzip is so much better for our mirrors (--rsyncable does gain a lot)). Also, technically, ftpmaster doesnt want to have to do much with the suite: We run the service, someone else does the work :) That is, we would want a team that has the say about it and that supplies us with an input file that defines how the suite has to look. Once, twice or four times a day. (That will be "Heidi" Format then) What will be the rules for the versions in CUT? It will definitely be >= stable. Also, I think <= unstable. No specific relation with testing? Though I think it should be somewhere <= testing and every update should go via testing first, it could be wanted to directly get a new version from unstable to CUT, while britney not yet let that migrate to testing. Especially if it ends up being 2 processes that define how testing/cut look. How about the testing-proposed-update suite and the relations there? Does this suite also need a p-u one? (I dont think so) -- bye, Joerg "That's just f***ing great, now the bar for being a cool guy in free software just got raised. It used to be you just had to write a million lines of useful code. Now you've got to get a subpoena from SCO to be cool." -- 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/877hk98vbb@delenn.ganneff.de
Uploading linux-2.6
linux-2.6 version 2.6.32-18 should transition to testing in 2 days. Following that, I intend to upload 2.6.32-19 incorporating stable release 2.6.32.17 and DRM changes from stable release 2.6.33.7. I also intend to upload 2.6.35 to experimental shortly. Shout if there's anything I should wait for. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: [SRM] Stable update for quik?
Hi, On Mon, July 19, 2010 16:14, Aurelien Jarno wrote: > quik, a bootloader for PowerMac, is really buggy in stable as it was not > until not so long ago in testing/unstable. Bug #513182 makes > debian-installer unusable on OldWorld machine, and bug #512429 makes > the package fails to build from source. > > It has been recently fixed in testing/unstable thanks to Vagrant > Cascadian and Lennart Sorensen, and it seems the same should also be > done in stable. Note that for example the OldWorld machine is the one > best emulated in QEMU. > > I have prepared a patch (see file attached), would it be ok for an > upload to stable? Apologies for the delay in getting back to you. Please go ahead. 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/c47ff68bf005b6a8b4aa1b502cd50d9c.squir...@adsl.funkybadger.org
Re: Constantly Usable Testing BoF @ DebConf10
Hi, On 01/08/10 at 13:35 -0400, Joey Hess wrote: > I'd like to invite any Release and FTP team members who are attending > DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am. > > http://penta.debconf.org/dc10_schedule/events/681.en.html > > The purpose of the BoF is to finally explore whether it would make sense > to implement the Constantly Usable Testing idea[1], ways to do it, and > get feedback and advice from teams that could be affected by it. While I agree that it would be nice that Debian committed to providing something in the lines of CUT, I'm wondering if it's not too early to talk about implementation details. Things we could also discuss in the BOF: - what's the "mission statement" for this "thing"? - which level of support/guarantees do we want to provide to users? - what are the possible implementations? - what makes current testing not suitable for that? (I can think of: security support, transitions delaying packages migration to testing, delayed migrations of important bugfixes, crappy name for something that we want users to actually use) - how do we make sure the goals of this "thing" don't conflict with Debian's goal of releasing stable releases? Should we really re-use testing for that "thing", or create another suite/branch/whatever? - Lucas -- 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/20100801182848.ga24...@xanadu.blop.info
Constantly Usable Testing BoF @ DebConf10
I'd like to invite any Release and FTP team members who are attending DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am. http://penta.debconf.org/dc10_schedule/events/681.en.html The purpose of the BoF is to finally explore whether it would make sense to implement the Constantly Usable Testing idea[1], ways to do it, and get feedback and advice from teams that could be affected by it. So it would be great to have some dak and britney wranglers to give advice on topics like: * Snapshotting testing. * How to support upgrades from old testing snapshots to current testing? * Installability/usability of testing. Issues like important packages being temporarily removed due to RC bugs. * Does testing get enough testing? Would having users use CUT improve that and help the quality of stable releases, or the opposite? -- see shy jo [1] http://kitenet.net/~joey/code/debian/cut/ signature.asc Description: Digital signature
Bug#589689: transition to libjack-jackd2-0 breaks many packages
Copying this to the appropriate bug... On 01/08/10 11:38, Adam D. Barratt wrote: > On Fri, July 30, 2010 19:02, Felipe Sateler wrote: >> On 30/07/10 13:25, Adam D. Barratt wrote: >>> - ardour: FTBFS on sparc (#590863) >>> - csound: FTBFS on hppa (#590948) >>> - slv2: FTBFS on hppa (#590976) >> >> All these three look like problems with the buildd host/toolchain. >> CSound hangs in a doxygen call that has not been modified since the -1 >> upload. Trying to build that same documentation in paer gives me >> segmentation faults in doxygen in different stages almost every time (I >> managed to build it after a few retries). > > Of the four tries on the buildds, csound hung in doxygen twice and during > the source build twice, afaics. That and the fact that it needed several > tries on paer suggest that even if we it managed to build after another > attempt or three, the next binNMU or sourceful upload may well have the > same problem(s). Indeed. How do you suggest working through this? Facts: 1. The build hangs unpredictably on a doxygen call. 2. The doxygen call is in build-indep (so it is not strictly necessary for binary only builds, but gets executed anyway). I can move the doxygen call away from there into binary-indep, but that feels like a hack to me. I have been trying to build the doxygen documentation a few times, and it looks like either doxygen is doing something wrong with pthread mutex calls or the hppa kernel/libc are doing something wrong with the calls doxygen makes. I'm getting some assertion failures now too: doxygen: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. All hangs and segmentation faults seem to happen inside synchronization calls (futex calls). I have not been able to reproduce the hang in the Generating docs for compound ... stage. > >> The paer sid chroot does not >> have the necessary build deps, so I can't binNMU it myself. > > You can, you just need to request that the build-deps be installed. Not necessary, since the faulty command (doxygen) is already installed and I do not plan on working around this bug by manually uploading a package that will have the same problem again. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Bug#589689: transition to libjack-jackd2-0 breaks many packages
On Fri, July 30, 2010 19:02, Felipe Sateler wrote: > On 30/07/10 13:25, Adam D. Barratt wrote: >> - ardour: FTBFS on sparc (#590863) >> - csound: FTBFS on hppa (#590948) >> - slv2: FTBFS on hppa (#590976) > > All these three look like problems with the buildd host/toolchain. > CSound hangs in a doxygen call that has not been modified since the -1 > upload. Trying to build that same documentation in paer gives me > segmentation faults in doxygen in different stages almost every time (I > managed to build it after a few retries). Of the four tries on the buildds, csound hung in doxygen twice and during the source build twice, afaics. That and the fact that it needed several tries on paer suggest that even if we it managed to build after another attempt or three, the next binNMU or sourceful upload may well have the same problem(s). > The paer sid chroot does not > have the necessary build deps, so I can't binNMU it myself. You can, you just need to request that the build-deps be installed. > slv2 hangs in a file copy operation, apparently. slv2 appears to have suffered from a known problem with waf's parallel functionality on hppa. The new sourceful upload has built fine on hppa. 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/2228bece93f73886d7874b212d6085c1.squir...@adsl.funkybadger.org
NEW changes in proposedupdates
Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_i386.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_alpha.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_amd64.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_arm.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_armel.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_hppa.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_ia64.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_mips.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_mipsel.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_powerpc.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_s390.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny4_sparc.changes ACCEPT Processing changes file: ghostscript_8.62.dfsg.1-3.2lenny2_i386.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/e1ofzer-00018s...@franck.debian.org
