Please force in kdeaddons
It's just waiting for hppa, like the rest of KDE. :-P force kdeaddons/4:3.4.3-1 -- Nathanael Nerode [EMAIL PROTECTED] [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer accessible SPARC machine
On Thu, 2006-01-05 at 08:06 -0500, Stephen Frost wrote: * Ben Collins ([EMAIL PROTECTED]) wrote: On Wed, 2006-01-04 at 00:22 -0800, Steve Langasek wrote: On Tue, Jan 03, 2006 at 04:35:30PM -0800, Andrew Pollock wrote: I note that one of the issues with the Sparc port is the the lack of a developer accessible machine. At present, vore.debian.org is back on line; the underlying issue, though, seems to be that vore, like the buildds, won't necessarily *stay* on-line due to some hard-to-pin kernel bugs that keep taking the systems down. Vore is stable now. What was the issue? I'm guessing kernel bug, so what change/version resolved the problem? Can it build openoffice, etc, now? Has there been any progress on the SunFire (and similar) 'Data MMU Fast Path Miss' or whatever that error is when trying to boot from cd? Kernel bug was auric. The issue with vore was mainly network. The hub it was connected to was dying a slow death. Took us awhile to resolve this because we didn't know what the actual problem was. Auric I'm unsure about right now. -- Ben Collins [EMAIL PROTECTED] Developer Ubuntu Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-depends on package not in testing
On Wed, Jan 04, 2006 at 03:36:00AM -0800, Steve Langasek wrote: reopen 345868 thanks On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote: Unfortunately the discussion about the freecdb package didn't attract my attention earlier, the release critical bug is resolved as invalid now. And reopened. You have *not* addressed the issues contributing to this RC bug: - freecdb provides no shared library or static _pic library suitable for linking into other shared libraries, which is something we generally expect from library packages - the only thing that sucks more than static-only libs for security support of a library is *bundled* static-only libs - the author (and current maintainer) of freecdb says that this cdb implementation should be considered dead 1) and 2) suck, but it's 3) that makes this a serious bug AFAICT; you can address 3) by becoming the new maintainer, of course, but in that case I would expect that you would actually, er, *maintain* it, for instance by providing a _pic.a library instead of dismissing the bug as a problem in vpopmail's packaging. I'm quite suprised. This isn't a release critical bug. The real author (not the current maintainer) doesn't consider this cdb implementation (the first and original one) dead AFAICS. This tiny library is excellent software from the public domain, rock-solid and bug-free for years. Nothing forces a maintainer to provide a _pic.a library, original upstream says that this is not what the library is intended for. I can't see how you justify severity serious, not through policy AFAIK. Good maintenance is not always to implement each and every wish people express. If anyone requests a pic library, one can tell them that it's not a good idea and what to do instead, if appropriate; that's good maintenance. Nobody's currently requesting it though. The issue discussed in the original bug report simply _is_ a problem in vpopmail's packaging, check the package if you don't believe. I planned to take over upstream and Debian maintenance for the reasons stated in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272127;msg=73 and offered to take responsibility for the current freecdb package in the meanwhile; don't know why you think you need to distrust my maintainer and upstream developer skills. Not allowing freecdb back into etch opens at least two new release ciritical bugs, two software projects I maintain for Debian use the cdb command line tools for selftests in the build process. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-depends on package not in testing
On Thu, Jan 05, 2006 at 06:05:28PM +0100, Gerrit Pape wrote: On Wed, Jan 04, 2006 at 03:36:00AM -0800, Steve Langasek wrote: reopen 345868 thanks On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote: Unfortunately the discussion about the freecdb package didn't attract my attention earlier, the release critical bug is resolved as invalid now. And reopened. You have *not* addressed the issues contributing to this RC bug: - freecdb provides no shared library or static _pic library suitable for linking into other shared libraries, which is something we generally expect from library packages - the only thing that sucks more than static-only libs for security support of a library is *bundled* static-only libs - the author (and current maintainer) of freecdb says that this cdb implementation should be considered dead 1) and 2) suck, but it's 3) that makes this a serious bug AFAICT; you can address 3) by becoming the new maintainer, of course, but in that case I would expect that you would actually, er, *maintain* it, for instance by providing a _pic.a library instead of dismissing the bug as a problem in vpopmail's packaging. I'm quite suprised. This isn't a release critical bug. The real author (not the current maintainer) doesn't consider this cdb implementation (the first and original one) dead AFAICS. This tiny library is excellent software from the public domain, rock-solid and bug-free for years. Nothing forces a maintainer to provide a _pic.a library, original upstream says that this is not what the library is intended for. I can't see how you justify severity serious, not through policy AFAIK. Good maintenance is not always to implement each and every wish people express. If anyone requests a pic library, one can tell them that it's not a good idea and what to do instead, if appropriate; that's good maintenance. Nobody's currently requesting it though. Is there a reason that there shouldn't be a shared library of freecdb? Is the API/ABI unstable or something? I don't see why you only want a static version of the library. I don't think saying that upstream says so is a valid reason, without also saying what the reason is. The only reason I saw so far was that it's very small (#338038), which I don't consider to be a good reason. The issue discussed in the original bug report simply _is_ a problem in vpopmail's packaging, check the package if you don't believe. So vpopmail's packaging isn't good because it tries to create a shared library that makes use of freecdb? Please explain me how this can be considered bad packaging. You're also saying that it's not supposed to be used in that way. Why shouldn't some other library try and use your library? What should they do instead? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please force in kdeaddons
On Thu, Jan 05, 2006 at 03:43:01AM -0500, Nathanael Nerode wrote: It's just waiting for hppa, like the rest of KDE. :-P force kdeaddons/4:3.4.3-1 Yes, forced. -- 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: Re: Please force in kdeaddons
It would be nice to know what's the planned fix for these packages, unless hppa is to be ignored soon. If forcing each package is the preferred way, while kdeaddons is the most important to force so that kde finally gets installable again, kdevelop3 is missing since a long time, and it could be checked whether k3b and amarok's amd64 issues are worth keeping them to enter testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: varconf and atlas-cpp are tied up with wfmath
On Thu, Jan 05, 2006 at 01:03:41AM -0500, Nathanael Nerode wrote: And they're all separate roots of the tree, none depending on any other. So the solo hint for wfmath is unlikely to work. Try Actually, it went in just fine today; it just needed old binaries from eris to be rene'd from unstable. -- 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: binNMU of camlimages needed on sparc
On Wed, Jan 04, 2006 at 06:48:24AM +0100, Julien Cristau wrote: a bug similar to 344688 seems to affect camlimages on sparc: $ ocamlopt -I +camlimages ci_core.cmxa ci_tiff.cmxa test.ml /usr/lib/ocaml/3.09.0/camlimages/libci_tiff.a(tiffwrite.o): In function `open_tiff_file_for_write': undefined reference to `caml_Double_val' collect2: ld returned 1 exit status Error during linking Could you queue a binNMU to fix this (I checked that with a rebuilt camlimages, this problem goes away)? Queued. What packages will need to be retried by the buildd once this is available? 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
Let's remove tkrat from testing
Long-standing RC bugs 259324, 344981 (missing dependencies); maintainer appears to be out to lunch and nobody else appears to care enough to NMU. Unchanged since sarge. remove tkrat/1:2.1.4-2 -- Nathanael Nerode [EMAIL PROTECTED] [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer accessible SPARC machine
On Wed, Jan 04, 2006 at 12:22:57AM -0800, Steve Langasek wrote: Hi Andrew, On Tue, Jan 03, 2006 at 04:35:30PM -0800, Andrew Pollock wrote: I note that one of the issues with the Sparc port is the the lack of a developer accessible machine. At present, vore.debian.org is back on line; the underlying issue, though, seems to be that vore, like the buildds, won't necessarily *stay* on-line due to some hard-to-pin kernel bugs that keep taking the systems down. Anyway, I'm working with Stephen Frost (though working is a bit of an overstatement, he's currently waiting on me) to arrange hosting of a porter system with his employer; the space is all arranged, now it's just a matter of acquiring appropriate hardware. I have at my disposal, an Ultra 5. Nothing fantastic, I know, but I'm sure m68k's had less grunty boxes... It has a healthy amount of RAM, and I would put a new hard drive in it (or would accept a hard drive purchased by SPI or something). I think an Ultra 5 is probably a little light for our purposes: m68k's porter machine may be slower, but m68k also doesn't have, say, an openoffice.org port that might need debugging... Also, given the problems that consumer-grade DSL poses for system accessibility over the long term, I'd think that vore is still a better bet currently in spite of some past connectivity problems there, both connectivity-wise and bogomips-wise. Would you be willing to ship the system to Stephen if the search for better hardware pans out and vore proves unreliable in the long term? I'd prefer not to relinquish posession of the box. Could it be added to the pool of developer accessible machines anyway (with the more-the-merrier reasoning), or is it considered insufficiently grunty bogo-mips-wise? regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer accessible SPARC machine
On Fri, Jan 06, 2006 at 05:13:54PM +1000, Andrew Pollock wrote: On Wed, Jan 04, 2006 at 12:22:57AM -0800, Steve Langasek wrote: Hi Andrew, On Tue, Jan 03, 2006 at 04:35:30PM -0800, Andrew Pollock wrote: I note that one of the issues with the Sparc port is the the lack of a developer accessible machine. At present, vore.debian.org is back on line; the underlying issue, though, seems to be that vore, like the buildds, won't necessarily *stay* on-line due to some hard-to-pin kernel bugs that keep taking the systems down. Anyway, I'm working with Stephen Frost (though working is a bit of an overstatement, he's currently waiting on me) to arrange hosting of a porter system with his employer; the space is all arranged, now it's just a matter of acquiring appropriate hardware. I have at my disposal, an Ultra 5. Nothing fantastic, I know, but I'm sure m68k's had less grunty boxes... It has a healthy amount of RAM, and I would put a new hard drive in it (or would accept a hard drive purchased by SPI or something). I think an Ultra 5 is probably a little light for our purposes: m68k's porter machine may be slower, but m68k also doesn't have, say, an openoffice.org port that might need debugging... Also, given the problems that consumer-grade DSL poses for system accessibility over the long term, I'd think that vore is still a better bet currently in spite of some past connectivity problems there, both connectivity-wise and bogomips-wise. Would you be willing to ship the system to Stephen if the search for better hardware pans out and vore proves unreliable in the long term? I'd prefer not to relinquish posession of the box. Could it be added to the pool of developer accessible machines anyway (with the more-the-merrier reasoning), or is it considered insufficiently grunty bogo-mips-wise? That'd be DSA's call; but given that it probably wouldn't be sufficient, it also seems unnecessary, so I guess it would be a low priority. You could always make a standing offer of individual accounts to DDs (or non-DDs, as we often have NMs who need help getting access for porting issues), I suppose? -- 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
