On Tue, Jul 29, 2003 at 05:02:53PM +0100, Colin Watson wrote:
> Yeah, I know, but let's pretend I mean 'fixed-upstream' or some
> yet-to-be-added tag.
What, you mean like the way the pending tag often seems to get used :) .
> > Besides, that doesn't help the default bug list :) .
> I'm not *ove
On Tue, Jul 29, 2003 at 11:35:01AM +0200, Matthias Urlichs wrote:
> > In my particular case (gforge), I'll have to hack around the
> > no-binary-in-diff limitation of dpkg-source. I work in the same
> > repository as upstream, and some images were changed.
>
> Ugly. The best idea I have about tha
On Tue, Jul 29, 2003 at 04:14:19PM +0100, Mark Brown wrote:
> On Tue, Jul 29, 2003 at 03:05:12PM +0100, Colin Watson wrote:
> > On Tue, Jul 29, 2003 at 02:52:19PM +0100, Mark Brown wrote:
> > > The upstream tag doesn't help with filtering out uninteresting
> > > bugs from the default bug list.
>
>
On Tue, Jul 29, 2003 at 03:05:12PM +0100, Colin Watson wrote:
> On Tue, Jul 29, 2003 at 02:52:19PM +0100, Mark Brown wrote:
> > The upstream tag doesn't help with filtering out uninteresting bugs from
> > the default bug list.
> Add '&exclude=upstream' to the URL?
Not really. The reason it does
On Tue, Jul 29, 2003 at 02:52:19PM +0100, Mark Brown wrote:
> On Tue, Jul 29, 2003 at 02:47:38PM +0200, Matthias Urlichs wrote:
> > Hi, Matt Zimmerman wrote:
> > > Because it is fixed in upstream CVS and I have not merged the patch into
> > > the Debian package,
>
> > If it's fixed in the next ups
On Tue, Jul 29, 2003 at 02:47:38PM +0200, Matthias Urlichs wrote:
> Hi, Matt Zimmerman wrote:
> > or because I have other changes pending which are incomplete.
>
> Personally, I deal with that by cvs-or-whatever-ing a new working
> tree, or (for more complex changes) there's branching.
That reall
On Tue, Jul 29, 2003 at 02:47:38PM +0200, Matthias Urlichs wrote:
> Hi, Matt Zimmerman wrote:
> > Because it is fixed in upstream CVS and I have not merged the patch into
> > the Debian package,
> If it's fixed in the next upstream release I would also set the Upstream
> tag.
The upstream tag do
On Tue, Jul 29, 2003 at 02:47:38PM +0200, Matthias Urlichs wrote:
> Hi, Matt Zimmerman wrote:
>
> > Because it is fixed in upstream CVS and I have not merged the patch into
> > the Debian package,
>
> If it's fixed in the next upstream release I would also set the Upstream
> tag.
The upstream t
Hi, Matt Zimmerman wrote:
> Because it is fixed in upstream CVS and I have not merged the patch into
> the Debian package,
If it's fixed in the next upstream release I would also set the Upstream
tag.
> or because I have other changes pending which are incomplete.
Personally, I deal with that b
On Tue, Jul 29, 2003 at 10:06:54AM +0200, Matthias Urlichs wrote:
> > I have done this as well, as I want these bugs out of my face because the
> > are already fixed. 'pending' is my standard "make it go away because it
> > has already been dealt with" tag.
>
> OK, but IMHO it's a good idea to g
On Tue, Jul 29, 2003 at 10:06:54AM +0200, Matthias Urlichs wrote:
> Hi, Matt Zimmerman wrote:
> > I have done this as well, as I want these bugs out of my face
> > because the are already fixed. 'pending' is my standard "make it go
> > away because it has already been dealt with" tag.
>
> OK, but
Hi, Roland Mas wrote:
> In my particular case (gforge), I'll have to hack around the
> no-binary-in-diff limitation of dpkg-source. I work in the same
> repository as upstream, and some images were changed.
Ugly. The best idea I have about that is to affix a .0.1 to the upstream
version number a
Matthias Urlichs (2003-07-29 10:06:54 +0200) :
> OK, but IMHO it's a good idea to get bugfixes out to the users
> reasonably fast so that they can check if the bug really is
> fixed. To that end, if you really have dealt with the bug, why not
> upload the package?
In my particular case (gforge),
Hi, Matt Zimmerman wrote:
> I have done this as well, as I want these bugs out of my face because the
> are already fixed. 'pending' is my standard "make it go away because it
> has already been dealt with" tag.
OK, but IMHO it's a good idea to get bugfixes out to the users reasonably
fast so th
On Sun, Jul 27, 2003 at 04:44:44PM +0100, Colin Watson wrote:
> On Sun, Jul 27, 2003 at 04:45:33PM +0200, Matthias Urlichs wrote:
> > It's also tagged "pending" since May... Matthew, do you need a
> > co-maintainer for ssh?
>
> Matthew's *got* a co-maintainer for ssh, as a cursory check of the
>
On Sun, Jul 27, 2003 at 07:45:47PM +0100, Colin Watson wrote:
> I admit I wasn't very clear about why I tagged it pending. I think we
> probably need a 'fixed-upstream' tag or similar now that pending is more
> explicitly reserved for "upload will happen soon".
I second that.
Michael
--
"The d
On Sun, Jul 27, 2003 at 08:00:05PM +0200, Matthias Urlichs wrote:
> Hi, Colin Watson wrote:
> > Matthew's *got* a co-maintainer for ssh, as a cursory check of the
> > changelog would have revealed. Hello.
>
> I checked the bug page, which says the maintainer is Matthew.
Unfortunately the BTS isn'
Hi, Colin Watson wrote:
> Matthew's *got* a co-maintainer for ssh, as a cursory check of the
> changelog would have revealed. Hello.
I checked the bug page, which says the maintainer is Matthew.
I'll remember to also check the changelog next time, thanks. (Seriously.)
Anyway, if you think it's O
On Sun, Jul 27, 2003 at 04:45:33PM +0200, Matthias Urlichs wrote:
> Hi, Bernd Eckenfels wrote:
> > On Sun, Jul 27, 2003 at 10:30:07AM +0200, Matthias Urlichs wrote:
> >> Wrong, actually. ssh forks twice before spawning a shell (I don't know
> >> why);
> >
> > I think it is related to the priveledg
On Sun, Jul 27, 2003 at 04:45:33PM +0200, Matthias Urlichs wrote:
> It's also tagged "pending" since May... Matthew, do you need a
> co-maintainer for ssh?
Matthew's *got* a co-maintainer for ssh, as a cursory check of the
changelog would have revealed. Hello.
ISTR that I tagged that bug pending
Hi, Bernd Eckenfels wrote:
> On Sun, Jul 27, 2003 at 10:30:07AM +0200, Matthias Urlichs wrote:
>> Wrong, actually. ssh forks twice before spawning a shell (I don't know
>> why);
>
> I think it is related to the priveledge separation code.
>
Probably. It's still a bug. #164797, actually, which is
On Sun, Jul 27, 2003 at 10:30:07AM +0200, Matthias Urlichs wrote:
> Wrong, actually. ssh forks twice before spawning a shell (I don't know
> why);
I think it is related to the priveledge separation code.
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) [EMAIL PROTECTED],linux.de,d
On Sun, Jul 27, 2003 at 09:47:29AM +0200, Norbert Tretkowski wrote:
> * Dennis Stampfer <[EMAIL PROTECTED]> wrote:
> > I have to log out a user who is logged in via ssh.
>
> ,
> | % apt-cache show slay
Sure, but I can't fix a bug by saying "use slay instead of this
package"... ;)
Dennis
Hi, Dennis Stampfer wrote:
> If he's logged in via telnet, I can do the job by killing that pid. That
> does not work with ssh: For some reason, all what I get out of utmp is
> the pid of the listening sshd which I can't kill if I don't want to
> disable ssh-logins.
Wrong, actually. ssh forks
* Dennis Stampfer <[EMAIL PROTECTED]> wrote:
> I have to log out a user who is logged in via ssh.
,
| % apt-cache show slay
| [...]
| Description: kills all of the user's processes
| Slay provides you with a way to quickly get rid of all
| processes selected user owns. Very useful if you wan
this question really belongs on debian-user, not on debian-devel.
On Sat, Jul 26, 2003 at 07:55:28PM +0200, Dennis Stampfer wrote:
> I have to log out a user who is logged in via ssh. The information that he
> is not allowed to login comes from the utmp-file like the pid to kill.
if he's not
On Saturday 26 July 2003 19:55, Dennis Stampfer wrote:
> I have to log out a user who is logged in via ssh. The information that
> he is not allowed to login comes from the utmp-file like the pid to
> kill.
Not sure if that helps, but 'slay' might be the proper tool for it.
Uli
27 matches
Mail list logo
