Bug#343839: aptitude: segfaults trying to downgrade e2fsprogs
On Sun, Dec 18, 2005 at 09:35:37PM -0800, Daniel Burrows wrote: If your system is still in a state where you can reproduce this, what would be ideal would be to post a bzipped tarfile of the following somewhere (assuming of course that the data are yours to post): - /etc/apt - /var/lib/dpkg/status - /var/lib/aptitude - /var/lib/apt Daniel My system is still in a state where I can easily reproduce the crash. The tar file is here: http://www.speakeasy.org/~nestler/aptitude-bug343839.tar.bz2 The scenario required to reproduce the crash is even simpler now. I have a handful of packages on hold (mozilla-firefox and all of the e2fsprogs binary packages) and I am trying to purge bittorrent and libwine-arts. Nothing is being upgraded, downgraded, or installed. I still get a segfault. The backtrace is hard to paste here because gdb's terminal gets totally messed up when running aptitude inside of it. I assume you can reproduce it. It involves pkgSimulate::Policy::~Policy() which is mentioned in another Bug (343488). However, applying the patch from that bug did not solve the problem. Also, downgrading aptitude to version 0.4.0-5 did not solve the problem either. -Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344108: spampd - weird %s in syslog, autolearn fails
Package: spampd Version: 2.30-1 Severity: important Hi, at first I have to thank you for the - so far - well working spampd. Something I've waited for for a long time. After installing there popped two things in my eyes: 1. weird %s in syslog: For every scanned mail spampd generates several lines like Dec 20 04:59:31 one spampd[5490]: %s in the log. After looking through the resolved bugs I think this could probably be a result of the fix introduced in #332259, probably it's unnessessary now due to changes in the perl libraries!? That's only a guess. 2. spamassassin/autolearn uses /root/.spamassassin After checking the output of spampd in the emails I've seen an autolearn=failed entry from spamassassin. Starting spampd in debugging mode showed, that spampd's spammassassin tries to put it's stuff into /root/.spamassassin/: [28638] dbg: config: using /root/.spamassassin/user_prefs for user prefs file [28638] dbg: bayes: no dbs present, cannot tie DB R/O: /root/.spamassassin/bayes_toks [28638] dbg: bayes: no dbs present, cannot tie DB R/O: /root/.spamassassin/bayes_toks [28638] dbg: locker: safe_lock: created /root/.spamassassin/auto-whitelist.lock.one.recluse.de.28638 [28638] dbg: locker: safe_lock: trying to get lock on /root/.spamassassin/auto-whitelist with 0 retries [28638] dbg: locker: safe_lock: link to /root/.spamassassin/auto-whitelist.lock: link ok [28638] dbg: auto-whitelist: tie-ing to DB file of type DB_File R/W in /root/.spamassassin/auto-whitelist [28638] dbg: locker: safe_unlock: unlink /root/.spamassassin/auto-whitelist.lock This works while starting the daemon - seems it's still running as root at this time, but as soon as it has given up root rights and it's running as spampd it should be unable to access /root/.spamassassin, at least on a well configured system. [pid 31947] stat(/root/.spamassassin/bayes_toks, 0x508550) = -1 EACCES (Permission denied) [pid 31947] stat(/root/.spamassassin/bayes_toks.db, 0x508550) = -1 EACCES (Permission denied) [pid 31947] stat(/root/.spamassassin, 0x508550) = -1 EACCES (Permission denied) [pid 31947] stat(/root/.spamassassin, 0x508550) = -1 EACCES (Permission denied) [pid 31947] mkdir(/root/.spamassassin, 0700) = -1 EACCES (Permission denied) [pid 31947] stat(/root/.spamassassin, 0x508550) = -1 EACCES (Permission denied) This bug is a bit critical imho, such a daemon should not even try to access stuff in /root. To fix this spampd needs a home-directory (like /var/lib/spampd or something like that) and the spamassassin part should be loaded as the user spampd - or is there any reason to do this before giving up root rights? Unfortunately I can't come up with a path for this - my knowledge of perl is much much too minimal. If you need any more informations or if you have a bugfix to test please let me know. Best regards, Bernd Zeimetz -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2-grsec Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages spampd depends on: ii adduser 3.80 Add and remove users and groups ii dpkg 1.13.11package maintenance system for Deb ii libnet-server-perl0.89-1 An extensible, general perl server ii perl 5.8.7-7Larry Wall's Practical Extraction ii spamassassin 3.1.0a-1 Perl-based spam filter using text spampd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343839: aptitude: segfaults trying to downgrade e2fsprogs
On Mon, Dec 19, 2005 at 10:48:31PM -0500, Ivan Nestlerode [EMAIL PROTECTED] was heard to say: The scenario required to reproduce the crash is even simpler now. I have a handful of packages on hold (mozilla-firefox and all of the e2fsprogs binary packages) and I am trying to purge bittorrent and libwine-arts. Nothing is being upgraded, downgraded, or installed. I still get a segfault. The backtrace is hard to paste here because gdb's terminal gets totally messed up when running aptitude inside of it. I assume you can reproduce it. It involves pkgSimulate::Policy::~Policy() which is mentioned in another Bug (343488). However, applying the patch from that bug did not solve the problem. Also, downgrading aptitude to version 0.4.0-5 did not solve the problem either. Unfortunately, backtraces are generally useless unless you compile the program yourself with -O0 -fno-inline. What exactly do you do to trigger the segfault? Nothing happens when I put all the stuff that's being upgraded on hold and then purge those packages, even if I type 'g'. Daniel signature.asc Description: Digital signature
Bug#344109: suggest libperl-dev
Package: perl Version: 5.8.7-9 perl package installs perlcc, which requires libperl.a, which is in package libperl-dev. But libperl-dev package is not required by package perl, not even suggested. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343839: aptitude: segfaults trying to downgrade e2fsprogs
On Mon, Dec 19, 2005 at 08:05:27PM -0800, Daniel Burrows wrote: On Mon, Dec 19, 2005 at 10:48:31PM -0500, Ivan Nestlerode [EMAIL PROTECTED] was heard to say: The scenario required to reproduce the crash is even simpler now. I have a handful of packages on hold (mozilla-firefox and all of the e2fsprogs binary packages) and I am trying to purge bittorrent and libwine-arts. Nothing is being upgraded, downgraded, or installed. I still get a segfault. The backtrace is hard to paste here because gdb's terminal gets totally messed up when running aptitude inside of it. I assume you can reproduce it. It involves pkgSimulate::Policy::~Policy() which is mentioned in another Bug (343488). However, applying the patch from that bug did not solve the problem. Also, downgrading aptitude to version 0.4.0-5 did not solve the problem either. Unfortunately, backtraces are generally useless unless you compile the program yourself with -O0 -fno-inline. What exactly do you do to trigger the segfault? Nothing happens when I put all the stuff that's being upgraded on hold and then purge those packages, even if I type 'g'. Daniel I start aptitude. I press g. The programs are already marked for holds and purges. I press g again and press Enter for Ok. Then I get the segfault. How exactly do I build aptitude such that a back trace is useful? I know how to build the package from source but not how to change the build options. -Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344110: xserver locks up and uses almost all cpu (99%)
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: important Sometimes the xserver locks up totally and the whole computer is running veeery slow. (Noticed by the choppy sound from my speakers. :-) The xserver uses almost all available cpu, I guess it is only the kernels safe guard (2.6) that lets other processes get some attention. I have to log in thru another computer to kill the X-process, only signal 9 helps. And then the screen keyboard are unusable so I hvae to reboot anyway. (Is there a way to restore them without rebooting?) This happens at most once a week or month, sometimes it has occurred twice a day, but that's very seldom. And I havn't been able to reproduce the problem. I'm using nvidias 7174-driver, but this problem has been around since I started using my nividia card with the xfree86 driver (at least 6629) so I'm very suspicous about the closed nividia driver. Anyway, here is a short strace of the X-process: Process 7247 attached - interrupt to quit --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) @ 0 (0) --- -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root familj 17 Oct 16 15:54 /etc/X11/X - /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 1833112 Nov 29 09:48 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: :03:00.0 VGA compatible controller: nVidia Corporation NV36.2 [GeForce FX 5700] (rev a1) /etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root familj 4993 Oct 16 15:54 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module # LoadGLcore Loadbitmap Loaddbe Loadddc # Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104
Bug#344111: preload: 0.2-3 suddenly depends on sysv-rc
Package: preload Version: 0.2-1 Severity: important Version 0.2-3 declares a dependency on sysv-rc whereas 0.2-1 does not; therefore 0.2-3 is not installable on my machine which uses file-rc. Also, there is no mention in the changelog about this added dependency. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages preload depends on: ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libglib2.0-0 2.8.4-2The GLib library of C routines preload recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343666: cdrecord: segfaults on burn start
On Tue, 2005-12-20 at 01:52 +, Steve McIntyre wrote: On Mon, Dec 19, 2005 at 06:40:40PM -0700, dann frazier wrote: On Sat, 2005-12-17 at 12:48 +, Steve McIntyre wrote: On Fri, Dec 16, 2005 at 05:40:09PM -0700, dann frazier wrote: Package: cdrecord Version: 4:2.01+01a03-4 Severity: important A backtrace is below[1]. The 4:2.01+01a03-4 release didn't segv, but reported an error[2]. Bugger. I _think_ I've found the problem, some debug left in that was a little too i386-specific. I have an ia64 here, but not with a CD-R drive attached to be able to test the fix. Can you test a rebuild with the patch 27_scsi_buffer_size replaced with the version attached please? Thanks Steve. I dropped the libscg/scg/scsitransp.h hunk because it already appears to be in -4 - rest of the patch applied cleanly. However, it still crashes in the same place. :-( Can you mail me a coredump please? I'll have to dig in further and see what's going on... http://dannf.org/bugs/343666 Corresponding binaries/source included as well, thanks! -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On 12/17/05, Bastian Blank [EMAIL PROTECTED] wrote: On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote: On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. And what is your reason for being unwilling to use the same procedure on devmapper disks? Which procedure? You seem to know something I don't know. (Overwrite means in my context: chmod of static devices or a MODE setting in the udev config) I'm trying to ask why you are unwilling to have devmapper disks provide a default of root.disk 660? Why can't you allow that to be the default? Is there some reason you can't have implement your personally preferred policy of root.root 600 on just your own system? Is there some reason for projecting your personal policies incompletely onto an arbitrary subset of debian's users? Is there something about this question I'm asking which doesn't make sense to you? Personally, I'm using a system where the only way to obtain root access is to log in as root -- there's no privileges gained through suid binaries. Err? Write access to the device of a mounted filesystem is a way to gain root if you don't disable several options. Quite a bit of stuff doesn't work the way you might normally expect, on that particular system. Anyways, good security means that the system works the way the person responsible for the system think it's supposed to be working. What you've done here introduces surprises and thus would tend to degrade the security of debian users's systems (not directly but by requiring that some people introduce ad-hoc and perhaps ill-considered workarounds). You seem to be asserting: a malicious person who handles backups could use the disk group to obtain root access, so you should force backup programs to run as root. But that does not seem to be a reasonable position: (1) There are risks other than a malicious people -- by ensuring backup programs don't have to run as root, we minimize the risks that such programs will do something they weren't designed to do. (2) A malicious person with physical access to the system can compromise it in a variety of ways (boot with init=/bin/sh, replace the OS, add monitoring hardware to the keyboard or the display, put a logic sniffer on the bus, etc. etc.) As things currently stand: (A) The risk you're protecting against is not defeated by the measures you propose. (B) The measures you propose have not been accepted (or even discussed) in the debian community at large. (C) You've defeated some measures which make debian systems more robust. (D) You've clearly stated that you do not require that devmapper use these defaults to implement your security policy. I don't have any right to object to how you maintain your own personal systems, but what you're inflicting on debian as a whole does not seem to make much sense. -- Raul
Bug#344112: ITP: libforehead-java -- a small framework to control the Java ClassLoader hierarchy
Package: wnpp Severity: wishlist Package name: libforehead-java Version: 0.0+cvs20051219 Upstream Author: Bob Mcwhirter [EMAIL PROTECTED] URL: http://forehead.sourceforge.net/ License: BSD-style (full-text at http://cvs.sourceforge.net/viewcvs.py/forehead/forehead/LICENSE.txt?rev=1.1.1.1view=auto) Description: a small framework to control the Java ClassLoader hierarchy forehead is a very small framework to assist in controlling the run-time ClassLoader hierarchy of Java applications.
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Stephen Gran wrote: At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. I did try commenting out: #alias net-pf-10 ipv6 in /etc/modprobe.d/aliases. Unfortunately, that doesn't keep the resolver from doing ipv6 queries. The behavior is the same regardless of whether the ipv6 kernel module is loaded (rebooted after the change and lsmod shows no ipv6 module). Is there another way to disable ipv6 queries by the resolver? I'm probably missing something simple but couldn't find anything in the docs. Thanks. Regards, Ed HTH, and take care, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343568: fakeroot: Fakeroot doesn't work at all on Linux 2.6.12
On Mon, Dec 19, 2005 at 10:10:32PM -0500, Clint Adams wrote: $ fakeroot $ whoami webb I verified that SysV IPC is on in my kernel options. On a 2.4.22 system I have also running Debian stable, I get the expected root. Does fakeroot-tcp exhibit the same behavior? Yes. I can also create a file (within the fakeroot or fakeroot-tcp environment) with touch and it says the owner is webb. Interestingly, the shell (bash) tells me I'm root when I'm in the fakeroot or fakeroot-tcp environment. My shell prompt is: PS1=---\n\h \u\! \w\n I've been trying to compile from source, but I'm having a hell of a time getting the stable version of this package. I figured out that apt-get source by default gets unstable sources, but I tried: $ apt-get source -b fakeroot=stable Reading Package Lists... Done Building Dependency Tree... Done E: Unable to find a source package for fakeroot $ apt-get source fakeroot Reading Package Lists... Done Building Dependency Tree... Done Need to get 981kB of source archives. Get:1 http://ftp3.nrc.ca unstable/main fakeroot 1.5.6 (dsc) [707B] Get:2 http://ftp3.nrc.ca unstable/main fakeroot 1.5.6 (tar) [980kB] snip $ apt-get source -b fakeroot=unstable Reading Package Lists... Done Building Dependency Tree... Done E: Unable to find a source package for fakeroot So why doesn't the last one work if the second works? I obviously don't know what I'm doing here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344078: aptitude: french translation of a string
tags 344078 pending thanks Quoting Daniel Luedemann ([EMAIL PROTECTED]): Package: aptitude Version: 0.4.0-3 Severity: minor Tags: l10n The french translation of the string Downgrade the following packages: misses the first letter, probably an R. It currently shows éinstaller à une version antérieure les paquets suivants :, and it should probably be Réinstaller à une version antérieure les paquets suivants : Thanks/merci Daniel for noticing..:-) I commited the fix and sent it to Daniel Burrows, the package maintainer, as usual for l10n fixes. Jean-Luc (Coulon, the translator), as I know you're working on the update of this translation, please look the offending line and remove the extra percent sign which is before the uppercase R. You certainly need to do it on your working copy. Daniel (Burrows), you're surrounded: 3 French people speaking to you..:-)
Bug#344113: rsync: tries to chdir() into a device (strace attached)
X-Reportbug-Version: 3.18
Package: rsync
Version: 2.6.6-1
Severity: important
With the following test-script I get an error of ENOTDIR; see
below for strace. It runs on an shmfs, and that may be some cause
for that bug, because previously it ran on a normal ext3 partition and
I didn't see this message.
The script makes some files, devices, symlinks and directories; then changes
the type of nearly all entries and tries to combine them.
#!/bin/bash
mkdir typechange
(
cd typechange
for i in 1 2 3 4
do
echo file file-$i
cp -a /dev/zero device-$i
ln -s file-$i symlink-$i
mkdir dir-$i
echo sub dir-$i/sub-entry
done
)
mkdir target
(
cd target
for i in file device symlink dir
do
echo file $i-1
cp -a /dev/zero $i-2
ln -s $i-1 $i-3
mkdir $i-4
echo sub $i-4/sub-entry
done
)
rsync -a -n --stats --delete typechange target
Here's the annotated strace:
Starting ...
6517 16:17:41.965845 execve(/bin/sh, [sh, -c, LANG=C rsync -n --delete
-a --st...], [/* 34 vars */] unfinished ...
... finding the entry
6517 16:17:42.156937 select(6, [5], [], NULL, {60, 0}) = 1 (in [5], left {60,
0})
6517 16:17:42.157065 read(5, typechange/device-4, 19) = 19
6517 16:17:42.157182 write(1, deleting typechange/device-4\n, 29) = 29
6517 16:17:42.157298 select(6, [5], [], NULL, {60, 0} unfinished ...
6518 16:17:42.157385 time(NULL)= 1135005462
6518 16:17:42.157496 munmap(0x401f6000, 266240) = 0
6518 16:17:42.157611 munmap(0x40237000, 135168) = 0
Here the entry is lstat()ed:
6518 16:17:42.157724 lstat64(typechange/device-4, {st_mode=S_IFCHR|0666,
st_rdev=makedev(1, 5), ...}) = 0
And directly afterwars an opendir() is called:
6518 16:17:42.157889 open(typechange/device-4,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
rsync continues nonetheless ...
6518 16:17:42.158268 select(4, [3], [1], NULL, {60, 0}) = 1 (out [1], left
{60, 0})
6518 16:17:42.158426 write(1, O\0\0\10rsync: opendir \/tmp/ram/wc2..., 83
unfinished ...
6517 16:17:42.158532 ... select resumed ) = 1 (in [5], left {60, 0})
6518 16:17:42.158606 ... write resumed ) = 83
6517 16:17:42.158677 read(5, O\0\0\10, 4) = 4
6517 16:17:42.158792 select(6, [5], [], NULL, {60, 0}) = 1 (in [5], left {60,
0})
6517 16:17:42.158918 read(5, rsync: opendir \/tmp/ram/wc2/typ..., 79) = 79
6517 16:17:42.159044 write(2, rsync: opendir \/tmp/ram/wc2/typ..., 79) = 79
6517 16:17:42.159553 select(6, [5], [], NULL, {60, 0} unfinished ...
6518 16:17:42.159647 time(NULL)= 1135005462
6518 16:17:42.159780 select(4, [3], [1], NULL, {60, 0}) = 1 (out [1], left
{60, 0})
And gives an error:
6518 16:17:42.159913 write(1, /\0\0\tIO error encountered -- skip..., 51
unfinished ...
6517 16:17:42.160542 ... select resumed ) = 1 (in [5], left {59, 99})
6518 16:17:42.160669 ... write resumed ) = 51
6517 16:17:42.160741 read(5, /\0\0\t, 4) = 4
6517 16:17:42.160861 select(6, [5], [], NULL, {60, 0}) = 1 (in [5], left {60,
0})
6517 16:17:42.160987 read(5, IO error encountered -- skipping..., 47) = 47
6517 16:17:42.161113 write(1, IO error encountered -- skipping..., 47) = 47
6517 16:17:42.161238 select(6, [5], [], NULL, {60, 0} unfinished ...
... and finished with an error.
6517 16:17:42.244334 waitpid(6518, 0xbfcb8f18, WNOHANG) = -1 ECHILD (No child
processes)
6517 16:17:42.244468 getpid() = 6517
6517 16:17:42.244570 kill(6518, SIGUSR1) = -1 ESRCH (No such process)
6517 16:17:42.244690 write(2, rsync error: some files could no..., 74) = 74
6517 16:17:42.245154 munmap(0x40017000, 4096) = 0
6517 16:17:42.245294 exit_group(23)= ?
Regards,
Phil
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (600, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-1) (ignored:
LC_ALL set to de_AT)
Versions of packages rsync depends on:
ii libc6 2.3.5-9GNU C Library: Shared libraries an
ii libpopt0 1.7-5 lib for parsing cmdline parameters
rsync recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336582: phpbb2: New round of security issues
Thijs Kinkhorst wrote:
On Mon, 2005-12-19 at 08:49 +0100, Martin Schulze wrote:
You didn't mention CVE-2005-3417. Is the version in sarge not vulnerable
to it? Or did you miss it? Or did you just didn't document this?
This has been fixed but indeed isn't documented in the changelog. The
fact is that CVE-2005-341{5,6,7} are all concentrated in one function,
that function has been fixed. Should we add that CVE id aswell and
rebuild or is that not necessary?
Since I've already moved the package into the security queue, we'll
only mention this cve name in the advisory. In the sid version, however,
please add the missing id to the changelog when you're doing the next
upload.
Regards,
Joey
--
A mathematician is a machine for converting coffee into theorems. Paul Erdös
Bug#335997: flyspray: Multiple XSS vulnerabilities
On Tue, Dec 20, 2005 at 12:42:40AM +0100, Pierre Habouzit wrote: Le Lun 19 Décembre 2005 22:15, Steve Langasek a écrit : On Mon, Dec 19, 2005 at 04:47:50PM +0100, Pierre Habouzit wrote: Moreover the current version has some problems that I'd not like to see enter testing at all. Current testing has an RC security bug. If those issues you mention are also RC, I suggest you document them in the BTS, since I didn't find any other RC issues in the tracker. If they are not, this version should progress in order to fix the RC security bug in testing that's absent in unstable. you are right on the full line, and I just did an upload of what I should have done way earlier and that was almost ready on my computer. thise one fixes a lot of bugs and use the update that upstream released a few day after I fixed the RC bug in a hurry. -6 is the package that will fix all that should be, and it'll enter etch in 10 days from now. If this fixes a release critical security bug, *why* are we treating it with urgency=low? I already did an upload with urgency low, either you can force it to be high, or I can reupload, as you want. Ok, urgency bumped. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#344114: Overrides system default fonts sans and serif
Package: ttf-unfonts Version: 1.0.1-3 Without ttf-unfonts installed, the system default fonts for sans and serif are the Vera fonts, which is the fontconfig default: [EMAIL PROTECTED]:~$ dpkg -l ttf-unfonts | tail -1 pn ttf-unfontsnone (no description available) [EMAIL PROTECTED]:~$ fc-match 'Sans' Vera.ttf: Bitstream Vera Sans Roman [EMAIL PROTECTED]:~$ fc-match 'Serif' VeraSe.ttf: Bitstream Vera Serif Roman With ttf-unfonts installed, the system default fonts for sans and serif are UnDotum and UnBatang respectively: [EMAIL PROTECTED]:~$ dpkg -l ttf-unfonts | tail -1 ii ttf-unfonts1.0.1-3Un series Korean TrueType fonts [EMAIL PROTECTED]:~$ fc-match 'Sans' UnDotum.ttf: UnDotum Regular [EMAIL PROTECTED]:~$ fc-match 'Serif' UnBatang.ttf: UnBatang Regular Installing a font package should not make those fonts the systemwide default. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#344115: apticron: only mail what changed since last run
Package: apticron Version: 1.1.13.0.0.dale.0 Severity: wishlist Tags: patch I use apticron to list the changes for updates to all my installed packages, not just security updates. On testing, there are usually 10 to 100 packages that need updating, as I only update about once a month. I wanted to be able to get these reports from apticron only when something has changed since the last report I got. I implemented this using a simple diff of the new report against the old, and then only send mail if there is a difference. See the attached patch, which requires changes to the apticron script and the conf file. I've never made a patch before, so I'm not sure if what I did will work for you, but I made this patch against the directory I got when I apt-get source apticron. Hope it makes sense to you. Cameron Dale -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages apticron depends on: ii apt-listchanges 2.59-0.2Display change history from .deb a ii debconf [debconf 1.4.58 Debian configuration management sy ii iproute 20041019-3 Professional tools to control the ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent apticron recommends no packages. -- debconf information: * apticron/notification: root diff -Naur apticron-1.1.13/apticron apticron-1.1.13.0.0.dale.0/apticron --- apticron-1.1.13/apticron2005-09-28 10:05:34.0 + +++ apticron-1.1.13.0.0.dale.0/apticron 2005-12-20 01:28:49.0 + @@ -22,10 +22,16 @@ # Set the IPADDRESSNUM IPADDRESSNUM=1 +# What to email +WHAT=all + # Source the config file [ -e /etc/apticron/apticron.conf ] . /etc/apticron/apticron.conf +TMPFILE=/tmp/apticron.$$ +LOGFILE=/var/log/apticron + if [ -z $IPADDRESSES ]; then # Set the IPv4 addresses IPADDRESSES=`(echo $( /bin/hostname -i ) ; @@ -64,6 +70,14 @@ PKGNAMES=`/usr/bin/apt-get -q -y -s dist-upgrade | /bin/grep ^Inst |\ /usr/bin/cut -d\ -f2 | /usr/bin/sort` +if [ $WHAT == diff ] ; then + if [ -e $LOGFILE ] ; then + /bin/cp -f --reply=yes $LOGFILE $TMPFILE + else + /bin/echo apticron has never been run before or was recently upgraded (no log file) $TMPFILE + fi +fi + if [ -n $PKGNAMES ] ; then # do the upgrade downloads @@ -124,6 +138,59 @@ apticron EOF - ) 21 | /usr/bin/mailx -s Debian Package Updates on `/bin/hostname` $EMAIL + ) $LOGFILE 21 + +fi + +if [ $WHAT == diff ] ; then + /usr/bin/diff -N $TMPFILE $LOGFILE | /bin/grep -E ^[] $TMPFILE.2 + NUMLINES=`/bin/grep -c $TMPFILE.2` + if [ $NUMLINES -gt 2 ] ; then + ( + /bin/cat EOF +apticron report [`/bin/date -R`] + + +apticron has detected that the package report changed since the last +run, this probably means that there are new packages available for: + + $SYSTEM $ADDRESSES + +Here is the difference between the two reports: + + +EOF + /bin/cat $TMPFILE.2 + + /bin/cat EOF + + +You can perform the upgrade of these and any other previously reported +changed packages by issuing the command: + + apt-get dist-upgrade + +as root on $SYSTEM + +The complete report of all changed packages is available at: + + $LOGFILE + +It is recommended that you simulate the upgrade first to confirm that +the actions that would be taken are reasonable. The upgrade may be +simulated by issuing the command: + + apt-get -s dist-upgrade + +-- +apticron +EOF + + ) | /usr/bin/mailx -s Debian Package Updates on `/bin/hostname` $EMAIL + fi + /bin/rm -f $TMPFILE + /bin/rm -f $TMPFILE.2 +else + /bin/cat $LOGFILE | /usr/bin/mailx -s Debian Package Updates on `/bin/hostname` $EMAIL fi diff -Naur apticron-1.1.13/apticron.conf apticron-1.1.13.0.0.dale.0/apticron.conf --- apticron-1.1.13/apticron.conf 2005-09-28 10:05:34.0 + +++ apticron-1.1.13.0.0.dale.0/apticron.conf2005-12-20 01:25:02.0 + @@ -31,3 +31,10 @@ # # IPADDRESSES=192.0.2.1 2001:db8:1:2:3::1 +# +# Set WHAT to diff to only output the difference in this run compared to +# the last run (ie. any new upgrades since the last run). If there are no +# differences, no output/email will be generated. By default, apticron will +# output everything that needs upgrading. +# +# WHAT=diff diff -Naur apticron-1.1.13/debian/changelog apticron-1.1.13.0.0.dale.0/debian/changelog ---
Bug#341978: libtool: prune unused libs from the linker line on GNU/kFreeBSD
Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Dec 04, 2005 at 07:47:32PM CET: On Sun, Dec 04, 2005 at 05:54:48PM +0100, Ralf Wildenhues wrote: By the way, why don't you submit the patches regarding the BSD changes Mainly because I have no idea if: - It's complete Looks good to me. - What the difference between netbsdelf*-gnu and knetbsd*-gnu is. Joel wrote a bit about that in the upstream submission: http://lists.gnu.org/archive/html/libtool-patches/2004-04/msg00143.html Still basically accurate. - Does the netbsd port still exist? I don't know. Let's ask Joel. It's been rather quiet, lately, but in theory it certainly does. Without reviewing the entire patch set and issue, I'd say the following is a good guideline: 1) netbsdelf*-gnu means: * Debian standard GCC * Debian standard binutils (including linker) * NetBSD 'native' libc (and related; libm, etc.) * Debian standard 'non-system' libraries As such, I would be of the opinion that if applying the basic logic to prune unused libraries causes a failure in anything under netbsdelf*-gnu, then it's a (significant) bug in the netbsd port and should be addressed by the porters (at the moment, that mostly seems to be 'me'). The only 'odd' library I know of for linking issues is/was libc, in that older GCC releases had some logic regarding whether to implicitly link libc on older NetBSD releases. I believe, however, that this is no longer an issue, particularly in the Debian GCC packages, since I recall writing patches to deal with it at the time, and I think it has become a non-issue, since that point. Other than that, I can work on making time to take a look at the patch more intensively, if there's some doubt about it, but anything that actually *works* for both Linux and kfreebsd*-gnu and/or knetbsd*-gnu is unlikely to break netbsdelf*-gnu (one possible point of note is that the Debian NetBSD port follows Debian library number conventions, not NetBSD ones - but that should make things easier, in general, anyway). -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: OpenPGP digital signature
Bug#344116: cupsys: [INTL:fr] French debconf templates translation
Package: cupsys Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Thanks for taking care of warning translators before uploading a new version with string changes. It's highly appreciated. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) # translation of fr.po to French #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # #Developers do not need to manually edit POT or PO files. # Christian Perrier [EMAIL PROTECTED], 2004, 2005. # msgid msgstr Project-Id-Version: fr\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2005-12-17 13:06+0900\n PO-Revision-Date: 2005-12-17 18:48+0100\n Last-Translator: Christian Perrier [EMAIL PROTECTED]\n Language-Team: French debian-l10n-french@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n X-Generator: KBabel 1.10.2\n Plural-Forms: Plural-Forms: nplurals=2; plural=n1;\n #. Type: boolean #. Description #: ../cupsys-bsd.templates:4 msgid Do you want to set up the BSD lpd compatibility server? msgstr Faut-il installer le serveur compatible avec le démon lpd de BSD ? #. Type: boolean #. Description #: ../cupsys-bsd.templates:4 msgid This package contains a server that can accept BSD-style print jobs and submit them to CUPS. It should only be set up if you have other computers that submit jobs over the network via \BSD\ or \LPR\ services, and these computers cannot be converted to use the IPP protocol that CUPS uses. msgstr Ce paquet comporte un serveur capable d'accepter des demandes d'impression au style BSD et de les donner à CUPS. Installez-le seulement si vous avez des machines qui envoient leurs demandes à travers le réseau via les services « BSD » ou « LPR » et qui ne peuvent pas accepter le protocole IPP utilisé par CUPS. #. Type: boolean #. Description #: ../cupsys.templates:4 msgid Do you want CUPS to print unknown jobs as raw jobs? msgstr CUPS doit-il imprimer les demandes sans type MIME sous forme brute ? #. Type: boolean #. Description #: ../cupsys.templates:4 msgid All print jobs in IPP get a MIME type. Since not all sources of print jobs can attach an appropriate type, many jobs get submitted as the MIME type application/octet-stream. Because of this, when CUPS receives a job with that MIME type, it attempts to guess what the format is. By default, if it cannot guess the proper type, it rejects the job. msgstr Selon le protocole IPP (« Internet Printing Protocol »), chaque demande d'impression comporte un type MIME. Comme certaines sources de demandes d'impression ne peuvent pas affecter un type MIME adapté, de nombreuses demandes sont soumises avec le type MIME application/octet-stream. Lorsque CUPS reçoit une demande d'impression avec ce type MIME, il tente d'en déterminer le format. Par défaut, si cette tentative échoue, la demande est rejetée. #. Type: boolean #. Description #: ../cupsys.templates:4 msgid It is possible to cause CUPS to treat all unrecognized jobs with this MIME type as \raw\ jobs, which causes them to be sent directly to the printer without processing. msgstr CUPS peut traiter toutes ces demandes sans type reconnu comme des demandes au format brut et les envoyer sans aucun traitement à l'imprimante. #. Type: boolean #. Description #: ../cupsys.templates:4 msgid If you will be accepting print jobs from Windows computers, you probably want this option set, as Windows gives all IPP print jobs processed by a local driver the MIME type application/octet-stream. Samba also submits its print jobs this way. msgstr Si vous acceptez des demandes d'impression émises par des ordinateurs utilisant Windows, vous devriez utiliser cette option car Windows affecte le type MIME application/octet-stream à toutes les demandes émises par un pilote local d'impression. Samba soumet également ses demandes d'impression de cette manière. #. Type: multiselect #. Choices #: ../cupsys.templates:22 msgid ipp msgstr IPP #. Type: multiselect #. Choices #: ../cupsys.templates:22 msgid lpd msgstr lpd #. Type: multiselect #. Choices #: ../cupsys.templates:22 msgid parallel msgstr parallèle #. Type: multiselect #. Choices #: ../cupsys.templates:22 msgid scsi msgstr SCSI #. Type: multiselect #. Choices #:
Bug#344103: gksuexec fails every time
Package: gksu Version: 1.3.6-1 Followup-For: Bug #344103 hello, every time I launch gksu, I have a blank error dialog box. In my .xsession-errors, I have only the following error : (gksu:22993): Gtk-WARNING **: Failed to set label from markup due to error parsing markup: Error on line 8 char 9: Invalid UTF-8 encoded text -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (900, 'stable'), (600, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages gksu depends on: ii gconf2 2.10.1-6GNOME configuration database syste ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgconf2-4 2.10.1-6GNOME configuration database syste ii libgksu1.2-0 1.3.7-1 library providing su and sudo func ii libgksuui1.0-1 1.0.7-1 a graphical fronted to su library ii libglib2.0-0 2.8.3-1 The GLib library of C routines ii libgnome-keyring00.4.5-1 GNOME keyring services library ii libgtk2.0-0 2.6.10-1The GTK+ graphical user interface ii liborbit21:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.8.2-3 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii sudo 1.6.8p7-1.2 Provide limited super user privile gksu recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281971: [Pkg-samba-maint] samba-doc-pdf package
Quoting Peter Eisentraut ([EMAIL PROTECTED]): Here again is a combined patch for bugs #281971 (make samba-doc-pdf package) and #233447 (remove duplicate docs in swat, symlink to samba-doc), which incorporates Adam Conrad's suggestions about fixing up the symlinks. Please consider. Well, I was about to upload new packages when I realized that this samba-doc-pdf package is surprisingly smallwhile it's supposedly aimed at reducing the size of samba-doc (which it does). Indeed, this is because we seem to be misin a debian/samba-doc-pdf.docs file: docs/Samba3-ByExample.pdf docs/Samba3-Developers-Guide.pdf docs/Samba3-HOWTO.pdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322264: intend to NMU
user [EMAIL PROTECTED] usertag 322264 + intend-to-nmu stop As this bug has had a patch filed for over 30 days without a response from the maintainer, I intend to NMU it in 1 week (or earlier, at the maintainer's request). -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344117: bad permissions on /var/lib/debsecan
Package: debsecan Version: 0.2 Severity: important I installed the debsecan cron job and then manually ran the command in the crontab, giving this error: chianamo:~# su daemon -c '/usr/bin/debsecan --suite sid --mailto root --cron' Traceback (most recent call last): File /usr/bin/debsecan, line 753, in ? rate_system(target, options, fetch_data(options), history) File /usr/bin/debsecan, line 738, in rate_system formatter.finish() File /usr/bin/debsecan, line 631, in finish self._write_history(self.options.history) File /usr/bin/debsecan, line 508, in _write_history f = file(new_name, w+) IOError: [Errno 13] Permission denied: '/var/lib/debsecan/history.new' Permissions are: chianamo:~# ls -ld /var/lib/debsecan/ drwxr-xr-x 2 root root 48 2005-12-20 03:38 /var/lib/debsecan/ This means that the default crontab will not work. Please fix the permissions on /var/lib/debsecan/. -- System Information: Debian Release: unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-k7 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages debsecan depends on: ii python2.3.5-3An interactive high-level object-o -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#149902: Australian time zones
On Tue, Dec 20, 2005 at 09:47:56AM +0900, GOTO Masanori wrote: Note that you probably want to know why AEST vs EST is long-standing problem: the short summary is available in glibc source tree timezone/australasia. Not only one governmental page but also showing another information source would be nice idea to change time zone maintainers. Wow, this is a bug come back from the dead. I read the summary in glibc and think it's wierd. For example, the counts supposedly showing Eastern Standard Time to be more popular than Australia Eastern Standard Time are bogus. The first search is obviously going to include the results of the second. A simple calculation shows that even then the prefix was four times as common as without. Current figures from Google: Australian Eastern Standard Time site:.au 155000 Eastern Standard Time site:.au206000 Eastern Standard Time -Australian Eastern Standard Time site:.au 5 But in my mind the argument is simple: EST is ambiguous, AEST is not. The issue I had has to do with input, not output. Saying 9:00 EST is ambiguous, but 9:00 AEST is not even recognised as a valid date. Obviously you can't remove all ambiguity, but it's certainly worth removing whenever possible. There is still no way to specify an Australian timezone to date, which I suppose is the real bug. Yes, you can affect it with environment variables, but still... $ date --date='9:00 Australia/Sydney' date: invalid date `9:00 Australia/Sydney' $ date --date='9:00 EST' Tue Dec 20 15:00:00 CET 2005 --- ??? Not european time. What is it? $ date --date='9:00 AEST' date: invalid date `9:00 AEST' Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpPEtCZWvTJ2.pgp Description: PGP signature
Bug#344046: FTBFS on m68k
unmerge 344046 reassign 344046 make 3.80+3.81.b4-1 severity 344046 serious block 344046 by 344041 thanks On Mon, Dec 19, 2005 at 01:52:54PM -0600, Manoj Srivastava wrote: reassign 344046 gcc-4.0 severity 344046 grave severity 344041 grave merge 344041 344046 thanks If this is a bug in gcc-4.0, and it causes other packages to have FTBS bugs, then we should fix gcc. By this standard, almost all toolchain bugs would be release-critical bugs. This is not reasonable; there is an order of magnitude difference (at least) between fix an arbitrary bug in gcc which causes package foo to FTBFS and fix package foo to use compile options that work, and one build failure (or a few) doesn't exactly make gcc unusable or mostly so anyway. When a package fails to build on a release architecture and the failure is not caused by an RC bug in another package, that's a serious bug in the package in question. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#344005: [Linux-wlan-ng-devel] Bug#344005: Acknowledgement (depmod: loop detected)
Am Montag, den 19.12.2005, 20:49 +0100 schrieb Enrico Tassi: The bug has been already fixed in -6 I think. Said that, it will be probably under you christmas tree... Allright, I tried to build modules with linux-wlan-ng version 0.2.2 +dfsg-7 from unstable for my kernel 2.6.12 from testing and it worked! Thank you very much! This bug may get closed! Nice Greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344118: Syntax error in erlang's Conflicts line
Package: erlang
Version: 10.b.7-1
Severity: normal
Tags: patch
Hi,
The erlang's Conflicts line is missing a comma at one point, resulting in
a warning from dpkg-gencontrol during build. Attached patch fixes it.
Best regards,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CCdiff -aur a/debian/control b/debian/control
--- a/debian/control2005-12-19 23:32:41.0 -0800
+++ b/debian/control2005-12-19 23:33:24.0 -0800
@@ -9,7 +9,7 @@
Architecture: all
Pre-Depends: dpkg (= 1.4.1.17)
Depends: debianutils (= 1.13.1), ${erlang:Depends}, erlang-base
(=${Source-Version}), tk8.4
-Conflicts: erlang-base ( ${Source-Version}) erlang-jams, erlang-jams-erl,
erlang-dev, erlang-mode, erlang-manpages ( 1:10.b.1a), elastic-base,
libxmerl-erlang
+Conflicts: erlang-base ( ${Source-Version}), erlang-jams, erlang-jams-erl,
erlang-dev, erlang-mode, erlang-manpages ( 1:10.b.1a), elastic-base,
libxmerl-erlang
Replaces: erlang-base ( ${Source-Version})
Suggests: erlang-manpages (= 1:10.b.7), erlang-doc-html (=1:10.b.7)
Description: A real-time, concurrent and distributed functional language
Bug#344119: pbuilder: readlink -e
Package: pbuilder Version: 0.142 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo! I'm not sure if this is #342117 and the fix didn't work or if this is a different problem, like pbuilder needing to depend on testing/unstable coreutils version. ~$ sudo pbuilder login Password: W: /home/avbidder/.pbuilderrc does not exist Building the build Environment - extracting base tarball [/var/cache/pbuilder/base.tgz] - creating local configuration - copying local configuration readlink: invalid option -- e Try `readlink --help' for more information. cp: missing destination file Try `cp --help' for more information. (and that it doesn't error out at readlink, continuing instead to the cp doesn't make a good impression to me either... set -e missing?) cheers - -- vbi - -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (60, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.14-2-686-smp Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Versions of packages pbuilder depends on: ii cdebootstrap 0.3.9 Bootstrap a Debian system ii coreutils 5.2.1-2The GNU core utilities ii debianutils 2.8.4 Miscellaneous utilities specific t ii gcc 4:4.0.2-2 The GNU C compiler ii wget 1.9.1-12 retrieves files from the web - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkOntktgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWAkEAoKo4oV7WFLSyMSxSPZqhdgw6 NG8WAKDjVV3R2mepvnIjcCN8Xk7bKHkimQ== =xmXO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344120: udev: snd_pcm_oss makes symlink /dev/dsp - dsp
X-Reportbug-Version: 3.18 X-Debbugs-Cc: [EMAIL PROTECTED] Package: udev Version: 0.076-6 Severity: normal On a Acer Travelmate 529TXV I include snd_pcm_oss. I get a /dev/dsp, but that is a symlink to dsp: $ ls -la /dev/dsp lrwxrwxrwx 1 root root 3 2005-12-20 09:40 /dev/dsp - dsp udevmonitor: udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1135068286.920648] add@/module/snd_pcm_oss UEVENT[1135068286.920795] add@/class/sound/dsp UEVENT[1135068286.920811] add@/class/sound/audio UEVENT[1135068286.920826] add@/class/sound/adsp UDEV [1135068286.928839] add@/module/snd_pcm_oss UDEV [1135068286.940921] add@/class/sound/dsp UDEV [1135068286.961477] add@/class/sound/audio UDEV [1135068286.980755] add@/class/sound/adsp $ cat /sys/class/sound/dsp/dev 14:3 If I mknod the /dev/dsp with appropriate rights it works. -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: insgesamt 4 lrwxrwxrwx 1 root root 19 2005-10-12 08:05 025_libgphoto2.rules - ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2005-12-19 08:15 025_libsane.rules - ../libsane.rules lrwxrwxrwx 1 root root 22 2005-12-06 08:12 025_logitechmouse.rules - ../logitechmouse.rules -rw-r--r-- 1 root root 302 2005-06-21 08:12 0mine.rules lrwxrwxrwx 1 root root 20 2005-05-10 08:06 20_permissions.rules - ../permissions.rules lrwxrwxrwx 1 root root 13 2005-01-10 10:20 50_udev.rules - ../udev.rules lrwxrwxrwx 1 root root 14 2005-01-10 10:20 60_devfs.rules - ../devfs.rules lrwxrwxrwx 1 root root 19 2005-01-10 10:20 cd-aliases.rules - ../cd-aliases.rules lrwxrwxrwx 1 root root 19 2005-08-16 07:55 z20_persistent.rules - ../persistent.rules lrwxrwxrwx 1 root root 12 2005-07-11 07:28 z50_run.rules - ../run.rules lrwxrwxrwx 1 root root 16 2005-10-10 08:25 z55_hotplug.rules - ../hotplug.rules lrwxrwxrwx 1 root root 15 2005-09-20 07:27 z60_hdparm.rules - ../hdparm.rules lrwxrwxrwx 1 root root 17 2005-07-11 07:28 z70_hotplugd.rules - ../hotplugd.rules -- /sys/: /sys/block/fd0/dev /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/drm/card0/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/event3/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/input/mouse1/dev /sys/class/misc/agpgart/dev /sys/class/misc/device-mapper/dev /sys/class/misc/hpet/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/misc/tun/dev /sys/class/printer/lp0/dev /sys/class/sound/controlC1/dev /sys/class/sound/dmmidi1/dev /sys/class/sound/dsp/dev /sys/class/sound/midi1/dev /sys/class/sound/midiC1D0/dev /sys/class/sound/mixer/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev1.2/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev2.2/dev /sys/class/usb/lp0/dev -- Kernel configuration: -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-1) (ignored: LC_ALL set to de_AT) Versions of packages udev depends on: ii initscripts 2.86.ds1-6 Standard scripts needed for bootin ii libc6 2.3.5-9GNU C Library: Shared libraries an ii libselinux1 1.26-1 SELinux shared libraries ii lsb-base 3.0-12 Linux Standard Base 3.0 init scrip ii makedev 3.3.8.2-0 Creates device files in /dev ii sed 4.1.4-5The GNU sed stream editor udev recommends no packages. -- debconf information: udev/devfs-warning: * udev/reboot-warning: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340079: insecure tempfiles
On Mon, Dec 19, 2005 at 04:01:32PM +0100, Bill Allombert wrote: On Sun, Nov 20, 2005 at 03:01:58PM -0800, Steve Langasek wrote: On Sun, Nov 20, 2005 at 10:13:00PM +0100, Bill Allombert wrote: However I am not sure this is a security bug: The original script create a file named tempfile in the current directory, not int /tmp. Would you consider this script to have a security hole? #!/bin/sh cat $1 tempfile mv tempfile $2 Yes, because the tool may be run in an untrusted directory that can be written to by an attacker. Hello Steve, I have not received any answer from the security team. should I upload the package to unstable in the mean time ? (the unstable version is identical to the sarge version, so in principle a DSA address sarge, etch and sid at once). Under the circumstances, uploading a fix to unstable seems sensible. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#328170: Does --nowrapper help?
I'm having similar problems with apt-build from unstable. If I do not use
--nowrapper, I get segfaults in make like this:
checking dependency style of i486-linux-gnu-g++... ./configure: line 4135:
19100 Segmentation fault ${MAKE-make} -s -f confmf /dev/null 21
In this case, line 4135 looks like this, probably typical of a configure file:
for depmode in $am_compiler_list; do
As a result, when make tries to actually compile it, it segfaults too:
make all-recursive
make[1]: *** [all] Segmentation fault
But if I run apt-build with --nowrapper, it works fine.
There seem to be similar bugs in here, but I'm getting different errors.
Should I file a new bug, or is this it?
pgpvZqG03ogSo.pgp
Description: PGP signature
Bug#323677: ITA: mgm -- A highly configurable, very gaudy system load meter
ITA: mgm -- A highly configurable, very gaudy system load meter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
