Bug#666523: libreoffice: upgrade to 1:3.5.2~rc2-1 utterly fails
On Sat, Mar 31, 2012 at 09:00:01PM +0200, Rene Engelhard wrote: > On Sat, Mar 31, 2012 at 08:43:23PM +0200, Mario 'BitKoenig' Holbe wrote: > > aptitude safe-upgrade fails the same. terminal-capture attached. > omg. safe-upgrade.. on sid... Of course, what else? full-upgrade tries to purge half of the system half of the time because of not-yet-fulfilled dependencies (a good example is libgcj-bc atm). And the other half of the time it fails to find a valid solution to fulfill dependencies :) Never anything else than safe-upgrade, especially not on sid. I even try to avoid full-upgrade as long as possible when upgrading stable systems to keep its influence as small as possible. > OK, so it at least doesn't have anything to do with safe-upgrade itself... safe-upgrade did never harm any upgrade in any way on any of my systems. Mario -- ... aber nur deshalb blueht Autoritaet, weil die meisten Menschen Feiglinge und manche Menschen Diebe sind. -- Robert A. Wilson signature.asc Description: Digital signature
Bug#666523: libreoffice: upgrade to 1:3.5.2~rc2-1 utterly fails
On Sat, Mar 31, 2012 at 07:24:53PM +0200, Rene Engelhard wrote:
> On Sat, Mar 31, 2012 at 07:10:17PM +0200, Christoph Anton Mitterer wrote:
> > I deleted some log file manually and then the upgrade of all packages
> > worked (after three iterations or so); however, still with endless
> > errors, that a stylesheet cannot be parsed.
> Yes, noticed that too. (see below)
>
> > ERROR: unopkg cannot be started. The lock file indicates it as already
> > running. If this does not apply, delete the lock file at:
> > /var/lib/libreoffice/share/prereg/.lock
> > dpkg: error processing
> > /var/cache/apt/archives/libreoffice-wiki-publisher_1.1.1+LibO3.5.2~rc2-1_all.deb
> > (--unpack):
> > subprocess new pre-installation script returned error exit status 1
>
> Do as it says. It doesn't say that for no reason. The unopkg in your first
> attempt failed
> and that kept the .lock it seems.
>
> I don't think rm'ing that lock is good (even though one could check for
> soffice.bin|unopkg.bin not there and the
> .lock there, but...)
aptitude safe-upgrade fails the same. terminal-capture attached.
The /var/lib/libreoffice/share/prereg/.lock does not exist prior the
(initial) upgrade but does afterwards.
Just before somebody starts shouting and crying: the 3 not upgraded
packages don't have anything to do with libreoffice (it's libgcj-bc
depending on unavailable libgcj10, and libdvdread4 and dvb-apps both put
on hold manually).
rm'ing /var/lib/libreoffice/share/prereg/.lock and a subsequent aptitude
safe-upgrade succeeds ... well, to some extent: with lots of those
already mentioned xsltParseStylesheetFile errors:
> > Enabling: Wiki Publisher
> > Enabling: help
> > error
> > xsltParseStylesheetFile : cannot parse
> Yes, noticed that too. But that's not a grave bug, neither a serious
> one. Maybe an important one if it makes the help not work, though :-)
I personally think a bug that breaks an upgrade on... well, a noticeable
amount of systems should be kept at a prio that shows it up in
apt-listbugs - as it does now, which probably saves some users some
trouble. I personally don't really care whether it's grave or serious,
but I assume there are enough people out there engaged enough to discuss
that in detail :)
regards
Mario
--
Das Gegenteil einer trivialen Wahrheit ist falsch;
das Gegenteil einer grossen Wahrheit ist ebenfalls wahr.
-- Niels Bohr
root@darkside:~# aptitude safe-upgrade
Resolving dependencies...
The following NEW packages will be installed:
libcmis-0.2-0{a} libexttextcat-data{a} libexttextcat0{a} libvisio-0.0-0{a}
The following packages will be REMOVED:
libtextcat-data{pu} libtextcat0{pu}
The following packages will be upgraded:
fonts-ipafont-nonfree-jisx0208 fonts-opensymbol gcalctool gir1.2-atk-1.0
gir1.2-gnomekeyring-1.0 gir1.2-peas-1.0 gir1.2-soup-2.4
gir1.2-totem-plparser-1.0 gnupg-agent
gnupg2 gnuplot gnuplot-doc gnuplot-nox gnuplot-x11 gpgsm libatk1.0-0
libatk1.0-data
libgnome-keyring-common libgnome-keyring0 libmpg123-0 libmtp-common
libmtp-runtime libmtp9
libnet-ssleay-perl libpeas-1.0-0 libpeas-common libreoffice libreoffice-base
libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core
libreoffice-draw
libreoffice-emailmerge libreoffice-filter-binfilter
libreoffice-filter-mobiledev
libreoffice-gnome libreoffice-gtk libreoffice-help-de libreoffice-help-en-us
libreoffice-impress libreoffice-java-common libreoffice-l10n-de
libreoffice-math
libreoffice-officebean libreoffice-ogltrans libreoffice-pdfimport
libreoffice-presentation-minimizer libreoffice-presenter-console
libreoffice-report-builder
libreoffice-report-builder-bin libreoffice-style-crystal
libreoffice-style-galaxy
libreoffice-style-hicontrast libreoffice-style-oxygen libreoffice-style-tango
libreoffice-wiki-publisher libreoffice-writer libsoup-gnome2.4-1 libsoup2.4-1
libsvga1
libtotem-plparser17 makedev mozilla-libreoffice mpg123 mtp-tools openclipart
openclipart-libreoffice openclipart-png openoffice.org-dtd-officedocument1.0
python-uno
scdaemon sound-juicer svgalib-bin ttf-opensymbol uno-libs3 ure
77 packages upgraded, 4 newly installed, 2 to remove and 3 not upgraded.
Need to get 823 MB of archives. After unpacking 64,3 MB will be used.
Do you want to continue? [Y/n/?]
Get: 1 http://ftp.de.debian.org/debian/ sid/main ure i386 3.5.2~rc2-1 [2.615 kB]
Get: 2 http://ftp.de.debian.org/debian/ sid/main uno-libs3 i386 3.5.2~rc2-1
[754 kB]
Get: 3 http://ftp.de.debian.org/debian/ sid/main libreoffice-calc i386
1:3.5.2~rc2-1 [7.446 kB]
Get: 4 http://ftp.de.debian.org/debian/ sid/main libreoffice-writer i386
1:3.5.2~rc2-1 [8.724 kB]
Get: 5 http://ftp.de.debian.org/debian/ sid/main libreoffice-base i386
1:3.5.2~rc2-1 [3.667 kB]
Get: 6 http://ftp.de.debian.org/debian/ sid/main libreoffice-base-core i386
1:3.5.2~rc2-1 [48,2 kB]
Get: 7 http://ftp.de.debian.org/debian/ sid/main
Bug#662808: grub-pc: fails to install: core.img unusually large
Package: grub-pc Version: 1.99-15 Severity: grave Hello, starting with 1.99-15 grub-pc fails to install: Setting up grub-pc (1.99-15) ... /usr/sbin/grub-setup: warn: Your core.img is unusually large. It won't fit in the embedding area.. /usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub-setup: error: cannot read `/grub/core.img' correctly. Generating grub.cfg ... On reboot the system hangs at "GRUB ". Downgrading to grub-pc 1.99-14 fixes this. The size of core.img between 1.99-14 and 1.99-15 increased from 28751 bytes to 33045 bytes. The system is plain standard MBR with mdraid (plus dm-crypt, but not for /boot). While 28751 bytes fit well in the typical 62 sectors gap on the first track, 33045 bytes would require at least 65 sectors. I can't find any hints in changelog.Debian what's causing this huge size increase except maybe: * Build with GCC 4.6 (closes: #654727). regards Mario -- Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht? signature.asc Description: Digital signature
Bug#657538: libxcb1: breaks alsamixer
On Fri, Jan 27, 2012 at 12:22:28AM +0100, Cyril Brulebois wrote: > Julien Cristau (27/01/2012): > > Core was generated by `alsamixer'. > > Program terminated with signal 11, Segmentation fault. > > #0 0x7f96c1c34fd0 in snd_mixer_class_unregister () > >from /usr/lib/x86_64-linux-gnu/libasound.so.2 > > (gdb) where > > #0 0x7f96c1c34fd0 in snd_mixer_class_unregister () > >from /usr/lib/x86_64-linux-gnu/libasound.so.2 > > #1 0x7f96c1c350cd in snd_mixer_close () > >from /usr/lib/x86_64-linux-gnu/libasound.so.2 > > #2 0x00409a0a in ?? () > > #3 0x7f96bf6fccb6 in xcb_disconnect (c=0x25fb8d0) > > at ../../src/xcb_conn.c:307 > > In the new libxcb version, xcb_disconnect calls shutdown() on a socket > (http://pubs.opengroup.org/onlinepubs/95399/functions/shutdown.html > or man 2 shutdown), but alsa-utils exposes such a function. ??? kaboom. > > Reassigning to alsa-utils, which needs to stop using already-taken > names. Julien: thanks for the quick investigation. Googling around a little showed up RedHat seems to have had this issue as well: https://bugzilla.redhat.com/show_bug.cgi?id=731381 ... and fixed it with a patch from ALSA-git: http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=4c09aaa5c13c2260fea57a89c47f88252da8a692 Thanks Julien and Cyril Mario -- Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. -- Antoine de Saint-Exupéry: Terre des Hommes, III: L'Avion signature.asc Description: Digital signature
Bug#657538: libxcb1: breaks alsamixer
On Thu, Jan 26, 2012 at 11:14:52PM +0100, Cyril Brulebois wrote: > Mario 'BitKoenig' Holbe (26/01/2012): > > root@darkside:~# echo q | alsamixer > > Segmentation fault (core dumped) > Please get us more info about that??? > I can't reproduce it here, also with gnome/pulseaudio installed. After I reported this I found #657342 vs. alsa-utils (which ships alsamixer). Sami Liedes attached a gdb backtrace there that could probably be helpful. At a first glance I'd say it looks like memory poisoning - but that's just a wild guess. Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail signature.asc Description: Digital signature
Bug#657538: libxcb1: breaks alsamixer
On Thu, Jan 26, 2012 at 10:05:16PM +0100, Mario 'BitKoenig' Holbe wrote: > root@darkside:~# COLUMNS=72 dpkg -l libxcb1 | grep ^i > ii libxcb11.7-4 X C Binding Uhm, of course this has to be ii libxcb11.8-1 X C Binding ... as is proven below: > root@darkside:~# dpkg -i /var/cache/apt/archives/libxcb1_1.7-4_i386.deb > dpkg: warning: downgrading libxcb1 from 1.8-1 to 1.7-4. -- We know that communication is a problem, but the company is not going to discuss it with the employees. -- Switching supervisor, AT&T Long Lines Division signature.asc Description: Digital signature
Bug#657538: libxcb1: breaks alsamixer
Package: libxcb1 Version: 1.8-1 Severity: critical Justification: makes unrelated software on the system break Hello, since libxcb1 upgraded to 1.8-1 alsamixer segfaults on startup. Downgrading libxcb1 to 1.7-4 fixes this. The system is a typical workstation with all the GNOME-bloat (and hence also pulseaudio) installed. root@darkside:~# COLUMNS=72 dpkg -l libxcb1 | grep ^i ii libxcb11.7-4 X C Binding root@darkside:~# echo q | alsamixer Segmentation fault (core dumped) root@darkside:~# dpkg -i /var/cache/apt/archives/libxcb1_1.7-4_i386.deb dpkg: warning: downgrading libxcb1 from 1.8-1 to 1.7-4. (Reading database ... 512829 files and directories currently installed.) Preparing to replace libxcb1 1.8-1 (using .../libxcb1_1.7-4_i386.deb) ... Unpacking replacement libxcb1 ... Setting up libxcb1 (1.7-4) ... root@darkside:~# echo q | alsamixer root@darkside:~# Thanks for your work & best regards Mario -- To err is human. To really foul things up requires a computer. signature.asc Description: Digital signature
Bug#572072: python-apt 0.8 API transition: Please update computer-janitor to new API
Hello, On Fri, May 27, 2011 at 04:32:56PM +0200, Julian Andres Klode wrote: > On Tue, 2011-05-24 at 15:45 +0200, Mehdi Dogguy wrote: > > On 05/04/2011 16:48, Julian Andres Klode wrote: > > > As I wrote some time ago, the APT team would like to disable > > > the old python-apt API for Python 2.X now. > > Are you ready to start this transition? If so, please go ahead. > 0.8.0 uploaded to unstable. Increasing the other bug severities to > release critical (grave, as they are uninstallable and thus unusable is there some progress to expect on computer-janitor wrt. python-apt transition or should I simply remove the package? I just don't get it: the maintainer himself files a bug for his own package, raises its severity later and nothing appears to happen on it for more than a year. regards Mario -- Good, Fast, Cheap: Pick any two (you can't have all three). -- RFC 1925, 7a signature.asc Description: Digital signature
Bug#643006: racoon: uninstallable, dependency loop with new init-script
Package: racoon Version: 1:0.8.0-4 Severity: grave Hello, the new init-script from 1:0.8.0-4 causes a dependency loop and hence makes the package uninstallable: Setting up racoon (1:0.8.0-4) ... Installing new version of config file /etc/init.d/racoon ... insserv: There is a loop between service sendsigs and racoon if stopped insserv: loop involving service racoon at depth 4 insserv: loop involving service sendsigs at depth 3 insserv: loop involving service sysklogd at depth 2 insserv: loop involving service umountnfs at depth 8 insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header dpkg: error processing racoon (--configure): subprocess installed post-installation script returned error exit status 1 This is most likely due to: -# Required-Stop: +# Required-Stop: $remote_fs regards Mario -- Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo Inc, 1989 signature.asc Description: Digital signature
Bug#629534: Upgrade fails, resulting in unusable system (no dynamic linking)
On Fri, Jun 10, 2011 at 10:26:39AM +0200, Mario 'BitKoenig' Holbe wrote: > I did a quick survey over all my Debian machines and found /lib/ld.so > together with the "Mar 7 2001" timestamp, as already mentioned by Haegar > and others, on all "older" systems, i.e. systems initially installed > several years ago. Most of those systems never had anything else > installed than Debian packages, so this does indeed appear to be some > left-over file from any package. All right - it definitely is: ldso.postinst: 25 cd /lib ldso.postinst: 26 if [ -f ld.so.1.9.11 ]; then ldso.postinst: 27 mv -f ld.so.1.9.11 ld.so ldso.postinst: 28 ln -f ld.so ld.so.1.9.11 ldso.postinst: 29 fi regards Mario -- Tower: "Say fuelstate." Pilot: "Fuelstate." Tower: "Say again." Pilot: "Again." Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..." signature.asc Description: Digital signature
Bug#629534: Upgrade fails, resulting in unusable system (no dynamic linking)
Hello Steve, On Wed, Jun 08, 2011 at 05:17:23PM -0700, Steve Langasek wrote: > The attached (untested) patch is based on an IRC conversation with Aurélien > yesterday about this bug. If there are any other copies of ld-2.x.so in > /lib that dpkg doesn't know about, we should abort the upgrade until these > have been removed. I just stumbled over this bug while upgrading 2.13-5 to 2.13-6 when I was hit by the "A non-dpkg owned copy of the C library was found" error. I found /lib/ld.so to be the cause and removing it let me sucessfully install 2.13-6. I did a quick survey over all my Debian machines and found /lib/ld.so together with the "Mar 7 2001" timestamp, as already mentioned by Haegar and others, on all "older" systems, i.e. systems initially installed several years ago. Most of those systems never had anything else installed than Debian packages, so this does indeed appear to be some left-over file from any package. Thus, I guess the current solution is not the best choice wrt. smooth upgrades. Systems initially installed from lenny or squeeze didn't have that file. Btw: I did not experience any problems with running new processes etc. on 2.13-5. regards Mario -- Whenever you design a better fool-proof software, the genetic pool will always design a better fool. signature.asc Description: Digital signature
Bug#619711: console-setup: breaks copying keymap to initramfs
Package: console-setup
Version: 1.71
Severity: grave
Hello,
if a system's keymap needs to be loaded during the initramfs stage,
initramfs-tools' /usr/share/initramfs-tools/hooks/keymap looks for
/etc/console-setup/cached.kmap.gz
and copies it to the initramfs.
console-setup 1.71 changed the name of this file to
/etc/console-setup/cached_${CHARMAP}_$backspace$VARIANT.kmap.gz
i.e. something like
/etc/console-setup/cached_ISO-8859-15_del.kmap.gz
Hence, /etc/console-setup/cached.kmap.gz doesn't exist anymore on fresh
installed systems and is thus not copied to the initramfs anymore.
This renders systems unbootable because, for example, passphrases cannot
be entered.
This bug hides well on upgraded systems, because console-setup doesn't
remove the old /etc/console-setup/cached.kmap.gz.
There are several alternatives to fix this bug like
* symlinking the new name to the old
* moving the keymap-copying from initramfs-tools to console-setup
* updating initramfs-tools to honor the new keymap name
Most of those alternatives need to be negotiated with initramfs-tools
and probably other initramfs-creators as well.
However, at the current stage console-setup should break on
packages that depend on the old naming scheme.
Thanks for your work & regards
Mario
--
We know that communication is a problem, but the company is not going to
discuss it with the employees.
-- Switching supervisor, AT&T Long Lines Division
signature.asc
Description: Digital signature
Bug#615018: evolution-mapi: Package is uninstallable, please upgrade to 0.32
Package: evolution-mapi Version: 0.30.3-2 Severity: grave Justification: renders package unusable Hello, evolution-mapi 0.30.3-2 cannot be installed anymore on unstable, because it's built against an old evolution version. Please update the package to the current version 0.32.2. Thanks for your work & regards Mario PS: Yes, I did read #590817 ... nobody takes care about -mapi... :/ -- [mod_nessus for iauth] "scanning your system...found depreciated OS...found hole...installing new OS...please reboot and reconnect now" signature.asc Description: Digital signature
Bug#614762: bashdb: ships /usr/share/info/dir.gz
On Wed, Feb 23, 2011 at 10:36:38AM -0600, Oleksandr Moskalenko wrote: > It's upstream code in the makefiles and tests that calls install-info. That > call produces the dreaded /usr/share/info/dir.gz Well, the issues on non-Debian systems should be similar to ours if upstream installs that dir.gz. Hence, I guess, forwarding that upstream would probably make sense. Mario -- I thought the only thing the internet was good for was porn. -- Futurama signature.asc Description: Digital signature
Bug#614762: bashdb: ships /usr/share/info/dir.gz
On Wed, Feb 23, 2011 at 09:33:59AM -0600, Oleksandr Moskalenko wrote: > * Mario 'BitKoenig' Holbe [2011-02-23 10:56:25 > +0100]: > > bashdb 4.2.0.6-1 started to ship > > /usr/share/info/dir.gz > workaround. I wonder if the install-info behavior should be directed to the > attention of the TeX maintainers. Mh, could you figure out which part in the rules file did put the dir file in place? I think this would then be the right recipient for a clone/reassign bug or something like that. Thanks for the workaround. Mario -- Selbst im Hirn des weisesten Mannes gibt es einen toerichten Winkel. -- Aristoteles signature.asc Description: Digital signature
Bug#614762: bashdb: ships /usr/share/info/dir.gz
Package: bashdb Version: 4.2.0.6-1 Severity: serious Hello, bashdb 4.2.0.6-1 started to ship /usr/share/info/dir.gz which is very likely not intentional. First of all, this file is usually managed by install-info and thus gets overwritten regularly which causes bashdb's package checksums to fail. Second, shipping this file triggers install-info to switch from plain to a compressed Info directory format, which breaks info viewers that cannot handle compressed dir files, like Emacs (see #543564). Third, (re)installing or upgrading bashdb always corrupts the info directory this way. The last time such bugs showed up (see #537835 and #543911) they've been caused by an install-info transition (see Sven's comment in #543911), maybe this helps in resolving the current issue. This issue persists in 4.2.0.6-2, btw. Thanks for your work & regards Mario -- Doing it right is no excuse for not meeting the schedule. -- Plant Manager, Delphi Corporation signature.asc Description: Digital signature
Bug#608484: zutils: diverts in /bin but installs itself to /usr/bin
Package: zutils Version: 0.9~rc2-2 Severity: critical Hello, zutils diverts binaries in /bin but installs its replacements to /usr/bin. This makes the respective commands unavailable as long as /usr/bin is not (yet) mounted. I'm aware of the libstdc++ dependency that prevents zutils from being installed in /bin, but the issue described above IMHO justifies the high severity, even if it is not (easily) fixable. regards Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail signature.asc Description: Digital signature
Bug#591633: user-setup: fails to install
Package: user-setup Version: 1.32 Severity: grave Hello, user-setup 1.32 fails to install: Preparing to replace user-setup 1.31 (using .../user-setup_1.32_all.deb) ... Unpacking replacement user-setup ... Setting up user-setup (1.32) ... Template parse error near `description...@latin.utf-8: Dozvoliti logovanje na sistem kao ârootâ korisnik?', in stanza #5 of /var/lib/dpkg/info/user-setup.templates dpkg: error processing user-setup (--configure): subprocess installed post-installation script returned error exit status 9 Errors were encountered while processing: user-setup Downgrading to 1.31 works well. Probably related packages: ii adduser3.112 add and remove users and groups ii apt0.7.25.3 Advanced front-end for dpkg ii debconf1.5.33 Debian configuration management system ii dpkg 1.15.8.3 Debian package management system ii passwd 1:4.1.4.2-1change and administer password and regards Mario -- Um mit einem Mann gluecklich zu werden, muss man ihn sehr gut verstehen und ihn ein bisschen lieben. Um mit einer Frau gluecklich zu werden, muss man sie sehr lieben und darf erst gar nicht versuchen, sie zu verstehen. signature.asc Description: Digital signature
Bug#589854: grub-pc: grub-install fails after upgrade
package grub-pc fixed 589854 1.98+20100802-1 thanks Hello, this bug doesn't seem to appear (anymore?) with 1.98+20100802-1: Setting up grub-pc (1.98+20100802-1) ... Installing new version of config file /etc/grub.d/05_debian_theme ... Installation finished. No error reported. Installation finished. No error reported. Generating grub.cfg ... I'm not sure whether this was intentionally fixed as there is no changelog entry for it, so I'm not closing the bug yet, but just mark it fixed in the current version. regards Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Bug#589854: grub-pc: grub-install fails after upgrade
Hello Colin,
got a bit more time for debugging...
Short: it reads the right device but returns data from the wrong device.
Long: ... read on :)
I modified ext2.c to read some more blocks around the ext2 superblock to
see what's going on (and enough blocks to make sure some of them are not
cached yet :)).
Attached grub2-ext2-debug.patch not for inclusion but for information to
show what I did and where the outputs later come from. This is a cleaned
up version of the one where my previous snippets came from, don't try to
match the debug output from my previous comment against this code.
# strace -o grub-probe.strace grub2-1.98+20100722/build/grub-pc/grub-probe -vv
--device-map=/boot/grub/device.map --target=fs --device /dev/md0
>grub-probe.out 2>grub-probe.err
# nl grub-probe.strace > grub-probe.strace.nl
Here is a grub-probe.out snippet:
...
kern/fs.c:54: Detecting nilfs2...
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/fs.c:60: nilfs2 detection failed.
kern/fs.c:54: Detecting minix...
kern/fs.c:60: minix detection failed.
kern/fs.c:54: Detecting jfs...
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/fs.c:60: jfs detection failed.
kern/fs.c:54: Detecting udf...
kern/fs.c:60: udf detection failed.
kern/fs.c:54: Detecting iso9660...
kern/fs.c:60: iso9660 detection failed.
kern/fs.c:54: Detecting hfsplus...
kern/fs.c:60: hfsplus detection failed.
kern/fs.c:54: Detecting hfs...
kern/fs.c:60: hfs detection failed.
kern/fs.c:54: Detecting ext2...
fs/ext2.c:548: grub_disk_read(md0, 1 * 2, 0, 336, &data->sblock)
fs/ext2.c:555: grub_disk_read(md0, 0, 0, 51200, buf)
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
kern/emu/hostdisk.c:582: reusing open device `/dev/sda2'
fs/ext2.c:573: 4c 55 4b 53 xx xx 00 xx 61 65 73 00 00 00 00 00
|LUKS**..aes.|
fs/ext2.c:573: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
fs/ext2.c:573: 0020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69
|xts-plai|
fs/ext2.c:573: 0030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
|n64.|
fs/ext2.c:573: 0040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
|sha256..|
fs/ext2.c:573: 0050 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
||
fs/ext2.c:573: 0060 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
||
fs/ext2.c:573: 0070 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
||
fs/ext2.c:573: 0080 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
||
fs/ext2.c:573: 0090 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
||
fs/ext2.c:573: 00a0 xx xx xx xx xx xx xx xx 66 63 31 37 39 39 37 35
|fc179975|
fs/ext2.c:573: 00b0 2d 64 35 33 32 2d 34 62 66 66 2d 39 39 32 61 2d
|-d532-4bff-992a-|
fs/ext2.c:573: 00c0 64 33 31 34 35 34 33 32 38 66 36 64 00 00 00 00
|d31454328f6d|
...
Excuse me that I don't like to disclose the whole LUKS header.
Note that /dev/md0, i.e. /dev/sda2 is no LUKS device but an ext2 fs.
I found instead of reading /dev/sda2 as member of /dev/md0 as it claims
it appears to read /dev/sdf which is a member of /dev/md74.
But strace.out shows it doesn't really: here is a grub-probe.strace.nl
snippet:
...
580 open("/dev/sda2", O_RDONLY|O_SYNC|O_LARGEFILE) = 10
...
1651 open("/dev/sdf", O_RDONLY|O_LARGEFILE) = 23
1652 fstat64(23, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 80), ...}) = 0
1653 ioctl(23, BLKGETSIZE64, 0xbfd4e0b8) = 0
1654 close(23) = 0
...
1714 read(10, ..., 4096) = 4096
1715 _llseek(10, 51200, [51200], SEEK_SET) = 0
1716 read(10, ..., 4096) = 4096
1717 write(1, "da2'\nkern/fs.c:60: nilfs2 detect"..., 4096) = 4096
1718 write(1, " 00 00 00 00 00 00 00 xx xx 00 "..., 4096) = 4096
1719 write(1, ".|\nfs/ext2.c:573: 04a0 "..., 4096) = 4096
From line 1716 I searched backwards for " = 10$" and found line 580 as
first hit. Also from line 1716 I searched backwards for sdf and found
line 1651 as first hit.
It seems like grub_disk_read() really reads /dev/sda2 as it claims but
does return data from /dev/sdf ... looks like grub's internal cache is
somewhat out of sync.
For completeness I also attached /proc/mdstat, /etc/fstab, and
/proc/mounts. This still requires a map from raid- to crypto-devices,
here is it:
/dev/md1/dev/dm-0 (/dev/mapper/md1)
/dev/md2/dev/dm-1 (/dev/mapper/md2)
/dev/md3
Bug#589854: Bug#589873: grub-pc: fails to install in mbr during postinstall
On Sat, Jul 24, 2010 at 11:44:00PM +0100, Colin Watson wrote: > In that case, Mario, please undo your incorrect merging of your bug with > Achim's, since they manifestly have different causes. I'm just going to bounce my newer comments to 589854, please don't get confused. I have no idea how to do this through the BTS. Mario -- The question of whether a computer can think is no more interesting than the question of whether a submarine can swim. -- E. W. Dijkstra signature.asc Description: Digital signature
Bug#589873: grub-pc: fails to install in mbr during postinstall
package grub-pc unmerge 589854 thanks On Sat, Jul 24, 2010 at 11:44:00PM +0100, Colin Watson wrote: > In that case, Mario, please undo your incorrect merging of your bug with > Achim's, since they manifestly have different causes. -- We are the Bore. Resistance is futile. You will be bored. signature.asc Description: Digital signature
Bug#589873: grub-pc: fails to install in mbr during postinstall
On Sat, Jul 24, 2010 at 06:36:01AM +0200, Mario 'BitKoenig' Holbe wrote: > On Thu, Jul 22, 2010 at 09:37:15PM +0100, Colin Watson wrote: > > Could you try 1.98+20100722-1 once it's available? I think it may fix > > this. > Sad to say: nope, it doesn't... > > /usr/sbin/grub-probe: info: opening md0. > kern/disk.c:245: Opening `md0'... > disk/raid.c:134: md0: total_devs=3, disk_size=481664 > disk/raid.c:163: md0: level=1, total_sectors=481664 > ... > kern/fs.c:54: Detecting ext2... > kern/fs.c:60: ext2 detection failed. Did a little more debugging: kern/fs.c:54: Detecting ext2... fs/ext2.c:855: grub_ext2_dir(): grub_ext2_mount() fs/ext2.c:541: grub_ext2_mount() fs/ext2.c:547: grub_ext2_mount(): grub_disk_read() kern/disk.c:396: grub_disk_read(disk = md0, sector = 2, offset = 0, size = 336) kern/disk.c:407: grub_disk_read() after grub_disk_adjust_range(): sector = 2, offset = 0) fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:571: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fs/ext2.c:575: grub_ext2_mount(): EXT2_MAGIC: 0 kern/fs.c:60: ext2 detection failed. The dump is data->sblock in grub_ext2_mount(). There are no real read()s in strace around this, so the data seems to come from grub's cache. But there's data on disk: # hexdump -C /dev/md0 ... 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0400 50 eb 00 00 c0 ac 03 00 09 2f 00 00 31 f7 02 00 |Pë..À¬.../..1÷..| 0410 65 ea 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |eê..| 0420 00 20 00 00 00 20 00 00 d8 07 00 00 68 6b 47 4c |. ... ..Ø...hkGL| 0430 42 13 4b 4c 06 00 14 00 53 ef 00 00 02 00 00 00 |B.KLSï..| 0440 f3 0d 42 4c 00 4e ed 00 00 00 00 00 01 00 00 00 |ó.BL.Ní.| 0450 00 00 00 00 0b 00 00 00 80 00 00 00 38 00 00 00 |8...| 0460 02 00 00 00 01 00 00 00 d0 fc 44 a3 cd 4a 42 79 |ÐüD£ÍJBy| 0470 b5 88 ce ef 6f 45 e1 81 62 6f 6f 74 00 00 00 00 |µ.ÎïoEá.boot| 0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || # hexdump -C /dev/sda2 ... 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0400 50 eb 00 00 c0 ac 03 00 09 2f 00 00 31 f7 02 00 |Pë..À¬.../..1÷..| 0410 65 ea 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |eê..| 0420 00 20 00 00 00 20 00 00 d8 07 00 00 68 6b 47 4c |. ... ..Ø...hkGL| 0430 42 13 4b 4c 06 00 14 00 53 ef 00 00 02 00 00 00 |B.KLSï..| 0440 f3 0d 42 4c 00 4e ed 00 00 00 00 00 01 00 00 00 |ó.BL.Ní.| 0450 00 00 00 00 0b 00 00 00 80 00 00 00 38 00 00 00 |8...| 0460 02 00 00 00 01 00 00 00 d0 fc 44 a3 cd 4a 42 79 |ÐüD£ÍJBy| 0470 b5 88 ce ef 6f 45 e1 81 62 6f 6f 74 00 00 00 00 |µ.ÎïoEá.boot| 0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || regards Mario -- Das Gegenteil einer trivialen Wahrheit ist falsch; das Gegenteil einer grossen Wahrheit ist ebenfalls wahr. -- Niels Bohr signature.asc Description: Digital signature
Bug#589873: grub-pc: fails to install in mbr during postinstall
On Thu, Jul 22, 2010 at 09:37:15PM +0100, Colin Watson wrote: > Could you try 1.98+20100722-1 once it's available? I think it may fix > this. Sad to say: nope, it doesn't... Setting up grub-pc (1.98+20100722-1) ... /usr/sbin/grub-probe: error: unknown filesystem. Auto-detection of a filesystem module failed. Please specify the module with the option `--modules' explicitly. # /usr/sbin/grub-probe -vv --device-map=/boot/grub/device.map --target=fs --device /dev/md0 ... /usr/sbin/grub-probe: info: opening md0. kern/disk.c:245: Opening `md0'... disk/raid.c:134: md0: total_devs=3, disk_size=481664 disk/raid.c:163: md0: level=1, total_sectors=481664 ... kern/fs.c:54: Detecting ext2... kern/fs.c:60: ext2 detection failed. ... # mdadm -E /dev/sda2 /dev/sda2: Magic : a92b4efc Version : 0.90.00 ... Raid Level : raid1 Used Dev Size : 240832 (235.23 MiB 246.61 MB) Array Size : 240832 (235.23 MiB 246.61 MB) Raid Devices : 3 Total Devices : 2 Preferred Minor : 0 ... regards Mario -- Selbst im Hirn des weisesten Mannes gibt es einen toerichten Winkel. -- Aristoteles signature.asc Description: Digital signature
Bug#589873: grub-pc: fails to install in mbr during postinstall
package grub-pc severity 589854 grave merge 589854 589873 thanks On Wed, Jul 21, 2010 at 10:06:51PM +0100, Colin Watson wrote: > sh -x /usr/sbin/grub-install $(readlink -f > /dev/disk/by-id/ata-WDC_WD1002FBYS-02A6B0_WD-WMATV5728872) > ... and post the output to this bug. I'm not Achim, but since our bugs are very likely equal... :) # sh -x /usr/sbin/grub-install /dev/sda [... all the copy-stuff removed...] + test -f /usr/share/locale/zh_TW.Big5/LC_MESSAGES/grub.mo + test -f /usr/share/locale/zu/LC_MESSAGES/grub.mo + /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=device /boot/grub + grub_device=/dev/md0 + test -f /boot/grub/grubenv + /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs --device /dev/md0 /usr/sbin/grub-probe: error: unknown filesystem. + fs_module= + test x = x -a x = x + echo Auto-detection of a filesystem module failed. Auto-detection of a filesystem module failed. + echo Please specify the module with the option `--modules' explicitly. Please specify the module with the option `--modules' explicitly. + exit 1 # /usr/sbin/grub-probe -v --device-map=/boot/grub/device.map --target=fs --device /dev/md0 /usr/sbin/grub-probe: info: the size of hd0 is 976773168. ... /usr/sbin/grub-probe: info: the size of hd5 is 2930277168. /usr/sbin/grub-probe: info: opening md0. /usr/sbin/grub-probe: error: unknown filesystem. # /usr/sbin/grub-probe -vv --device-map=/boot/grub/device.map --target=fs --device /dev/md0 /usr/sbin/grub-probe: info: opening md0. kern/disk.c:245: Opening `md0'... disk/raid.c:134: md0: total_devs=3, disk_size=481664 disk/raid.c:163: md0: level=1, total_sectors=481664 kern/fs.c:54: Detecting afs... kern/fs.c:60: afs detection failed. kern/fs.c:54: Detecting afs_be... kern/fs.c:60: afs_be detection failed. kern/fs.c:54: Detecting befs... kern/fs.c:60: befs detection failed. kern/fs.c:54: Detecting befs_be... kern/fs.c:60: befs_be detection failed. kern/fs.c:54: Detecting xfs... kern/fs.c:60: xfs detection failed. kern/fs.c:54: Detecting ufs1... kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/fs.c:60: ufs1 detection failed. kern/fs.c:54: Detecting ufs2... kern/fs.c:60: ufs2 detection failed. kern/fs.c:54: Detecting sfs... kern/fs.c:60: sfs detection failed. kern/fs.c:54: Detecting reiserfs... kern/fs.c:60: reiserfs detection failed. kern/fs.c:54: Detecting ntfs... kern/fs.c:60: ntfs detection failed. kern/fs.c:54: Detecting nilfs2... kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/fs.c:60: nilfs2 detection failed. kern/fs.c:54: Detecting minix... kern/fs.c:60: minix detection failed. kern/fs.c:54: Detecting jfs... kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/emu/hostdisk.c:582: reusing open device `/dev/sda2' kern/fs.c:60: jfs detection failed. kern/fs.c:54: Detecting udf... kern/fs.c:60: udf detection failed. kern/fs.c:54: Detecting iso9660... kern/fs.c:60: iso9660 detection failed. kern/fs.c:54: Detecting hfsplus... kern/fs.c:60: hfsplus detection failed. kern/fs.c:54: Detecting hfs... kern/fs.c:60: hfs detection failed. kern/fs.c:54: Detecting ext2... kern/fs.c:60: ext2 detection failed. kern/fs.c:54: Detecting fat... kern/fs.c:60: fat detection failed. kern/fs.c:54: Detecting cpiofs... kern/fs.c:60: cpiofs detection failed. kern/fs.c:54: Detecting tarfs... kern/fs.c:60: tarfs detection failed. kern/fs.c:54: Detecting affs... kern/fs.c:60: affs detection failed. /usr/sbin/grub-probe: error: unknown filesystem. # grep -A2 ^md0 /proc/mdstat md0 : active raid1 sda2[0] sdb2[1] 240832 blocks [3/2] [UU_] # grep ^/dev/md0 /etc/fstab /dev/md0/boot ext2defaults,nosuid,nodev,noexec0 2 # Btw... it doesn't matter whether the array is degraded or not. regards Mario -- I heard, if you play a NT-CD backwards, you get satanic messages... That's nothing. If you play it forwards, it installs NT. signature.asc Description: Digital signature
Bug#584858: qtoctave: package upgrade collides with quicktime-utils
Package: qtoctave Version: 0.9.1-1 Severity: grave Hello, qtoctave upgrade to 0.9.1-1 fails due to a file-conflict with quicktime-utils: Preparing to replace qtoctave 0.8.2+dfsg-2 (using .../qtoctave_0.9.1-1_i386.deb) ... Unpacking replacement qtoctave ... dpkg: error processing /var/cache/apt/archives/qtoctave_0.9.1-1_i386.deb (--unpack): trying to overwrite '/usr/bin/qtinfo', which is also in package quicktime-utils 3:1.1.5-0.1 dpkg-deb: subprocess paste killed by signal (Broken pipe) Processing triggers for menu ... Errors were encountered while processing: /var/cache/apt/archives/qtoctave_0.9.1-1_i386.deb Even if I have installed debian-multimedia's version of quicktime-utils, Debian's quicktime-utils 2:1.1.5-1 does also contain /usr/bin/qtinfo. regards Mario -- I thought the only thing the internet was good for was porn. -- Futurama signature.asc Description: Digital signature
Bug#583727: fetch-crl: fails to install
Package: fetch-crl Version: 2.8.4-1 Severity: grave Hello, fetch-crl fails to install: Unpacking fetch-crl (from .../fetch-crl_2.8.4-1_all.deb) ... Processing triggers for man-db ... Setting up fetch-crl (2.8.4-1) ... update-rc.d: error: start|stop arguments not terminated by "." usage: update-rc.d [-n] [-f] remove update-rc.d [-n] defaults [NN | SS KK] update-rc.d [-n] start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing fetch-crl (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fetch-crl regards Mario -- "Why are we hiding from the police, daddy?" | J. E. Guenther "Because we use SuSE son, they use SYSVR4." | de.alt.sysadmin.recovery signature.asc Description: Digital signature
Bug#578426: ocrfeeder: fails to install due to file conflict with calibre
Package: ocrfeeder Version: 0.6.6-1 Severity: serious Hello, ocrfeeder fails to install: Selecting previously deselected package ocrfeeder. Unpacking ocrfeeder (from .../ocrfeeder_0.6.6-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/ocrfeeder_0.6.6-1_all.deb (--unpack): trying to overwrite '/usr/share/pyshared/odf/presentation.py', which is also in package calibre 0:0.5.14+dfsg-1 Errors were encountered while processing: /var/cache/apt/archives/ocrfeeder_0.6.6-1_all.deb regards Mario -- The Encyclopedia Galactica, in its chapter on Love states that it is far too complicated to define. The Hitchhiker's Guide to the Galaxy has this to say on the subject of love: Avoid, if at all possible. signature.asc Description: Digital signature
Bug#558079: dstat: install fails due to compile error
Package: dstat Version: 0.7.0-1 Severity: serious Hello, the installation of dstat fails due to a compile error in postinst: Preparing to replace dstat 0.6.9-1 (using .../archives/dstat_0.7.0-1_all.deb) ... Unpacking replacement dstat ... Processing triggers for man-db ... Setting up dstat (0.7.0-1) ... Compiling /usr/share/dstat/dstat_mysql5_conn.py ... File "/usr/share/dstat/dstat_mysql5_conn.py", line 39 self.set2['Threads'] = float(thread[1] / float(max[1]) 1.0 * 100) ^ SyntaxError: invalid syntax pycentral: pycentral pkginstall: error byte-compiling files (54) pycentral pkginstall: error byte-compiling files (54) dpkg: error processing dstat (--configure): subprocess installed post-installation script returned error exit status 1 $ COLUMNS=80 dpkg -l python python-central | grep ^.i ii python 2.5.4-2An interactive high-level object-oriented la ii python-central 0.6.13 register and build utility for Python packag $ python --version Python 2.5.4 regards Mario -- Independence Day: Fortunately, the alien computer operating system works just fine with the laptop. This proves an important point which Apple enthusiasts have known for years. While the evil empire of Microsoft may dominate the computers of Earth people, more advanced life forms clearly prefer Macs. signature.asc Description: Digital signature
Bug#558078: extlinux: install fails due to overlap with syslinux
Package: extlinux Version: 2:3.83+dfsg-2 Severity: serious Hello, the installation of extlinux fails due to a file-conflict with syslinux: Unpacking extlinux (from .../extlinux_2%3a3.83+dfsg-2_i386.deb) ... dpkg: error processing /var/cache/apt/archives/extlinux_2%3a3.83+dfsg-2_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/extlinux.1.gz', which is also in package syslinux 2:3.83+dfsg-2 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/extlinux_2%3a3.83+dfsg-2_i386.deb $ COLUMNS=80 dpkg -l syslinux\* | grep ^.i ii syslinux 2:3.83+dfsg-2 utilities for the syslinux bootloaders ii syslinux-commo 2:3.83+dfsg-2 Kernel loader which uses a FAT, ext2/3 or is regards Mario -- Wine is fine, but wiskey is quicker. Suicide is slow with liquor. -- Ozzy Osbourne signature.asc Description: Digital signature
Bug#557628: rtmpdump: install fails - conflict with flvstreamer
On Mon, Nov 23, 2009 at 03:06:04PM +, Martin Michlmayr wrote: > * Mario 'BitKoenig' Holbe [2009-11-23 13:01]: > > Package: rtmpdump > > Version: 1.9-0.0 > This pacage doesn't seem to be in Debian. Do you know where you got I'm sorry, this was my fault - I just forgot to check where it came from. It's from Debian-Multimedia and I did already forward the issue to Christian. How do I have to proceed with this bug? Can I simply close it or does it require some special handling? regards Mario -- Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes. -- Walt Whitman signature.asc Description: Digital signature
Bug#557628: rtmpdump: install fails - conflict with flvstreamer
Package: rtmpdump Version: 1.9-0.0 Severity: serious Hello, the installation of rtmpdump fails due to a file-conflict with flvstreamer: Unpacking rtmpdump (from .../rtmpdump_1.9-0.0_i386.deb) ... dpkg: error processing /var/cache/apt/archives/rtmpdump_1.9-0.0_i386.deb (--unpack): trying to overwrite '/usr/bin/streams', which is also in package flvstreamer 0:1.9-1 Errors were encountered while processing: /var/cache/apt/archives/rtmpdump_1.9-0.0_i386.deb regards Mario -- bjmg: ja, logik ist mein fachgebiet. das liegt im gen in welchem? im zweiten X signature.asc Description: Digital signature
Bug#555200: ninja: postinst fails
Package: ninja Version: 0.1.2-4 Severity: serious Hello, ninja's postinst fails due to the shipped conffile: Preparing to replace ninja 0.1.2-3 (using .../ninja_0.1.2-4_i386.deb) ... Unpacking replacement ninja ... Setting up ninja (0.1.2-4) ... /etc/init.d/ninja: 27: escalation: not found Starting : log: reading configuration file: /etc/ninja/ninja.conf log: ninja version 0.1.2 initializing log: magic group: gid=0 (root) log: logfile: (null) die: error: `(null)' is not a regular file invoke-rc.d: initscript ninja, action "start" failed. dpkg: error processing ninja (--configure): subprocess installed post-installation script returned error exit status 1 regards Mario -- But after a while I learned the trick of speaking fast. You don't have to think any faster; just use twice as many words to say everything. -- Paul Graham signature.asc Description: Digital signature
Bug#544669: cryptsetup: /sbin/blkid is not in initramfs
Package: cryptsetup Version: 2:1.0.7-2 Severity: grave Hello, cryptsetup 1.0.7-2 recommends to replace vol_id and un_vol_id by blkid and un_blkid. Both of these scripts depend on /sbin/blkid. However, /sbin/blkid is not available in the initramfs image. Considering your changelog statement that udev will remove vol_id soon, I'm not sure whether this bug should really be fixed in cryptsetup itself or if /sbin/blkid should be included in the initramfs either by initramfs-tools or util-linux directly. regards Mario -- User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten signature.asc Description: Digital signature
Bug#543911: acct: ships /usr/share/info/dir.gz
Package: acct Version: 6.4~pre1-8 Severity: serious Hello, acct 6.4~pre1-8 started to ship /usr/share/info/dir.gz which is very likely not intentional. First of all, this file is usually managed by install-info and thus gets overwritten regularly which causes acct's package checksums to fail. Second, shipping this file triggers install-info to switch from plain to a compressed Info directory format, which breaks info viewers that cannot handle compressed dir files, like Emacs (see #543564). Third, (re)installing or upgrading acct always corrupts the Info directory this way. Fourth, because of this file and a similar bug, acct currently conflicts with opencubicplayer (#537835): Preparing to replace acct 6.4~pre1-7+b1 (using .../acct_6.4~pre1-8_i386.deb) ... Stopping process accounting: Turning off process accounting. acct. Unpacking replacement acct ... dpkg: error processing /var/cache/apt/archives/acct_6.4~pre1-8_i386.deb (--unpack): trying to overwrite `/usr/share/info/dir.gz', which is also in package opencubicplayer Starting process accounting: Turning on process accounting, file set to '/var/log/account/pacct'. acct. Since this is the second bug of this kind i'm writing within quite a short time: Maybe you find some hints why packages start shipping /usr/share/info/dir.gz while resolving this issue - if you do so, please reassign this bug or file another bug report against the causative package. Thanks for your work & regards Mario -- File names are infinite in length where infinity is set to 255 characters. -- Peter Collinson, "The Unix File System" signature.asc Description: Digital signature
Bug#542265: sendmail-base and logcheck-database: error when trying to install together
On Sat, Aug 22, 2009 at 01:30:56PM -0400, Frédéric Brière wrote: > Alright, I'll go ahead and commit this fix. Now where you have agreed on how to handle this file, you could probably also find a solution for /etc/logcheck/ignore.d.server/ntp - which is shipped in logcheck-database as well as ntp since quite a long time (and just does not collide because of a Replaces: directive in ntp). just my 2 cents, Mario -- Evidently men are more intelligent than women. Every woman on earth believes that men should be able to read minds. Every man knows this is impossible. Ergo, we are more intelligent. signature.asc Description: Digital signature
Bug#537830: timidity: check of /usr/share/doc/* in init-script violates policy
On Tue, Jul 21, 2009 at 12:49:13PM +0200, Mario 'BitKoenig' Holbe wrote: > If you think about an upgrade-path for the conf-files, I'm not sure > whether unchanged obsolete conffiles get removed automagically in the > meantime or not. I now got a peek on 2.13.2-31. It seems /etc/default/timidity is now completely gone - it's neither shipped with timidity nor with timidity-daemon, which isn't bad at all, IMHO. However, I have 2 points regarding this: 1. The file remains obsolete on the filesystem, maybe you would like to add it to timidity's preinst rm_conffile section. 2. The new default TIM_ALSASEQPARAMS="-B2,8" in the init-script differs from the old default TIM_ALSASEQPARAMS="-Os" in the now obsolete /etc/default/timidity file, I don't know if this matters. Thanks for your work & best regards Mario -- There are trivial truths and the great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true. -- Niels Bohr signature.asc Description: Digital signature
Bug#537830: timidity: check of /usr/share/doc/* in init-script violates policy
On Tue, Jul 21, 2009 at 12:12:25PM +0200, Joost Yervante Damad wrote: > The reason I didn't take that approach is because I couldn't easily provide a > transparent upgrade path here, but since indeed the current approach violates > policy I think I will go for /etc/init.d/timidity in timidity-daemon. Hm, i thought so. To ease upgrades you could, for example, recommend timidity-daemon. But this would change the default behaviour from ALSA Sequencer not enabled to enabled. If you think about an upgrade-path for the conf-files, I'm not sure whether unchanged obsolete conffiles get removed automagically in the meantime or not. Mario -- The question of whether a computer can think is no more interesting than the question of whether a submarine can swim. -- E. W. Dijkstra signature.asc Description: Digital signature
Bug#537830: timidity: check of /usr/share/doc/* in init-script violates policy
Package: timidity Version: 2.13.2-29 Severity: serious Hello, timidity's init-script test for the existence of /usr/share/doc/timidity-daemon violates the Debian policy 12.3.: "Packages must not require the existence of any files in `/usr/share/doc/' in order to function." A far more clean split between timidity and timidity-daemon would be to just move /etc/init.d/timidity and /etc/default/timidity to timidity-daemon since they are not used otherwise in timidity itself than for daemon-purposes. This would also simplify the init-script code a little bit. Thanks for your work & regards Mario -- We know that communication is a problem, but the company is not going to discuss it with the employees. -- Switching supervisor, AT&T Long Lines Division signature.asc Description: Digital signature
Bug#500460: oss-compat: modules are not loaded
On Sun, Nov 30, 2008 at 09:11:52PM +0100, Sven Joachim wrote: > Am 30.11.2008 um 14:29 schrieb Mario 'BitKoenig' Holbe: > > What about just not installing oss-compat when you don't like to have > > the OSS-emu modules loaded? > Unfortunately this is not possible for many people, any KDE program will > drag it in via the kdelibs4c2a -> libarts1c2a -> oss-compat dependency File a bug against libarts1c2a to make this a recommend? -- Computer Science is no more about computers than astronomy is about telescopes. -- E. W. Dijkstra signature.asc Description: Digital signature
Bug#500460: oss-compat: modules are not loaded
On Sun, Nov 30, 2008 at 02:13:42PM +0100, Jarek Kami?ski wrote:
> What about handling it via kernel module autoloading? oss-compat would
> create /dev/{audio,dsp} and OSS would get loaded only when it's needed.
Apart from kernel module autoloading being out of date...
What about just not installing oss-compat when you don't like to have
the OSS-emu modules loaded?
> This approach won't reintroduce #315455 and #499695.
It would. Cite from #315455:
"Some apps first try OSS before trying ALSA"
Following your suggestion, this would load the OSS-emu modules.
I didn't look at the other report.
Mario
--
It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories instead of theories
to suit facts. -- Sherlock Holmes by Arthur Conan Doyle
signature.asc
Description: Digital signature
Bug#504336: watchdog: /etc/init.d/watchdog restart fails
On Mon, Nov 03, 2008 at 09:33:21AM +0100, Michael Meskes wrote: > The big question is why does it work on all my systems. Hmm... Hmmm, /etc/init.d/watchdog restart should fail on your systems as well. It doesn't print any errors, you only see the problem in syslog and when you check your processes afterwards: you see both, wd_keepalive and watchdog running - the watchdog binary continues running, but it doesn't touch /dev/watchdog, though. On upgrade it depends on whether you have installed invoke-rc.d (sysv-rc), since only then postinst calls restart. Otherwise it calls stop/start - which goes well, of course. Mario -- Und wie jede Sprache, so hat auch PHP ein Anwendungsgebiet, fuer das es besonders gut geeignet ist. Soweit ich sehen kann, handelt es sich dabei um das sogenannte "ins Knie schiessen". -- Volker Birk, de.alt.sysadmin.recovery signature.asc Description: Digital signature
Bug#488219: lynx: claims to support lynx-ssl but doesn't support HTTPS URLs
On Fri, Jun 27, 2008 at 07:57:46PM +0200, Andreas Metzler wrote: > (currently shipped in package lynx-cur) the only thing to "fix" this > bug is to stop providing lynx-ssl. Yes. > Why should this bug be severity "serious"? Because the package claims things it cannot hold. It's just as formal as stopping to build against OpenSSL(wrapper). However, it's easy to fix, so this should not be a big issue at all. Mario -- talk softly and carry a keen sword signature.asc Description: Digital signature
Bug#488219: lynx: claims to support lynx-ssl but doesn't support HTTPS URLs
Package: lynx Version: 2.8.6-2.1 Severity: serious Hello, with 2.8.6-2.1 lynx stopped linking against a SSL library and thus lynx complains when it is requested to open a https:// URL: Alert!: This client does not contain support for HTTPS URLs. However, the package still claims to replace and provide lynx-ssl, which is obviously not true anymore. regards Mario -- But after a while I learned the trick of speaking fast. You don't have to think any faster; just use twice as many words to say everything. -- Paul Graham signature.asc Description: Digital signature
Bug#486822: rar: fails to install
Package: rar Version: 1:3.8b2-1 Severity: grave Hello, rar 1:3.8b2-1 fails to install: Preparing to replace rar 1:3.7.1-2 (using .../rar_1%3a3.8b2-1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/rar_1%3a3.8b2-1_i386.deb (--unpack): subprocess pre-installation script returned error exit status 10 regards Mario -- $ make fire Don't know how to make fire $ Why not? No match signature.asc Description: Digital signature
Bug#486656: ike: package installation fails
Package: ike Version: 2.0.3+dfsg-1 Severity: serious Hello, the ike package installation fails if racoon is present on the system: Setting up ike (2.0.3+dfsg-1) ... Starting Shrew Soft IKE daemon...ii : reading config /etc/iked.conf !! : socket bind failed daemon network configuration failed ( line 9, col 15 ) failed! invoke-rc.d: initscript ike, action "start" failed. dpkg: error processing ike (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of ike-qtgui: ike-qtgui depends on ike; however: Package ike is not configured yet. dpkg: error processing ike-qtgui (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: ike ike-qtgui This is obviously due to racoon listening on IKE port 500 as well. From the package itself it becomes not clear if ike and racoon could co-exist (i.e. vpnc and racoon can, because vpnc does not neccessarily need to listen on port 500 for IKE), if they both serve exactly the same purpose, if ike is a more advanced racoon or whatever. If ike definitely needs to listen at port 500, it should probably just conflict on racoon (and probably even provide it? - if it provides interface compatibility). regards Mario -- $ make fire Don't know how to make fire $ Why not? No match signature.asc Description: Digital signature
Bug#479504: libdigest-md4-perl: uninstallable due to libperl transition
Package: libdigest-md4-perl Version: 1.5.dfsg-1.2 Severity: serious Hello, perl currently transits from 5.8.8 to 5.10.0. This breaks libdigest-md4-perl which depends on perlapi-5.8.8. Could you please instead depend on perlapi-5.10.0. Thanks for your work & regards Mario -- I heard, if you play a NT-CD backwards, you get satanic messages... That's nothing. If you play it forwards, it installs NT. signature.asc Description: Digital signature
Bug#479494: python-ctypes: uninstallable due to libffi4 dependency
Package: python-ctypes Version: 1.0.2-4 Severity: serious Hello, currently, python-ctypes does not install due to it's dependency on libffi4 which has intentionally stopped building by the gcc-maintainers starting with gcc-4.3 (4.3.0-4) - see also #479115. Could you please instead depend on libffi5. Thanks for your work & regards Mario -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: Digital signature
Bug#443511: closed by Manoj Srivastava <[EMAIL PROTECTED]> (Bug#443511: fixed in fvwm 1:2.5.23-2)
On Sat, Sep 22, 2007 at 06:54:04AM +, Debian Bug Tracking System wrote: >* Bug fix: "fvwm: postinst fails", thanks to Mario 'BitKoenig' > Holbe. Added a Section field to doc-base file. Funny thing is, this > did not fail to install for me -- I wonder why. (Closes: > #443511). Hm, do you have doc-base installed? doc-base: /usr/sbin/install-docs ii doc-base 0.8.5 utilities to manage online documentation Mario -- But after a while I learned the trick of speaking fast. You don't have to think any faster; just use twice as many words to say everything. -- Paul Graham signature.asc Description: Digital signature
Bug#443511: fvwm: postinst fails
Package: fvwm Version: 1:2.5.23-1 Severity: serious Hello, postinst of 1:2.5.23-1 fails: Setting up fvwm (1:2.5.23-1) ... Error in `/usr/share/doc-base/fvwm', line 12: `Section' value not specified dpkg: error processing fvwm (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: fvwm installation script returned error exit status 100. Press to continue. regards Mario -- We know that communication is a problem, but the company is not going to discuss it with the employees. -- Switching supervisor, AT&T Long Lines Division signature.asc Description: Digital signature
Bug#411961: watchdog: wd_keepalive uses /KA_PIDFILE as pidfile
Package: watchdog Version: 5.3-1 Severity: grave Hello, since 5.3-1 wd_keepalive stores it's pid in /KA_PIDFILE and not in /var/run/wd_keepalive.pid anymore. This breaks the wd_keepalive init-script. Thanks for your work & regards Mario -- Oh Du mein Koenig ... Eine Netzgroesse schrieb mal sinngemaess: Du musst es so lesen wie ich es meine, nicht so wie ich es schreibe. Ich meine es natuerlich so, wie Du es schreibst 8--) O.G. Schwenk - de.comm.chatsystems signature.asc Description: Digital signature
Bug#400389: xterm: installation fails
Package: xterm Version: 222-2 Severity: grave Hello, xterm 222-2 fails to install: Setting up xterm (222-2) ... Installing new version of config file /etc/X11/app-defaults/KOI8RXTerm ... error in control file: `Format' value not specified at /usr/sbin/install-docs line 699, line 22. dpkg: error processing xterm (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: xterm regards Mario -- When Bruce Schneier uses double ROT13 encryption, the ciphertext is totally unbreakable. signature.asc Description: Digital signature
Bug#398797: gradm: fails to install
On Thu, Nov 16, 2006 at 05:58:58AM -0800, Steve Langasek wrote: > done -- in the general case you get a 30 return /after/ it's been shown to > the user, since the first time it's called is normally when it does get > displayed... Ah, now I got it - and I can also explain it now :) The messages which I did paste to the bug report was from a subsequent `dselect install' - after a downgrade back to the previous version inbetween (to get a clean block to paste into the bug report - well, obviously it was a bit too "clean" then ;)). This, in turn, means the message has already been shown to me and was flagged seen in the debconf db. And thus the pre-config failed in subsequent attempts. When I remove the seen flag in the debconf db, the config-script doesn't fail in pre-config stage but shows me the message. However, the postinst does still fail even then, of course. Mario -- File names are infinite in length where infinity is set to 255 characters. -- Peter Collinson, "The Unix File System" signature.asc Description: Digital signature
Bug#398797: gradm: fails to install
On Thu, Nov 16, 2006 at 05:12:59AM -0800, Steve Langasek wrote: > No, the postinst is fine; the failure is in the config script which it > calls, whose error exit propagates to the postinst. > An exit code of 30 happens if the message isn't displayed to the user. Hm, if the call to /usr/share/debconf/confmodule in postinst exits 30 because gradm/deprecated isn't (yet) displayed to the user, i'm quite sure it does the same in config, where the script then is immediately aborted due to -e - so it never reaches the db_input line, not to mention db_go :) Mario -- I thought the only thing the internet was good for was porn. -- Futurama signature.asc Description: Digital signature
Bug#398797: gradm: fails to install
On Wed, Nov 15, 2006 at 11:01:51PM -0800, Steve Langasek wrote: > On Wed, Nov 15, 2006 at 04:38:39PM +0100, Mario 'BitKoenig' Holbe wrote: > > gradm version 1.9.15-2.1 fails to install: > Are you trying to use the non-interactive front-end? for debconf? No, my debconf frontend is Dialog. I think the failing postinst is because the postinst script does only contain: #!/bin/sh -e . /usr/share/debconf/confmodule nothing more. And I assume this returns something != 0 no matter what debconf frontend is used. Mario -- Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht? signature.asc Description: Digital signature
Bug#398797: gradm: fails to install
Package: gradm Version: 1.9.15-2.1 Severity: grave Hello, gradm version 1.9.15-2.1 fails to install: Preconfiguring packages ... gradm failed to preconfigure, with exit status 30 (Reading database ... 229400 files and directories currently installed.) Preparing to replace gradm 1.9.15-2 (using .../gradm_1.9.15-2.1_i386.deb) ... Unpacking replacement gradm ... Setting up gradm (1.9.15-2.1) ... dpkg: error processing gradm (--configure): subprocess post-installation script returned error exit status 30 Errors were encountered while processing: gradm Downgrading back to 1.9.15-2 works. regards Mario -- It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. -- Dijkstra signature.asc Description: Digital signature
Bug#396716: closed by Alberto Gonzalez Iniesta <[EMAIL PROTECTED]> (Bug#396716: fixed in irda-utils 0.9.18-4)
Hi, On Fri, Nov 10, 2006 at 04:18:15AM -0800, Debian Bug Tracking System wrote: > #396716: irda-utils: fails to install, > It has been closed by Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>. >* Added '-e' to sysctl calls so that a bad kernel/package > configuration won't stop the package installation. > (Closes: #396716) hmmm, could you do this for the stop-part, too? [EMAIL PROTECTED]:~# dpkg --purge irda-utils (Reading database ... 230020 files and directories currently installed.) Removing irda-utils ... Stopping IrDA service: irattacherror: "net.irda.discovery" is an unknown key invoke-rc.d: initscript irda-utils, action "stop" failed. dpkg: error processing irda-utils (--purge): subprocess pre-removal script returned error exit status 255 Starting IrDA service: irattach. Errors were encountered while processing: irda-utils regards Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Bug#397367: lirc-modules-source: builds well for 2.4.27 but freezes system at modprobe
Package: lirc-modules-source Version: 0.8.0-9 Severity: grave Hello, building lirc-modules from 0.8.0-9 on kernel 2.4.27 works well, but a subsequent modprobe lirc_dev freezes the whole system (at least until a kernel-watchdog issues a hard reboot). Reverting back to lirc-modules-source 0.8.0-7 and recompiling leads to clean loading modules. This is probably caused by one of the patches introduced with 0.8.0-8. Thanks for your work & regards Mario -- It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. -- Dijkstra signature.asc Description: Digital signature
Bug#397134: acct: init-script uses uninitialized $ACCT_LOGFILE
Package: acct Version: 6.4~pre1-1 Severity: grave Hello, the new package version tries to completely avoid a user-configurable path to the acct-logfile, but is not consistent there, since the init-script still relies on ACCT_LOGFILE being set, which results in: [EMAIL PROTECTED]:~# debsums -as acct [EMAIL PROTECTED]:~# /etc/init.d/acct start Starting process accounting: Turning on process accounting, file set to ''. [EMAIL PROTECTED]:~# Consequently, no accounting gets written to /var/log/account/pacct. This just renders the package unusable with it's default configuration. I guess, just replacing the `"$ACCT_LOGFILE"' with `on' in /etc/init.d/acct should solve this issue. regards Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Bug#396716: irda-utils: fails to install
Package: irda-utils Version: 0.9.18-3 Severity: grave Hi, irda-utils fails to install because the init-script fails to start: Setting up irda-utils (0.9.18-3) ... depmod: *** Unresolved symbols in /lib/modules/2.4.27/CiscoVPN/cisco_ipsec Starting IrDA service: irattacherror: "net.irda.discovery" is an unknown key invoke-rc.d: initscript irda-utils, action "start" failed. dpkg: error processing irda-utils (--configure): subprocess post-installation script returned error exit status 255 Errors were encountered while processing: irda-utils E: Sub-process /usr/bin/dpkg returned an error code (1) The failing init-script is probably okay (although previous versions didn't fail), but the postinst script should not fail just because of that. Thanks for your work & regards Mario -- Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht? signature.asc Description: Digital signature
Bug#390287: Remove xawtv?
On Wed, Oct 11, 2006 at 03:59:36PM +0200, Thijs Kinkhorst wrote: > Same experience - just noise. Oh, and what exactly do you mean with "just noise", you don't mean the usual black-white noise (the ant war or whatever you like to name it) on empty channels, do you? Did you configure xawtv with scantv before? If not - you can also tune up/down channels with cursor up/down. Mario -- There are 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature
Bug#390287: Remove xawtv?
On Wed, Oct 11, 2006 at 03:59:36PM +0200, Thijs Kinkhorst wrote: > On Wed, 2006-10-11 at 15:03 +0200, Mario 'BitKoenig' Holbe wrote: > > Oh, in that case... could you please try with version 3.95-2 and see > > if this behaves the same? > Same experience - just noise. Interesting. Did xawtv ever work for you? And if so: can you trace back when it stopped to do so? PS: let's move over to the BTS and CC: the bug. regards Mario -- Evidently men are more intelligent than women. Every woman on earth believes that men should be able to read minds. Every man knows this is impossible. Ergo, we are more intelligent. signature.asc Description: Digital signature
Bug#392534: xen-hypervisor-3.0.3-rc1-i386: fails to install
On Thu, Oct 12, 2006 at 08:30:08AM +0200, Mario 'BitKoenig' Holbe wrote: > xen-hypervisor-3.0.3-rc1-i386 fails to install: Oh, and it does also fail to purge: # dpkg --purge xen-hypervisor-3.0.3-rc1-i386 (Reading database ... 229724 files and directories currently installed.) Removing xen-hypervisor-3.0.3-rc1-i386 ... Searching for GRUB installation directory ... No GRUB directory found. To create a template run 'mkdir /boot/grub' first. To install grub, install it manually or try the 'grub-install' command. ### Warning, grub-install is used to change your MBR. ### dpkg: error processing xen-hypervisor-3.0.3-rc1-i386 (--purge): subprocess post-removal script returned error exit status 1 Errors were encountered while processing: xen-hypervisor-3.0.3-rc1-i386 Mario -- reich sein heisst nicht, einen Ferrari zu kaufen, sondern einen zu verbrennen Dietmar Wischmeier signature.asc Description: Digital signature
Bug#392534: xen-hypervisor-3.0.3-rc1-i386: fails to install
Package: xen-hypervisor-3.0.3-rc1-i386 Version: 3.0.3~rc1+hg11686-1 Severity: grave Hello, xen-hypervisor-3.0.3-rc1-i386 fails to install: Setting up xen-hypervisor-3.0.3-rc1-i386 (3.0.3~rc1+hg11686-1) ... Searching for GRUB installation directory ... No GRUB directory found. To create a template run 'mkdir /boot/grub' first. To install grub, install it manually or try the 'grub-install' command. ### Warning, grub-install is used to change your MBR. ### dpkg: error processing xen-hypervisor-3.0.3-rc1-i386 (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: xen-hypervisor-3.0.3-rc1-i386 regards Mario -- talk softly and carry a keen sword signature.asc Description: Digital signature
Bug#392462: gpar2: installation fails
Package: gpar2 Version: 0.3-1 Severity: grave Hello, the installation of gpar2 fails - probably due to a missing existence-guard for the call to update-desktop-database or a missing dependency on desktop-file-utils: Setting up gpar2 (0.3-1) ... /var/lib/dpkg/info/gpar2.postinst: line 23: update-desktop-database: command not found dpkg: error processing gpar2 (--configure): subprocess post-installation script returned error exit status 127 Thanks for your work & regards Mario -- To err is human. To really foul things up requires a computer. signature.asc Description: Digital signature
Bug#391588: libquicktime0: causes fbtv and xawtv to core
Package: libquicktime0 Version: 1:0.9.10+debian-2 Severity: grave Hello, upgrading to libquicktime0 1:0.9.10+debian-2 causes fbtv and xawtv (and very likely others from the same source, too) to core immediately on startup. Downgrading to the previous version (libquicktime0 1:0.9.7-0.6+b1) immediately fixes this. Thanks for your work & regards Mario -- There are two major products that come from Berkeley: LSD and UNIX. We don't believe this to be a coincidence.-- Jeremy S. Anderson signature.asc Description: Digital signature
Bug#385078: closed by David Nusinow <[EMAIL PROTECTED]> (Bug#385078: fixed in xorg 1:7.1.0-3)
package xserver-xorg reopen 385078 thanks On Thu, Oct 05, 2006 at 08:19:17PM -0700, Debian Bug Tracking System wrote: > #385078: xserver-xorg: impossible mouse configuration other than > /dev/input/mice, > It has been closed by David Nusinow <[EMAIL PROTECTED]>. >* Make /dev/input/mice the default mouse port in the xserver-xorg.templates > file. Also provide the devices in this file rather than as a variable in > the config script. Closes: #385078 I cannot confirm that. Neither `dpkg-reconfigure xserver-xorg' nor `dpkg-reconfigure -phigh xserver-xorg' nor `dpkg-reconfigure -plow xserver-xorg' asks me about the mouse-device. It always fixes it to /dev/input/mice. regards Mario -- bjmg: ja, logik ist mein fachgebiet. das liegt im gen in welchem? im zweiten X signature.asc Description: Digital signature
Bug#385078: xserver-xorg: impossible mouse configuration other than /dev/input/mice
On Mon, Sep 18, 2006 at 12:41:32PM -0400, José Parrella wrote: > Indeed. I do not mean to steal their work (and actually the Developer's I didn't mean stealing too, I meant more like fiddling into their plans. Like, if they are working on it currently and you NMU something inbetween, this would probably provoke new bugreports which dont fit in the old picture, they have to care about them, however, etc. pp. > About the diff, I used debdiff. If you think the produced diff is > misleading, please let me know. I think it's just reverse, i.e. diff new against old instead of old against new. Mario -- If you think technology can solve your problems you don't understand technology and you don't understand your problems. -- Bruce Schneier signature.asc Description: Digital signature
Bug#385078: xserver-xorg: impossible mouse configuration other than /dev/input/mice
Hi, On Sun, Sep 17, 2006 at 05:54:43PM -0400, José Parrella wrote: > Please try this patch. I'm not a bash (nor debconf!) guru but I think > that it address your concerns regarding the non-interactivity for the > mouse device setting. Please let me know if the patch works for you. Well, I would like to try it, but since I've changed my VGA-card recently, I hit #375689 and thus went over to a fully self-managed xorg.conf. > Therefore I'm providing: > 1) A full, NMU-ready, source package in [1] Hm, I think (or better I strongly hope :)) the xorg-maintainers are hardly working on the package-configuration thingies, so I personally would not suggest to NMU currently. > 3) A diff regarding the config.in, which you'll find attached Is it possible that your diff is a reverse-diff? regards Mario -- It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. -- Dijkstra signature.asc Description: Digital signature
Bug#384791: fbtv: fails with `mmap: Invalid argument'
package fbtv reopen 384791 thanks On Tue, Sep 05, 2006 at 12:32:31AM +0200, Aurelien Jarno wrote: > They have failed due to a temporary problem, but the buildd maintainers > of those architecture haven't requeued them. I will ask them. Hmmm, this seems to take a while. I'll reopen then bug to prevent the wrong version from entering testing. It should be closed automagically anyways once all archs are built. However, if it should not, I will also take care of this :) Mario -- "Why are we hiding from the police, daddy?" | J. E. Guenther "Because we use SuSE son, they use SYSVR4." | de.alt.sysadmin.recovery signature.asc Description: Digital signature
Bug#384791: fbtv: fails with `mmap: Invalid argument'
On Sat, Sep 02, 2006 at 11:48:15AM -0700, Debian Bug Tracking System wrote: > From: Aurelien Jarno <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > This bug has been fixed in version 3.95-4, closing it. Hm, do you probably have an idea why especially the arm and i386 versions are not yet built? Thanks for your work & regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Bug#385078: xserver-xorg: impossible mouse configuration other than /dev/input/mice
Package: xserver-xorg
Version: 1:7.0.23
Severity: serious
Hello,
upgrading xserver-xorg from 6.9.0.dfsg.1-6 to 1:7.0.23 broke my
previously running X:
No core pointer
Fatal server error:
failed to initialize core devices
This is because xserver-xorg.config forces mouse port to /dev/input/mice
while it was /dev/gpmdata before. And since /dev/input/mice just doesn't
exist, startx fails.
I think this is because xserver-xorg.config seems to hardcode the mouse
port to /dev/input/mice currently:
xserver-xorg.config:2022:AUTODETECTED_PORT="/dev/input/mice"
xserver-xorg.config:2023:AUTODETECTED_PROTOCOL="ImPS/2"
xserver-xorg.config:2024:
xserver-xorg.config:2025:db_subst xserver-xorg/config/inputdevice/mouse/port
choices $AUTODETECTED_PORT
xserver-xorg.config:2026:auto_answer db_input "$(priority_ceil low)"
xserver-xorg/config/inputdevice/mouse/port "${AUTODETECTED_PORT}"
xserver-xorg.config:2027:
xserver-xorg.config:2028:db_get xserver-xorg/config/inputdevice/mouse/port
And because I always configured X via xserver-xorg, the config entry has
the seen flag set and is not shown again. I'm not even able to change it
via dpkg-reconfigure :/ Yes, my debconf/priority is set to low, but also
an explicit dpkg-reconfigure -plow doesn't show it.
I don't know why you think you need to hardcode things this way - okay,
the mouse autodetection didn't work well with 6.9 (especially with gpm
running it left the mouse in some strange state), but IMHO asking users
then would be a better option.
Since for most users /dev/input/mice should be available, I don't set
the bug's severity to grave. However, I don't think the package is
suitable for release with this behaviour. Especially because the package
currently breaks previously running systems this way.
My X was always configured via the package's config-interface. This is
currently impossible - I have to manually fix my xorg.conf since the
package doesn't leave me another chance :/
regards
Mario
--
It is practically impossible to teach good programming style to students
that have had prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration. -- Dijkstra
signature.asc
Description: Digital signature
Bug#384950: oss-compat: fails to install
Package: oss-compat Version: 0.0.1 Severity: serious Hello, oss-compat fails to install on 2.4.27: Setting up oss-compat (0.0.1) ... modprobe: Can't locate module snd-seq-oss dpkg: error processing oss-compat (--configure): subprocess post-installation script returned error exit status 255 Errors were encountered while processing: oss-compat Package installation IMHO should not fail just because a module ist not (yet?) present. regards Mario -- To err is human. To really foul things up requires a computer. signature.asc Description: Digital signature
Bug#384791: fbtv: fails with `mmap: Invalid argument'
Package: fbtv Version: 3.95-3 Severity: grave Hello, with 3.95-3 fbtv stopped working: [EMAIL PROTECTED]:/home/holbe% fbtv using linux console font "/usr/share/consolefonts/lat1-16.psf.gz" map: vt03 => fb0 mmap: Invalid argument [1]1818 exit 1 fbtv [EMAIL PROTECTED]:/home/holbe% Downgrading back to 3.95-2 immediately fixes this problem. ii libc6 2.3.6.ds1-4GNU C Library: Shared libraries Linux darkside 2.4.27 #1 Wed Aug 16 09:25:37 CEST 2006 i686 GNU/Linux regards Mario -- [mod_nessus for iauth] "scanning your system...found depreciated OS...found hole...installing new OS...please reboot and reconnect now" signature.asc Description: Digital signature
Bug#384426: sendmail-bin: uninstallable due to unavailable libsasl2 (>= 2.1.19.dfsg1)
Package: sendmail-bin Version: 8.13.4-3sarge2 Severity: grave Tags: sarge, security Hello, the just released security fix package 8.13.4-3sarge2 does not install on sarge, because it depends on libsasl2 (>= 2.1.19.dfsg1) while on sarge only libsasl2 (2.1.19-1.5sarge1) is available. Package: sendmail-bin Version: 8.13.4-3sarge2 Depends: ..., libsasl2 (>= 2.1.19.dfsg1), ... Package: libsasl2 Version: 2.1.19-1.5sarge1 I'm not sure whether this bug is to be best off, so I'm CC:ing debian-security@lists.debian.org as hinted in the Security Advisory. regards Mario -- User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten signature.asc Description: Digital signature
Bug#362907: xcal and x.org
On Fri, Apr 21, 2006 at 08:30:08PM +0200, Lars Bahner wrote: > This bug should be solved when imake settles. Nothing to be done at this > end for now. do you by chance have an idea already, when this will happen? Thanks for your work & regards Mario -- talk softly and carry a keen sword signature.asc Description: Digital signature
Bug#370739: reportbug: postinst fails
Package: reportbug Version: 3.21 Severity: grave Hello, the post-installation script of reportbug 3.21 fails: Setting up reportbug (3.21) ... Compiling /usr/share/reportbug/reportbug_submit.py ... File "/usr/share/reportbug/reportbug_submit.py", line 354 while failed != True: ^ SyntaxError: invalid syntax dpkg: error processing reportbug (--configure): subprocess post-installation script returned error exit status 1 [EMAIL PROTECTED]:~# COLUMNS=72 dpkg -l python2.3 | grep ^ii ii python2.3 2.3.5-9.1 An interactive high-level object-oriented la regards Mario -- reich sein heisst nicht, einen Ferrari zu kaufen, sondern einen zu verbrennen Dietmar Wischmeier signature.asc Description: Digital signature
Bug#370745: udev: udevsettle waits forever when udev is not running
Package: lirc Version: 0.8.0-4 Severity: serious Hello, the lirc init script waits forever, if udev is not running - i.e. especially on 2.4 kernels. This is due to your call to udevsettle in the init-script. I was quite close at submitting a bug against udev because udevsettle waits forever when udev is not running. However, udevsettle doesn't do that as long as /dev/.udev/queue does not exist - which it usually doesn't if udev is not running - at least not on my system. Unfortunately you are creating it yourself in the init-script so I'll better call the problem home-made :) [EMAIL PROTECTED]:~# uname -a Linux darkside 2.4.27 #1 Thu Dec 22 21:52:46 CET 2005 i686 GNU/Linux [EMAIL PROTECTED]:~# ps -ef | grep udev root 32488 2775 0 18:30 tty1 00:00:00 grep udev [EMAIL PROTECTED]:~# udevsettle [EMAIL PROTECTED]:~# mkdir /dev/.udev/queue [EMAIL PROTECTED]:~# udevsettle ... waits forever ... I set the severity to serious because this currently breaks (or better hangs) the installation of lirc 0.8.0-4 on all non-udev systems. If you think this is an udev problem (despite your home-made queue), please feel free to re-assign this bug there. regards Mario -- I have great faith in fools; self-confidence my friends call it. -- Edgar Allan Poe signature.asc Description: Digital signature
Bug#365680: CGIIRC vulnerability (Bug#365680)
On Thu, May 04, 2006 at 04:55:39PM +0200, Martin Schulze wrote: > Are you going to update the package in sid as well? We're preparing a new version for sid, which of course will include the fix, too. But this will take a few days longer, so... > Or should the package propagate via stable-security? Yes, for the first it should be okay to propagate the package via stable-security. On Thu, May 04, 2006 at 04:50:55PM +0200, Martin Schulze wrote: > Elrond wrote: > > I _might_ be able to test, wether the package still works > Please let us know. Tests are done. Everything seems to work well. > Update prepared. Go on :) Please make sure you did also add 50_client-c_bufferoverflow_fix to debian/patches/00list in order to really make it active, since Elrond did forget to mention this in his original ToDo list. Thanks for your work & best regards Mario -- File names are infinite in length where infinity is set to 255 characters. -- Peter Collinson, "The Unix File System" signature.asc Description: Digital signature
Bug#365680: Patch for 0.5.4-6
package cgiirc tags 365680 + patch thanks On Tue, May 02, 2006 at 10:30:11PM +0200, Elrond wrote: > To create a new package: > - Place the .dpatch in debian/patches > - Add 50_client-c_bufferoverflow_fix.dpatch to > debian/patches/ - Add 50_client-c_bufferoverflow_fix to debian/patches/00list > - Create a new changelog entry. > > To Do / Done: > * I verified, that the above builds a fresh package Dito. It does also install/upgrade clean :) > * Testing is needed I did my best :) > * Tag this bug "patch" On the way. > * Let the security team to their job Okay :) regards Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Bug#365680: It does affect all installs
On Tue, May 02, 2006 at 08:46:28PM +0100, David Leadbeater wrote: > Mario: It does affect all configurations, just because the > configuration file says client-perl.cgi it doesn't stop someone > accessing client.cgi as the package builds client.cgi and puts it Yes, i missed that in the first look iteration. We've quite finished an intermediate security release. Mario -- We are the Bore. Resistance is futile. You will be bored. signature.asc Description: Digital signature
Bug#365680: cgiirc: buffer overflow in client.c
Hi, On Tue, May 02, 2006 at 10:15:37AM +0800, Paul Wise wrote: > Upstream has just released 0.5.8, which fixes a buffer overflow in > client.c amongst other things. The 0.5.8 timeline can be seen here: Just as a short-term reply and for documentation reasons regarding this issue: The Debian package ships with a safe default configuration and is thus not per-se vulnerable. However, of course it is vulnerable if the configuration is changed to use client.cgi instead of client-perl.cgi. regards Mario -- I've never been certain whether the moral of the Icarus story should only be, as is generally accepted, "Don't try to fly too high," or whether it might also be thought of as, "Forget the wax and feathers and do a better job on the wings."-- Stanley Kubrick signature.asc Description: Digital signature
Bug#358373: lvm2: doesn't install if kernel is too old
package lvm2 reopen 358373 thanks On Wed, Mar 22, 2006 at 06:24:44PM +0100, Mario 'BitKoenig' Holbe wrote: > On Wed, Mar 22, 2006 at 09:18:13AM -0800, Debian Bug Tracking System wrote: > > From: Bastian Blank <[EMAIL PROTECTED]> > > On Wed, Mar 22, 2006 at 02:37:22PM +0100, Mario 'BitKoenig' Holbe wrote: > > > I'm not sure whether this is intentional or not. > > It is. > Could you then please at least comment a little about my migration > scenario? Allright, if you don't see a need to comment, I'll just comment myself and reopen the bug. No problem. Refusing to install the package on a system that's not currently running a kernel > 2.6.12 makes it impossible to migrate from lvm1 to lvm2 at all for users running their /usr and /var on lvm1 already: Current 2.6 kernels don't support lvm1, so these users are not able to mount their /usr and /var to be able to install Debian packages at all. Thus, these users are not able to install lvm2 once they've booted a recent 2.6 kernel. Thus, they are not able to install the package *after* booting into 2.6. Since you make it impossible to install the package *before* booting into 2.6, these users have no chance to install the package at all. Thus, they have no chance to migrate at all. That's why simply refusing to install on systems running too old kernels is just not acceptable. If you *need* to refuse to install on systems running kernels <2.6.12 because you would otherwise break things that did work before, you need to provide a different migration path. You could, for example, let this package carry an earlier lvm2 version that supports kernels <2.6.12 and you could provide another (third) package carrying a recent lvm2 version to close the migration gap. best regards Mario -- Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den Unsinn und den Stumpfsinn. [Holger Veit in doc] signature.asc Description: Digital signature
Bug#358373: lvm2: doesn't install if kernel is too old
On Wed, Mar 22, 2006 at 09:18:13AM -0800, Debian Bug Tracking System wrote: > From: Bastian Blank <[EMAIL PROTECTED]> > On Wed, Mar 22, 2006 at 02:37:22PM +0100, Mario 'BitKoenig' Holbe wrote: > > I'm not sure whether this is intentional or not. > It is. Could you then please at least comment a little about my migration scenario? regards Mario -- Independence Day: Fortunately, the alien computer operating system works just fine with the laptop. This proves an important point which Apple enthusiasts have known for years. While the evil empire of Microsoft may dominate the computers of Earth people, more advanced life forms clearly prefer Mac's. signature.asc Description: Digital signature
Bug#358373: lvm2: doesn't install if kernel is too old
Package: lvm2 Version: 2.02.02-1 Severity: grave Hello, the lvm2 package fails to install at least on systems running a kernel < 2.6.12. A debconf message box appears during the installation, telling: Running kernel TOO old Your running kernel is < 2.6.12. lvm2 since 2.02.00 does not work with them. An then the installation fails: dpkg: error processing /var/cache/apt/archives/lvm2_2.02.02-1_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/lvm2_2.02.02-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) I'm not sure whether this is intentional or not. If it should be intentional, it is at least quite unwise. Of course the average user who is already using lvm is *not* running a 2.6 kernel at the moment when he's installing lvm2. He's running 2.4 and is on the way to reboot into a 2.6 kernel where he needs the new tools for the first time. Btw... in the package description you say: LVM2 is backwards-compatible with LVM1 (lvm10), and requires Linux kernel 2.4 or later This is obviously not true, since it then would not fail to install on 2.4 or later kernels :) regards Mario -- Independence Day: Fortunately, the alien computer operating system works just fine with the laptop. This proves an important point which Apple enthusiasts have known for years. While the evil empire of Microsoft may dominate the computers of Earth people, more advanced life forms clearly prefer Mac's. signature.asc Description: Digital signature
Bug#355519: libsensors3:
Package: libsensors3 Version: 1:2.10.0-2 Severity: grave Hello, since 2.10.0-2 libsensors doesn't support kernel 2.4 proc interface anymore (although it suggests it would), with 2.10.0-1 everything did work well: [EMAIL PROTECTED]:~# dpkg -i /var/cache/apt/archives/libsensors3_1%3a2.10.0-1_i386.deb dpkg - warning: downgrading libsensors3 from 2.10.0-2 to 2.10.0-1. (Reading database ... 205345 files and directories currently installed.) Preparing to replace libsensors3 1:2.10.0-2 (using .../libsensors3_1%3a2.10.0-1_i386.deb) ... Unpacking replacement libsensors3 ... Setting up libsensors3 (2.10.0-1) ... [EMAIL PROTECTED]:~# sensors as99127f-i2c-0-2d Adapter: SMBus Via Pro adapter at e800 ... [EMAIL PROTECTED]:~# dpkg -i /var/cache/apt/archives/libsensors3_1%3a2.10.0-2_i386.deb (Reading database ... 205345 files and directories currently installed.) Preparing to replace libsensors3 1:2.10.0-1 (using .../libsensors3_1%3a2.10.0-2_i386.deb) ... Unpacking replacement libsensors3 ... Setting up libsensors3 (2.10.0-2) ... [EMAIL PROTECTED]:~# sensors Can't access procfs/sysfs file Unable to find i2c bus information; For 2.6 kernels, make sure you have mounted sysfs and libsensors was compiled with sysfs support! For older kernels, make sure you have done 'modprobe i2c-proc'! [EMAIL PROTECTED]:~# lsmod | grep i2c-proc i2c-proc6308 0 [bt869 w83781d] i2c-core 15588 0 [lirc_i2c tuner tvmixer tvaudio msp3400 bttv bt869 w83781d i2c-algo-bit i2c-viapro i2c-dev i2c-proc] [EMAIL PROTECTED]:~# uname -a Linux darkside 2.4.27 #1 Thu Dec 22 21:52:46 CET 2005 i686 GNU/Linux [EMAIL PROTECTED]:~# regards Mario -- Why did the tachyon cross the road? Because it was on the other side. signature.asc Description: Digital signature
Bug#353531: dumputils: modifies shipped conffile
Package: dumputils Version: 0.4-6 Severity: serious Hello, dumputils modifies /etc/dumputils.conf in it's postinst script, which is against Debian Policy 10.7.3. This behaviour did lead to a) DUMP_FLAGS=0 appended to my dumputils.conf although I had DUMP_FLAGS=1 manually configured there (this is btw. IMHO one of the reasons why the policy forbids modification of conffiles :)) and b) this line being added *multiple* times. If you think it's a good idea to manipulate config-files, please think about using ucf. If you still think it's agood idea to manipulate config-files, please consider that package postinst is probably the wrong place to do it, since kernels can change independently of the installation/upgrade of dumputils. Probably it would be better to give some warning in the init-script if it detects a configuration incompatible to the currently running kernel. Thanks for your work & regards Mario -- Tower: "Say fuelstate." Pilot: "Fuelstate." Tower: "Say again." Pilot: "Again." Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..." signature.asc Description: Digital signature
Bug#353529: cdrdao: collides with cue2toc, again
Package: cdrdao Version: 1:1.2.1-5 Severity: serious Hello, while 1:1.2.1-4 did coexist well with cue2toc, 1:1.2.1-5 doesn't do anymore: Preparing to replace cdrdao 1:1.2.1-4 (using .../cdrdao_1%3a1.2.1-5_i386.deb) ... Unpacking replacement cdrdao ... dpkg: error processing /var/cache/apt/archives/cdrdao_1%3a1.2.1-5_i386.deb (--unpack): trying to overwrite `/usr/share/man/man1/cue2toc.1.gz', which is also in package cue2toc dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/cdrdao_1%3a1.2.1-5_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) PS: I was thinking about adding this to #353500. However, I don't understand this bug, so I just left it alone :) Thanks for your work & regards Mario -- The question of whether a computer can think is no more interesting than the question of whether a submarine can swim. -- E. W. Dijkstra signature.asc Description: Digital signature
Bug#330526: [Pkg-shadow-devel] Bug#330526: Install failed. Trying to overwrite `/usr/share/man/de/man5/passwd.5.gz', which is also in package manpages-de
On Wed, Sep 28, 2005 at 07:02:34PM +0300, Alexander Gattin wrote: > merge 330526 330247 > thanks > > IMHO it's better to have all these grave conflicts > with manpages-XX merged in single place. Well, unfortunately, 330247 was for login (which was why I didn't report a dup for login yesterday) and is already fixed, while 330526 is for passwd and is not yet fixed (which is why I did report it today). Anyways - as long as the thing gets fixed, I don't care what you are merging it with :) Mario -- Sex is not the answer. Sex is the question. Yes is the answer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330526: Install failed. Trying to overwrite `/usr/share/man/de/man5/passwd.5.gz', which is also in package manpages-de
Package: passwd Version: 1:4.0.12-3 Severity: grave Tags: l10n Justification: renders package unusable The package tries to overwrite /usr/share/man/de/man5/passwd.5.gz which is also in the package "manpages-de". dpkg-output: Unpacking replacement passwd ... dpkg: error processing /var/cache/apt/archives/passwd_1%3a4.0.12-3_i386.deb (--unpack): trying to overwrite `/usr/share/man/de/man5/passwd.5.gz', which is also in package manpages-de dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/passwd_1%3a4.0.12-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks for your work & regards Mario -- who | grep -i blonde | talk; cd; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; true; gasp; umount; make clean; sleep -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306261: pppd persist eats up all cpu after reconnect
On Mon, Apr 25, 2005 at 12:34:52PM +0200, Joerg Dorchain wrote: > exspected. After the the first dis- and reconnect (i.e. after 24h) pppd > eats up all cpu time. The reconnect itself works as expected, but the > systems becomes notably slow with pppd playing cpu-hog. ... > with fd 13 and 14 being connected to /dev/ppp. Same here with 2.4.27 built from kernel-source-2.4.27 and ppp 2.4.3-20050321+1 and pppoe-plugin. [EMAIL PROTECTED]:~# ll /proc/$(pidof pppd)/fd | grep ppp\$ lrwx-- 1 root root 64 May 3 20:36 11 -> /dev/ppp lrwx-- 1 root root 64 May 3 20:36 12 -> /dev/ppp lrwx-- 1 root root 64 May 3 20:36 13 -> /dev/ppp [EMAIL PROTECTED]:~# Mario -- I've never been certain whether the moral of the Icarus story should only be, as is generally accepted, "Don't try to fly too high," or whether it might also be thought of as, "Forget the wax and feathers and do a better job on the wings."-- Stanley Kubrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
