remove aleph?

The aleph package, long orphaned, is no longer maintained upstream (the last release was three years ago). It is exhibiting a namespace collision; it installs /usr/bin/aleph, and TeX also wants to install that. As a result, there is a Conflict between TeX and aleph, but even so, the release crite

dropping gnome 1 packages

Since consensus is that we should drop the gnome-1 packages which aren't used by other Debian packages, we need to be very sure to put a note to this effect in the release notes for etch. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EM

orphaning Gnome 1 libraries

For a while I have been maintaining the gnome-1 libraries, because gnucash was the last big package which required them. When I uploaded the gnome-2 version of gnucash into unstable, I filed RFAs for these libraries. Now that the gnome-2 version of gnucash has migrated into testing, I'm orphan

Re: Update on orphaned packages with very low popcon numbers

Nathanael Nerode <[EMAIL PROTECTED]> writes: > malaga: 16 (5 votes) Please note from #369161 that there is someone who might be willing to maintain malaga if asked, under sponsorship. > manpages-fi: 14 > manpages-ko: 16 Dropping these is really not an option; Debian is committed to internationa

Re: Orphaned packages with very low popcon numbers

Michael Stone <[EMAIL PROTECTED]> writes: > On Wed, Jun 14, 2006 at 05:18:13PM -0700, Thomas Bushnell BSG wrote: >> Yes. Deleting information is a big step. > > Luckily we aren't doing that, since the information itself is still > available in archives. Whose arc

Re: Orphaned packages with very low popcon numbers

Michael Stone <[EMAIL PROTECTED]> writes: > No, what is unsubstantiated is your characterization of what is > happening. One of things that happens *every time* this sort of > discussion comes up is that someone starts creating straw men along > the lines of "what if some important package gets re

Re: Orphaned packages with very low popcon numbers

Michael Stone <[EMAIL PROTECTED]> writes: > On Mon, Jun 12, 2006 at 10:55:32AM -0700, Thomas Bushnell BSG wrote: >>But a bulk "anything that is orphaned and has a low popcon number must >>be useless" is incorrect. > > You've made this assertion several

Re: Follow-up to "52 packages it would be nice to remove"

"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > After a suitable period of time to collect replies (two weeks), I plan > to write to the debian-qa mailing list. I'll give a summary of the > source packages listed at the first URL above for which I received > affirmative, negative, and no respons

Re: Orphaned packages with very low popcon numbers

Michael Stone <[EMAIL PROTECTED]> writes: > On Mon, Jun 12, 2006 at 09:51:28AM +0200, Thomas Viehmann wrote: >>Basically, this amounts to perpetually keeping obsolete packages. Is a >>good choice? > > Well, at least you've learned why debian has so much obsolete > junk--the "every package is sacre

Re: Orphaned packages with very low popcon numbers

Thomas Viehmann <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG wrote: >> If it gets dropped entirely, then the user doesn't get any notice of >> that fact; their system just keeps on going as before. Except that >> the package now gets *no* updates instead of

Re: Orphaned packages with very low popcon numbers

Nathanael Nerode <[EMAIL PROTECTED]> writes: > If they require *any* maintenance, they are a waste of our time. QA has > hundreds of packages to maintain, most of which have far, far more users. > (Some have several thousand popcon installations.) Um, great. I've been quite happy not to spend

Re: Orphaned packages with very low popcon numbers

Thomas Viehmann <[EMAIL PROTECTED]> writes: > I'd prefer Debian releases to consist of properly supported packages as > much as possible. It's not as if we want to forcibly delete the packages > from our user's machines, we'd just acknowledge that they aren't > maintained anymore. Me too, but I w

Re: Forcibly orphaning mhash?

Nathanael Nerode <[EMAIL PROTECTED]> writes: > As discussed in this bug, mhash's maintainer appears to be MIA or > out to lunch. > > Is it OK if we forcibly orphan the package now? There is no procedure for forcible orphaning the package. If you have a fix for the bug (the bug log seems to sugge

Re: Hijack or remove postgis

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Something has to be done about the postgis package. There are RC > bugs on uninstallability and FTBFS as well as several functionality > bugs and two new upstream releases and no one seems to do anything. > The packaging seems to be sufficiently ugly

Bug#359905: PTS: unsubscription fraud possible

MJ Ray <[EMAIL PROTECTED]> writes: > They have an attacker-specified subject line and can be loaded > with content after the stop command, to trigger spam traps. > If you expect users to flag up these messages, how can they > spot them? I recall you insisting that false positives were not a serio

Re: Bug#280691: Removing efax

MJ Ray <[EMAIL PROTECTED]> writes: > As you may appreciate for a package without an upstream release for > a long time, there are a quite a few bugs to squash. Maybe I will > give up on some for now just to upload and avoid Matej's attention. There is never anything wrong with fixing some bugs an

Re: Idea for maintaining packages up for adoption

Raphael Hertzog <[EMAIL PROTECTED]> writes: > But building packages from a suvbersion repository can be done > automatically. So yes, we could provide automatically unofficial > packages to the users. I'm fine with that, but I'm against making them official packages. Which means we need to do n

Re: packages with invalid maintainer fields

Matthew Palmer <[EMAIL PROTECTED]> writes: > If the package is improperly maintained, someone else will take it over > sooner or later and give it the love it needs, regardless of what is in the > Maintainer: field. Ignoring questions about the package (whether > machine-assisted or through pure

Re: packages with invalid maintainer fields

Matthew Palmer <[EMAIL PROTECTED]> writes: > Again, what material effect does that have? Does it prevent the person who > has primary interest in the package (whom we commonly term "the maintainer") > from updating it? It might mildly interest QA people, but since they NMU > packages in bad shap

Re: packages with invalid maintainer fields

Russ Allbery <[EMAIL PROTECTED]> writes: > Plus, I really don't think there's any way that one can achieve, let > alone mandate, zero false positives -- as previously mentioned, > purely human spam filtering does not have zero false positives. There's a wild difference between these two cases, wh

Re: packages with invalid maintainer fields

Russ Allbery <[EMAIL PROTECTED]> writes: > Please don't underestimate the problems caused by backscatter. Nearly all > of my current virus load is backscatter traffic, and each time a new virus > comes out I tend to get a hundred copies and several hundred to a thousand > bounce messages claiming

Re: packages with invalid maintainer fields

Matthew Palmer <[EMAIL PROTECTED]> writes: > On Sat, Jun 18, 2005 at 03:36:44PM -0700, Thomas Bushnell BSG wrote: >> Debian maintainers are required to provide a valid email address in >> the maintainer field for package uploads. Some maintainers have >> adopted the

Re: packages with invalid maintainer fields

Russ Allbery <[EMAIL PROTECTED]> writes: > I adopt no particular spam filtering rules at the SMTP layer, but I use > bogofilter (a Bayesian-trained spam filter) to pre-process my mail and > weed out the spam. The chances of me noticing a false positive are > non-zero but fairly low. It is plausi

packages with invalid maintainer fields

Debian maintainers are required to provide a valid email address in the maintainer field for package uploads. Some maintainers have adopted the policy of various arbitrary filtering rules of their own invention, under which they will not receive some proper email from perfectly legitimate senders

Re: Removing old orphaned packages?

Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Jun 14, 2005 at 04:48:03PM -0700, Russ Allbery wrote: >> > x-ttcidfont-conf -- Configure TrueType and CID fonts [#201376] > >> If someone has a chance to explain this one, I'm really curious what's up >> with it. I never really understood what

Re: Removing old orphaned packages?

Martin Michlmayr <[EMAIL PROTECTED]> writes: > libcapplet -- Library for Gnome Control Center applets [#197841] > * Orphaned 727 days ago > * Package orphaned > 360 days ago. As explained in private mail and a bug log too (and repeated here just for completeness) this package is needed for gt

Re: Bug#307488: please upgrade to newer libtool (libtool1.4 being removed)

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Tue, 03 May 2005, Thomas Bushnell BSG wrote: >> > libtool1.4 is no longer maintained and will be removed from the >> > archive after sarge is released. Please upgrade your package to use a >> >

Re: Bug#307488: please upgrade to newer libtool (libtool1.4 being removed)

Martin Michlmayr <[EMAIL PROTECTED]> writes: > libtool1.4 is no longer maintained and will be removed from the > archive after sarge is released. Please upgrade your package to use a > newer, ideally the latest, version of libtool, and make sure this gets > integrated in upstream. What about the

gtkhtml

The new gtkhtml package, taken over by from Takue KITAME, has now been accepted by the ftpmasters. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

roleplayer

As per the follow-up you just got (see bug 246486 for complete context), I have requested that ftpmaster drop "roleplaying". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages which build-depend on libtool1.4

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > That will get a lot of people whose upstream still thinks they can get away > with autoconf 2.13 and libtool/automake 1.4 forever pissed, but probably the > only package we will have to tolerate violating that rule is gnucash (whose > build

Re: Packages which build-depend on libtool1.4

Martin Michlmayr <[EMAIL PROTECTED]> writes: > IMHO they are important since libtool1.4 *will* be removed and then > the bugs are serious. The only reason we're keeping libtool1.4 for now is > because those packages still use it. Many developers might be using libtool1.4 without needing to decla

Re: Let's remove moria

Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005-03-14 10:39]: > > > Removing it from non-free still doesn't hurt anything, since IIRC > > > that'll have to happen anyway when it goes to main. I don&

Re: Let's remove moria

Andrew Suffield <[EMAIL PROTECTED]> writes: > On Mon, Mar 14, 2005 at 01:21:45AM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 14 Mar 2005, Martin Michlmayr wrote: > > > > I don't think that the QA team should be formerly adopting non-free > > > > packages. I think our resources are best u

Re: gtkhtml is unmaintained

Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005-03-04 13:31]: > > Takuo Kitame, the maintainer of gtkhtml, has not been maintaining it, > > and an upgrade has been necessary for ages to fix a known gnucash > > prin

Re: gtkhtml is unmaintained

Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005-03-04 13:31]: > > Takuo Kitame, the maintainer of gtkhtml, has not been maintaining it, > > and an upgrade has been necessary for ages to fix a known gnucash > > prin

[Olaf van der Spek ] Whereabouts of missing maintainer shiju@infovillage.net (Shiju p. Nair)

--- Begin Message --- Hi, Does anyone know about the whereabouts of the mrtg maintainer, Shiju p. Nair? The package has bugs that are multiple years old and no recent uploads by the maintainer. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mrtg -- Olaf van der Spek http://xccu.sf.net/ --

gtkhtml stuck

It appears that you are not willing to maintain the old gtkhtml20 package anymore. You have not been willing to respond to my emails or offers to help. The failure to upgrade to version 1.1 is causing an severity "important" bug in gnucash to go uncorrected for at least a year. This is not acce

gtkhtml is unmaintained

Takuo Kitame, the maintainer of gtkhtml, has not been maintaining it, and an upgrade has been necessary for ages to fix a known gnucash printing bug. He has told me that he thinks gtkhtml should be dropped because it's been replaced with newer versions, but gnucash depends on the old gnome-1 vers

Re: help needed with mips build failure

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > As for it being complicated, well, I believe you. But you need not be > upstream to change the build system, I have done that three or four times > already. It is not the most gratifying work in the world, at all... but the > result is fa

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > Clearly not, or it wouldn't have failed to build on mips and mipsel. There > is nothing "perfectly working" about that version of libtool, and moreover, > its effects are not limited to the mips architectures -- as the obscenely > long list of library

Re: help needed with mips build failure

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Wed, 16 Feb 2005, Thomas Bushnell BSG wrote: > > Now, it should be noted, upstream uses autoconf 2.13, and libtool > > 1.4c. So these errors should not be happening, and seem to imply > > problems i

Re: help needed with mips build failure

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > You're using an old (and broken) version of libtool. C.f. > > <http://lists.debian.org/debian-qa-packages/2003/09/msg00023.html> for > > Ryan&#x

Re: help needed with mips build failure

Steve Langasek <[EMAIL PROTECTED]> writes: > You're using an old (and broken) version of libtool. C.f. > for > Ryan's boilerplate explanation for fixing this problem. Thanks a bunch, this is surely the problem, but applying the s

help needed with mips build failure

Can someone with mips and/or libtool expertise examine the build failure for gnucash below, and see if they can diagnose the problem? http://buildd.debian.org/fetch.php?&pkg=gnucash&ver=1.8.10-5&arch=mips&stamp=1107337123&file=log&as=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a su

Re: QA packages for release

Amaya <[EMAIL PROTECTED]> writes: > Right, I have changed severities and merged both bugs, and I am working > on an upload that fixes several minor bugs. > > There's also a recently approved Alioth project to take care of lirc and > libirman as a group. > > We are also working into getting newes

Re: doomlegacy

Andreas Metzler <[EMAIL PROTECTED]> writes: > #264816. I think the right thing to do is file a bug against ftp.debian.org.

Re: doomlegacy

Robert Millan <[EMAIL PROTECTED]> writes: > Do you still want to maintain doomlegacy in Debian? It's currently > in violation of Raven Corp.'s license in upstream, and has other > release-critical problems. It also has a number of deficiencies, > and with better alternatives like prboom I'd sugg

QA packages for release

For a while I've been tracking the sarge inclusion of QA-managed packages. Here is a status report. Some of you are getting this because you have done something relevant to one or more of these packages and should stay on top of things. But I have set the Reply-To to debian-release. If you rep

Re: ppxp build failure

Luk Claes <[EMAIL PROTECTED]> writes: > I have built the package in a clean pbuilder. It builds fine. So what explains the buildd failure? Can you upload it in a binary NMU so that at least we can get the package into testing?

Re: FTBFS, error in .orig.tar.gz

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > The problem is that clean doesn't need to be run. Policy says you should > be be able to build the package by just unpacking and then running > 'debian/rules binary'. > > Buildd's run clean first, but that isn't required, and a FTBFS when > clea

ppxp build failure

See bug http://bugs.debian.org/267927. I only just noticed the ppxp build failure, which is i386 specific. The -9 version was fine, but the -10 version fails. But the -10 version only changed package descriptions and the maintainer address. (All previous uploads were build by the maintainer on i

Re: FTBFS, error in .orig.tar.gz

Matthew Palmer <[EMAIL PROTECTED]> writes: > I don't believe it is possible to upload a new orig.tar.gz for the same > upstream version of a package. That's a fairly reasonable thing, IMHO -- > you really don't want the source for your package shifting under your > feet... Well, what we need is

FTBFS, error in .orig.tar.gz

See http://bugs.debian.org/264172. So I don't know what is the standard way to force an upload of a new .orig.tar.gz file. Most people don't see the bug, because we apt-get source as non-root, so that tar unpackas without setting the setuid bit, and then the package builds without errors. But

The sarge/sid table of importance

Jeroen van Welffelaar helpfully filled in the widget at http://www.wolffelaar.nl/~sarge/ for the packages maintained by QA. However, since he did so, some new entries have arisen in that table needing attention. I have just set entries for the following packages which had no previous judgment in

Re: mmake problem solved

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > By the way, I'd like to politely request to not start a new thread when > it's not needed, this breaks threading of related mails. I apologize. Sometimes I do it intentionally, because there it does carry a particular semantic tone, and I inte

Re: [EMAIL PROTECTED]: Re: Accepted mmake 2.2.1-4 (all source)]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED]/tmp/mmake-2.2.1$ cat LICENSE > COPYRIGHT GNUGPL (c) 1998-2001 Jan-Henrik Haukeland <[EMAIL PROTECTED]> > > Redistribution and use with or without modification, are permitted > provided that the above copyright notice can be rep

mmake problem solved

So rather than a seemingly interminable conversation, it is hereby concluded, since I have now closed bug 261581, and QA need no longer be concerned with the question. Thomas

Re: [opal@debian.org: Re: Accepted mmake 2.2.1-4 (all source)]

Ola Lundqvist <[EMAIL PROTECTED]> writes: > Well well. I assume of non-serious priority right? > I did a random check of tree packages. 2 of them was correct and 1 did > not include such source comments (hsftp). It depends on the particular case. > That he removed GNUGPL.TXT and LICENSE and adde

Re: [opal@debian.org: Re: Accepted mmake 2.2.1-4 (all source)]

Ola Lundqvist <[EMAIL PROTECTED]> writes: > > associated with the copyrights in the actual source files, and that's > > what actually matters. I wish it were not so, but thus it is. We > > cannot tell from that file which things it covers, and that makes it > > not a valid license. :( > > Well

attempts to fix

It turns out that fixing this bug is not trivial; it is merely one of a whole host of problems that are caused because apparently swig has changed its interface in a variety of ways. Adapting to the changes seems easy on the assumption that you understand swig, but I don't. Perhaps version 2.0.1

Re: [opal@debian.org: Re: Accepted mmake 2.2.1-4 (all source)]

Ola Lundqvist <[EMAIL PROTECTED]> writes: > My reference comes from that GNUGPL.TXT in the source. > > The LICENSE file is a bit short but the GNUGPL.TXT file covers > everything just as it should. It just has an uncommon name, that > is all. The LICENSE file there is, alas, not sufficient. It

Re: Accepted mmake 2.2.1-4 (all source)

reopen 255955 thanks Ola Lundqvist <[EMAIL PROTECTED]> writes: > Description: > mmake - Makefile generator for Java programs > Closes: 199875 216534 255955 > Changes: > mmake (2.2.1-4) unstable; urgency=low > . >* Updated copyright file so it include GPL in a correct way, closes: >

Re: Bug#264774: Age horribly out-of-date RFPs.

Moritz Muehlenhoff <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG wrote: > > I don't object to doing a cleanup now, but my QA bug here is not about > > doing one now, but about creating an infrastructure and record-keeping > > system that would provide advice a

Re: Bug#264774: Age horribly out-of-date RFPs.

Moritz Muehlenhoff <[EMAIL PROTECTED]> writes: > Good idea, there's alot of cruft and with more than one megabyte size > as HTML WNPP should really be put on a diet. I don't object to doing a cleanup now, but my QA bug here is not about doing one now, but about creating an infrastructure and reco

Bug#264769: Provide QA advice and tables for WNPP cleanup work

Frank Lichtenheld <[EMAIL PROTECTED]> writes: > I have done some ITA clean-up runs in the last year and I believe that > the task can be much more automated but finally we always will need some > people that check all retitle actions before they are actually applied. > Will save us a lot of discus

Bug#264769: Provide QA advice and tables for WNPP cleanup work

Package: qa.debian.org Severity: wishlist A necessary QA task is occasional cleanup of stale WNPP information. The most important tasks are to do something about very old and non-current ITA and ITP records, because these may inhibit people from volunteering for tasks that still need to be done.

Bug#264774: Age horribly out-of-date RFPs.

Package: qa.debian.org Severity: wishlist So this is similar to my last item, but different. There are 1707 wishlist items in WNPP now. Maybe 10% of those are ITP. Some of these are very very old. But most are fairly recent. It seems to me that some kind of thing should happen to those which

Re: WNPP cleanup procedures

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > Well, if you prepare text and code for it, I'll put it on the web > > page. But the issue there is IMHO: How can the program dectect when > > the title was c

Re: WNPP cleanup procedures

Andreas Barth <[EMAIL PROTECTED]> writes: > Well, if you prepare text and code for it, I'll put it on the web > page. But the issue there is IMHO: How can the program dectect when > the title was changed? So, it needs to permanently track each bug. Well, I can prepare text. ;) I'm not good at th

"fixed" for QA packages

As you have no doubt noticed, I have finished clearing out the "fixed in NMU" bugs for QA packages. Most of these were fixed in NMU, then the package was orphaned, and then taken by QA. There is no such thing as an NMU of a QA package, and so at this point the "fixed in NMU" bug becomes official

Re: WNPP cleanup procedures

Andreas Barth <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG ([EMAIL PROTECTED]) [040809 22:55]: > > Andreas Barth <[EMAIL PROTECTED]> writes: > > > Well, there is a list of ITA packages. Of course, you need to take a > > > look into the bug report i

Re: WNPP cleanup procedures

Andreas Barth <[EMAIL PROTECTED]> writes: > > > for any action; however, if I saw good reason from the history of a > > > bug report to not do anything, then I didn't write mail at all. > > > By RFP you mean ITA? > > No, I meant: Request for Packages and Intend to Package. Oh; I'm thinking spe

Re: WNPP cleanup procedures

Andreas Barth <[EMAIL PROTECTED]> writes: > I did take 6 months for an ITP, and one year for a RFP as lower limit > for any action; however, if I saw good reason from the history of a > bug report to not do anything, then I didn't write mail at all. By RFP you mean ITA? I think six months and a

WNPP cleanup procedures

There used to be an established set of procedures for aging stale ITP and ITA wnpp entries, and setting them back to O. As I recall, it was something like: If the ITA or ITP is more than a month old, then: QA/WNPP sends email asking if they still intend to package or need help, If no respons

Re: distributed-net-pproxy

Matthew Palmer <[EMAIL PROTECTED]> writes: > The procedure I've observed is that someone files a bug on ftp.debian.org > asking for removal, ftpmasters reassigns the bug to qa.debian.org, and then > tbm reassigns it back to ftp.debian.org with a rationale. Ok, I'll reassign the existing thing to

distributed-net-pproxy

distributed-net-pproxy should be deleted from Debian; see Bug 241112. Can we make this happen? (I'm a little hesitant about the right procedure for these kinds of cases; is it ok for me to simply queue the appropriate bug on ftp.debian.org, or should I ask here first?)

freehoo

See bug 228039. Freehoo should, in my opinion, be dropped from unstable. The last change in the upstream CVS was seven months ago, and given that yahoo changes its protocols frequently (and deliberately to frustrate free clients)--and since gaim is doing a decent job of keeping up--there doesn

Re: need help

Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2004-08-07 17:21]: > > I suspect this means that guile-oops should actually be removed, but > > #263719: ftp.debian.org: Please remove guile-oops from unstable Ah, I missed that! Thanks.

snacc status?

On July 5, W. Borgert offered to try and fix the RC bug for snacc. Has progress been made? I have some experience with the auto* tools, and perhaps I would be able to fix the problem, but I don't want to step on anyoone's toes. Thomas

Re: work in progress on maintainer addresses

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > I'm working on fixing the maintainer addresses for some long-orphaned > packages. Ok, I've finish what I'm doing for now. I did most (but not all) of the packages which have been orphaned more than 14 days and are lis

need help

I would like to set the maintainer address for guile-oops to the proper QA address, but recent versions of guile have goops built in, and when you try to build the package, the configure script detects this and refuses to build it. I suspect this means that guile-oops should actually be removed,

work in progress on maintainer addresses

I'm working on fixing the maintainer addresses for some long-orphaned packages.

Re: Last minute package update request

Anthony Towns writes: > If people are busy doing productive things that you want to have happen > faster or more reliably or more professionally, do _not_ try to distract > them with an idiotic flamewar --- least of all one that's been done > to death twice already. It's a _very_ simple rule, wit

Re: Last minute package update request

Anthony Towns writes: > And, just to expound upon that before we drop further into the usual > sort of self-righteousness these threads evoke, you do _not_ know > what you're talking about at all. Right now, eg, much of ftpmaster is > working on fixing the security infrastructure. When people m

Re: Last minute package update request

Anthony Towns writes: > Everyone's an expert. You know, your attitude is really not helpful. You responded to a courteous message, one which thanked you for doing a difficult job well, and you comment with something snide like this. And it comes amidst an attitude of utter refusal to explain a

[Adam Heath ] Re: Debian doesn't have to be slower than time.

Attn: whoever maintains bugs.debian.net: --- Begin Message --- On 17 Feb 2002, Thomas Bushnell, BSG wrote: > The QA team has an actual list of the people who officially have this > attitude. It is, from bugs.debian.net: > * Adam Heath Remove me from this list. I no longer feel

Re: ITP->RFP

Bas Zoetekouw <[EMAIL PROTECTED]> writes: > Hmm, this would indeed be a better solution, the only problem being that > it's not very easily automated. Maybe the bug should also be tagged > appropriately (unactive or something) when sending the QA question. Then > my script can easily determine whi

Re: ITP->RFP

Bas Zoetekouw <[EMAIL PROTECTED]> writes: > I intend to rename all ITP's that haven't had any activity in the last > 100 days to RFP's. Any objections? I would propose the two-stage method in use for ITAs: For each apparently stale ITP: 1) If the last thing that happened in the bug is a QA qu

Re: ITP->RFP

Martin Michlmayr <[EMAIL PROTECTED]> writes: > This problem with WNPP should be solved when people can subscribe to > individual bugs. Well, except that it really would be solved when that feature exists *and* the "relevant" people are auto-subbed to particular wnpp bugs.

Re: QA logbook

Torsten Landschoff <[EMAIL PROTECTED]> writes: > Indeed. But OTOH this looks like a major time hog for me. Even discussing > how to implement this can take a lot of time from our fellow developers. > Not that I am against it, but I think we would need something to report > on first. Well, if we

Re: When should the BTS help tag be used?

Torsten Landschoff <[EMAIL PROTECTED]> writes: > On Sun, Jan 13, 2002 at 01:51:59PM +0100, Josip Rodin wrote: > > On Sun, Jan 13, 2002 at 05:30:28AM +0100, Torsten Landschoff wrote: > > > Frustrating. There are 1001 bugs tagged "patch"... > > > > Hey, that's better than 1001 bugs tagged "wontfix"

Re: When should the BTS help tag be used?

Colin Watson <[EMAIL PROTECTED]> writes: > Would some lists of bugs with other tags set be helpful? I'm thinking of > unreproducible, security, and perhaps moreinfo. I think that "security" should be of interest to the security team; other than that, I don't see a particular need for the others.

Re: When should the BTS help tag be used?

Edward Betts <[EMAIL PROTECTED]> writes: > One of my bugs (98053 freesweep forwarded normal help) is tagged help. It is > half fixed with a work-around, upstream did not seem interested in fixing it, > but said they would have a look. This was a few months ago. I tagged the bug > help, to encourag

Re: Implementing my proposal for the organisation of QA

Adrian Bunk <[EMAIL PROTECTED]> writes: > I'd like to get this running, so I'd like you to tell me within one week: > - if you seriously object against it > - to tell your comments about the suggested tasks below I have no objection to having people that are designated as being responsible for ce

Re: Bugs tagged help

Edward Betts <[EMAIL PROTECTED]> writes: > "Thomas Bushnell, BSG" <[EMAIL PROTECTED]> wrote: > > Edward Betts <[EMAIL PROTECTED]> writes: > > > > > Colin Watson <[EMAIL PROTECTED]> wrote: > > > > 98053 freesweep forwarded no

Re: Bugs tagged help

Edward Betts <[EMAIL PROTECTED]> writes: > Colin Watson <[EMAIL PROTECTED]> wrote: > > 98053 freesweep forwarded normal help > > This is one of mine, requires some knowledge of autoconf and hurd which I do > not have. Can anybody help? Um, Marcus Brinkmann who well understands both is already h

Re: Bug#128138: postfix: file conflict with package "smtpd"

Colin Watson <[EMAIL PROTECTED]> writes: > Is there a real need to copy run-of-the-mill bug reports to -qa like > this? I can see it making some amount of sense if the maintainer was > very inactive and there was a good chance that an NMU would be required > before somebody spotted it in the cours

Re: microwindows build status

Michael Schmitz <[EMAIL PROTECTED]> writes: > It was easily reproduced - there's no libmwdrivers.a for powerpc and the > microwindows build tries to use that before it's built. No, no, a thousand times no. microwindows does try to build libmwdrivers.before it's used, and without someone giving m

Re: microwindows build status

Colin Walters <[EMAIL PROTECTED]> writes: > On Fri, 2002-01-04 at 18:47, Thomas Bushnell, BSG wrote: > > This is not such a good idea. Maintainers are generally not > > responsible for checking build status and logs [...] > > Which is kind of silly, given how

  1   2   >