Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 03:06:21PM -0500, Hubert Chathi wrote: > On Wed, 02 Jan 2008 13:17:24 -0600, Raphael Geissert <[EMAIL PROTECTED]> said: > > Hello all, I've written a script which tries to detect packages which > > should be architecture all based on the fact that they don't contain a > > Depends field. This is usually bug either because of a missing > > Depends or because the package should be Architecture: all. > > Maybe you want to make this into a lintian test? One thing I feel is worth mentioning is that it is more harmful for a package to be mistakenly Architecture: all than mistakenly Architecture: any. The former merely wastes some disk space, while the latter will cause actual broken packages. While the breakage would be obvious in the case of packages containing ELF binaries, in the case of packages like os-prober that include different scripts depending on the build architecture, the breakage would be more subtle and time-consuming: it will simply fail to detect things that should have been detected. In light of this, and that there's no straightforward way I can think of for Lintian to detect this situation given a binary package, I feel that a Lintian test risks prompting inexperienced maintainers to err on the side of incaution and set an incorrect Architecture field. I appreciate the zeal involved in cleaning up those packages which are any when they should be all, but is a Lintian test for this worth the potential breakage? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Thu, Jan 10, 2008 at 07:53:03PM -0600, Raphael Geissert wrote: > Cyril Brulebois wrote: > > On 11/01/2008, Raphael Geissert wrote: > >> And here's the list of packages which after comparing the md5sum files > >> show no reason why they aren't arch all: > >> > >> Grub Maintainers <[EMAIL PROTECTED]> > >>grub > > > > Again, there is a very good reason: > > | /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 > > | (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), > > | stripped > > > >> Camm Maguire <[EMAIL PROTECTED]> > >>hol88-library > > > > So, again, *how* do you find it possible to list this package as MUST be > > Architecture: all, while it has things like that inside? > > | … cut … > > | /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB > > | relocatable, Intel 80386, version 1 (SYSV), not stripped > > | /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB > > | relocatable, Intel 80386, version 1 (SYSV), not stripped > > | usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB > > | relocatable, Intel 80386, version 1 (SYSV), not stripped … cut … > > There "MUST" be something wrong with the package then, how is that i386's > and amd64's md5sum are exactly the same? I don't know about hol88-library, but grub builds with -m32 on amd64. Nevertheless, it's still architecture-dependent; it builds different binaries on Linux and the Hurd, and also the grub package should not be in Packages for architectures to which it hasn't been ported. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#499577: PTS incorrectly claims base-passwd is LowNmu
Package: qa.debian.org http://wiki.debian.org/LowThresholdNmu says: 38. Colin Watson - (all packages) - except: base-passwd - Comaintainers welcome - check: base-passwd comaintainers are welcome However, http://packages.qa.debian.org/b/base-passwd.html says: Maintainer Colin Watson MaintenanceLowNMU Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Piuparts-devel] Unclear failure for asclock (left over files in /var)
On Sat, Nov 28, 2009 at 10:04:30PM +0100, Guillem Jover wrote: > On Sat, 2009-11-28 at 10:22:40 +0100, Holger Levsen wrote: > > On Mittwoch, 25. November 2009, Helge Kreutzmann wrote: > > > Package purging left files on system: > > > /var/cache/man/pt not owned > > > /var/cache/man/pt/cat1 not owned > > [...] > > > Judging from this analyis, this looks like a false positive... > > > > I think it is too, but I'm not entirely sure, so I would appreciate a > > comment > > from someone more familar with "man" then I am, that's why I've added d-qa@ > > to cc: > > > > So far, piuparts has been ignoring left over files with the following > > patterns: > > > > "/var/cache/man/(.*)/index.db", > > "/var/cache/man/index.db", > > > > (obviously, there are more :) > > > > Looking at the failed piuparts logs, I see there are more with left over > > files > > in /var/cache/man/.*/cat? - should piuparts just ignore /var/cache/man? > > Comments welcome. > > Ignoring /var/cache/man/ seems the most reasonable course of action to > me. The man-db package is the one handling those databases, it just > seems logical to me that it should be the one in charge of removing it > when purged. It makes sense for mandb to observe that a hierarchy of manual pages has gone away entirely (e.g. no more /usr/share/man/pt) and remove the corresponding database. Could somebody file a bug on man-db for this, or reassign/clone an existing bug? I wasn't sure if there was already a bug report for this so I haven't filed one myself. Ignoring /var/cache/man seems fairly harmless in the meantime. (man-db of course does remove /var/cache/man when it itself is purged, but we could perhaps do better.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#816450: debcheck: Lists packages depending on libraries with lower priority
On Sun, Feb 18, 2018 at 07:19:29PM +0100, Sven Joachim wrote: > On 2016-03-01 23:14 +0100, Guillem Jover wrote: > > The debcheck script is listing packages depending on libraries with > > lower priority. But the archive overrides were recently updated to > > change libraries to have lower priority so that they would not get > > stuck indefinitely by frontends. > > > > So it seems this check is partialy bogus now. > > Two years later the check is completely bogus: Policy version 4.0.1 has > removed the requirement that packages must not depend on packages with > lower priority, and the FTP masters have changed the priorities of all > libraries to optional. I've made a merge request which should fix this: https://salsa.debian.org/qa/qa/merge_requests/24 -- Colin Watson [cjwat...@debian.org]
Bug#945112: debcheck: handle debhelper-compat
On Wed, Nov 20, 2019 at 03:30:26AM +0100, Thorsten Glaser wrote: > On Tue, 19 Nov 2019, Thorsten Glaser wrote: > > Please hack debcheck that it works with these virtual packages. Thanks! > > Perhaps same with 'default-logind | logind'. Both this and debhelper-compat are cases of versioned Provides (although one is typically found in Build-Depends and one in Depends, but it works out much the same way). I've made a merge request that should fix this: https://salsa.debian.org/qa/qa/merge_requests/25 -- Colin Watson [cjwat...@debian.org]
Bug#816449: debcheck: Lists missing Standards-Version for udebs
On Tue, Mar 01, 2016 at 11:03:29PM +0100, Guillem Jover wrote: > The debcheck script is reporting that many udebs are missing the > Standards-Version field, but udebs are not supposed to have such field > as they do not follow Debian policy. > > > <https://qa.debian.org/debcheck.php?dist=sid&list=main-only-No-Standards-Version&arch=ANY> I've made a merge request which should fix this: https://salsa.debian.org/qa/qa/merge_requests/26 -- Colin Watson [cjwat...@debian.org]
Bug#945112: debcheck: handle debhelper-compat
On Sun, Dec 15, 2019 at 07:59:12PM +0100, Thorsten Glaser wrote: > On Sun, 15 Dec 2019, Colin Watson wrote: > > Both this and debhelper-compat are cases of versioned Provides (although > > one is typically found in Build-Depends and one in Depends, but it works > > out much the same way). I've made a merge request that should fix this: > > Thanks! > > I get that or’d dependencies may be an issue in Build-Depends > due to buildds only using the first alternative, but this was > counter-productive in my DDPO. The problem with "default-logind | logind" wasn't anything to do with alternative build-dependencies; it was that both default-logind and logind only appear in versioned Provides, so debcheck didn't realise that either of them was provided at all. -- Colin Watson [cjwat...@debian.org]
Bug#872646: qa.debian.org: [debcheck] Escape some HTML before outputting
On Sun, Aug 20, 2017 at 02:53:09PM +0200, gregor herrmann wrote: > On Sun, 20 Aug 2017 10:13:47 +0200, Mattia Rizzolo wrote: > > On Sat, Aug 19, 2017 at 11:20:50AM -0700, Chris Lamb wrote: > > > Updated patch attached, although the last hunk is probably unnecessary > > > anyway. > > > > Although, I'm not a perl guy so I must ask before applying: > > * shouldn't that function be `escape_html()` instead of `html_escape()` ? > >(i.e., what is cited in the `use`) > > * does that thing requires a new dependency? The closer thing I could > >find on the net is > >http://search.cpan.org/dist/HTML-Escape/lib/HTML/Escape.pm which > >doesn't seem like something that is in the standard lib… > > * in the last chunk you escaped the first $me but not the latter in the > >line below, probably best to at least be consistent? > > AFAICS HTML::Escape is not packaged for Debian. > (Ack on the other points). > > HTML::Entities might be an option: > > https://metacpan.org/pod/HTML::Entities > > Included in the libhtml-parser-perl package. Yes, I think that's probably the right [1] answer. quantz already has libhtml-parser-perl installed too. I've tidied this up along those lines and made a merge request: https://salsa.debian.org/qa/qa/merge_requests/27 Note that I didn't bother to escape things that have already been checked as conforming to a syntax that doesn't require HTML-escaping, e.g. priority names, just because it was getting unwieldy. Ordinarily I'd make sure to put all substitutions through an escaping mechanism just to guard against future mistakes, but well, see [1]. [1] I might have written it this way myself when I first started writing Perl in 1999 or so, so no criticism of the original author intended, but I've very distinctly gone off the idea of assembling HTML out of lots of little string fragments in the intervening two decades. These days I'd use a templating system (e.g. Perl's Template Toolkit looks reasonable enough) as a bare minimum. But right now I really don't feel like rewriting almost all of debcheck to achieve that ... -- Colin Watson [cjwat...@debian.org]
Re: RFC: Changing the NM system
Adrian Bunk <[EMAIL PROTECTED]> wrote: >On Sat, 16 Dec 2000, Christian Kurz wrote: >> more careful task&skill test would be helpful. > >Yes, and the main point of my proposal is: An applicant doesn't get his >account before he had worked some months for Debian. This lets us judge >on his whole work (e.g. his knowledge about packaging, how he handles >bugs,...). I agree that a lot of care should be taken. Still, working through sponsorship is unbelievably frustrating if there isn't a great deal of interest in your packages, or if your sponsor is slow to react [1], and I don't think it's representative of working as a developer. In particular, while I try to run through random packages in the BTS reasonably often, I feel (perhaps inaccurately) somewhat limited in that I can't make uploads when the maintainer is obviously missing in action. Perhaps we need a more organized system of sponsorship, so that people who are stuck waiting in the NM queue can do QA work with some degree of ease. At the moment it seems to be largely a matter of whether you're lucky enough to find somebody who'll quickly and consistently sponsor your uploads. Of course, if the goal is to find people who are persistent enough to work through and despite this, then fair enough. [1] The only bug I have open has been closeable since the day after it was filed six months ago, but my sponsor never replied to my note that an upload was available. Admittedly it was my own fault when I thought I'd replied to Edward Betts later and actually don't seem to have done. -- Colin Watson [EMAIL PROTECTED]
Re: libcgicg1 bugs
On Sun, 17 Dec 2000 at 14:37:16 + (GMT), Matthew Vernon wrote: > Matthew Vernon writes: > > I'm working on these now... > > Well, I've got a built version with the currently-open bugs fixed; > OTOH, the code is terrible; I'm not sure I've got the patience to go > and try and fix up the grossnesses in it. Shall I upload the bug-fix > packages? I'm in the process of adopting libcgic, and have all but one bug fixed, so no need to bother. I want to check with iwj about a detail of his const-safety bug before I fix it as well (I'm not convinced about part of the suggested patch, and the rest should probably involve some conversation with upstream). -- Colin Watson [EMAIL PROTECTED]
Bug#85823: realplayer: Can't exit configuration if player not downloaded
merge 60426 85823 thanks "KORN Andras" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >please include a 'cancel' button in the configuration dialog (where you ask >what directory realplayer has been downloaded into). This would allow the >user to skip configuring realplayer and get on with other packages while >downloading the required file from real.com. Already reported several times, so I'm merging them. -- Colin Watson [EMAIL PROTECTED]
Re: vrweb uses /usr/X11R6/lib/X11/app-defaults
Since this package is orphaned (#87388), I'll fix its bugs shortly and set the maintainer to QA. Cheers, -- Colin Watson [EMAIL PROTECTED]
Some /usr/doc NMUs coming up
I'm going to NMU some orphaned packages soon to fix up their FHS status and set their maintainer to QA if necessary. In particular, if no-one else has done them already, I'll do bezerk, bridge, echo-linux, freefont, nasm-mode, python-pmw, sharefont, swish-e, tcl8.0-ja, tk8.0-ja, and type1inst. I won't be doing dpkg-mountable, as its former maintainer expressed a desire to have it removed. I won't be doing bigbrother, as the general consensus seems to be to get rid of the thing. I won't be doing x3270, as Rick Nelson seems to be interested in taking it (I'll get in touch with him and ask him how that's progressing). If anybody objects to any of these NMUs, please speak up soon; I'd like to get started on this. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Some /usr/doc NMUs coming up
Edward Betts <[EMAIL PROTECTED]> wrote: >Another thought, bridge contains the userspace tools for operating an >ethernet bridge on Linux 2.0, we have have not supported the 1.x >versions of the Linux kernel for some time, is it about time that we >dropped the support for version 2.0? Hmm, the modutils in woody doesn't support 2.0. Should we remove bridge, then? No-one seems to have been interested in adopting it for quite some time. -- Colin Watson [EMAIL PROTECTED]
Officially drop Linux 2.0 support? (was Some /usr/doc NMUs coming up)
Edward Betts <[EMAIL PROTECTED]> wrote: >Colin Watson <[EMAIL PROTECTED]> wrote: >> Edward Betts <[EMAIL PROTECTED]> wrote: >> >Another thought, bridge contains the userspace tools for operating an >> >ethernet bridge on Linux 2.0, we have have not supported the 1.x >> >versions of the Linux kernel for some time, is it about time that we >> >dropped the support for version 2.0? >> >> Hmm, the modutils in woody doesn't support 2.0. Should we remove bridge, >> then? No-one seems to have been interested in adopting it for quite some >> time. > >In that case I suggest that we remove bridge, and make it official that the >next release of Debian will only versions of Linux supported are 2.2 and 2.4. > >Are there any other packages that only support Linux 2.0? At least the following binary packages: arla-modules-2.0.36 ftape-tools (?) ibcs-source-2.0 ipautofw (?) ipfwadm (will this work with 2.4's compatibility mode? If so keep it) kernel-doc-2.0.36 kernel-headers-2.0.36 kernel-patch-2.0.36-m68k kernel-patch-2.0.37-raid kernel-source-2.0.36 This should definitely be discussed on debian-devel, though (cc'ed). -- Colin Watson [EMAIL PROTECTED]
Re: Officially drop Linux 2.0 support? (was Some /usr/doc NMUs coming up)
Edward Betts <[EMAIL PROTECTED]> wrote: >Found another one: > >update - daemon to periodically flush filesystem buffers >The description says: > This package is not needed with Linux 2.2.8 and above. If you do not > plan to run a 2.0.x series kernel on this system, you can safely > remove this package. update may still be useful in sync mode (as opposed > to flush mode) on more recent kernels for the extra paranoid. Judging by that description, I think it's worth keeping, although perhaps at lower priority. -- Colin Watson [EMAIL PROTECTED]
Re: Officially drop Linux 2.0 support? (was Some /usr/doc NMUs coming up)
Richard Braakman <[EMAIL PROTECTED]> wrote: >On Mon, Mar 26, 2001 at 01:45:08AM -0800, Alexander Hvostov wrote: >> This is, however, my _personal_opinion_ and there will probably be >> very good reasons against it. Let the debate begin! > >One reason against it is that there are probably machines running Debian >that were last rebooted before linux 2.2 was out. It's sort of cool >to be able to keep upgrading those without losing their uptime -- it >demonstrates one of Debian's technical principles. We've already lost the ability to manage modular 2.0 kernels, though, and I don't think most of the rest impact your ability to keep an old machine running. Perhaps we should remove most of the old packages containing sources and patches, and add a package providing an older modutils if this is important. -- Colin Watson [EMAIL PROTECTED]
Bug#91764: Please remove bigbrother
Package: ftp.debian.org Severity: normal Please remove bigbrother from unstable. It's non-free, has three unmerged open critical security bugs, one open grave bug, and a host of other bugs, is Standards-Version: 2.4.0.0 and doesn't conform to the FHS, and has good substitutes (e.g. netsaint). It's also been orphaned for a month; I realize this isn't all that long, but, with nobody apparently interested in fixing its bad RC bugs (people who previously announced their intent to adopt never produced anything), I think it would be better to remove it. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: iitalian
Francesco Tapparo <[EMAIL PROTECTED]> wrote: >On Thu, Mar 29, 2001 at 01:24:09AM +0100, Martin Michlmayr wrote: >> Can some Italian folks please NMU 'iitalian'. thanks. Also man-pages-it, please: Package: man-pages-it Binary: manpages-it Version: 0.3.0-1 Priority: optional Section: doc Maintainer: Fabrizio Polacco <[EMAIL PROTECTED]> Architecture: all Standards-Version: 2.5.0.0 The only non-forwarded bug is a note about /usr/doc. >> Package: iitalian >> Binary: iitalian >> Version: 0.03-2 >> Priority: optional >> Section: text >> Maintainer: Fabrizio Polacco <[EMAIL PROTECTED]> >> Architecture: all >> Standards-Version: 2.5.0.0 > >I'm italian, and I've contacted Fabrizio Polacco, but without any answer. >I could do the NMU if there are no objection. Have a look back through the -private archives a month or two - if he isn't back to responding to e-mail yet, which it doesn't seem he is, you should go ahead and NMU. -- Colin Watson [EMAIL PROTECTED]
Re: osh: changed maintainer to debian-qa
Domenico Andreoli <[EMAIL PROTECTED]> wrote: >i uploaded osh with a new maintainer, it is an NMU so i didn't >modified anything other It's nice to update the Standards-Version to something that includes build-dependencies. Since the package is maintained by QA now, it's reasonable to make this sort of change. -- Colin Watson [EMAIL PROTECTED]
Fixed in NMU of circlepack 4.0.1-4
tag 70322 + fixed tag 76079 + fixed tag 91131 + fixed tag 91410 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Apr 2001 02:07:20 +0100 Source: circlepack Binary: circlepack Architecture: source i386 Version: 4.0.1-4 Distribution: unstable Urgency: low Maintainer: Debian QA Group <[EMAIL PROTECTED]> Changed-By: Colin Watson <[EMAIL PROTECTED]> Description: circlepack - creation and display of circle packings Closes: 70322 76079 91131 91410 Changes: circlepack (4.0.1-4) unstable; urgency=low . * The maintainer has orphaned this package; set maintainer to Debian QA Group. * Update to policy version 3.1.1: - FHS updates (closes: #91131, #91410). - Build dependencies (closes: #70322). * Refer to the X Window System properly in package description (closes: #76079). * Get dpkg-gencontrol to include the section and priority fields. Files: 5f7c5761b70964f8f9468b6e836d1e46 645 math optional circlepack_4.0.1-4.dsc 3af9ee14702293211f9c1b400e68d4f1 3505 math optional circlepack_4.0.1-4.diff.gz 3dec821e7d8d431543f6642e6075cee9 502364 math optional circlepack_4.0.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE616mHMVrRHkkXpRQRAspYAKCCNAIxIHkD3FXh6LRrlfiBc678TQCfcqTk +m7zQHN94wF+X/6wndnpBi8= =i9J/ -END PGP SIGNATURE-
Fixed in NMU of lshell 2.01-10
tag 17462 + fixed tag 22216 + fixed tag 91203 + fixed tag 91576 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Apr 2001 23:59:40 +0100 Source: lshell Binary: lshell Architecture: source i386 Version: 2.01-10 Distribution: unstable Urgency: low Maintainer: Debian QA Group <[EMAIL PROTECTED]> Changed-By: Colin Watson <[EMAIL PROTECTED]> Description: lshell - Enforce limits to protect system integrity. Closes: 17462 22216 91203 91576 Changes: lshell (2.01-10) unstable; urgency=low . * Package is orphaned; set maintainer to Debian QA Group. * Make the postinst and prerm a bit more careful (closes: #17462, #22216). * Update to policy version 3.5.2: - Converted to debhelper for FHS updates (closes: #91203, #91576). - Added build dependencies. - Support DEB_BUILD_OPTIONS debug and nostrip. Files: c4cc6642fff1378ecb950b900ee2865b 604 admin extra lshell_2.01-10.dsc 434c03073ba80bc27709dde51facd329 6512 admin extra lshell_2.01-10.diff.gz a98151178c06e97200150095a399aafb 8510 admin extra lshell_2.01-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE614WuMVrRHkkXpRQRAg/fAJ0Q6bdSJc9wEtsVBCXTRtpZ4tIoyACePCf9 O3omojPRFW+VHX0qkkpUrbw= =M78R -END PGP SIGNATURE-
Re: Bug#94339: set6x86 does not build from source
Bas Zoetekouw <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >Package: set6x86 >Version: 1.5-4 >Severity: serious >X-Debbugs-Cc: debian-qa@lists.debian.org > >set6x86 (which is orphaned, but has a wrong maintainer field), does not >build from source: > >cc -O2 -g -Wall -DVERSION=\"1.5\" -o 6x86_reg 6x86_reg.c >6x86_reg.c: In function `get_IO_range': >6x86_reg.c:53: warning: implicit declaration of function `ioperm' >6x86_reg.c: In function `main': >6x86_reg.c:281: warning: suggest explicit braces to avoid ambiguous `else' >6x86_reg.c:321: warning: suggest explicit braces to avoid ambiguous `else' >6x86_reg.c:86: Invalid `asm' statement: >6x86_reg.c:86: fixed or forbidden register 0 (ax) was spilled for class AREG. >make[1]: *** [6x86_reg] Error 1 >make[1]: Leaving directory `/build/bas/orphan/set6x86-1.5' >make: *** [build] Error 2 > >the problem with ioperm is easily solved by including instead >of (which was used in libc5). I don't know how to solve the >assembler problem, though. I've solved it, but I'm very reluctant to upload a package like set6x86 which I have no way of testing, especially when I'm poking at assembler. Does anyone have a Cyrix 6x86 on which they could test my package? -- Colin Watson [EMAIL PROTECTED]
Re: Announcing myself
[EMAIL PROTECTED] wrote: >With all the discussion lately about binaries not having man pages, I >thought I'd jump in and volunteer to write some. Is there a formal >procedure for this, or should I just file bug reports with man pages >attached? There should be bug reports about many of them already, in which case attach man pages to those; if not, file new bug reports with them. >And is there a list of anywhere, either a web page or a previous list >message? http://qa.debian.org/man-pages.html >(For that matter, is this the right mailing list?) Seems ideal to me. :) -- Colin Watson [EMAIL PROTECTED]
Re: [MAILER-DAEMON@ull.es: Returned mail: Cannot send message within 4 days]
Josip Rodin <[EMAIL PROTECTED]> wrote: >Enrique, are you there? :) I sent one mail about <[EMAIL PROTECTED]> >being broken already, a couple of weeks ago, no reply... > >If anyone from QA would be so kind to NMU the acm package to change the >maintainer to the <[EMAIL PROTECTED]> address (which doesn't bounce), I'd >be most grateful. These bounces are repeating constantly and are starting to >get on my nerves. :) I'm in the process of adopting acm, and will fix that all shortly ... -- Colin Watson [EMAIL PROTECTED]
Re: Bug#91553: marked as done (Package libliteclue still has at
On Tue, 24 Apr 2001 at 13:06:50 -0300, Carlos Laviola wrote: > Shouldn't a new (dummy) libliteclue package be uploaded to reflect > this in its description? If any packages actually used it, I'd say that those packages just need to be recompiled. Since nothing else depends on it, though, I'd say that for a library there isn't much point: anybody who had it installed for development will have libliteclue-dev installed, which will pull in the new library package, and anybody who really wants an unused library installed probably won't have any problem installing the new package. One thing that might be a good idea is for libliteclue1 to conflict and provide libliteclue, as well as replacing it if they share any files. -- Colin Watson [EMAIL PROTECTED]
Re: Bug#91553: marked as done (Package libliteclue still has at
Carlos Laviola <[EMAIL PROTECTED]> wrote: >On 24-Apr-2001 Colin Watson wrote: >> One thing that might be a good idea is for libliteclue1 to conflict and >> provide libliteclue, as well as replacing it if they share any files. > >They did, the .so itself. Looks like it's fixed in incoming, though. -- Colin Watson [EMAIL PROTECTED]
Re: more about /usr/share transition
Colin Phipps <[EMAIL PROTECTED]> wrote: >On Wed, May 16, 2001 at 11:08:12AM +0200, Raphael Hertzog wrote: >> Le Wed, May 16, 2001 at 10:53:17AM +0200, Adrian Bunk ?crivait: >> > Sorry, but these are "serious" bugs. We want to have /usr/doc symlinks for >> > _all_ our packages in woody. >> >> I'm against submitting more & more RC bugs that are not worth it >> considering that we don't have the resources available to fix them. > >It may take time, but these bugs are considered serious enough to warrant >delaying a release to fix them. > >> Furthermore all those RC bugs that won't get fixed will just be useful >> to prevent more packages from sid to get into testing. > >If you file against the versions in testing, then they should not count against >the sid version so ought not to affect packages getting into testing. >(That's my understanding, anyway) No, the bug tracking system takes no account of versions. Pseudo-headers other than Package:, Severity:, and Tags: are purely informational. The best that the testing scripts can do is make a few guesses based on the newest version available at the time the bugs were filed. >> Feel free to ask the maintainer to update their packages but don't submit >> them as RC bugs. > >If you feel /usr/doc/ symlinks aren't release critical, file the appropriate >policy ammendment. Personally I won't downgrade RC bugs that have been filed about it, but nor will I worry too much about filing them myself. Considering that the symlinks will go away in a release or two's time, it's a much lower priority than getting the last few packages moved to /usr/share/doc at all. -- Colin Watson [EMAIL PROTECTED]
Re: more about /usr/share transition
Martin Quinson <[EMAIL PROTECTED]> wrote: >But what about a dh_fhs part (or what ever) of debhelper which would add >these lines to the good scripts, and move /usr/doc files to there correct >location. I mean, would it be usefull, or is it overkill ? I think you misunderstand what debhelper scripts do. You can create a debhelper script which automates some common task: for instance, dh_installdocs already installs documentation files in the correct place and installs the symlink. However, you can't as such create a debhelper script which fixes some common bug, not in the sense of fixing the whole archive in one easy step. Doing the FHS transition in a package is already trivial, even in packages that need more than a rebuild with a newer version of debhelper. The social aspects (i.e. persuading people to do it or following the polite steps to NMU their packages) are much harder, and you can't automate them. We're nearly there, though. -- Colin Watson [EMAIL PROTECTED]
Re: ical package
James Pinkster <[EMAIL PROTECTED]> wrote: >What has happened to the ical package, it seems to have disapeared ? http://ftp-master.debian.org/removals.txt [Date: Sat, 31 Mar 2001 06:38:13 -0500] [ftpmaster: James Troup] Removed the following packages from unstable: ical | 2.2-9 | source, alpha, arm, i386, m68k, mips, powerpc, sparc Closed bugs: 92286 --- Reason --- Requested by vela@; orphaned, bugs, previous maintainer considers it obsoleted by better alternatives, dead upstream ------ -- Colin Watson [EMAIL PROTECTED]
Bug#91550: marked as done (Package libliteclue-dev still has at least one file in /usr/doc)
On Fri, 25 May 2001 at 19:32:00 +0100, Colin Watson wrote: > libliteclue-dev is orphaned; Gergely Nagy made it FHS-compliant last > month, but the changelog didn't mention that. I'm closing it now. > > libliteclue (1.2.16-1.1) unstable; urgency=low > > * Non-maintainer upload > * Made it FHS compliant (Closes: Bug#91553) Of course, I meant "the changelog didn't mention this bug". -- Colin Watson [EMAIL PROTECTED]
Bug#99555: metrics: Missing symlinks for some man pages
Package: metrics Severity: normal Hi, An upcoming release of Debian policy, version 3.5.5.0, contains an amendment which clarifies the way man pages need to be installed. Until now, packages could install /usr/share/man/man1/foo.1.gz with 'foo, bar \- programs to do something' in the NAME section and have no corresponding symbolic link from bar.1.gz (policy suggested using a symbolic link, but wasn't clear that it's required), and our man program happened to magically figure it out for itself and display the right man page when you typed 'man bar'. However, guaranteeing that this would work even when you've recently installed some new packages has a serious performance impact on man, as it frequently has to go and look through the filesystem to update its database. Before woody's base system is frozen, I intend to remove this "feature" from man-db, so that its performance is consistent and acceptable for a reasonable number of people. It isn't a standard feature even among the various man page browsers in Debian, let alone in other Linux distributions, so there should be no compatibility problems. However, your package seems to rely on it, so this bug is being filed to let you know that the way some of your man pages are installed needs to be improved in order to work properly in woody. All you need to do, if you already have, say, foo(1) and expect bar(1) to work as well, is install a symbolic link to foo.1.gz as bar.1.gz (.so links and hard links are also OK, though symlinks are recommended). Here's a list of man pages and the names that don't appear anywhere in the filesystem: usr/share/man/man1/c_halsfilt.1.gz: metrics is a collection of programs that gather various static metrics from C source code usr/share/man/man1/c_halsfilt.1.gz: primarily to measure size and complexity. csize If the list looks odd, please check man(7) to see if the man page is formatted properly. This output was generated by way of mandb, so if it's confused then users will be too; if it turns out that it's done the wrong thing, please reassign this bug to man-db so that I can fix it. I might not have caught symlinks that are created in the postinst (say, using alternatives); if that's the case, please close this bug. Please see bug #94995 and policy 3.5.5 section 13.1 for more information, and feel free to contact me if you need help. Thanks, -- Colin Watson, via a script
Bug#99612: tclx8.0.4-dev: Missing symlinks for some man pages
Package: tclx8.0.4-dev Severity: normal Hi, An upcoming release of Debian policy, version 3.5.5.0, contains an amendment which clarifies the way man pages need to be installed. Until now, packages could install /usr/share/man/man1/foo.1.gz with 'foo, bar \- programs to do something' in the NAME section and have no corresponding symbolic link from bar.1.gz (policy suggested using a symbolic link, but wasn't clear that it's required), and our man program happened to magically figure it out for itself and display the right man page when you typed 'man bar'. However, guaranteeing that this would work even when you've recently installed some new packages has a serious performance impact on man, as it frequently has to go and look through the filesystem to update its database. Before woody's base system is frozen, I intend to remove this "feature" from man-db, so that its performance is consistent and acceptable for a reasonable number of people. It isn't a standard feature even among the various man page browsers in Debian, let alone in other Linux distributions, so there should be no compatibility problems. However, your package seems to rely on it, so this bug is being filed to let you know that the way some of your man pages are installed needs to be improved in order to work properly in woody. All you need to do, if you already have, say, foo(1) and expect bar(1) to work as well, is install a symbolic link to foo.1.gz as bar.1.gz (.so links and hard links are also OK, though symlinks are recommended). Here's a list of man pages and the names that don't appear anywhere in the filesystem: usr/share/man/man3/Tcl_HandleTblInit.3tclx.gz: Tcl_HandleTblUseCount Tcl_HandleWalk If the list looks odd, please check man(7) to see if the man page is formatted properly. This output was generated by way of mandb, so if it's confused then users will be too; if it turns out that it's done the wrong thing, please reassign this bug to man-db so that I can fix it. I might not have caught symlinks that are created in the postinst (say, using alternatives); if that's the case, please close this bug. Please see bug #94995 and policy 3.5.5 section 13.1 for more information, and feel free to contact me if you need help. Thanks, -- Colin Watson, via a script
Fixed in NMU of metrics 1.0-3
tag 99555 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 2 Jun 2001 01:25:05 +0100 Source: metrics Binary: metrics Architecture: source i386 Version: 1.0-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group <[EMAIL PROTECTED]> Changed-By: Colin Watson <[EMAIL PROTECTED]> Description: metrics- Tools for software metrics ( LOC/Halstead/kdsi/McCabe). Closes: 99555 Changes: metrics (1.0-3) unstable; urgency=low . * QA upload. * Rearrange metrics(1) to have a correct NAME section (closes: #99555). * s/prospective manpages/respective manpages/. * Make sure metrics(1) is symlinked to rather than copied. Files: 3db6b258c69176cce5dbc8506db04f1f 641 devel optional metrics_1.0-3.dsc b648b3e7ded885e975acd99826a76ca3 5289 devel optional metrics_1.0-3.diff.gz a80bb651dc33f8e6e1d8cf1bd44ea28f 44264 devel optional metrics_1.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: Colin Watson <[EMAIL PROTECTED]> -- Debian GNU/Linux developer iD8DBQE7GD6dMVrRHkkXpRQRAgoyAJ9i5+MQOfqJ4SPtI2vQ7bIrNdhcZgCgv3ut 44lXodGpECr2CapdkX8smec= =WEUt -END PGP SIGNATURE-
Re: Bug#99532: bash: Missing symlinks for some man pages
On Mon, 04 Jun 2001 at 11:28:02 +0200, Matthias Klose wrote: > so we do have to provide all these man pages and manage them with > alternatives among all the shells? > > sounds like a mess to maintain. I agree with Herbert that the current situation is very confusing: as it stands, you can be running ash, type 'man for', and get the man page for the bash builtins [1], which is at least surprising. Personally I'd have builtins(1) just say 'builtins \- bash built-in commands, see bash(1)' in the NAME section, and list the commands in the SYNOPSIS instead. NAME has a more well-defined meaning. [1] Well, actually, at the moment you get bash(1) because the fact that builtins(1) doesn't mention 'builtins' in its NAME section, and instead mentions 'bash' which it does not document, tickles a bug in man. I'll fix it when I work out how to do so without breaking other recent fixes. -- Colin Watson [EMAIL PROTECTED]
Re: wnpplint
Uwe Hermann <[EMAIL PROTECTED]> wrote: >On Thu, Jun 28, 2001 at 09:55:20PM +0200, Martin Michlmayr wrote: >> Hmm, I'd actually prefer patches against wnpp-lint (pandora: >> /org/qa.debian.org/data/wnpp/). > >Hm, OK. I didn't know of wnpp-lint. > >Pandora is listed as 'Access: developers only' on >http://db.debian.org/machines.cgi?host=pandora, but IANADD yet. > >Is it available via HTTP or FTP from somewhere? You can get it by anonymous CVS: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/qa co data Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: remaining FHS bugs
Jordi Mallach <[EMAIL PROTECTED]> wrote: >Hello, >A quick look over the FHS list: Thanks! Replies trimmed to -qa. >cqcam, libcqcam-dev: this package seems to be very unmaintained... >bugs ignored for years, etc. Should be orphaned/removed. Somebody (Edward?) was working on this. >faqomatic: same, trivial ignored bugs for ages, etc. Anyone knows if >this package is useful for anything? I NMUed at DebConf. Won't comment on its usefulness or otherwise for now (this keyboard is way too awkward ...) >gerstensaft: Joey? Roland fixed this one. >infocom, int-fiction, jlex, libggidemos, propsel, rocks-n-diamonds, > xserver-ggi: this maintainer looks like completely MIA. I see tbm has > noticed already :> They're probably all yada, too :( Is somebody proficient with that who could work on these? >libstdc++2.8: maintained by Galen Hazelwood, is he MIA (I can't >remember). tbm filed a bug to remove this, I think? >printop: also abandoned, old, trivial bugs ignored. I learnt the build system for a similar package (cracklib2) a while ago, so I can do this. (Yuck.) >sauce, userv: Ian, are you interested in these packages still? Should we NMU? Ian gave me permission to NMU a while ago, so I should get moving and do it (upload prepared for sauce, actually, but I haven't figured out how to test it yet). userv doesn't build for reasons that will need more discussion. >vrwave: Javi? Stephen Zander is taking this over. >libterm-readline-perl-perl: Darren, can you have a look at this? I started work on an NMU, not finished yet though. >idled, phototk: CR? tille was working on phototk. -- Colin Watson [EMAIL PROTECTED]
Re: Libraries to move to oldlibs
Edward Betts <[EMAIL PROTECTED]> wrote: >libdb2 (1 bug) - lots of packages do not work with libdb3 (exim), and there >are problems in with data files in the transition, leave the libdb2 its >current place, or move it to oldlibs to show that it is deprecated. Erk. I asked the maintainer a while ago how easy it was to implement a smooth transition from db2 to db3, i.e. without having to rebuild the database from scratch, but I asked on IRC so the question probably got lost. For somebody who knows little about Berkeley DB but maintains a package based on it, how difficult is it likely to be? If it's relatively easy, I suppose I could move to it, but I'm deeply reluctant to do that to man-db during the freeze. libc6 also has issues with upgrading from potato that require a dependency on libdb2 (AIUI). Please leave libdb2 where it is until woody + 1; we shouldn't have a required/base package depending on something in oldlibs. No objections to the others, although libpam-modules may have similar problems with moving to libcap2? Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Sudhakar Chandrasekharan is MIA [MAILER-DAEMON@ywing.netscape.com: Returned mail: see transcript for details]
Josip Rodin <[EMAIL PROTECTED]> wrote: >Hi, > >This has been going on for quite a while. Unless someone can reach thaths, >he should be considered MIA and his packages should be orphaned. :/ Hi Sudhakar, Is this a valid e-mail address for you? Do you need NMUs to change the maintainer address on your packages to something valid, or will you have time yourself soon? Thanks, -- Colin Watson [EMAIL PROTECTED]
Raising /usr/doc bugs to serious (policy 3.5.6.0)
# arla, arla-dev, arla-modules-2.0.36, libroxen-ldapmod don't have bugs # filed. # f77reorder severity 91444 serious # ftape-doc severity 64055 serious # ftape-util severity 64056 serious # gcc-m68k-linux severity 91476 serious # glimpse severity 91484 serious # gs-aladdin-manual severity 91486 serious # gs-aladdin-manual-de severity 91483 serious # gsfonts-other severity 91485 serious # idled severity 91513 serious # infocom severity 91515 serious # int-fiction severity 91507 serious # jlex severity 91510 serious # lexmark7000linux severity 91529 serious # lib-gnu.getopt-java severity 91556 serious # libggidemos severity 91552 serious # libterm-readline-perl-perl severity 91562 serious # ncurses3.0 severity 91611 serious # ncurses3.4 severity 91598 serious # onshore-timesheet-el severity 91619 serious # pccts severity 91608 serious # picasm severity 91616 serious # printop severity 91610 serious # rscheme-modules severity 91639 serious # sauce severity 91644 serious # sml-nj severity 91661 serious # userv severity 91678 serious # xserver-ggi severity 91725 serious thanks According to the upgrading-checklist in Debian Policy version 3.5.6.0: - Putting documentation in /usr/doc versus /usr/share/doc is now a ``serious'' policy violation See bug #102199 for more information. Accordingly, and since there are only 31 packages left to make the transition (at least on i386), I'm upgrading all relevant bug reports to serious. I don't think any of these are in base, so they shouldn't hold up the current stage of the freeze. -- Colin Watson [EMAIL PROTECTED]
Re: Raising /usr/doc bugs to serious (policy 3.5.6.0)
On Fri, Aug 03, 2001 at 07:45:02AM +0100, Edward Betts wrote: > Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > * Colin Watson <[EMAIL PROTECTED]> [20010731 13:09]: > > > # gs-aladdin-manual > > > # gs-aladdin-manual-de > > > # idled > > > # ncurses3.0 > > > # ncurses3.4 > > > # sml-nj > > > > to be removed (bugs filed). > > Could this be shown on http://qa.debian.org/fhs.html in some way? I'll see what I can do. -- Colin Watson [EMAIL PROTECTED]
Re: Raising /usr/doc bugs to serious (policy 3.5.6.0)
On Fri, Aug 03, 2001 at 12:40:06PM +0200, Martin Michlmayr wrote: > * Colin Watson <[EMAIL PROTECTED]> [20010803 05:26]: > > > Could this be shown on http://qa.debian.org/fhs.html in some way? > > > > I'll see what I can do. > > Is it really worth the effort? I'd rather wait until the BTS offers > some standardized way to get this information (see the discussion on > -project). Fair point, but the FHS transition will be over long before that happens unless we're doing something very wrong. It was little enough effort that I just did it. > Also, the FTP admins are usually very fast with removing > stuff. The Contents files still take a while to update, though. -- Colin Watson [EMAIL PROTECTED]
FHS: jlex
I'm adopting jlex and will have it moved to /usr/share/doc in a couple of days. -- Colin Watson [EMAIL PROTECTED]
Re: fhs transition update
On Wed, Aug 08, 2001 at 06:09:33PM +0200, Bas Zoetekouw wrote: > 6. gcc-m68k-linux > Martin Mitchell <[EMAIL PROTECTED]> > > Package is not installable and has build problems on hppa. I don't know > why this package has Architecture "Any" anyway. Isn't it a m68k only > package? Or is it a cross compiler? It's a cross-compiler. It perhaps should be removed since we've lost cross-binutils, at least if nobody is willing to maintain it; somebody should contact the m68k folks to see if they still want it. > 7. glimpse > Marco Budde <[EMAIL PROTECTED]> > > Has a grave security bug files now for almost 1.5 years (/tmp races). > Probably won't make it into woody anyway. Is the maintainer MIA? We currently need it for the lists archives, as far as I can remember. I'll try to come up with a patch for the /tmp races. > 9. jlex > Charles Briscoe-Smith <[EMAIL PROTECTED]> > > Patch in BTS, NMU in two weeks. As I said a day or two ago on this list, I'm adopting this, so no need to NMU. A fix is in incoming waiting for ftpmaster approval (as it moves the package to main). -- Colin Watson [EMAIL PROTECTED]
Re: fhs transition update
On Thu, Aug 09, 2001 at 12:12:18PM +0200, Josip Rodin wrote: > On Wed, Aug 08, 2001 at 12:48:31PM -0500, Colin Watson wrote: > > > 7. glimpse > > > Marco Budde <[EMAIL PROTECTED]> > > > > > > Has a grave security bug files now for almost 1.5 years (/tmp races). > > > Probably won't make it into woody anyway. Is the maintainer MIA? > > > > We currently need it for the lists archives, as far as I can remember. > > Yes, but if glimpse can't be fixed, it doesn't matter. lists-archives' > dependency on it doesn't have to be Depends:. Oh, OK. Having looked at it last night, it's probably fixable, but since some of the problems are practically design flaws it's quite a big job for a non-free package. Since the maintainer seems to be MIA, I'm more than half inclined to suggest removing it from unstable. > Jaako Niemi said he's going to get mnogosearch to work for list archives, > anyway :) It's the last non-free thing our servers rely on, isn't it? Cool. :) -- Colin Watson [EMAIL PROTECTED]
Bug#108717: qa.debian.org: debcheck: new architectures for woody and sid
Package: qa.debian.org Severity: wishlist Currently, debcheck only tracks the six architectures we released with potato, regardless of whether you're looking at stable, testing, or unstable. It should also track these architectures: woody: hppa ia64 sid: hppa hurd-i386 ia64 mips mipsel s390 sh I think this is just a case of selecting @ARCHS based on $DIST, but since I don't know the debcheck code I'm not going to poke around at it. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: fhs transition update
On Thu, Aug 09, 2001 at 11:20:25AM +0100, Colin Watson wrote: > On Thu, Aug 09, 2001 at 12:12:18PM +0200, Josip Rodin wrote: > > On Wed, Aug 08, 2001 at 12:48:31PM -0500, Colin Watson wrote: > > > > 7. glimpse > > > > Marco Budde <[EMAIL PROTECTED]> > > > > > > > > Has a grave security bug files now for almost 1.5 years (/tmp races). > > > > Probably won't make it into woody anyway. Is the maintainer MIA? > > > > > > We currently need it for the lists archives, as far as I can remember. > > > > Yes, but if glimpse can't be fixed, it doesn't matter. lists-archives' > > dependency on it doesn't have to be Depends:. > > Oh, OK. Having looked at it last night, it's probably fixable, but since > some of the problems are practically design flaws it's quite a big job > for a non-free package. (Cc'd to the maintainer) So, can we remove glimpse? There hasn't been an upload for almost three years, and not having it doesn't seem to have particularly damaged the last stable release. -- Colin Watson [EMAIL PROTECTED]
Re: diald not installing
On Sat, Aug 18, 2001 at 12:52:54PM +0100, Stig Brautaset wrote: > I have trouble installing diald. It fails to run the post-installation script. > > here is some output: > > Arwen:~# dpkg --configure diald > Setting up diald (0.99.4-2.1) ... > dpkg: error processing diald (--configure): > subprocess post-installation script returned error exit status 30 > Errors were encountered while processing: > diald > Arwen:~# > > Is there a flaw in the package? Or is there some flaw on my system? No, it's a bug in the package (see http://bugs.debian.org/76449). I promised ages ago to do a non-maintainer upload to fix this, but forgot; now my GPG key has been the casualty of a disk crash and I haven't recovered it yet. QA people, could somebody NMU diald? My last message in the bug log explains how to fix it, and in the month and a half since I sent that I've heard nothing from the maintainer. It's one of our oldest release-critical bugs. Stig: in the meantime, edit /var/lib/dpkg/info/diald.config, look for lines starting with 'db_input', and make sure they all end with '|| true'. Then run 'dpkg --configure diald' again. -- Colin Watson [EMAIL PROTECTED]
Re: Fixed in NMU of dstooltk 2.0-4
On Wed, Aug 22, 2001 at 08:09:34PM +0100, James Troup wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > tag 96034 + fixed > > > > quit > > > > This message was generated automatically in response to a > > non-maintainer upload. The .changes file follows. > > Grr, can you guys please standardize on one Maintainer: line and stick > to it? > > So far we have: > > o "Debian QA Group" > o Debian QA > o Debian QA Group > o Debian Quality Assurance > > and now > > o Debian QA Team Is it possible to check for the maintainer e-mail address instead? Only [EMAIL PROTECTED] and [EMAIL PROTECTED] should be in use (the former is deprecated). Failing that, we need to fix gen-orphaned so that it checks that the maintainer name is one that katie likes. -- Colin Watson [EMAIL PROTECTED]
Re: bug #68199
On Fri, Aug 24, 2001 at 09:46:38AM -0400, Rick Brunelle wrote: > I would like to maintain this package -- saml -- Simple Algebraic Math > Library > This request is in reference to bug #68199 Hi, Please read http://www.debian.org/devel/wnpp/ to find out how to adopt a package (search for 'ITA'). You'll also need a sponsor if you aren't a developer. However, looking at the logs of bug #68199, Ian seems to be making progress on adopting saml with Adrian's sponsorship: On 23 Aug 2001, Ian Zimmerman wrote: > I hope to do the same with saml tomorrow. Actually today, it's 3:00 > here :( -- Colin Watson [EMAIL PROTECTED]
Bug#110134: mpg123: Can't build on powerpc
Package: mpg123 Version: 0.59r-7 Severity: serious Building mpg123 failed on powerpc as follows: dpkg-buildpackage: source package is mpg123 dpkg-buildpackage: source version is 0.59r-7 dpkg-buildpackage: host architecture is powerpc fakeroot debian/rules clean test -e debian/control test `id -u` = "0" rm -f build-stamp /usr/bin/make clean make[1]: Entering directory `/home/cjwatson/mpg123-0.59r' rm -f *.o *core *~ mpg123 gmon.out sajberplay system mpg123m make[1]: Leaving directory `/home/cjwatson/mpg123-0.59r' rm -f mpg123-oss mpg123-esd rm -rf debian/tmp.* debian/files debian/substvars.* debian/rules build /usr/bin/make clean make[1]: Entering directory `/home/cjwatson/mpg123-0.59r' rm -f *.o *core *~ mpg123 gmon.out sajberplay system mpg123m make[1]: Leaving directory `/home/cjwatson/mpg123-0.59r' /usr/bin/make linuxppc make[1]: Entering directory `/home/cjwatson/mpg123-0.59r' make[1]: *** No rule to make target `linuxppc'. Stop. make[1]: Leaving directory `/home/cjwatson/mpg123-0.59r' make: *** [mpg123-oss] Error 2 debuild: fatal error at line 322: dpkg-buildpackage failed! It actually looks like a simple typo in debian/rules; I'll see what I can do about it this evening, but I'm filing this here in case I forget. -- Colin Watson [EMAIL PROTECTED]
Re: Some more uploads for orphaned packages
On Sat, Aug 25, 2001 at 12:14:30AM +0200, Adrian Bunk wrote: > at the moment I do the following uploads for orphaned packages to set the > maintainer to Debian QA and to fix some bugs: qub_0.4.9-2_i386.changes is in incoming, and I'm currently working on mh. I'll go on later to work on krusader, pgpgpg, sharefont, and xtoolplaces. -- Colin Watson [EMAIL PROTECTED]
Bug#110134: mpg123: Can't build on powerpc
On Sun, Aug 26, 2001 at 01:31:10PM +0100, Colin Watson wrote: > Package: mpg123 > Version: 0.59r-7 > Severity: serious > > Building mpg123 failed on powerpc as follows: [...] > It actually looks like a simple typo in debian/rules; I'll see what I > can do about it this evening, but I'm filing this here in case I forget. A fix is in incoming now. -- Colin Watson [EMAIL PROTECTED]
Re: mh override disparity
On Sun, Aug 26, 2001 at 03:04:07PM -0400, Debian Installer wrote: > There are disparities between your recently installed upload and the > override file for the following file(s): > > mh-papers_6.8.4-JP-3.03-33_all.deb: priority is overridden from extra to > optional. > mh_6.8.4-JP-3.03-33_i386.deb: priority is overridden from standard to extra. mh should indeed be extra of course, but would it make sense to demote mh-papers to extra? Its README.Debian says: These documents are mostly of historical interest, since, in my opinion, a much better discussion of all matters MH can be found live on the web: http://www.ics.uci.edu/~mh/book/ If enough people ask, I may package *that* up rather than these venerable files. -- Colin Watson [EMAIL PROTECTED]
Bug#110832: [PATCH] mpg123 support for Debian HPPA/Linux
On Fri, Aug 31, 2001 at 11:03:07PM +0200, Helge Deller wrote: > Package: mpg123 > Version: 0.59r-8 > > mpg123 isn't yet available on Debian/HPPA/Linux since > it didn't compiled on this architecture yet. > Could someone of you Debian-maintainers please apply the > following (tested) patch (on top of the debian mpg123 patches) which should > let mpg123 build cleanly for HPPA too ? I'm working on this now. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: ntop and gdchart support
On Thu, Sep 06, 2001 at 04:39:15PM -0300, Henrique de Moraes Holschuh wrote: > Also, if it is not there, look at http://www.debian.org/devel/wnpp and check > if someone is trying to produce one already. ... which is broken right now, but http://bugs.debian.org/wnpp shows the same information in a less easy-to-read form. > BTW, any futher questions like this one are better sent to > [EMAIL PROTECTED] http://lists.debian.org is your friend, use > it wisely. In case there's any confusion, that should be [EMAIL PROTECTED] Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: xmailtool_3.1.2b-1.4_i386.changes is NEW
On Tue, Sep 18, 2001 at 03:09:27PM -0400, Debian Installer wrote: > (new) xmailtool_3.1.2b-1.4.diff.gz optional mail > (new) xmailtool_3.1.2b-1.4_i386.deb optional mail > BSD-style mail reader for X > XMailTool manages your mail in much the same manner as mailx, but provides > a more convenient and powerful user interface. Scrollable windows allow > easy access to your mailbox and mail folders. Software "buttons" make the > most frequently used commands readily available. The full editing > capabilities of xedit are available for modifying and composing mail. > (new) xmailtool_3.1.2b-1.4.dsc optional mail > Changes: xmailtool (3.1.2b-1.4) unstable; urgency=low > . > * NMU Does anyone remember why xmailtool was removed from unstable? http://ftp-master.debian.org/removals.txt seems to expire after a while, and has lost that information. -- Colin Watson [EMAIL PROTECTED]
Re: about the ddts mails...
On Sat, Sep 15, 2001 at 06:14:08AM +0200, Michael Bramer wrote: > The ddts server send this mails, if someone make a new translation or > upload a newer translation. > > I can stop the server, to send this mails to the qa packages. > > Should I stop the server or read somebody this mails and check this > mails? Please stop them. I think if nobody's actively maintaining the package then there's probably no point drilling down to that level of detail about it to QA. (Is there an easy way for the new maintainer of a package to find out all the translations so far, if he/she wants?) -- Colin Watson [EMAIL PROTECTED]
Bug#112850: noatun: Doesn't play MP3
On Thu, Sep 20, 2001 at 08:19:28AM -0600, Ivan E. Moore II wrote: > tags #112850 unreproducible > severity #112850 normal > thanks > > first off, grave means it breaks other packages, important means the package > in question is basically useless. Since you can select wav files it's not > useless. 'reportbug' is right, one of grave's meanings is that the package is broken itself. Although if not everybody can reproduce that then it's not grave, as you say. -- Colin Watson [EMAIL PROTECTED]
Bug#113496: wily: Numerous policy violations
tags 113496 - woody tags 113496 + potato thanks On Tue, Sep 25, 2001 at 10:27:55AM -0700, C.M. Connelly wrote: > Package: wily > Version: 0.13.41-0.2 > Severity: serious > Tags: woody > > The wily package is extremely out of date and has several serious > policy violations, one of which prevents the xlibs 4.1.0-6 package > from being installed. wily isn't in either testing or unstable any more. If this prevents it from installing, perhaps xlibs could conflict with those packages that have been removed rather than updated for the new app-defaults arrangement? Otherwise it's going to be difficult to achieve a clean upgrade path without reinstating lots of packages we've removed (presumably for good reasons). I realize that an enormously long Conflicts: line for xlibs would be bad, but there should be relatively few packages which contained app-defaults files and were removed between potato and woody. -- Colin Watson [EMAIL PROTECTED]
Bug#113496: wily: Numerous policy violations
On Tue, Sep 25, 2001 at 08:48:40PM +0200, Jordi Mallach wrote: > On Tue, Sep 25, 2001 at 10:27:55AM -0700, C.M. Connelly wrote: > > [many lintian errors] > > > E: wily: FSSTND-dir-in-usr usr/doc/ > > Kamion, why isn't this package detected by the FHS script? Because the FHS script only looks at unstable. There is one outstanding problem, which I might as well mention: if any package creates empty directories in /usr/doc, they won't be spotted (as those don't show up in the Contents files). I noticed a couple of examples of this recently among doc-linux-*. There's not much that can easily be done about that without the lintian reports, though. -- Colin Watson [EMAIL PROTECTED]
Bug#113496: wily: Numerous policy violations
On Tue, Sep 25, 2001 at 04:35:21PM -0500, Branden Robinson wrote: > I should *also* Conflict: with app-defaults using packages from potato > that have been abandoned in woody (all surviving woody packages migrated > to /etc/X11/app-defaults months ago). > > Colin, can you help me to come up with a such a list? Have a look at master:~cjwatson/bin/app-defaults.pl. Running e.g. 'app-defaults.pl i386' comes up with the following list: chimera jgroff metro-motif-bin metro-motif-demobin netscape3 wily xarchie xcontrib xmailtool xsm You'll probably want to sanity-check that, of course, but it looks like a good start. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#113496: wily: Numerous policy violations
On Tue, Sep 25, 2001 at 11:36:10PM +0200, Jordi Mallach wrote: > On Tue, Sep 25, 2001 at 04:25:56PM -0500, Colin Watson wrote: > > There is one outstanding problem, which I might as well mention: if any > > package creates empty directories in /usr/doc, they won't be spotted (as > > those don't show up in the Contents files). I noticed a couple of > > examples of this recently among doc-linux-*. There's not much that can > > easily be done about that without the lintian reports, though. > > Does lintian.d.o check sid? If it does... it's not funny. > > FSSTND-dir-in-usr (103 packages, 128 tags) Check the latest lintian report - it was updated just a couple of hours ago. FSSTND-dir-in-usr (9 packages, 9 tags) (That's icecast-server, vim, xitalk, and xserver-ggi.) I think that report is a bit broken, though. It's citing xitalk because of /usr/man, not /usr/doc, which is fine in itself, but it misses a lot of other packages that also use /usr/man. Hmm. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: fhs scoreboard missing?
On Sat, Sep 29, 2001 at 03:40:16PM +0200, Josip Rodin wrote: > At http://qa.debian.org/fhs.html there is no scoreboard even though one is > mentioned. > > I'd meddle with this but I never touched it so I won't. :) It's built on auric, which may not be helping matters (maybe the cron job deleted it when wget didn't work, oops). It could also be that i386 is done, in which case I'll make it start displaying other architectures or something. -- Colin Watson [EMAIL PROTECTED]
Bug#113850: mhonarc: New upstream available
On Sun, Sep 30, 2001 at 11:40:43AM +0200, J?r?me Marant wrote: > Jeff Breidenbach writes: > > I think Debian can very reasonably go either way; package 2.5.0b2 or > > wait for 2.5.0. I guesstimate Earl will release 2.5.0 before 2002. > > In any case, waiting for the stable release seems to me the more > reasonnable thing to do and moreover should be a guideline for > every debian developer (yeah I could give names of some people > who screwed things up when shipping beta versions). I think that's a very black-and-white view. Some things are less safe in beta than others: libraries are the standard example. On the other hand, I doubt that anyone cares that trn4, say, is still in beta; in practice it's probably never going to get a stable release due to development being stagnant, but I'd take it over the stable trn (3.6) any day. It's clearly a judgement call for the maintainer. If a piece of beta software is in practice stable, in particular if it's a significant improvement even now over the previous stable release, and if there's going to be enough time to fix any unexpected problems that might occur before Debian's next stable release, then it's reasonable to package it. We should be fairly conservative about the possibility of breaking people's systems, certainly, but on the other hand if something is believed to be pretty safe then packaging it for unstable before it's officially released might mean we can help upstream catch a few more bugs earlier, which is good for the community. Davide Salvetti offered to adopt mhonarc last October. I e-mailed him about it in early August and never got a response, so I think I'll change its state back to orphaned and see if anybody else is interested in it. -- Colin Watson [EMAIL PROTECTED]
Bug#113850: mhonarc: New upstream available
On Sun, Sep 30, 2001 at 11:43:45PM +0200, J?r?me Marant wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > I think that's a very black-and-white view. Some things are less safe in > > beta than others: libraries are the standard example. On the other hand, > > I doubt that anyone cares that trn4, say, is still in beta; in practice > > it's probably never going to get a stable release due to development > > being stagnant, but I'd take it over the stable trn (3.6) any day. > > It is not a black-and-white view. With that argumentation, you are just > opening doors to abuses. I'm just talking about Quality Assurance, > there's nothing new. I was trying to say "it depends on the package", but maybe I wasn't clear enough about that. QA isn't a mechanical process that you can apply in the same way across the board. > I have at least two examples in mind: > > - I was very happy with using Konqueror 2.1, it was stable then Ivan > Moore decided to ship beta versions of kde libs 2.2 and it suddenly > crashed and no more kde app could stay in memory more than 30 seconds. > - the current version of mp3blaster is a beta version and there are > regressions in functionalities since some features are missing but > were present in the previous version. Then obviously neither of those should have been packaged. > As I said before, there are many means of installing applications, > people can download the tarball and break there systems it they > want. When you distribute a beta version in debs, you have the > risk to get bloated by BTS bugs about an application you know not > to be fully debugged. That's not always what "beta" means. In the case of trn4, for instance, the only reason it hasn't been declared stable is insufficient documentation. There was even less documentation in trn 3.6, so trn4's is an improvement. Furthermore, when upstream has slow development cycles, packaging a known-to-be-pretty-solid "beta" release may well be better for the users (i.e. result in fewer open bugs sooner) than waiting for a "stable" release which is some way off. Packaging a shoddy beta release will obviously lead to problems, in the same way as packaging a shoddy stable release would. Please let's stop worrying about some blurry, exaggerated distinction between "beta" and "stable" releases which isn't applied even vaguely consistently anyway across different upstream developers, and instead concern ourselves with the actual stability of the software. Jeff says in his bug report that there have been no reports on the MHonArc mailing list about 2.5.0b2; do you have evidence or concrete concerns that it isn't stable? In short, I fully agree that we shouldn't package buggy software. However, I disagree that upstream designations of releases are a universally reliable way of deciding whether a release is better and more stable for our users. (Jeff, please shout if you'd rather be left out of this discussion. :)) > > Davide Salvetti offered to adopt mhonarc last October. I e-mailed him > > about it in early August and never got a response, so I think I'll > > change its state back to orphaned and see if anybody else is interested > > in it. > > I already contacted him some times ago and it seems he is no longer > interested in adopting it. Ah, none of that discussion was copied to the bug report (#68829), so I didn't know about that. I've marked it orphaned. > As I'm packaging a mailing list manager which requires mhonarc, I > might adopt it. Great! -- Colin Watson [EMAIL PROTECTED]
Re: ddts: notification about it translation of the lilo-config description
On Mon, Oct 01, 2001 at 06:37:59AM -0400, [EMAIL PROTECTED] wrote: > This is merely an automated notification mail from the ddts 'Debian > Description Translation Server'. Can these please be turned off by maintainer (debian-qa@lists.debian.org or [EMAIL PROTECTED]), not by package? New packages become maintained by QA all the time. -- Colin Watson [EMAIL PROTECTED]
Bug#114195: StickyForm missing
On Tue, Oct 02, 2001 at 01:54:48PM +0200, Igor Mozetic wrote: > Package: htmlgen > Version: 2.2.2-4 > Severity: normal > > Is there any reason that the StickyForm.py code is missing > from deb (it is in documentation), or just an oversight? Just an oversight, as far as I know. We should have the debinstall target in the Makefile install $(EXTRAS) too. I'll have a look at it tomorrow night. -- Colin Watson [EMAIL PROTECTED]
Re: ddts: notification about it translation of the lilo-config description
On Tue, Oct 02, 2001 at 08:41:36AM +0200, Michael Bramer wrote: > On Mon, Oct 01, 2001 at 08:04:39AM -0500, Colin Watson wrote: > > Can these please be turned off by maintainer (debian-qa@lists.debian.org > > or [EMAIL PROTECTED]), not by package? New packages become > > maintained by QA all the time. > > I have not add this feature now. > > But I read this list and if I find a notification, I add this package > on the server list myself. That's very unreliable, and I'll bet you'll often miss them. That still leaves us with being spammed by the first one for each package, too, and debian-qa gets enough mail when a package enters its maintainership. > Where can I get a uptoday list of all qa packages? Search the Packages files for either possible maintainer address. I strongly encourage you to add support for NONOTIFICATION [EMAIL PROTECTED] instead, though, as that would alleviate a lot of people's annoyances with the ddts - from a brief look at the code, it looks like a matter of adding the maintainer address to the database plus a couple of extra lines of parsing code. Also, remember that if you won't do this you have to take packages out of the no-notification list again when they stop being maintained by QA. In general your system doesn't cope very well when maintainers change, because the preference is almost always on a per-maintainer basis rather than on a per-package basis. -- Colin Watson [EMAIL PROTECTED]
Re: ddts: notification about it translation of the lilo-config description
On Thu, Oct 04, 2001 at 12:10:44AM +0200, Michael Bramer wrote: > On Wed, Oct 03, 2001 at 03:28:44PM -0500, Colin Watson wrote: > > Search the Packages files for either possible maintainer address. I > > strongly encourage you to add support for NONOTIFICATION > > [EMAIL PROTECTED] instead, though, as that would alleviate a lot of > > people's annoyances with the ddts - from a brief look at the code, it > > looks like a matter of adding the maintainer address to the database > > plus a couple of extra lines of parsing code. [...] > ok, this is a 'right way' of the nonotification. I will code this... Thank you! -- Colin Watson [EMAIL PROTECTED]
RC bugs in packages maintained by this list
Martin did this a while ago, and I guess it's time to do it again ... Critical bugs - outstanding * #104576: dcoppython shadows python-pyqt Package: dcoppython; Severity: critical; Reported by: Bruce Sass <[EMAIL PROTECTED]>; Tags: sid; 95 days old. Grave functionality bugs - outstanding * #59031: ssh2: ssh2_2.0.13-5 sshd cannot create .Xauthority Package: ssh2; Severity: grave; Reported by: Ian Eure <[EMAIL PROTECTED]>; 1 year and 235 days old. * #83284: kicq segfaults Package: kicq; Severity: grave; Reported by: Markus Mohr <[EMAIL PROTECTED]>; 266 days old. * #96469: newsclipper: Missing Dependency on File::Cache Package: newsclipper; Severity: grave; Reported by: [EMAIL PROTECTED]; 164 days old. * #101322: Missing dependency on Log::Agent::Rotate Package: newsclipper; Severity: grave; Reported by: Tomas Pospisek <[EMAIL PROTECTED]>; 120 days old. I've fixed the last two in incoming. Serious policy violations - outstanding * #60498: new SSH2 broke SSH1 (sshd2 reports v2.0 not 1.99) Package: ssh2; Severity: serious; Reported by: Scott Jennings <[EMAIL PROTECTED]>; 1 year and 216 days old. * #89881: swi-prolog: bus error during build on sparc Package: swi-prolog; Severity: serious; Reported by: Ben Collins <[EMAIL PROTECTED]>; 214 days old. * #92749: failed autobuild of knews_1.0b.1-5 (m68k): chown of `debian/substvars.new' not permitted Package: knews; Severity: serious; Reported by: Michael Schmitz <[EMAIL PROTECTED]>; 196 days old. This is really a dpkg-dev bug (dpkg-shlibdeps calls chown when non-root), but we need to work around it somehow. * #99032: can't build on arm Package: swi-prolog; Severity: serious; Reported by: Philip Blundell <[EMAIL PROTECTED]>; 141 days old. * #109378: vic: build failure on alpha (and other 64 bit platforms) Package: vic; Severity: serious; Reported by: Paul Slootman <[EMAIL PROTECTED]>; 57 days old. * #110567: ssh2: missing Build-Depends, namely xbase-clients Package: ssh2; Severity: serious; Reported by: Paul Slootman <[EMAIL PROTECTED]>; 48 days old. * #110707: kdeutils: Doesn't build from source Package: kdeutils; Severity: serious; Reported by: John Goerzen <[EMAIL PROTECTED]>; 47 days old. * #111633: ssh2_2.0.13-5.2(unstable): build failure (possibly easy fix) Package: ssh2; Severity: serious; Reported by: Michael Weber <[EMAIL PROTECTED]>; 39 days old. * #112645: installing xlibs tries to overwrite /usr/X11R6/lib/X11/app-defaults Package: xmailtool; Severity: serious; Reported by: Jan de Vos <[EMAIL PROTECTED]>; 28 days old. I'm going to close this one; xmailtool is dead and xlibs is fixed. * #113550: xmailtool mail locking Package: xmailtool; Severity: serious; Reported by: Scott Dier <[EMAIL PROTECTED]>; 21 days old. This is presumably there to stop anybody reintroducing xmailtool. * #115303: qub: unbuildable on ia64 Package: qub; Severity: serious; Reported by: Branden Robinson <[EMAIL PROTECTED]>. I can clean out some of the ssh2 stuff, but somebody who actually knows about ssh should have a look at the ones that aren't just build failures. None of these packages seems to have an outstanding ITA filed; I can't find either an O or an ITA for kdeutils. If you're working on a package whose maintainer is debian-qa@lists.debian.org, please change the maintainer to [EMAIL PROTECTED] while you're at it, so that we can eventually look at just the one list. -- Colin Watson [EMAIL PROTECTED]
Bug#115958: knews: fails to build due to changes in libpng
Package: knews Version: 1.0b1-5 Severity: serious Several functions in libpng have been moved to PNG_INTERNAL "to discourage their use", with the result that knews no longer builds from source. I'm working on this, and have a patch which I think is roughly correct; it at least lets the package build. -- Colin Watson [EMAIL PROTECTED]
Bug#114590: Bug report mpg123 SID
On Fri, 5 Oct 2001 at 21:47:11 +0200, Frederic VANNIERE wrote: > Package: mpg123 > Version: 0.59r-9 > Distrib: SID (updated daily :) > > It seems tha the binary in this package is mpg123 0.59q, not 0.59r Why do you think that? [EMAIL PROTECTED] ~]$ mpg123-oss --help 2>&1 | head -2 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. [EMAIL PROTECTED] ~/src/debian/nmu/mpg123/mpg123-0.59r]$ head -1 CHANGES 0.59r: (MH) It certainly seems to be mpg123 0.59r from here. -- Colin Watson [EMAIL PROTECTED]
Bug#107300: blank image in window
On Tue, 31 Jul 2001 at 22:14:02 +, Tom Kuiper wrote: > Invoking imaptool on a .gif and a .jpg file of the same image gave me > a blank screen only. For the .gif file the screen was all black. For > the .jpg it was all light grey. The images when viewed with xv are > normal. > > The same problem happened when I locally compiled imaptool-0.9 except > that for the .jpg file the screen was all light blue. Would it be possible for you to send me the .gif and .jpg files in question? (I'm taking over the maintenance of the Debian imaptool package.) Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: RC bugs in packages maintained by this list
On Wed, Oct 17, 2001 at 07:44:36AM -0700, Sean 'Shaleh' Perry wrote: > Colin Watson wrote: > > If you're working on a package whose maintainer is > > debian-qa@lists.debian.org, please change the maintainer to > > [EMAIL PROTECTED] while you're at it, so that we can eventually > > look at just the one list. > > Has policy been changed as well? Seems so: 2.3.2. The maintainer of a package -- If the maintainer of a package quits from the Debian project, "Debian QA Group" <[EMAIL PROTECTED]> takes over the maintainership of the package until someone else volunteers for that task. These packages are called _orphaned packages_.[1] (Similarly in the Developer's Reference.) -- Colin Watson [EMAIL PROTECTED]
Bug#52878: knews (unstable) can't post (S-Lang Error)
On Thu, 16 Dec 1999 at 10:53:38 -0800 (PST), Jeremy C. Reed wrote: > When I click "Post --> Post a new article", I receive the error message: > > Failed to open terminal.S-Lang Error: Unknown Error Code > SLcurses_initscr: init failed > > I am using package slang1 version 1.3.9-1. (I assume that these versions > of slang and knews are incompatible.) Sorry for the late reply; knews has been lacking active maintenance in Debian for some time (and I'm just doing QA work). knews doesn't use S-Lang, so I don't believe this error can be coming from it. Perhaps the error was really from something like your editor? Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RC bugs in packages maintained by this list
On Thu, Oct 18, 2001 at 09:26:19AM +0200, Christian Kurz wrote: > If I remember correctly, then ssh2 offers some authentication and chroot > options, that are not available with OpenSSH. And I'm not sure if all > those features will be implemented into OpenSSH too. So therefor I would > be for keeping that package around and only agree with it's removal, if > our ssh maintainer also agrees with such a removal, because he be should > know best the differences from OpenSSH to the commercial ssh > client/server. And if it's worth it to keep both around or not. Are you willing to maintain it, or at least make it suitable for release? We're only contemplating its removal because it's orphaned and buggy. -- Colin Watson [EMAIL PROTECTED]
Re: RC bugs in packages maintained by this list
On Thu, Oct 18, 2001 at 04:26:06PM +0200, Christian Kurz wrote: > On 18/10/01, Colin Watson wrote: > > Are you willing to maintain it, > > No, since I'm currently happy with the number of packages that I > maintain. Also I'm tracking the OpenSSH development and so far it worked > for me, so that I don't have a need to use ssh2. > > > or at least make it suitable for release? > > Is that the new way of threading people who speak up against a removal > request for a package? Show me the threat. Otherwise, please calm down and stop being a twit. I'm merely trying to avoid the situation where people say "keep it" but nobody wants to keep it enough to fix its bugs so that we *can* keep it. Two of the RC bugs in ssh2 have been open for more than a year, causing it not to have been included in potato, and no-one seems to have cared enough so far. A package can be as worthy as it likes, but *somebody* has to want to maintain the thing. QA maintenance, while certainly better than the situation before the QA Group existed, is almost by definition not acceptable for a package in the long term. If it is, then there's no real reason to have normal maintainers at all. > Also why did you ignore my hint in which case a removal maybe > acceptable? I didn't. I was talking about the case in which the openssh maintainer reckons that there's a good reason to keep ssh2. In that case it needs a maintainer. > > We're only contemplating its removal because it's orphaned and buggy. > > Oh, so because it's orphaned we shall remove it? Great, when do you ask > to remove more packages from this list `grep-available -FMaintainer > -sPackage [EMAIL PROTECTED] which contains 225 packages with the > same reason? And yes, I'm pretty sure that some packages in that list > have also bugs and can therefor be called buggy, so that you reason for > removal is also fulfilled by them. So I plan to see more removal request > from you for packages which match the criteria that you defined above. > Otherwise this looks for me like someone seeking an very simple and easy > solution for handling release-critical bugs in packages maintained by > the members of this list. I look forward to seeing your proposed modifications to http://qa.debian.org/documentation/qa.html/ch-rules.html which modify the text that says that, after one month in which nobody has volunteered to maintain an orphaned package, "they will be withdrawn from the unstable distribution". I'm absolutely certain that a package which hasn't had a maintainer upload since February 2000 and which has RC bugs over a year old is well outside the limits where that document says (correctly, as far as I'm concerned) that we're supposed to seriously discuss removing the thing. Yes, if I see low-quality packages maintained by QA that nobody wants to maintain for real, I will (a) fix them if I can, (b) look for a proper maintainer who can fix them, and (c) if none can be found ask for them to be removed. (Sometimes the prospect of a package being removed can prompt somebody to step up to maintain it, so even the last resort (c) can be useful.) I won't be the first. Do you think that leaving crappy packages around increases the quality of Debian? If we don't have the guts to remove occasional packages that are "so buggy that we refuse to support them" (to quote Policy), then "Quality Assurance" is not the correct name for this list. Now, I suppose I've just bitten down hard on your attempt to start a flamewar. I apologize to the rest of the list. Can we get back to fixing packages now? -- Colin Watson [EMAIL PROTECTED]
Re: RC bugs in packages maintained by this list
On Fri, Oct 19, 2001 at 09:26:23AM +0200, Christian Kurz wrote: > On 18/10/01, Colin Watson wrote: > > On Thu, Oct 18, 2001 at 04:26:06PM +0200, Christian Kurz wrote: > > > On 18/10/01, Colin Watson wrote: > > > > Are you willing to maintain it, > > > > No, since I'm currently happy with the number of packages that I > > > maintain. Also I'm tracking the OpenSSH development and so far it worked > > > for me, so that I don't have a need to use ssh2. > > > > > or at least make it suitable for release? > > > > Is that the new way of threading people who speak up against a removal > > > request for a package? > > > Show me the threat. > > Pardon, telling someone who speaks up against a removal for either > maintainig the package or at "least make it suitable for release" is a > kind of threading people to shup up. Of course it's not! It's asking them if they would volunteer to do the necessary work, since *somebody* has to do it, and if they're interested in keeping the package around then they clearly know something about the package, and therefore would obviously be a better person to do a QA upload than somebody like me who knows next to nothing about it. Since when was asking people with knowledge if they would volunteer to do some particular task the same as telling them to shut up? (I hope it never was and never will be.) I think you somehow completely misunderstood my tone. > > A package can be as worthy as it likes, but *somebody* has to want to > > maintain the thing. QA maintenance, while certainly better than the > > situation before the QA Group existed, is almost by definition not > > acceptable for a package in the long term. If it is, then there's no > > real reason to have normal maintainers at all. > > And that's why I once suggested that orphaned packages are maintained by > a seperate group, who has enough man-power do this and have the QA group > focus on QA issues. Personally, I think orphaned packages *are* a QA issue. But now that the majority of orphaned packages have their maintainer set to [EMAIL PROTECTED], we might be able to split the discussion of their maintenance off to a separate list. (That was one of the points of changing the address, wasn't it?) Anyone? > > I didn't. I was talking about the case in which the openssh maintainer > > reckons that there's a good reason to keep ssh2. In that case it needs a > > maintainer. > > And then it's inappropriate or impossible for you to ask on debian-devel > with a broad audience for someone to become the maintainer of the > package, because it's needed? Matt had already done that before I replied to your first post in this thread. And it wasn't me who suggested removal in the first place. I fully agree with making every effort to find a maintainer for any package before removing it out of hand; that's why I asked you if you would do it, since you spoke up on the subject and since I know you've worked on ssh before. (You seem to be ascribing all kinds of motives to me which simply aren't there ...) > > I look forward to seeing your proposed modifications to > > http://qa.debian.org/documentation/qa.html/ch-rules.html which modify > > the text that says that, after one month in which nobody has volunteered > > Sorry, but that's a proposal only which was never accepted as standard > document outlining the actions of the QA Group. This document has > therefor exactly 0 importance for any decision that is made here, until > it's official accepted and the status changed. What does "officially accepted" constitute? A vote among people active in QA? I'd like to see some discussion so that we do have a set of guidelines that we know we all roughly agree on. My intent, though, was not to wave rules in your face (sorry if it sounded that way), but to point out that it looked as if at least the authors of that document would have agreed that it was time to think about removing ssh2, assuming they stood behind their words. One other thing; Adrian Bunk asked almost three months ago (http://bugs.debian.org/99950) on this list if anyone objected to ssh2 being removed. You objected, so it was not removed then, but nobody fixed the bugs either. > > unstable distribution". I'm absolutely certain that a package which > > hasn't had a maintainer upload since February 2000 and which has RC bugs > > over a year old is well outside the limits where that document says > > According to the last mail to debian-devel-announce the package is > exactly a 133 days orphaned, which is not nearly a year. So instead of > complaining now here about the lousy m
Bug#59031: Downgrading #59031
severity 59031 important thanks On the principle that if it doesn't break for everyone it's not grave, I'm downgrading this bug. My only guess at an ssh2 problem that might trigger this is that ssh2 might be trying to set up X forwarding without dropping privileges (and if that turns out to be true then it might be worth upgrading this again, but it seems unlikely); failing that it's probably a bug in xauth. Can you still reproduce this with current X? -- Colin Watson [EMAIL PROTECTED]
Re: RC bugs in packages maintained by this list
On Wed, Oct 17, 2001 at 05:44:32AM -0500, Colin Watson wrote: > I can clean out some of the ssh2 stuff, but somebody who actually knows > about ssh should have a look at the ones that aren't just build > failures. OK, acrimony aside, I've downgraded one of ssh2's RC bugs and fixed the remaining three in an upload now sitting in pandora's incoming, with Christian Kurz's help. Assuming that it builds cleanly, it should now be releasable. -- Colin Watson [EMAIL PROTECTED]
RFC: debian-qa-packages
One of the points that came up in my argument with Christian was that it'd be nice if we could split discussions of orphaned package maintenance off to a separate list. This was the original rationale for changing the orphaned Maintainer: field to [EMAIL PROTECTED] (Message-ID: <[EMAIL PROTECTED]>), and the timeline was "a few months". We now have 32 packages maintained by debian-qa and 223 packages maintained by [EMAIL PROTECTED], so it seems like it's time for the next stage in the transition. If there's consensus here then I'll request a new mailing list as follows: 1. Name debian-qa-packages 2. Rationale Due to the large number of orphaned packages and the verbose messages produced by the Debian Bug Tracking System and the archive maintenance tools in relation to them, the signal-to-noise ratio on the QA Group mailing list (debian-qa) is quite poor. We have spent some time over the last few months changing the maintainer address to [EMAIL PROTECTED], and would now like to be able to point that address at a separate list so that debian-qa can be used for more general discussions of quality assurance in Debian. 3. Long description Bug reports against orphaned packages and discussions about fixing them. 4. Category Developers 5. Subscription Policy Open 6. Post Policy Open 7. Web-Archive Yes (it's for discussion of bug reports as well as the reports themselves) 8. Short description Orphaned package maintenance Comments? -- Colin Watson [EMAIL PROTECTED]
Bug#116719: Please create debian-qa-packages
Package: lists.debian.org Severity: wishlist Name: debian-qa-packages Rationale: Due to the large number of orphaned packages and the verbose messages produced by the Debian Bug Tracking System and the archive maintenance tools in relation to them, the signal-to-noise ratio on the QA Group mailing list (debian-qa) is quite poor. We have spent some time over the last few months changing the maintainer address to [EMAIL PROTECTED], and would now like to be able to point that address at a separate list so that debian-qa can be used for more general discussions of quality assurance in Debian. Long description: Bug reports against orphaned packages and discussions about fixing them. Category: Developers Subscription Policy: open Post Policy: open Web-Archive: yes (it's for discussion as well as the reports themselves) Short description: Orphaned package maintenance Thanks, -- Colin Watson [EMAIL PROTECTED]
Time for another bugsquash?
Considering that woody is partly frozen, we have an awful lot of release-critical bugs (442 at the time of writing). It's been a long time since the last bug-squashing party, so how do people feel about holding another one? I suggest two weekends from now (Saturday 10th November / Sunday 11th November), since that gives us about enough time to contact maintainers and so on. (Although I suggest people have a look in advance at what they might want to work on and drop people mails about it - doing things en-masse can give a bad impression and results in whoever did it having a very full mailbox.) Obviously helping with base/standard/task bugs has priority. Look at http://base.debian.net/ and http://standard.debian.net/ and be afraid. There are also a large number of "easy" bugs currently outstanding, though. -- Colin Watson [EMAIL PROTECTED]
Bug-Squashing Party #6 on November 9-11
Hello all, The sixth Bug-Squashing Party for woody will take place on the second weekend of November: Friday 9th to Sunday 11th. Our goal is to fix release-critical bugs, especially those filed against base and standard/task packages. If you'd like to have an advance look at what needs to be done and warn of any non-maintainer uploads you think will be needed, please do. There are convenient interfaces to the lists of bugs in base and standard/task packages at http://base.debian.net/ and http://standard.debian.net/ respectively. The full list of release-critical bugs can be found at http://bugs.debian.org/release-critical/. Please concentrate particularly on RC bugs that have been open for a long time. We welcome help from developers and non-developers alike. Since substantial care should be taken with uploads of base and standard packages, we expect a lot of the work to consist of reproducing and diagnosing problems, with which anyone can help. If uploads are needed, there will be developers around throughout the party to review patches. As usual, the bug-squashing party will be co-ordinated in the #debian-bugs IRC channel on the OpenProjects network (IRC server irc.debian.org). It will start at 17:00 UTC on Friday 9th and continue until Sunday afternoon. Hope to see you all there! -- Colin Watson [EMAIL PROTECTED] pgp9la07hUyfL.pgp Description: PGP signature
Re: Package puzzle can be removed
On Mon, Nov 05, 2001 at 12:59:39PM +0100, Marcelo E. Magallon wrote: > Does anyone know if this is being taking care of? (I don't watch the > -dpkg or -whatever-the-relevant-one-is-called list at all) Will it be, > at some point in the near or far future, possible to rename packages in > a sensible way? Provides/Replaces/Conflicts? Dummy packages are only needed when there are versioned dependencies on the old package. -- Colin Watson [EMAIL PROTECTED]
Interest in libfloat?
Hi, The libfloat package is currently orphaned, and seems to be arm-only. Would anyone with ARM experience like to look after it? Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#118498: frad: fails to build on ia64
On Tue, Nov 06, 2001 at 11:20:31AM -0500, Doug Porter wrote: > I hope to hear from you soon. If I receive no word I will NMU > frad to fix this bug in seven days time, as per the guidelines > set for porters in the Debian Developer's Reference. Thank you. frad is maintained by the QA Group, so go ahead. Otherwise somebody will deal with it soon. -- Colin Watson [EMAIL PROTECTED]
Re: QA pop quiz
On Wed, Nov 14, 2001 at 05:14:05PM +0100, Marcelo E. Magallon wrote: > This one is open book, use whatever resources you want to find an > answer, but provide sources for any quotation (Colin, you still owe me > that PCR source). I don't know of a source for the composite Provides/Conflicts/Replaces trick, but it's easy enough to build it up from the definitions of each of those fields. Policy 7.5.2 says that Conflicts/Replaces allows one package to say that another should be removed, and renaming is identical to introducing a new package which forces the old package to be removed. It's an easy step to see that renaming must involve Provides/Conflicts/Replaces if you want dependencies to continue to work. (If versioned dependencies must continue to work, of course, a dummy package is required, until such time as we have versioned provides.) I see one use of P/C/R in the policy manual, again in section 7.5.2, although its use is somewhat different and involves mutually conflicting mail-transport-agents. That said, although dpkg's "considering removing foo in favour of bar" message is triggered by Conflicts/Replaces, dselect doesn't yet understand Replaces. > A package has or is the source of interoperability problems. What > should the bug severity be set to? Consider other Linux distributions > as well other Unix implementations. PS noted, but I'd have to take the easy way out and say "not enough information" here. There are situations where interoperability problems will render a package mostly unusable: say Debian's NFS client software broke interoperability with Solaris' NFS server, for example. Considering the number of sites where Solaris is chosen as the NFS server, this would be fair justification for 'critical' or 'grave'. Serious? Well, it depends on the source of the interoperability, but this severity probably only applies if the interoperability is an explicit policy violation (e.g. the package uses the wrong location for the mail spool). I think this would be more likely if the package fails to interoperate with other Debian packages, or if the interoperability is due to it being a violation of some specification (say, it's a news server that fails to handle dot-stuffing correctly) than if it fails to interoperate with software on other systems for more ordinary reasons. For most such problems, I would be liable to pick 'important' or 'normal', depending on the degree to which things break due to the bug. Examples of these might include Debian's ssh client being unable to talk to some particular commercial ssh server, or tar producing archives that can't be read by some other tar implementations. Is that a specific enough answer? I have a feeling you meant something a little less general than that. -- Colin Watson [EMAIL PROTECTED]
Re: WNPP bug overview
On Sat, Nov 17, 2001 at 05:32:22PM +0100, Bas Zoetekouw wrote: > My script can also automatically rename ITA's to O's and ITP's to RFP's. > Do you like this idea? Please make sure that you cc the person who submitted the ITA/ITP (who isn't always the bug submitter) if you do this. For instance, my xscrabble ITP is held pending legal issues, so if somebody decided it had expired and retitled it to RFP I'd like to know. I certainly don't object to the idea, though. -- Colin Watson [EMAIL PROTECTED]
Re: WNPP bug overview
On Sun, Nov 18, 2001 at 09:21:59PM +0100, Martin Michlmayr wrote: > * Martin Schulze <[EMAIL PROTECTED]> [2008 18:21]: > > The debian-devel-announce list may be more suited, with a > > Mail-Followup-To set to debian-devel. > > Perhaps it should be integrated with the main wnpp report. Yet > another weekly report to d-d-announce is probably not a good idea; > I doubt many people still read the weekly wnpp and bugtrack postings. Also, if it does need to be separate, I think a monthly posting would do well enough. -- Colin Watson [EMAIL PROTECTED]
Bug#47528: gcc-2.95 miscompiles saml
merge 47528 49342 thanks Both these segfaults happen in the same place, and are due to gcc-2.95 miscompiling lib/Integer.c: (gdb) 100 data = BI(n)->d; (gdb) 102 *data++ = ax % BASE; (gdb) 103 ax /= BASE; (gdb) 104 } while (ax); (gdb) p ax $1 = 0 (gdb) n 102 *data++ = ax % BASE; (It continues round the loop like this, blithely ignoring the fact that ax is 0, and eventually segfaults when the data pointer runs off the end of memory.) Compiling this file with gcc-3.0 fixes the problem, so these two bugs can be closed once the various port maintainers decide to start using gcc-3.0 as the default C compiler on all architectures. -- Colin Watson [EMAIL PROTECTED]
Re: Some uploads for orphaned packages
On Fri, Nov 09, 2001 at 09:36:46PM +0100, Adrian Bunk wrote: > Another one that is now in incoming: > > ilu_2.0.0.91-4_i386.changes I've just uploaded this one: saml_970418-8_i386.changes Should we change http://qa.debian.org/orphaned.html to report packages with the maintainer set to [EMAIL PROTECTED] -- Colin Watson [EMAIL PROTECTED]
Bug#120464: ipmenu: manpage fixes.
On Wed, Nov 21, 2001 at 11:43:29AM +0100, Uwe Hermann wrote: > here's a patch which fixes some issues with the ipmenu.8 manpage: While you're fixing typos, watch out for this one. :) > +.SH LISENCE (should be LICENCE or LICENSE, depending on your brand of English) -- Colin Watson [EMAIL PROTECTED]
Bug#120447: faqomatic: [patch] fix for Language_de
I'm going to adopt faqomatic and will apply this patch shortly. -- Colin Watson [EMAIL PROTECTED]
Premature removal of yodl Debian package
Hi, While I appreciate the reasons for removing yodl, there are still five packages in the Debian archive that rely on it in order to build (ecamegapedal, ecawave, xwatch, zsh, zsh-beta). Because of this, I think its removal was premature. Steve Kowalik had fixed the release-critical issues with yodl itself before the package was removed. I'm happy to resurrect yodl, fix the rest of its bugs, and maintain it until such time as nothing else in Debian build-depends on it. (I'm the groff maintainer, so another documentation language shouldn't be a problem.) Does anybody object to this? -- Colin Watson [EMAIL PROTECTED]
Re: Bug#120302: Premature removal of yodl Debian package
On Thu, Nov 22, 2001 at 10:29:43AM -0500, Clint Adams wrote: > Colin Watson wrote: > > I'm happy to resurrect yodl, fix the rest of its bugs, and maintain > > it until such time as nothing else in Debian build-depends on it. > > (I'm the groff maintainer, so another documentation language > > shouldn't be a problem.) > > Please do so as soon as possible. It's now in incoming. I'll let you know when the ftpmasters install it. -- Colin Watson [EMAIL PROTECTED]
Re: Bug #74239 - Will it ever be fixed?!
On Wed, Nov 28, 2001 at 11:08:04PM +, Matthew Vernon wrote: > Åke Wallebom writes: > > #74239: ssh: X11 forwarding hangs connection attempt > > Package: ssh2; Severity: important; Reported by: Brian White <[EMAIL > PROTECTED]>; 1 year and 53 days old. > > > > Will it ever be fixed?! I really want to use X11 Tunnels! > > > > Is there another package for debian which provides a ssh2 > > compatible server? > > the openssh packages are probably what you want. Indeed (the binary package is just called 'ssh'). If you need the non-free ssh in particular to be fixed for some reason you'll probably have to track it down yourself, as there isn't much in the way of maintenance happening on ssh2 (being orphaned and all). On the other hand if you *do* find a fix somebody will certainly be able to apply it. -- Colin Watson [EMAIL PROTECTED]
Bug#121697: gcc-m68k-linux (was Bug#121697: mpg123: Man page in /usr/man, not /usr/share/man)
On Thu, Nov 29, 2001 at 01:21:42PM +0100, Jordi Mallach wrote: > On Thu, Nov 29, 2001 at 04:37:50AM -0500, Anthony DeRobertis wrote: > > mpg123 is one of the only five man pages left in /usr/man ... > > what are the others? If somebody could fix, adopt, or decide that it's OK to remove gcc-m68k-linux, we'd have finished the /usr/doc transition on i386 and I could start tracking /usr/man and others on the QA pages. Can anyone on -68k say what should be done here? Bas Zoetekouw asked about this in August and [EMAIL PROTECTED] said he was going to adopt it, but nothing seems to have happened since. Thanks, -- Colin Watson [EMAIL PROTECTED]
