Re: 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 can only speak for w. It currently prefers what it gets from systemd or elogind, effectively iterating over the sessions coming from sd_get_sessions() if sd_booted() returns true. If sd_booted() returns false, then it uses the old utmp/utmpx files for now. Besides the Y2038 issue, the utmp "API" is pretty awful with things like errors pretty much undetectable. There is also the problem about who (e.g. which process) should be writing to those files as you have pointed out in your email. For now w/uptime will use utmp as a fallback, but I'll be happy if this gets updated to something better; it's a low-priority for me because systemd/elogind do what I need most of the time. - 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 depend on libprocps. Looks like old dependencies so the removal of libprocps-dev from their build dependency line in control is all that is needed. I can do that, or the respective maintainers can. - Craig
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'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 version in unstable that's now unable to >> migrate. >> > Odd they hadn't noticed it not compiling. I think I have looked at both > these before so I'll see what I can do. > > - 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 > look and help the maintainer with migrating to the new version of > procps? open-vm-tools has a new version in unstable that's now unable to > migrate. > Odd they hadn't noticed it not compiling. I think I have looked at both these before so I'll see what I can do. - Craig
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 can always update the pending changes after > the migration happened. > Sure thing Paul; I have uploaded an NMU which is only the patch that gets it to link to libproc2. I know upstream made some slight changes, with the patch I sent them but it was for things like using exit instead of return for some functions when there was a failure, but most of them used both anyway so it seemed pretty arbitrary. If /proc is unmounted or malloc fails, you're in a world of hurt anyway. Timo, if you need help getting the next version linked to libproc2 I've done both versions so I can help. - Craig
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 have patches for all but some cannot be tested due to the odd way their build systems work.
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, I thought you were the igt maintainer :) > > I'll have a go recreating it and uploading it tonight. I'm pretty > confident about the patches but don't use the package myself. > So the issue is that the changelog has updated the version to 1.26+git20221011-1 but this isn't uploaded or tagged. I can either: Attach my patch for 1024221 to bug #1024221 and wait Update to 20221011 and add the patch, this both links to libproc2 and updates the version Roll-back to 20220524 and add the patch, keeps the binary the same linked to libproc2 but moves the changelog back Ideally, I'd like 20221011 linked to libproc2 but I don't want to release a new version of intel-gpu-tools as I'm not the maintainer and there might be a reason its not being updated. BUT, procps is in transition and this linking needs to happen before the first freeze milestone so I will upload 20220525 linked to libproc2 if we get near to running out of time. - Craig > - Craig > >
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 patches but don't use the package myself. - Craig
Bug#1022573: transition: procps
On Thu, 22 Dec 2022 at 05:54, Paul Gevers wrote: > The issue is that src:intel-gpu-tools is a key packages but currently > unfixed. Having procps migrate to testing now would cause it to be > instantaneously RC buggy, but because it is key, we can't simply remove > it from bookworm. Can you help fix this package in unstable? > I'm surprised there is an issue: * There has been a patch for it for a while now * Upstream have the patch and I believe is either in or still being discussed * I've personally built igt Debian packages with that patch Is there something else you need? This one was one of the easier ones to fix. - Craig
Bug#1022573: transition: procps
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The procps library is now finally changing. Over 20 years ago there was a library to assist with the procps binaries but the API wasn't very good nor not really intentioned for use outside procps. The Bad: This change is a major API change. Basically nothing is like what was before as far as the API is concerned. The library is still about parsing the /proc filesystem but that's about it. All packages will need patching and/or updating. The Good: Upstream/me is able to provide patches as we've done these fixes already. Upstream has an issue tracking the dependent packages at[1] The impacted packages are: * apitrace - Untested patches available * cpu-x - Upstream updated to new (interim API) minor fixes to get it working * deepin-screen-recorder - Embeds old pointers into functions, needs work * intel-gpu-tools - Patches available, upstream working on issue * obs-advanced-scene-switches - Have patches for 4.0.0, minor fix to get them to new API * openscap - Have patches for 4.0.0, minor fix for new API * veyon - No patches but a way forward I can work with the relevant developers to get the API changed. - Craig 1: https://gitlab.com/procps-ng/procps/-/issues/239 Ben file: title = "procps"; is_affected = .depends ~ /libproc2\-0|libproc\-dev|libprocps[0-9]|libprocps\-dev/; is_good = .depends ~ /libproc2\-0|libproc\-dev/; is_bad = .depends ~ /libprocps[0-9]|libprocps\-dev/;
Bug#996192: unblock: net-snmp/5.9.1+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package net-snmp [ Reason ] net-snmp is not moving into bookworm due to a regression with pyagentx. However there is reason to believe this is due to a race condition in pyagentx test script https://salsa.debian.org/python-team/packages/pyagentx/-/merge_requests/2 [ Impact ] net-snmp will stay at 5.9, specifically the AES improvements will not be there and anything else that was added in the last year. [ Tests ] net-snmp passes all its autopkg tests see https://qa.debian.org/excuses.php?package=net-snmp [ Risks ] I see no risk, the issue is pyagentx failing its tests. It's not a linking issue, pyagentx is pure python but uses snmpd to test itself. The problem is that if the agentx starts faster than snmpd the test fails because it cannot connect to the socket. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock net-snmp/5.9.1+dfsg-3
Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1
Thanks for looking after this Raphael! This will stop a lot a bug reports about why does the process not get found. - Craig On Sun, 5 Sep 2021, 01:01 Raphael Hertzog, wrote: > Hello, > > On Sat, 04 Sep 2021, Adam D. Barratt wrote: > > On Mon, 2021-08-16 at 12:02 +0200, Raphael Hertzog wrote: > > > I would like to update "psmisc" in buster to fix a regression in > > > "killall". The bug https://bugs.debian.org/912748 was never fixed in > > > that release and "killall command-longer-than-15-char" is thus not > > > working at all in buster > > > > Please go ahead. > > Thanks, uploaded. > > Cheers, > -- > Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47 > https://www.freexian.com >
Bug#987084: Acknowledgement (unblock: wordpress/5.7.1+dfsg1-1)
Hi, I have just got a bug report for WordPress about a messed up symlink in one of the theme packages #986085. As a result, I'd like to change this unblock from 5.7.1+dfsg1-1 to 5.7.1+dfsg1-2 The singular change between these two is fixing the symlink for wordpress-theme-twentytwentyone - Craig On Sat, 17 Apr 2021 at 21:15, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 987084: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987084. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Release Team > > If you wish to submit further information on this problem, please > send it to 987...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 987084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987084 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#987084: unblock: wordpress/5.7.1+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package wordpress Currently Wordpress in Bullseye is 5.6.1 and is vulnerable to CVE-2021-29450 reported in bug #987065 There are really three options here, either a) Bullseye gets upgraded to 5.6.3 [1]; or b) Bullseye gets 5.6.1 that only has the patch c) WordPress in 5.7.1 in Sid is unblocked and put into Bullseye My preference is to have Bullseye use 5.7.1, i.e. unblock from Sid, hence this email. This will make the inevitable security updates easier during the life of Bullseye and will slow down "why is this version so old" emails I'll get. I was hoping to get 5.7 into Bullseye anyway but missed the freeze. With this security bug, there needs to be an update, it just comes down to which one to do. Patching only the change initially sounds good, but the issue is any subsequent patches (and there will be security bugs in future) become very difficult to do. Upstream may also assume a bug is not a bug due to some previous fix (e.g. a change in 5.6.2 we don't put stops some future security issue. The issue of patching future WordPress 5.6.1+ versions is easy to see by looking at upstreams source repository[2], there are two security updates here. So, 768f1d8 looks like a good contender for a PHP8 related problem which is CVE-2021-29447[3] but where is the fix for CVE-2021-29450 [4]? It's probably buried in c937087 "Grouped merges for 5.6.3" This sort of thing happens all the time, its why for example Buster we track 5.0.x [5] and Buster has 5.0.11 not 5.0.4+something. [ Reason ] To fix security bug CVE-2021-29450 [4] and to ensure that subsequent security issues are properly handled for Bullseye. [ Impact ] Bullseye WordPress users will remain vulnerable OR we have to do some special upload of 5.6.3 OR some patched thing which is almost but not quite anything tested anywhere. [ Tests ] There are two sets of changes here. WordPress 5.7 has been out for about a month with no reported issues, so its been tested on various systems out there including my own. WordPress 5.7.1 is new. Upstream have automated tests, I have run this version on my on systems and not had any issues. [ Risks ] The change from 5.6.1 to 5.7.1 is big, about 20MB of data but that would include things like minimised and unminimised javascript. I'm not sure of the mix of upstream WordPress websites between 5.6.x and 5.7.x but I'd expect most track the latest upstream meaning 5.7.1 would be used *way* more than 5.6.3 Nobody would be using the patched 5.6.1 option before its released. [ Checklist ] [Y] all changes are documented in the d/changelog [Y] I reviewed all changes and I approve them [N] attach debdiff against the package in testing [ Other info ] I can provide the 25M debdiff if required, but I don't think it will be useful. 1: https://wordpress.org/support/wordpress-version/version-5-6-3/ 2: https://github.com/WordPress/WordPress/commits/5.6-branch 3: https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-rv47-pc52-qrhh 4: https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-pmmh-2f36-wvhq 5: https://metadata.ftp-master.debian.org/changelogs//main/w/wordpress/wordpress_5.0.11+dfsg1-0+deb10u1_changelog unblock wordpress/5.7.1+dfsg1-1 -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAmB6ILMSHGNzbWFsbEBk ZWJpYW4ub3JnAAoJEAIhZsD/PITji3cQAIkBX6K8JxFd2ZF4hTcX24vcZw8ByoDO x2Iq8NIF7T2UPc2kAOLZYlROC2TgvTwTNw32eJ/HZ1lmjCmzuZT43fWJUk1dMXqu Ef6kbu5qBivvTUTtY+DzNRDtVC3VvAWob6DKj4fzlM0ZaGNFxIYQXAU9DgwHi0KC 53HUx7XttTdb9NJonRKJ1bOf05Q+dwwZWZFLzE7lnXmq/TqofrPCl/wZ2irUsISt vLp2QUZCAZiSrn/Gg4ZjRvgIPGtqSWFKmGFnwhk1RKTYYQuhptyVOa1O90zDpABP WLmLpK8u+bCwVpogvEJ9NRIH39oHd5N75d3nBXs52SCfNmRbDoSFMJ1IRUp7E8iu 63JVYNuV2NuVOIRprfX/mW+I+9Dvg+wabggV2VVnUOwqY+bIpdD0ir4VfrACAua2 I+W0o9QetX8Gwm3WVTzszg3h6PJCwlDWvnVuJWwevr91PO9Pv17waDY64Qxhq2fy gl+g2eL5yHdfEqS+rPQmBNvLrkQAl9DOj67yI3JKE5v+gY4BLOVI9RDWZ0R3x0Or VVYDmKiiSov2PvC4eAiKQqxskqdix4beN9KEc0w+gP/CbPqGdHJo87jEPc5GhLov vcSmTHkLdsDQSipmEWxQ3OBgyeUfepYhKsAGCBT86gQuf5uYeeBCdbAacWQsrt3d qxKYzq4kIora =GwCm -END PGP SIGNATURE-
Bug#986443: unblock: procps/2:3.3.17-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please unblock package procps
[ Reason ]
This version only adds a breaks and replaces against
manpages-fr-extra. In other words, only changes to the
control file.
[ Impact ]
#986276 - Depending on where the user is upgrading from
you may get an error updating procps with overwriten files.
[ Tests ]
I installed the package and it worked fine.
[ Risks ]
It's a 2 line change to the control file. Trivial change.
[ Checklist ]
[Y] all changes are documented in the d/changelog
[Y] I reviewed all changes and I approve them
[Y] attach debdiff against the package in testing
[ Other info ]
Nil
unblock procps/2:3.3.17-5
-BEGIN PGP SIGNATURE-
iQJGBAEBCgAwFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAmBsDL4SHGNzbWFsbEBk
ZWJpYW4ub3JnAAoJEAIhZsD/PITja98P/AyNWJRnSyWQCknTk2ot7WvDIE/IvIB6
YhRbzcz6/bBT9CNe8UM+V9l7et0KtlPhV68ZRsz1t5OLNU6YuZ9K+4BIV885gFXu
xWzkQwuwq6QKeG0Uub3+jTbnkBFuGgDK3NqHgUDKoSLRNEmU5LaHME+nCebn6RTh
5VPf67fzMAJRn4o49j3Zh4n1M3Jr+G1i6lRqGXQOaJgw3JnBiIwyUM2/zdbu+W9Q
5Agc4fIkaGysf5BNdomGZic7mGPiOetPXS+O6eoKuAfG38qasm54c0e4c0/RqDNN
RDd+x+he6+b9paPitJaWKQ8h+Zc9P+lndWkNv/0zPBc0o9upoNDUVMdmwvYRF8nq
bRf1xT70GRvvOZ/LXoNWHLjIBwQH533MwCo3bHleLiLPZpQBmmVnmyTVmezQ3MHJ
n+76eKL3ttJPVkDQwHJcsOivJh6sHGQUvrW0br9xX2Wn2K2oE3LVHmvGoftdUJyy
VrL5BArOEqkSw6XM+5zYnJZ5aEAR+uVExq4e5laUhbNoERIiw0v7pGT6F0EG5tdP
c65oPWpyi9k/lol6+kpHn5Vd3V/b5SXdtlvxooP2buIjqfUj668eXG+wdoWZ+WFV
QuI2gjZBLso0fJBE/5VI7+s0ZokLCot8Sq7LwrYtUUdd2bVuAkBYZQfH6egUvcdL
Kn9ikm1fo322
=4UIz
-END PGP SIGNATURE-
diff -Nru procps-3.3.17/debian/changelog procps-3.3.17/debian/changelog
--- procps-3.3.17/debian/changelog 2021-02-15 20:50:26.0 +1100
+++ procps-3.3.17/debian/changelog 2021-04-06 17:17:53.0 +1000
@@ -1,3 +1,9 @@
+procps (2:3.3.17-5) unstable; urgency=medium
+
+ * Add break/replace for conflicting manpages-fr-extra Closes: #986276
+
+ -- Craig Small Tue, 06 Apr 2021 17:17:53 +1000
+
procps (2:3.3.17-4) unstable; urgency=medium
* Remove w alternative in postinst Closes: #982803
diff -Nru procps-3.3.17/debian/control procps-3.3.17/debian/control
--- procps-3.3.17/debian/control2021-02-15 20:50:26.0 +1100
+++ procps-3.3.17/debian/control2021-04-06 17:17:53.0 +1000
@@ -20,8 +20,10 @@
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 3.0-10),
init-system-helpers (>= 1.29~)
Breaks: guymager (<= 0.5.9-1), open-vm-tools (<= 2011.12.20-562307-1 ),
-manpages-de (<< 4.9.1-2), manpages-fr (<< 4.9.1-2), manpages-pl (<<
1:4.9.1-2)
-Replaces: manpages-de (<< 4.9.1-2), manpages-fr (<< 4.9.1-2), manpages-pl (<<
1:4.9.1-2)
+manpages-de (<< 4.9.1-2), manpages-fr (<< 4.9.1-2), manpages-pl (<<
1:4.9.1-2),
+manpages-fr-extra (<< 20151231+nmu1)
+Replaces: manpages-de (<< 4.9.1-2), manpages-fr (<< 4.9.1-2), manpages-pl (<<
1:4.9.1-2),
+ manpages-fr-extra (<< 20151231+nmu1)
Provides: watch
Recommends: psmisc
Description: /proc file system utilities
Bug#972149: buster-pu: package net-snmp/5.7.3+dfsg-5+deb10u1
I missed this. I'm uploading now although with the freeze it might not matter anyway. - Craig On Thu, 24 Dec 2020 at 16:52, Salvatore Bonaccorso wrote: > Hi Craig, > > On Sun, Nov 22, 2020 at 07:09:29PM +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Tue, 2020-10-13 at 21:30 +1100, Craig Small wrote: > > > The security release in deb10u1 made EXTEND-MIB read-only > > > to close a security hole (CVE-2020-15862/Bug #9651166) > > > However this meant the cacheTime and execType could not be > > > changed which caused problems with some SNMP managers or setups. > > > > > > [ Impact ] > > > The cachetime and execType cannot be set anywhere as these > > > parameters appear in net-snmp 5.8 which is in sid but not > > > buster. > > > > +net-snmp (5.7.3+dfsg-5+deb10u2) buster-security; urgency=high > > > > The distribution wants to simply be "buster" for a stable upload. > > > > + * snmpd: Add cacheTime and execType flags to EXTEND-MIB. > > +Previous security release made EXTEND-MIB read-only which meant > > +it was not possible to set the timeout of the cache. This patch > > +allows administrator to set the value in the snmpd.conf file. > > > > s/administrator// (or "the administrator", I guess). > > > > Bearing the above in mind, please go ahead. > > Did you saw this ack from Adam to upload it for buster-pu? > > Regards, > Salvatore >
Bug#972149: buster-pu: package net-snmp/5.7.3+dfsg-5+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
[ Reason ]
The security release in deb10u1 made EXTEND-MIB read-only
to close a security hole (CVE-2020-15862/Bug #9651166)
However this meant the cacheTime and execType could not be
changed which caused problems with some SNMP managers or setups.
[ Impact ]
The cachetime and execType cannot be set anywhere as these
parameters appear in net-snmp 5.8 which is in sid but not
buster.
[ Tests ]
Tested with Ubuntu
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1892980
Upstream have the patch and their tests:
https://sourceforge.net/p/net-snmp/patches/1290/
My tests.
Install the candidate snmpd on a Debian10 VM
Configuration file is:
rocommunity public default
extend -cacheTime 10 test /usr/bin/date
Run snmpd using this configuration file
On a different host, run
watch -d snmpwalk -v 1 -c public {test_server_ip}
.1.3.6.1.4.1.8072.1.3.2.3.1.1.4
Notice the date only changes approximately every 10 seconds as the
result is cached.
[ Risks ]
The patch is about 30 additional lines. Most users probably don't
use the "extend" option so won't exercise this or the buggy setup.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Changes ]
Adds two options to the extend command line parameter
[ Other info ]
None
- -- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iQJGBAEBCgAwFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAl+FgaoSHGNzbWFsbEBk
ZWJpYW4ub3JnAAoJEAIhZsD/PITjmX8P/1fCfD2sAxLcc+eC+e5PiIyBVSog2YuI
qytA2SxzXYLXQtOUJeafAM/zqB1qNGvRbTYSPSo9HxRM1L5gUWKIdnENBAoJv4Pd
xnv9Sfsay5Hn+MGecZDkOOybRDK0KrJpPhYg2lO3sZeuilwEKPMnIJ7xoHZD8gDO
V4t+kOFS0AF/EYgAs18NmgemRTjqvCllTiHsrLRLWIdsE7X2N7C44l5Bg5BQAk/V
s/cAuIzZsMxDlMlofLmbWy6yahQiV8UwtG8DTewx4j9seVRUXHgp7i5ibR3yMffS
BbcA4OhBjCe0VHVUcvqSBvEkZY8+v68ifRXQZ9A4M4whQqyICws9MM3Z4HbGxAwc
j67VH9cL6wt9c4vNu+cxW8fts9GeGmOAMJoriqS/+w1rmzlO9Rza2krDcrBLbJQx
5Nc0YYk9TtwRhaeNK2vaIZM8Mj37mq6EbJh9lQ3oP3CR3goWIb9P2n2II/ICvbIY
llQC6fa8V8G/Hv2qOVTqU/qdwCgIeMnjl6nV66Sb64CjkCfa5Adj1z7lXkQvVezt
omCmi+AwdbJLWPxjL8hPoZzSzBTphKcz3D+RxSh6RbIf5wtnm4zD5+eHe1mP21Gs
4QLWjq9RDDSawmH2qWl4EQ4Fba7xJGaw6vkMLiLhAPEPQ+yBjwMdHvd91PdeyMHS
u6+o1BU2BGmq
=gGjJ
-END PGP SIGNATURE-
diff -Nru net-snmp-5.7.3+dfsg/debian/changelog
net-snmp-5.7.3+dfsg/debian/changelog
--- net-snmp-5.7.3+dfsg/debian/changelog2020-07-31 20:53:22.0
+1000
+++ net-snmp-5.7.3+dfsg/debian/changelog2020-09-07 07:16:17.0
+1000
@@ -1,3 +1,13 @@
+net-snmp (5.7.3+dfsg-5+deb10u2) buster-security; urgency=high
+
+ * snmpd: Add cacheTime and execType flags to EXTEND-MIB.
+Previous security release made EXTEND-MIB read-only which meant
+it was not possible to set the timeout of the cache. This patch
+allows administrator to set the value in the snmpd.conf file.
+Closes: #969508
+
+ -- Craig Small Mon, 07 Sep 2020 07:16:17 +1000
+
net-snmp (5.7.3+dfsg-5+deb10u1) buster-security; urgency=high
* snmpd: Make EXTEND-MIB readonly access
diff -Nru net-snmp-5.7.3+dfsg/debian/patches/series
net-snmp-5.7.3+dfsg/debian/patches/series
--- net-snmp-5.7.3+dfsg/debian/patches/series 2020-07-31 20:53:22.0
+1000
+++ net-snmp-5.7.3+dfsg/debian/patches/series 2020-09-07 07:16:17.0
+1000
@@ -44,3 +44,4 @@
snmpd_stop_mib_indexes_files
snmp_snmptrapd_disallow_user_change
+snmpd_cachetime_exectype
diff -Nru net-snmp-5.7.3+dfsg/debian/patches/snmpd_cachetime_exectype
net-snmp-5.7.3+dfsg/debian/patches/snmpd_cachetime_exectype
--- net-snmp-5.7.3+dfsg/debian/patches/snmpd_cachetime_exectype 1970-01-01
10:00:00.0 +1000
+++ net-snmp-5.7.3+dfsg/debian/patches/snmpd_cachetime_exectype 2020-09-07
07:16:17.0 +1000
@@ -0,0 +1,85 @@
+Description: Add a couple of optional flags to the "extend" config
+ directive, enabling non-volatile configuration of a couple of aspects that so
+ far have been configurable only temporarily via SETs:
+ -cacheTime specifies the cache timeout
+Author: Jeff Gehlbach
+Origin: upstream,
https://github.com/net-snmp/net-snmp/commit/d8b12900629ed73a78b27535f08c4f0a721a93be
+Bug-Debian: https://bugs.debian.org/969508
+Applied-Upstream: 5.8
+Reviewed-by: Craig Small
+Last-Update: 2020-09-05
+--- a/agent/mibgroup/agent/extend.c
b/agent/mibgroup/agent/extend.c
+@@ -528,8 +528,27 @@
Re: Accepted net-snmp 5.8+dfsg-1 (source all amd64) into unstable, unstable
Hi Paul, The first two are just how SNMP works, you scan the table and... just fall off it. The last looks like the perl error that has been fixed up. I put some testing on the packages now and the salsa output is all green (I have bypassed the reproducibility tests)[1] This also includes a simple include the perl module test. My reading of this is the "old" -1 is failing (the urls you sent) while the "new" -2 is not (salsa url I sent). Is that how you see it? Odd about the first two. Salsa is ok but other systems are not. - Craig 1: https://salsa.debian.org/debian/net-snmp/pipelines On Mon, 21 Oct. 2019, 5:32 am Paul Gevers, wrote: > Hi Craig, > > On 15-10-2019 07:41, Paul Gevers wrote: > > On 15-10-2019 01:15, Craig Small wrote: > >> I'll have to build a new version of net-snmp including the library to > >> fix at least the perl problem. For that second upload, do you want me > >> to run it through experimental or just upload "normally"? > > > > As the new soname is already in unstable, and there is no new binary > > package (I hope), there is no need to use experimental. Our "need" for > > experimental is to clear the NEW queue and in case of transitions to > > have an automatically generated ben file for the transition tracker, > > such that we can plan transitions. Both of these reasons don't apply > > anymore to new uploads of net-snmp as long as the soname isn't bumped > again. > > > >> With the RC bug, it's not going anywhere fast in its current state. > > > > Ack. > > Any progress with net-snmp? > > Also, I'll like to draw your attention to 3 autopkgtest regressions [1] > which are also blocking migration. Two have seemingly the same error: > [2]: > PACEMAKER-PCS-V1-MIB::pcmkPcsV1 = No more variables left in this MIB > View (It is past the end of the MIB tree) > [3]: > iso.3.6.1.4.1.8072.. = No more variables left in this MIB View > (It is past the end of the MIB tree) > > The third seems to require an update in your reverse (test) dependencies > [4], but I could be wrong: > # Can't load > > '/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/NetSNMP/default_store/default_store.so' > for module NetSNMP::default_store: > > /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/NetSNMP/default_store/default_store.so: > undefined symbol: netsnmp_ds_get_boolean at > /usr/lib/x86_64-linux-gnu/perl/5.30/DynaLoader.pm line 193. > > Paul > > [1] https://qa.debian.org/excuses.php?package=net-snmp > [2] > https://ci.debian.net/data/autopkgtest/testing/amd64/p/pcs/3208873/log.gz > [3] > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyagentx/3208874/log.gz > [4] > > https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsnmp-info-perl/3208872/log.gz > >
Re: Accepted net-snmp 5.8+dfsg-1 (source all amd64) into unstable, unstable
Hi, I'll have to build a new version of net-snmp including the library to fix at least the perl problem. For that second upload, do you want me to run it through experimental or just upload "normally"? With the RC bug, it's not going anywhere fast in its current state. - Craig On Tue, 15 Oct 2019 at 07:24, Paul Gevers wrote: > Hi Craig, > > On 14-10-2019 04:27, Craig Small wrote: > > Hi Paul (and others), > > I think I see the problem, the wiki has two places for transition. > > > > https://wiki.debian.org/TransitionBestPractices which speaks to the > > Whow, not updated since 2014. > > > developer and doesn't mention at all things like going into experimental > and > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions which initially > > Which is linked from https://release.debian.org/transitions/ > > > looks more like what the transition team need to do but has important > > instructions for developers. > > Yes, that page is totally meant for developers. > > > So it seems Debian's documentation strikes again. > > Ack. I'll fix the first wiki page you mentioned. Thanks for bringing > that up. > > > My understanding of experimental was it was used for, well, experimental > > stuff. However, the release teams page uses this as a standard workflow. > > Yes, as has been communicated multiple times. Last that I know of (about > the source-only issue): > https://lists.debian.org/debian-devel-announce/2019/07/msg2.html > > The documentation about how to start transitions is indeed the second > wiki you mention. > > > Regarding the source only uploads, this is the message you get if you > > try that. > > > > Source-only uploads to NEW are not allowed. > > > > binary:libsnmp35 is NEW. > > binary:libsnmp35-dbg is NEW. > > Ack > > > My understanding now is this running through experimental hack will > > "fix" this issue. You upload, I guess the full binary/source into > > experimental, wait, and then it's fine for sid once its updates. > > Indeed. > > > It looks like its going to be stuck in sid anyway, there is a > > perl-related problem that is somehow related to what the Debian > > packaging is doing to the module (it works ok as a plain upstream thing). > > I'm subscribed to the snmp bugs (because of my cacti-spine reverse > dependency), so I saw that. > > Paul > >
Re: Accepted net-snmp 5.8+dfsg-1 (source all amd64) into unstable, unstable
Hi Paul (and others), I think I see the problem, the wiki has two places for transition. https://wiki.debian.org/TransitionBestPractices which speaks to the developer and doesn't mention at all things like going into experimental and https://wiki.debian.org/Teams/ReleaseTeam/Transitions which initially looks more like what the transition team need to do but has important instructions for developers. So it seems Debian's documentation strikes again. My understanding of experimental was it was used for, well, experimental stuff. However, the release teams page uses this as a standard workflow. Regarding the source only uploads, this is the message you get if you try that. Source-only uploads to NEW are not allowed. binary:libsnmp35 is NEW. binary:libsnmp35-dbg is NEW. My understanding now is this running through experimental hack will "fix" this issue. You upload, I guess the full binary/source into experimental, wait, and then it's fine for sid once its updates. It looks like its going to be stuck in sid anyway, there is a perl-related problem that is somehow related to what the Debian packaging is doing to the module (it works ok as a plain upstream thing). - Craig On Mon, 14 Oct 2019 at 07:27, Craig Small wrote: > Hi, > Source only uploads get automatically rejected so someone needs to fix > that then. I originally did upload source only for net-snmp but got the > reject message. > > I never have run a soname change through experimental for any of my > packages before, is this a new thing? > > On Mon, 14 Oct. 2019, 6:49 am Paul Gevers, wrote: > >> Dear Craig, >> >> Next time, can you please start your transition in experimental? >> Everybody is supposed to coordinate transitions with us such that they >> don't interfere with ongoing transitions. I think we're lucky [1], but >> there were others waiting for a transition slot, so this isn't nice to >> them. >> >> You'll also have to upload a source-only upload because we're not >> allowing binary packages that aren't build on a buildd to propagate to >> testing anymore, so please do that ASAP. >> >> Paul >> >> [1] https://release.debian.org/transitions/html/auto-net-snmp.html >> >> > Changes: >> > net-snmp (5.8+dfsg-1) unstable; urgency=medium >> >> [...] >> >> >* Library soname updated to 35 >> >>
Re: Accepted net-snmp 5.8+dfsg-1 (source all amd64) into unstable, unstable
Hi, Source only uploads get automatically rejected so someone needs to fix that then. I originally did upload source only for net-snmp but got the reject message. I never have run a soname change through experimental for any of my packages before, is this a new thing? On Mon, 14 Oct. 2019, 6:49 am Paul Gevers, wrote: > Dear Craig, > > Next time, can you please start your transition in experimental? > Everybody is supposed to coordinate transitions with us such that they > don't interfere with ongoing transitions. I think we're lucky [1], but > there were others waiting for a transition slot, so this isn't nice to > them. > > You'll also have to upload a source-only upload because we're not > allowing binary packages that aren't build on a buildd to propagate to > testing anymore, so please do that ASAP. > > Paul > > [1] https://release.debian.org/transitions/html/auto-net-snmp.html > > > Changes: > > net-snmp (5.8+dfsg-1) unstable; urgency=medium > > [...] > > >* Library soname updated to 35 > >
Bug#925314: unblock: wordpress/5.0.3+dfsg1-1
Hi,
Attached is a debdiff between 5.0.3 to 5.04 which is essentially the
changesets I previously reference from the upstream SVN repository.
Option 1 is my preference, the main difference between #1 and #2 was the
changelog version.
- Craig
diff -Nru wordpress-5.0.3+dfsg1/debian/changelog wordpress-5.0.4+dfsg1/debian/changelog
--- wordpress-5.0.3+dfsg1/debian/changelog 2019-02-05 22:23:39.0 +1100
+++ wordpress-5.0.4+dfsg1/debian/changelog 2019-03-24 09:20:02.0 +1100
@@ -1,3 +1,10 @@
+wordpress (5.0.4+dfsg1-1) testing-proposed-updates; urgency=medium
+
+ * Backport of 5.1.1 patches
+ * Fix XSS security hole in comments Closes: #924546 CVE-2019-9787
+
+ -- Craig Small Sun, 24 Mar 2019 09:20:02 +1100
+
wordpress (5.0.3+dfsg1-1) unstable; urgency=medium
* New upstream release
diff -Nru wordpress-5.0.3+dfsg1/wp-admin/about.php wordpress-5.0.4+dfsg1/wp-admin/about.php
--- wordpress-5.0.3+dfsg1/wp-admin/about.php 2019-02-05 21:54:35.0 +1100
+++ wordpress-5.0.4+dfsg1/wp-admin/about.php 2019-03-24 09:14:11.0 +1100
@@ -65,6 +65,26 @@
Version %s addressed some security issues.' ),
+ '5.0.4'
+);
+?>
+the release notes.' ),
+ sprintf(
+ /* translators: %s: WordPress version */
+ esc_url( __( 'https://wordpress.org/support/wordpress-version/version-%s/' ) ),
+ sanitize_title( '5.0.4' )
+ )
+);
+?>
+
+
+Version %1$s addressed %2$s bug.',
diff -Nru wordpress-5.0.3+dfsg1/wp-admin/includes/ajax-actions.php wordpress-5.0.4+dfsg1/wp-admin/includes/ajax-actions.php
--- wordpress-5.0.3+dfsg1/wp-admin/includes/ajax-actions.php 2019-02-05 21:54:35.0 +1100
+++ wordpress-5.0.4+dfsg1/wp-admin/includes/ajax-actions.php 2019-03-24 09:14:11.0 +1100
@@ -1070,6 +1070,8 @@
if ( wp_create_nonce( 'unfiltered-html-comment' ) != $_POST['_wp_unfiltered_html_comment'] ) {
kses_remove_filters(); // start with a clean slate
kses_init_filters(); // set up the filters
+remove_filter( 'pre_comment_content', 'wp_filter_post_kses' );
+add_filter( 'pre_comment_content', 'wp_filter_kses' );
}
}
} else {
diff -Nru wordpress-5.0.3+dfsg1/wp-includes/comment.php wordpress-5.0.4+dfsg1/wp-includes/comment.php
--- wordpress-5.0.3+dfsg1/wp-includes/comment.php 2019-02-05 21:54:35.0 +1100
+++ wordpress-5.0.4+dfsg1/wp-includes/comment.php 2019-03-24 09:14:11.0 +1100
@@ -3098,6 +3098,8 @@
) {
kses_remove_filters(); // start with a clean slate
kses_init_filters(); // set up the filters
+remove_filter( 'pre_comment_content', 'wp_filter_post_kses' );
+add_filter( 'pre_comment_content', 'wp_filter_kses' );
}
}
} else {
diff -Nru wordpress-5.0.3+dfsg1/wp-includes/formatting.php wordpress-5.0.4+dfsg1/wp-includes/formatting.php
--- wordpress-5.0.3+dfsg1/wp-includes/formatting.php 2019-02-05 21:54:35.0 +1100
+++ wordpress-5.0.4+dfsg1/wp-includes/formatting.php 2019-03-24 09:14:11.0 +1100
@@ -2750,10 +2750,12 @@
$atts = shortcode_parse_atts( $matches[1] );
$rel = 'nofollow';
- if ( preg_match( '%href=["\'](' . preg_quote( set_url_scheme( home_url(), 'http' ) ) . ')%i', $text ) ||
- preg_match( '%href=["\'](' . preg_quote( set_url_scheme( home_url(), 'https' ) ) . ')%i', $text )
- ) {
- return "";
+ if ( ! empty( $atts['href'] ) ) {
+ if ( in_array( strtolower( wp_parse_url( $atts['href'], PHP_URL_SCHEME ) ), array( 'http', 'https' ), true ) ) {
+ if ( strtolower( wp_parse_url( $atts['href'], PHP_URL_HOST ) ) === strtolower( wp_parse_url( home_url(), PHP_URL_HOST ) ) ) {
+return "";
+ }
+ }
}
if ( ! empty( $atts['rel'] ) ) {
@@ -2766,11 +2768,11 @@
$html = '';
foreach ( $atts as $name => $value ) {
- $html .= "{$name}=\"$value\" ";
+ $html .= "{$name}=\"" . esc_attr( $value ) . "\" ";
}
$text = trim( $html );
}
- return "";
+ return "";
}
/**
diff -Nru wordpress-5.0.3+dfsg1/wp-includes/version.php wordpress-5.0.4+dfsg1/wp-includes/version.php
--- wordpress-5.0.3+dfsg1/wp-includes/version.php 2019-02-05 21:54:35.0 +1100
+++ wordpress-5.0.4+dfsg1/wp-includes/version.php 2019-03-24 09:14:11.0 +1100
@@ -4,7 +4,7 @@
*
* @global string $wp_version
*/
-$wp_version = '5.0.3';
+$wp_version = '5.0.4';
/**
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
@@ -33,3 +33,4 @@
* @global string $required_mysql_version
*/
$required_mysql_version = '5.0';
+
\ No newline at end of file
Bug#925314: Acknowledgement (unblock: wordpress/5.0.3+dfsg1-1)
I probably should have stated it in the initial email but if you are asking what my preference is, it would be to have WordPress 5.0.4 in Buster. The difference between 5.0.4 and 5.0.3 currently in Buster is the security fixes. - Craig
Bug#925314: unblock: wordpress/5.0.3+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package wordpress WordPress 5.0.3 has a security bug #924546 which was fixed in upstream version 5.1.1 [1] Sid has 5.1.1 which has this fix, however it also has all the non-security fixes of 5.1 as well. For stretch, there is a patch ready to go for 4.7.5, seen at [2] that covers only the security fixes. If Buster was released, I'd prepare a security patch that would be almost-identical to the Stretch fix, taken from [3] which is where upstream tracks 5.0.x releases, using changeset 44835 and 44844. So, we have a few options: 1) Update Buster WordPress 5.0.3 to 5.0.4 which is the security fixes 2) Make a security release for Buster, effectively what (1) is with different version numbers 3) Update Buster to follow Sid, which is a major update, 5.1.1 4) Do nothing and wait until Buster is released and then fix it. I haven't prepared differences yet because depending on the answer you get a different debdiff. - Craig 1: https://wordpress.org/news/2019/03/wordpress-5-1-1-security-and-maintenance-release/ 2: https://salsa.debian.org/debian/wordpress/commit/a903dc48fb4177b15642c2c50912de50adb77c73 3: https://core.trac.wordpress.org/log/branches/5.0 unblock wordpress/5.0.3+dfsg1-1 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#779962: unblock: procps/2:3.3.9-9
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package procps
This is to fix #775624 which FTBFS depending on the kernel version used.
The fix is a four line diff which moves some output lines before the
check that passes/fails depending on the kernel response.
Either look in the source of procps for the patch
bts775624-pmap-xoutput or on the BTS at
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=42;filename=procps-pmap-xoutput.diff;att=1;bug=775624
debdiff:
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Version: [-2:3.3.9-8-] {+2:3.3.9-9+}
dsc debdiff attached.
unblock procps/2:3.3.9-9
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru procps-3.3.9/debian/changelog procps-3.3.9/debian/changelog
--- procps-3.3.9/debian/changelog 2014-09-28 09:45:14.0 +1000
+++ procps-3.3.9/debian/changelog 2015-03-07 08:12:02.0 +1100
@@ -1,3 +1,9 @@
+procps (2:3.3.9-9) unstable; urgency=medium
+
+ * pmap: output with unreadale /proc/1/smaps Closes: #775624
+
+ -- Craig Small csm...@debian.org Sat, 07 Mar 2015 08:11:15 +1100
+
procps (2:3.3.9-8) unstable; urgency=medium
* Revert to 3.3.9 upstream for Jessie freeze
diff -Nru procps-3.3.9/debian/patches/bts775624-pmap-xoutput procps-3.3.9/debian/patches/bts775624-pmap-xoutput
--- procps-3.3.9/debian/patches/bts775624-pmap-xoutput 1970-01-01 10:00:00.0 +1000
+++ procps-3.3.9/debian/patches/bts775624-pmap-xoutput 2015-03-07 08:12:02.0 +1100
@@ -0,0 +1,29 @@
+Description: pmap: output when smaps unreadable
+ If smaps can be opened but not readable, the output
+ is now the same as if the file cannot be opened
+Bug-Debian: https://bugs.debian.org/775624
+Last-Update: 2015-03-07
+--- a/pmap.c
b/pmap.c
+@@ -532,6 +532,10 @@
+ */
+ int maxcmd = 0xf;
+
++ escape_command(cmdbuf, p, sizeof cmdbuf, maxcmd,
++ ESC_ARGS | ESC_BRACKETS);
++ printf(%u: %s\n, p-tgid, cmdbuf);
++
+ if (x_option || X_option || c_option) {
+ sprintf(buf, /proc/%u/smaps, p-tgid);
+ if ((fp = fopen(buf, r)) == NULL)
+@@ -542,10 +546,6 @@
+ return 1;
+ }
+
+- escape_command(cmdbuf, p, sizeof cmdbuf, maxcmd,
+- ESC_ARGS | ESC_BRACKETS);
+- printf(%u: %s\n, p-tgid, cmdbuf);
+-
+ if (X_option || c_option) {
+ print_extended_maps(fp);
+ return 0;
diff -Nru procps-3.3.9/debian/patches/series procps-3.3.9/debian/patches/series
--- procps-3.3.9/debian/patches/series 2014-09-28 09:45:14.0 +1000
+++ procps-3.3.9/debian/patches/series 2015-03-07 08:12:02.0 +1100
@@ -1,3 +1,4 @@
+bts775624-pmap-xoutput
bts743758_vmstat_test
top_defines
uptime_test
Re: Bug#772862: Pending dpkg upload will Break your package due to trigger cycle in your package
On Sun, Dec 28, 2014 at 11:31:39AM +0100, Raphael Hertzog wrote: We have been pushing new upstream releases as security updates both in wheezy and in squeeze. It's likely that this will need to happen again during the 5 years of Jessie. Given this, it seems to me that pushing wordpress 4.1 in Jessie during the freeze should be considered too. For the same reason, I agree with Raphael. The short-term pain for getting wordpress 4.1 in will benefit over its lifecycle as the newer the package is to the then current the easier it is to maintain it. If there must only be a change for this fix, I can change the trigger line only, but it is a second preference. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141228110056.gb30...@enc.com.au
Bug#770700: unblock: wordpress/4.0.1+dfsg-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package wordpress
Wordpress 4.0 which is currently in Jessie has several
security bugs, see upstream announcement at
https://wordpress.org/news/2014/11/wordpress-4-0-1/
for details. Security bug is #770425.
The Debian 4.0.1+dfsg-1 package is *only* this upstream
change, I have no fixed anything else in order to give
the smallest delta to what we already have. I not that
the debdiff shows libphp-phpmailer version bump but
version 5.2.9+dfsg-2 is in jessie so there's no problem there.
- Craig
unblock wordpress/4.0.1+dfsg-1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
File lists identical (after any substitutions)
Control files of package wordpress: lines which differ (wdiff format)
-
Depends: apache2 | httpd, libapache2-mod-php5 | php5, ca-certificates,
mysql-client | mariadb-client, php5-gd, php5-mysql | php5-mysqlnd,
wordpress-theme-twentyfourteen, libjs-cropper (= 1.2.2), libphp-phpmailer (=
[-5.2.8+dfsg),-] {+5.2.9+dfsg),+} libphp-snoopy (= 1.2.4)
Installed-Size: [-15462-] {+15468+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-l10n: lines which differ (wdiff format)
--
Depends: wordpress (= [-4.0+dfsg-1)-] {+4.0.1+dfsg-1)+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentyfourteen: lines which differ
(wdiff format)
--
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentythirteen: lines which differ
(wdiff format)
--
Installed-Size: [-638-] {+639+}
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Control files of package wordpress-theme-twentytwelve: lines which differ
(wdiff format)
Version: [-4.0+dfsg-1-] {+4.0.1+dfsg-1+}
Re: Your procps upload 1:3.3.10-1
On Fri, Sep 26, 2014 at 08:23:47PM +0100, Jonathan Wiltshire wrote: I thought it would stay in sid and not be put into the frozen set of packages. I don't understand what you mean by this. I thought that: New package goes into SID = no real problem. The frozen set of packages come from testing, not Sid, so as long as procps wasn't moved from Sid to testing, then it would not mess up the don't change libraries stage we're in now. So Jessie has 1:3.3.9-7 and Sid has 1:3.3.10-1 and when the freeze comes its all based on Jessie which is 1:3.3.9-7 which doesn't have the API change. Isn't just a case of ensuring that 1:3.3.10-1 does not move into Jessie and it's all ok? Wouldn't merely a RC bug stop that? Is there something more to this problem I'm missing? I get its not the ideal situation. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927224204.gb14...@enc.com.au
Re: Your procps upload 1:3.3.10-1
On Sat, Sep 27, 2014 at 11:56:19PM +0100, Steven Chamberlain wrote: But the buildd chroots take packages from sid, so a reverse-dependency of procps could pick up a dependency on procps = 1:3.3.10; then that package then can't migrate unless procps does too. Yep, the other Steve (McIntyre) explained a bit too. 2%3.3.9-1 is on its way. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927231633.ga17...@enc.com.au
Re: Your procps upload 1:3.3.10-1
procps 2:3.3.9-8 got uploaded a few minutes ago. This has reverted back to libprocps3 API. I have also attempted to make sure the correct -dev library gets installed too. Let me know if there are further problems; there's a 1:3 chance that the s390 will complain due to the funny buildds they have. Apologies for the noise, you've got enough release worries to deal with without people like me doing what I did. I'll put libprocps4 into experimental with some adjustments for the top that everyone seems to hate (but that's not a RC problem). - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 signature.asc Description: Digital signature
Re: Your procps upload 1:3.3.10-1
On Thu, Sep 25, 2014 at 04:12:06PM +0100, Jonathan Wiltshire wrote: - procps FTBFS on s390x [1] The s390x is flaky, sometimes it builds sometimes it doesn't. It's due to how they (the individual buildds) are setup; they are not consistent. - open-vm-tools on i386 no longer depends on libprocps when rebuilt - open-vm-tools on amd64 FTBFS with procps-related errors [2] when rebuilt. It builds fine with libprocps3 in an otherwise up-to-date chroot I suspect it uses certain library calls it shouldn't that was the problem last time. Please either revert your upload, or fix this mess, before midnight Sunday GMT. Why did it actually get transistioned? I thought it would stay in sid and not be put into the frozen set of packages. How do you actually revert an upload? It's out there now isn't it? Again, I thought there were gates in the freeze period to stop this very thing. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140926075802.ga9...@enc.com.au
Bug#704127: unblock: procps/3.3.3-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package procps
ps crashes when processes have larger than normal groups, essentially
it is because the /proc/PID/status file is larger than 1024 bytes. This
is NOT a buffer overflow but the parser gets all sad because it runs out
of things to parse.
The fix is a rather simple bump up the buffer from 1024 to 4096.
This fixes bug #702965 which is merged with another.
We (upstream) have a permanent fix in later versions that is much more
intrusive.
Strictly speaking, the bug is in libproc0 not procps, it is just that
the binary ps crashes because of it.
unblock procps/3.3.3-3
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru procps-3.3.3/debian/changelog procps-3.3.3/debian/changelog
--- procps-3.3.3/debian/changelog 2012-06-17 18:06:28.0 +1000
+++ procps-3.3.3/debian/changelog 2013-03-28 21:14:02.0 +1100
@@ -1,3 +1,9 @@
+procps (1:3.3.3-3) UNRELEASED; urgency=low
+
+ * 3.3.3-3 Fix ps crash with large process groups Closes: #702965
+
+ -- Craig Small csm...@debian.org Thu, 28 Mar 2013 21:03:15 +1100
+
procps (1:3.3.3-2) unstable; urgency=low
* Fixes for kFreeBSD Closes: #674785
diff -Nru procps-3.3.3/debian/patches/bts702965-biggerbuff procps-3.3.3/debian/patches/bts702965-biggerbuff
--- procps-3.3.3/debian/patches/bts702965-biggerbuff 1970-01-01 10:00:00.0 +1000
+++ procps-3.3.3/debian/patches/bts702965-biggerbuff 2013-03-28 21:17:28.0 +1100
@@ -0,0 +1,47 @@
+Description: ps: allow large list of groups
+ ps crashes when the information exceeds 1024 bytes in files such as
+ /proc/PID/status.
+Origin: https://www.gitorious.org/procps/procps/commit/7933435584aa1fd75460f4c7715a3d4855d97c1c
+Author: Eric Dumazet eric.duma...@gmail.com
+Reviewed-by: Craig Small csm...@debian.org
+Bug-Debian: http://bugs.debian.org/702965
+--- a/proc/readproc.c
b/proc/readproc.c
+@@ -353,7 +353,9 @@
+ P-vm_swap = strtol(S,S,10);
+ continue;
+ case_Groups:
+-{ int j = strchr(S, '\n') - S;// currently lines end space + \n
++{ char *nl = strchr(S, '\n');
++int j = nl ? (nl - S) : strlen(S);
++
+ if (j) {
+ P-supgid = xmalloc(j+1); // +1 in case space disappears
+ memcpy(P-supgid, S, j);
+@@ -723,7 +725,7 @@
+ // room to spare.
+ static proc_t* simple_readproc(PROCTAB *restrict const PT, proc_t *restrict const p) {
+ static struct stat sb; // stat() buffer
+-static char sbuf[1024];// buffer for stat,statm,status
++static char sbuf[4096];// buffer for stat,statm,status
+ char *restrict const path = PT-path;
+ unsigned flags = PT-flags;
+
+@@ -827,7 +829,7 @@
+ // path is a path to the task, with some room to spare.
+ static proc_t* simple_readtask(PROCTAB *restrict const PT, const proc_t *restrict const p, proc_t *restrict const t, char *restrict const path) {
+ static struct stat sb; // stat() buffer
+-static char sbuf[1024];// buffer for stat,statm,status
++static char sbuf[4096];// buffer for stat,statm,status
+ unsigned flags = PT-flags;
+
+ if (unlikely(stat(path, sb) == -1))/* no such dirent (anymore) */
+@@ -1368,7 +1370,7 @@
+ * and filled out proc_t structure.
+ */
+ proc_t * get_proc_stats(pid_t pid, proc_t *p) {
+- static char path[32], sbuf[1024];
++ static char path[32], sbuf[4096];
+ struct stat statbuf;
+
+ sprintf(path, /proc/%d, pid);
diff -Nru procps-3.3.3/debian/patches/series procps-3.3.3/debian/patches/series
--- procps-3.3.3/debian/patches/series 2012-06-17 18:00:06.0 +1000
+++ procps-3.3.3/debian/patches/series 2013-03-28 21:14:25.0 +1100
@@ -2,3 +2,4 @@
bts676239-pkill-u-option
watch_8bit
uptime_test
+bts702965-biggerbuff
Bug#704127: unblock: procps/3.3.3-3
On Thu, Mar 28, 2013 at 10:51:47AM +, Adam D. Barratt wrote: This doesn't appear to have made it to the archive yet as far as I can see. If the attached debdiff was created from the final package I thought the debdiff needed to be sent first, anyhow its now uploaded to testing-proposed-updates. unstable already has 3.3.4-2, so a fix for this in wheezy would need to go via testing-proposed-updates. In such cases, we'd generally be looking at getting the fix in to unstable first though. Thanks for the tip, 3.3.4-1 had this same fix so I've let the BTS know about that too. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130328111509.ga17...@enc.com.au
ps crashes with some wheezy kernels
Hello, It seems with some kernels, including some found in wheezy, that ps will crash. The most likely problem is the number of groups appearing in /proc/PID/status. I have two reports of this happening already. I am proposing: * Increase the severity of bug #702965 * Applying a minimal diff which is in upstream (second half of [1]) * Uploading a new version of procps Otherwise we're going to be plauged with ps crashing type bugs for years while wheezy is still around, or until the next sub-release. This change is pretty trivial and works for all known kernel formats. There is another change at [2] where the buffers are dynamically created but this is brand new and a much much bigger change. I'd like to do this today (28/Mar). - Craig [1] https://www.gitorious.org/procps/procps/commit/7933435584aa1fd75460f4c7715a3d4855d97c1c [2] https://www.gitorious.org/procps/procps/commit/a45dace4b82c9cdcda7020ca5665153b1e81275f -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 signature.asc Description: Digital signature
Bug#699308: unblock: psmisc/22.19-2
On Wed, Jan 30, 2013 at 01:23:49PM +, Adam D. Barratt wrote: Please could you prepare a tpu upload (preferably versioned as 22.19-1+deb7u1) and send a debdiff to this report? Done both, the debdiff only shows the changelog changing. The patch of the source code changes is in bug 687829. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130202070417.ga31...@enc.com.au
Bug#699308: unblock: psmisc/22.19-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package psmisc unblock psmisc/22.19-2 psmisc 22.19-2 is a minimal change to 22.19-1 that fixes a bug for kFreeBSD systems (see #687829) where they don't shutdown cleanly. Other than the version number the debdiff says there is no difference to the packages. The patch involved is bug687829-kfreebsd-hang.patch which basically sets the root pid to 0. 22.20-1 also fixes this but that is probably a much bigger change to swallow while 22.19-2 is a minimal change. - Craig -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130130021453.19652.96526.report...@elmo.enc.com.au
Re: procps 3.3.4 and 3.3.5
On Sun, Nov 04, 2012 at 01:04:40PM +0100, Julien Cristau wrote: Then the broken changes in 3.3.4 need to be reverted in sid ASAP. Was uploaded a few minutes ago. It's procps 3.3.4-2 I've tested against procps 3.3.3-2 and 3.3.4-2 and it doesn't matter which combination you use, they work (slabtop and ps ax being the main two to test) - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104121147.ga3...@enc.com.au
Bug#692074: unblock: procps/1:3.3.5-1
On Thu, Nov 01, 2012 at 08:10:55PM -0700, Jonathan Nieder wrote: 1. prepare 3.3.4-2 backing out the ABI change, ask ftpmasters to reject 3.3.5-1 from NEW I emailled them tonight. 2. upload 3.3.4-2 Uploaded a few minutes ago 3. coordinate with the release team on the next step (probably that means scheduling a transition to libprocps1) Yes, I now know where the two changes were. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104121315.gb3...@enc.com.au
Bug#692074: unblock: procps/1:3.3.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package procps
procps 3.3.5-1 is blocked because libproc1 is new. The problem is that
the oldest libproc0 will not work with 3.3.5-1 because the API changed.
This means current if you install procps 3.3.4 with libproc0 3.3.4 you
have an unbootable system. Critical bug 691847 is against procps 3.3.4
but I'd like this cleared up.
unblock procps/1:3.3.5-1
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru procps-3.3.4/configure procps-3.3.5/configure
--- procps-3.3.4/configure 2012-10-29 22:04:42.0 +1100
+++ procps-3.3.5/configure 2012-10-30 22:24:28.0 +1100
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for procps-ng 3.3.4.
+# Generated by GNU Autoconf 2.69 for procps-ng 3.3.5.
#
# Report bugs to pro...@freelists.org.
#
@@ -590,8 +590,8 @@
# Identity of this package.
PACKAGE_NAME='procps-ng'
PACKAGE_TARNAME='procps-ng'
-PACKAGE_VERSION='3.3.4'
-PACKAGE_STRING='procps-ng 3.3.4'
+PACKAGE_VERSION='3.3.5'
+PACKAGE_STRING='procps-ng 3.3.5'
PACKAGE_BUGREPORT='pro...@freelists.org'
PACKAGE_URL='http://gitorious.org/procps'
@@ -1359,7 +1359,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat _ACEOF
-\`configure' configures procps-ng 3.3.4 to adapt to many kinds of systems.
+\`configure' configures procps-ng 3.3.5 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1429,7 +1429,7 @@
if test -n $ac_init_help; then
case $ac_init_help in
- short | recursive ) echo Configuration of procps-ng 3.3.4:;;
+ short | recursive ) echo Configuration of procps-ng 3.3.5:;;
esac
cat \_ACEOF
@@ -1559,7 +1559,7 @@
test -n $ac_init_help exit $ac_status
if $ac_init_version; then
cat \_ACEOF
-procps-ng configure 3.3.4
+procps-ng configure 3.3.5
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2039,7 +2039,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by procps-ng $as_me 3.3.4, which was
+It was created by procps-ng $as_me 3.3.5, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -2857,7 +2857,7 @@
# Define the identity of the package.
PACKAGE='procps-ng'
- VERSION='3.3.4'
+ VERSION='3.3.5'
cat confdefs.h _ACEOF
@@ -16644,7 +16644,7 @@
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log=
-This file was extended by procps-ng $as_me 3.3.4, which was
+This file was extended by procps-ng $as_me 3.3.5, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -16711,7 +16711,7 @@
cat $CONFIG_STATUS _ACEOF || ac_write_fail=1
ac_cs_config=`$as_echo $ac_configure_args | sed 's/^ //; s/[\\\`\$]//g'`
ac_cs_version=\\
-procps-ng config.status 3.3.4
+procps-ng config.status 3.3.5
configured by $0, generated by GNU Autoconf 2.69,
with options \\\$ac_cs_config\\
diff -Nru procps-3.3.4/debian/changelog procps-3.3.5/debian/changelog
--- procps-3.3.4/debian/changelog 2012-10-29 22:36:52.0 +1100
+++ procps-3.3.5/debian/changelog 2012-10-30 22:36:28.0 +1100
@@ -1,3 +1,12 @@
+procps (1:3.3.5-1) unstable; urgency=low
+
+ * New upstream version
+ * bumped SONAME of packages Closes: #691847
+ * Stop SIGFPE on vmstat at times Closes: #677903
+ * Upstream took freebsd bug patch
+
+ -- Craig Small csm...@debian.org Tue, 30 Oct 2012 22:26:52 +1100
+
procps (1:3.3.4-1) unstable; urgency=low
* New upstream version
diff -Nru procps-3.3.4/debian/clean procps-3.3.5/debian/clean
--- procps-3.3.4/debian/clean 1970-01-01 10:00:00.0 +1000
+++ procps-3.3.5/debian/clean 2012-10-30 22:43:23.0 +1100
@@ -0,0 +1 @@
+.version
diff -Nru procps-3.3.4/debian/control procps-3.3.5/debian/control
--- procps-3.3.4/debian/control 2012-05-20 16:47:39.0 +1000
+++ procps-3.3.5/debian/control 2012-10-30 22:27:47.0 +1100
@@ -25,7 +25,7 @@
It contains free, kill, pkill, pgrep, pmap, ps, pwdx, skill, slabtop,
snice, sysctl, tload, top, uptime, vmstat, w, and watch.
-Package: libprocps0
+Package: libprocps1
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
@@ -38,11 +38,11 @@
This package contains the shared libraries necessary to run programs
compilied with libprocps.
-Package: libprocps0-dev
+Package: libprocps1-dev
Bug#692074: unblock: procps/1:3.3.5-1
On Thu, Nov 01, 2012 at 05:37:37PM -0700, Jonathan Nieder wrote: I think including libprocps1 in wheezy would be good, but would it be possible to back out the ABI break in sid in the meantime? Tell me how to do it (not the API change, but more around the what version etc) and I will. I assume its making a 3.3.4-2 with a debian patch to reverse the API and then do.. something. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102030318.ga18...@enc.com.au
procps 3.3.4 and 3.3.5
Hi, I'm trying to make sure procps 3.3.4-1 is not going to be progressed along any further. The API changed which means if procps is upgraded and libproc0 isn't, then some procps commands don't work well. I've reported a critical bug [1] on procps (it stops the boot process) but 3.3.5 is stuck because the package name has changed to libproc1. Ideally I'd like 3.3.4 gone but I think its too late for that, so some things depending on libproc0 may go strange. - Craig [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691847 -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 signature.asc Description: Digital signature
Putting procps 3.2.7-9 into Lenny
Hello Release Team, I would like to propose that procps 3.2.7-9 be put into Lenny, instead of procps 3.2.7-8. There are some small but (for some significant) changes in this version. The biggie is #460331. If you are like me and have only i386 computers you don't see this bug at all :) This fix basically reads all 7 numbers in the cpu line instead of 4 (which it used to be in old kernels). These numbers are used to work out the Hz-jiffy conversion. Anyhow, if you have something strange like an Armel, ARM, qnap 209 and probably other things, you will get this bug at some time. Changing to 3.2.7-9 means our friends with these sorts of architectures won't (or shouldn't) get that bug. I think hosts running Xen or other things like it may get it too. 3.2.7-9 has been out since August, procps is in base so everyone has it and there are no NEW bugs specific to 3.2.7-9 (ie that weren't in 3.2.7-8 or earlier) - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#311344: Replacing lpr-ppd with lprng removes printer database
On Wed, Jun 01, 2005 at 01:15:37PM +0200, A Mennucc wrote: /etc/printcap is a conffile of lpr-ppd ; if lpr-ppd is removed, /etc/printcap will still be there ; but if you purge lpr-ppd , dpkg will delete /etc/printcap , since it is not a conffile of lprng lprng used to have /etc/printcap but for very good reasons I can no longer remember (perhaps that conffiles need to be only for a single package) it no longer has a printcap. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
rspfd : You can remove this package
Hello, I was just going over my packages around release time and noticed that rspfd was still in sarge. You can easily drop this package and nothing should depend on it. I have had it RFA for over a year and just put in a bug to ftp.debian.org to have it removed. Sorry for my bad timing! - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lprng 3.8.28-2 fixes security bug #286391
Hello, I have just uploaded lprng 3.8.28-2 which fixes a minor but security related bug #286391. I have only made enough changes to fix this bug which is a patch to a shell script and so, i hope, will not cause too much headache for you guys. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
