KDE 3.3.1 in sarge, closes many RC bugs
tags 285126 -sarge tags 271256 -sarge tags 285126 -sarge tags 252670 -sarge tags 278173 +sid tags 253701 -sarge tags 247243 -sarge thanks KDE 3.3 has been accepted into testing and should be visible from the mirrors starting tomorrow. I believe all of these RC bugs can therefore be closed. Many thanks to the KDE team for their efforts in making this happen, and to Anthony Towns for handholding britney through the transition. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Pushing (frozen) ifupdown (0.6.4-4.10) into sarge?
On Mon, Dec 20, 2004 at 03:24:04PM +0100, Javier Fernández-Sanguino Peña wrote: > Ifupdown latest version (0.6.4-4.10) has been out for quite a while (since > August) and if includes: translation fixes (#248717, #249233, #247772), > documentation fixes (including #259609, #247772, #255218 ) and normal bug > fixes (#250713, #245067, #242607, #255228, #121755, #258965, #255574, > #242537, #242527 some of which have bitten new installations) and only a > new feature [1] (--exclude) intented to help fix #254705, #256680 and > #208700 in netbase (quite an easy fix, BTW). > I know this package has been frozen but, since this package has been widely > tested, and there are no RC bugs, could it be considered a candidate for > moving into sarge? > If this could be done then a new netbase version (4.20?) could be uploaded > to the archive to fix the 'deconfiguring 'lo' on shutdown' issues so that > this issue is removed from new installations of sarge... With the new > ifupdown version, the fix to the issues above is really simple and implies > just a line change in netbase's networking script. Actually, this fix has > been tested by a number of people and could be considered quite safe too. AJ, do you have a position on this changeset as the ifupdown maintainer? Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
More structureal Octave path problem [Was: Problem with octave-plplot]
John: Please try to read through -- this is from an exchange between Rafael in the role of the frustrated octave-plplot maintainer, Steve as the helpful and clueful release manager, and Dirk as an almost innocent bystander who also happens to be frustrated about a lack of octave-forge in testing. Oh, and I will also include Richard, who is ginac maintainer (and upstream hacker) whose ginac package is upheld by octave-forge as well. On Mon, Jan 03, 2005 at 05:12:23PM -0800, Steve Langasek wrote: > On Sun, Jan 02, 2005 at 01:15:10PM +0100, Rafael Laboissiere wrote: > > * Steve Langasek <[EMAIL PROTECTED]> [2005-01-01 18:57]: > > > > Please open an RC bug report, tagged sarge, against one (or both) of the > > > packages to document this issue. > > > Done: Bug#288186. > > > > Have steps been taken to ensure this kind of API-skew doesn't affect > > > testing in the future, or do you need help from the release team to craft > > > a > > > solution to that problem? > > > I think that this is the responsibility of the maintainers of the packages > > (Dirk and me). We are quite responsive to new upstream releases of Octave > > and that should be enough to ensure smooth transitions from unstable to > > testing, unless there is lost of binaries at the build daemons or compiler > > blocking in sarge, as is currently the case. > > As I've explained to Dirk on IRC, the problem is that dealing with this > issue only when the dependencies have been broken is too late. Past > experience is a strong indicator that Depends: octave2.1 (>= 2.1.64) is too > weak, because what octave-plplot actually depends on is "a version of > octave2.1 that provides octave API version 11", and we've already had at > least 4 API versions within the octave2.1 package series. Of course, > there's currently no way for octave-plplot to express such a dependency, but > there should be; probably with a virtual package, e.g., octave2.1 Provides: > octave-api-11. > > This is important because the current situation allows users to break their > systems with partial upgrades, and it also allows packages to become > out-of-sync in testing. Both are undesirable, and both are fixable in the > vast majority of cases by getting the package dependencies right. It does > mean that more handholding is (currently) required from the release team to > get octave package updates into testing, but this is a price we're willing to > pay to ensure testing is as usable as possible. > > Dirk, you spoke on IRC of packages such as kmatplot having even tighter > dependencies, requiring the exact minor version of octave2.1 that they built > against. It appears kmatplot already deals with this problem, e.g., > > Package: kmatplot > Version: 0.4-7 > Recommends: octave2.1 (>= 2.1.57), octave2.1 (<< 2.1.58) > > If octave-plplot has the same tight dependency, and not just a dependency on > the octave API version as suggested by the error message in Raphael's mail, > then the same solution is also warranted. As I tried to explain on IRC, the problem is that every /binary/ Octave module depends on the /actual/ Octave version it is built against. See here for the two most recent versions of octave-forge, and 2.1.64 and 2.1.63 respectively: [EMAIL PROTECTED]:/var/local/cache/pbuilder/result> dpkg -c octave-forge_2004.11.16-3_i386.deb | grep 2.1.64 | grep ".oct$" | tail -1 lrwxrwxrwx root/root 0 2004-12-04 11:09:54 ./usr/lib/octave/2.1.64/site/oct/i386-pc-linux-gnu/octave-forge/vpa.oct -> symbols.oct [EMAIL PROTECTED]:/var/local/cache/pbuilder/result> dpkg -c octave-forge_2004.11.16-2_i386.deb | grep 2.1.63 | grep ".oct$" | tail -1 lrwxrwxrwx root/root 0 2004-11-18 22:54:09 ./usr/lib/octave/2.1.63/site/oct/i386-pc-linux-gnu/octave-forge/vpa.oct -> symbols.oct This is nothing that Rafael or I can do anything about as John imposes it upstream (for reasons we always consider to be fair enough: frequent changes in Octave). But as Steve outlines above, it has its costs, and it really is not desirable. I think Steve's idea of using an Octave API counter may be better. John: Would it be possible to replace /usr/lib/octave/$VERSION/ with /usr/lib/octave/$APICOUNTER/ in the hope that rapid-succession uploads could have a chance of not requiring an increment to $APICOUNTER -- yet allowing you to increase the counter whenever "something significant enough" changes? Best, Dirk > > Thanks, > -- > Steve Langasek > postmodern programmer -- If you don't go with R now, you will someday. -- David Kane on r-sig-finance, 30 Nov 2004
Re: Problem with octave-plplot
On Sun, Jan 02, 2005 at 01:15:10PM +0100, Rafael Laboissiere wrote: > * Steve Langasek <[EMAIL PROTECTED]> [2005-01-01 18:57]: > > Please open an RC bug report, tagged sarge, against one (or both) of the > > packages to document this issue. > Done: Bug#288186. > > Have steps been taken to ensure this kind of API-skew doesn't affect > > testing in the future, or do you need help from the release team to craft a > > solution to that problem? > I think that this is the responsibility of the maintainers of the packages > (Dirk and me). We are quite responsive to new upstream releases of Octave > and that should be enough to ensure smooth transitions from unstable to > testing, unless there is lost of binaries at the build daemons or compiler > blocking in sarge, as is currently the case. As I've explained to Dirk on IRC, the problem is that dealing with this issue only when the dependencies have been broken is too late. Past experience is a strong indicator that Depends: octave2.1 (>= 2.1.64) is too weak, because what octave-plplot actually depends on is "a version of octave2.1 that provides octave API version 11", and we've already had at least 4 API versions within the octave2.1 package series. Of course, there's currently no way for octave-plplot to express such a dependency, but there should be; probably with a virtual package, e.g., octave2.1 Provides: octave-api-11. This is important because the current situation allows users to break their systems with partial upgrades, and it also allows packages to become out-of-sync in testing. Both are undesirable, and both are fixable in the vast majority of cases by getting the package dependencies right. It does mean that more handholding is (currently) required from the release team to get octave package updates into testing, but this is a price we're willing to pay to ensure testing is as usable as possible. Dirk, you spoke on IRC of packages such as kmatplot having even tighter dependencies, requiring the exact minor version of octave2.1 that they built against. It appears kmatplot already deals with this problem, e.g., Package: kmatplot Version: 0.4-7 Recommends: octave2.1 (>= 2.1.57), octave2.1 (<< 2.1.58) If octave-plplot has the same tight dependency, and not just a dependency on the octave API version as suggested by the error message in Raphael's mail, then the same solution is also warranted. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
[M-f-t set, I think this is offtopic for -release.] Matthew Palmer wrote: [snip] > > > Common sense would suggest that tests that have to be analysed by a human > > > being after every test run aren't particularly useful. > > > > Actually, skimming over the dozen or so failing ones, and recognizing > > they are the same as in the last run isn't that hard. > > But what does that get you? Just that GCC is as broken (or not) as it was > previously. It doesn't actually tell you whether the problems reported are > spurious or serious, does it? Well, some knowledge about gcc is reqired to interpret the failures. The testsuite provides only some pointers. Thiemo signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
On Tue, Jan 04, 2005 at 12:20:36AM +0100, Thiemo Seufer wrote: > Matthew Palmer wrote: > [snip] > > > > So what are the tests useful for, then? They're obviously useless as a > > > > gauge of quality, because failing tests apparently don't indicate a > > > > flaw in > > > > the software. > > > > > > A little common sense, please? The test results have to be interpreted > > > by a human being. There are about twenty thousand tests and most > > > architectures fail maybe a few dozen. > > > > Common sense would suggest that tests that have to be analysed by a human > > being after every test run aren't particularly useful. > > Actually, skimming over the dozen or so failing ones, and recognizing > they are the same as in the last run isn't that hard. But what does that get you? Just that GCC is as broken (or not) as it was previously. It doesn't actually tell you whether the problems reported are spurious or serious, does it? - Matt signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
Matthew Palmer wrote: [snip] > > > So what are the tests useful for, then? They're obviously useless as a > > > gauge of quality, because failing tests apparently don't indicate a flaw > > > in > > > the software. > > > > A little common sense, please? The test results have to be interpreted > > by a human being. There are about twenty thousand tests and most > > architectures fail maybe a few dozen. > > Common sense would suggest that tests that have to be analysed by a human > being after every test run aren't particularly useful. Actually, skimming over the dozen or so failing ones, and recognizing they are the same as in the last run isn't that hard. > * The person needs to be sufficiently clued to work out which tests are > actually important and which ones are fluff. I couldn't make that call, if > buildd admins aren't compiler experts I wouldn't expect them to be able to > make that call, and I wouldn't expect them to need to. Buildlogs are public, and the test summary of a build is posted to -gcc. It doesn't go unchecked. Thiemo signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
On Mon, Jan 03, 2005 at 05:12:57PM -0500, Daniel Jacobowitz wrote: > On Tue, Jan 04, 2005 at 08:47:45AM +1100, Matthew Palmer wrote: > > On Mon, Jan 03, 2005 at 02:07:59PM +, James Troup wrote: > > > Matthew Palmer <[EMAIL PROTECTED]> writes: > > > >> would pretty much ensure that the package never, ever builds. And > > > > > > > > Well, if it's always broken, we don't really want it, do we? > > > > > > If 'failing tests == broken' then we wouldn't have a working compiler > > > for any architecture and/or for any release. I think there's a small > > > flaw in your logic. > > > > So what are the tests useful for, then? They're obviously useless as a > > gauge of quality, because failing tests apparently don't indicate a flaw in > > the software. > > A little common sense, please? The test results have to be interpreted > by a human being. There are about twenty thousand tests and most > architectures fail maybe a few dozen. Common sense would suggest that tests that have to be analysed by a human being after every test run aren't particularly useful. * The person needs to be sufficiently clued to work out which tests are actually important and which ones are fluff. I couldn't make that call, if buildd admins aren't compiler experts I wouldn't expect them to be able to make that call, and I wouldn't expect them to need to. * If your usually clued test-analyst is having a bad day, they might dismiss a critical failed test as being harmless, resulting in problems passing through QA that *were* picked up by the test suite but were ignored. * Are all of the possible exceptions to tests passing well documented? If not, then if your clued test-analyst takes a bus between the eyes, you're down to guessing at which test failures are real. * If your test failures are documented, then you can turn that list into a machine-readable list of tests to not run on particular architectures. This way, if new tests fail, they stand out like dogs' bollocks, and your programmers will know that something's gone wrong. It may eventually come to pass that the problem is put on the "ignore" list, but until then it's a big red flag which is waving in the air and saying "there's a problem here, look at me". If you've got one real red flag in a field of ignorable ones, it gets real hard to pick out of the crowd. * Tests are supposed to be a "here be monsters" type of thing. If your programmers get into the habit of ignoring test failures because "they're harmless", they *will* ignore real problems as well. - Matt signature.asc Description: Digital signature
Re: quik into testing
Ce jour Sun, 02 Jan 2005, Steve Langasek a dit: > On Thu, Dec 23, 2004 at 05:48:52PM +, [EMAIL PROTECTED] wrote: > > i'm one of the maintainers for quik. Peter De Schrijver is the other > > one. as you may well know, quik is in base and priority important, and > > base is frozen. it has fixes for the used to be outstanding bug with > > large kernels, and supports initrd (the latter being a long-awaited > > "feature" for it). > > > therefore, i think it needs to get into testing-proposed-updates ASAP. > > That would be testing, not testing-proposed-updates, since AIUI you are > proposing that the version currently in unstable (which includes the fixes) > be included in sarge. > > However, this issue is currently blocked by RC bug #288096, which I see > Frank filed yesterday. Once this is fixed in sid, we can reconsider > promoting the package to testing; the threshold is otherwise fairly low for > getting an update for this package approved, since the impact of individual > bootloader packages on the rest of the installer is minimal. > > Thanks, > -- > Steve Langasek > postmodern programmer yes, and it's waiting for someone to sponsor the upload for 2 or 3 days now already *hint* *hint*. e.c./ -- Cold pizza and cold coffee, second best thing to cold pizza and warm beer. -- me signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
On Tue, Jan 04, 2005 at 08:47:45AM +1100, Matthew Palmer wrote: > On Mon, Jan 03, 2005 at 02:07:59PM +, James Troup wrote: > > Matthew Palmer <[EMAIL PROTECTED]> writes: > > >> would pretty much ensure that the package never, ever builds. And > > > > > > Well, if it's always broken, we don't really want it, do we? > > > > If 'failing tests == broken' then we wouldn't have a working compiler > > for any architecture and/or for any release. I think there's a small > > flaw in your logic. > > So what are the tests useful for, then? They're obviously useless as a > gauge of quality, because failing tests apparently don't indicate a flaw in > the software. A little common sense, please? The test results have to be interpreted by a human being. There are about twenty thousand tests and most architectures fail maybe a few dozen. -- Daniel Jacobowitz
Re: gcc-3.4 emits large amounts of test failures
On Mon, Jan 03, 2005 at 02:07:59PM +, James Troup wrote: > Matthew Palmer <[EMAIL PROTECTED]> writes: > >> would pretty much ensure that the package never, ever builds. And > > > > Well, if it's always broken, we don't really want it, do we? > > If 'failing tests == broken' then we wouldn't have a working compiler > for any architecture and/or for any release. I think there's a small > flaw in your logic. So what are the tests useful for, then? They're obviously useless as a gauge of quality, because failing tests apparently don't indicate a flaw in the software. - Matt signature.asc Description: Digital signature
Re: Bastian Blank (MIA?) and zope-zwiki
On Mon, Jan 03, 2005 at 12:44:07PM +0100, Jeroen van Wolffelaar wrote: > On Sun, Jan 02, 2005 at 11:13:50PM -0700, Joel Aelwyn wrote: > > So, upon running into some issues with it recently, I pulled up the QA > > page for zope-zwiki, and realized that it is, to put it mildly, "not in > > great shape". This message is to check with Bastian as to whether he is > > active, wants to keep zope-zwiki, and intends to update it (last upload > > 2003-05-03, looks to have never made it into Testing due to bugs, and has a > > Grave(security) bug open against it for 38 days now). > > If you'd have done some minimal checking[1], you'd have noticed that > Bastian Blank is not Missing In Action, in any case. To be frank, I don't consider the LDAP last-seen to be the only determiner of MIA - especially not if something is in the state that zope-zwiki is, without any maintainer comments in grave bugs for 1+ month. (I was also having issues with the LDAP search, but I suspect that to primarily be user error...) Thus, I asked. > I do agree that zoke-zwiki doesn't look in a good shape though. As > currently a 0-day NMU policy is in effect for release-critical issues, > you're free to use this policy to NMU the package (however, read on > below). > > > If not, my intent is to package and upload a reasonably current version > > (since 0.37 and 0.38 should both fix the security bug, and there appears > > to be minimal use in fixing 0.18 as it is almost two years out of date), > > including a pass through the bug list to tag or close those that appear to > > be fixed by the new version. > > If you're not maintainer, you can always look through other people's > buglists, and tag those bugs 'fixed' that you believe shouldn't be open > anymore. Both true - but updating the version is not suitable to an NMU, and as I said previously, I don't feel that just patching the security issue on a two year old release and trying to get that into our current release would benefit anyone (seeing what can be done about a security update for Woody is, of course, a different matter). > > Since I need the package with relative speed, I'll be doing a local version > > ASAP, but I will wait until someone can either confirm Bastian as being > > a known MIA, or I get a response, to upload anything to the main archive > > (honestly, it's in bad enough shape that I don't feel doing an NMU just to > > have the default 1 week delay is going to do anyone much good). Instead, > > I'll wait at least one week before kidnapping the package, more if folks > > feel it is warranted. > > If you suspect people to be MIA, better contact [EMAIL PROTECTED] with > your suspection, as then _all_ packages need to get looked after. Also, > people can be on vacation or just very temporarily away, and it's polite > to give them a bit more time to react. This also being why I asked the lists, since I had some recollection of having seen Bastian's name recently, but it didn't seem consistant with the bug state, so I wasn't sure I wasn't mixing up people. > This is not the case here though, I asked Bastian Blank, and it appears > to be a misunderstanding: Someone showed interest in the package quite > some time ago, Bastian assumed he'd take care of it, but to day this > someone didn't yet followup, with as result the current situation. > > In a moment I'm going to file an orphan bug, and set you as the adopter, > so you can then adopt the package anytime you wish by uploading with > "Adopted package (Closes: #the-bug-I'm-about-to-submit)", and meanwhile, > you can really close bugs etc :). > > Most times, just mailing a maintainer privately works fine if you're > concerned about a package, it doesn't happen really often the people > don't reply at all. True, and had the last upload not been two years ago, or the grave bug not been as it stood, I probably wouldn't have done anything (at least for a couple of weeks) other than that. In any case, the above explains what's up, and I'll get to work on the package. Bastian, my apologies if any of this came across as rude; that really wasn't my intent. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: any objections to uploading tiff 3.7.1 to unstable?
Steve Langasek <[EMAIL PROTECTED]> writes: > As this package is not frozen, and you have asserted that the library does > not break backwards compatibility, I see no reason to object to an upload of > 3.7.1 to unstable. Please only upload with low urgency, however, so that we > have the full 10-day minimum period for other eyeballs to notice bugs before > it reaches testing. > > It appears that 3.7.0-2 is still held up in NEW; if 3.7.1 will also be held > up from reaching unstable for the same reason, I'm not overly concerned > about its impact on the KDE 3.3 transition, which appears to be ready to go > without any further rebuilds of the core KDE packages. Thanks for the reply. I'm waiting to upload 3.7.1-1 until 3.7.0-2 clears NEW. My packages are sitting ready to go, and I've been running them locally for some time. I would, of course, do a low urgency upload as you suggested. Thanks. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: gcc-3.4 emits large amounts of test failures
Matthew Palmer <[EMAIL PROTECTED]> writes: >> So what do you propose to do? Fail the build if there are test failures? That > > Well, there's a reason that test suites exist, you know. If your > tests are failing spuriously, then it's time to fix the tests, not > ignore them. I'm sure the gcc developers, both Debian and upstream, are keen to see your patches to fix all the testsuite failures on our 11+ architectures. >> would pretty much ensure that the package never, ever builds. And > > Well, if it's always broken, we don't really want it, do we? If 'failing tests == broken' then we wouldn't have a working compiler for any architecture and/or for any release. I think there's a small flaw in your logic. -- James
Re: gcc-3.4 emits large amounts of test failures
On Mon, Jan 03, 2005 at 10:57:09AM +0100, Bastian Blank wrote: > I just read a buildlog for gcc-3.4 and saw large amount of test failures > but the build themself is marked as successfull. I don't think this is > the proper use of a testsuite and have to asume that nothing in the > package may work. Do you have /dev/pts mounted? Without it dejagnu does not work properly and generate lots of errors. There should be test-summary.gz in /usr/share/doc/gcc-3.4 (or just test-summary in the build directory) with an overview of what the status of the tests. This for instance lists this for C on i386: === gcc Summary === # of expected passes24999 # of unexpected failures2 # of expected failures 70 # of untested testcases 7 # of unsupported tests 201 /home/packages/gcc/3.4/gcc-3.4-3.4.3/build/gcc/xgcc version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) And this for c++: === g++ Summary === # of expected passes9769 # of unexpected successes 3 # of expected failures 71 # of unsupported tests 43 /home/packages/gcc/3.4/gcc-3.4-3.4.3/build/gcc/testsuite/../g++ version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) So for C there are 2 unexpected failures and for C++ there are 3 unexpected successes. I wouldn't call that many errors. I could only hope that it gives as good as results as this on all arches. Kurt
Re: Bastian Blank (MIA?) and zope-zwiki
On Sun, Jan 02, 2005 at 11:13:50PM -0700, Joel Aelwyn wrote: > So, upon running into some issues with it recently, I pulled up the QA > page for zope-zwiki, and realized that it is, to put it mildly, "not in > great shape". This message is to check with Bastian as to whether he is > active, wants to keep zope-zwiki, and intends to update it (last upload > 2003-05-03, looks to have never made it into Testing due to bugs, and has a > Grave(security) bug open against it for 38 days now). If you'd have done some minimal checking[1], you'd have noticed that Bastian Blank is not Missing In Action, in any case. I do agree that zoke-zwiki doesn't look in a good shape though. As currently a 0-day NMU policy is in effect for release-critical issues, you're free to use this policy to NMU the package (however, read on below). > If not, my intent is to package and upload a reasonably current version > (since 0.37 and 0.38 should both fix the security bug, and there appears > to be minimal use in fixing 0.18 as it is almost two years out of date), > including a pass through the bug list to tag or close those that appear to > be fixed by the new version. If you're not maintainer, you can always look through other people's buglists, and tag those bugs 'fixed' that you believe shouldn't be open anymore. > Since I need the package with relative speed, I'll be doing a local version > ASAP, but I will wait until someone can either confirm Bastian as being > a known MIA, or I get a response, to upload anything to the main archive > (honestly, it's in bad enough shape that I don't feel doing an NMU just to > have the default 1 week delay is going to do anyone much good). Instead, > I'll wait at least one week before kidnapping the package, more if folks > feel it is warranted. If you suspect people to be MIA, better contact [EMAIL PROTECTED] with your suspection, as then _all_ packages need to get looked after. Also, people can be on vacation or just very temporarily away, and it's polite to give them a bit more time to react. This is not the case here though, I asked Bastian Blank, and it appears to be a misunderstanding: Someone showed interest in the package quite some time ago, Bastian assumed he'd take care of it, but to day this someone didn't yet followup, with as result the current situation. In a moment I'm going to file an orphan bug, and set you as the adopter, so you can then adopt the package anytime you wish by uploading with "Adopted package (Closes: #the-bug-I'm-about-to-submit)", and meanwhile, you can really close bugs etc :). Most times, just mailing a maintainer privately works fine if you're concerned about a package, it doesn't happen really often the people don't reply at all. Thanks, --Jeroen [1] For example by checking out last activity in the Debian LDAP -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Final polishing of the KDE 3.3 transition
#> we'll go with lowering to 'important', with an attached explanation. #285128: kdelibs: CAN-2004-1165: FTP command injection bug severity 285128 important #286516: kdebase: CAN-2004-1158: Konqueror Window Injection Vuln. severity 286516 important #286521: kdelibs: CAN-2004-1145: Konqueror Java Vulnerability severity 286521 important thanks mate, see you again after the transition In agreement with the Release Team, I'm downgrading the severity of the above three security bugs in KDE to important, so that KDE 3.3 can enter sarge. See this thread [1] for more info. [1] http://lists.debian.org/debian-release/2005/01/msg4.html The severity will be restored right after the transition, and uploads to sid will shortly follow. Just to say what is going to happen: kdebase 3.3.1-4 will be uploaded first (along with a arts 1.3.2-2, not security related). While buildds churn these two, a kdelibs 3.3.2-1 upload to sid will be prepared, and uploaded as soon as kdebase+arts is built in all arches. We need to upload kdelibs 3.3.2 since the fix for CAN-2004-1145 (the Java Vulnerability) is not easily backportable to 3.3.1. Having kdelibs 3.3.2 with the rest of packages being at 3.3.1 is a safe mix; in any case, we will test prior to uploading and the urgency won't be set to high. Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: 10,000 Maniacs - don't talk Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. -- Alan Kay
Re: gcc-3.4 emits large amounts of test failures
On Mon, Jan 03, 2005 at 11:09:09AM +0100, Falk Hueffner wrote: > Bastian Blank <[EMAIL PROTECTED]> schrieb am 03.01.05 10:57:34: > > > I just read a buildlog for gcc-3.4 and saw large amount of test failures > > but the build themself is marked as successfull. I don't think this is > > the proper use of a testsuite and have to asume that nothing in the > > package may work. > > So what do you propose to do? Fail the build if there are test failures? That Well, there's a reason that test suites exist, you know. If your tests are failing spuriously, then it's time to fix the tests, not ignore them. > would pretty much ensure that the package never, ever builds. And the Well, if it's always broken, we don't really want it, do we? > bootstrapping already makes sure that the compiler isn't totally broken. "Not totally broken" might be a suitable marketing strategy for Microsoft, but I'm not convinced it's a level we want to be particularly aiming for. - Matt signature.asc Description: Digital signature
Re: gcc-3.4 emits large amounts of test failures
Bastian Blank <[EMAIL PROTECTED]> schrieb am 03.01.05 10:57:34: > I just read a buildlog for gcc-3.4 and saw large amount of test failures > but the build themself is marked as successfull. I don't think this is > the proper use of a testsuite and have to asume that nothing in the > package may work. So what do you propose to do? Fail the build if there are test failures? That would pretty much ensure that the package never, ever builds. And the bootstrapping already makes sure that the compiler isn't totally broken. Falk
gcc-3.4 emits large amounts of test failures
I just read a buildlog for gcc-3.4 and saw large amount of test failures but the build themself is marked as successfull. I don't think this is the proper use of a testsuite and have to asume that nothing in the package may work. Bastian -- It is more rational to sacrifice one life than six. -- Spock, "The Galileo Seven", stardate 2822.3 signature.asc Description: Digital signature
Re: Final polishing of the KDE 3.3 transition
* Steve Langasek [Sun, 02 Jan 2005 20:23:11 -0800]: > This bug is now closed. thanks. > I agree that the impact of the KDE blockage is sufficient that we shouldn't > be holding KDE out of testing for bugs that aren't specific to unstable. ack. > > (but: I think I prefer to lie about the severity > > rather than lie about the tags; Kamion may have a different > > opinion as a bugmaster.) > This preference isn't strong enough that I would want it to hold anything > up; all the options are kludges, so we might as well pick one and get on > with things. we'll go with lowering to 'important', with an attached explanation. > This is not really a major concern; if there are RC bugs that haven't been > detected yet, there's no sense in sitting around waiting for them to be > filed. If you have specific issues in mind that you suspect may be RC, it > would be best to investigate them before the affected packages reach > testing, of course. no, no specific issues in mind. I throw away and forget about (d) now. * * * so, we'll be downgrading the security bugs to important now, right?, and aiui the transition can happen in today's britney run (provided that today's dinstall picks kdeedu/mipsel and britney sees it, which is what happens if iuic). thanks for your time and your excellent work. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Re: any objections to uploading tiff 3.7.1 to unstable?
On Tue, Dec 21, 2004 at 04:24:03PM +, Jay Berkenbilt wrote: > The tiff packages are not yet frozen, but since they have many reverse > dependencies, including parts KDE, I don't want to do an upload to > unstable without release team approval. > 3.7.1 is binary compatible with 3.6.1, the version currently in sid. > A pre-release of 3.7.0 (disguised as 3.7.0) has been in experimental > for a few weeks. A handful of people have reported success with these > packages, and no one has reported any problems, excepting a bug report > pointing out an incorrect path in the doc-base file. > 3.7.0 and 3.7.1 includes a great many fixes over 3.6.1. In fact, all > reproducible outstanding bugs against the tiff packages of severity > higher than "wishlist" in the debian BTS are known to be fixed in > 3.7.1. There are many other performance fixes and fixes to fax > codecs, among other things. > Given that I have done and continue to do careful testing of these > packages and am responsive to any problems that come up (and now have > a very responsive sponsor helping with uploads) and that 3.7.1 is so > far superior to 3.6.1, I'd like permission to upload 3.7.1 into > unstable in hopes of it making the transition to sarge. > Note that 3.7.0-2, uploaded to experimental, introduced the new binary > package libtiff-opengl which includes one program that was not > previously part of libtiff. This upload, made 10 days ago, required > modification to the override file, which has not yet happened. > Assuming it takes the usual 3 weeks for this to happen and that I > upload 3.7.1-1 immediately after this at urgency low, we're still > three weeks away from 3.7.1 transitioning to sarge. Maybe that will > be too late, which would be sad. I'm resisting the temptation to work > around the override issue by doing something like upload 3.7.1-1 > without opengl, waiting for it show up, and then uploading 3.7.1-2 > with opengl. (Maybe I'll discuss this on IRC and get some opinions.) As this package is not frozen, and you have asserted that the library does not break backwards compatibility, I see no reason to object to an upload of 3.7.1 to unstable. Please only upload with low urgency, however, so that we have the full 10-day minimum period for other eyeballs to notice bugs before it reaches testing. It appears that 3.7.0-2 is still held up in NEW; if 3.7.1 will also be held up from reaching unstable for the same reason, I'm not overly concerned about its impact on the KDE 3.3 transition, which appears to be ready to go without any further rebuilds of the core KDE packages. Regards, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please prepare for a request to hint shadow (really, now...)
On Sat, Jan 01, 2005 at 11:13:03AM +0100, Christian Perrier wrote: > shadow 4.0.3_30.7 has now been built on all arches. No RC bug appeared > (still 3 days to run for the 10 days incubation period). > I have double-checked that the following changes do NOT break Debian > Installer and I thus consider it ready for sarge as the now de facto > maintainer of this package (still seeking for help maintaining > itannoucement soon to come). > So, now really, please hint shadow for entering sarge. 1:4.0.3-30.7 approved, and should go in with the britney run of 1/3. Thanks for your work on shadow, Christian. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bastian Blank (MIA?) and zope-zwiki
So, upon running into some issues with it recently, I pulled up the QA page for zope-zwiki, and realized that it is, to put it mildly, "not in great shape". This message is to check with Bastian as to whether he is active, wants to keep zope-zwiki, and intends to update it (last upload 2003-05-03, looks to have never made it into Testing due to bugs, and has a Grave(security) bug open against it for 38 days now). If not, my intent is to package and upload a reasonably current version (since 0.37 and 0.38 should both fix the security bug, and there appears to be minimal use in fixing 0.18 as it is almost two years out of date), including a pass through the bug list to tag or close those that appear to be fixed by the new version. Since I need the package with relative speed, I'll be doing a local version ASAP, but I will wait until someone can either confirm Bastian as being a known MIA, or I get a response, to upload anything to the main archive (honestly, it's in bad enough shape that I don't feel doing an NMU just to have the default 1 week delay is going to do anyone much good). Instead, I'll wait at least one week before kidnapping the package, more if folks feel it is warranted. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
