Re: TS for Release Assistents
On Mon, Sep 10, 2007 at 04:45:13AM +, Robert Edmonds wrote: 368226 Quagga does intentionally not upgrade automatically Maintainer forgot to close the bug. Perhaps you should use a versioned close on this bug, so that the status of the fix can be tracked in etch and lenny? 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Steve Langasek wrote: On Mon, Sep 10, 2007 at 04:45:13AM +, Robert Edmonds wrote: 368226 Quagga does intentionally not upgrade automatically Maintainer forgot to close the bug. Perhaps you should use a versioned close on this bug, so that the status of the fix can be tracked in etch and lenny? Done. etch and lenny have the fix, in fact. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: TS for Release Assistents
On Thu, Aug 30, 2007 at 01:29:48PM +, Pierre Habouzit wrote: On jeu, aoû 30, 2007 at 11:51:36 +, Luk Claes wrote: Pierre Habouzit 393403 Source package contains non-free IETF RFC/I-D's NMUed. 294520 qtparted: Incorrect handling of extended partitions The patch is commited with a test in the test-suite. I don't know when the parted maintainers plan to upload, maybe I should do some more kicking around. But it's pending. 356055 loadlin: loadlin.exe cannot be built from source On this one, Sam who happens to be yasm maintainer believes upstream is not that interested about the patch of tasm symtax compat that Samuel Thibault wrote before (and that does not apply properly on recent versions anyways). I lack the time to refactor it, and I don't know yasm or tasm, so it doesn't help at all. Though, loadlin seems to be the sole way for some class of users (mostly blind people using braille ttys) to install debian in an accesibility PoV. win32-loader does not helps very well in that regard according to people I talked about this issue to. So I fear that if we want the issue to be fixe, the available options are the statu-quo (which is against DFSG) or the move to contrib. Note that what really matters is that loadlin.exe is present in our CDs. Strictly speaking, loadlin is 100% free, it's just that we don't have the tool in Debian to build it. I may be flamed to death for what I'll say, but I'm not sure why we couldn't ship a loadlin.exe on the CDs with loadlin in contrib. It seems somehow unfair to me to prevent blind people to install debian properly (and not use loadlin.exe ever after that) because not enough well-sighted people are interested in fixing it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpg3imFbkHcD.pgp Description: PGP signature
Re: TS for Release Assistents
On 2007-08-30, Luk Claes [EMAIL PROTECTED] wrote: Once you've done as much as you're able for the two weeks, make sure the bug report includes all the up to date information, then reply to this mail (to debian-release@lists.debian.org) with a brief summary of what's happened and what the next step (if any) is. If you think the package requires removal from testing (or the bug can be fixed by other means from the release team), feel free to forward the proposed fix as soon as possible to the release team. If the above is just too easy, for extra credit you can take on some of the other older bugs from the RC bug list. If you do, include those in your mail next week. If you're not able to fix a bug, ask for help or do as much as you can, then leave it; don't get in over your head, or, worse, upload an NMU that's broken or doesn't completely fix the problem. Here's my report: 423823 retchmail: FTBFS Merged RC bugs 387989, 423823, 423966, 423967. Fixed by uploading wvstreams 4.2.2-2.3. 368226 Quagga does intentionally not upgrade automatically Maintainer forgot to close the bug. 405186 docbook2x: FTBFS According to Daniel Leidert, not reproducible in docbook2x = 0.8.7. Fixed in libxml-sax-perl 0.16-0.1 (verified that docbook2x 0.8.3 built with this version) along with RC bug #419757. For extra credit: Fixed the following bugs blocking the invoke-rc.d transition (#438885): 341413 dict-easton 367734 dict-hitchcock 367725 net-acct 341415 dict-gcide 348259 dict-elements 367729 rbootd (additionally, FTBFS bug #379635) 367733 dict-moby-thesaurus 367737 dict-bouvier 367740 dict-gazetteer2k-zips 367755 tama 440574 memlockd (along with RC bugs #418666, #431529) Fixed: 409473 424601 anon-proxy FTBFS Pending fixes: 441449 memlockd FTBFS anon-proxy is interesting. It looks like it's been abandoned by the maintainer and the upstream[0] has rewritten it in Java. Its open bugs lead me to believe it's not suitable for testing or a release. [0] http://anon.inf.tu-dresden.de/index_en.html -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Aug 30, 2007 at 13:51:36 +0200, Luk Claes wrote: Julien Cristau 423966 wvdial: FTBFS: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available Robert took care of that one before I had a chance :) 393361 Source package contains non-free IETF RFC/I-D's NMUed, needs a week and a sparc build before it gets to testing. 403611 xemacs21-basesupport: xsl mode interprets delete key inconsistently I don't think a bug in one emacs mode in this package should be considered RC. I'm away next week[0], so probably won't have time to follow up on things before I get back on the 16th. Cheers, Julien [0] http://www2.unil.ch/logique/GAMES07/ signature.asc Description: Digital signature
Re: TS for Release Assistents
On 2007-08-30, Robert Edmonds [EMAIL PROTECTED] wrote: On 2007-08-30, Luk Claes [EMAIL PROTECTED] wrote: 423823 retchmail: FTBFS: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available C++ headers are Turing-complete -- the bug is actually in the wvstreams source. Merged with #387989 and #423967, and NMU'd wvstreams (#440245). retchmail will build once wvstreams 4.2.2-2.3 is in the archive. RC bugs #387989, #423823, #423966, #423967 are all fixed by this upload. (But they're all the same bug -- do I get credit for four? :) -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
TS for Release Assistents
[Cced the victi^Wpotential assistents this time - next time get it from the list :] Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Robert Edmonds 423823 retchmail: FTBFS: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available 368226 Quagga does intentionally not upgrade automatically 405186 docbook2x: FTBFS: reference to nonexistent nodes Julien Cristau 423966 wvdial: FTBFS: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available 393361 Source package contains non-free IETF RFC/I-D's 403611 xemacs21-basesupport: xsl mode interprets delete key inconsistently Pierre Habouzit 393403 Source package contains non-free IETF RFC/I-D's 294520 qtparted: Incorrect handling of extended partitions 356055 loadlin: loadlin.exe cannot be built from source Neil McGovern 393425 Source package contains non-free IETF RFC/I-D's 395252 requires too much security maintainance work due to embedded ffmpeg copy 402482 busybox gunzip / zcat fail to decompress validly gzipped files Solve can mean many things. The best solution is a fixed package being uploaded to the archive that satisfies the submitter, the maintainer, and everyone else. Alternatively, it might be that it's a non-bug or has already been fixed, and you can satisfy everyone that that's the case. Another option is that the bug might be unfixable, and the package may need to be removed from testing or unstable or both. In some cases the bug may be specific to woody or sarge. In some cases the submitter might not be contactable to verify the problem's solved. By this time in two weeks, you should aim for each of the bugs under your name to have moved forward as far as possible, ideally closed. If it's not clear what the problem is, find out. If it's not clear what would fix it, work it out. If the fix isn't entirely clear, spell it out. If it's fixed upstream, point that out. Prepare a patch if there isn't already one. Do an NMU if appropriate. You get the idea. You might want to consider spending a few minutes looking at each bug now, and, if necessary, ask for any more information that's needed from the submitter, so that you have the information when you've got some more time to spend on it later. Once you've done as much as you're able for the two weeks, make sure the bug report includes all the up to date information, then reply to this mail (to debian-release@lists.debian.org) with a brief summary of what's happened and what the next step (if any) is. If you think the package requires removal from testing (or the bug can be fixed by other means from the release team), feel free to forward the proposed fix as soon as possible to the release team. If the above is just too easy, for extra credit you can take on some of the other older bugs from the RC bug list. If you do, include those in your mail next week. If you're not able to fix a bug, ask for help or do as much as you can, then leave it; don't get in over your head, or, worse, upload an NMU that's broken or doesn't completely fix the problem. Of course, you are allowed to use all resources available for bug fixing; this excludes the help of the current release team members for obvious reasons. :) So, have fun, Your Release Managers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On jeu, aoû 30, 2007 at 11:51:36 +, Luk Claes wrote: Pierre Habouzit 393403 Source package contains non-free IETF RFC/I-D's NMUed. 294520 qtparted: Incorrect handling of extended partitions The proposing fix has been reviewed by Otavio and committed in the parted git repository, and it seems to be right. 15:15 otavio | MadCoder: Sent to parted-devel for last review. 15:15 otavio | MadCoder: it ought to be parted of 1.8.9 and next upload So I guess it's off my duty now. 356055 loadlin: loadlin.exe cannot be built from source That one is a b*tch :) Yasm upstream do not seem to care about tasm compatibility at _all_. So I'm now investigating wether loadlin is still needed or not (last time it was needed for accessibility reasons, I don't know if there is alternatives e.g. if win32-loader works properly for blind people). Investigating. But at a first glance, I don't see an immediate way to have this fixed. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcVzAEWy72x.pgp Description: PGP signature
Re: TS for Release Assistents
Pierre Habouzit wrote: On jeu, aoû 30, 2007 at 11:51:36 +, Luk Claes wrote: Pierre Habouzit 393403 Source package contains non-free IETF RFC/I-D's NMUed. Hmm, it seems you didn't follow the NMU rules, for instance I see no patch in the bug log nor a trace of informing the maintainer days ago about your intention to NMU? 294520 qtparted: Incorrect handling of extended partitions The proposing fix has been reviewed by Otavio and committed in the parted git repository, and it seems to be right. 15:15 otavio | MadCoder: Sent to parted-devel for last review. 15:15 otavio | MadCoder: it ought to be parted of 1.8.9 and next upload So I guess it's off my duty now. Ok. 356055 loadlin: loadlin.exe cannot be built from source That one is a b*tch :) Yasm upstream do not seem to care about tasm compatibility at _all_. So I'm now investigating wether loadlin is still needed or not (last time it was needed for accessibility reasons, I don't know if there is alternatives e.g. if win32-loader works properly for blind people). Investigating. But at a first glance, I don't see an immediate way to have this fixed. Please try to reach as close as possible to 'a' fix as described in the mail and don't hesitate to fix other RC bugs (preferably not the ones appointed to other candidates ;-)) Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Hi, Am Donnerstag, den 30.08.2007, 13:51 +0200 schrieb Luk Claes: [Cced the victi^Wpotential assistents this time - next time get it from the list :] Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Robert Edmonds [..] 405186 docbook2x: FTBFS: reference to nonexistent nodes [..] JFTR: This is a bug in libxml-sax-perl, not in docbook2x - it's just the title has not been changed. So don't waste time to fix this issue in docbook2x. There we already worked around it (and IIRC the bug was not reproducible with 0.8.7/8 anymore). However, if you need my assistence (I'm responsible for docbook2x atm), don't hesitate to contact me. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Aug 30, 2007 at 01:37:28PM +, Luk Claes wrote: Pierre Habouzit wrote: On jeu, aoû 30, 2007 at 11:51:36 +, Luk Claes wrote: Pierre Habouzit 393403 Source package contains non-free IETF RFC/I-D's NMUed. Hmm, it seems you didn't follow the NMU rules, for instance I see no patch in the bug log nor a trace of informing the maintainer days ago about your intention to NMU? Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... Anyways, nmudiff sent to the bug report, I did that in the first place, but mistyped bugs.debian.org so it bounced, and you just made me notice that. 356055 loadlin: loadlin.exe cannot be built from source That one is a b*tch :) Yasm upstream do not seem to care about tasm compatibility at _all_. So I'm now investigating wether loadlin is still needed or not (last time it was needed for accessibility reasons, I don't know if there is alternatives e.g. if win32-loader works properly for blind people). Investigating. But at a first glance, I don't see an immediate way to have this fixed. Please try to reach as close as possible to 'a' fix as described in the mail and don't hesitate to fix other RC bugs (preferably not the ones appointed to other candidates ;-)) Sure, I don't consider this bug fixed yet, I have to contact people aware of accessibility issues to know if win32-loader is a proper replacement for loadlin or not. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzwwuR6zJZG.pgp Description: PGP signature
Re: TS for Release Assistents
Pierre Habouzit wrote: Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... I totally agree with you here! Could we at least write those down or at least agree on what qualifies to the 0-day NMU policy? As far as I know, it's just the we are about to release reason I am familiar with. -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Amaya wrote: Pierre Habouzit wrote: Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... I totally agree with you here! Could we at least write those down or at least agree on what qualifies to the 0-day NMU policy? As far as I know, it's just the we are about to release reason I am familiar with. From the Developer's Reference: -- At times, the release manager or an organized group of developers can announce a certain period of time in which the NMU rules are relaxed. This usually involves shortening the period during which one is to wait before uploading the fixes, and shortening the DELAYED period. It is important to notice that even in these so-called bug squashing party times, the NMU'er has to file bugs and contact the developer first, and act later. Please see Bug squashing parties, Section 7.2.2 for details. -- This is the only thing we based on us so far to relax the NMU rules... in practice this meant either a BSP or the period up to the release. I don't see any problem with having more BSPs with relaxed NMU rules that target particular type of bugs... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Amaya [EMAIL PROTECTED] writes: Pierre Habouzit wrote: Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... I totally agree with you here! Could we at least write those down or at least agree on what qualifies to the 0-day NMU policy? As far as I know, it's just the we are about to release reason I am familiar with. Acked too. If it's open for too long time and there's no activity, it's OK to NMU it. The only exception is if the maintainer is active and easy to contact so is nice to coodinate with him/her. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On 30/08/07 at 12:40 -0300, Otavio Salvador wrote: Amaya [EMAIL PROTECTED] writes: Pierre Habouzit wrote: Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... I totally agree with you here! Could we at least write those down or at least agree on what qualifies to the 0-day NMU policy? As far as I know, it's just the we are about to release reason I am familiar with. Acked too. If it's open for too long time and there's no activity, it's OK to NMU it. The only exception is if the maintainer is active and easy to contact so is nice to coodinate with him/her. Before the release, we had a 0-day NMU policy for bugs older than 7 days. Maybe we could have a permanent 0-day NMU policy for bugs older than 21 days, or older than a month? Also, it would be great if this could be extended to the release goals. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Lucas Nussbaum [EMAIL PROTECTED] writes: Before the release, we had a 0-day NMU policy for bugs older than 7 days. Maybe we could have a permanent 0-day NMU policy for bugs older than 21 days, or older than a month? Also, it would be great if this could be extended to the release goals. I personally think that one month is a short period of time but a bug without any action from maintainer for more then three months is, imho, a very good candidate for NMU. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On 2007-08-30, Luk Claes [EMAIL PROTECTED] wrote: 423823 retchmail: FTBFS: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available C++ headers are Turing-complete -- the bug is actually in the wvstreams source. Merged with #387989 and #423967, and NMU'd wvstreams (#440245). retchmail will build once wvstreams 4.2.2-2.3 is in the archive. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On 2007-08-30, Luk Claes [EMAIL PROTECTED] wrote: 368226 Quagga does intentionally not upgrade automatically It looks like the maintainer rewrote the prerm script to fix this but neglected to note this in the changelog or BTS. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Aug 30, 2007 at 03:48:38PM +0200, Pierre Habouzit wrote: Hmm you mean I should inform a Maintainer's package for a package whose last 4 uploads since 2006-10-27 are NMUs ? for a bug that is what, 10 months old ? Heh. It qualifies to the 0-day NMU policy for so many reasons that well... Inform, always; wait, not particularly. ie: look at the bug log, make sure you understand everything involved, create a fix, mail the bug log, upload the fix, be prepared to deal with anything that comes up. Non 0-day NMUs just add a give maintainer a chance to respond step. Cheers, aj signature.asc Description: Digital signature
Re: TS for Release Assistents
Hi, * Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [060504 14:07]: [...] Thanks for your work. Please continue this way. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Hi, thanks for your work. One comment only: * Luk Claes ([EMAIL PROTECTED]) [060504 22:48]: 311188 [ ] debian-edu-config: Messes programmatically with conffiles of other packages I made a list of the by debian-edu-config affected conffiles in /etc. Though closing the bug is only possible if debian-edu-config's behavior changes or when the packages that ship the conffiles make them adjustable via debconf or something similar. Could you please continue to track this issue? Also, the question is: what is the resolving strategy for this bug? Thanks, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Hi, * Bill Allombert ([EMAIL PROTECTED]) [060504 23:05]: On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: [Cced the victi^Wpotential assistents this time - next time get it from the list :] Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Before starting, I would like to ask how I ended up in such short list of candidates. Anyway, thanks for this great opportunuity to fix some RC bugs! Date: Sun, 24 Jul 2005 23:27:57 +0200 Message-ID: [EMAIL PROTECTED] :) Thanks for your work. Please keep it up this way - and of course, feel free to follow up the bugs that are not finally out of the release critical area. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
* A Mennucc ([EMAIL PROTECTED]) [060516 10:28]: On Mon, May 08, 2006 at 10:17:42AM +0200, A Mennucc wrote: On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: Andrea Mennucci 354650 lightspeed: segfault at start up on amd64 I converted it to GTK2; the bug submitter says that the new version is fine, so I uploaded it to unstable, as version 1.2a-6. Now bug 354650 does not 'render package unusable', so I downgraded the severity to 'normal'. So, 354650 is not a RC bug anymore. Well done. 340538 apache2: includes non-free and possibly undistributable files nobody ever answered my message http://lists.debian.org/debian-apache/2006/05/msg00022.html or other messages that I sent ... I dont know what to do... I fear in this case you need to hunt down one of the maintainers (aka uploaders) wherever you meet him, and force them to comment on that. This happens sometimes, and is of course not what one likes to happen. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Mon, May 08, 2006 at 10:17:42AM +0200, A Mennucc wrote: On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: Andrea Mennucci 354650 lightspeed: segfault at start up on amd64 I converted it to GTK2; the bug submitter says that the new version is fine, so I uploaded it to unstable, as version 1.2a-6. Now bug 354650 does not 'render package unusable', so I downgraded the severity to 'normal'. So, 354650 is not a RC bug anymore. 340538 apache2: includes non-free and possibly undistributable files nobody ever answered my message http://lists.debian.org/debian-apache/2006/05/msg00022.html or other messages that I sent ... I dont know what to do... --- I am currently an unemplyed Release Assistant. a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: Andrea Mennucci 354650 lightspeed: segfault at start up on amd64 I converted it to GTK2, and uploaded it to experimental, as version 1.2a-3 ; if anybody has a AMD64 machine on the desktop, please test it. In 1.2a-3 there is a bug when saving snapshots of the window, so it is not ready for unstable. 340538 apache2: includes non-free and possibly undistributable files hmmm the apache team talked about packaging 2.2 in December , (see bug bug 344072 (*)) then all went dead; from time to time there is a message such as http://lists.debian.org/debian-apache/2006/03/msg00059.html http://lists.debian.org/debian-apache/2006/04/msg00039.html http://lists.debian.org/debian-apache/2006/05/msg00022.html but no answer to them ever (and no answer to my message as well). So the situation is fishy: I may NMU apache2 in its current version 2.0, and replace all non-free code with free code; but this would not serve our users well. Truth is, apache2 would need a lot of work: it has 3 RC bugs open and 110 IN bugs open. If apache2 is not actively mantained, maybe the best thing would be to look for someone with time and interest to actively mantain it; or otherwise to just drop it off the archives. (*) Actually, according to [EMAIL PROTECTED] (see bug 344072), in Feb apache2.2 was awaiting some final polish, so it would be nice if he may publish the partial work somewhere a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
Re: TS for Release Assistents
Hi Andrea, On Sat, Apr 29, 2006 at 07:46:43PM +0200, wrote: ^^ You might want to check that you set valid From: headers in your mails. :) On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: 354650 lightspeed: segfault at start up on amd64 first and foremost: this is now considered to be a bug in libgtk1.2 ... is it really worthy to spend a lot of time debugging it (*), since libgtk1.2 is obsolete and not mantained upstream? so here is a possible line of action: I can (probably) modify lightspeed to use libgtkgl2.0-dev and GTK2 ; after this, the bug 354650 severity may be set to normal. What do you think? Sure, that's an ok solution for the problem if it fixes it. I'm not really convinced that it is a library bug rather than an application bug, but, well, that's for you to figure out. :-) ps (*) I would need a amd64 running unstable to really debug this bug as it is; I have a amd64 machine running stable, but I cannot install unstable in it, it is a production machine; and it has just 366Mb free... pergolesi.debian.org has unstable amd64 chroots that are available to all developers. Any build-dependencies you need, you can get installed for you with a simple mail to debian-admin. 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: TS for Release Assistents
On Thu, May 04, 2006 at 03:19:38AM -0700, Steve Langasek wrote: Hi Andrea, You might want to check that you set valid From: headers in your mails. :) I do not know how it got wrong... anyway I have other debugging to be done 354650 lightspeed: segfault at start up on amd64 so here is a possible line of action: I can (probably) modify lightspeed to use libgtkgl2.0-dev and GTK2 ; after this, the bug 354650 severity may be set to normal. What do you think? Sure, that's an ok solution for the problem if it fixes it. I hope it will do; people are using GTK2 all the time on AMD64, so we can rule out that the GTK_BOX call will fail there. Moreover changing the library may help discover if the bug is in the app or in the library a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
Heya, Let's see what I've done. Andreas Barth [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt 354093 [ ] libnss-ldap: getent segfault when reading large uid-/gidNumbers This bug seems to be fixed in newer upstream releases. As there are other RC bugs on the package (which should also be fixed by newer upstream versions), I've asked the maintainer, Stephen Frost, what's up with the package and if he's still willing and able to maintain it on his own. This triggered some more activity from him, including communication with upstream to remove a non-free file (RFC) from the upstream tarball. Stephen plans to package the new release when it comes out, which should fix all four outstanding RC bugs. I guess this will happen in the next few weeks, I'll follow up on this. 356394 [ ] mc-foo: exception on startup This was already fixed as it turns out, but I asked the maintainer for a comment. He said that the package needs some work anyway, but that he has no time/interest in the moment, so it's OK to remove the package From etch for now. 353134 [ ] libtest-builder-tester-perl: FTBFS with perl 5.8.8 This bug is actually not solved, but the package was removed from testing and unstable already :) The module Test::Builder::Tester is now included in libtest-simple-perl (and recent versions of perl-modules), so it was enough to patch the two r-deps to depend on libtest-simple-perl (fixing #358745 and #356829 on the way) before removing the obsolete, rc-buggy libtest-builder-tester-perl package. I didn't have much free time to do other stuff, but I filed some bugs to track the xulrunner-transition and poked some of the maintainers needing to do something via IRC. See http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=xulrunner-transition;[EMAIL PROTECTED] for more infos on the bugs. I hope that these bugs, a bit of social engineering and upstream work should make it possible to remove the mozilla package from etch before we release (and replace it by seamonkey instead for those who want to use a full mozilla suite). This should also give xulrunner a good test environment, which will reduce the number of problems that we need to expect when Firefox will start to use it as basis. The nice thing of xulrunner is that it finally replaces the mess that the integration of the gecko engine was. The downside is that next year, firefox, thunderbird, galeon, ... will all depend on xulrunner, which still implements the weird mozilla library versioning scheme [1]. Marc Footnotes: [1] mostly meaning partial upgrades are someone else's problem -- BOFH #376: Budget cuts forced us to sell all the power cords for the servers. pgp9i0HTZ1c5W.pgp Description: PGP signature
Re: TS for Release Assistents
Andreas Barth wrote: [Cced the victi^Wpotential assistents this time - next time get it from the list :] Hi guys, Hi Release Managers and debian-release readers :-) Your first assignment, should you choose to accept it, is to solve the following bugs: [...] Luk Claes 335473 [ ] cricket: Completely broken with latest rrdtool package 1.2.11-0.4 This bug is fixed (closed) by the new maintainer. I filed an O bug as the previous maintainer thought he already did that some time ago. I also filed the bug upstream where it got fixed quite fast. 309932 [ ] boot-admin should not be in unstable I uploaded an NMU with the approval of one of the co-maintainers which fixes this bug by removing the boot-admin binary from the package. The actual bug in boot-admin is being worked on upstream, though boot-admin is not release quality yet. 311188 [ ] debian-edu-config: Messes programmatically with conffiles of other packages I made a list of the by debian-edu-config affected conffiles in /etc. Though closing the bug is only possible if debian-edu-config's behavior changes or when the packages that ship the conffiles make them adjustable via debconf or something similar. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: TS for Release Assistents
On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote:
[Cced the victi^Wpotential assistents this time - next time get it from the
list :]
Hi guys,
Your first assignment, should you choose to accept it, is to solve the
following bugs:
Before starting, I would like to ask how I ended up in such short list
of candidates. Anyway, thanks for this great opportunuity to fix some
RC bugs!
Bill Allombert
320375 [ ] conquest-gl: fail to start (Assertion
`window-Window.VisualInfo != ((void *)0)' failed.)
(downgraded to normal). Conquest-gl requires a visual with a least one
bit of alpha channel, and some video cards/drivers combinations do not
provide such visuals, so conquest-gl will not work there. However there
are Debian system where conquest-gl work fine so this bug should not be
RC. Moreover recent libfreeglut has replaced the assert by a more
friendly error message Visual with necessary capabilities not found.
Note that the glxinfo command display the list of visuals and their
number of bits of alpha-channel.
350407 [ ] lessdisks-terminal: modifies /etc/kernel-img.conf in
postinst
(will be fixed by maintainer upload soon) I pinged the bug and that
generated a lot of discussion. Jonas will upload a new package that put
files in /etc/kernel/post{inst,rm}.d/ instead of modifying
/etc/kernel-img.conf.
331661 [ ] extensions/*.jar ship without source code, shipped jar
files are installed
(fixed by NMU) The upstream tarball include java extensions
without providing the sources. Since theses extensions are not crucial
for most usage of the package, are built for older releases of xalan and
saxon, and that the last maintainer upload is dated October 2004, I took
the simpler route to propose a NMU to remove the extensions from the
upstream tarball. I did not get any reply so I uploaded it.
Cheers,
Bill.
pgpzL9uWg46Yq.pgp
Description: PGP signature
Re: TS for Release Assistents
On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: Your first assignment, should you choose to accept it, is to solve the following bugs: 346115 lineak-xosdplugin: doesn't print onscreen messages anymore this bug was closed 340538 apache2: includes non-free and possibly undistributable files I will look at this bug later on 354650 lightspeed: segfault at start up on amd64 first and foremost: this is now considered to be a bug in libgtk1.2 ... is it really worthy to spend a lot of time debugging it (*), since libgtk1.2 is obsolete and not mantained upstream? so here is a possible line of action: I can (probably) modify lightspeed to use libgtkgl2.0-dev and GTK2 ; after this, the bug 354650 severity may be set to normal. What do you think? a. ps (*) I would need a amd64 running unstable to really debug this bug as it is; I have a amd64 machine running stable, but I cannot install unstable in it, it is a production machine; and it has just 366Mb free... -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: Hi, Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Guido Trotter 346354 [ ] distribution of this package is likely a GPL violation 351981 [ ] muine: Fails to start 352926 [ ] System crash while prelinking causes data loss I surely accept and will work on these ASAP... Unfortunately this weekend I'm away to visit my granfather and will have a very limited internet connection (56k modem, only for a small part of the day) till sunday, and then none till wedsday! (I didn't go on vacation for now because it was only for a small number of days and I planned to have some internet connection, even if not much) Next weekend I will be partially away too, even though not for the whole time (what happens is that since the 25th of April and the 1st of May are vacations in Italy many people planned something for these two weekends)... Anyway that's why I haven't started yet and I will be able to work on it only for a time a bit more limited than usual... I have started reading the bug logs and will start contacting people ASAP... Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TS for Release Assistents
On Thu, Apr 20, 2006 at 10:36:16PM +0200, Andreas Barth wrote: [Cced the victi^Wpotential assistents this time - next time get it from the list :] Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Speaking of which, since this seems like as good a time as any and I manifestly haven't been keeping up with Debian release stuff: [EMAIL PROTECTED] ~/src/debian/webwml/cvs/webwml/english/intro$ cvs di cvs server: Diffing . Index: organization.data === RCS file: /cvs/webwml/webwml/english/intro/organization.data,v retrieving revision 1.197 diff -p -u -r1.197 organization.data --- organization.data 18 Apr 2006 19:42:30 - 1.197 +++ organization.data 21 Apr 2006 08:12:16 - @@ -83,7 +83,6 @@ job gettext domain=organizationRelease Assistants/gettext memberJoey Hess memberFrank Lichtenheld - memberColin Watson job gettext domain=organizationRelease Manager for ``stable''/gettext memberAndreas Barth membermail Martin Zobel-Helas [EMAIL PROTECTED] [EMAIL PROTECTED] ~/src/debian/webwml/cvs/webwml/english/intro$ cvs ci -m 'stepping down as Release Assistant' cvs commit: Examining . Checking in organization.data; /cvs/webwml/webwml/english/intro/organization.data,v -- organization.data new revision: 1.198; previous revision: 1.197 done [EMAIL PROTECTED] ~/src/debian/webwml/cvs/webwml/english/intro$ All the best, and good luck to the new RAs, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
