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 that
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, 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 and
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 IMHO it's
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 get
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 by
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 is
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 doesn't
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 really
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 upstream
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 doesn't
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.
Add
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 that is to
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 *overly*
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
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
* 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 want
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
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
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
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 a
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
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 priveledge separation
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 OK
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't
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
Hi!
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 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
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
28 matches
Mail list logo
