Bug#1064284: [pcp] Bug#1064284: pcp: NMU diff for 64-bit time_t transition
Hi Steve, On Tue, Feb 20, 2024 at 3:11 PM Steve Langasek wrote: > [...] > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pcp > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Thanks for preparing the patch, sorry for not getting back to you sooner (I've been away). I have discussed with other PCP maintainers and we'd prefer an approach where we simply exclude PCP from the few remaining 32 bit platforms, from the next major release onward. This is consistent with the approach taken with other distributions and avoids the package name mangling and general user confusion that will result for our packages. > [...] if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. cheers. -- Nathan
Bug#1041754: [pcp] Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig
https://github.com/performancecopilot/pcp/pull/1874
Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig
On Mon, Jan 1, 2024 at 1:47 AM Chris Hofstaedtler wrote: > [..] > > I see you've uploaded two new upstream versions since this bug was > filed. Is there anything blocking inclusion of Helmut's patch? > Thank you for the reminder and thanks for the patch Helmut. I'll get this into the next update (pcp-6.2.0 expected late next week). cheers. -- Nathan
Bug#1007287: xfsdump: please consider upgrading to 3.0 source format
Hi Bastian, Please go right ahead - thanks for your efforts! cheers. -- Nathan
Bug#990223: fixed in pcp 5.3.4-1
Thanks Sunil, Mark (Goodwin) has been looking into getting this merged for next week's PCP release - he'll be in contact with you soon I believe. cheers. On Sat, Oct 30, 2021 at 5:19 PM Sunil Mohan Adapa wrote: > > On Sun, 10 Oct 2021 11:50:03 -0700 Sunil Mohan Adapa > wrote: > > On Thu, 07 Oct 2021 23:18:50 + Debian FTP Masters > > wrote: > > > Source: pcp > > > Source-Version: 5.3.4-1 > > > Done: Nathan Scott > > > > > > > Unfortunately, the solution didn't seem to work. piuparts still failed > > with the latest version[1]. This is presumably because the environment > > under which piuparts has installed the package, systemd was not detected > > and the changes were still made to the configuration file. > > > > We could either drop the changes for non-systemd systems entirely or > > patch the init.d file to pickup a newly environmental file dropped in by > > zeroconf. > > > > Hi Nathan, > > My apologies for an incomplete solution earlier. I have proposed a > different solution that works for machines with systemd and without[1]. > I would appreciate a review, merge and release with the new fix. > > Links: > > 1) https://github.com/performancecopilot/pcp/pull/1462 > > Thanks, > > -- > Sunil >
Bug#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger
Hi Sunil, On Thu, Sep 30, 2021 at 3:52 AM Sunil Mohan Adapa wrote: > > On Sun, 5 Sep 2021 16:51:46 +1000 Nathan Scott wrote: > > Hi Petter, > > > > On Sun, Sep 5, 2021 at 4:45 PM Petter Reinholdtsen wrote: > > > [...] This approach is known as multilevel configuration. > > > > > > I recommend it over modifying conffiles in /etc/. > > > > I'll discuss with other upstream folks and see if we can transition > > to this style of solution & for all distros. It's a fairly major change, > > so it won't happen overnight, but I agree it is a good way to tackle > > this. > > > > There is a simpler solution. The configuration option in question is an > environment variable. This can be passed to the daemon by shipping a Interesting idea. > systemd service configuration file in pmlogger packaging. > > $ cat /usr/lib/systemd/system/pmlogger.service.d/pcp-zeroconf.conf > [Service] > > Environment=PMLOGGER_INTERVAL=10 > > [...] > I have tested this solution as follows: > > (comment out PMLOGGER_INTERVAL in /etc/default/pmlogger) > # systemctl daemon-reload > # systemctl show pmlogger.service | grep Environment > Environment=PMLOGGER_INTERVAL=10 > > # systemctl restart pmlogger.service > # systemctl status pmlogger.service > (pickup main PID from output) > # cat /proc/{pid}/environ | tr '\0' '\n' | grep PMLOGGER_INTERVAL > PMLOGGER_INTERVAL=10 Yep, well played - neat solution. > Non-systemd systems: > > In addition to this solution the change in pmlogger.postinst can be > confined to non-systemd systems: > +1 > > > # increase default pmlogger recording frequency > > > if [ ! -e /run/systemd ]; then > > sed -i 's/^\#\ PMLOGGER_INTERVAL.*/PMLOGGER_INTERVAL=10/g' > /etc/default/pmlogger > > > fi > > > If better approach for non-systemd systems is desired, then we canpatch > [...] I think this would do for now. Could you post a patch? Either here, or to me directly, or p...@groups.io, or a PR on the PCP github repo? (all the debian build files are there too). > Severity: > > Currently, this bug is threatening to remove all of pcp, cockpit and > freedombox from Debian on October 10th. Please consider adopting some > solution to avoid this. That'd be good - if you can send through that tested solution, I'll endeavour to get a build uploaded with it next week. cheers. -- Nathan
Bug#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger
Hi Petter, On Sun, Sep 5, 2021 at 4:45 PM Petter Reinholdtsen wrote: > [...] This approach is known as multilevel configuration. > > I recommend it over modifying conffiles in /etc/. I'll discuss with other upstream folks and see if we can transition to this style of solution & for all distros. It's a fairly major change, so it won't happen overnight, but I agree it is a good way to tackle this. Thanks! -- Nathan
Bug#985384: [pcp] Bug#985384: pcp: Need to write permission to /var/log/pcp/pmfind/
Hi Yabuki, On Wed, Mar 17, 2021 at 11:45 AM YABUKI Yukiharu wrote: > [...] > Your pcp package need to give write permissions to /var/log/pcp/pmfind/ > pcp claims that it could not touch /var/log/pcp/pmfind/pmfind_check.log. Thanks for letting us know - this will be fixed in the pcp-5.3.0 release. cheers. -- Nathan
Bug#982323: [pcp] Bug#982323: pcp-export-pcp2{graphite,influxdb}: missing Breaks+Replaces: pcp (<< 5.2.5)
Hi Andreas, On Tue, Feb 9, 2021 at 8:55 AM Andreas Beckmann wrote: > [...] > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > [...] Thanks for the report. It's strange - I performed a similar upgrade from 5.2.3 but didn't run into this. I'll fix it up via your suggested change and upload a -2 build soon. cheers. -- Nathan
Bug#962994: [pcp] Bug#962994: pcp: cron jobs launch pcp in cron's cgroup
Hi Sam, On Wed, Jan 6, 2021 at 5:38 AM Sam Morris wrote: > [...] > > checking if systemd should be used... no > > I wish it was possible to see the config.log from this build... but at > least I can reproduce this with pbuilder. > > Adding --with-systemd to the configure command line will promote this to > a build error. I recommend making that change in debian/rules so that > this doesn't fall through the cracks: Agreed - will do. > [...] > And it's systemd that ships systemd.pc: > > $ dpkg -S /usr/share/pkgconfig/systemd.pc > systemd: /usr/share/pkgconfig/systemd.pc Aha! I get it now - the libsystem-dev dependency is insufficient, we need a dependency on systemd itself (as you say). I'll get that fixed up too. Thanks!!! cheers. -- Nathan
Bug#976683: RFS: xfsprogs/5.10.0-0.1 [NMU] -- Utilities for managing the XFS filesystem
Hi Bastian, On Sun, Jan 10, 2021 at 8:04 AM Bastian Germann wrote: > [...] > > Changes since the last upload: > > xfsprogs (5.10.0-0.1) unstable; urgency=medium Please get your changes merged in the upstream xfsprogs git repo (via linux-xfs mailing list patches), and add yourself to the Uploaders line. Thanks. -- Nathan
Bug#975997: [pcp] Bug#975997: pcp: Upgrade failure due to unversioned libpcp3 dependency
Hi Matthew, On Sat, Nov 28, 2020 at 7:38 PM Matthew Gabeler-Lee wrote: > > Attempting an `apt upgrade` on my bullseye system failed, due to improper > dependency info in the pcp package. The libpcp3 dependency has no version > constraints, and the new version of libpcp3 requires pulling in a new > version of perl, so `apt upgrade` left it out. This then resulted in the > attempt to restart the pcp service failing due to a missing symbol: Thanks for the report - this is resolved in the upstream PCP git repo now, and will be uploaded in a couple of weeks after further testing. cheers. -- Nathan
Bug#974704: [pcp] Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]
Hi Dom, On Sun, Nov 15, 2020 at 7:01 AM Dominic Hargreaves wrote: > > On Sat, Nov 14, 2020 at 12:35:04AM +, Dominic Hargreaves wrote: > > This package FTBFS on the architectures which don't have bpftrace as a > > dependency since: > > ... > > Also, if you do do another upload, please can you do a source-only > upload or make sure that you build on an up-to-date sid (the upload > on Wednesday was built against perl 5.30 on amd64). We always do source-only uploads, except in this case where we were explicitly requested by ftp-masters to do a binary upload as it introduced a new sub-package. Thanks for the NMU, please feel free to reduce it from 4 days to less if that helps - I'll ensure a version of your patch gets included in the next upstream release. cheers. -- Nathan
Bug#973010: [pcp] Bug#973010: pcp is uninstallable on many architectures due to new bpftrace dependency
On Wed, Oct 28, 2020 at 7:56 AM Martin Pitt wrote: > > Package: pcp > Version: 5.2.1-1 > [...] > But the "bpftrace" package only exists on a few architectures [1]. This is > what > makes the package uninstallable and prevents testing migration [2]. > > Please fix > that at least by restricting the architectures, like so: Thanks Martin - we'll tackle this in the next update (pcp-5.2.2, couple weeks out). > Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, > libpcp-pmda-perl, python3-pcp, python3, bpftrace (>= 0.9.2) [amd64 arm64 > ppc64 ppc64el], libpcp-web1 > > Preferably you would also drop it to Recommends:, as hopefully bpftrace isn't > an absolute requirement for running PCP? I.e. It's not an absolute requirement - more of a Suggests: line entry, even. cheers. -- Nathan
Bug#962994: [pcp] Bug#962994: pcp: cron jobs launch pcp in cron's cgroup
On Wed, Jun 17, 2020 at 9:52 PM Ken McDonell wrote: > On 17 June 2020 8:45:12 pm Sam Morris wrote: > > > Package: pcp > > Version: 5.1.1-1 > > Severity: normal > > > > $ systemctl status cron > > ● cron.service - Regular background program processing daemon > > Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor > > preset: > > enabled) > > Active: active (running) since Wed 2020-06-17 09:03:18 BST; 2min 5s ago > > Docs: man:cron(8) > > Main PID: 3499535 (cron) > > IP: 0B in, 0B out > > Tasks: 49 (limit: 38380) > > Memory: 2.4G > >CPU: 728ms > > CGroup: /system.slice/cron.service > > ├─2725001 /usr/bin/pmie -b -F -P -l > > /var/log/pcp/pmie/fragarach.domain.example/pmie.log -c > > config.default > > ├─3241662 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c > > config.default -v > > 100mb -m pmlogger_check %Y%m%d.%H.%M > > ... > > Hi Sam, > > Do you expect all these pmloggers to be running? > > We're going to need some help to debug this one. > I found some clues. Firstly, and most obviously I guess - we should not even be installing these cron jobs - this task is managed by our systemd timers now. Digging into that aspect, it seems the PCP configure script has now started disabling systemd (!) on Debian for reasons I don't follow. Here's a relevant build log: https://buildd.debian.org/status/fetch.php?pkg=pcp=amd64=5.1.1-1=1590715276=0 This is the relevant PCP configure.ac snippet: dnl Check for systemd services enable_systemd=false AC_MSG_CHECKING([if systemd should be used]) AS_IF([test "x$do_systemd" != "xno"], [ enable_systemd=true PKG_CHECK_VAR([SYSTEMD_SYSTEMUNITDIR], [systemd], [systemdsystemunitdir], [pcp_systemdunit_dir=$SYSTEMD_SYSTEMUNITDIR], [enable_systemd=false]) so, we are (all of a sudden?) taking the enable_systemd=false path and looks like it's all downhill from there. cheers. -- Nathan
Bug#953537: xfsdump fails to install in /usr merged system.
Hi folks, Apologies for the slow response - yes, I'm around but not with alot of time for packaging work unfortunately. I appreciate all the help! On Mon, Mar 16, 2020 at 11:06 PM Goffredo Baroncelli wrote: > > This bug was already addressed in the past by Marco d'Itri. Now it reappears. Yes, what's really needed here is for a change to be merged upstream (as all other deb packaging artifacts are) otherwise this will keep getting lost in time. I suspect the Makefile change may need some tweaking to be palatable to any other distributions relying on the existing behaviour, but the new files below debian/* should be no problem. CC'ing upstream maintainer - Eric this looks like an issue resolved in rpm builds, any thoughts on the changes being requested in the patch here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953537 Thanks! -- Nathan
Bug#954792: xfsdump: xfsrestore does not recreate missing inventory information
On Tue, Mar 24, 2020 at 1:57 AM root wrote: > [...] > I noticed this with xfsrestore 3.1.6 (on a Debian 9.12 host), then I git > cloned xfsdump-dev, built from source and observed the same behaviour in > xfsrestore 3.1.9. > Best to discuss this with the (upstream) XFS maintainers as it's not something specific to the Debian packaging of xfsdump AFAICT. cheers. -- Nathan
Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hi Martin, Sunil, all, Thanks for looking into this issue while we were all off, Martin and Sunil! To summarise where I understand things are at now: Martin's uploaded a pcp package for rebuild which drops the python2 build steps. I think this is fine and solves the immediate, pressing issue. The intent with the build system is/was to allow pcp deb builds on older Debian platforms as well, where python(2) may be the only option. But, it looks like python3 has been present in all supported Debian versions going back to debian8 so perhaps it is time to make Martin's change in upstream PCP too? Ken and Andreas, this would mean we set Debian8 (and the equivalent Ubuntu release) as the minimum required for Makepkgs builds. Would that be a problem for anyone? It turns out that was the first Debian that used systemd as the init system, so there's a possibility of several other useful packaging cleanups if we take this path. cheers. -- Nathan On Mon, Jan 6, 2020 at 7:19 AM Martin Pitt wrote: > > Control: tag -1 pending > > Hello again, > > Martin Pitt [2020-01-05 10:54 +0100]: > > > I ran into similar issue when attempting to build with multiple parallel > > > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this > > > turned on, please try disabling it. > > > > I indeed had that option set, thanks for pointing out! pcp's packaging is > > rather complex and debian/rules rather old-fashioned and hard to understand, > > and apparently doesn't get along well with parallel builds. This RC bug fix > > is > > not the time for more intrusive changes though, so let's ignore this for now > > indeed. > > > > However, even with unsetting it it still fails: > > Nevermind, I also had MAKEVARS=-j4 set, which caused this issue. > > I now uploaded this as an NMU to DELAYED/3, using the exact patch that I > attached yesterday. > > Thanks, > > Martin > > -=-=-=-=-=-=-=-=-=-=-=- > Groups.io Links: You receive all messages sent to this group. > > View/Reply Online (#21752): https://groups.io/g/pcp/message/21752 > Mute This Topic: https://groups.io/mt/69427489/174104 > -=-=- > pcp mailing list > p...@groups.io > https://groups.io/g/pcp/messages > -=-=- > Group Owner: pcp+ow...@groups.io > Unsubscribe: https://groups.io/g/pcp/leave/354222/526236543/xyzzy > [nath...@redhat.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Bug#937260: [pcp] Bug#937260: Offering NMU
Hi Martin, On Mon, Dec 2, 2019 at 10:48 AM Martin Pitt via Groups.Io wrote: > > Hello, > > I just checked that python-pcp has zero reverse build and binary dependencies, > so it's fine to just drop it and thus fix this RC bug. If you don't have time, > I'm happy to do an NMU for this (as cockpit maintainer I don't want cockpit to > get dropped from testing due to pcp disappearing). Thanks! I've updated the PCP deb builds in the upstream PCP repo and plan to close this issue out with the pcp-5.0.2 release (scheduled for Wed 11th). If you need the fix sooner though, feel free to NMU. cheers. -- Nathan
Bug#929318: [pcp] Bug#929318: unblock: papi/5.7.0+dfsg-1
Hi Paul, Andreas, Apologies for the slow response - I'm in meetings all week this week and I'm a bit behind as a result. On Thu, Jun 20, 2019 at 9:17 AM Andreas Beckmann wrote: > > On 18/06/2019 23.05, Paul Gevers wrote: > > pcp was completely off my radar since it has (silently) dropped all papi > dependencies in unstable. The PAPI metrics in PCP have been transitioned to using perfevent - one of the several reasons for this was to help resolve this Debian bug. The best outcome for Debian PCP user base here would be to use the bugfix PCP update that has been in unstable for several weeks now - this provides a clean upgrade path for pmdapapi users, and removes the PCP dependency on PAPI completely. > I'll do a 0-day NMU of pcp on Thursday (36 hours from now) unless we > heard from Nathan till then. If we cannot use the tested, stable, upstream bugfix update provided earlier due to the release constraints, please go ahead and NMU as needed Andreas - thanks. > Just thinking ... lazy removal of libpapi5 from testing does not work, > since libpapi5.7 breaks it, and pcp-dev probably depends transitively on FWIW, the PCP development packages do not depend on any PAPI (and never have) - it is only older versions of the 'pcp' package itself, which contain the pmdapapi binary - now retired to help resolve this issue. cheers. -- Nathan
Bug#921975: ITS: attr
On Mon, Feb 11, 2019 at 6:39 AM Guillem Jover wrote: > > Source: attr > Source-Version: 1:2.4.47-2 > Severity: important > > Hi! > > This package needs some attention, and looks like a candidate for > salvaging. Anibal is already being tracked by the MIA team, and I > think it's just a matter of days until he gets an orphaning pass. > > I'd like to get updated packages uploaded for the next release, so > some time before the freeze. That's why I'll probably be using a > shorter salvaging process here. Nathan please let me know if you > have any objection over this? No objection at all Guillem, thanks for taking on this work. cheers. -- Nathan
Bug#921974: ITS: acl
On Mon, Feb 11, 2019 at 6:36 AM Guillem Jover wrote: > > Source: acl > Source-Version: 2.2.52-3 > Severity: important > > Hi! > > This package needs some attention, and looks like a candidate for > salvaging. Anibal is already being tracked by the MIA team, and I > think it's just a matter of days until he gets an orphaning pass. > > I'd like to get updated packages uploaded for the next release, so > some time before the freeze. That's why I'll probably be using a > shorter salvaging process here. Nathan please let me know if you > have any objection over this? No objection at all Guillem, thanks for taking on this work. cheers. -- Nathan
Bug#766811: spurious library links
Hi Michael, Yes, please go right ahead with NMU - I will follow up with the XFS folks when I can. thanks! On Sat, Mar 18, 2017 at 1:32 AM, Michael Biebl <bi...@debian.org> wrote: > Hi Nathan, > > thanks for your quick reply > > Am 17.03.2017 um 13:22 schrieb Nathan Scott: > >> So this NMU happened, but unfortunately your followup maintainer upload, > >> i.e. 4.5.0 did not include the changes from the NMU. > > > > (d'oh, these changes needs to be sent upstream to the kernel.org > > <http://kernel.org> XFS list) > > I'm not sure about Marco, but I don't know the procedures getting a > patch into xfsprogs. So I would very much prefer if you forward the > patch to the right people. > > >> Nathan, could you make another upload including the fix from Marco? > > > > I'm currently traveling and will be unable to attend to this for some > time. > > Should Marco or myself do another NMU then? I would send you an updated > debdiff in this case. > > Regards, > Michael > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#766811: spurious library links
Hi Michael, > So this NMU happened, but unfortunately your followup maintainer upload, > i.e. 4.5.0 did not include the changes from the NMU. (d'oh, these changes needs to be sent upstream to the kernel.org XFS list) > Nathan, could you make another upload including the fix from Marco? I'm currently traveling and will be unable to attend to this for some time. cheers. -- Nathan On Fri, Mar 17, 2017 at 3:28 AM, Michael Biebl <bi...@debian.org> wrote: > Hi Nathan > > On Tue, 9 Feb 2016 22:20:23 -0500 (EST) Nathan Scott > <nath...@debian.org> wrote: > > > > Should I NMU? > > > > Please go right ahead Marco - many thanks! > > So this NMU happened, but unfortunately your followup maintainer upload, > i.e. 4.5.0 did not include the changes from the NMU. > > Nathan, could you make another upload including the fix from Marco? > > I've attached the debdiff which still seems to apply against 4.9.0 > > Seeing that this issue already caused two duplicates being filed, I'd > say it's worth fixing for stretch. > > Regards, > Michael > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#851664: nmu: pcp_3.11.7
Hi guys, - Original Message - > On Sun, Jan 22, 2017 at 04:41:59PM -0500, Nathan Scott wrote: > > > > This is happening again and again (see bugs 776440 and 847149). The fix > > > here is to get rid of the package until the maintainer catches up, not > > > to work around him time and time again, IMO. > > > > I'm planning to start source-only uploads from the next pcp upload, so > > this class of problem should go away. > > Please consider fixing Bug #805955 as well (FTBFS with dpkg-buildpackage -A), > otherwise the package will not be released with stretch. > > (The package migrated to testing on 2016-12-29, but that was really > an accident). > Understood, and yep, I would love to see that fixed (patches welcome), but its not reached the front of my queue yet. cheers. -- Nathan
Bug#851664: nmu: pcp_3.11.7
Hi there, - Original Message - > On Tue, Jan 17, 2017 at 12:42:05 +0100, Andreas Beckmann wrote: > > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu pcp_3.11.7 . amd64 . unstable . -m "Rebuild in sid." > > > > Maintainer uploaded package was built in stable. Sorry about this guys, this is the first I became aware of these two issues. I'm building on an infrequently-updated unstable, not stable. I guess somehow the perl packages must not be getting dpkg updated on this box. > This is happening again and again (see bugs 776440 and 847149). The fix > here is to get rid of the package until the maintainer catches up, not > to work around him time and time again, IMO. I'm planning to start source-only uploads from the next pcp upload, so this class of problem should go away. cheers. -- Nathan
Bug#805955: [pcp] Bug#805955: pcp: FTBFS when built with dpkg-buildpackage -A (no binary artifacts)
- Original Message - > > Actually some advice would be great, having had an initial look into > > this one now. Patch below shows the basic split we'll need to make > > the architecture independent packages generated separately, but I'm > > not sure how to fit that split into the rest of the rules file (I get > > the same sort of errors with a change like this in place no matter > > what I try - maybe its obvious to someone more deb knowledgeable?). > > I have not tested the patch but I see why it would not work. > > Try putting "dh_builddeb" somewhere in binary-indep, otherwise the > actual .deb packages will not be created. > > Thanks. > Taa. I see problems in the binary-indep target before the build reaches that stage though. The debian/rules uses dh_install(1) - in particular, it relies on this behaviour from the man page... On the other hand, maybe you have a large package that builds multiple binary packages. You can use the upstream Makefile to install it all into debian/tmp, and then use dh_install to copy directories and files from there into the proper package build directories. And dh_install fails when used by the binary-indep target - it requires files from both binary-indep and binary-arch, I think. Does that mean dh_install can no longer be used for these targets as described above or does that stage need to done elsewhere? (before dh_builddeb I'm sure) Thanks. -- Nathan
Bug#805955: [pcp] Bug#805955: pcp: FTBFS when built with dpkg-buildpackage -A (no binary artifacts)
Tags: help - Original Message - > Greetings. > > I have the ok from the Release Managers to consider this issue as RC > for stretch. I'm going to wait at least one week before raising > this to "serious". > > If you need help to fix this bug, please tag it as "help". Actually some advice would be great, having had an initial look into this one now. Patch below shows the basic split we'll need to make the architecture independent packages generated separately, but I'm not sure how to fit that split into the rest of the rules file (I get the same sort of errors with a change like this in place no matter what I try - maybe its obvious to someone more deb knowledgeable?). Thanks! -- Nathan diff --git a/debian/rules b/debian/rules index dccf619..44774a1 100755 --- a/debian/rules +++ b/debian/rules @@ -163,7 +163,20 @@ clean: dh_autotools-dev_restoreconfig dh_clean -binary-indep: +binary-indep: checkroot build-stamp + @echo "== dpkg-buildpackage: binary-indep" 1>&2 + $(checkdir) + $(pkgpcp_import_sar) $(MAKE) -C src/sar2pcp install + $(pkgpcp_import_ganglia) $(MAKE) -C src/ganglia2pcp install + $(pkgpcp_import_mrtg) $(MAKE) -C src/mrtg2pcp install + $(pkgpcp_import_sheet) $(MAKE) -C src/sheet2pcp install + $(pkgpcp_import_iostat) $(MAKE) -C src/iostat2pcp install + dh_perl -p $(pcp_import_sar) + dh_perl -p $(pcp_import_ganglia) + dh_perl -p $(pcp_import_mrtg) + dh_perl -p $(pcp_import_sheet) + dh_perl -p $(pcp_import_iostat) + dh_installdeb binary-arch: checkroot build-stamp @echo "== dpkg-buildpackage: binary-arch" 1>&2 @@ -177,11 +190,6 @@ binary-arch: checkroot build-stamp $(pkglibpcp_pmda_perl) $(MAKE) -C src/perl/PMDA install_perl $(pkglibpcp_import_perl) $(MAKE) -C src/perl/LogImport install_perl $(pkgpcp_logsummary_perl) $(MAKE) -C src/perl/LogSummary install_perl - $(pkgpcp_import_sar) $(MAKE) -C src/sar2pcp install - $(pkgpcp_import_ganglia) $(MAKE) -C src/ganglia2pcp install - $(pkgpcp_import_mrtg) $(MAKE) -C src/mrtg2pcp install - $(pkgpcp_import_sheet) $(MAKE) -C src/sheet2pcp install - $(pkgpcp_import_iostat) $(MAKE) -C src/iostat2pcp install $(pkgpcp_import_collectl) $(MAKE) -C src/collectl2pcp install $(pkgpcp_export_graphite) $(MAKE) -C src/pcp2graphite install $(pkgpcp_export_zabbix) $(MAKE) -C src/zabbix-agent install @@ -237,11 +245,6 @@ binary-arch: checkroot build-stamp dh_perl -p $(libpcp_pmda_perl) dh_perl -p $(libpcp_import_perl) dh_perl -p $(pcp_logsummary_perl) - dh_perl -p $(pcp_import_sar) - dh_perl -p $(pcp_import_ganglia) - dh_perl -p $(pcp_import_mrtg) - dh_perl -p $(pcp_import_sheet) - dh_perl -p $(pcp_import_iostat) dh_installdeb dh_shlibdeps 2>/dev/null# qmake doesn't allow a library list dh_gencontrol $(SUBSTVARS) 2>/dev/null # squash the python:Versions warning
Bug#805955: [pcp] Bug#805955: pcp: FTBFS when built with dpkg-buildpackage -A (no binary artifacts)
Hi Santiago, - Original Message - > Greetings. > > I have the ok from the Release Managers to consider this issue as RC > for stretch. I'm going to wait at least one week before raising > this to "serious". > > If you need help to fix this bug, please tag it as "help". > I have a build with another pending fix to upload too, so will look into this first and push both up this weekend. cheers. -- Nathan
Bug#766811: spurious library links
- Original Message - > [..] > Right. Nathan, this code path is not used on Red Hat and SuSE, which > already implemented a merged /usr, and it has always been wrong on > Debian: I think it should just be removed from the upstream package. > Should I NMU? Please go right ahead Marco - many thanks! -- Nathan
Bug#766813: spurious library links
- Original Message - > [...] > If you do not think that this library is still useful for modern > software then I recommend asking for its removal. > I completely support that - would you mind doing the legwork with the ftp-masters, Marco? Many thanks! -- Nathan
Bug#766813: spurious library links
Hi Marco, - Original Message - > On Oct 26, Marco d'Itriwrote: > > > These links do not appear to have any purpose and should be removed: > > > > /lib/libdm.a -> /usr/lib/libdm.a > > /lib/libdm.la -> /usr/lib/libdm.la > > /usr/lib/libdm.so -> /lib/libdm.so > > > > Also, policy forbids to thip the .la files at all for normal libraries. > This is an obvious bug and I have not heard back from you in over one > year, what are your plans about fixing this? Do you need help? Sorry, I'm juggling many balls & this has been off the radar for a long time. Help is *always* very welcome, thanks! I think also nothing else (packages) depends on libdm anymore - used to be xfsdump? - so perhaps it should be removed entirely from the archive. cheers. -- Nathan
Bug#804255: Please update initramfs in postinst
- Original Message - > >[...] > >That would be great, if you don't mind Steve? Many thanks! > > Here's a debdiff of what I've just built. Ignore the NMU version in > the changelog... Thanks Steve - I believe there's an upstream xfsprogs release pending, so we'll get this uploaded shortly. cheers. -- Nathan
Bug#804255: Please update initramfs in postinst
Hi Steve, - Original Message - > Package: xfsprogs > Version: 3.2.1 > Severity: important > Tags: d-i > > To make this work well, all filesystem tools packages for filesystems > that are likely to be used for / and/or /usr should call > "update-initramfs -u" in their postinst. This will OK. > I've checked your package and I don't see any update-initramfs > calls. (yep, xfsprogs has no postinst at all IIRC) > Please add one. If you'd like help doing that postinst work, I > can supply a patch - just ask! That would be great, if you don't mind Steve? Many thanks! cheers. -- Nathan
Bug#793495: xfsprogs fails to build on debian ppc64el
- Original Message - On Wed, Aug 05, 2015 at 12:52:50PM -0300, Fernando Seiti Furusato wrote: [...] It is the Debian source package that fails, exclusively. [...] That hunk shows why it is failing - no ppc64le:Linux match in the old script. Nathan is already looking into it... So, yeah, its definitely got something to do with the local setup here inserting configure-generated files that are dated. I build the .debs from a tagged git repo checkout (without the generated files initially) so they do get inserted locally. Having re-installed all autoconf-related packages now on that machine, as well as constructing an entirely new unstable VM for builds :P ... the problem has resolved itself and I see config.sub with ppc64le bits too. I'll do a build and upload (source-unchanged) 3.2.4-1 package to make sure its resolved on the build servers. Thanks to all for looking into it so closely! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793496: About the security issues affecting xfsprogs in Squeeze
Hi Raphaël, - Original Message - [...] We decided that we would not prepare a squeeze security update (usually because the security impact is low and that we concentrate our limited resources on higher severity issues and on the most widely used packages). That said the squeeze users would most certainly benefit from a fixed package. I tend to agree - seems like a fairly minor issue I don't have a huge amount of spare time either. I'll concentrate on getting next upstream release with the fix uploaded to unstable as soon as possible though - but I'm not likely to get to backporting this one. Thanks for the heads-up! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789376: [pcp] Bug#789376: missing licenses in debian/copyright
- Original Message - [...] lots of files in man/*, book/* and images/* are licensed under some version of CC. Please remove all files from the tarball that use a DFSG incompatible license and mention the others in your debian/copyright. OK, will do. I see a mix of CC-SA versions there - some (icon files) under v2.5 - these files are nowadays in the public domain though, so easily fixed. Most/all others appear to be under CC-BY-SA v3.0, and AIUI from https://wiki.debian.org/DFSGLicenses this is OK. I'll get that first set fixed up and update the copyright file for pcp-3.10.6 - thanks Thorsten! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781047: [pcp] Bug#781047: libpcp3-dev: /usr/include/pcp/import.h missing
Hi Shawn, - Original Message - Package: libpcp3-dev [...] the package is not installing all the header files please ship /usr/include/pcp/import.h This file is shipped as part of the libpcp-import1-dev package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771793: [pcp] Bug#771793: pcp: insecure use of /var/tmp in postinst
Hi Jakub, - Original Message - [...] I'd suggest using stat(1) to check the file type and ownership atomically, and without following symlinks. Something like this should work: [ $(LC_ALL=C stat -c '%u %g %F' $dir) = 0 0 directory ] mv $dir /var/lib/pcp/tmp Yep, looks good - will get this included in the next update, thanks. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771789: [pcp] Bug#771789: libpcp-pmda-perl: uninstallable on i386: depends on perlapi-5.18.2
Hi Jakub, - Original Message - [...] The following packages have unmet dependencies: libpcp-pmda-perl : Depends: perlapi-5.18.2 but it is not installable E: Unable to correct problems, you have held broken packages. Oh, I have an outdated perl installation here - have upgraded it now, will be fixed by the next upload. Thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752171: Debian Bug #752171
Hi Xilin, Thanks for the fix! I wont have a chance to upload for another two weeks, so please go ahead with the pcp-3.9.6+nmu1 NMU shown in your patch. I'll ensure your patch is also included in pcp-3.9.7. Thanks again. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746994: Same bug on my box
- Original Message - Hi, I see this ps error too on my box, version 3.9.4. Can it be overcome to try building until 3.9.5 is out? I suspect there are issues with make 4.0 too. The fix is in git://git.performancecopilot.org/pcp dev branch - it would be great if you could use that and confirm the fix? pcp-3.9.5 will be released and uploaded next week, so the wait shouldn't be too long now. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749462: [pcp] Bug#749462: pcp-gui-testsuite: not installable in sid
Hi Ralf, - Original Message - Package: pcp-gui-testsuite Version: 1.5.13 Severity: serious User: trei...@debian.org Usertags: edos-outdated Hi, pcp-gui-testsuite is no longer installable in sid as it depends on pcp-gui (= 1.5.13). Since pcp-gui moved into the pcp source package we have pcp-gui version 3.9.4 in sid. Shouldn't the pcp-gui-testsuite package be removed from sid (or rather the whole pcp-gui source package)? Yep, the whole pcp-gui source package should be removed - just looking into how to do that. thanks. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746996: pcp ships an upstream binary without rebuilding it
- Original Message - On Thu, May 15, 2014 at 11:41:36PM -0400, Nathan Scott wrote: Hi Aurelien, | On i386, pcp ships the upstream binary src/pmdas/mmv/mmvdump into | /var/lib/pcp/pmdas/mmv/mmvdump without rebuilding it. This violates | Debian policy and might be used by upstream to introduce backdoors or | other security issues. What gives that impression? It seems to not be the case to me, there is clearly code, makefile and no binary in the source tar ball... $ tar tzf ~/SOURCES/pcp-3.9.2.src.tar.gz | grep mmvdump pcp-3.9.2/src/pmdas/mmv/mmvdump.c You are looking at the upstream tarball. Given you repackage it (which probably warrants another bug report), you include some additionbal binaries. *nod* - before 3.9.4 this was sort-of the case (the source tarball is generated during the build from makefiles) and this is now done differently again (3.9.4+), using git to generate the src.tar.gz, but anyway ... ultimately, there was never any intention to ship binaries accidentally this way, and it was accidentally resolved by the git-archive transition in 3.9.4. And confusion on my end resulted from looking at the 3.9.2 source tarball generated from a different build - you are correct. wget http://snapshot.debian.org/archive/debian/20140416T053134Z/pool/main/p/pcp/pcp_3.9.2.tar.xz *nod*, my mistake - and as mentioned, 3.9.4 has kindly fixed this up for us as a by-product of other changes. Of course, this has silently been fixed in version 3.9.4 without any mention in the changelog. *nod* - it was not a known issue at that time. Hope this helps sort things out; I guess at the end of the day, on this bug at least, alls well that ends well. thanks Aurelien. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746994: pcp: FTBFS with systemd: FATAL ERROR: could not determine how to get the all processes with arguments
Hi Aurelien, - Original Message - The configure script tries to find systemd in /bin/systemd, while ps -ef show a different path: $ ps -ef | grep systemd root 1 0 0 avril30 ? 00:00:01 /lib/systemd/systemd --system --deserialize 22 Ah, there's that information I was looking for - thanks! I don't run systemd on my primary machine yet, so had been looking here as a poor source of second-hand information: https://packages.debian.org/sid/amd64/systemd/filelist ... which fooled me into thinking we're doing the same thing as Fedora with the /bin/systemd listed there. I am therefore reopening the bug. Thanks! Will address this in pcp-3.9.5 shortly - sorry about closing prematurely, I thought you'd lost interest / found the source of that incorrectly-suspected-misconfiguration when I didn't hear back before. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749556: RM: pcp-gui -- NVIU; Superceded by pcp-3.9.4 which has a pcp-gui subpackage
Package: ftp.debian.org Severity: normal Hi folks, pcp-3.9.4 has included the sources for pcp-gui, and builds the pcp-gui as a sub-package along with several others. Thus the source for the pre-existing, separate package pcp-gui(-1.5.13) in unstable would ideally be removed at this point. Many thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-rt-686-pae (SMP w/2 CPU cores; PREEMPT) 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749462: [pcp] Bug#749462: Bug#749462: pcp-gui-testsuite: not installable in sid
- Original Message - [...] it ususally should happen automatically, but it probably didn't in this case since pcp-gui-testsuite isn't provided by the pcp source package. See [1] for how to request removals. Thanks Ralf, bug #749556 has been opened for the ftpmasters. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746996: pcp ships an upstream binary without rebuilding it
Hi Aurelien, | On i386, pcp ships the upstream binary src/pmdas/mmv/mmvdump into | /var/lib/pcp/pmdas/mmv/mmvdump without rebuilding it. This violates | Debian policy and might be used by upstream to introduce backdoors or | other security issues. What gives that impression? It seems to not be the case to me, there is clearly code, makefile and no binary in the source tar ball... $ tar tzf ~/SOURCES/pcp-3.9.2.src.tar.gz | grep mmvdump pcp-3.9.2/src/pmdas/mmv/mmvdump.c ? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746994: FTBFS with systemd: FATAL ERROR: could not determine how to get the all processes with arguments
Hi, The configure script does appear to look at /bin/systemd when ps -ef is used ... can you send me the output from ps -ef from this system? (privately if you prefer, it might contain confidential info not for the bts). Thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747080: xfsprogs: new upstream release (2013-05-08 v3.1.11)
- Original Message - Package: xfsprogs Version: 3.1.9 Severity: wishlist Hello there, please consider updating the package to the newest upstream release, see Hi Flo, There is a pending xfsprogs-3.2.0 release - I've been working on ensuring the build and packaging and clean there. I'm planning to upload that right after its released, which I'm led to believe is just days away. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747079: xfsdump: new upstream release (2013-05-08 v3.1.3)
- Original Message - Package: xfsdump Version: 3.1.1 Severity: wishlist Hello there, please consider updating the package to the newest upstream release, see I have one debian-specific patch to get merged and then hope to convince the XFS folks to make a new xfsdump release shortly thereafter, and then upload that one. Thanks for the reminder note, Florian. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739952: [pcp] Bug#739952: missing license in debian/copyright
Thanks Thorsten, - Original Message - [...] please add the missing MIT and BSD licenses of files in pcp-3.9.0/src/pmwebapi/jsdemos/* These are dual licensed under the already documented GPL license used for the rest of this package, so I reasoned (possibly incorrectly?) this was covered. (you should also mention the version of LGPL in debian/copyright) *nod* - thanks, I will update this in the next release. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737340: [pcp] Bug#737340: pcp: use autotools-dev to update config.{sub, guess} for new arches
- Original Message - ... Please use autotools-dev to update config.{sub,guess} for new architectures. ... Thanks for considering the patch. Thanks Logan - merged in. I'll close this bug out when pcp-3.8.13 is released uploaded (the usual release schedule should put that in about four weeks time). cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725627: [pcp] Bug#725627: closed by Nathan Scott nath...@debian.org (Bug#725627: fixed in pcp 3.8.6)
3.8.8 has been uploaded to address this, finally, hopefully. :( cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725627: [pcp] Bug#725627: Still FTBFS
Hi Mathieu, - Original Message - ... -I../../../src/include/pcp -c -o trace.o trace.c trace.c:19:20: fatal error: probes.h: No such file or directory #include probes.h ^ compilation terminated. Please fix this soon as this is preventing ctdb migration in testing. Sorry about that, I had thought it resolved. I have a complete fix a bug-fix update will be uploaded this week after further testing. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725971: xfsprogs: config.guess/config.sub out of date for arm64
Hi Colin, Looks good to me, thanks - will follow up get this merged. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725627: [pcp] Bug#725627: pcp: FTBFS on kfreebsd-*: trace.c:19:20: fatal error: probes.h: No such file or directory
- Original Message - ... Full build logs: https://buildd.debian.org/status/package.php?p=pcpsuite=sid Feel free to contact debian-bsd@ (cc'd) if you need help. Thanks - this is fixed upstream, expected to arrive in pcp-3.8.5 (later this week, hopefully). cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698735: [pcp] Bug#698735: CVE-2012-5530
Hi guys, Coming back to this one after quite some time ... (my apologies!) - Original Message - Only an update... In the security-tracker CVE-2012-5530[1] was marked as no-dsa. This means there will not be a security announce update via stable-security. But could you prepare a fix for it for Squeeze via a stable-proposed-updates? I have finally been able to find resources needed to setup an oldstable machine to appropriately build and test these changes, and have done so now. So, mainly FYI - I'll be following Salvatore's pointer above, and doing an upload as a proposed update to oldstable to resolve this one (stable has since become wheezy and it is unaffected). cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705994: [pcp] Bug#705994: pcp: unowned files after purge (policy 6.8, 10.8): /var/log/pcp/install.log
- Original Message - Hi, during a test with piuparts I noticed your package left unowned files on ... Thanks Andreas - this one is relatively straightforward to address, will do so in the next PCP update. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698735: [pcp] Bug#698735: CVE-2012-5530
Hi, - Original Message - ... Only an update... In the security-tracker CVE-2012-5530[1] was marked as no-dsa. This means there will not be a security announce update via stable-security. But could you prepare a fix for it for Squeeze via a stable-proposed-updates? See [2] for further information on that. [1]: https://security-tracker.debian.org/tracker/CVE-2012-5530 [2]: http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable Does this helps? I'm travelling at the moment with limited net access - will read through the above in ~1 week and see. Thanks for the pointers! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698735: CVE-2012-5530
Hi all, This is not getting any traction in danger of being forgotten - can anyone help out who knows the security update build process? The patches have been prepared, tested, and are ready in the git tree (below) - but I need some help to get it over the line. thanks!! - Original Message - - Original Message - - Original Message - Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5530 for further references. Thanks Moritz; I will work on the squeeze backport over this weekend. An upstream update is planned for next week which I'll use to get the version in unstable updated. I've prepared the squeeze backport, and done sanity testing on a build on my laptop (which is running unstable). Could someone from the security team help me out with details or other assistance on a clean squeeze build? I don't have a spare machine (or much diskspace for new VMs, etc, currently) to do a local squeeze build. The updated sources are at: git://oss.sgi.com/pcp/pcp squeeze Many thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698735: CVE-2012-5530
Hi, - Original Message - - Original Message - Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5530 for further references. Thanks Moritz; I will work on the squeeze backport over this weekend. An upstream update is planned for next week which I'll use to get the version in unstable updated. I've prepared the squeeze backport, and done sanity testing on a build on my laptop (which is running unstable). Could someone from the security team help me out with details or other assistance on a clean squeeze build? I don't have a spare machine (or much diskspace for new VMs, etc, currently) to do a local squeeze build. The updated sources are at: git://oss.sgi.com/pcp/pcp squeeze Many thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698735: CVE-2012-5530
- Original Message - Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5530 for further references. Thanks Moritz; I will work on the squeeze backport over this weekend. An upstream update is planned for next week which I'll use to get the version in unstable updated. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695875: xfsprogs: Build-Depend on libreadline6 rather than libreadline5
Hi there, - Original Message - ... Hello! During development of SprezzOS, I noticed that the xfsprogs package Build-Depends on libreadline-gplv2-dev | libreadline5-dev libreadline5-dev no longer exists in the archive; the current Ayup, that's why the libreadline-gplv2-dev | precedes it. implementation is libreadline6-dev. Please make this change, so that machines with libreadline6-dev installed can build the package. The whole sorry saga is discussed over in bug 553875. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686868: unblock: pcp/3.6.5
Hi guys! - Original Message - Control: tag -1 moreinfo On Thu, Sep 6, 2012 at 22:05:41 +0200, Moritz Muehlenhoff wrote: Package: release.debian.org Severity: normal Hi, please unblock pcp 3.6.5. It fixes several security issues. BTW, there was a comment earlier saying that 3.6.5 only fixes security issues - that's a misunderstanding, I believe. This was a regular PCP minor release, and included those security fixes (just happened to be the next bug-fix point release). I did backport the fixes to squeeze, although I can't offer to do that again (its time consuming, and I don't have spare time atm). Others might prefer that approach, and could take on a similar backport. I wouldn't recommend that approach however, as alot of testing is required ( has been done on 3.6.5). The shlibs information for libpcp-pmda3 needs to be updated for the new pmdaEventNewActiveQueue function. Strictly speaking that is certainly correct, and should be fixed in a future PCP update. However, this NewActiveQueue function is for a special/experimental use-case. From the changelog: - ... - Added an interface to allow PMDAs to register event queues with existing clients (pmdaEventNewActiveQueue). - Initial version of the (experimental) bash tracing PMDA. This bash tracing PMDA is the only code using that interface, and it is a new, experimental PMDA (only optional to use). So, if you're looking for a maintainer opinion, my preference is to go with 3.6.5 as is. A separate bug should be opened for the new symbol shlibs issue (a patch would be lovely too ;) Thanks for following up on this Moritz, it'd completely fallen off my radar. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689552: restrict is a keyword in C99
- Original Message - src/pmdas/logger/event.c, function event_config, uses restrict as a variable name. This collides with the fact that in C99 restrict is a keyword. Compilers that default to C99-mode, or gcc -std=c99, fail to compile this code. Thanks Michael, good timing too - we'll probably be putting out a PCP release late next week, I'll make sure change this is included. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576257: Exploring the possibility of an l10n upload of xfsdump to fix pending l10n bugs
Hi David, On 1 August 2012 10:18, David Prévot da...@tilapin.org wrote: Hi Nathan, Thanks for your quick answer. No problem, I've forwarded the patch upstream for further review now, with my minor build (makefile) addition and your fixup - all looks good. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678530: marked as done (libpcp-import-perl: uninstallable in sid because of obsolete perl dependency)
Thanks for pushing this through Adam... The following packages have unmet dependencies: libpcp-import-perl : Depends: perlapi-5.12.4 but it is not installable E: Unable to correct problems, you have held broken packages. ... -- Forwarded message -- From: Adam D. Barratt a...@adam-barratt.org.uk To: Touko Korpela touko.korp...@iki.fi, 678530-d...@bugs.debian.org Cc: Date: Sat, 23 Jun 2012 18:55:50 +0100 Subject: Re: Bug#678530: only i386 is broken On Fri, 2012-06-22 at 23:56 +0300, Touko Korpela wrote: Nathan, please fix your build environment. Indeed. It's obviously not unstable, nor even stable as that had perl 5.10. It is in fact unstable, having been apt-get update'd for several years (5?) now. nathans@verge:~$ cat /etc/debian_version wheezy/sid However, it looks like the last major perl update has not been successfully applied somehow ... will look into that fix it up. Sorry Laurent, I thought the original problem was on a different build machine, didn't realise I'd hit it again. I've scheduled it so that the RC fix can migrate, but I'm not particularly impressive at having to do it again. Nah, you *are* impressive - helping out total strangers in need like this - that's awesome, thanks Adam!! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669307: pcp: FTBFS[kfreebsd]: error: dereferencing pointer to incomplete type
Fabulous - thanks Robert!!! That patch will be in pcp-3.6.3 which I'll test upload in the next few days. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669307: pcp: FTBFS[kfreebsd]: error: dereferencing pointer to incomplete type
Hi Robert, On 20 April 2012 05:46, Robert Millan r...@debian.org wrote: tags 669307 patch thanks El 19 d’abril de 2012 20:31, Robert Millan r...@debian.org ha escrit: It's missing indeed. Problem fixed in glibc-bsd SVN (rev 4209). Besides, a few more fixes are needed to build pcp on GNU/kFreeBSD. Please could you forward those upstream? That's merged. For the glibc-bsd commit, will I need an updated Build-Depends line to ensure that the new glibc is present when building pcp? If so, could you suggest a minimum version to depend on there? Thanks! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668701: pcp: this is not a Debian native package
Upstream is downstream and vice-versa. For convenience of the developers, PCP is intentionally packaged in this way. Thanks for taking time to submit the report (and also for the init script failure bug) - we appreciate it. cheers. -- Nathan
Bug#669307: pcp: FTBFS[kfreebsd]: error: dereferencing pointer to incomplete type
Hi, Thanks for reporting the (new) build problem (again), Christoph! freebsd.c: In function 'kmemread_init': freebsd.c:425:10: warning: variable 'sts' set but not used [-Wunused-but-set-variable] freebsd.c: In function 'freebsd_fetchCallBack': freebsd.c:522:35: error: dereferencing pointer to incomplete type freebsd.c:522:50: error: dereferencing pointer to incomplete type freebsd.c:512:13: warning: variable 'i' set but not used [-Wunused-but-set-variable] make[4]: *** [freebsd.o] Error 1 make[3]: *** [default_pcp] Error 2 This package recently acquired some FreeBSD-specific code. I have access to a FreeBSD 8.2 machine, where the code compiles, but on Debian FreeBSD still no joy. I attempted to access one of the Debian kfreebsd boxes, with no luck although I can access other Debian machines. Can anyone give me some pointers on how to get onto a kfreebsd box to check the build issue? Its either a build packaging dependency issue, or more likely somehow the loadavg struct in sys/resource.h is not visible... (perhaps guarded by a macro? not clear, keen to poke around to check though, so I can stop wasting Christophs time) Thanks!! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668671: pcp: FTBFS[kfreebsd]: fatal error: kvm.h: No such file or directory
Hi Christoph, Might be missing libbsd support for that Full build log at https://buildd.debian.org/status/fetch.php?pkg=pcparch=kfreebsd-amd64ver=3.6.1stamp=1334211209 Thanks, yeah looks like a build dependency on libkvm-dev is needed. PCP 3.6.2 is pending, I'll get a new version with this fix uploaded in next few days. cheers. -- Nathan
Bug#654616: still fails on all arches
On 17 January 2012 07:35, Konstantinos Margaritis mar...@genesi-usa.com wrote: reopen 654616 thanks Still fails on all arches. Ugh, I overlooked something - new upload shortly - thanks for letting me know! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654616: pcp-gui: FTBFS on all arches: ./configure: line 4874: /etc/pcp.env: No such file or directory
On 11 January 2012 09:57, Julien Cristau jcris...@debian.org wrote: On Wed, Jan 11, 2012 at 09:51:35 +1100, Nathan Scott wrote: Not 100% sure what you mean ... do you mean rename pcp.conf to something including the library version? Ah, I see - the underlying issue is this doesn't allow multiple versions of libpcp to be installed simultaneously right? Right. Unless you're absolutely sure the ABI will never change, having files in the shared library package whose path isn't tied to the library's SONAME causes pain down the road. I've opened 655440 to track this issue, thanks again. I'll upload the pcp-gui build fix in the morning (separate change), the fix there appears ok so far. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654616: pcp-gui: FTBFS on all arches: ./configure: line 4874: /etc/pcp.env: No such file or directory
Thanks Julien, On 11 January 2012 05:49, Julien Cristau jcris...@debian.org wrote: On Tue, Jan 10, 2012 at 13:32:18 +1100, Nathan Scott wrote: On 10 January 2012 09:19, Julien Cristau jcris...@debian.org wrote: Note that the presence of /etc/pcp.conf in libpcp3 is a RC bug of its own. Oh... hmm ... signficant parts of it (libpcp API) wont work without it though, whats the prefered approach there? I can think of 3 approaches, there may be others... You could fix the library to behave sanely without configuration, There'd be fairly invasive code changes needed to do that, and much diversion from upstream, so can't really see that approach being viable in this case. move pcp.conf to a separate package, That's possibly the best (well, most straightforward to achieve) of the three options. I think. or rename it to something that includes the library version. Not 100% sure what you mean ... do you mean rename pcp.conf to something including the library version? Ah, I see - the underlying issue is this doesn't allow multiple versions of libpcp to be installed simultaneously right? Probably in that order of preference. The same goes for /usr/include/pcp/* btw, that has nothing to do in a shared library package. *nod* ... I need to look into the history of why that was done and what the fallout might be ... but I'm leaning toward your separate package approach as the most direct route to achieving this. Thanks for the tips, -- Nathan
Bug#655440: libpcp3 package mixes library and configuration files
Package: pcp Version: 3.5.11 The way libpcp3 is packaged has the potential to cause problems down the track. In particular, the shared library package contains both the (SONAME versioned) library files and configuration files (pcp.conf, and builddefs/buildrules) in the same package. The problem is if/when we move to a libpcp4 package, this will not be able to be installed at the same time as libpcp3 (which is a major advantage of the Debian shared library packaging, when done correctly). This is because /etc/pcp.conf and some other files will conflict between the packages. Discussion with Julien Cristau (jcris...@debian.org) in the context of bug 654616, where further discussion on this topic can be found, identified three potential ways to address the problem, paraphrased as: 1. make libpcp.so not require pcp.conf (and probably move it to pcp package) 2. create a separate package for the configuration files (these are the core config files - i.e. pcp.conf - and also the builddefs/buildrules files needed by the layered -dev development packages). 3. use SONAME-specific file names in libpcp3 for the config files (/etc/pcp3.conf) This obviously needs to be addressed before any libpcp4 can ever exist. Its not on the immediate horizon, but pcpv4 plans are well underway and it might well be needed in the medium term. Best to tackle it sooner rather than later anyway. In #654616 I lay out a preference for option #2 but I'll seed feedback from other interested / knowledgeable parties before going far down any particular path. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654616: pcp-gui: FTBFS on all arches: ./configure: line 4874: /etc/pcp.env: No such file or directory
On 5 January 2012 11:56, peter green plugw...@p10link.net wrote: tags 654616 +patch thanks Konstantinos Margaritis wrote: pcp-gui FTBFS on all arches, due to broken configure script: More specficially it fails because the configure script fails to find /etc/pcp.env which is provided by package pcp The package builds fine if pcp is installed, please add it to the build-depends or otherwise fix this bug. Thanks guys - preferably we wont have a dependency on pcp, I've cooked up a patch to continue to have a libpcp3 dependency only (via /etc/pcp.conf use, in place of /etc/pcp.env) ... will upload it shortly. cheers. -- Nathan
Bug#654616: pcp-gui: FTBFS on all arches: ./configure: line 4874: /etc/pcp.env: No such file or directory
On 10 January 2012 09:19, Julien Cristau jcris...@debian.org wrote: Note that the presence of /etc/pcp.conf in libpcp3 is a RC bug of its own. Oh... hmm ... signficant parts of it (libpcp API) wont work without it though, whats the prefered approach there? thanks. -- Nathan
Bug#553875: fixed in xfsprogs 3.1.6
Hi, On 15 November 2011 17:18, Aurelien Jarno aurel...@aurel32.net wrote: On Tue, Nov 15, 2011 at 12:00:50PM +1100, Nathan Scott wrote: Hi Aurelien, On 15 November 2011 08:48, Aurelien Jarno aurel...@aurel32.net wrote: This new version basically replaced the build-depends on libreadline-gplv2-dev by a build-depends on libreadline5-dev | libreadline-gplv2-dev Given libreadline5-dev is not in the archive, the package can't be built, It seems to work as expected for me (iow, if either of the two are installed, it proceeds with using the installed package). I tested both variants on latest unstable, so I'm at a loss to explain the failure you're seeing - can you forward the build output showing the issue? The buildd daemons require that the first package of an alternative exists in the archive, which is not the case there. *nod* - right you are - I look after another package which (by sheer good luck) got these the other the way around, correctly, and its building fine. I'll get a patch out for review, and get a new release uploaded soon. Thanks for the tip, Aurelien! cheers. -- Nathan
Bug#553875: fixed in xfsprogs 3.1.6
Hi Aurelien, On 15 November 2011 08:48, Aurelien Jarno aurel...@aurel32.net wrote: This new version basically replaced the build-depends on libreadline-gplv2-dev by a build-depends on libreadline5-dev | libreadline-gplv2-dev Given libreadline5-dev is not in the archive, the package can't be built, It seems to work as expected for me (iow, if either of the two are installed, it proceeds with using the installed package). I tested both variants on latest unstable, so I'm at a loss to explain the failure you're seeing - can you forward the build output showing the issue? Allowing either package to satisfy the dependency means more people have been able to continue to build and use these packages, which helps those users who are not using unstable, so unless its not feasible I'd prefer to leave that option open to them. cheers. -- Nathan
Bug#625961: pcp: FTBFS on the buildds ($HOME not set)
- Original Message - Package: pcp Version: 3.4.0 Severity: serious Justification: fails to build from source See https://buildd.debian.org/status/package.php?p=pcp Thanks Julien - I have a fix, will get it uploaded soon. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618169: pcp-gui: FTBFS: ui_pmchart.h:30:30: fatal error: qassistantclient.h: No such file or directory
- Julien Cristau jcris...@debian.org wrote: qt 4.7 removed libqtassistantclient, so you now need libqtassistantclient-dev. Thanks, I'll get that fixed up. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618169: pcp-gui: FTBFS: ui_pmchart.h:30:30: fatal error: qassistantclient.h: No such file or directory
- Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. ... === chart === === views === make[4]: Nothing to be done for `default'. /usr/bin/qmake-qt4 /usr/bin/make -f Makefile /usr/bin/uic-qt4 aboutdialog.ui -o ui_aboutdialog.h /usr/bin/uic-qt4 chartdialog.ui -o ui_chartdialog.h /usr/bin/uic-qt4 console.ui -o ui_console.h /usr/bin/uic-qt4 exportdialog.ui -o ui_exportdialog.h /usr/bin/uic-qt4 hostdialog.ui -o ui_hostdialog.h /usr/bin/uic-qt4 infodialog.ui -o ui_infodialog.h /usr/bin/uic-qt4 tabdialog.ui -o ui_tabdialog.h /usr/bin/uic-qt4 recorddialog.ui -o ui_recorddialog.h /usr/bin/uic-qt4 settingsdialog.ui -o ui_settingsdialog.h /usr/bin/uic-qt4 pmchart.ui -o ui_pmchart.h /usr/bin/uic-qt4 openviewdialog.ui -o ui_openviewdialog.h /usr/bin/uic-qt4 samplesdialog.ui -o ui_samplesdialog.h /usr/bin/uic-qt4 saveviewdialog.ui -o ui_saveviewdialog.h /usr/bin/uic-qt4 searchdialog.ui -o ui_searchdialog.h /usr/bin/uic-qt4 seealsodialog.ui -o ui_seealsodialog.h g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I../include -I../libqmc -I../libqwt -I. -I. -o console.o console.cpp In file included from pmchart.h:17:0, from console.h:19, from console.cpp:15: ui_pmchart.h:30:30: fatal error: qassistantclient.h: No such file or directory compilation terminated. Hmm, this might be a bug in the sid Qt4 version, and not in pcp-gui ... the ui_pmchart.h file is generated (by uic-qt4 tool, above), so I guess somehow thats not being correctly written wrt the QAssistantClient class. The build dependencies look correct (libqt4-dev) as far as I can tell. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567102:
- Olaf van der Spek olafvds...@gmail.com wrote: Anibal? Nathan? I added a comment to the bug last week ... not sure what more you're looking for here? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567102: Get acl installed and usable by default
Hi Olaf, OK, you have reported two things: | Could FS ACLs be enabled (acl package installed, This is not my call, and not a bug in the ACL package ... and I'm not sure who determines what packages are essential and always installed ... perhaps a query to the installer folks? | acl option in fstab) | by default (right after standard Debian install))? Some filesystems support ACLs with no options (e.g. XFS), whereas others need special mount options ... you can either choose a filesystem which supports ACLs by default already, or ask the installer team to add this functionality. But, neither are things that the ACL package can help with. | POSIX access control isn't enough anymore (IMO), so it | would be nice to have ACLs available when necessary. I don't know, wont hurt to ask, but I wonder if the installer team will consider that sufficient justification. Anyway, these things cannot be addressed by the acl package, I'm afraid... hence, your original report fell by the wayside (my bad, shoulda replied earlier to set expectations for you). cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598908: xfs_growfs: -I is an option in the help but if used Invalid Option is returned
Hi there, I have a 45 TB disk but with the kernel for amd64 is not possible to increase it to 55 TB through xfs_growfs; It should be possible, that's more a small-medium sized filesystem for XFS, I guess - far larger sizes are supported and actively used on x86_64 ... so, this should work. when i tried to use the -I I got the message invalid option from xfs_growfs but --help report it like a valid option. Could you paste the exact command line invocation and message please? Also, could you include cat /proc/partitions and cat /proc/mounts with that please? Also, are you using a 32 bit userspace? (output from file /usr/sbin/growfs and ldd /usr/sbin/growfs will help us answer that question). Thanks! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590240: acl: Please move binaries to /bin (from /usr/bin)
- Anibal Monsalve Salazar ani...@debian.org wrote: On Sat, Aug 07, 2010 at 08:42:14AM +1000, Nathan Scott wrote: Still, would prefer to hear from Anibal... yoohoo, Anibal? I've been away from home during the last week (DebConf in New York City) and this week (LinuxCon in Boston). No worries mate - good to hear from you! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590240: acl: Please move binaries to /bin (from /usr/bin)
- Julien BLACHE jbla...@debian.org wrote: Nathan Scott nath...@aconex.com wrote: Hi Nathan, I tend to think this will be the simplest way to fix it, like you, just need to sort out where Anibal is at... Anibal? Just a thought, not knowing what you did for the move to /bin: you may want to keep symlinks in /usr/bin so as to not break anything that would use the absolute path. Yep, the patch does that. Still haven't heard from Anibal. I'm unlikely to get any time this weekend to look at it, but may have to try to merge in all his stuff if I don't hear anything soon... should have some time next week. Still, would prefer to hear from Anibal... yoohoo, Anibal? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590240: acl: Please move binaries to /bin (from /usr/bin)
- Julien BLACHE jbla...@debian.org wrote: Nathan Scott nath...@aconex.com wrote: Hi Nathan, Actually, the shared libraries are already there - so, amend that question to are you thinking we should be moving all of chacl, getfacl, setfacl, attr, getfattr, setfattr? Just checking the status of this request, as I need to come up with a solution for Squeeze. If you're not going to move the ACL binaries, I'm going to have to come up with something else, like shipping a helper in /lib inside libsane to basically replace setfacl. I'd rather not rush that in just before the freeze if I can avoid it :/ Hi Julien, I was planning to fix it. The acl/attr packages are in a slightly funny state, in that they have been uploaded by Anibal several times since my last, and he's managing patches completely differently to me ... some issues to sort out there. I sent Anibal a patch to make these binaries end up in the root fs, but haven't heard back from him yet. I tend to think this will be the simplest way to fix it, like you, just need to sort out where Anibal is at... Anibal? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590240: acl: Please move binaries to /bin (from /usr/bin)
- nath...@aconex.com wrote: - Julien BLACHE jbla...@debian.org wrote: happens very early during boot, I can't apply this fix until/unless the ACL utilities are moved to /bin. Are you advocating moving all of: libacl.so, libattr.so, chacl, getfacl, setfacl, attr, getfattr, and setfattr? Actually, the shared libraries are already there - so, amend that question to are you thinking we should be moving all of chacl, getfacl, setfacl, attr, getfattr, setfattr? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559490: xfsdump: fsr creates files mode 666
- Justin T Pryzby justinpry...@users.sourceforge.net wrote: Package: xfsdump Version: 2.2.48-1 Tags: security Looks like this: 127176340 drwxrwxrwx 2 root root6 Sep 21 09:40 /var/.fsr/ag0 Thanks, have begun discussions with upstream as to affects of this. Did you run that ls as root? What permissions do you see on the /var/.fsr (parent) directory? cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552577: Package kmchart has been removed from Debian
- Simon Olofsson si...@olofsson.de wrote: Nathan, Marco, thanks for your explanations. I just saw that this package is now only available via debports. I don't think this was the case, when I filed the bug, so I didn't really notice, that this package was removed. Hi Simon, Yes, this has only just been removed from the archive (your report prompted me to get onto it - thanks). I believe your patch has been incorporated into the kmchart replacement package, pcp-gui - if that turns out not to be the case (I'm certain it is though), please let me know. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552577: kmchart: FTBFS with GCC 4.4 and eglibc 2.10
Thanks Simon. A while ago, the kmchart package was renamed to pcp-gui. This fix has been applied there awhile back too. I guess I need to figure out how to properly mark a package as deprecated in the Debian archive - not too sure whats involved there though. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552808: ftp.debian.org: Please remove kmchart from the archive
Package: ftp.debian.org Severity: normal Please remove the package kmchart from the archive. It has been (long since) replaced by the newer pcp-gui package and nothing else should be referencing it anymore. Many thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544350: pcp: Missing runlevels and dependencies in init.d scripts
- Petter Reinholdtsen p...@hungry.com wrote: [Nathan Scott] and the package fail to install in unstable now. Can you describe this in more detail? It installs OK for me... I must be missing something, of course - what is no longer functional? Sure. Without any runlevel listed in Default-*, there is no start or stop symlinks set in /etc/rc?.d/, and the package fail to start as it should during boot. This is the status after installation in a sid chroot: # ls -l /etc/rc?.d/*pcp /etc/rc?.d/*pmie /etc/rc?.d/*pmproxy ls: cannot access /etc/rc?.d/*pcp: No such file or directory ls: cannot access /etc/rc?.d/*pmie: No such file or directory ls: cannot access /etc/rc?.d/*pmproxy: No such file or directory # Note that RedHat/SuSe and Debian have different runleve defaults. Debian have identical setting for runlevels 2-5, while RedHat/Suse do not start the network services in runlevel 2 (and 4?). In Fedora, they are requesting that no daemons be started unless they are absolutely critical, and it becomes opt-in for the administrator, always except in the case of core functionality (or some I'm told). For PCP we have several daemons in the one package (as you see above in that ls output) and depending on the deployment, maybe some should be enabled, and maybe some not ... its not necessarily a bad thing to leave that choice up to the administrator, in the end, for PCP. Is there any downside (other than not auto-starting in boot) to not having Default run levels set in the script? Is it required / policy to do so? I couldn't find docs that suggest that is/isn't the case anywhere. I couldn't find where in the developers reference / policy doc / ... that these fields are explained in detail - can you point me to the right place to read further as to what is required of Debian packages here? The best documentation is currently at URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot and URL:http://wiki.debian.org/LSBInitScripts. Ah, great. Thanks! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544350: pcp: Missing runlevels and dependencies in init.d scripts
Hi Petter, - Petter Reinholdtsen p...@hungry.com wrote: ... [Nathan Scott] Thanks Petter, your patch looks fine to me. I'll merge it upstream and get it into the next PCP release (hopefully later this week). The new version 3.0.0 introduced broken headers. There are no runlevels listed in the Default-* headers, This change was made by the Fedora packagers recently. Hmmm. and the package fail to install in unstable now. Can you describe this in more detail? It installs OK for me... I must be missing something, of course - what is no longer functional? I couldn't find where in the developers reference / policy doc / ... that these fields are explained in detail - can you point me to the right place to read further as to what is required of Debian packages here? Thanks for the heads-up all the help! cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545851: pcp: FTBFS: pmns.c:1459: error: incompatible types in assignment
Hi Kurt, - Kurt Roeckx k...@roeckx.be wrote: ... albeniz.debian.org is the porter box, and seems to be working fine. I finally got some time to get onto that machine - I have a fixed version of pcp now for Alpha. Theres a pcp-3.0.0 release due out in a few days, so I'll merge the patch and get that version into the archive once its released. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#290874: libacl1: libacl NFSv4 support
- Roger Leigh rle...@debian.org wrote: Package: libacl1 Version: 2.2.47-2 Followup-For: Bug #290874 Hi, Has any further progress been made on merging NFSv4 ACL support into libacl? I've seen no further discussion of this anywhere, incl. on the acl mailing list... so AFAIK the answer is no progress. cheers. -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545851: pcp: FTBFS: pmns.c:1459: error: incompatible types in assignment
Hi Kurt, - Kurt Roeckx k...@roeckx.be wrote: Source: pcp Version: 2.9.2 Severity: important ... There was an error while trying to autobuild your package: Ugh - I made an attempt to fix this in the last upload, looks like it wasn't quite right. The build for this package only fails on Alpha, and it must have something unusual in its bits/stat.h header - do you know if theres a machine I (nath...@debian.org) can get access to, to try figure this out? I had a look on the machines web page a little while back, but the Alphas all seemed to have restricted access? thanks! -- Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org