Bug#1106735: [ps] segmentation fault with options -lam

tag -1 bookworm done -1 2:4.0.4-1 This is a duplicate of #1036631 fixed in procps 4.0.4-1 Trixie is about to be released, so when that happens you'll move to 4.0.4-8 - Craig On Thu, 29 May 2025 at 05:03, void wrote: > The exact output I got is: > $ ps -lam > F S UID PIDPPID C PRI

Bug#1092550: procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/

reassign -1 procps thankyou On Thu, 29 May 2025 at 06:33, Ben Hutchings wrote: > I think system administrators looking to experiment with sysctl changes > are more likely to reaach for procps and the sysctl command, because: > > - sysctl is on the path while systemd-sysctl isn't > - "apt search

Bug#1092550: procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/

On Mon, 26 May 2025 at 02:05, Ben Hutchings wrote: > linux-sysctl-defaults is meant to provide defaults only. Therefore I > don't think it is appropriate to add that example/template to it. > > What is the problem with keeping an example in procps? > I can do that, but on a standard Debian syste

Bug#1069087: marked as pending in net-snmp

On Tue, 6 May 2025 at 19:07, Craig Small wrote: > I think I can get that going. > Actually, I was looking in my experimental branch (where the next version is). The main branch has everything I need. - Craig

Bug#1069087: marked as pending in net-snmp

On Tue, 6 May 2025 at 17:24, IOhannes m zmoelnig wrote: > given that trixie is going to ship linux-6.12, I wonder whether you have > intentions to upload this a fixed-version in time (after all we are in > soft-freeze right now, and hard-freeze will start in 9 days...so given > that prolonged tra

Bug#1068904: Processed: found 1068904 in 4.0.4-8

On Tue, 15 Apr 2025 at 17:15, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Processing commands for cont...@bugs.debian.org: > > > found 1068904 4.0.4-8 > Bug #1068904 [procps] w: crashes because of the systemd support > Hi, Can you give more details? Some sort of backtrace? The o

Bug#408879: Bug is still present! Re: Bug#408879 closed by Craig (ps process start times)

On Tue, 15 Apr 2025 at 19:48, Paul Szabo wrote: > > psz@azaona:~$ date --rfc-3339=ns; ps -ouser,lstart,command | grep -E > 'psz.*grep|USER' > 2025-04-15 19:38:41.589754682+10:00 > USER STARTED COMMAND > psz Tue Apr 15 19:38:40 2025 grep -E psz.*grep|USER > > Surely worth

Bug#1100138: Re: Bug#1100138: Resignation & call for votes to elect the Chair

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2025-03-11 at 17:12, matt...@debian.org wrote: > === BEGIN > > A: Christoph Berg > B: Helmut Grohne > C: Matthew Garrett > D: Stefano Rivera > E: Timo Röhling > F: Craig Small > G: Paul Tagliamonte > H: Matt

Bug#1099834: tech-ctte: Call for votes on TC membership of Paul Tagliamonte

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2025-03-08 at 17:48, matt...@debian.org wrote: > ===BEGIN > The Technical Committee recommends that Paul Tagliamonte (paultag) be appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Paul Tagliamonte (pau

Bug#810018: New Essential package procps-base

On Mon, 3 Mar 2025 at 23:28, Emilio Pozuelo Monfort wrote: > I don't think this is a change that should be done this close to the > freeze. > Please stage this change in experimental if you wish, but let's postpone > it > until forky. > > btw, the transition suggested by Helmut on [1] sounds reas

Bug#1091995: Call for votes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A > B > C > N Base-files is the right place for this directory but if there needs to be some sort of fix, then I prefer B over C. - Craig -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.5.7 Comment: Seamlessly send and receive

Bug#810018: New Essential package procps-base

I've now got a git branch on salsa showing the required changes and to see how it went getting built. https://salsa.debian.org/debian/procps/-/tree/new-pidof - Craig

Bug#810018: New Essential package procps-base

rwarded message ----- From: Craig Small Date: Tue, 25 Feb 2025 at 20:24 Subject: Re: Bug#810018: New Essential package procps-base To: Luca Boccassi Cc: <810...@bugs.debian.org> On Thu, 20 Feb 2025 at 21:07, Luca Boccassi wrote: > On Thu, 20 Feb 2025 at 09:26, Craig Small wrote: &

Bug#810018: New Essential package procps-base

On Thu, 20 Feb 2025 at 21:07, Luca Boccassi wrote: > On Thu, 20 Feb 2025 at 09:26, Craig Small wrote: > - src:procps with a new procps-pidof binary package that > breaks/replaces current sysvinit-utils and with prio: essential > - drop pidof and prio:essential from sysvinit-u

Bug#1091864: tech-ctte: Avahi vs systemd-resolved vote concluded

I did vote. On the 17th February, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091864#151 FWIW S was first for me too. - Craig On Mon, 24 Feb 2025 at 09:33, Helmut Grohne wrote: > Hi, > > thanks all for voting. > > csmall: n/a > helmutg: S > A > F > matthew: S > F > A > mjg59: S > A >

Bug#810018: New Essential package procps-base

Hi Luca, The issue is getting from where we are to where we want to be without breaking everything. In other words, it interim steps along the way. Admittedly I haven't thought *too* much about it, but pidof (either one) needs to be installed all the time, without dragging in all of procps. Ther

Bug#880868: wordpress: CVE-2012-6707

On Tue, 18 Feb 2025 at 06:09, Salvatore Bonaccorso wrote: > > Looks this got fixed in > https://core.trac.wordpress.org/changeset/59828 > A 2012 CVE :) It's not in 6.7.2, let's hope it makes the next release. - Craig

Bug#1091864: tech-ctte: Avahi and systemd-resolved cannot a run mDNS responder at the same time

> (S) The CTTE reaffirms that avahi-daemon is the default mDNS > implementation in Debian trixie. Therefore systemd-resolved should > disable the mDNS functionality in its default installation in Debian > trixie. > (Requires a 3:1 majority overruling a developer.) > > (A) The CTTE

Bug#1085130: still not fixed in procps 2:4.0.4-7

On Mon, 27 Jan 2025 at 09:27, Vincent Lefevre wrote: > With 2:4.0.4-7, it is still listed, but now appears as > > Conffiles: > /etc/sysctl.conf newconffile remove-on-upgrade > It's not very clear from the documentation, but that looks correct. The fact that "dpkg -s procps", for example, shows t

Bug#1092550: procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/

reassign -1 linux-sysctl-defaults thankyou The procps package doesn't carry any of the sysctl configuration files anymore, but they're in the linux-sysctl-defaults so reassigning to that package. linux-base folk, if you need the last version of sysctl.conf the commit to remove it was at https://s

Bug#1089468: wordpress: Supporting rootless builds by default

On Sat, 4 Jan 2025, 10:27 pm Niels Thykier, wrote: > > In the mean time, the transition has moved to the endgame with the bug > now becoming RC (a regular FTBFS in sid). I can offer to do a NMU of > wordpress/6.6.1+dfsg1-1 with a minimal patch to fix the bug (1-line > `Rules-Requires-Root: binary

Bug#1089468: wordpress: Supporting rootless builds by default

GPG > exited with status code 0) > > gpg: Signature made Tue Dec 10 05:15:58 2024 UTC > > gpg:using RSA key > 5D3DF0F538B327C0AA7A77A2022166C0FF3C84E3 > > gpg: Good signature from "Craig Small " [expired] > > gpg: aka "Craig

Bug#1089468: wordpress: Supporting rootless builds by default

On Tue, 31 Dec 2024 at 05:54, Niels Thykier wrote: > > Fix in git (commit 823dbdac1cf5be00b44c8faa726c6dc2d651ed5a). It should > be part of the upload tagged debian/6.7.1+dfsg1-1 in git, but that > version does not appear in the archive. > 6.7.1 got uploaded, I have the .upload file locally. I'm

Bug#1088934: w: "idle time" information is incorrect

On Tue, 3 Dec 2024 at 21:21, Vincent Lefevre wrote: > This particular one could be a bug in the kernel. But the access time > (or modification time) is correct here with /dev/pts/* devices, though > They're handled differently so if the tty kernel code could still be the issue. Also one user sess

Bug#1088934: w: "idle time" information is incorrect

On Tue, 3 Dec 2024 at 19:21, Vincent Lefevre wrote: > Package: procps > The "idle time" information output by "w" (in the IDLE column) is > incorrect. It is a common, arbitrary value for all entries, which > does not seem to be related to any idle time. It can be something > like "2days" or "7day

Bug#1080333: procps: w(1) man page: obsolete contents about /var/run/utmp

On Mon, 2 Sept 2024 at 21:57, Vincent Lefevre wrote: > As of systemd 256.5-2, utmp support is disabled (/var/run/utmp > no longer exists), while w is still working. So it seems that > /var/run/utmp is no longer used. > For that particular default way of installation. I've added a note that its on

Bug#1088203: linux-sysctl-defaults: apply setting after installation

On Mon, 25 Nov 2024 at 10:27, Ben Hutchings wrote: > I've opened > to add the necessary file trigger to procps. > Thanks for that Ben, its now merged. - Craig

Bug#1085160: linux-sysctl-defaults: apply setting after installation

On Thu, 31 Oct 2024 at 05:56, Ben Hutchings wrote: > On Thu, 2024-10-24 at 21:09 +1100, Craig Small wrote: > > I'm not seeing that. There are three triggers in systemd 256.6-1 but not > > for sysctl files. > > Wouldn't it be in > > > https://salsa.debia

Bug#1086341: logcheck-database: systemd rules - Consumed CPU time change

Package: logcheck-database Version: 1.4.3 Severity: normal The logcheck rule for system CPU time misses the new memory peak part. Current line in ignore.d.server/systemd: # possibly https://sources.debian.org/src/systemd/252.4-1/src/core/unit.c/#L2307 (line 2474 converts the "consumed"->"Consum

Bug#1077187: procps: please drop/replace the obsolete sysctl.conf(5) man page

On Sat, 27 Jul 2024 at 00:12, Vincent Lefevre wrote: > On 2024-07-26 15:27:25 +0200, Vincent Lefevre wrote: > > The sysctl.conf(5) man page is still there and yields confusion. > > > >sysctl.conf - sysctl preload/configuration file > > [...] > >/etc/sysctl.conf > procps sysctl sti

Bug#1085160: linux-sysctl-defaults: apply setting after installation

On Thu, 24 Oct 2024 at 11:25, Ben Hutchings wrote: > > 1. As discussed in the GitLab MR, systemd implements a file trigger on >sysctl configuration files. I'm not seeing that. There are three triggers in systemd 256.6-1 but not for sysctl files. Wouldn't it be in https://salsa.debian.org/sys

Bug#1076352: procps: leftover conffiles

On Tue, 22 Oct 2024 at 09:33, of1 wrote: > Just a note to point out that /etc/sysctl.conf is still referenced in > the sysctl manual. Is the file still a valid and usable conf file? > Yes, for procps sysctl. - Craig

Bug#1077187: procps: please drop/replace the obsolete sysctl.conf(5) man page

On Thu, 24 Oct 2024 at 19:43, Craig Small wrote: > There should be a note in sysctl.conf stating this is for procps sysctl, > I'll add that. > https://gitlab.com/procps-ng/procps/-/commit/ec590d5145668ea1868e1787c272d329ce5feba1

Bug#1085130: procps: /etc/sysctl.conf is still listed as a conffile

On Tue, 15 Oct 2024 at 13:03, Vincent Lefevre wrote: > /etc/sysctl.conf is still listed as a conffile, and this can break > other tools. > It seems remove-on-upgrade in the conffiles didn't do what I wanted. I've added a rm_conffile to the mainscript which seems to have removed it. - Craig

Bug#1072533: procps: flaky autopkgtest:

On Thu, 26 Sept 2024 at 03:48, Paul Gevers wrote: > Hi, > > On 25-09-2024 12:05, Craig Small wrote: > > grep -E '^([[:space:]]+[[:digit:]]+){18}$' "${stdoutF}" >/dev/null > > I thought the problem was that the result didn't start with > ^[

Bug#1072533: procps: flaky autopkgtest:

On Tue, 24 Sept 2024 at 04:57, Paul Gevers wrote: > It took quite some manual iterations, but it failed in the end. > > root@elbrus:/tmp/autopkgtest-lxc.lyg9_rfi/downtmp/build.aKs/src# grep -E > '^(Buffers|Cached|SReclaimable):' /proc/meminfo ; vmstat > Buffers: 0 kB > Cached:

Bug#1072533: procps: flaky autopkgtest:

On Sat, 20 Jul 2024 at 17:24, Paul Gevers wrote: > I can give you access to a testbed on our infrastructure where you can > play in a production environment exactly like the tests run. We'd need > to align the date/time, as in the current way that I can provide this > service, I need to be on-lin

Bug#1081801: ps.1: Some remarks and editorial changes for this man page

Hi, I have added most of these changes to the upstream ps.1 Some of them have already been changed in other patches. - Craig On Sun, 15 Sept 2024 at 10:09, Bjarni Ingi Gislason wrote: > Package: procps > Version: 2:4.0.4-5 > Severity: minor > Tags: patch > >* What led up to the situatio

Bug#1077818: snmp-mibs-downloader: Consider adding RFC-1212, RFC-1215 and IANA-ENTITY-MIB

On Sat, 3 Aug 2024 at 04:18, Matthijs Kooijman wrote: > Package: snmp-mibs-downloader > Version: 1.6 > Severity: wishlist > > Hi, > > I've been using snmp-mibs-downloader for getting MIB files for my > netgear switch, but I'm running into problems because RFC-1212, RFC-1215 > and IANA-ENTITY-MIB

Bug#1077764: Call for votes: don't issue any ruling

> = > BEGIN BALLOT > > The Technical Committee declines to overrule the maintainer of > base-files, or issue any advice on issues concerning /etc/os-release. > > We do not think there is a clear proposal on the table for us to assess, > and we do not think it is appropriate to issue any general

Bug#1076745: logcheck-database: cron rules

Package: logcheck-database Version: 1.4.3 Severity: normal Hi, I'm getting logcheck entries like: Jul 23 06:02:01 myhost CRON[566969]: pam_unix(cron:session): session opened for user logcheck(uid=124) by logcheck(uid=0) The relevant mis-matching line is in paranoid.d/cron: ^(\w{3} [ :0-9]{1

Bug#729569: [watch] -g only reacts to visible output

tags -1 fixed-upstream We use the ncurses library to store the displayed characters and use that library to determine what has changed. It only holds the visible parts, so changes outside the ncurses window are not stored and cannot be compared. I've added a note to the watch manpage which all we

Bug#1076510: procps: "vm.max_map_count = 65530" : Value too small for gaming

reassign -1 linux-sysctl-defaults On Thu, 18 Jul 2024 at 00:33, Davius wrote: >I was playing on Steam and experiment Crashes in some games. > >Increasing vm.max_map_count to 1048576 solve this issue creating a file in > /etc/sysctl.d to change the value. >This increased value is now

Bug#1072533: procps: flaky autopkgtest:

On Tue, 4 Jun 2024 at 05:57, Paul Gevers wrote: > I looked at the results of the autopkgtest of your package, because it > showed up in the glibc regressions. I noticed that it regularly fails on > amd64, ppc64el and s390x. For your info, as it seems to correlate, those > are the architectures whe

Bug#1061944: wrong description for --unit in vmstat(1)

tags -1 fixed-upstream On Tue, 30 Jan 2024 at 22:30, Wenbin Lv wrote: > The description for --unit in vmstat(1) writes, "this does not change the > swap (si/so) or block (bi/bo) fields". This is inconsistent with the text in > section "FIELD DESCRIPTION FOR VM MODE", and "vmstat -S M" does chan

Bug#1076352: procps: leftover conffiles

On Tue, 16 Jul 2024 at 10:20, Chris Hofstaedtler wrote: > I'd suggest to add the following to your package; dpkg should then > clean up the conffile automatically. Please test it, however. > >echo 'remove-on-upgrade /etc/sysctl.conf' >> debian/procps.conffiles Oh, I've not seen that method be

Bug#1072831: getting memory info fails when running under lxc

On Sun, 9 Jun 2024 at 01:03, Paul Slootman wrote: > I am running a number of virtual systems under lxc via libvirt. > This means these systems share the host kernel (not like qemu where a > whole virtual machine is emulated). Hi Paul, I did the following (as root) lxc-create --name debtest2 --t

Bug#1074156: procps: Depend or Recommend linux-sysctl-defaults

On Mon, 24 Jun 2024 at 05:57, Ben Hutchings wrote: > Please consider dropping /usr/lib/sysctl.d/99-protect-links.conf and > adding linux-sysctl-defaults to Depends or Recommends instead, once > that package is available in testing. Hi Ben, This sounds like a great idea, config stuff for systemd-

Bug#1072831: getting memory info fails when running under lxc

Control: tags -1 fixed-upstream On Tue, 11 Jun 2024 at 21:16, Paul Slootman wrote: > I see I missed the case lseek() fails with another errno. > Updated patch attached. Thanks Paul, This was applied upstream at https://gitlab.com/procps-ng/procps/-/commit/104b3ce3df67092eeb868ba5e019cb895ebdf32

Bug#1072831: getting memory info fails when running under lxc

On Sun, 9 Jun 2024 at 01:03, Paul Slootman wrote: > # free > free: Unable to create meminfo structure That's procps_meminfo_new() failing but /proc/meminfo exists. The function: checks the parameters allocates some memory for the structure runs meminfo_make_hash_failed(), which sets up the h

Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm

On Tue, 11 Jun 2024 at 00:15, Chad William Seys wrote: > > Hmm, was there a cleanup or migration script which failed to run? > > On 6/8/24 09:30, Paul Slootman wrote: > > On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: > > > >> After upgrading to bookworm there is an unowned /usr/bin/ps on the

Bug#1072533: procps: flaky autopkgtest:

On Tue, 4 Jun 2024 at 05:57, Paul Gevers wrote: > I looked at the results of the autopkgtest of your package, because it > showed up in the glibc regressions. I noticed that it regularly fails on > amd64, ppc64el and s390x. For your info, as it seems to correlate, those > are the architectures whe

Bug#1068632: dh-exec still broken

On Mon, 20 May 2024 at 02:03, Kip Warner wrote: > I would like to keep this bug report open still. > I have reopened it. > I can confirm that it does not work. dh_missing does not report any > warnings anymore, but the resulting package does not contain anything > that I specified in my .instal

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On Wed, 8 May 2024 at 09:03, Jun MO wrote: > 1) I hope there will still be the original > w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1) > tools which can still read *old* format utmp/wtmp/lastlog in Debian at > least for > a while after switch to Y2038-safe replacements. Those tools can read > I c

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

gt; > > > On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > > > >> The vote has concluded. The result is that the Technical Committee > >> recommends that Craig Small be appointed by the Debian Project > >> Leader to the Technical Committee. > &g

Bug#1069828: [debian trixie] [package procps] w segmentation fault

Control: forwarded -1 https://gitlab.com/procps-ng/procps/-/issues/301 Control: tags -1 fixed-upstream On Thu, 25 Apr 2024 at 22:36, David wrote: > Hello, it seems there is a bug in the debian package "procps" with the > "w"utility. > it produce a segfault when using the "-s" argument. > I tried

Bug#1069091: wordpress: Stored XSS in Avatar block

Package: wordpress Version: 6.5+dfsg1-1 Severity: important Tags: security X-Debbugs-Cc: Debian Security Team In WordPress < 6.5.2 there is a stored XSS in the Avatar block. You have to have certain things enabled for it to work so it won't impact everyone. References: https://wpscan.com/blog/

Bug#1068632: dh-exec-install - dh_missing fails when using arch or indep

Package: dh-exec Version: 0.29 Severity: normal In a multi-binary package, if there is a dh-exec-install .install or .manpages file for one of the packages, then these files are not carried across and logged for dh_install so dh_missing fails if you use the other type of build. For example, on t

Bug#1059997: razercfg: pyrazer modules installed in incorrect location

Package: razercfg Version: 0.42+ds-4 Followup-For: Bug #1059997 Hi, You have double "dist-packages" in the install path. $ python3 Python 3.11.8 (main, Feb 7 2024, 21:52:08) [GCC 13.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from pyrazer import * Tr

Bug#1066090: psmisc: killall --older-than doesn't work as documented in a container

Control: tag 1066090 fixed-upstream On Wed, 13 Mar 2024 at 00:30, Tim Connors wrote: > I'm guessing it's looking at field 22 starttime in /proc/$pid/stat? > starttime is seconds since boot. Since the process exists in the > parent system as well, starttime will surely be seconds since host > bo

Bug#1064968: marked as done (net-snmp: CVE-2024-26464)

> > As per https://www.cve.org/CVERecord?id=CVE-2024-26464 the CVE has > been rejected now. > > Reason: This candidate was withdrawn by its CNA. Further investigation > showed that it was not a security issue. > I did wonder myself how it could be a security issue. Wonder if it is one of those auto

Bug#1064219: net-snmp: NMU diff for 64-bit time_t transition

Hi Steve, Looks like you missed one: dh_installdocs -plibsnmp-perl -ptkmib -plibsnmp-base -plibsnmp40 dh_installdocs: error: Requested unknown package libsnmp40 via -p/--package, expected one of: snmpd snmptrapd snmp libsnmp-base libsnmp40t64 libnetsnmptrapd40t64 libsnmp-dev libsnmp-perl tkmib d

Bug#1063444: psmisc: FTBFS due to unexpected failures running tests

On Thu, 8 Feb 2024 at 21:06, Emanuele Rocca wrote: > FAIL: fuser no args, no proc > FAIL: fuser -a no proc > FAIL: fuser -v, no proc > FAIL: fuser -av, no proc > FAIL: fuser -va, no proc > Are these systems running systemd? If you can get on those hosts, what does fuser `mktemp` show?

Bug#827171: [uptime] show container uptime

On Mon, 13 Jun 2016 at 20:09, Daniel Baumann < daniel.baum...@progress-technologies.com> wrote: > when using 'uptime' in containers (regardless what kind of containers), > it shows the uptime of the host system rather than the one of the > container. > > What we used locally here is to look at /de

Bug#1059649: NTP does not keep accurate time on bookworm

On Fri, 2 Feb 2024 at 08:54, Rob Janssen wrote: > I am using systemd. > Where are you seeing this error? The systemd socket is the thing that opens up the socket, so shouldn't matter what the snmptrapd process is running as. When I reboot, I get this: $ sudo ss -unlp | grep 162 UNCONN 0 0

Bug#1059649: NTP does not keep accurate time on bookworm

On Sat, 30 Dec 2023 at 06:15, Rob Janssen wrote: > After the upgrade, the snmptrapd service no longer starts. > The error message is: couldn't open udp:162 -- errno 13 ("Permission > denied") > Could you tell me how you start snmptrapd? There are two ways: The default systemd way. The socket is c

Bug#1062250: Please add ucd-snmp/lmSensors MIB module to monitor lm_sensors data

> On a system reporting temperatures via "sensors", trying to enumerate the > corresponding OIDs via: > snmpwalk -v 2c -c public localhost LM-SENSORS-MIB::lmSensors > yields no result. > $ snmpwalk -v 2c -c public 127.0.0.1 LM-SENSORS-MIB::lmSensors | grep ': temp[0-9]' LM-SENSORS-MIB::lmTempSens

Bug#1059817: #1059817 fixed in experimental

Hi Chris, It got uploaded to unstable tonight. - Craig On Sat, 27 Jan 2024 at 07:30, Chris Hofstaedtler wrote: > Hi, > > please upload the fix for #1059817 also to unstable. > > Thanks, > Chris >

Bug#1060359: psmisc: install fuser into /usr (DEP17)

On Wed, 10 Jan 2024 at 09:42, Chris Hofstaedtler wrote: > Please find a patch attached to install fuser into /usr, for the > currently ongoing UsrMerge effort [1]. > It has been build-tested and checked by dumat. > Hi Chris, Thanks for the patch. I have reviewed it and uploaded a new version of

Bug#810018: New Essential package procps-base

On Wed, 15 Nov 2023 at 23:03, Guillem Jover wrote: > I'm all in for shrinking the essential-set. If there is consensus to > switch pidof implementations that also seems fine to me in the abstract. > But this shuffling around of essential-ness and new tiny packages and > stuff seems a bit unnecess

Bug#810018: New Essential package procps-base

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.

Bug#810018: Bug #810018: Consider shipping pidof with procps

On Tue, 14 Nov 2023 at 06:09, Mark Hindley wrote: > IIUC, the proposal[1] was to create a new Essential procps-base just > containing > pidof. Otherwise bin:procps would have to become Essential itself. Its > installed > size is about 20 times larger than sysvinit-util and that wouldn't > contrib

Bug#810018: Bug #810018: Consider shipping pidof with procps

On Sat, 11 Nov 2023 at 23:45, Luca Boccassi wrote: > Now that Bookworm has shipped, what about finally finishing this and > getting rid of this debianism? There is really no reason to delay it > any longer at this point. Thank you! > Hi Luca, I'll need the assistance of the sysvinit-utils maint

Bug#1055126: procps: pgrep and pidwait are identical. one should by a symlink to the other

On Wed, 1 Nov 2023 at 08:15, Ani Hay wrote: > Instead of wasting all this space one should be a symlink to the other. > 39 kilobytes is not exactly a lot.

Bug#1053706: procps: [w] no "from" data and segfault with parameter -s

tags 1053706 fixed-upstream thankyou On Mon, 9 Oct 2023 at 22:09, Pierpaolo Toniolo wrote: > I was trying to read the DISPLAY value from the output of 'w' command but > with > version 2:4.0.4-2 there is no value in the "FROM" column. > It's not really giving anything useful printing :0 Also wit

Bug#831786: dh-exec: breaks dh_install --fail-missing

On Sat, 23 Sept 2023 at 08:09, Michael Biebl wrote: > Is there some work being done to support this in dh-exec? > Is there a way I can work around this issue for now? > The short answer is, that no work has been done on that issue. The main use-case I have seen for dh-exec was for the multiarch d

Bug#1052034: procps: FTBFS on amd64, i386: # of unexpected failures 1

Looks like another "guess what strange thing the buildd is doing this time" problem. The failing test is (effectively) pmap -XX $pid $pid | grep KB And make sure the first numbers of each row are the same. Because it is the same process, it should be the same. There is the same test for pmap -X an

Bug#1049457: fuser(1) not working on libraries, possibly because of disagreement over minor device

t way. - Craig On Tue, 22 Aug 2023 at 12:07, Paul Kimoto wrote: > On Wed, Aug 16, 2023 at 11:03:14PM -0400, Paul Kimoto wrote: > > On Wed, Aug 16, 2023 at 05:25:26PM +1000, Craig Small wrote: > >> What does > >> grep -e ' 0:2[57] ' /proc/self/mountinfo

Bug#1030747: Acknowledgement (fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't)

On Tue, 21 Feb 2023 at 10:51, Andras Korn wrote: > The changelog for 23.6 says "fuser: Use modern statn where possible", but > it's regrettably also used where not possible. > The next release of psmisc will have that fallback, see https://gitlab.com/psmisc/psmisc/-/commit/c22d1e4edbfec6e24346cd8

Bug#1049457: fuser(1) not working on libraries, possibly because of disagreement over minor device

Hi Paul, On Wed, 16 Aug 2023 at 12:45, Paul Kimoto wrote: > I believe that fuser(1) should work on libraries, but on this system > it doesn't: > I don't think it is the libraries, the issue is the device IDs are different. > $ stat -L /usr/lib/x86_64-linux-gnu/libc.so.6 > > File: /usr/lib/x8

Bug#1042887: procps: CVE-2023-4016 ps buffer overflow External

tags -1 fixed-upstream The probable fix is at https://gitlab.com/procps-ng/procps/-/commit/2c933ecba3bb1d3041a5a7a53a7b4078a6003413 The issue is the -C command allocates memory using malloc(length of arg * size of struct). In odd situations, you could have a very large arg, the multiplication ove

Bug#1042887: procps: CVE-2023-4016 ps buffer overflow

Package: procps Version: 2:4.0.3-1 Severity: important Tags: security X-Debbugs-Cc: Debian Security Team We have a very scant report of a ps buffer overflow security bug. Under some circumstances, this weakness allows a user who has access to run the “ps” utility on a machine, the ability to wr

Bug#1037450: procps: [pgrep] [regression]: >15 characters warning when long regex doesn't match

Hi, I'm thinking of adding a quick and dirty check for a regex. A very quick set of characters to say "this is a regex" and suppress the warning. The first idea is just look for a '[' or a '|'. I think that covers most simple conditions. I'm not looking for some sort odd corner cases, just the ma

Bug#1034203: snmp: specifying -Op /at all/ segfaults all snmpcmd(1) commands

On Tue, 11 Apr 2023 at 11:48, наб wrote: > This happens in all these configurations: > $ snmptranslate -Op .1 > Segmentation fault > $ snmptranslate -Op > Segmentation fault > $ snmpget -Op > Segmentation fault > Hi наб, Thanks for the report. I have passed this to upstream at http

Bug#1032139: snmp: snmpbulkwalk.1 mentions snmpbulkget instead of snmpbulkwalk

forwarded 1032139 https://github.com/net-snmp/net-snmp/issues/537 thankyou On Wed, 1 Mar 2023 at 01:36, наб wrote: > > I couldn't for the life of me find where I'd post this, so I trust you > understand upstream's link jungle and can forward this in my stead. > Forwarded to https://github.com/ne

Bug#1029069: libc6: wcswidth doesn't report correct width for ：

Package: libc6 Version: 2.36-6 Severity: minor I've been trying to work out why the Chinese translation for free doesn't want to line up the columns like everyone else, report is at [1] For some reason, it thinks the strange colon used in the translation is one character wide, but its actually tw

Bug#1027963: vmstat: does not update memory columns

On Thu, 5 Jan 2023, 19:30 Ingo Saitz, wrote: > running vmstat to produce a continuous output (eg. "vmstat 3") does not > update the values in the memory columns any more. The "main loop" just > does not fetch those values. > Hi Ingo, Thanks very much for the report and the patch. It has been appl

Bug#1025915: skill: -p $pid seems broken

On Thu, 5 Jan 2023 at 18:26, Chris Hofstaedtler wrote: > Right. For the avoidance of doubt, if you think removing it is a > better option, from my PoV, please do so. It would be nice, but we're sort-of locked in for the "user API". I would rationalise the ps command line parsing first. If you're

Bug#1027771: its nocompatible

For some reason the issue is not vim-ale its something broken in the generic vim infrastructure. debian.vim sets nocompatible which is supposed to stop the issue but it doesn't running vim -N or putting "set nocompatible" in ~/.vimrc fixes it

Bug#1024020: net-snmp: CVE-2022-44792 CVE-2022-44793

On Fri, 30 Dec 2022 at 18:33, Salvatore Bonaccorso wrote: > Upstream has addressed both issues with > https://github.com/net-snmp/net-snmp/commit/be804106fd0771a7d05236cff36e199af077af57 I've made a debian patch and uploaded 5.9.3+dfsg-2 that has this fix. - Craig

Bug#1027270: guymager doesn't require libprocps

On Sat, 31 Dec 2022 at 22:21, Michael Prokop wrote: > I just uploaded guymager v0.8.13-2 which takes care of this. Great, that's another one down. Thanks for the quick response. - Craig

Bug#1027271: open-vm-tools doesn't need libprocps

Hi I checked the source code, build logs and current binaries, open-vm-tools doesn't use libprocps or link to it. A simple removal of libprocps-dev from debian/control will fix this. - Craig

Bug#1027270: guymager doesn't require libprocps

Hi, I checked the build logs, the source code and even the current binary packages. guymager does not need libprocps. A simple removal of libprocps-dev from debian/control is all that is needed. - Craig

Bug#1022573: transition: procps

On Thu, 29 Dec 2022 at 05:04, Paul Gevers wrote: > With procps migrated to testing, dose [1] is reporting two more packages > that weren't on our radar: open-vm-tools and guymager. Can you have a > Both these packages do not use any symbols from the old library and their binary packages do not de

Bug#1022573: transition: procps

OK, open-vm-tools doesn't even use the library so that's an easy fix. On Sat, 31 Dec 2022 at 15:50, Craig Small wrote: > On Thu, 29 Dec 2022 at 05:04, Paul Gevers wrote: > >> With procps migrated to testing, dose [1] is reporting two more packages >> that weren&#

Bug#1022573: transition: procps

On Thu, 29 Dec 2022 at 05:04, Paul Gevers wrote: > With procps migrated to testing, dose [1] is reporting two more packages > that weren't on our radar: open-vm-tools and guymager. Can you have a > look and help the maintainer with migrating to the new version of > procps? open-vm-tools has a new

Bug#1022573: transition: procps

On Thu, 22 Dec 2022 at 19:50, Paul Gevers wrote: > That's (in general) sub-optimal for the release team. We try hard to > avoid entangling transitions and therefor we try to finish transitions > sooner rather than later. My preference would be that you NMU (minimal > changes) now; the maintainer

Bug#1022573: procps transition status at Dec 22

#1024218 - apitrace - patch available #1024219 - cpu-x - patch available at upstream git #1024220 - deepin-screen-recorder - nil #1024221 - intel-gpu-tools - patch available upstream, version issues #1024223 - obs-advanced-scene-switcher - Done! #1024224 - openscap - Done! #1024225 - veyon - nil I

Bug#1022573: transition: procps

(added the bug report for igt) On Thu, 22 Dec 2022 at 08:29, Craig Small wrote: > On Thu, 22 Dec 2022 at 07:46, Paul Gevers wrote: > >> An actual upload. If the maintainer isn't doing it, I think an NMU is >> appropriate if you're sure of the fix. >> > Ah,

Bug#1022573: transition: procps

On Thu, 22 Dec 2022 at 07:46, Paul Gevers wrote: > An actual upload. If the maintainer isn't doing it, I think an NMU is > appropriate if you're sure of the fix. > Ah, I thought you were the igt maintainer :) I'll have a go recreating it and uploading it tonight. I'm pretty confident about the p

  1   2   3   4   5   6   7   8   9   10   >