On Nov 20, Craig Small wrote:
> Also why is killall5 not a candidate too?
Probably because it makes no sense outside of sysvinit, except that as
a footgun.
(Also, is it equivalent to pkill --inverse?)
--
ciao,
Marco
signature.asc
Description: PGP signature
stuff seems a bit unnecessary to me, more so when this increases the
> bootstrapping-set. I'd also rather see instead a _proper_ transition to
> get sysvinit-utils out of the essential-set, and then at some later
> point procps can take over pidof.
>
There really is two options then:
Hi!
On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote:
> What:
> Create a new package procps-base. This uses the existing procps source
> package and just enable building of pidof. procps-base will be an Essential
> package and only contain pidof.
>
> Why:
> This
On 14/11/23 11:11, Helmut Grohne wrote:
I welcome the effort in general. Like Andreas, I question whether having
pidof remain essential is useful. A quick codesearch
https://codesearch.debian.net/search?q=%5Cbpidof%5Cb&literal=0 suggests
that we have less than 500 source packages that even mentio
ciple and if you do not want to take on the
> non-essential part, I fear I see little alternatives to that procps-base
> proposal.
Yeah, let's not make this task impossibly huge and lengthy, please.
Using the same implementation as every other distro has immediate
benefits for everybo
Hi Craig,
On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote:
> Hello,
> For quite some time (since 2006!) there has been a discussion at[1] about
> changing from the sysvinit-utils version of pidof to the procps one. A
> quick scan of the various distributions shows that
Hi,
On 11/14/23 18:42, Andreas Henriksson wrote:
Instead I think pidof can just be part of procps package. The
sysvinit-utils package will then pull in procps via a dependency (once
sysvinit-utils stops being Essential), which would smooth the transition
for all sysvinit users until LSB
Hello,
On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote:
> Hello,
> For quite some time (since 2006!) there has been a discussion at[1] about
> changing from the sysvinit-utils version of pidof to the procps one. A
> quick scan of the various distributions shows that onl
Hello,
For quite some time (since 2006!) there has been a discussion at[1] about
changing from the sysvinit-utils version of pidof to the procps one. A
quick scan of the various distributions shows that only Debian and Ubuntu
(and I assume most other downstreams) use the sysvinit-utils version
Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari"
* Package name : golang-procps
Version : 0+git20150225.6c34ef8
Upstream Author : The Prometheus Authors
* URL : https://github.com/prometheus/procfs/
* License : Apache-2.0
Programmin
On Mon, Feb 24, 2014 at 09:27:08PM -0500, Stephen Powell wrote:
> and extracted with dpkg-source. In other words, on my machine at least,
> I did not get a FTBFS error.
It looks like its something strange on that particular pbuilder.
The problem is that barriere is even stranger and the programs w
On Mon, 24 Feb 2014 15:16:23 -0500 (EST), Cyril Brulebois wrote:
>
> #739874 should have been called a failure to build from source (FTBFS),
> and could have linked to [1], but anyhow.
>
> 1. https://buildd.debian.org/status/package.php?p=procps&suite=sid
I apologize, Mr.
On Tue, Feb 25, 2014 at 12:06:56AM +0300, Cyril Brulebois wrote:
> No, I wasn't sure what Craig was not sure about, that's why I tried to
> connect the dots with the usual FTBFS bug reports developers might be
> (more?) familiar with.
You guessed right, I understood what you meant and got a way for
Jakub Wilk (2014-02-24):
> I just hope you didn't mean to say that only perfect bug reports are
> welcome these days, and those merely good are somehow frowned upon.
No, I wasn't sure what Craig was not sure about, that's why I tried to
connect the dots with the usual FTBFS bug reports developers
* Cyril Brulebois , 2014-02-24, 23:16:
I got a bug report stating that there is no i386 build for procps.
First I'm not really sure that's how bug reports work, but anyhow.
#739874 should have been called a failure to build from source (FTBFS),
and could have linked to [1], but a
Craig Small (2014-02-25):
> I got a bug report stating that there is no i386 build for procps.
> First I'm not really sure that's how bug reports work, but anyhow.
#739874 should have been called a failure to build from source (FTBFS),
and could have linked to [1], but an
I got a bug report stating that there is no i386 build for procps.
First I'm not really sure that's how bug reports work, but anyhow.
There doesn't seem to be a publically available i386 Debian machine
that supports building packages. This makes it nearly impossible to
support th
> For the moment they have no plans moving pidof though they don't seem
> terribly fussed either way (that's my read of it anyhow).
> What I have done is used the --disable-pidof flag in procps configure
> step. This means procps does *not* have pidof and it can remain in
&g
ibly fussed either way (that's my read of it anyhow).
What I have done is used the --disable-pidof flag in procps configure
step. This means procps does *not* have pidof and it can remain in
sysvinit-tools for the time being.
If the upstream decides to move it, we'll work out what
On Sun, 2013-12-15 at 11:54 -0800, Steve Langasek wrote:
> On Sun, Dec 15, 2013 at 07:07:54PM +, Ben Hutchings wrote:
> > On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote:
> > > On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek
> > > wrote:
> > > >On Tue, Dec 10, 2013 at 09:02:21AM +,
On Sun, Dec 15, 2013 at 07:07:54PM +, Ben Hutchings wrote:
> On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote:
> > On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek
> > wrote:
> > >On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote:
> > >> Steve Langasek dixit:
> > >> >(For v
On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote:
> On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek
> wrote:
> >On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote:
> >> Steve Langasek dixit:
> >
> >> >(For values of "permanently" that include "we now have two implementations
> >
On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek
wrote:
>On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote:
>> Steve Langasek dixit:
>
>> >(For values of "permanently" that include "we now have two implementations
>> >of sh in Essential, because no one has done the work to let us g
On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote:
> Steve Langasek dixit:
> >(For values of "permanently" that include "we now have two implementations
> >of sh in Essential, because no one has done the work to let us get rid of
> >bash".)
> Maybe because the offered alternative su
Steve Langasek dixit:
>(For values of "permanently" that include "we now have two implementations
>of sh in Essential, because no one has done the work to let us get rid of
>bash".)
Maybe because the offered alternative sucks so much.
I’d happily split mksh into mksh and mksh-static, make
the la
On Mon, Dec 09, 2013 at 10:03:09PM +, Ben Hutchings wrote:
> On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote:
> [...]
> > AIUI, you've also proposed including the following list of binaries in
> > procps-base:
> > > procps-base: pidof, ps, sys
it maintainers. Perhaps the rewrite of pidof is
> something that we want to pick up, but the rationale for including it in the
> procps package doesn't apply to Debian at all.
Right, can someone go and ask the sysvinit-utils or sysvinit-tools
upstream what they are going to do? If they are goi
On Mon, Dec 09, 2013 at 10:03:09PM +, Ben Hutchings wrote:
> Discussed here:
>
> http://thread.gmane.org/gmane.linux.debian.devel.general/185723/focus=185725
That's the "leaving" side, the "arriving" side is.
http://www.freelists.org/post/procps/Adopting-
e-Dep ond
> procps-base, the Pre-Depends<->Breaks relationship makes it impossible for
That makes sense actually.
Install procps-base first, the Replaces lets it replace pidof
Install new sysvinit-utils, it pre-depends on procps-base so pidof
is there.
It's not critical that t
On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote:
[...]
> AIUI, you've also proposed including the following list of binaries in
> procps-base:
>
> > procps-base: pidof, ps, sysctl, pgrep, pkill
>
> Currently, the *only* one of these which is used as part
we simply
> > drop pidof?
> Yes, and the man page too.
> > Will procps-base be guaranteed to be installed via upgrade?
> Now this I am unsure. It will be Essential but do new Essential packages
> automatically get installed?
> > I imagine we'll have to also have a
On Mon, Dec 09, 2013 at 01:56:57PM +1100, Craig Small wrote:
> As pidof is moving from sysvinit-utils to procps-base in the next
> release, I want to check I've got the way dpkg handles flags correctly.
> procps-base will contain the new pidof and will be
> Essential: yes
>
Hello,
2013-12-09 03:55, Ben Hutchings:
> On Mon, 2013-12-09 at 13:56 +1100, Craig Small wrote:
> > As pidof is moving from sysvinit-utils to procps-base in the next
> > release, I want to check I've got the way dpkg handles flags correctly.
> >
> > procps-bas
On Mon, 2013-12-09 at 13:56 +1100, Craig Small wrote:
> As pidof is moving from sysvinit-utils to procps-base in the next
> release, I want to check I've got the way dpkg handles flags correctly.
>
> procps-base will contain the new pidof and will be
> Essential: yes
>
As pidof is moving from sysvinit-utils to procps-base in the next
release, I want to check I've got the way dpkg handles flags correctly.
procps-base will contain the new pidof and will be
Essential: yes
Breaks: sysvinit-utils << 2.88dsf-43
Now, if there is a new Essential packa
On Sat, Oct 12, 2013 at 10:01:33AM +1100, Craig Small wrote:
> my first cut of it would be:
> procps-base: pidof, ps, sysctl, pgrep, pkill
> procps: pwdx, vmstat, tload, free, pmap, skill, slabtop, top, uptime,
> watch, w, snice
>
> procps-base is Essential an
On Sun, Aug 11, 2013 at 11:28:47AM +1000, Craig Small wrote:
> On Fri, Aug 09, 2013 at 01:39:20PM +0200, Ben Hutchings wrote:
> > I also wonder whether it would not be more sensible to split procps into
> > essential and non-essential binary packages. Aside from pidof, I bet
> &
that might go, the results are:
-c: corosync, glusterfs and sheepdog
-n: no packages
-m: not available on Debian pidof
> I also wonder whether it would not be more sensible to split procps into
> essential and non-essential binary packages. Aside from pidof, I bet
> there are
On Fri, Aug 09, 2013 at 03:14:14PM +0200, Ondřej Surý wrote:
>And is there a strong reason why we don't move whole procps into
>essential?A
It used to be there and then it was decided it wasn't essential.
- Craig
--
Craig Small VK2XLZ http://enc.com.au/
On Fri, Aug 09, 2013 at 04:46:26PM +0400, Игорь Пашев wrote:
> Since we are talking about pidof, I'd like to note that pgrep is more
> portable ;-)
They'll actually share some of the same codebase after this change.
pidof is bascially a cut-down pgrep.
- Craig
--
Craig Small VK2XLZ http://enc.
On Fri, Aug 9, 2013 at 1:39 PM, Ben Hutchings wrote:
> On Fri, 2013-08-09 at 21:10 +1000, Craig Small wrote:
> > Besides my Debian duties I am also upstream for procps. I have been in
> > discussion with the sysvinit-tools upstream and they want to find a new
> > home for pi
Since we are talking about pidof, I'd like to note that pgrep is more
portable ;-)
2013/8/9, Craig Small :
> Besides my Debian duties I am also upstream for procps. I have been in
> discussion with the sysvinit-tools upstream and they want to find a new
> home for pidof so it "
On Fri, 2013-08-09 at 14:21 +0200, Bastien ROUCARIES wrote:
>
> Le 9 août 2013 13:39, "Ben Hutchings" a écrit :
> >
> > On Fri, 2013-08-09 at 21:10 +1000, Craig Small wrote:
> > > Besides my Debian duties I am also upstream for procps. I have
> been in
Le 9 août 2013 13:39, "Ben Hutchings" a écrit :
>
> On Fri, 2013-08-09 at 21:10 +1000, Craig Small wrote:
> > Besides my Debian duties I am also upstream for procps. I have been in
> > discussion with the sysvinit-tools upstream and they want to find a new
> >
On Fri, 2013-08-09 at 21:10 +1000, Craig Small wrote:
> Besides my Debian duties I am also upstream for procps. I have been in
> discussion with the sysvinit-tools upstream and they want to find a new
> home for pidof so it "fits" with similiar tools (pidof used to be in
> p
Besides my Debian duties I am also upstream for procps. I have been in
discussion with the sysvinit-tools upstream and they want to find a new
home for pidof so it "fits" with similiar tools (pidof used to be in
procps in the dark ages). This means shortly that pidof will disappear
fro
* Cyril Brulebois [110822 23:51]:
> Michael Prokop (22/08/2011):
> > * Adam D. Barratt [Mon Aug 22, 2011 at 07:11:08PM +0100]:
> > > Looking at the procps source package in unstable, it appears to have the
> > > same issue. If that's the case, then I'm afr
Michael Prokop (22/08/2011):
> * Adam D. Barratt [Mon Aug 22, 2011 at 07:11:08PM +0100]:
> > Looking at the procps source package in unstable, it appears to have the
> > same issue. If that's the case, then I'm afraid your question should
> > really have been &q
this issue in squeeze?
> > > >a) Build a i386 package with broken symlink?
> > > >b) Build whatever-arch package with working symlink?
> > > Stop using basename on what's in /lib, and do that on what's under
> > > debian/tmp.
> > So 1
h broken symlink?
> > >b) Build whatever-arch package with working symlink?
>
> > Stop using basename on what's in /lib, and do that on what's under
> > debian/tmp.
>
> So 1b, thanks.
Looking at the procps source package in unstable, it appears to have the
s
On Mon, Aug 22, 2011 at 12:19:13 +0200, Michael Prokop wrote:
> But that the procps package is non-essential but seems to be installed
> on (some?) buildds is irrelevant?
>
Yes.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &qu
Stop using basename on what's in /lib, and do that on what's under
> debian/tmp.
So 1b, thanks.
> > 2) How can we make sure such a bug doesn't happen again
> >(besides working towards source-only uploads :))?
> >Bugreport against buildd.debian.org?
&g
-s call after the .so is available under proc/, and
profit. That should fix the issue.
d) To confirm the difference between procps installed and missing,
add an “exit 42” at the end of the build target, and notice the
presence of the libproc-….so file when procps is installed.
Michael Prokop (22/08/2011):
> 1) What's the proper way to address this issue in squeeze?
>a) Build a i386 package with broken symlink?
>b) Build whatever-arch package with working symlink?
Stop using basename on what's in /lib, and do that on what's under
debian/tmp.
> 2) How can we ma
Hi,
Christian Hofstaedtler prepared a stable update for procps regarding
#632749 (with ACK from Craig as the procps maintainer and from Adam
from the release team - Cc-ing both of them therefore FYI).
While reviewing the package I noticed an interesting bug, causing
procps in squeeze to have an
retty sure it doesn't muck
around with the environment. I had a look at the bug where I changed it
to a .sh file (Bug #52228 ) but there doesn't appear to be a good
reason for doing it there.
Finally, procps.sh (or procps init script soon possibly) is called
at runlevel S with a 30 prefi
[Craig Small]
> Isn't the whole point of the /etc/init.d/.sh files to setup
> environment variables for subsequent init scripts.
Nope. The point of .sh init.d scripts is to speed up the boot. The
sourcing is not guaranteed when scripts are executed in parallel, so
all scripts should work when e
Hello,
I've been looking at bug #343620 where /etc/init.d/procps.sh should
not exit out. I can see why this could cause problems.
However, while I can see that bug #52228 asks for procps to be sourced,
I can see no good reason for doing so.
Isn't the whole point of the /etc/init.d
On Fri, 2002-04-12 at 00:30, Craig Small wrote:
> Hello,
> I have bug #142292, #109237 and #106414 for procps. The common thing
> is that if System.map file is a multiple of 1024 (or 4096 not sure
> which) ps crashes. Thanks to Dark for getting me that far.
>
> Can someone
Hello,
I have bug #142292, #109237 and #106414 for procps. The common thing
is that if System.map file is a multiple of 1024 (or 4096 not sure
which) ps crashes. Thanks to Dark for getting me that far.
Can someone look at 106414 and Dark's analysis and help me out here?
I'm not sub
On Wed, Oct 06, 1999 at 09:44:46AM +0200, Mirek Kwasniak wrote:
>
> No, news bsdutils package is without kill.
Oh, wee, another portable program bites the dust.
Is the kill in procps linux specific, eg, does it make use of the proc
filesystem? This won't work in the Hurd, so the Hu
Mirek Kwasniak <[EMAIL PROTECTED]> writes:
> On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote:
> > Package: procps
> > Version: 1:2.0.3-3
> >
> > Preparing to replace procps 1:2.0.3-3 (using
> > .../procps_1%3a2.0.3-4_i386.deb) ..
> > .
On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote:
> Package: procps
> Version: 1:2.0.3-3
>
> Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb)
> ..
> .
> Unpacking replacement procps ...
> dpkg: error processing /var/cache/apt/a
Package: procps
Version: 1:2.0.3-3
Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) ..
On Jan 8, [EMAIL PROTECTED] wrote
> > Please file a bugreport against ftp.debian.org so Guy remembers this.
>
> Note that this is probably already covered:
> #4378: Dependencies should be checked automatically
> #9857: ftp 'dinstall' needs to check dependancies
Now you're really scaring me: out o
On Thu, Jan 08, 1998 at 03:13:05PM +0100, Martin Schulze wrote:
> On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote:
> > I mut say I find the policy with respect to split or renamed packages
> > getting stuck in Incoming suboptimal. First e2fsprogsg, now killall.
>
> Please file a bugr
On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote:
> > > Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
> > > include it. "killall" is used in quite a lot of scripts, which are now
> > > starting to break.
> >
> > Yes, it got broken out upstream into a seperate ps
On Jan 8, Scott Ellis wrote
> On Thu, 8 Jan 1998, Bart Schuller wrote:
> > Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
> > include it. "killall" is used in quite a lot of scripts, which are now
> > starting to break.
>
> Yes, it got broken out upstream into a seperate psmis
On Thu, 8 Jan 1998, Bart Schuller wrote:
> BTW,
>
> Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
> include it. "killall" is used in quite a lot of scripts, which are now
> starting to break.
Yes, it got broken out upstream into a seperate psmisc package. Which is
now stuc
[EMAIL PROTECTED] (Ulf Jaenicke-Roessler) writes:
> where should 'ps' reside, according to the standard?
> In the latest version it moved from /bin/ps to /usr/bin/ps.
I noticed this too, and filed a bug. The maintainer says it will return to
/bin in the next release.
Martin.
--
TO UN
BTW,
Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
include it. "killall" is used in quite a lot of scripts, which are now
starting to break.
--
Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the
Lunatech Research http://www.lunatech.com/ f
-BEGIN PGP SIGNED MESSAGE-
On Thu, 8 Jan 1998, Ulf Jaenicke-Roessler wrote:
> where should 'ps' reside, according to the standard?
> In the latest version it moved from /bin/ps to /usr/bin/ps.
According to the maintainer, it will be moved back to /bin.
This is bug #16705. Thanks.
Hi,
where should 'ps' reside, according to the standard?
In the latest version it moved from /bin/ps to /usr/bin/ps.
Thanks,
Ulf
--
#include
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Joey Hess wrote:
> BTW, could you make a procps-dev package with a libproc.a, and libproc's .h
> files in it? I need this for a package I would like to make called
> w.bassman, it's a different version of 'w', that links with libproc, and
> needs whattime.h to buil
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Two options:
> I merge the psmic into procps
> I create a new package called psmisc.
procps is required. pure compatability would argue that
psmisc also be required (or something very close).
--
Raul
--
TO UNSUBSCRIBE FROM TH
Nobody's going to be upset if you create the new package. I think you should
go ahead.
Thanks
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
BTW, could you make a procps-dev package with a libproc.a, and libproc's .h
files in it? I need this for a package I would like to make called
w.bassman, it's a different version of 'w', that links with libproc, and
needs whattime.h to build.
--
see shy jo
--
TO UNSUBSCRI
[EMAIL PROTECTED] wrote:
> will NOT HAVE KILLALL. I think this is probably a Bad Thing.
>
> Two options:
> I merge the psmic into procps
> I create a new package called psmisc.
The second, and make procps recommend or suggest the new psmisc package.
--
see shy jo
--
TO U
[I emailled the talk about procps and colors on debian-private, but on second
thoughts it probably should go here]
Ok, so I have patched procps so it now does colors, and compiles and works.
But, killall is no longer in procps. It is now part of a package called
psmisc. This was done by the
I have written a 'tmem' program, similiar to tload, and would like to
see if there is interest in including it in procps. So.. since Helmut
Geyer seems to have dissappeared (anyone know if he is ok?:-(, I'm
curious who I ought to be sending this to...
Thanks,
-
I lost the reference, but someone said that System.map/psdatabase are
obsoleted by /proc/ksyms in more recent kernels.
I didn't know exactly then, so I checked it at home. This
simply isn't true. ksyms holds a lot less information (only those
symbols as generated by genksyms, not all symbols from
Note that current 1.3.x kernels seem to have everything in /proc/ksyms,
instead of just one page. Using that information, psupdate and System.map
are completely unnecessary.
Jeff
>
> Package: procps
>
> Kernel 1.3.53 seems to have changed the way memory use is reported (I
> think it reports a new value in /proc/meminfo, "cached:", referring to
> cached VM pages) and also has an internal process "kernel bdflush" that
> has a space
Package: procps
Kernel 1.3.53 seems to have changed the way memory use is reported (I
think it reports a new value in /proc/meminfo, "cached:", referring to
cached VM pages) and also has an internal process "kernel bdflush" that
has a space in its name. The result is that &qu
Package: procps
Version: 0.97-4
valour$ w
5:07pm up 15 days, 20:31, 7 users, load average: 0.16, 0.11, 0.09, 3/76
User tty login@ idle JCPU PCPU what
and1000 ttyp0 4:15pm49 24 -bash (bash
Package: procps
Version: 0.97
Package_Revision: 4
The manpage ps(1) tells us:
--- happs 8<--
COMMAND-LINE OPTIONS
Command line arguments may optionally be preceeded by a
'-', but there is no need for i
is too long (not NUL-
terminated) and overwriting other fields in the structure. Not good...
Marek
diff -urN procps-0.97.orig/snap.c procps-0.97/snap.c
--- procps-0.97.orig/snap.c Sun Sep 25 19:46:21 1994
+++ procps-0.97/snap.c Thu Oct 19 21:33:56 1995
@@ -35,7 +35,8 @@
;
*tmp=&#
87 matches
Mail list logo
