Bug#909231: "lexical" taperscan in Amanda 3.5 ignores tapes' pool assignment
Package: amanda-common Version: 1:3.5-1 The lexical taperscan algorithm is supposed to select the next volume to use based on the lexical ordering of volume labels, but as implemented in Amanda v3.5 it does not properly restrict the volume labels being processed to those from the tape pool in question. If multiple tape pools are in use in a particular configuration, this will cause the last-used volume in one pool to unexpectedly affect the next volume selected for use in another pool. A patch to correct this bug was posted to the amanda-hackers list in From: Jean-Louis Martineau Subject: Re: lexical.pm last_use_label ignores "storage" field on tapelist Date: Mon, 12 Mar 2018 14:49:02 + Message-ID: https://marc.info/?l=amanda-hackers=152086658119204=2 I applied the patch locally and confirmed it solve the problem for me, but it was never included in an official Amanda release. Since upstream maintenance of Amanda seems to be paused at the moment, it might be worth including this fix as a debian/patch in the Debian Amanda package. Nathan
Bug#891757: package's /etc/udhcpd.conf still mentions obsolete "remaining" option
On Wed, Feb 28, 2018 at 10:36:46 -0500, Nathan Stratton Treadway wrote: > (Comparing those two files quickly I don't see any other obsolete option > still listed in the Debian /etc/udhcpd.conf file.) Actually, looking a little more closely it seems that this Debian-specific file was copied (essentially unchanged) from the upstream "examples" version of the file shortly before the above-mentioned commit 2b0e95780863da44f6a9244699ece8620a599e19, and it hasn't been updated since. So perhaps it would make sense just to distribute the upstream version as Debian's /etc/udhcpd.conf rather than having a separate copy? = $ git diff 2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf HEAD:debian/tree/udhcpd/etc/udhcpd.conf | cat diff --git a/2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf b/HEAD:debian/tree/udhcpd/etc/udhcpd.conf index 8c9a968..672c481 100644 --- a/2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf +++ b/HEAD:debian/tree/udhcpd/etc/udhcpd.conf @@ -114,7 +114,7 @@ option lease 864000 # 10 days of seconds #opt ntpsrv #opt tftp #opt bootfile - +#opt wpad # Static leases map #static_lease 00:60:08:11:CE:4E 192.168.0.54 $ git log debian/tree/udhcpd/etc/udhcpd.conf commit 9f5c542f05969830b28e16d73c2f8af69c742a90 Author: Bastian Blank <wa...@debian.org> Date: Sat Nov 7 18:26:56 2009 + * debian/busybox-syslogd.busybox-klogd.init, debian/busybox-syslogd.default, debian/busybox-syslogd.init, debian/busybox-syslogd.links, debian/udhcpc.install, debian/udhcpc.links, debian/udhcpd.install, debian/udhcpd.links: Add. * debian/config/deb, debian/config/static: Enable FEATURE_PIDFILE- * debian/control: Add new binary packages. * debian/copyright: Fix typo. * debian/rules: Build new binary packages. * debian/tree/udhcpc, debian/tree/udhcpd: Add trees. r61201 = Nathan
Bug#891757: package's /etc/udhcpd.conf still mentions obsolete "remaining" option
Package: udhcpd Version: 1:1.27.2-2 I noticed that the copy of /etc/udhcpd.conf installed by the udhcpd package includes a section describing the "remaining" option: = # If remaining is true (default), udhcpd will store the time # remaining for each lease in the udhcpd leases file. This is # for embedded systems that cannot keep time between reboots. # If you set remaining to no, the absolute time that the lease # expires at will be stored in the dhcpd.leases file. #remaining yes #default: yes = However, this option was actually removed from the udhcpd program many years ago, in commit 0416e3dde17ea9295635c52183b30fe3d7172333 (See, e.g.: https://git.busybox.net/busybox/commit?id=0416e3dde17ea9295635c52183b30fe3d7172333 or https://anonscm.debian.org/cgit/d-i/busybox.git/commit/?id=0416e3dde17ea9295635c52183b30fe3d7172333 ), and from the examples/udhcp/udhcpd.conf file in the upstream source in commit 2b0e95780863da44f6a9244699ece8620a599e19 . (Comparing those two files quickly I don't see any other obsolete option still listed in the Debian /etc/udhcpd.conf file.) Nathan
Bug#775612: amanda-server: Depends on Tie/StdHash.pm which exists on NO package in debian
> This seems to be yet another occurrence of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781120 -- handling > of non-readable directories on @INC Just to pull together the various strands of this discussion: the issue is that no StdHash.pm file actually exists, but Perl don't know that ahead of time and has to search through @INC looking for it -- and (since @INC ends with a "." entry) if the . directory happens to be unreadable by the current user, Perl aborts that search with an error. On the other hand, if all directories in @INC are readable, then Perl completes the search without finding StdHash.pm anywhere (but also without raising an error), and falls back to the definition of the Tie::StdHash package contained within the Hash.pm file. (For what it's worth, the discussion about why Perl [v5.18 and later] aborts with an error if a path in @INC is unreadable can be found in Perl bug #113422 and the various bugs associated with it: https://rt.perl.org/Public/Bug/Display.html?id=113422 ) Anyway, Amanda upstream has recently implemented a workaround for this situation, as mentioned on the amanda-hackers list: Subject:Re: "./Tie/StdHash.pm: Permission denied at" error messages From: Jean-Louis Martineau Date: 2017-07-19 12:16:04 http://marc.info/?l=amanda-hackers=150046696903634=2 The two-line patch in question can be found at, e.g.: https://github.com/zmanda/amanda/commit/9f390065b6eb27a79ea273295065890925f1659a Nathan
Bug#795025: systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5
On Tue, Sep 15, 2015 at 15:16:30 -0400, Alain Choquet wrote:
> The error in systemd log is not caused by the APM option itself but by the
> failed attempt by hdparm to write output messages to a non existent output.
> On my system a command in /lib/udev/hdparm expands to
>
> /sbin/hdparm -B254 -q -S119 /dev/sdg
>
Actually, I believe the error does come from the APM option itself
At least for hdparm version 9.48+ds-1, the line in /lib/udev/hdparm that
calls the hdparm binary is:
/sbin/hdparm $OPTIONS $DEVNAME 2>/dev/null
If I try this style of command on the command line and then look at the
exit code, doing a query ("-B") returns a status of 0, but trying to set
the value returns a status of 5:
# hdparm -B /dev/sdb 2>/dev/null ; echo "ret: $?"
/dev/sdd:
APM_level = not supported
ret: 0
# hdparm -B254 /dev/sdd 2>/dev/null ; echo "ret: $?"
/dev/sdd:
setting Advanced Power Management level to 0xfe (254)
APM_level = not supported
ret: 5
Since the /lib/udev/hdparm script runs with "set -e", as soon
as hdparm exits with a status of 5, the entire script does so as well
(thus generating the error that appears in the systemd journal file).
Nathan
Bug#795025: Spoke too soon
On Sat, Aug 22, 2015 at 08:35:00 -0400, Dominique Brazziel wrote:
> The error still exists here even after specifying
> '-B 255' because this WD Caviar drive does not
> support APM. I'll let upstream handle this.
I found that I could avoid the error by giving a blank "apm" value in
hdparm.conf, i.e.
/dev/sdb {
apm =
}
This causes the udev script to run "hdparm -B /dev/sdb", which simply
prints (to stdout) a message with the current APM level and thus avoids
causing the drive to return an error status when hdparm tries to
change/set the APM level
Nathan
Bug#845597: shorewall: Shorewall doesn't start at the system boot
On Fri, Dec 09, 2016 at 14:41:27 -0500, Nathan Stratton Treadway wrote: > I have only worked with this under Ubuntu (not Debian per se), but I > believe the issue you are seeing is that the Shorewall documentation has > not been updated to reflect the use of systemd instead of the old-style > /etc/init.d/shorewall script. [...]> > To turn on automatic startup of shorewall under systemd, you need to > "enable" the service: > # systemctl enable shorewall Actually, I found in the Debian changelog: http://metadata.ftp-master.debian.org/changelogs/main/s/shorewall/shorewall_5.0.14.1-1_changelog that (assuming you are in fact using v5.0.14.1-1 as specified in the bug report) the package should now already be enabling itself upon installation: shorewall (5.0.7-1) unstable; urgency=low * New Upstream Version * Enable systemd service on package installation and disable on removal (Ubuntu Xenial has v5.0.4-1, so it doesn't get enabled automatically on installation there.) So, I'm not sure if "systemctl enable shorewall" will fix your problem, but in any case running "systemctl status shorewall" immediately after a reboot may give some indication as to what is going wrong. Nathan
Bug#845597: shorewall: Shorewall doesn't start at the system boot
On Fri, 25 Nov 2016 01:56:54 +0100, Carlo Stemberger wrote: > At the moment all seems to work as expected, with an exception: the > program doesn't start at the system boot; however I can run Shorewall with > both > `# service shorewall start` and `# shorewall start`. > > Please note that I set `startup=1` in `/etc/default/shorewall` as I have only worked with this under Ubuntu (not Debian per se), but I believe the issue you are seeing is that the Shorewall documentation has not been updated to reflect the use of systemd instead of the old-style /etc/init.d/shorewall script. In particular, it was that script which checked for the value of "startup" as set in the /etc/default/shorewall file -- but the shorewall.service file used under systemd does not care about that setting. To turn on automatic startup of shorewall under systemd, you need to "enable" the service: # systemctl enable shorewall The Loaded: line in the output of "systemctl status shorewall" will confirm (with the word "enabled" or "disabled") whether or not the service is set for auto-startup. Note that "service shorewall start" translates to "systemctl start shorewall" under systemd, which starts up Shorewall right then, but doesn't configure it to auto-start at boot time later. Nathan
Bug#796599: false positive for Linux/Ebury - Operation Windigo -> due to now existing 'ssh -G' parameter
For what it's worth, Fedora just released their own fix to this problem, as discussed in: https://bugzilla.redhat.com/show_bug.cgi?id=1234436 (The specific patch they implemented can be found here: http://pkgs.fedoraproject.org/cgit/rpms/chkrootkit.git/commit/?h=f23=82dd537b2fd88850eb4327a80b2c9acb7dbcf2ab ) Ubuntu has LP: #1508248 open on this issue: https://bugs.launchpad.net/debian/+source/chkrootkit/+bug/1508248 Nathan
Bug#825317: bash-completion: Un-escaped "~*" leads to spurious NSS lookups
00-fix_quote_readline_by_ref.patch was introduced in bash-completion v1:2.1-3 as a fix for bug 739835 "filename completion broken with bash 4.3". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835 The patch file was originally pulled from Ubuntu, where it was created to fix two LP bugs: * avoid escaping 1st '~' (LP: #1288314) * avoid quoting if empty, else expansion without args only shows dirs (LP: #1288031) Interestingly, LP: #1288031 includes a comment (#9) saying that this Ubuntu/Debian patch was no longer needed due to upstream Bash fixes, but it's not clear to me whether the same is true for the "unescaped ~*" bug. https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031 Meanwhile, Ubuntu has just released new versions of the bash-completion package, with a patch (15-add_backslash_for_tilde.patch) to the 00-fix_quote_readline_by_ref.patch file to fix the Un-escaped "~*" bug; see: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061 Nathan
Bug#776223: missing documentation of Debian usershare max shares customization
The smb.conf.5 section for max shares currently says: usershare max shares (G) This parameter specifies the number of user defined shares that are allowed to be created by users belonging to the group owning the usershare directory. If set to zero (the default) user defined shares are ignored. Default: usershare max shares = 0 I propose adding below that a paragraph something along these lines: Note: On Debian systems the default value for this parameter is 100. To disable usershares, you can explicitly set it to 0 in your smb.conf file. Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776223: missing documentation of Debian usershare max shares customization
Attached is a suggested patch for the max shares entry in the distributed smb.conf file. Nathan --- smb.conf.ucf-dist_trusty2014-10-28 14:44:30.031106772 -0400 +++ smb.conf_max-share_new 2015-01-25 12:15:00.345729305 -0500 @@ -178,8 +178,9 @@ # Setup usershare options to enable non-root users to share folders # with the net usershare command. -# Maximum number of usershare. 0 (default) means that usershare is disabled. -; usershare max shares = 100 +# Maximum number of usershare. The default setting on Debian systems +# is 100. 0 means that usershare is disabled. +; usershare max shares = 0 # Allow users who've been granted usershare privileges to create # public shares, not just authenticated ones
Bug#776223: missing documentation of Debian usershare max shares customization
Package: samba Version: 2:4.1.6+dfsg-1 I was recently setting up Samba on a file server system running Ubuntu Trusty, and as I was testing out my configuration I was surprised to find error messages similar to process_usershare_file: stat of /var/lib/samba/usershares/test failed. No such file or directory in my Samba logs, since I had not intended to have usershares enabled on that system. I looked closely at my smb.conf file and confirmed that I did not have any active usershare max shares line -- and saw that both the comments in smb.conf itself and the smb.conf man page stated the default setting for that parameter was 0, which should have meant the usershare function was disabled. After further digging, I discovered that usershares are enabled because of the Debian-specific patch file (usershare.patch), which changes the compiled-in default values of max shares to be 100 instead of 0. (This patch which was applied as part of bug #443230, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443230 ) That patch does update the net.8 man page's USERSHARE section to reflect the new behavior, but that information does not seem to be mentioned anywhere in the smb.conf.5 man page or the distributed smb.conf file. (The Trusty versions of the samba packages are derived from Debian's 2:4.1.6+dfsg-1 package, so I am using that version number for this bug report. I manually checked the samba package in the anonscm.debian.org git repo, and both the patch and smb.conf appear to be unchanged since then.) Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776259: samba-common.postinst searches smb.conf for non-existent [cdrom] keyword
Package: samba
Version: 2:4.1.6+dfsg-1
In the past when I upgraded my samba packages, the samba-common.postinst
script automatically copied my locally-defined shares from smb.conf onto
the end of the generated smb.conf.ucf-dist file... but recently I
noticed that's no longer happening.
Looking at the postinst script, I believe the problem is that the code
uses the [cdrom] keyword as a flag for finding the end of the
as-distributed-by-the-package section:
cp /usr/share/samba/smb.conf $NEWFILE
configure_smb_conf $NEWFILE
if [ -e $CONFIG ]; then
sed -e '1,/^[;#[:space:]]*\[cdrom\]/ { d }
1,/^[[:space:]]*\[/ { /^[^[]/d; /^$/d }
' $CONFIG $NEWFILE
fi
... but (as of commit 16c3c21335025) that keyword no longer exists in
the /usr/share/samba/smb.conf template file -- and thus after switching
to an smb.conf file generated from that new template, on later package
upgrades the sed command doesn't find that keyword any more, and
thus no lines get appended at the end of $NEWFILE .
Perhaps it makes sense to introduce a custom, specific comment line for
this purpose? Something like
# START LOCAL SHARE DEFINITIONS
or whatever. (In that case, the postinst script could just copy all
lines after that one from $CONFIG to $NEWFILE.)
Nathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740551: documentation for APT::Periodic::MaxSize v.s. processing in apt.cron.daily
Package: apt Severity: minor Version: 0.9.15.5 Near the top of /etc/cron.daily/apt, the documentation for the MaxSize variable says: # APT::Periodic::MaxSize 0; (new) # - Set maximum size of the cache in MB (0=disable). If the cache #is bigger, cached package files are deleted until the size #requirement is met (the biggest packages will be deleted #first). (This same text is also found in /usr/share/doc/apt/examples/configure-index.gz ) However, later on in the script, starting around line 170, the loop that actually deletes files when MaxSize is non-zero includes the comments reverse-sort by mtime and delete oldest file, and in fact the loop that processes the files goes through them in ls -rt order (This mismatch was true in various Debian versions going back for a while, and still seems to be true in the latest Git: http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=blob;f=debian/apt.cron.daily;hb=HEAD , i.e. http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=blob;f=debian/apt.cron.daily;h=71ac76555f00611973d6f2ffaa9c9277c490efd5;hb=a4a5901577a2b0d72f1c973f036a8198046d937a as of today.) Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705215: logger: logs locally, even when told to write to remote syslog server
I recently ran into this bug, too (on an Ubuntu Precise system, running bsdutils 1:2.20.1-1ubuntu3), and in my investigation discovered that a similar patch has been applied upstream to fix this bug: http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=86248cd28a27bdd9a437e389966b0415e106802e Also, for what it's worth, I realized that because of specifics of the conditionals used in the buggy branches of code one can actually trick the v2.20 logger into sending over UDP by specifying both -n and -u options at the same time: $ logger -n myloghost -u FOO -p local0.info test log message $ echo another test message | logger -n myloghost -u FOO -p local0.info (Specifically, when both options are specified the socket-path given for the -u option is ignored -- but the fact the option is specified triggers logger to go ahead and use the UDP connection set up by the -n option rather than incorrectly going down the builtin syslog routines code path.) Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#356937: /usr/bin/logger: logging to facility kern doesn't work
For what its worth, the man page for logger v2.20.1 includes some warning text about this issue: Valid facility names are: auth, authpriv (for security information of a sensitive nature), cron, daemon, ftp, kern (can't be generated from user process) [...] Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658975: tar -g incremental segfault
I don't have any personal experience with this bug, but according to the following post, it was fixed in tar 1.24: http://lists.gnu.org/archive/html/bug-tar/2012-10/msg00039.html The patch referenced in that message is just one line, and can be found at: http://git.savannah.gnu.org/cgit/tar.git/commit/?id=e21d54e8cd3d8026ad56f90cc6bde831106c2cb9 (If I understand the patch correctly, it appears that the segfault is only triggered when a plain / is included in the list of files to add to the archive) Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651503: rake: dependency on virtual package rdoc pulls in transitional package ruby
On Fri, Dec 09, 2011 at 09:58:57 +0100, Jörg-Volker Peetz wrote: the new dependency on virtual package rdoc pulls in transitional package ruby. On Thu, Jun 07, 2012 at 19:29:58 -0400, Nathan Stratton Treadway wrote: Doing so would presumably help avoid pulling in the ruby v4.8 transitional package by mistake) [Just to clarify the history of this discussion: From version 4.6 up through 4.8, the ruby package was described as a transitional package (and included the note It can safely be removed.), implying one would generally want to avoid installing it However, starting with v4.9 the package is instead described as a default version package -- and thus it does make sense for the rake package to continue to depend on ruby | ruby-interpreter. (That way, installing rake will pull in the currently-designated default Ruby version if there isn't already some ruby-interpreter installed). ] Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651503: rake: dependency on virtual package rdoc pulls in transitional package ruby
the new dependency on virtual package rdoc pulls in transitional package ruby. I'm not sure if this package is to blame. But to me it seems the package rdoc and the versioned packages rdoc1.8 and rdoc1.9.1 are virtual packages provided by the ruby* packages. Therefore, the dependency on ruby | ruby-interpreter should be sufficient. Right... both the ruby1.8 and ruby1.9.1 packages provide rdoc internally, so that separate dependency is probably no longer needed. Alternatively, the dependency could be changed to something along the lines of rdoc | rdoc1.8 | rdoc1.9.1. There is a similar issue with the rubygems dependency, which forces the installation of the rubygems (1.8) package even though the ruby1.9.1 package itself provides rubygems1.9.1. So, perhaps the rake dependency should be changed to rubygems1.8 | rubygems1.9.1 ? Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651503: rake: dependency on virtual package rdoc pulls in transitional package ruby
(On a related note, ruby-interpreter is now provided by all the available ruby1.x packages, so it should probably be safe to drop the ruby half of the rake packages's ruby | ruby-interpreter dependency. Doing so would presumably help avoid pulling in the ruby v4.8 transitional package by mistake) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624391: initscripts: postinst dupes /etc/motd into /etc/motd.tail
On Sat, Apr 30, 2011 at 22:09:22 +1000, Kel Modderman wrote: On Thu, 28 Apr 2011 02:44:15 PM Andrew Pollock wrote: In short, I don't think the postinst should be creating an /etc/motd.tail if one doesn't exist already. I do not completely understand this statement. Do you mean: postinst should never create /etc/motd.tail at all? The code to create the /etc/motd.tail file was added as part of the migration from a static /etc/motd to the one found in /var/run/motd, as mentioned in this changelog entry: sysvinit (2.86.ds1-7) experimental; urgency=low [...] * bootmisc.sh: Shorten motd header (Closes: #340017) * bootmisc.sh: Store dynamic motd in /var/run/ and make /etc/motd a symbolic link. The EDITMOTD variable no longer has any effect; to disable updating of the motd just point the /etc/motd symlink to a static file such as /etc/motd.static. [...] -- Petter Reinholdtsen p...@debian.org Sat, 17 Dec 2005 21:26:03 +0100 Basically, it looks like the idea was that the package postinst script would preserve the existing file's contents into /etc/motd.tail, which would then be used going forward (by bootmisc.sh) to re-generate the /var/run/motd so that it looked like /etc/motd had looked prior to the move. (See http://anonscm.debian.org/viewvc/pkg-sysvinit/sysvinit/trunk/debian/initscripts.postinst?r1=365r2=380 or http://snapshot.debian.org/archive/debian/20051219T00Z/pool/main/s/sysvinit/sysvinit_2.86.ds1-7.diff.gz for the exact changes.) Unfortunately, this logic is still found in the postinst script, and it runs every time the package is upgraded... even if /etc/motd was already converted to a symlink to /var/run/motd on a prior upgrade. I guess this hasn't turned out to be a big issue on Debian systems because of the way the motd file generally gets used on those systems -- but even so, it seems like there's really no point for the postinst script to still be attempting this /etc/motd - /etc/motd.tail migration processs these days I'd be happy to look at/apply a patch if you could please whip one up? The simplest patch just removes the motd.tail logic completely (attached). (You can find patches implementing a couple other approaches attached to LP #659738: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/659738 , but off hand I don't see a compelling reason to use those over the simple patch in the Debian package) Nathan --- initscripts.postinst2011-06-08 10:44:48.0 -0400 +++ initscripts.postinst_no_motd-tail 2011-06-08 10:47:10.0 -0400 @@ -288,14 +288,6 @@ # # Set up motd stuff, putting variable file in /var/run/ # -if [ ! -f /etc/motd.tail ] -then - if [ -f /etc/motd ] - then - sed 1d /etc/motd /etc/motd.tail - [ -s /etc/motd.tail ] || rm -f /etc/motd.tail - fi -fi if [ ! -f /var/run/motd ] then if [ -f /etc/motd ]
Bug#403213: Trouble with SSL and certificates
On Tue, Dec 21, 2010 at 17:13:27 +0100, Nirgal Vourgère wrote: Support for TLS_CACERTDIR has been broken. See bug 513270 I had a simmilar problem. Using an explicit TLS_CACERT with the specific crt/pem file works around. Note that as it copies certificates into the /etc/ssl/certs directory, the update-ca-certificates command also creates a single large file /etc/ssl/certs/ca-certificates.crt containing copies of all of those certificates. Thus the OP may be able to use the line TLS_CACERT /etc/ssl/certs/ca-certificates.crt in place of the original TLS_CACERTDIR /etc/ssl/certs line to achieve the goal of having the LDAP clients validate successfully against servers using certificates issued by both his own own root CA and by proper CA certs. (The update-ca-certificates command is included in the ca-certificates package, and is called automatically by that package's postinst script [but can be run manually as well; see the man page for more info].) Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506786: dosfstools: dosfslabel does not seem to set the label correctly
On Mon, Nov 24, 2008 at 19:31:30 +, Sam Morris wrote: I've tried running dosfslabel to change the label of a vfat filesystem. This seemed to work: # /sbin/dosfslabel /dev/sda1 sam However, the change was not picked up by HAL. On investigation, it seems that this is because libvolume-id0 still sees the label as 'UDISK 2.0. This sounds like it might be the same problem as the one described by the bug dosfslabel does not set volume label in the right place in the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=503228 For what it's worth, the mlabel command (part of the mtools package) does seem to set both copies of the volume label; you might be able to use mlabel -i /dev/sda1 :: in place of your dosfslabel command above Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540683: libdvdread: debian/copyright file doesn't mention new upstream
Package: libdvdread Severity: minor I noticed that even in the very latest unstable version of this package (I checked both the copyright link from the Package Tracking System page and the Debian git repository), debian/copyright still gives only the Download: URL for the old chalmers.se upstream. Should this file be updated to list the origin of the 4.1.3 version? Nathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526360: vmstat: format of partition lines in /proc/diskstats changed in Linux 2.6.25
Package: procps Version: 1:3.2.7-11 Severity: normal When I run the vmstat command on a machine running Linux 2.6.26, it doesn't properly recognize my disk partitions. Specifically, when I run vmstat -d it includes the partitions in the output, and when I run vmstat -p it can't find the partition: $ vmstat -d | grep hdc hdc12159 2474 472866 32376 1602247 74288 476756 0 54 hdc1 12139 2457 472570 32320 1602247 74288 476756 0 54 $ vmstat -p hdc1 Partition was not found This seems to be caused by the fact that format of the partition lines in the /proc/diskstats file has changed (as of Linux 2.6.25, according to the Documentation/iostats.txt file from 2.6.26). I found a Red Hat bug that covers this issue (and includes a patch): https://bugzilla.redhat.com/show_bug.cgi?id=485243 Thanks. Nathan -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages procps depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip Versions of packages procps recommends: ii psmisc22.6-1 Utilities that use the proc filesy procps suggests no packages. -- no debconf information Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 signature.asc Description: Digital signature
Bug#513243: iftop: top bar still shows bits even when use-bytes/-B is active
Package: iftop Version: 0.17-3 Severity: normal When I use the -B command line option or the use-bytes config-file option, most of the bandwidth rates on the screen change to bytes... but the numbers in the top line of the screen do not. A one-line patch to fix this problem was posted in the Gentoo bug-tracking system: https://bugs.gentoo.org/show_bug.cgi?id=101926 That patch was also reported to the iftop-users list and appears to have been committed to the upstream CVS (but not until after the release of v0.17). http://lists.beasts.org/pipermail/iftop-users/2006-June/thread.html On a related note, the man page description of the max-bandwidth config option should probably be updated to mention that the value specified should always be in bits-per-second (regardless of the use-bytes/-B setting). Thanks. Nathan -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-486 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages iftop depends on: ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii libncurses55.5-5 Shared libraries for terminal hand ii libpcap0.8 0.9.5-1 System interface for user-level pa iftop recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#265501: openssh-client: ServerAliveInterval has the same bug
On Wed, Jan 24, 2007 at 10:34:00AM -0500, xavier renaut wrote: the ssh client apply ServerAliveInterval to all hosts, even if it's host specific : my .ssh/config : Host baba.8d.com ServerAliveInterval 5 Host * ServerAliveInterval 0 I ran into this problem, too, and discovered that it was reported upstream as Buzilla Bug #1275 Config parsing (parse_time) in Host: context acts globally: https://bugzilla.mindrot.org/show_bug.cgi?id=1275 That bug is marked FIXED, and the release notes for the upstream OpenSSH 4.6 http://www.openssh.com/txt/release-4.6 includes this comment: - Parsing of time values in Match blocks was incorrectly applied to the global configuration (bugzilla #1275) , so presumably this bug is resolved as of that version. (However, I am not running Lenny yet so I am not able to confirm this with an actual test.) Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#273577: raidutils: shared memory leak in raidutil
On Mon, Sep 27, 2004 at 11:21:51AM +1000, Phil Homewood wrote:
raidutil -d0 -e status leaks a shared memory segment each
time it's invoked, as verified with ipcs(8). Seems to only
be the status command that does it.
I saw this behavior, too (with 0.0.6-4). Not only was the shared memory
segment still allocated after raidutil finished, but the raideng
process that raidutil spawns was also left running indefinitely (I had
to kill it by hand).
It turned out that the code path for handling the -e option wasn't
cleaning up properly, and so the library that handles the connections
to the raideng process didn't shut down the link when it normally
would have (because it thought the link was still in use).
Attached is the one-line patch that seems to have fixed these problems
on my local machine.
Nathan
Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region
Ray Ontko Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
--- deborig-0.0.6-4/raidutils-0.0.6/raidutil/parser.cpp 2004-04-29 05:20:12.0 -0500
+++ deblocal-0.0.6-4/raidutils-0.0.6/raidutil/parser.cpp 2008-02-01 14:30:03.556385238 -0500
@@ -730,6 +730,7 @@
{
EventLog *temp = new EventLog (components, eventLogOpts);
cmd_List-add_Item (*temp);
+ delete temp;
}
else
Error_in_Parsing(EventStrings[STR_PARSE_ERR_MUST_SPECIFY_ADDRESS], this_Commands_Text);
@@ -1645,7 +1646,7 @@
temp = new NvramBit (Cache_Stale, params.hba_Num, temp_set);
else
temp = new NvramBit (Cache_Stale, -1, temp_set);
-cmd_List-add_Item (*temp);
+cmd_List-add_Item (*temp);
delete temp;
}
else if (!strncmp(command_Line, +cluster, strlen(cluster)))
signature.asc
Description: Digital signature
Bug#332229: raidutils _osdStartCp/DPTI_startEataCp segfault
I noticed that that Anders and Dimitrij both posted information about a segfault that occurs after an _osdStartCp message is printed in the output from raideng /VERBOSE. This is definitely a different situation than the segfault that I was trying to fix with my osd_unix.cpp patch, and so I'm thinking it might make sense to separate this DPTI_startEataCp issue into a second Debian bug. Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 signature.asc Description: Digital signature
Bug#332229: patch to fix raidutils (raideng) segfault
We recently upgraded a server with an Adaptec 2100S card to Linux 2.6.18 (i686 architecture). After the upgrade we started getting segfaults from the raideng program, identical to the problem described in bug #332229. To make a long story short, after some debugging I was able to track down the problem to a bug in the upstream raidutil source code. Specifically, the bug in question was triggered under the following conditions: * using the i2o_* modules (instead of dtp_i2o) * the i2o_config module is loaded (and /dev/i2octl exists) * using the raidutils Debian package, version 0.0.6-3 or 0.0.6-3.2 . The symptoms of this particular problem are: * after kicking off raidutil -L all, there is about a 10-second delay, and then the error message Engine connect failed: Open * running raideng /VERBOSE does not produce _any_ output other than the Segmentation fault error. * running strace raideng shows the following steps (at the bottom of the trace) 1a) successful open of /dev/i2octl 1b) I2OGETIOPS ioctl call on the i2octl file handle 1c) close of i2octl file handle 2) unsuccessful attempts to open /dev/dti0 through dtpi17 3) --- SIGSEGV (Segmentation fault) @ 0 (0) --- It turns out that is the ioctl call in 1b) that caused the problem. The program was passing in a pointer to an int variable, but the I2OGETIOPS ioctl actually expects a pointer to a (largish) data buffer, and thus the program's stack frame gets clobbered when the ioctl routine runs. The program proceeds to look for the old-style device names (step 2) , but then segfaults when that function exits and the return address stored in the stack is zero (step 3). As far as I can tell, the rpm package that people have been able to run successfully also has the same bug, but I guess some difference in the compilation environment there meant that the stack-clobbering didn't consistently trigger a segfault as it did with the Debian binary. However, if I understand the workings of the I2OGETIOPS ioctl correctly, I think the Red Hat version (or any other based on that original source) would not work correctly on machines that have more than one I2O adapter installed. (That is, due to the way the I2OGETIOPS data buffer is populated, the fact that the original raideng code is treating data-buffer space as an int variable happens to work if the ioctl reports exactly one active unit, but I don't belive it would work otherwise.) I am attaching a patch against raideng/osd_unix.cpp (from raidutils 0.0.6-3.2) which is my attempt at fixing this problem. I'm not very familiar with the raidutil code and certainly could have missed something, but we've built new Debian packages locally after applying this patch and so far it has worked well for us. I should mention that the first two chunks of the patch (the ones inside the osdIOrequest and osdOpenEngine functions, respectively) are not strictly related to the I2OGETIOPS segfault problem, but I added them to improve the error reporting in situations that raideng can't find any active device files to open. The osdOpenEngine patch causes the program to abort with an error message if no HBAs are found during the program initialization. At least as far as using raideng with the raidutil command, I couldn't see any reason for raideng to keep running in that situation, but I'm not familiar enough with the package to know for sure if there is some other situation where this abort is undesirable On the other hand, the osdIOrequest change simply adds a check to make sure that the given device file was previously found to point to an active HBA before attempting to open that file. Since it doesn't seem likely that the open will work this time if it just failed a second or two earlier (during the initialization pass), I'm fairly confident that this is a safe change. Together, these two changes (or the osdIOrequest change by itself) will prevent people from getting the misleading File /dev/dpti17 Could Not Be Opened message when the actual problem is that the /dev/i2octl file doesn't exist. Anyway, hopefully this patch helps resolve this segfault problem for the other people who have run into it. Nathan p.s. I based my fix on the I2OGETIOPS documentation found in the kernel Documentation/i2o/ioctl file, e.g. http://lxr.linux.no/linux+v2.6.18.5/Documentation/i2o/ioctl#L33 Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 --- deborig/raidutils-0.0.6/raideng/osd_unix.cpp 2008-01-28 14:28:45.0 -0500 +++ deblocal/raidutils-0.0.6/raideng/osd_unix.cpp 2008-01-28 14:21:41.232389361
Bug#413136: raidutils: File /dev/dpti17 Could Not Be Opened
I was looking through the history of bug #413136, and since I just worked through these same issues when trying to get raidutils working on my own machine, I thought I'd post my findings there in case it helps anyone else. There are actually two separate problems getting mixed together in #413136. They both prevent the raidutil command from running successfully, but they have two separate causes. The problem described in the original post was that running a raidutil command produced the following output: osdIOrequest : File /dev/dpti17 Could Not Be Opened Engine connect failed: COMPATIBILITY number This particular message is generated when raideng can't find any valid device files to open. One can get additional confirmation of this by running the command raideng /VERBOSE, which will report osdOpenEngine : date Return = 0 - 0 hbas found The 0 hbas found indicates that the program didn't find any active raid controllers after probing a compiled-in list of device files. Unfortunately, when raideng finds itself in this situation, it doesn't give up and exit, but instead just keeps running and waits until a raidutil process asks it to do something. At that point, raideng then goes out and tries to open the last device file that it probed during the earlier phase (even though the probing phase found that there was not a controller attached to that device file). When this second attempt to open the device file fails, then raideng (finally) aborts, printing the Could Not Be Opened error message. It happens that (under Linux, anyway) the last file probed is /dev/dpti17, and thus that's the file mentioned in the error message. So, to summarize what various people mentioned as part of the history for bug #413136: if you get this error message, you most likely just need to be sure that either /dev/i2octl or /dev/dpti0 exists (depending on whether you are using the i2o_* modules or the dpt_i2o module). (/dev/i2octl is created automatically via udev when the i2o_config module is loaded.) If it still doesn't work, running strace raideng should tell you which device files it's looking for. (Note that in spite of the message printed, you do NOT actually need to have a /dev/dpti17 file [unless you are happen to be using the dpt_i2o module to run 18 raid cards, anyway].) However, for many of us who were using the i2o_* modules, getting past the device-file problem didn't actually allow the raidutil command to work. Instead, the existence of the proper /dev/i2octl caused raideng to open and access that device file... and then segfault. The symptoms for this problem are that raidutil aborts with the message Engine connect failed: Open, and that running raideng /VERBOSE doesn't produce any output at all (other than a Segmentation fault message from the system). This segfault problem is covered by bug #332229, and I just posted a patch there which resolves that problem (at least on our machine). Looking through the history for #413136, I didn't see any issues raised that weren't either related to missing device files or to the raideng segfault-after-finding-the-i2octl-device issue. As far as I could see from the history, all the people who reported a device-file problem were able to get past it (at least far enough to run into the segfault problem). So hopefully if the patch does actually resolve #332229, then bug #413136 can be closed as well Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440161: Adding support for i2o RAID adapters
I noticed the following question from Otavio Salvador in the discussion for bug #440161: I still fail to understand how i2o_block will work for your device if it's not registered for it on pcialias file ... that makes me worry about it. I think the answer to the question is that the i2o_core module also supports the 0x000e class. For example, the modules.pcimap file for our 2.6.18-5-k7 installation includes the following line: i2o_core 0x 0x 0x 0x 0x000e 0x0000 0x0 This matches the I2O class of the Adaptec 2100S card: # lspci -nn [...] 00:0a.1 I2O [0e00]: Adaptec (formerly DPT) SmartRAID V Controller [1044:a501] (rev 02) Earlier in the thread there was a mention that the following two devices were listed in modules.pcimap as being supported by i2o_core: 1044:a511 dpt_i2o i2o_core 8086:1962 i2o_core I believe these two device ids are listed specifically in order support two particular types of cards that don't match the 0x0e00 class: http://i2o.shadowconnect.com/faq.php#promise http://i2o.shadowconnect.com/faq.php#zerochannel [More specifically, for the Promise card the line from modules.pcimap is: # pci module vendor device subvendor subdevice class class_mask driver_data i2o_core 0x8086 0x1962 0x105a 0x 0x 0x 0x0 , and /usr/share/misc/pci.ids lists that vendor/device/subvendor as as: --- 8086 Intel Corp. [...] 1962 80960RM [i960RM Microprocessor] 105a SuperTrak SX6000 I2O CPU --- Similarly, the Zero Channel card reports itself as class 0104, according to lspci -n output included at the bottom of https://www.redhat.com/archives/rhl-beta-list/2004-October/msg01321.html , and so the driver needs to support that specific card by device id. ] Hope this helps. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457338: aptitude-doc-en: incorrect keybindings for PrevPage command in default keybindings table
Package: aptitude-doc-en Version: 0.2.15.9-6bpo3 Severity: minor I noticed that the table of default keybindings in the Aptitude table shows that both NextPage and PrevPage are listed as bound to pagedown,C-f. Presumably, PrevPage should actually be listed as bound to pageup,C-b. I originally found this error in my local HTML documentation installed by aptitude-doc-en 0.2.15, but I also searched for an online copy of version 0.4.10 of the manual and confirmed that it still has the same typo: http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s04s02.html Thanks. Nathan -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401981: cupsys: cupsd.conf no longer has Printcap /var/run/cups/printcap line
Package: cupsys Version: 1.2.7-1 Severity: normal I just upgraded from Sarge to Etch, moving from cupsys 1.1.23-10sarge1 to 1.2.7-1 in the process. I noticed that the /etc/cups/cupsd.conf distributed with 1.2.7-1 no longer includes a Printcap line, and thus CUPS is now putting the printcap file in its default location of /etc/printcap. (The Sarge file includes the line Printcap /var/run/cups/printcap in the distributed cupsd.conf file.) I saw in the changelog.Debian.gz entry from 10 May 2003 that this file was specifically moved to /var/run/cups/printcap in response to bug #187954, but wasn't able to find any changelog.Debian or NEWS.Debian entries mentioning that it was moved back. If the Printcap line was left out of the config file on purpose, it would be helpful to have the reasons for the move explained somewhere. If it wasn't left out on purpose, should the line be added back in? Thanks. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400942: debian-archive-keyring: README could use links to additional information
I noticed that bug #401114 has been filed against the debian-archive-keyring package on this topic. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400935: upgrade-reports: Woody - Sarge upgrade installs debian-archive-keyring before upgrading apt
I noticed that bug #401114 has been filed against the debian-archive-keyring package on this topic. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400942: debian-archive-keyring: README could use links to additional information
On Fri, Dec 01, 2006 at 03:55:49PM -0500, Nathan Stratton Treadway wrote: I noticed that bug #401114 has been filed against the debian-archive-keyring package on this topic. Please ignore the above message; it was sent to the wrong bug. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400935: upgrade-reports: Woody - Sarge upgrade installs debian-archive-keyring before upgrading apt
Package: upgrade-reports Severity: normal When I followed the instructions in the Sarge - Etch release notes and run aptitude upgrade aptitude, that operation also brings in the causes the apt package to be updated as well as installing the new debian-archive-keyring package. However, at least in my case, it installed the keyring package before performing the upgrade on apt... and thus /usr/bin/apt-key didn't exist when the debian-archive-keyring postinst script was run and the new archive keys were not installed into the apt-key trusted key list. This in turn meant that I got a W: There are no public key available for the following key IDs: A70DAF536070D3A1 message every time I ran an aptitute update afterwards. (Once I figured what happened I was able to fix the problem just by running apt-key update manually.) I assume that there is some good reason the debian-archive-keyring package does not already have a dependency on a version of apt that contains apt-key, and I'm not sure if there is some other way to get aptitude to automatically perform the update/install operations in the correct order. If not, it seems like the issue should at least be mentioned in the release notes (probably right there in section 4.4.2 Upgrading aptitude). Thanks. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400942: debian-archive-keyring: README could use links to additional information
Package: debian-archive-keyring Version: 2006.11.22 Severity: wishlist It would be useful if the README file for debian-archive-keyring included a little more information on how the package is supposed' to function and how one can make use of the keys it contains when that doesn't happen. A few examples: * Archive/release keyrings are used by apt versions 0.6 and later; these versions of the apt package contain the the apt-key command. * Normally (i.e. if the apt-key binary is found), the keys contained in the debian-archive-keyring package will be automatically installed into apt's trusted keyring by the package's postinst script. * If the automatic installation of the keys fails, then the user can run apt-key update manually. It might also be worth mentioning the http://wiki.debian.org/SecureApt page. Thanks. Nathan -- System Information: Debian Release: 4.0 Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages debian-archive-keyring depends on: ii gnupg 1.4.5-2GNU privacy guard - a free PGP rep debian-archive-keyring recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321365: popularity-contest: documentation of popcon tags v.s. a vote
On Sun, Mar 26, 2006 at 09:22:11PM +0200, Bill Allombert wrote: The distinction is important, because libraries atime is unreliable due to the use of ldconfig, so libraries are marked NOFILES, but we still want to know about libraries usage, so the use of dependencies allow to make recently used libraries as voted. Makes sense. I will add the following to the FAQ Q) What is considered a 'vote' for a package ? A) A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server. I hope this clear this issue. Yes, that helps a lot. One clarification, though: the popularity-contest report does not contain any package version info, so I'm curious what data the server uses when calculating package dependencies. (For example, does it just use the dependency list for the latest known version of that package in any Debian release? Or does it just use the set of dependencies from one specific release, and ignore packages it finds that aren't in that release? Etc.) Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352244: incorrect description of /etc/smartmontools/run.d/ scripts in README.Debian
Package: smartmontools Version: 5.33+5.34cvs20050802-4 Severity: minor README.Debian states Package Maintainers and users can put script to be run when smartd detects an error into /etc/smartmontools/run.d. The script will receive the errormessage on stdin. See /etc/smartmontools/run.d/10mail as an example. However, 10mail actually pulls the error message text from a file whose name is passed as the first argument (and not from stdin) -- and I see that the error message is specifically saved to this temporary file in /usr/share/smartmontools/smartd-runner . Thanks. Nathan -- Package-specific info: Ouput of /usr/share/bug/smartmontools: # CONFIG_IDE_TASK_IOCTL is not set -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages smartmontools depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 pgphsRL9Ed2K8.pgp Description: PGP signature
Bug#322261: popularity-contest: hints on translating time_t numbers to dates
On Thu, Aug 11, 2005 at 03:14:24PM +0200, Bill Allombert wrote: On Tue, Aug 09, 2005 at 10:07:41PM -0500, Nathan Stratton Treadway wrote: Package: popularity-contest Version: 1.28 Severity: wishlist I was interested in converting the atime and ctime time_t integers found in my popularity contest reports into a human-readable date. I eventually ran across the ctime() function in Python's time module which did the conversion I wanted, but I wasn't able to find any simple command line utility that was able to convert in that direction. (For example, the date command's %s format directive will return the time_t integer for the date being displayed, but the --date= option doesn't seem to let me specify a date using the time_t integer.) IMHO, this should rather be reported as a wishlist to the date utility. You can use date -d $((`date +%s` - $DATE )) seconds ago For what it's worth, I eventually found that the Info documentation for date does contain a page of examples: info coreutiles examples of date That page suggests using the following syntax to do the time_t-to-readable conversion: date -d 1970-01-01 UTC 1139229934 seconds perl -e 'print scalar localtime '$DATE',\n' where $DATE is the the date you want to convert. Also good to know. Thanks. Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322471: remote ntptrace incompatible with ntp-server's default ntp.conf file
Package: ntp-server Version: 1:4.2.0a+stable-2 Severity: wishlist I am in the process of upgrading some machines from Woody to Sarge. After upgrading my internal NTP server and some client machines, I discovered that the ntptrace program on upgraded clients was timing out when attempting to get info about on the internal server. ntptrace worked fine from the internal server itself -- and also on machines running Woody's version the ntp package. After poking around a bit I discovered that the old ntptrace binary has been replaced with a new perl script built on top of the ntpq command, which lead me to realize that the reason ntptrace was failing on client machines was the restrict default [...] noquery line in the default ntp.conf. Adding a restrict line for my internal network with the noquery changed to nomodify in the config file on the internal server allowed ntptrace to work again from the Sarge clients. I think the current restrict default line is a good idea, but it might also be nice to mention somewhere that it prevents ntptrace from working on machines that use this one as server. This could be an additional comment in the sample ntp.conf, or mentioned in /usr/share/doc/ntp/README.Debian.gz, or whatever. (The current ntp.conf does have a comment pointing the reader to the accopt.html file -- but that file doesn't mention ntptrace anywhere, so it still wasn't obvious that the restrict setting was causing the problem) Thanks. Nathan -- System Information: Debian Release: 3.1 Architecture: i386 (i486) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ntp-server depends on: ii ntp1:4.2.0a+stable-2 Network Time Protocol: network uti ii ntp-simple 1:4.2.0a+stable-2 Network Time Protocol: daemon for -- no debconf information Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 pgpvjseKuyZng.pgp Description: PGP signature
Bug#322261: popularity-contest: hints on translating time_t numbers to dates
Package: popularity-contest Version: 1.28 Severity: wishlist I was interested in converting the atime and ctime time_t integers found in my popularity contest reports into a human-readable date. I eventually ran across the ctime() function in Python's time module which did the conversion I wanted, but I wasn't able to find any simple command line utility that was able to convert in that direction. (For example, the date command's %s format directive will return the time_t integer for the date being displayed, but the --date= option doesn't seem to let me specify a date using the time_t integer.) Anyway, if anyone working on the popcon project has found some easy way(s) to convert these numbers, it might be worth mentioning it/them in the documentation somewhere (e.g. in the README along with the description of the atime and ctime fields, or in the FAQ as a new question). Thanks. Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 pgpl5g8AXvGqe.pgp Description: PGP signature
Bug#298760: popularity-contest: Gives inaccurate information when disk is mounted with noatime option
On Thu, Aug 04, 2005 at 04:58:53PM -0500, Nathan Stratton Treadway wrote: A related issue is the case where a program such as integrit updates the atime of all files in /bin and /usr (and elsewhere) each day. [...] So, my point is that if you add special handling for the noatime case, you might want to also handle the atimes are all too close together problem at the same time. For what it's worth, I discovered that a similar problem affected another machine, one that does not run integrit. In this case, it was backing up the system (e.g. to tape) that set all of my atimes to be no older that a few days, and thus all packages are still getted voted. It's clear that there are lots of situations that make the votes inaccurate, so you (popcon-developers) may just decide to leave things as they are. However, it occurs to me that one possible approach is to define a new field in the report header, something like ATIME_STATUS: or whatever. When set to some sort invalid status, this would indicate to the server that this particular report should be included in the installed count but not the vote count, or whatever. In my two situations, the client script would decide to set this flag based on the fact that all the atimes are within a short time span of each other but the ctimes are more spread out. (Obviously the trick to to pick reasonable cutoff values for this calculation...) In the case described by the original submitter, this status could get set based on the existence of a noatime-mounted partition, for example. (Or perhaps even by noticing that dpkg-query, perl-base, etc. had atimes that were clearly too old given that popularity-contest itself uses them) Anyway, something to consider. Thanks. Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 pgpVnERhOFUMe.pgp Description: PGP signature
Bug#298760: popularity-contest: Gives inaccurate information when disk is mounted with noatime option
A related issue is the case where a program such as integrit updates the atime of all files in /bin and /usr (and elsewhere) each day. For example, a popcon submission on one of my systems (a few months ago) looks like: POPULARITY-CONTEST-0 TIME:1108386306 ID:[...] 1108386315 1089347334 grep /bin/egrep 1108386313 1089346922 findutils /usr/bin/find 1108386306 1089347334 shellutils /bin/date 1108386306 1089346951 popularity-contest /usr/sbin/popularity-contest . . . 1108384616 1089346922 netcat /usr/bin/netcat 1108384616 1089346922 ncurses-bin /usr/bin/captoinfo 1108384616 1089346922 joe /usr/bin/jpico 1108384615 1089346921 whiptail /usr/bin/whiptail 0 0 zlib1g NOFILES 0 0 xprt-common NOFILES . . . END-POPULARITY-CONTEST-0 TIME:1108386320 [This submission was generated by the popularity-contest package in Woody (1.3-1.1), but as far as I have been able to find, the issue the issue is still there at least through the Sarge version (1.28).] The issue is that all the atime values fall in a short range (e.g. 1108386315 - 1108384615 = 1700 sec 30 minutes) and occur just before the runtime of popularity-contest itself. So, my point is that if you add special handling for the noatime case, you might want to also handle the atimes are all too close together problem at the same time. (In addition eventually dealing with this situation the program, it would also be nice to know if the popcon maintainers would or would not like to have systems affected by this problem participating in the program. Is it more helpful or harmful for these systems to be included given their bogus vote counts?) Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298760: popularity-contest: Gives inaccurate information when disk is mounted with noatime option
On Thu, Aug 04, 2005 at 04:58:53PM -0500, Nathan Stratton Treadway wrote: The issue is that all the atime values fall in a short range (e.g. 1108386315 - 1108384615 = 1700 sec 30 minutes) and occur just before the runtime of popularity-contest itself. So, my point is that if you add special handling for the noatime case, you might want to also handle the atimes are all too close together problem at the same time. I should have spelled out that the side-effect of this range of atimes is that ALL packages with valid files are considered recently used; none of them ever get tagged as OLD (or anything else; they are left untagged). I guess this situation is the exact opposite of that caused by noatime partitions, which cause packages to get marked as OLD even when they are being used. Nathan Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321365: popularity-contest: documentation of popcon tags v.s. a vote
Package: popularity-contest Version: 1.28 Severity: wishlist I've been noticing the popularity-contest package/project mentioned frequently on Debian mailing lists and similar places, and often those messages mention votes for this or that package. However, when I installed the package myself and looked through the documentation (files in /usr/share/doc/popularity-contest as well as the man page), I didn't see the term vote used or explained anywhere. After looking at http://popcon.debian.org/ as well as the popularity-contest Perl source itself, I am thinking that a package is considered voted if none of the other three tags get applied to it. Assuming this is correct, it might avoid a little confusion for the uninitiated if this fact where explained in the README file (along with the the description of the three possible tag strings). Thanks. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
