n user;2527;24;1;2013-09-05;2686;5;
> kboot-utils;Antonio Ospite ;;979641;Unknown
> user;2;1;1;2013-12-14;2586;0;
> libdbix-class-htmlwidget-perl;Al Nikolov
> ;;979529;Timeout;9;1;1;2017-06-08;1314;7;
> liblingua-en-namecase-perl;C. Chad Wallace
> ;;979502;Unknown user;17;2;1
You can point master at the correct branch for the packaging, or if you
prefer, you can add '-b foo' to your Vcs-Git field, as documented in Policy.
The wording of the message on the tracker may be suboptimal, but I do think
it's reasonable to ask that 'debcheckout' be given
On Mon, Nov 24, 2014 at 12:34:27PM +0100, Holger Levsen wrote:
> On Freitag, 21. November 2014, Steve Langasek wrote:
> > The libpam-modules-bin package ships no maintainer scripts. Therefore
> > there is nothing at the "setting up" stage which is under control of this
&g
I am not likely to have any time/motivation to contribute to this software
in the near future, but I'd like to just say thank you for including a link
to the git repo in the page output. This should be considered best practice
for all our web infrastructure, and is an important s
Yep, I can confirm this here.
Attaching a tcpdump capture for reference.
I imagine this will need to be taken up with T-Mobile.
For reference, a 'HEAD / /HTTP/1.1' on a direct connection to port 80
returns the correct information.
--
Steve Langasek Give me a lever l
of them also
being shown by default (though we'd probably want to aggregate all of them
in the default view to not wind up with an endless set of columns each
reporting zero bugs for the common case). It's always easier for someone to
hide the information they decide th
José Carlos, are you still interested in maintaining dogtail? You haven't
uploaded it in 6 years, and it does seem to be in need of attention.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can mov
aning packages?
According to LDAP, the maintainer has been active in the BTS as recently as
two days ago. An NMU for a serious bug is obviously ok (including in
experimental), but you can consider this an objection to any such "soon"
orphaning.
--
Steve Langasek Gi
I'm with Jakub on this one - RFA means that the maintainer would like
it known that they want to hand it off, but they are still maintaining it
and should have a say in who they hand it off to as the next maintainer.
That's always been part of the distinction between RFA and O packa
t
everyone who receives bug mail has the BTS bug numbers memorized. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debi
- a stale ITP may mean that the proposer is no
longer interested in the package at all, not that they want someone else to
package it because they've run out of time. So I would propose closing
stale ITPs outright, not converting them to RFPs.
--
Steve Langasek
On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote:
> On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> > > For future handling: If we are adding tags to the list that will hit
> > > more than a few packages we will send a notice to the d-d
On Tue, Jul 07, 2009 at 02:53:52PM -0700, Steve Langasek wrote:
> IOW, you can't actually point to an issue *that affects you* with the
> current version of the package, or you wouldn't have had to quote the
> upstream changelog at me. Do you even use the software? What test
over the package without my consent. That tells me that you have
bad manners, but it doesn't give me a reason to reprioritize
libdbd-sybase-perl in my todo list.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on,
ven't looked at the code.
This is the second time in recent weeks that I've seen such a case of
britney mis-reporting a package in unstable as RC buggy. I think there's a
regression here in the bug lists that bugs.debian.org is feeding to britney.
--
Steve Langasek
am. Please, do
> not discuss the merit of this approach, as it is _their_ IT mgmt
> problem to solve.) How release team verify distro consistency?
No. Why would Debian be providing regression tests for software we don't
ship?
> Could you point an url with the correct answers to th
On Thu, Aug 21, 2008 at 11:13:38PM +0200, Holger Levsen wrote:
> On Friday 15 August 2008 05:16, Steve Langasek wrote:
> > > (you might want to check the video when it will be available)
> > From experience, there seems to be a several-month delay before videos
> > become
transitional basis; it would be a shame if we have so many
more packages failing to depend on ucf/debconf/adduser now that we have to
treat them as non-RC yet again.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to se
On Thu, Aug 14, 2008 at 11:35:39PM -0400, Filipus Klutiero wrote:
> Le August 14, 2008 11:08:10 pm Steve Langasek, vous avez écrit :
> > On Thu, Aug 14, 2008 at 11:01:46PM -0400, Filipus Klutiero wrote:
> > > Tagging lenny and sid does not imply that other suites are free
arently really agreed with the proposal.
Hrm, ok... well, I still disagree, but I seem to be overruled :)
> (you might want to check the video when it will be available)
>From experience, there seems to be a several-month delay before videos
become available after DebConf.
--
Steve L
bug is found in suite x, but "This bug should not be
> archived until it is fixed in suite x."
Not unless there's been a regression since the last time I talked to Don
about this.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
represented in this BoF? I'm surprised
that this would be considered release-critical per se; I really don't see
the justification for excluding packages without known bugs from a stable
release just because they don't have a maintainer, when in fact there are
many packages /with/
l, "etch-ignore" implies that the bug has been given a pass by the
release team for that release. I think you rather want to tag the bug
"lenny+sid" to indicate the bug is not present in etch.
But I'm glad to see this done - it's a pity that my dear etc
There is no bug in it and it seems up-to-date.
But why would we want to take up archive space for a library that nothing
uses? Removal seems reasonable to me.
Thanks Frank, for doing this review!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ral/63627
Given that you've expressed interest in gnus, I think you would be the ideal
person to investigate this bug and discuss with the security team what the
correct severity of this bug should be. In general, the severity
definitions at <http://www.debian.org/Bugs/Developer#severitie
olor
> or put a title attribute over it to mark it's no more supported.
I think it's fair to leave oldstable listed on p.q.d.o until such time as
oldstable is dropped from the archive. I guess mirror disk space is not a
pressing issue right now, since this hasn't ha
:
Package: ssh-askpass-gnome
Depends: [...] openssh-client | ssh (>= 1:1.2pre7-4) | ssh-krb5
So this could be dropped, but doesn't prevent removal of the transitional
package.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
to me filling a removal request?
Removing this seems like a good idea to me.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp:/
ut the reasons why we should consider removing the
package, but am not sure whether I personally think those reasons outweigh
a userbase of that size - usually the installed userbase of non-lib packages
that get nominated for removal is much smaller. :)
--
Steve Langasek
been no new security fixes since then only
because people have stopped caring about this code. (The state of the art
for security exploits has advanced sufficiently over time that even the best
of code written in 1997 stands a middling chance of being vulnerable in one
or more ways that the author h
> somewhere if anyone else is interested.
Preferably in the BTS, so that we have a documentation trail for any
regressions that might be introduced by the patch, as well as a suitable
counter on which to base NMUing of this package if the maintainer doesn't
act.
Thanks,
--
Steve Langasek
have both wxWidgets and Qt builds of
such an application as this anyway, but if someone really wants it, there
you are.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubun
ce if this can be accomplished for
> lenny.
And one of the reverse-deps of gtk+1.2 is wxwindows2.4, which takes up
about 5x as much archive space as gtk+1.2 itself does. In light of the
thread on -devel, perhaps you'd care to take the lead on eliminating the
reverse-dependencie
> would cause.
It makes it harder later for folks to figure out the package should be
orphaned because the *other* comaintainers have gone MIA.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to
rid of very old
> gtk at some point is one of them.
> zsh3.0 -- A shell with lots of features
> - has zsh to replace it
> - only 38 popcon installations
> - last maintainer upload 2005-11-04
I don't see this package anywhere in the archive?
--
Steve Langasek
ng list. However, I would like to repeat that I was not at
> all satisfied with the response from the bug owner.
I'm sorry, but the kernel package in particular is one that requires the
maintainers to be able to triage a large number of bugs very quickly,
including reports about issues
duhr be removed from unstable?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE,
On Tue, May 29, 2007 at 01:13:25PM +0800, Uwe Dippel wrote:
> Steve Langasek wrote:
> >Anyway, this is a bug in a specific package. The QA team isn't
> >responsible
> >for finding all bugs in individual packages; ask the maintainer of the lpr
> >package why
to test etch before the release made it
happen. I'm sorry if that means there are use cases of concern to you that
weren't addressed by this process, but the only way to be totally certain
a release will meet your particular needs is to participate in testing it
beforehand.
--
Steve Lang
rent aptitude, this is not the case. There is a specific aptitude
rule to exclude linux-image packages from "auto" handling.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it o
I can continue to do this.
> Keep me in Uploaders if that don't bother you.
Well, if this happens and someone works on getting the package building,
then of course I have no problem with the package and am happy to provide
any additional alpha porting support that might be required.
Cheers,
--
y someone who apparently
wasn't a DD), but if the package isn't actually being maintained I'd rather
not fix these bugs just to clear the way for an unmaintained package to
enter testing.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develo
On Tue, Apr 24, 2007 at 05:34:20PM +0100, Regis Boudin wrote:
> On Tue, April 24, 2007 15:42, Steve Langasek wrote:
> >> I have results I will put online as soon as I convert them in a better
> >> format than a simple text list, but if you have comments on what to do
> >
which is the right virtual package to depend on
when using libapt. The same applies to build-deps on virtual packages,
which normally are provided by only one real package at a time in a given
suite.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Devel
On Thu, Apr 12, 2007 at 09:40:08AM +0200, Thijs Kinkhorst wrote:
> On Thu, 2007-04-12 at 08:12 +0200, Steve Langasek wrote:
> > Just like all the other 10-year-old packages that have 7-year-old bugs? If
> > the package doesn't have any RC problems, why should it be orphaned ju
t
because there are some older bugs? If anything, this looks to me like a
veiled attempt to remove the package from the archive, disguised as an
orphaning, since I don't imagine there are a great number of people
clamouring to adopt it afterwards.
--
Steve Langasek
enough to let it reflow the text on its own.
The full intended changelog entry was:
* Rebuild to fix a bug of indeterminate origin that causes screen to switch
from pipes to sockets; addresses bug #413674.
--
Steve Langasek Give me a lever long enough and a Free OS
Debia
hese problems
all at the end of the release cycle.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNS
deluser/delgroup commands are
*not* from passwd, they're from adduser, which is prio: important and thus
subject to removal, just like update-inetd and ucf are.
So those four classes of bugs are potentially RC for etch, though we may
ultimately decide to etch-ignore unfixed ones if they would
on can make it into etch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROT
s haven't been
> recompiled
> or uploaded in a *long* time.
> I'd like to ask -release to schedule these for binNMUs. If they don't
> build then FTBFS bugs should be filed, obviously.
BinNMUs scheduled for all binary packages in the archive that depend on
li
ions against filing removal bugs?
I don't object either way, for me they're not worth using due to their
non-free status. Life's too short. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
ix that the slirp package does have prior claim to
the name. I think this just needs to be resolved by slang-slirp changing
its binary name the same way as the package name.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
udes packages which declare conflicts. It
doesn't exclude packages that use diversions. Perhaps a whitelist of these
diversions would be useful?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on,
he mail sent to you by the ftp
masters in response to an upload of a package with an override mismatch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
s support 32 Bit UID/GID's?
Debian supports them just fine. Who says it doesn't?
> If the system does not reclaim the UID's in less then 4 weeks I would
> run into trouble since the CURRENT configurations do not have enough.
What does that have to do with what packa
ing dependencies as etch-ignorable;
and a missing dependency on ucf definitely wouldn't be ignorable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
ovides an inferior experience for users.
Every time the discussion has come up so far, there's been an absence of
consensus about whether it was correct to attempt to reclaim user ids on
purge.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develope
e than a personal
> preference.
In the case of adduser, there is a strong case for not doing deluser at
*all* on purge, because it's impossible to ensure that there are no off-line
or remote resources referencing the uid/gid.
--
Steve Langasek Give me a lever long eno
t simply is not a useful indicator of
whether the package I'm installing has RC bugs.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www
On Fri, Sep 15, 2006 at 10:33:24AM -0300, Gustavo Franco wrote:
> Steve Langasek wrote:
> > On Thu, Sep 14, 2006 at 01:55:59PM -0400, Nathanael Nerode wrote:
> >> I'm not up to doing this myself at the moment, but it should be done.
> >> So could someone on debia
On Thu, Sep 14, 2006 at 02:04:35PM -0400, Nathanael Nerode wrote:
> Please could someone QA-upload libglade to stop producing
> libglade-bonobo0 and the corresponding -dev package.
Done.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
maintainer of libgtk-perl has consented
to drop the package.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
T
shouldn't it by my name there?
IMHO yes, but I don't sponsor NMUs -- I consider the bug here to be in the
contents of the changelog, not in how qa.d.o shows it afterwards. ;)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to
On Mon, Aug 07, 2006 at 08:57:14PM +0200, Lionel Elie Mamane wrote:
> On Thu, Aug 03, 2006 at 03:20:32PM -0700, Steve Langasek wrote:
> > On Thu, Aug 03, 2006 at 11:37:17AM +0200, Lionel Elie Mamane wrote:
> >> http://qa.debian.org/developer.php?login=lmamane&comaint=ye
this.
> Similarly, I have not QA-uploaded svn-arch-mirror, but sponsored a QA
> upload by Eric Wong.
I'm not sure I have an opinion on this one way or another.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Fri, Apr 21, 2006 at 04:12:49PM +0200, Andreas Barth wrote:
> gsnes9x
This one is really only held out by a dependency (that, and some binaries on
mips/m68k which never should have been uploaded); I don't think it makes
sense to remove gsnes9x unless we should also remove snes9x-x.
-
ng.
The rekall package is also involved in this transition, but currently fails
to build on all 64-bit architectures, so needs to be fixed for that issue
before the mysql transition can complete.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian D
nk they should be marked RC at this point, but I think uploads
(including NMUs) should be encouraged.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
ke a look at
> these packages anyway.
I believe that icheck is a valuable tool that should be kept in Debian, but
I haven't had the time to adopt it. Maybe Lars should adopt it as part of
his 20-year plan to familiarize himself with ELF libraries. :)
--
Steve Langasek
interest, regardless of skill
level!
Beyond that, of course, Debian is a very self-organizing group, so you're
welcome to work on whatever you think is most appropriate -- the help is
definitely welcome, but you probably aren't going to find anybody here to
tell you what you *should
hink that the multiarch-style directories are the right way
forward, but it doesn't make sense to require uclibc to conform to them
before any other packages are doing so. As such, I agree with the idea of
granting uclibc an exception here *if* multiarch doesn't happen for etch;
but in the
None of these bugs are higher than severity: important. Is "buggy" really a
factor in removing this package?
FWIW, I don't object to the removal request itself; I've actually deployed
dcl, but having it in package form would have been useless to me.
Cheers,
--
Steve Langasek
m deserve a simple rebuild; there are only 57, so it's
> probably worth just doing it (listed by source package, mostly):
I've started working through these, FWIW; that's why your list starts at 'e'
instead of 'a'. :) I'm only doing a few at a time, so I c
e
very public resignation of a single developer from a single role are
uninteresting and irrelevant.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PRO
roblems. I
> think other people are doing the same with unstable.
Matt Kraai and Daniel Schepler do rebuilds of unstable, I believe.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL
n as 1 days
> old tomorrow?).
It's been running, but not completing. Yesterday it completed when run by
hand, but the results weren't committed because LCA interfered. Today it
should complete on its own and be committed normally.
--
Steve Langasek Give me a lever
Gnome 1.X, we
> should remove libgnome-gnorba-perl. No rdepends, no users, rc-buggy
> (xlibs-dev transition), no maintainer.
Yes, let's!
Hurray!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
ilt it and, should it pass my testing, will upload.
> I took the liberty to document in the changelog that no changes were
> necessary for updating the standards version. Please do so yourself on
> future upgrades.
Sorry, I've already uploaded this...
--
Steve Langasek
*\(/\*.*\*/\)*$,,; \
s,^[[:space:]]*#include[[:space:]]*<,/usr/X11R6/include/,' | sort -u \
| xargs dpkg -S | cut -f1 -d: | sort -u
And almost all libxt-dev matches are caused by old autoconf macros, FWIW;
nobody uses Xt by choice. :-P
--
Steve Langasek Give
.
> o The script to determine which libraries were needed missed a
> couple: ICE and SM.
The script looks for included headers. If headers from libice-dev and
libsm-dev aren't being included anywhere in the source, I suspect this
build-dependency exists only because the
'd be happy to sponsor for you (as, I imagine, would
Thomas).
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.
ns for using an older autoconf that aren't transitory are bad
reasons. :) autoconf2.13 is ancient, unsupported, and won't stay around
forever, within Debian or otherwise. And it has bugs. Like this one. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Fr
to rerun autoconf or build-dep: libxt-dev
> > wmblob-1.0.3
> maintainer decision to rerun autoconf or build-dep: libxt-dev
> Fails to find libXpm even when build-dep on libxpm-dev
> > xscorch-0.2.0
> maintainer decision to rerun autoconf or build-dep: libxt-dev, libxpm-dev
There&
pt should have found the X11 library, but it looks like
> it didn't.
Explanation for this problem is here:
http://lists.gnu.org/archive/html/bug-autoconf/2005-09/msg00023.html
Simple fix is to re-run autoconf on the package, to pick up a new definition
of the AC_PATH_X macro.
Alternat
> dependency problem.
Are you talking about this page?:
http://qa.debian.org/debcheck.php?dist=unstable&package=nip2
This is the only reference to uninstallability that I see, and it only
applies to m68k, which is true...
--
Steve Langasek Give me a lever long enough and a F
in unstable already conflicts with krb4, which is a
source of fresh RC bugs on it. The only remaining issue is for cyrus-sasl2
to rebuild without krb4, then it can be dropped, IIRC.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to
easier to contribute, you're much better off
arguing it in terms of the *benefits to the project* (and mitigation of the
risks) than in terms of how it makes a set of possible contributors feel.
And this...
> I run Ubuntu .. I can't even test my own Debian package
> on my own system.
from unstable along with its one
reverse-dependency, libpng-dylan.
Copious X-Debbugs-Cc: set; closing one RC bug, commenting the other for the
maintainer's benefit, and notifying QA and MIA.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
o a samba misbuild. It
should be fixed as soon as samba gets binNMUed (autobuilder binNMUs are
currently down for maintenance).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL
on this mail the address of the
relevant bug in the BTS?
Apparently, no bug has been filed yet against glademm asking for the GNOME 1
dependencies to be dropped. Would you please file this bug, given that
you're asking for NMUs to fix it?
--
Steve Langasek Give me a l
g pointless or
> not though...
Based on the number of RC bugs and the chronic lack of interest shown
in the package, I think removal is the best option. I meant to reassign
321328 to ftp.debian.org at some point, but hadn't gotten to it yet.
--
Steve Langasek Give me a l
could sponsor the upload. You can get
> > the source package from:
> > deb-src http://archives.eyrie.org/debian unstable main
> > or via the corresponding direct paths.
> I've now corrected the PID file handling for non-root users as well,
> fixing the attack pointed
are probably very few processes that a stray SIGUSR1 can
do damage to on a typical system, but if it's worth protecting root
from, it's probably worth protecting users from as well. In any case,
this is not the bug that 276789 is primarily concerned with.
--
Steve Langasek
Package: ftp.debian.org
On Fri, Aug 26, 2005 at 06:32:31PM +0200, Thomas Viehmann wrote:
> please remove phpgroupware-napster. It isn't useful, upstream dropped it
> a long time ago, and it's dead debian-wise as well.
Added missing pseudo-header.
--
Steve Langasek
On Sat, Aug 20, 2005 at 06:10:36PM +1000, Hamish Moffatt wrote:
> On Sat, Aug 20, 2005 at 09:27:24AM +0200, Andreas Barth wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) [050819 23:39]:
> > > On Fri, Aug 19, 2005 at 05:44:30PM +0200, Andreas Barth wrote:
> > > > * Ha
ich
the bug was closed; if the package was removed without the bug ever
having been fixed, closing with a version number doesn't make any sense
here.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer t
immediately, and (if no one picks it up, as I expect will happen) removed
from the archive shortly thereafter.
Cheers,
--
Steve Langasek
postmodern programmer
- Forwarded message from Aurelien Jarno <[EMAIL PROTECTED]> -
X-Original-To: [EMAIL PROTECTED]
Old-Return-Path: <[EMAIL PROT
On Sat, Jul 30, 2005 at 08:00:29PM +0200, Andreas Tille wrote:
> On Sat, 30 Jul 2005, Steve Langasek wrote:
> >I think that if such a change is made to the Uploaders: field of a package
> >without the maintainer's approval, this means that instead of just
> >hijack
e package, you've hijacked the package and then *lied* about it. It isn't
comaintenance unless the parties explicitly agree to it.
If you meant that Nelson would only be added to the Uploaders: field with
Matthew's approval, then I guess I don't know why the QA team's in
1 - 100 of 125 matches
Mail list logo
