Bug#817499: ifstat: diff for NMU version 1.1-8.1
Hi,
On Sat, Sep 24, 2016 at 04:14:44PM +0200, Tobias Frost wrote:
> Control: tags 817499 + patch
> Control: tags 817499 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for ifstat (versioned as 1.1-8.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> diff -u ifstat-1.1/debian/changelog ifstat-1.1/debian/changelog
> --- ifstat-1.1/debian/changelog
> +++ ifstat-1.1/debian/changelog
> @@ -1,3 +1,10 @@
> +ifstat (1.1-8.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Bump d/compat to 9 (Closes: #817499)
> +
> + -- Tobias Frost <t...@debian.org> Sat, 24 Sep 2016 16:13:19 +0200
> +
> ifstat (1.1-8) unstable; urgency=low
>
>* New maintainer address.
> diff -u ifstat-1.1/debian/control ifstat-1.1/debian/control
> --- ifstat-1.1/debian/control
> +++ ifstat-1.1/debian/control
> @@ -2,13 +2,13 @@
> Section: net
> Priority: optional
> Maintainer: Goswin von Brederlow <goswin-...@web.de>
> -Build-Depends: debhelper (>= 4), libsnmp-dev
> +Build-Depends: debhelper (>= 9), libsnmp-dev
> Standards-Version: 3.7.2.2
>
> Package: ifstat
> Section: net
> Architecture: any
> -Depends: ${shlibs:Depends}
> +Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: InterFace STATistics Monitoring
> ifstat is a tool to report network interfaces bandwidth just like
> vmstat/iostat do for other system counters. It can monitor local
Sorry for coming back so late. Why didn't you just sponsor the updated
ifstat package from mentors.debian.net?
https://mentors.debian.net/package/ifstat
Please upload that instead to properly transition ifstat to the new
debhelper and dh. The old debian/rules file will randomly break with
parallel builds, like in #828348. debian/control also is missing a
Build-Depends on libssl-dev.
MfG
Goswin
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Wed, Mar 11, 2015 at 06:09:50PM +, Ben Hutchings wrote: On Tue, 2015-03-10 at 12:47 +0100, Goswin von Brederlow wrote: On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote: Thanks for your work on this bug. I ended up with a somewhat different implementation as I don't think it's necessary to duplicate the information that udev provides, and as we may now need to mount more than one filesystem. But I should have credited you in the changelog for prototyping this, and I forgot to do so. Ben. The idea with the udev rule was to wait up to ROOTDELAY seconds without a new device apearing before giving up. Now you wait ROOTDELAY seconds in total, which then can depend on the number of devices. It's now max(rootdelay, 30) because the rootdelay kernel parameter wasn't meant for this purpose at all. Add new disk and you have to increase the ROOTDELAY. I hope not! On one system the PSU isn't big enough to spin up all disks at once. So the SCSI controler is set to not start them on power on. Instead they come up sequentially. So one disk takes 5s, 2 disks 10s, 3 disks 15s, ... accordingly you have to set the delay. Add another disk and the total time goes up. Also it was ment so that block scripts could specifically target the new devices instead of having to scan all devices every time. For example say you have a crypt device and you forgot the password. Now I think you will be asked 30 times for the password before the initramfs gives up. True, but so far as I could see you didn't send scripts that made use of that. We could still implement that later, I think. And now that we potentially have to mount /usr (and possibly other filesystems), not just root and swap, lvm2's script needed to be told which device we're looking for, not which devices appeared. Ben. That isn't realy new. Debian already had root and swap. Adding a third doesn't realy change anything. LVM should already have known what devices to activate for root and swap. The problem I see there is detecting what devices to bring up. The /usr filesystem might be in a ZPOOL that uses a crypt device on a LVM logical volume on a raid. Or any other complex nesting. Could be any number of devices that are needed for /usr to become available. Again nothing new for /usr, / and swap already have that problem. Note: LVM has persistent metadata that tell it wether to bring up a device or not. So I'm not sure it makes much sense to guess what devices are needed and limiting lvm to only start those. The metadata already has this functionality and is more reliable than guessing what devices may be needed. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote: Thanks for your work on this bug. I ended up with a somewhat different implementation as I don't think it's necessary to duplicate the information that udev provides, and as we may now need to mount more than one filesystem. But I should have credited you in the changelog for prototyping this, and I forgot to do so. Ben. The idea with the udev rule was to wait up to ROOTDELAY seconds without a new device apearing before giving up. Now you wait ROOTDELAY seconds in total, which then can depend on the number of devices. Add a new disk and you have to increase the ROOTDELAY. Also it was ment so that block scripts could specifically target the new devices instead of having to scan all devices every time. For example say you have a crypt device and you forgot the password. Now I think you will be asked 30 times for the password before the initramfs gives up. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776633: alternative libblas.so.3gf can't be slave of libblas.so.3: it is a master alternative
Package: libblas3 Version: 1.2.20110419-10 Severity: grave Updating libblas3 fails with: Setting up libblas3 (1.2.20110419-10) ... update-alternatives: error: alternative libblas.so.3gf can't be slave of libblas.so.3: it is a master alternative dpkg: error processing package libblas3 (--configure): subprocess installed post-installation script returned error exit status 2 MfG Goswin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages libblas3 depends on: ii libblas-common 1.2.20110419-10 ii libc6 2.19-13 ii libgcc1 1:4.9.2-10 ii libgfortran34.6.2-9 ii libquadmath04.9.2-10 libblas3 recommends no packages. libblas3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776634: alternative liblapack.so.3gf can't be slave of liblapack.so.3: it is a master alternative
Package: liblapack3 Version: 3.5.0-4 Severity: grave Updating liblapack3 fails with: Setting up liblapack3 (3.5.0-4) ... update-alternatives: error: alternative liblapack.so.3gf can't be slave of liblapack.so.3: it is a master alternative dpkg: error processing package liblapack3 (--configure): subprocess installed post-installation script returned error exit status 2 The package used to provide liblapack.so.3gf as master alternative and never removes it on upgrade. This might also need to break with other providers of that alternative. MfG Goswin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages liblapack3 depends on: ii libblas3 [libblas.so.3] 1.2.20110419-10 ii libc62.19-13 ii libgcc1 1:4.9.2-10 ii libgfortran3 4.6.2-9 ii libquadmath0 4.9.2-10 liblapack3 recommends no packages. liblapack3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Sun, Aug 31, 2014 at 10:14:18AM +0200, Michael Prokop wrote: Hi, f'up to our recent discussion we had on IRC * Goswin von Brederlow [Sat Jun 23, 2012 at 09:25:28PM +0200]: the attached patch adds an event based loop for block devices to the init script. New blockdevices are recorded in /run/initramfs/block-events by an udev rule as they appear. The init script repeadately waits for that and then calls /scripts/local-block/* with a list of new devices storedin NEWDEVS until $ROOT and $resume (if set) exists or a timeout is reached. This fixes the problem that USB devices take too long to be discovered and crypto, raid, lvm or multipath can't be started on them. It also adds support for arbitrary nestings of them, e.g. raid5 over raid1. [...] First of all thanks again for the patch and your helpful feedback on IRC. I've tested your patch based on top of current i-t git master (v0.116) with a setup like: BOOT_IMAGE=/boot/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-root ro quiet but it sadly fails to work as intended (it boots but doesn't find the block devices until the timeout is kicking in). I didn't investigate closer yet, but AFAICS it seems to be related to the fact that /dev/mapper/vg0-root doesn't exist at that time yet. If it boots after the timeout then the device must exist. So either the test for it is wrong or the device only gets created after the timeout. If you or someones else finds time to try and possibly further investigate I'd very much welcome and appreciate that. regards, -mika- Questions: Does your system boot without the patch? If not then you also need the lvm patch to provide the hook script that scans for a VG when new block devices are detected. Do you see any messages about vg0 being activated before the timeout or after? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752507: Hangs in splash screen
Package: eric Version: 5.4.3-1 Severity: grave When I start eric the splash screen opens saying Generating Main Window... and then nothing else happens. I've tried pugring eric, deleting all ~/.eric* dirs and reinstalling but no change. MfG Goswin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages eric depends on: ii bicyclerepair0.9-6.1 ii python-chardet 2.2.1-1 ii python3-pygments 1.6+dfsg-1 ii python3-pyqt44.10.3+dfsg1-1+b1 ii python3-pyqt4.qsci 2.8.1-2 ii python3-pyqt4.qtsql 4.10.3+dfsg1-1+b1 Versions of packages eric recommends: pn eric-api-files none Versions of packages eric suggests: ii pyqt4-dev-tools 4.11+dfsg-1+b1 pn pyqt5-doc none ii python [python-profiler] 2.7.5-5 pn python-docnone pn python-kde4-doc none pn python-qt4-docnone ii qt4-designer 4:4.8.6+dfsg-1 ii qt4-dev-tools 4:4.8.6+dfsg-1 pn qt4-doc-html none pn qt5-doc none pn ruby none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719984: Adding... dialog pops up after every bug making multitasking impossible
Package: calibre Version: 0.9.41+dfsg-1 Severity: critical File: /usr/bin/calibre Hi, I'm using calibre for the first time so I'm adding a large number of books all at once. Given that it takes rather long per book, 5-30s per book, I would realy like to do something else with my computer while it scans books. But every time a book is added the Adding... dialog pops to the front obscuring other windows, stealing the focus (because my mouse happens to be where the dialog is) and making it impossible to work. It, at least temporary, breaks the system. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages calibre depends on: ii calibre-bin 0.9.41+dfsg-1 ii fonts-liberation 1.07.2-7 ii imagemagick 8:6.7.7.10-2 ii libjs-mathjax 2.2-1 ii poppler-utils 0.18.4-3 ii python-beautifulsoup 3.2.1-1 ii python-chardet2.0.1-2 ii python-cherrypy3 3.2.2-2 ii python-cssselect 0.8-1 ii python-cssutils 0.9.10~b1-2 ii python-dateutil 1.5-1 ii python-dbus 1.2.0-2+b1 ii python-feedparser 5.1.2-2 ii python-imaging1.1.7-4 ii python-lxml 3.2.0-1+b1 ii python-markdown 2.3.1-1 ii python-mechanize 1:0.2.5-3 ii python-netifaces 0.8-2 ii python-pkg-resources 0.6.49-2 ii python-pyparsing 1.5.7+dfsg1-2 ii python-qt44.10.2-2 ii python-routes 1.13-2 ii python2.7 2.7.3-1 ii xdg-utils 1.1.0~rc1+git20111210-6 Versions of packages calibre recommends: pn python-dnspython none calibre suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700818: [Pkg-ia32-libs-maintainers] Bug#700818: Bug#700818: ia32-libs: not installable
On Mon, Feb 18, 2013 at 09:28:53AM +0100, Thijs Kinkhorst wrote: Hi Lucas, On Sun, February 17, 2013 22:07, Lucas Nussbaum wrote: While testing the installation of all packages in wheezy, I ran into the following problem: The following packages have unmet dependencies: ia32-libs : Depends: ia32-libs-i386 but it is not installable E: Unable to correct problems, you have held broken packages. This is documented in the release notes: http://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html#ia32libs Does it work for you when following those teps? Cheers, Thijs It is also mentioned in the package description. Is there something that would make it clearer without overly bloating the long description? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680317: [Pkg-ia32-libs-maintainers] Bug#680317: Uninstallable due dependency to unexisting package: i32-libs-gtk-i386
On Mon, Jul 09, 2012 at 11:09:42AM +0200, Marco Nenciarini wrote: Il giorno ven, 06/07/2012 alle 11.36 +0200, Goswin von Brederlow ha scritto: On Thu, Jul 05, 2012 at 12:45:55AM +0200, Marco Nenciarini wrote: Package: ia32-libs-gtk Version: 20120616 Severity: serious The package ia32-libs-gtk is uninstallable due to dependency on i32-libs- gtk-i386 (missing 'a' in ia32) However, even with the correct spelling, I can't find the ia32-libs-gtk-i386 package anywhere. Fixed in 20120706: http://mentors.debian.net/package/ia32-libs-gtk http://mentors.debian.net/debian/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_20120706.dsc Feel free to sponsor the upload. Note: I've put some packages into Recommends because they are still Multi-Arch buggy. This allows ia32-libs-gtk-i386 to be installed and tested without them but might break some applications. They should move back to depends as the bugs get fixed. I would be happy to help sponsoring, but I see another problem: the package is listed only amd64 in buildd's Packages-arch-specific file [1]. So It will not be picked up for i386 and therefore it will not work. [1]https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific As a workaround I've searched if there is a clean way to do a mixed-arch upload (i386+amd64) but I found nothing, so you should ask Bastian Blank (in cc) who did a mixed upload for ia32-libs version 20120616 [2] [2] http://packages.qa.debian.org/i/ia32-libs/news/20120630T094734Z.html Regards, Marco There are 3 ways to do this: 1) build for i386 + src, upload and let the amd64 buildd do the rest 2) build for amd64 + src, upload, build for just i386, upload without source 3) build amd64 + src, build i386, dpkg-mergechanges, upload I've filed a bug against P-A-S so hopefully that will be fixed soon. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680317: [Pkg-ia32-libs-maintainers] Bug#680317: Uninstallable due dependency to unexisting package: i32-libs-gtk-i386
On Thu, Jul 05, 2012 at 12:45:55AM +0200, Marco Nenciarini wrote: Package: ia32-libs-gtk Version: 20120616 Severity: serious The package ia32-libs-gtk is uninstallable due to dependency on i32-libs- gtk-i386 (missing 'a' in ia32) However, even with the correct spelling, I can't find the ia32-libs-gtk-i386 package anywhere. Fixed in 20120706: http://mentors.debian.net/package/ia32-libs-gtk http://mentors.debian.net/debian/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_20120706.dsc Feel free to sponsor the upload. Note: I've put some packages into Recommends because they are still Multi-Arch buggy. This allows ia32-libs-gtk-i386 to be installed and tested without them but might break some applications. They should move back to depends as the bugs get fixed. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679671: [Pkg-ia32-libs-maintainers] Bug#679671: ia32-libs-i386: depends on removed package libdb4.8
On Thu, Jul 05, 2012 at 08:55:37PM -0400, Larry wrote: The dependency problem was with package ia32-libs-i386. You submitted new ia32-libs but not the package in question ia32-libs-i386 It still depends on the removed package libdb4.8, thus ia32-libs is still broken because it depends on ia32-libs-386 which still needs to be updated. Both ia32-libs and ia32-libs-i386 are build from the same source ia32-libs. ia32-libs-i386 just needs to be build by the i386 autobuilder, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680378. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679780: [Piuparts-devel] Processed: reassign 679780 to piuparts
On Mon, Jul 02, 2012 at 11:46:23PM +0200, Andreas Beckmann wrote: Hi Goswin, I would really appreciate if you try to create a working script instead of giving a vague description, especially for the dist-upgrade case. Andreas How? As far as I see there is no framework in place to do a second dist-upgrade or to do an upgrade of selective packages (apt/dpkg) first. If you had then the script would be simple: #!/bin/sh dpkg --add-architecture i386 apt-get update This needs to be done before ia32-libs can be updated but must be done after apt/dpkg have been updated. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679826: zsnes: segfaults on start in testing i386
On Mon, 2 Jul 2012 07:35:57 +0930, Ron wrote: FWIW severity 'grave' for #679826 looks just a tad hysterical. grave: makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. zsnes works without sound cards but segfaults if you have one. I would think most users do have a soundcard so zsnes becomes unusable to most = grave. Anyway, to see whats wrong I compiled zsnes -with -g and run it in valgrind: /znes/zsnes-1.510+bz2# file ./src/zsnes ./src/zsnes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x174839ca4599d5b32320cd48b76992ee336f13ad, not stripped /znes/zsnes-1.510+bz2# valgrind ./src/zsnes ==11091== Memcheck, a memory error detector ==11091== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==11091== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==11091== Command: ./src/zsnes ==11091== --11091-- WARNING: Serious error when reading debug info --11091-- When reading debug info from /usr/lib/i386-linux-gnu/libGL.so.1.2: --11091-- Can't make sense of .got section mapping --11091-- WARNING: Serious error when reading debug info --11091-- When reading debug info from /usr/lib/i386-linux-gnu/libglapi.so.0.0.0: --11091-- Can't make sense of .got section mapping ZSNES v1.51, (c) 1997-2007, ZSNES Team Be sure to check http://www.zsnes.com/ for the latest version. ZSNES is written by the ZSNES Team (See AUTHORS.TXT) ZSNES comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; please read 'LICENSE.TXT' thoroughly before doing so. Use ZSNES -? for command line definitions. Starting Mouse detection. /dev/input does not exist or is inaccessable ManyMouse: -1 mice detected. ==11091== Syscall param writev(vector[...]) points to uninitialised byte(s) ==11091==at 0x742DCDC: writev (writev.c:56) ==11091==by 0x7A167C5: ??? (in /usr/lib/i386-linux-gnu/libxcb.so.1.1.0) ==11091==by 0x391: ??? ==11091== Address 0xa24ee13 is 19 bytes inside a block of size 16,384 alloc'd ==11091==at 0x4A4BA68: calloc (vg_replace_malloc.c:566) ==11091==by 0x7900AE9: XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) ==11091==by 0x736F686B: ??? ==11091== ==11091== Conditional jump or move depends on uninitialised value(s) ==11091==at 0x4D4D774: _open_device (in /usr/lib/libao.so.4.0.0) ==11091==by 0x82FA8FE: InitSound (audio.c:197) ==11091==by 0x82FDE1E: initwinvideo (sdllink.c:1088) ==11091==by 0x82FB363: ??? (in /znes/zsnes-1.510+bz2/src/zsnes) ==11091== ==11091== Conditional jump or move depends on uninitialised value(s) ==11091==at 0x4D4B62C: _sanitize_matrix.isra.2 (in /usr/lib/libao.so.4.0.0) ==11091==by 0x4D4D78A: _open_device (in /usr/lib/libao.so.4.0.0) ==11091==by 0x82FA8FE: InitSound (audio.c:197) ==11091==by 0x82FDE1E: initwinvideo (sdllink.c:1088) ==11091==by 0x82FB363: ??? (in /znes/zsnes-1.510+bz2/src/zsnes) ==11091== ==11091== Use of uninitialised value of size 4 ==11091==at 0x4A4DA48: strlen (mc_replace_strmem.c:390) ==11091==by 0x4D4B639: _sanitize_matrix.isra.2 (in /usr/lib/libao.so.4.0.0) ==11091==by 0x4D4D78A: _open_device (in /usr/lib/libao.so.4.0.0) ==11091==by 0x82FA8FE: InitSound (audio.c:197) ==11091==by 0x82FDE1E: initwinvideo (sdllink.c:1088) ==11091==by 0x82FB363: ??? (in /znes/zsnes-1.510+bz2/src/zsnes) ==11091== ==11091== Invalid read of size 1 ==11091==at 0x4A4DA48: strlen (mc_replace_strmem.c:390) ==11091==by 0x4D4B639: _sanitize_matrix.isra.2 (in /usr/lib/libao.so.4.0.0) ==11091==by 0x4D4D78A: _open_device (in /usr/lib/libao.so.4.0.0) ==11091==by 0x82FA8FE: InitSound (audio.c:197) ==11091==by 0x82FDE1E: initwinvideo (sdllink.c:1088) ==11091==by 0x82FB363: ??? (in /znes/zsnes-1.510+bz2/src/zsnes) ==11091== Address 0x5 is not stack'd, malloc'd or (recently) free'd ==11091== ==11091== ==11091== HEAP SUMMARY: ==11091== in use at exit: 11,913,398 bytes in 490 blocks ==11091== total heap usage: 4,694 allocs, 4,204 frees, 13,720,241 bytes allocated ==11091== ==11091== LEAK SUMMARY: ==11091==definitely lost: 12 bytes in 2 blocks ==11091==indirectly lost: 0 bytes in 0 blocks ==11091== possibly lost: 336 bytes in 2 blocks ==11091==still reachable: 11,913,050 bytes in 486 blocks ==11091== suppressed: 0 bytes in 0 blocks ==11091== Rerun with --leak-check=full to see details of leaked memory ==11091== ==11091== For counts of detected and suppressed errors, rerun with: -v ==11091== Use --track-origins=yes to see where uninitialised values come from ==11091== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 167 from 12) Killed The first one looks like a problem in libxcb and I would start with the other errors.So look at InitSound
Bug#679826: zsnes: segfaults on start in testing i386
Hi, might I suggest adding memset(driver_format, 0, sizeof(driver_format)); That way even if the API changes and the driver_format structure grows it will still initialize all fields to 0, which is usualy a good default. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679780: ia32-libs: please document how to perform automated package install and upgrade tests that involve ia32-libs
Hi, testing ia32-libs is pretty simple and should be the same as for all 32bit packages that will switch to multiarch (e.g wine). As you speculated you need to run dpkg --add-architecture and apt-get update. After that ia32-libs can simply be installed. For upgrades the same holds true. Except you can't add the foreign architecture until you have already upgraded dpkg and apt. You will need to two this in multiple steps: * replace sources.list to point ot the next distribution * run pre_distupgrade scripts (above variables + PIUPARTS_DISTRIBUTION_NEXT) * apt-get dist-upgrade * dpkg --add-architecture i386 * apt-get update * apt-get dist-upgrade * run post_distupgrade scripts (above variables + PIUPARTS_DISTRIBUTION_PREV) So I figure you need some do_i_need_to_repeat_distupgrade script that figures out if you need to go multi-arch and repeat the dist-upgrade. Idealy this will be enough. ia32-libs should be held back on upgrade until i386 is added as foreign architecture. Same for wine. But apt-get or aptitude might decide to remove the package instead of holding it back. If so then we need more detailed instructions for the release nodes. So some automatic testing of upgrades will be invaluable. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679671: [Pkg-ia32-libs-maintainers] Bug#679671: ia32-libs-i386: depends on removed package libdb4.8
Sven Joachim svenj...@gmx.de writes: Package: ia32-libs-i386 Version: 20120616 Severity: serious Your package depends on libdb4.8 which is no longer available in unstable. It is still in wheezy. I assume it is going to be removed there as well? Dear Release Team, as per http://release.debian.org/wheezy/freeze_policy.html I'm CCing you on this bug (#679671) to ask for a freeze exception. == diff -Nru ia32-libs-20120616/debian/control ia32-libs-20120701/debian/control --- ia32-libs-20120616/debian/control 2012-06-16 21:30:00.0 +0200 +++ ia32-libs-20120701/debian/control 2012-07-01 10:54:26.0 +0200 @@ -31,7 +31,7 @@ libavahi-common3 (= 0.6.27-2+squeeze1), libbsd0 (= 0.2.0-1), libcap2 (= 1:2.19-3), libcomerr2 (= 1.41.12-4stable1), libcups2 (= 1.4.4-7+squeeze1), - libcurl3 (= 7.21.0-2), libdb4.8 (= 4.8.30-2), + libcurl3 (= 7.21.0-2), libdbus-1-3 (= 1.2.24-4+squeeze1), libdirectfb-1.2-9 (= 1.2.10.0-4), libdrm-intel1 (= 2.4.21-1~squeeze3), libdrm-radeon1 (= 2.4.21-1~squeeze3), libdrm2 (= 2.4.21-1~squeeze3), libedit2 (= 2.11-20080614-2), == The package is uploaded to mentors awaiting sponsoring: http://mentors.debian.net/package/ia32-libs http://mentors.debian.net/debian/pool/main/i/ia32-libs/ia32-libs_20120701.dsc MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679671: [Pkg-ia32-libs-maintainers] Bug#679671: ia32-libs-i386: depends on removed package libdb4.8
Adam D. Barratt a...@adam-barratt.org.uk writes: [Dropped pkg-db-devel from Cc because it apparently doesn't accept posts from non-subscribers] On Sun, 2012-07-01 at 11:56 +0100, Adam D. Barratt wrote: Looking at the package currently in unstable, I do have to ask what happened to: ia32-libs-20120616/debian/copyright|13164 -- Answering my own question, it's presumably a side-effect of no longer embedding loads of other packages, so not needing to ship their copyright information. Regards, Adam Indeed. It's just 2 empty transitional packages now that pull in everything that used to be in ia32-libs through dependencies. So no embedding of loads of other packages and therefore no need to repeat the copyright infos. You will notice it got ~400MB smaller too (including binaries). MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679826: zsnes: segfaults on start in testing i386
Package: zsnes Version: 1.510+bz2-3 Severity: grave Running zsnes in a wheezy i386 chroot gives a segfault: # zsnes ZSNES v1.51, (c) 1997-2007, ZSNES Team Be sure to check http://www.zsnes.com/ for the latest version. ZSNES is written by the ZSNES Team (See AUTHORS.TXT) ZSNES comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; please read 'LICENSE.TXT' thoroughly before doing so. Use ZSNES -? for command line definitions. Starting Mouse detection. /dev/input does not exist or is inaccessable ManyMouse: -1 mice detected. Segmentation fault MfG Goswin -- System Information: Debian Release: wheezy APT prefers testing APT policy: (500, 'testing') Architecture: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages zsnes depends on: ii libao4 1.1.0-2 ii libc6 2.13-33 ii libgcc1 1:4.7.0-8 ii libgl1-mesa-glx 8.0.3-1 ii libncurses5 5.9-9 ii libpng12-0 1.2.49-1 ii libsdl1.2debian 1.2.15-5 ii libstdc++6 4.7.0-8 ii libtinfo5 5.9-9 ii zlib1g 1:1.2.7.dfsg-13 zsnes recommends no packages. zsnes suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679524: Build-Depends on obsolete package ia32-libs-dev
Package: libvdpau Version: 0.4.1-6 Severity: serious Hi, as has long been anounced ia32-libs-dev will not be in wheezy since 32bit support will be replaced by multiarch. Since your package still Build-Depends on ia32-libs-dev this means it will no longer build from source. Please multiarchify your package. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679525: Build-Depends on obsolete package ia32-libs-dev
Package: wine-unstable Version: 1.3.15-0.1 Severity: serious Hi, as has long been anounced ia32-libs-dev will not be in wheezy since 32bit support will be replaced by multiarch. Since your package still Build-Depends on ia32-libs-dev this means it will no longer build from source. Please multiarchify your package. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679526: Build-Depends on obsolete package ia32-libs-dev
Package: zsnes Version: 1.510+bz2-3 Severity: serious Hi, as has long been anounced ia32-libs-dev will not be in wheezy since 32bit support will be replaced by multiarch. Since your package still Build-Depends on ia32-libs-dev this means it will no longer build from source. Please multiarchify your package. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679526: Build-Depends on obsolete package ia32-libs-dev
Fabian Greffrath fab...@greffrath.com writes: block 679526 by 638741 thanks Am 29.06.2012 14:23, schrieb Goswin von Brederlow: as has long been anounced ia32-libs-dev will not be in wheezy since 32bit support will be replaced by multiarch. Since your package still Build-Depends on ia32-libs-dev this means it will no longer build from source. Please multiarchify your package. That's easier said than done. This week I tried to install zsnes:i386 on amd64 and it failed, because one of its dependencies was not yet multiarchyfied. I am looking at you, libao! - Fabian As mentioned in the bug log for 638741 the zsnes package doesn't have to wait for libao4. It should only set M-A: foreign and drop the amd64 build. It will then be installable with libao4:i386 if libao4:amd64 isn't installed. Not ideal but ... As for libao4 and the multiarch patch in the BTS. I took a quick look at the patch and I consider that incomplete. As is it switches the plugin dir to the multiarch dir without providing backward compatibility. That means the patch breaks all plugins for libao4 and they all need to be multiarchified together with versioned Breaks and Depends. This is usualy not ideal. Better would be to have libao4 look in both the old plugin dir as well as the new plugin dir. That way plugins can be multiarchified over time. Other than that the patch looks fine. MfG Goswin PS: When you do decide to multiarchify libao4 please file bugs against all the plugin packages if not already present and user tag them with user = multiarch-de...@lists.alioth.debian.org, usertag = multiarch. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679525: closed by Michael Gilbert mgilb...@debian.org (Re: [pkg-wine-party] Bug#679525: Build-Depends on obsolete package ia32-libs-dev)
ow...@bugs.debian.org (Debian Bug Tracking System) writes: This is an automatic notification regarding your Bug report which was filed against the wine-unstable package: #679525: Build-Depends on obsolete package ia32-libs-dev It has been closed by Michael Gilbert mgilb...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Michael Gilbert mgilb...@debian.org by replying to this email. -- 679525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679525 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems From: Michael Gilbert mgilb...@debian.org Subject: Re: [pkg-wine-party] Bug#679525: Build-Depends on obsolete package ia32-libs-dev To: 679525-cl...@bugs.debian.org Cc: Debian Bug Tracking System sub...@bugs.debian.org Date: Fri, 29 Jun 2012 12:18:30 -0400 version: 1.5.0-1 On Fri, Jun 29, 2012 at 8:22 AM, Goswin von Brederlow wrote: Package: wine-unstable Version: 1.3.15-0.1 Severity: serious Hi, as has long been anounced ia32-libs-dev will not be in wheezy since 32bit support will be replaced by multiarch. Since your package still Build-Depends on ia32-libs-dev this means it will no longer build from source. ÃÂ Please multiarchify your package. This has been fixed for the past couple uploads. I'm not sure why the source for 1.3.15 is still lingering around in unstable. Best wishes, Mike Package: libwine-unstable Source: wine-unstable Version: 1.3.15-0.1 Architecture: amd64 Did you forget to request the removal of packages no longer build by wine-unstable? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677741: Multiarch issues
Package: ia32-libs Version: 20120616 Severity: grave Meta bug to track the remaining issues with a multiarch ia32-libs. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ia32-libs depends on: ii dpkg 1.16.2 ii lib32asound2 1.0.25-2 ii lib32bz2-1.0 1.0.6-1 ii lib32gcc1 1:4.6.2-5 ii lib32ncurses5 5.9-5 ii lib32stdc++6 4.6.2-5 ii lib32v4l-0 0.8.6-2 ii lib32z11:1.2.7.dfsg-2 ii libc6-i386 2.13-32 ia32-libs recommends no packages. Versions of packages ia32-libs suggests: ii ia32-libs-gtk 20120102 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677762: Multiarch issues
Package: ia32-libs-gtk Version: 20120102 Severity: serious Meta bug to track the remaining issues with a multiarch ia32-libs-gtk. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ia32-libs-gtk depends on: ii ia32-libs 20120102 ii lib32asound2 1.0.25-2 ii lib32gcc1 1:4.6.2-5 ii lib32stdc++6 4.6.2-5 ii lib32z1 1:1.2.7.dfsg-2 ii libc6-i3862.13-32 ia32-libs-gtk recommends no packages. ia32-libs-gtk suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676372: API breakage
Package: libdebian-installer4
Version: 0.80
Severity: serious
File: /usr/lib/libdebian-installer.so.4
At some point between squeeze and wheezy the declaration of
di_release_file.sum has changed from char * to char **. This breaks
the API making it impossible to compile software (e.g. cdebootstrap)
for stable and testing/unstable without ugly hacks. For example in
cdebootstrap the following code is needed:
if (sizeof(item-sum[0]) == sizeof(char*)) {
if (item-sum[1])
return check_sum (target, sha1sum, (const char*)(intptr_t)item-sum[1],
buf_name);
if (item-sum[0])
return check_sum (target, md5sum, (const char*)(intptr_t)item-sum[0],
buf_name);
} else {
return check_sum (target, md5sum, (const char*)item-sum,
buf_name);
}
This is an API and ABI breakage requiring a rename to
libdebian-installter5[-dev].
Alternatively change the declaration of struct di_release_file to
struct di_release_file
{
union
{
char *filename; /** filename */
di_rstring key; /** @internal */
};
unsigned int size;/** size */
char *sum;/** checksum, currently md5 or
sha */
char *sums[2]; /** checksums, currently md5
and sha1 */
};
filling both sum and sums.
It would be nice to also have some define declared so sources can
check if di_release_file.sums is available. Something simpler than
having to compare the LIBDI_VERSION like
#define DEBIAN_INSTALLER__RELEASE_MULTISUM 1
#define DEBIAN_INSTALLER__RELEASE_SUM0 md5
#define DEBIAN_INSTALLER__RELEASE_SUM1 sha1
MfG
Goswin
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages libdebian-installer4 depends on:
ii libc6 2.13-32
libdebian-installer4 recommends no packages.
libdebian-installer4 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671302: Circular Build Dependencies
Andres Mejia amejia...@gmail.com writes: On May 3, 2012 10:20 AM, Andres Mejia amejia...@gmail.com wrote: On May 3, 2012 9:30 AM, Pino Toscano p...@debian.org wrote: Alle giovedì 3 maggio 2012, Andres Mejia ha scritto: On Thu, May 3, 2012 at 3:44 AM, Pino Toscano p...@debian.org wrote: Package: libav Version: 6:0.8.1-7 Severity: important Hi, libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav libraries. This currently makes libav unbuildable on mipsel and hurd-i386, and generically makes libav no more bootstrap'able without having itself compiled already. Could you please drop the opencv usage again, please? What could be done instead is a binary only upload with opencv support disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not require changing the version. Once this package is uploaded, the release team can then be asked to do a binNMU for these archs, which will bring back opencv support since the archive will contain the regular *.debian.tar.gz changes that included opencv. I believe this is better than doing a full build on all archs without opencv, then doing another build with opencv. This mess (which is only a mess, not a clean solution) does not solve at all the fact that you cannot do a clean build of libav without having libav compiled already (for opencv). I don't see this as a viable solution, especially if in the future the epoch is raised bringing again conflicts between the old libav libraries and the new one. -- Pino Toscano I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel. ~ Andres Hello all, I would like to know if there is a good (perhaps best) approach in resolving issues with packages with circular build dependencies. Libav has various circular build dependencies including. libav - opencv - libav libav - x264 - libav libav - x264 - gpac - libav I found some mention of this issue at [1]. This however doesn't offer any clear solution. 1. http://wiki.debian.org/DebianBootstrap ~ Andres gcc depends on gcc. *gasp* I think at some point you simply have to live with such circular Build-Depends. [1] offers a solution, or the begining of one, using stages (see Mechanism). What is unclear about the idea? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664257: multiarch tuples are not documented/defined
Matthias Klose d...@debian.org writes: On 21.03.2012 11:26, Goswin von Brederlow wrote: Matthias Klosed...@debian.org writes: On 19.03.2012 15:34, Jonathan Nieder wrote: Goswin von Brederlow wrote: Did you read the wiki page? Yes. Is the kind of information on which calling convention, basic system library structures, and so on form the ABI for a given tuple that I was giving examples of not what the upstream gcc folks were looking for? I'm not sure I understand the point of your question. Ah, maybe this is where we are talking past each other: I read this as a request to pin down and document the definition of each multiarch tuple. Perhaps you read it as a request to pin down and document the definition of the term multiarch tuple, without necessarily pinning down the details for each arch. It would certainly be useful to clarify which is needed before deciding which to spend time on, so thanks for asking. Matthias? first thing would be the documentation of each tuple currently used by Debian (including the ones used for the non-default biarch multilibs). If we can come up with a definition of multiarch tuple later that's fine, but given that we did abandon the earlier approach I'm not sure that's possible. Matthias Should we even have biarch in the multiarch world? multilib libraries should continue to build. Time will tell. The biarch libs and foreign libs installed through multiarch implement the same ABI/calling convention/functionality. They are basically interchangable. To make them truely interchangable the multiarch tuple for biarch libs should be the same as they would have if they were the native one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as example from now on]. And they should use the same paths. If there is no native equivalent for some biarch lib then just make up some multiarch tuple based on the gnu triplet. The only thing that matters is that it uniquly identifies the calling convention of the lib. For Debian (wheezy+x) I would like to see gcc-multilib depend on libc6:i386 instead of libc6-i386. Or maybe remove multilib support alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc -m32 could remain for compatibility but call i486-linux-gnu-gcc. no. adding cross-architecture build dependencies doesn't add to the build stability. The possibility to call another version or target Nobody is talking about cross-architecture build dependencies. As said building 32bit stuff on amd64 in the multiarch world is pointless. The same stuff can just be gotten from i386 directly. And if no source builds 32bit stuff on amd64 then we do not need multilib. And if nothing needs multilib then you do not need to build it and thus do not need to build-depend on cross-architecture stuff to build it. compiler from the driver was removed upstream, so I doubt somebody want to re-add it again, and I won't carry this as a downstream patch (so please get the done in stage1 for 4.8 if you are interested in that). Fair enough. Overall it would make no sense that I have to call armel-linux-gnu-gcc to build for arm but gcc -m32 to build for i386 in a multiarch world [again example with amd64 as native arch]. After all with multiarch having anything build for 32bit in amd64 is wastefull as it just duplicates the package already in i386. Same with ppc / ppc64, ... yes, but you are quick to waste my own time. Patches which do not go upstream do require an extra maintenance effort as seen for the split build (gcc, gcj, ...) and the hardening patches. A lot of multilib packages can be dropped, but the ones built from gcc and glibc should continue to build. Nobody is holding a gun to your head and forcing you to invest any time. Although I would say dropping multilib would rather safe you a lot of time and maintainance effort than cost you anything. And since multilib is enabled in debian/* there is no patch that would need to go upstream. Wheezy+x is a long way in the future so lets just wait and see. There is still a lot of work to do for multiarch before dropping multilib support from gcc can even be considered. No point arguing about that now. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664257: multiarch tuples are not documented/defined
Matthias Klose d...@debian.org writes: On 19.03.2012 15:34, Jonathan Nieder wrote: Goswin von Brederlow wrote: Did you read the wiki page? Yes. Is the kind of information on which calling convention, basic system library structures, and so on form the ABI for a given tuple that I was giving examples of not what the upstream gcc folks were looking for? I'm not sure I understand the point of your question. Ah, maybe this is where we are talking past each other: I read this as a request to pin down and document the definition of each multiarch tuple. Perhaps you read it as a request to pin down and document the definition of the term multiarch tuple, without necessarily pinning down the details for each arch. It would certainly be useful to clarify which is needed before deciding which to spend time on, so thanks for asking. Matthias? first thing would be the documentation of each tuple currently used by Debian (including the ones used for the non-default biarch multilibs). If we can come up with a definition of multiarch tuple later that's fine, but given that we did abandon the earlier approach I'm not sure that's possible. Matthias Should we even have biarch in the multiarch world? The biarch libs and foreign libs installed through multiarch implement the same ABI/calling convention/functionality. They are basically interchangable. To make them truely interchangable the multiarch tuple for biarch libs should be the same as they would have if they were the native one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as example from now on]. And they should use the same paths. If there is no native equivalent for some biarch lib then just make up some multiarch tuple based on the gnu triplet. The only thing that matters is that it uniquly identifies the calling convention of the lib. For Debian (wheezy+x) I would like to see gcc-multilib depend on libc6:i386 instead of libc6-i386. Or maybe remove multilib support alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc -m32 could remain for compatibility but call i486-linux-gnu-gcc. After all with multiarch having anything build for 32bit in amd64 is wastefull as it just duplicates the package already in i386. Same with ppc / ppc64, ... MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664257: multiarch tuples are not documented/defined
Jonathan Nieder jrnie...@gmail.com writes: Matthias Klose wrote: While we strive to get multiarch ready for squeeze, there is currently nothing to point to what the multiarch tuples actually mean, neither on the Debian side nor on some kind of standards side like the FHS or LSB. This has to be documented on the Debian side, and better be incorporated into standards like the FHS or LSB. The current state is http://wiki.debian.org/Multiarch/Tuples, deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An email to debian-ports didn't get any feedback. From my point of view such a wiki page should be self-contained and be usable as a reference for upstream projects. Thanks. To start (warning: the following is just a bunch of guesses, many of which are almost certainly wrong): Did you read the wiki page? If I had to define the multiarch tuple I would say: The multiarch tuple uniquly defines the calling convention used in a binary or library. For convenience the first GNU triplet implementing a calling convention is used where possible or suitably extended to remain unique. If there are multiple libraries with different ABIs but with the same calling convention (e.g. i386, i486, i586, ...) so that they can be interchanged without binaries needing to be recompiled then they share a multiarch tuple (i386-linux-gnu). On the other hand if one ABI has multiple calling conventions (hard/soft floats on arm) then the multiarch tuples must differ for each calling convention. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657557: [PATCH] Alternate patch for missing long descriptions
Cyril Brulebois k...@debian.org writes:
For the sake of getting my fellow packages/translations maintainers to
get the whole picture since you insist so much on proposing a wrong
solution and calling mine âpapering over the bugâ, I'll reply anyway.
Please don't make up quotes I never said. And thanks for finally
responding with more than wrong to support your case even if it
doesn't explain why long description in the package db are neccessary or
give an example what remains broken with just my patch.
Goswin von Brederlow goswin-...@web.de (22/02/2012):
Now my patch (attached) fixes this problem by only computing the
description-md5 field if it is missing in Packages.bz2. A simple one
line fix. The rest of the code already does all the right things and
looks up the translation correclty including falling back to 'en' as
needed.
That's only if you're interesting in getting the translations back.
Which is what is done when generating the webpages so this seems rather
important to me.
Now
go read the block of code right above $data{'description-md5'}â¦
Let see:
# we add some additional data here
my $descr = $data{'description'}\000$data{'package'}\000
.($data{'tag'}||'');
Description in database format.
my $sdescr = $data{'description'};
$sdescr =~ s/\n.*//os;
Description in text format.
my $did = undef;
if (exists($descriptions{$descr})) {
$did = $descriptions{$descr};
} else {
$did = 1 + $#descriptions;
$descriptions[$did] = $descr;
$descriptions{$descr} = $did;
}
Reuse the same $did if the description already exists.
Ok, so without your patch this bit of code will share a $did if the
short description matches. That certainly differs from what it used to
do. So lets see what effect that has:
- http://localhost/sid/comixcursors -
Package: comixcursors (0.7.2-2)
transitional dummy package
ComixCursors is a set of mouse pointer themes for X11 in the style of
comic-book art.
This package is transitional to install the right-handed, translucent cursor
set, which is now in the \u2018comixcursors-righthanded\u2019 package.
Tags: Role: Application Data, Dummy Package, X Window System: Theme
Packages providing comixcursors
...
- http://localhost/sid/ttf-aoyagi-soseki -
Package: ttf-aoyagi-soseki (20070207-6)
transitional dummy package
This package is a dummy transitional package. It can be safely removed.
Tags: Culture: Japanese, Made Of: Font, Role: Standalone Data, Dummy Package
...
--
Oh wait, we always use the description from the translation file even if
it is the english translation.
Correct me if I'm wrong but here is how I understand Cyrils patch: It
works by fixing the symptom instead of the problem. In [PATCH 2/4] it
checks if the Packages.bz2 file contains an description-md5 field, If
so it looks up the english translation for the package and replaces
the description with the english translation, thereby restoring the
long description for the package (line 146 with his patch).
⦠and this is needed so that storing the description in the database
(what I pointed to above: $descr, $sdescr, etc.) happens properly,
meaning: the long description, not the short one only.
True. Without your patch the long description is no longer stored in the
package database, only in the translations database.
What you haven't explained is why that is needed. Without your patch the
packages_descriptions.db (ever only used by bin/parse-packages) and
descriptions_packages.db (used in DoShow.pm and Search.pm) will have
bogus entries.
But the package pages show the translation and searching in the
descriptions also seems to properly look into the english translations.
E.g. searching for It can be safely removed gives among others:
--- http://localhost/search?searchon=allkeywords=It+can+be+safely+removed ---
...
Package gnash-opengl
sid (unstable) (oldlibs): dummy package for gnash-opengl removal
0.8.10-3: all
- http://localhost/sid/gnash-opengl -
Package: gnash-opengl (0.8.10-3)
dummy package for gnash-opengl removal
This package is a transitional package for gnash-opengl removal.
It can be safely removed when Gnash is installed.
Tags: User Interface: X Window System, Role: Dummy Package, Program, Interface
Toolkit: uitoolkit::gtk, use::playing, Supports Format: SWF, ShockWave Flash,
Works with: works-with::audio, works-with::video, X Window System: Application
--
As you can see the search string only appears in the long description
(meaning the english translation) and not the short description
Bug#657557: [PATCH] Alternate patch for missing long descriptions
Package: www.debian.org
Followup-For: Bug #657557
Hi,
Cyril and I disagree about the cause for the missing description and
the fix for it. So someone impartial please look over both out patches
and see which makes more sense. In both cases the english translations
must be added to ddtplangs [Patch 1/4] from Cyril [1], I didn't
want to repost that.
Here is how I see the problem:
1) Originaly Packages.bz2 contained the long description and no
description-md5 field (still does for older releases).
2) Translations are indexed by the md5 of the original long description.
3) bin/parse-packages computes description-md5 and stores it in the
packages database.
4) When generating the webpages the description-md5 is used to lookup
the translated description with fallback to english and the
original description.
But in sid the Packages.bz2 files now contain a description-md5 field
and only the short description instead of the short and long
description. This cause the computation in (3) above to compute the
md5sum of only the short description and then the translation lookup
in (4) fails to find a translation and falls back to the original
description, which is only the short description.
Now my patch (attached) fixes this problem by only computing the
description-md5 field if it is missing in Packages.bz2. A simple one
line fix. The rest of the code already does all the right things and
looks up the translation correclty including falling back to 'en' as
needed. E.g.:
- http://localhost/sid/gcc ---
Package: gcc (4:4.6.2-4)
GNU C compiler
This is the GNU C compiler, a fairly portable optimizing compiler for C.
This is a dependency package providing the default GNU C compiler.
Tags: Software Development: Compiler, C Development, User Interface:
interface::commandline, role::metapackage, Role: Program, Application Suite:
suite::gnu, works-with::software:source
Other Packages Related to gcc
...
- http://localhost/de/sid/gcc
Paket: gcc (4:4.6.2-4)
Der GNU-C-Compiler
Dies ist der GNU-C-Compiler, ein recht portabler, optimierender C-Compiler.
Dies ist ein Abhängigkeitspaket, welches den Standard-GNU-C-Compiler zur
Verfügung stellt.
Markierungen: Software-Entwicklung: Compiler, C-Entwicklung,
Benutzer-Schnittstellen: interface::commandline, role::metapackage, Rolle:
Programm, Anwendungs-Suite: suite::gnu, works-with::software:source
Andere Pakete mit Bezug zu gcc
...
-- http://localhost/de/sid/3depict --
Paket: 3depict (0.0.9-1 und andere)
visualisation and analysis for single valued point data
This program provides a graphical interface for the scientific analysis of real
valued point data (x,y,z,value). This is primarily targeted towards Atom probe
tomography applications, but may prove useful to other applications as well.
Markierungen: Benutzer-Schnittstellen: X-Window-System, Rolle: Programm,
GUI-Baukasten: wxWidgets, Zweck: use::analysing, x11::application
Andere Pakete mit Bezug zu 3depict
--
3depict has no german translation so the english translation is used
as it should.
Correct me if I'm wrong but here is how I understand Cyrils patch: It
works by fixing the symptom instead of the problem. In [PATCH 2/4] it
checks if the Packages.bz2 file contains an description-md5 field, If
so it looks up the english translation for the package and replaces
the description with the english translation, thereby restoring the
long description for the package (line 146 with his patch). And now
that the long description has been restored the computation of
description-md5 a few lines later computes to the right value, the one
that is already present. And with the right description-md5 value the
translation lookup when generating the pages functions again. [PATCH
3/4] and [PATCH 4/4] then tidy things up and make it possible to do an
english only run for bin/parse-translations. The reason for this is
that with his patch bin/parse-packages requires an in-sync translation
database to function.
MfG
Goswin
1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657557#29
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
diff --git a/bin/parse-packages b/bin/parse-packages
index a1c8d98..1cb2075 100755
--- a/bin/parse-packages
+++ b/bin/parse-packages
@@ -142,7 +142,7 @@ for my $suite (@SUITES) {
$descriptions[$did] = $descr;
$descriptions{$descr} = $did;
}
- $data{'description-md5'} = Digest::MD5::md5_hex($data{'description'}, \n);
+ $data{'description-md5'} = Digest::MD5::md5_hex($data{'description'}, \n) if (!exists($data{'description-md5'}));
$data{'description'} = $did;
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Guillem Jover guil...@debian.org writes: Hi! On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote: Roger Leigh wrote: I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Didn't the hurd port try this several years ago? My impression was that they didn't feel it had been worth the pain, perhaps it's not so easy. The old default was changed for GNU/Hurd not because the setup in itself was considered particularly painful, more because doing so for a single port w/o getting the distribution at large to agree this was something worth supporting was painful as overwrite problems were continuously introduced. regards, guillem Plus you can not ship /usr as symlink in one package and as directory in others. That triggers a file overwrite error during update (for the package containing the symlink). We had this problem with packages shipping files in /lib64 or /usr/lib64 in the past several times. So if /usr is a symlink then everyone has to change to --prefix=/. That is what makes linking /bin and /sbin to /usr/* easier. Less packages to change. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Russ Allbery r...@debian.org writes: Zachary Harris zacharyhar...@hotmail.com writes: My understanding of the FHS would be that if a library is a dependency of a binary in /bin or /sbin, then such library belongs in /lib, not /usr/lib. (If for some reason the library is also desired in /usr/lib then a sym link from /lib to /usr/lib, but not the other way around, is acceptable.) A review of past bug reports (e.g. #633019 and #639939 from this summer) shows that this policy gets repeatedly violated in Debian until someone catches it. I'm increasingly convinced by the recent discussion on debian-devel that doing all the (rather substantial) work required to keep this separation working is a waste of our collective time. We're not doing a very good job at it anyway, chasing all the library dependencies is a fair amount of work, and things have to keep moving around as dependencies change. And this is all to support use cases that, while real, are fairly marginal in my estimation. This does not seem like the most effective place for us to be spending our time. I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. Absolutely NO, NO, NO. You can't just break all the systems out there that do have a seperate /usr partition. And that isn't what was suggested. The suggested approach is to have /usr mounted in initramfs (or in one of the first boot scripts). So what Debian could officially say is that /usr will be mounted and packages may freely use it at any time during boot. That the seperation of / and /usr becomes unimportant because both will always be available. But before any of that happens please first show us a working implementation of mounting /usr from initramfs and as first thing during boot. And that should probably be included in a stable release before the seperation of / and /usr is declared meaningless. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh rle...@codelibre.net writes:
On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from / (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in pure
Debian, rather than, say, in Ubuntu.
This is a bit beside the point. People keep bringing up mounting /usr
over NFS. No one to date has provided a sensible use case for it.
This is because old timers (or whoever) have failed to notice a
fundamental flaw: *package management does not work with a shared /usr*.
The cluster setup I use at work uses an initramfs with all the essential
stuff in it and mounts the rest over NFS. The reason why this works is
that the / is just as shared as /usr. Just one is shared via pxe and
then other via NFS.
The reason for not having everything on NFS is to reduce network load
and that nodes should be minimally functional without NFS. Esspecially
that you can still log in as root and diagnose problems.
On a Debian there are really only two categories for partitions:
those under the control of the package manager, and those which
are not (user data etc.). Does it make sense to split package-managed
files over multiple partitions? (other than /var)
This is *the* key point. Under a package managed distribution /
and /usr are part of a *managed whole*. They can't exist separately,
even if they are on different partitions, mounted over NFS, or
whatever. It's fine that such things /work/, but we do need to
question /why/ one would do such a thing. If you're mounting /usr
over NFS, the real question is why aren't you mounting / over NFS,
which also then includes /usr?. Mounting /usr separately makes no
sense *at all*.
The same argument applies to encryption. / and /usr both contain a
selection of programs, libraries etc. If you're encrypting one, why
would you not encrypt all of it? And the same for mounting read-only.
/, specifically /etc, contains sensitive information so it has to be
encrypted. /usr on the other hand does not and encrypting it is just a
waste of cpu time.
This would actually call for having /etc a seperate (encrypted)
partition and /usr not. Encrypting /bin or /lib is indeed as useless as
/usr.
The question that needs answering is this:
what are the reasons, today, for a separate /usr?
Excluding historical practice. What real function does it have?
Does it have any reason to continue to exist?
And regarding the LSB: I checked, and it would be entirely compliant
for Debian to merge the two.
Enforce a
policy that anything being put into /sbin or /bin must pass the ldd
test. If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either downgrade the binary to /usr/{s,}bin
or upgrade the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers essential in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).)
The problem here is, can we /be/ consistent? What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs. We can't be all
things to all people in the current state. But unification /would/
*guarantee* things would always work and be consistent: every
program and library would always be right there on the rootfs.
You are not reading him.
consistent == if it is in /sbin or /bin then it works without /usr.
consistent != everything even some insane user might want in / is in /.
That was exactly his point.
The status quo is a best effort. Things sometimes break, and
there's an continuing migration of essential packages to the
rootfs. Given that a modern initramfs can mount pretty much any
filesystem, either locally or over a network, what's the *real*
reason for a separate /usr? It's certainly not for any booting-
related reason.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642310: overwrite error: /usr/share/man/man2/io_getevents.2.gz
Guillem Jover guil...@debian.org writes: On Wed, 2011-09-28 at 10:30:53 +0200, Goswin von Brederlow wrote: Guillem Jover guil...@debian.org writes: On Wed, 2011-09-21 at 14:28:46 +0200, Goswin von Brederlow wrote: Trying to upgarde libaio-dev fails with: Unpacking replacement libaio-dev ... dpkg: error processing /var/cache/apt/archives/libaio-dev_0.3.109-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man2/io_getevents.2.gz', which is also in package manpages-dev 3.28-1 This is a bug in manpages, which included those when libaio-dev has always provided them, fixed in manpages-dev 3.32-0.2, you should upgrade that one. (Bug #636704) Upgrades have to work in any order or packages have to say otherwise (breaks, conflicts, replaces, ...) so that isn't really a solution. We are talking about a buggy package (manpages-dev) that does not exist anymore on the archive, is not in any stable release, and for which there's a fix released in testing already. So for starters serious here is way way out of proportion. Even if libaio-dev was to drop the pages right now, there would still be a period where upgrades can break, there's no way around this fact. unstable and testing break from time to time, if you cannot cope with that do not use them... No, there wouldn't. Upgrading manpages-dev first would introduce the Replaces so that works and upgrading libaio-dev first would remove the conflicting files. So either order would work, unlike now. Also manpages-dev says: * debian/control: add Replace against libaio-dev, because of aio_init.3.gz and lio_listio.3.gz (Closes: #636704) That is only approriate when the files are moved from libaio-dev to manpages-dev and clearly libaio-dev has not droped those files. They have not moved yet, that does not make manpages-dev wrong, neither libaio-dev. If manpages-dev did not have missed the Replaces on the first place the overwritting issue would not have ever existed. So one or both of the two packages are wrong. I strongly disagree, and as such I'm re-closing this now. regards, guillem MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642310: overwrite error: /usr/share/man/man2/io_getevents.2.gz
reopen 642310 thanks Guillem Jover guil...@debian.org writes: On Wed, 2011-09-21 at 14:28:46 +0200, Goswin von Brederlow wrote: Package: libaio-dev Version: 0.3.109-1 Severity: serious Trying to upgarde libaio-dev fails with: Unpacking replacement libaio-dev ... dpkg: error processing /var/cache/apt/archives/libaio-dev_0.3.109-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man2/io_getevents.2.gz', which is also in package manpages-dev 3.28-1 This is a bug in manpages, which included those when libaio-dev has always provided them, fixed in manpages-dev 3.32-0.2, you should upgrade that one. (Bug #636704) thanks, guillem Upgrades have to work in any order or packages have to say otherwise (breaks, conflicts, replaces, ...) so that isn't really a solution. Also manpages-dev says: * debian/control: add Replace against libaio-dev, because of aio_init.3.gz and lio_listio.3.gz (Closes: #636704) That is only approriate when the files are moved from libaio-dev to manpages-dev and clearly libaio-dev has not droped those files. So one or both of the two packages are wrong. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642310: overwrite error: /usr/share/man/man2/io_getevents.2.gz
Package: libaio-dev Version: 0.3.109-1 Severity: serious Trying to upgarde libaio-dev fails with: Unpacking replacement libaio-dev ... dpkg: error processing /var/cache/apt/archives/libaio-dev_0.3.109-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man2/io_getevents.2.gz', which is also in package manpages-dev 3.28-1 MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libaio-dev depends on: iu libaio1 0.3.109-2 Linux kernel AIO access library - libaio-dev recommends no packages. libaio-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635512: File overwrite error
Package: kdelibs5-plugins Version: 4:4.4.5-2 Severity: serious I assume you moved the plugins into their own package. But then you need to use Replaces: kdelibs5 ( 'version after split'~~). (Reading database ... 181944 files and directories currently installed.) Preparing to replace kdelibs5-plugins 4:4.4.5-2 (using .../kdelibs5-plugins_4%3a4.6.5-2_amd64.deb) ... Unpacking replacement kdelibs5-plugins ... dpkg: error processing /var/cache/apt/archives/kdelibs5-plugins_4%3a4.6.5-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/qt4/plugins/designer/kdewidgets.so', which is also in package kdelibs5 4:4.3.4-1 dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/kdelibs5-plugins_4%3a4.6.5-2_amd64.deb E: Sub-process /usr/lib/apt-ma-emu/dpkg returned an error code (1) MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-book-1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages kdelibs5-plugins depends on: ii dbus-x111.2.16-2 simple interprocess messaging syst pn kdelibs-bin none (no description available) pn kdelibs5-data none (no description available) pn kdoctools none (no description available) ii libacl1 2.2.51-3 Access control list shared library ii libaspell15 0.60.6-4 GNU Aspell spell-checker runtime l ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libenchant1c2a 1.6.0-1 a wrapper library for various spel ii libgcc1 1:4.4.4-13 GCC support library ii libgssapi-krb5-21.8.1+dfsg-2 MIT Kerberos runtime libraries - k ii libilmbase6 1.0.1-3 several utility libraries from ILM ii libjasper1 1.900.1-7The JasPer JPEG-2000 runtime libra pn libkdecore5 none (no description available) pn libkdeui5 none (no description available) pn libkfile4 none (no description available) pn libkhtml5 none (no description available) pn libkio5 none (no description available) pn libkjsapi4 none (no description available) pn libkjsembed4none (no description available) pn libkntlm4 none (no description available) pn libkparts4 none (no description available) pn libkrosscore4 none (no description available) pn libktexteditor4 none (no description available) pn libkutils4 none (no description available) ii libopenexr6 1.6.1-4.1runtime files for the OpenEXR imag pn libphonon4 none (no description available) ii libpolkit-qt-1-00.95.1-1 PolicyKit-qt-1 library pn libqt4-dbus none (no description available) pn libqt4-designer none (no description available) pn libqt4-network none (no description available) pn libqt4-script none (no description available) pn libqt4-xml none (no description available) pn libqtcore4 none (no description available) pn libqtgui4 none (no description available) ii libstdc++6 4.6.1-5 GNU Standard C++ Library v3 ii libx11-62:1.3.3-1X11 client-side library ii perl5.10.1-12Larry Wall's Practical Extraction ii shared-mime-info0.70-1 FreeDesktop.org shared MIME databa ii xdg-utils 1.0.2-6.1desktop integration utilities from ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages kdelibs5-plugins recommends: ii kaboom1.1.2 The Debian KDE settings migration pn kdebase-runtime none (no description available) ii ttf-dejavu2.30-2 Metapackage to pull in ttf-dejavu- kdelibs5-plugins suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612918: Writing to /etc/ from a privileged UI
David Paleino da...@debian.org writes: Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, Uses /etc/wicd/wireless-settings.conf as state file. My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. With / being mounted read-only, and yes there are more and more people who do have that again, /etc is not writable at runtime for anything. So your GUI will simply fail to work. I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable. I'd like to stick with files under /etc/, possibly. What's your opinion on this? I haven't searched thoroughly through the archive, but I guess there are other UIs run by privileged non-root users that write to /etc/? Didier, I hope I correctly summarised the bug you reported. If not, please reply :) Thanks for your suggestions, David The only way you can argue is that your GUI is a nice frontend for editing the static config in /etc/wicd/wireless-settings.conf. As such the admin needs to remount / read-write before running it just like he would before running 'sensible-editor /etc/wicd/wireless-settings.conf'. In that case you should detect when /etc is read-only and have good error messages. Maybe even have some way to automatically or with one click mount / read-write for the duration of the write. Note: For comparison in apt one can configure hooks to mount / read-write before invoking dpkg and read-only after. So apt-get upgrade works without having to remount / read-write first. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562234: Cache file location in violation of FHS
Alasdair G Kergon a...@redhat.com writes: On Thu, Dec 09, 2010 at 08:46:50AM +0100, Goswin von Brederlow wrote: In what case does it break? That's the wrong question:) You should ask: Under what conditions are its hard-coded assumptions about LVM metadata true? Alasdair Way to avoid answering. From the BTS I gather that grub2 can't handle mirrored LVs. Support for snapshots suposedly was fixed. No report about pvmove. Anything else with LVM in the topic is about install failures and pretty vague. So if you know of a way other than mirrored LVs to make grub2 fail then please do report a bug. It works here[tm], which makes it hard to debug and fix suposed problems. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562234: Cache file location in violation of FHS
Hi, the current cache file location (/etc/lvm) makes problems with a read-only / so something has to be done. On the other hand configuring it to /var/backups/ seems to work just fine all around. No problems so far even during boot (when /var isn't there yet). Since grub2 can now too boot directly from lvm and any software raid I think that /etc/lvm is far less likely to be on a non LVM parttion. Same can be said for /boot. So I see little to no drawback to using /var/backups, which is most likely on LVM. So I would suggest that the location for new installs should be /var/backups/lvm since that produces less problems overall. I'm a little conflicted what to do with exinsting installs, esspecially those where /etc is not on LVM. It would be greate to then leave the backup there but that would require some detection code and a dynamic lvm.conf (ucf?). Do you want to add some detection for a non LVM volume (/etc/lvm or /boot/lvm)? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562234: Cache file location in violation of FHS
Alasdair G Kergon a...@redhat.com writes: /etc/lvm has several functions. Read-only config - leave it where it is. Obviously. I was only meaning the writable parts. cache_dir - in general can be cleared on each boot so a tmpfs location would be fine or /var/cache or something Maybe /lib/init/rw/ then for it to work early during boot. Works without errors when pointed to /var/backups/lvm/ but it might have speed penalties. Not sure. Metadata backups ideally would be stored persistently outside lvm but otherwise /var/backups sounds OK (The locations of the *writeable* parts are configurable from inside the *readable* part.) On Wed, Dec 08, 2010 at 04:31:29PM +0100, Goswin von Brederlow wrote: Since grub2 can now too boot directly from lvm *Not* in general. It's unsafe for general use but works under certain undocumented configurations. Alasdair D-I lets you install it that way without warnings and doesn't need expert mode to allow it. The unsafeness seems to be a secret. In what case does it break? When you are in the middle of a pvmove? When the LV is split between devices? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605218: [Pkg-ia32-libs-maintainers] Bug#605218: Same problem: fresh installation
David Martin davidcmartin2...@yahoo.co.uk writes: I've just reinstalled Ubuntu 10.04 using the Wubi download and my first action is to try to get the Epson SX215 scanner working. It never worked in the previous installation because of an 'Error: Wrong architecture 'i386'' message. I've now worked out I needed the ia32-libs_20101117_amd64.deb (I'm still an Ubuntu novice) but that fails to install as reported here. However, the flash patch ia32-libs-workaround-499043 has not been installed (I've checked by trying to purge it). I installed the ia32-libs but still no joy. David Without showing the error I certainly can't help you. You should file Ubuntu errors under Ubuntu first too. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605218: [Pkg-ia32-libs-maintainers] Bug#605218: apt-get dist-upgrade fails to install ia32-libs
Michael Gilbert michael.s.gilb...@gmail.com writes: tag 605218 patch thanks On Wed, Dec 1, 2010 at 4:34 PM, Julien Cristau wrote: On Wed, Dec  1, 2010 at 16:18:54 -0500, Michael Gilbert wrote: Since ia32-libs-workaround-499043 is a third-party package, this really isn't Debian's problem. I think that the bug can be safely closed. In the meantime, this discussion can serve as a record for anyone else who may have installed the rogue package and run into the problem. NAK.  If the package was widely documented as the way to get flash on 64bit, then we need to handle the upgrade path, if only by conflicting against it. Please see attached patch. I've tested that this will successfully install the new ia32-libs and remove ia32-libs-workaround-499043 (if its installed) in the process. Mike It would have been more helpfull for someone to sponsor the already fixed package on mentors.debian.net. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602810: #602810 ia32-libs fails in postinst due to wrong version conditioning prior to dpkg-divert
Hi, The diversion code in postinst was changed some time ago. Please verify that the problem no longer exists in testing/unstable. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
Package: initramfs-tools Version: 0.93.4 Severity: critical File: /usr/share/initramfs-tools/init Tags: patch Hi, I recently installed a squeeze system. The generated /etc/fstab contains the following line: # file system mount point type options dump pass proc/proc procdefaults0 0 But in /usr/share/initramfs-tools/init you have: mount -t proc -o nodev,noexec,nosuid none /proc This causes mount to return an error when mounting all local filesystems because proc and none are different divices and it can't mount /proc again over an existing mountpoint. The /etc/init.d/mountall.sh script reports a red FAILED because of that. Node: /etc/mtab is a link to /proc/mounts here. That might affect this issue. Please change the mount command for proc to: mount -t proc -o nodev,noexec,nosuid proc /proc MfG Goswin -- Package-specific info: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-book-1 (SMP w/1 CPU core; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.10-1 GNU cpio -- a program to manage ar ii findutils 4.4.2-1utilities for finding files--find, ii klibc-utils 1.5.15-1 small utilities built with klibc f ii module-init-tools 3.11-1 tools for managing Linux kernel mo ii udev 161-1 /dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.14.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602810: [Pkg-ia32-libs-maintainers] Bug#602810: ia32-libs fails in postinst due to wrong version conditioning prior to dpkg-divert
Daniel Reichelt deb...@nachtgeist.net writes: Hi Julien, If it only happens with 3rd party packages I don't think this counts as serious. Short answer: if the 3rd party package is perfectly fine, that's no justification, ia32-libs postinstall script still is broken. Long answer: It may very well be disputable if my bug report is to be classified serious or not, however for a different reason, namely if said wrong conditioning of the cleanup code constitutes a violation of the suggested MO of dpkg-divert in the Debian Policy. And frankly I don't mind about the seriousness, I just hope it gets fixed :) So aside from that, serious or not: will the report receive ack status? Thanks, Daniel ACK. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597460: Please add support for Wheezy
Package: cdebootstrap Version: 0.5.6 Severity: serious Tags: squeeze, sid Hi, the next release will be called wheezy. Please add that to /usr/share/cdebootstrap/suites MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-debian-xen-1 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages cdebootstrap depends on: ii debian-archive-keyring2010.08.28 GnuPG archive keys of the Debian a ii gpgv 1.4.10-4 GNU privacy guard - signature veri ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libdebian-installer-extra40.75 Library of some extra debian-insta ii libdebian-installer4 0.75 Library of common debian-installer ii wget 1.12-2.1 retrieves files from the web cdebootstrap recommends no packages. cdebootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597461: Please add support for wheezy
Package: debootstrap Version: 1.0.23 Severity: serious Tags: squeeze sid The next release will be called wheezy. Please add support for that. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-debian-xen-1 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages debootstrap depends on: ii wget 1.12-2.1 retrieves files from the web Versions of packages debootstrap recommends: ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596727: [Pkg-ia32-libs-maintainers] Bug#596727: [ia32-libs]
gregory hainaut gregory.hain...@gmail.com writes: Package: ia32-libs Version: 20100908 --- Please enter the report below this line. --- As a side note: cairo was also removed. Maybe it is plane to add it to ia32-libs-gtk. Regards, Gregory As noted in the changelog, due to a dependency on libs in ia32-libs-gtk. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595431: Aborting fsck aborts all scripts in rcS.d
Kel Modderman k...@otaku42.de writes:
On Saturday 04 September 2010 06:39:49 Goswin von Brederlow wrote:
Package: insserv
Version: 1.14.0-2
Severity: critical
Hi,
during boot /etc/rcS.d/S13checkfs.sh starts a filesystem check (hasn't
been checked for 197 days) as well as giving some errors for missing
devices. Since I didn't want to wait for the fsck before fixing the
missing devices I aborted the check with crlt-c. This resulted in the
fsck to be aborted but then also skipped all further rcS.d scripts
saying:
Running scripts in rcS.d/ took 41 seconds.
INIT: Entering runlevel: 2
Given that filesystem weren't mounted or anything that didn't work out
well leaving the system unusable.
This is a serious regressions from before insserv. The old behaviour
was to display a message asking for the root password to get a shell
or ctrl-D to continue booting.
How does changing /etc/init.d/rc with the below patch modify behaviour?
Thanks, Kel.
--- rc~
+++ rc
@@ -43,7 +43,7 @@ on_exit() {
trap on_exit EXIT # Enable emergency handler
# Ignore CTRL-C only in this shell, so we can interrupt subprocesses.
-trap : INT QUIT TSTP
+trap INT QUIT TSTP
# Set onlcr to avoid staircase effect.
stty onlcr 01
Well, ask me in another 197 days when then fsck runs again. :)
Since it doesn't boot without handholding due to mdadm bugs I don't plan
to reboot the system any time soon, with or without forced fsck.
But you can check ourself by forcing a fsck for the next boot.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595431: Aborting fsck aborts all scripts in rcS.d
Sven Joachim svenj...@gmx.de writes: reassign 595431 sysvinit-utils found 595431 2.88-12 thanks On 2010-09-03 22:39 +0200, Goswin von Brederlow wrote: Package: insserv Version: 1.14.0-2 Severity: critical Hi, during boot /etc/rcS.d/S13checkfs.sh starts a filesystem check (hasn't been checked for 197 days) as well as giving some errors for missing devices. Since I didn't want to wait for the fsck before fixing the missing devices I aborted the check with crlt-c. This resulted in the fsck to be aborted but then also skipped all further rcS.d scripts saying: Running scripts in rcS.d/ took 41 seconds. INIT: Entering runlevel: 2 Given that filesystem weren't mounted or anything that didn't work out well leaving the system unusable. I can reproduce this, but only if parallel booting is enabled (the default). This is a serious regressions from before insserv. The old behaviour was to display a message asking for the root password to get a shell or ctrl-D to continue booting. Well, was it? I think Ctrl-c should just abort the fsck and continue the boot (this happens here with CONCURRENCY=none in /etc/default/rcS, but I don't have any actual filesystem problems and booted with the forcefsck option). Anyway, this seems to be a bug in startpar's signal handling, thus reassigning to sysvinit-utils. Sven In my case there were fsck errors because a raid device didn't come up and there it should give the prompt. At least that is the old behaviour. Continue to boot with devices missing isn't a good plan. But the cause will most likely be the same. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595431: Aborting fsck aborts all scripts in rcS.d
Package: insserv Version: 1.14.0-2 Severity: critical Hi, during boot /etc/rcS.d/S13checkfs.sh starts a filesystem check (hasn't been checked for 197 days) as well as giving some errors for missing devices. Since I didn't want to wait for the fsck before fixing the missing devices I aborted the check with crlt-c. This resulted in the fsck to be aborted but then also skipped all further rcS.d scripts saying: Running scripts in rcS.d/ took 41 seconds. INIT: Entering runlevel: 2 Given that filesystem weren't mounted or anything that didn't work out well leaving the system unusable. This is a serious regressions from before insserv. The old behaviour was to display a message asking for the root password to get a shell or ctrl-D to continue booting. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages insserv depends on: ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib insserv recommends no packages. Versions of packages insserv suggests: pn bootchart none (no description available) -- debconf information: * insserv/enable: true -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590888: Dependencies on init.d script insuficcient
Package: chrony Version: 1.23-7 Severity: serious File: /etc/init.d/chrony Hi, chrony lives in /usr and /usr is potentialy only present with $remote_fs, not $local_fs. Also the sendsigs script is run before $local_fs (after $remote_fs) on shutdown and chrony should stop before that. Depending on networking might also be an idea. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages chrony depends on: ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libreadline5 5.2-7 GNU readline and history libraries ii timelimit 1.5-1 Simple utility to limit a process' ii ucf 3.0025 Update Configuration File: preserv Versions of packages chrony recommends: ii udev 157-1 /dev/ and hotplug management daemo chrony suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589821: Kills systems ypbind when installing in chroot
Package: nis Version: 3.17-17 Severity: critical Hi, installing nis in a chroot with chroot $DIR apt-get install nis causes nis to break down on the main system. E.g. sudo says: YPBINDPROC_DOMAIN: Domain not bound YPBINDPROC_DOMAIN: Domain not bound sudo: unknown uid: 1009 Restarting nis on the main system fixes the problem. I beliefe the problem is the following in postinst: # And start the service. if [ $2 != -a $2 != ] dpkg --compare-versions $2 le 3.9-1 then killall ypbind /dev/null 21 || true fi which kills not just the ypbind in the chroot (of which there is none) but also any other ypbind including the systems one. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.5-book-1 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: [Pkg-ia32-libs-maintainers] Bug#563402: Any progress ?
Moritz Muehlenhoff j...@inutil.org writes: On Sun, Mar 07, 2010 at 10:28:12PM +0100, Sylvestre Ledru wrote: Le dimanche 07 mars 2010 à 19:30 +0100, Goswin von Brederlow a écrit : Sylvestre Ledru sylves...@debian.org writes: Is there any progress on this ? sun-java6 still not build: https://buildd.debian.org/fetch.cgi?pkg=sun-java6arch=ia64ver=6.18-2stamp=1265956947file=log Thanks Sylvestre Can you confirm that updating the link fixes the problem? Or are there more issues? I am testing with porterbox. I guess I need to have root permission to do it ... Was your test successful? Cheers, Moritz Ia32-libs-core, with the right link, is now in Debian. Unfortunately using that building sun-java6 segfaults. So there is more to test and debug. I just don't know enough about ia64 to say what is causing this. Might be ia32-libs-croe fault or not. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: Isn't this a security problem?
David Kalnischkies kalnischkies+deb...@gmail.com writes: 2010/6/12 Torsten Landschoff t.landsch...@gmx.net: I would consider this to be a critical issue as it could become a security problem. Let's assume an archive key is compromised. As an admin reading this on some information channel (irc, twitter, lwn.net, whatever) I would just remove the key as shown by Tollef. Only by reading this bug report I do know now that this plainly would not work. Instead apt-key will reenable this key given any chance. Not at any chance and for any key: It will do so only for the debian-archive-keyring AND only on update for the package apt and/or debian-archive-keyring. (with complete gpg import output in the log btw) If the debian-archive-keyring is ever compromised the attacker has the possibility to provide different apt/debian-archive-keyring packages anyway so you better not upgrade as long as the archive doesn't have a new key (which you have validated and installed manually) -- and in this event the debian-archive-keyring package will be one of the first packages updated in the archive (removing the old, installing the new key - just to be sure and for all the users which haven't done it manually ). Other keyring packages normally add themselves to the database on an install/upgrade of these packages automatically - if you don't want that what is the point of installing these keyring packages? So, does this bug still apply? Still applies as the fragments file infrastructure is not used so far. As said earlier i intend to promote that a bit after squeeze release to have a smoother transition (keyrings are normally without a problem backportable between different releases - breaking that feels a bit ugly.) The difference is not big through. Instead of calling apt-key or doing some manual gpg calling a package drops a file into /etc/apt/trusted.gpg.d/ The file is still binary so manual editing is not a good idea (TM) but at least someone who really wants to remove keys from a keyring file will get the benefits of dpkgs conffile handling - in terms of that he will notice that you have changed something, not so much that you can easily see what was changed But, and that is what should help in this regard a bit is, that most keyrings are actually just one key, so the action can be broken down to a removed config file instead This just need support by the maintainer of the keyring, so the debian-archive-keyring could e.g. be split into debian-lenny.gpg, debian-squeeze.gpg, debian-next-big-thing.gpg and so on. You might ask why binary? now, but APT internally uses gpgv for the validation which only understands binaries and not the ascii-amored stuff. (gpg is only used to import keyrings into the trusted keyring by the keyrings - if we switch to fragment files the gpg is no longer needed ) Best regards, David Kalnischkies That would complicate things when using deb [keyring=debian-lenny.gpg] http://ftp.debian.org/debian stable main The idea of specifying a specific keyring is so that one compromised key will not endanger all sources.list entries to attacks. But I guess having to change the keyring name from debian-lenny.gpg to debian-squeeze.gpg when upgrading to a new major release would be acceptable. Just don't have it change name at will or for point/security releases. There could also be a debian-stable.gpg - debian-lenny.gpg symlink. Since I'm quite opposed to non human readable conffiles: Why is the keyring a conffile? Why not have the packages keyring in /usr/lib/apt/trusted.gpg.d/ and user keyrings in /etc/apt/trusted.gpg.d/ or /usr/local/apt/trusted.gpg.d/? But I don't know how one would go about removing a key then. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583110: Fails to restore raid speed on error
Package: hdparm Version: 9.27-1 Severity: critical File: /etc/init.d/hdparm Hi, when a raid is reshaping or resyncing the hdparm boot script temporarily sets the speed to 0. But if the script then exits with an error, for example because /etc/hdparm.conf lists a device that is not present, the speed is not restored to its old value. That means that the raid devices never finish reshaping or resyncing, which brings the system in danger of data loss. In my case I have a SATA Port Multiplier, last one I ever buy :), and it seems that takes a while to work after a boot. Sometimes its disks just aren't there fast enough during boot and for example the fsck run fails. I'm guessing the hdparm script fails too and then the raid speed remains at 0. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages hdparm depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip hdparm recommends no packages. Versions of packages hdparm suggests: pn apmd none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583110: Fails to restore raid speed on error
Stephen Gran sg...@debian.org writes: This one time, at band camp, Goswin von Brederlow said: In my case I have a SATA Port Multiplier, last one I ever buy :), and it seems that takes a while to work after a boot. Sometimes its disks just aren't there fast enough during boot and for example the fsck run fails. I'm guessing the hdparm script fails too and then the raid speed remains at 0. s/fails/failed/ Instead of guessing, would it be possible for you to debug this? Cheers, Oh I did test it after boot by adding another entry that doesn't exist and starting the script again. It exits prematurely. I'm only guessing that, at the point the hdparm script did run during boot, the devices weren't yet discovered by the kernel. The last thing that happens is: + hdparm -S 120 /dev/sdl /dev/sdl: No such file or directory The problem seems to be in line 382 and the fix could be something like this: --- /etc/init.d/hdparm~ 2010-05-26 02:37:59.0 +0200 +++ /etc/init.d/hdparm 2010-05-26 02:46:12.0 +0200 @@ -15,7 +15,7 @@ @@ -379,9 +379,11 @@ ;; esac else - $KEY $SEP $VALUE + $KEY $SEP $VALUE || ret=$? NEXT_LINE=no-go WAS_RUN=1 + log_progress_msg $DISC + log_end_msg $ret || true fi done MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571255: Please fix this
Raphael Hertzog hert...@debian.org writes: On Thu, 13 May 2010, Goswin von Brederlow wrote: The only affect I see this will have is that an installed linux-image meta package will be updated. That might get a new kernel installed or not. If the minimal version is carefully chosen, it will ensure a new kernel is installed. That's the standard Debian way to have newer kernel auto-installed and upgraded so we should be able to rely on it for upgrades. No. If the linux-image meta package isn't installed then it won't be. Only if the user is using that way will it cause an update. The only thing Breaks prevents is an old meta package being installed. But how does that change anything for the system? It does not mean the new kernel will be used at all. It does not mean older kernel images will be removed. It does not change the kernel the system is currently running. It in no way means udev will actually work. Newer kernels are used by default in grub, sure the user can make a bad choice but we can't prevent everything. The current hack was no better in that regard. It just ensured that a newer kernel was being installed, it had no way to ensure that a good kernel is going to be used on next boot. Not saying it was. Just saying the Breaks will hardly help. The problem is udev being so screwed up. The only real solution would be to make udev work with multiple kernel versions. We could improve this further by having grub only display working kernels. Packages could communicate a minimal kernel version to grub, and grub could use that information in update-grub. Please don't remove any entries. Booting a not quite woring kernel might be the only way to recover from a bad kernel/udev update. But the entries with too old kernel could be marked in some way. Apart from that I like the idea. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571255: Please fix this
m...@linux.it (Marco d'Itri) writes: On May 12, David Kalnischkies kalnischkies+deb...@gmail.com wrote: Good that i am not a developer so i can say crap and ask afterwards for pointers to a documentation which tells me why udev can't e.g. Breaks: linux-image-686 ( x), linux-image-amd64 ( x), ? *Breaks* may work, dependencies are not acceptable. Are there any objections from anybody to trying this? The only affect I see this will have is that an installed linux-image meta package will be updated. That might get a new kernel installed or not. But how does that change anything for the system? It does not mean the new kernel will be used at all. It does not mean older kernel images will be removed. It does not change the kernel the system is currently running. It in no way means udev will actually work. As far as i understand i need for a successful boot udev and a kernel without that option enabled. This doesn't imply to me that i need to install it in Also for a working system. There have been enough changes that the old udev will not like the new configuration files and will probably not work much, so the system must be rebooted ASAP after upgrading kernel+udev. This really reminds me of the Windows world: You have moved your mouse. This change will only take affect after a reboot. Reboot now? When will you (meaning upstream) finally stabilize the udev api or allow for transitions? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: RFH: Bug#563402: ia32-libs broken on ia64
Torsten Werner twer...@debian.org writes: Hi, changing the link as described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563402#47 will certainly help and won't make anything worse. Is someone working on that? Cheers, Torsten Try http://mentors.debian.net/debian/pool/main/i/ia32-libs-core/ MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: [Pkg-ia32-libs-maintainers] Bug#563402: Any progress ?
Sylvestre Ledru sylves...@debian.org writes: Is there any progress on this ? sun-java6 still not build: https://buildd.debian.org/fetch.cgi?pkg=sun-java6arch=ia64ver=6.18-2stamp=1265956947file=log Thanks Sylvestre Can you confirm that updating the link fixes the problem? Or are there more issues? I hate to do a 500MB upload just to get another report that it still doesn't work. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570695: Fails with absolute symlinks
Package: makejail Version: 0.0.5-7 Severity: grave Hi, on amd64 the dynamic linker is /lib64/ld-linux-x86-64.so.2 but /lib64 is a symlink to /lib. When makejail looks for missing files it correctly detects that /lib64/ld-linux-x86-64.so.2 is missing. It then detects that /lib64 is a link to /lib and creates it. But then it claims /lib64/ld-linux-x86-64.so.2 is already installed in the chroot. I'm assuming it stats $chroot/lib64/ld-linux-x86-64.so.2 and finds the systems /lib/ld-linux-x86-64.so.2. In any case the ld.so is not copied into the chroot making it complelty unusable. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (499, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages makejail depends on: ii binstats 1.08-8 Statistics tool for installed prog ii psmisc22.10-1utilities that use the proc file s ii python2.5.4-9An interactive high-level object-o ii strace4.5.19-1 A system call tracer makejail recommends no packages. makejail suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566671: Fails to purge
Package: ogre-plugins-cgprogrammanager Version: 1.6.1-1 Severity: serious m...@frosties:~% sudo dpkg --purge ogre-plugins-cgprogrammanager (Reading database ... 142115 files and directories currently installed.) Removing ogre-plugins-cgprogrammanager ... /var/lib/dpkg/info/ogre-plugins-cgprogrammanager.postrm: line 3: update-ogre-plugins: command not found dpkg: error processing ogre-plugins-cgprogrammanager (--purge): subprocess installed post-removal script returned error exit status 127 Errors were encountered while processing: ogre-plugins-cgprogrammanager -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ogre-plugins-cgprogrammanager depends on: ii libc6 2.10.1-2 GNU C Library: Shared libraries pn libfreeimage3 none(no description available) ii libgcc11:4.4.1-1 GCC support library pn libogremain-1.6.1 none(no description available) ii libstdc++6 4.4.1-1 The GNU Standard C++ Library v3 ii nvidia-cg-toolkit 2.2.0006~ogredev1 NVIDIA Cg Toolkit Installer ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime ogre-plugins-cgprogrammanager recommends no packages. ogre-plugins-cgprogrammanager suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566683: trying to overwrite '/etc/bash_completion.d/xm', which is also in package xen-tools 0:4.1-1
Package: bash-completion, xen-tools Version: 1:1.0-3 Severity: serious Either bash-completion or xen-tools is missing a Replaces and then other should drop the file. (Reading database ... 142148 files and directories currently installed.) Preparing to replace bash-completion 1:1.0-3 (using .../bash-completion_1%3a1.1-3_all.deb) ... Unpacking replacement bash-completion ... dpkg: error processing /var/cache/apt/archives/bash-completion_1%3a1.1-3_all.deb (--unpack): trying to overwrite '/etc/bash_completion.d/xm', which is also in package xen-tools 0:4.1-1 dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/bash-completion_1%3a1.1-3_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages bash-completion depends on: ii bash 4.1-1 The GNU Bourne Again SHell bash-completion recommends no packages. bash-completion suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566683: trying to overwrite '/etc/bash_completion.d/xm', which is also in package xen-tools 0:4.1-1
Jan Wagner w...@cyconet.org writes: Hi Goswin, On Sunday 24 January 2010, Goswin von Brederlow wrote: Either bash-completion or xen-tools is missing a Replaces and then other should drop the file. maybe you have noticed, that xen-tools was removed from testing and sid and even the bug was also reported, before it was marked fixed with the removal? With kind regards, Jan. I didn't notice that and it will not make xen-tools disapear from users system. Updating from stable, which does have xen-tools, will run into the file conflict. So you still need the Replaces even if squeeze does no longer has xen-tools. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: RFH: Bug#563402: ia32-libs broken on ia64
Hi, lacking any access to ia64 I'm wondering if any porter can help with Bug#563402. Is there actualy something wrong in ia32-libs (and then what) or is merulo[1] just not capable of running 32bit x86 binaries? MfG Goswin -- [1] https://db.debian.org/machines.cgi?host=3Dmerulo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: RFH: Bug#563402: ia32-libs broken on ia64
dann frazier da...@dannf.org writes: On Thu, Jan 21, 2010 at 06:30:14PM +0100, Goswin von Brederlow wrote: Hi, lacking any access to ia64 I'm wondering if any porter can help with Bug#563402. Is there actualy something wrong in ia32-libs (and then what) or is merulo[1] just not capable of running 32bit x86 binaries? It should have x86 support in hardware - but, something is certainly wrong. da...@krebs:~$ file /tmp/hello /tmp/hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped da...@krebs:~$ dpkg -l ia32-libs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii ia32-libs 20090808 ia32 shared libraries for use on amd64 and ia64 systems da...@krebs:~$ /tmp/hello -bash: /tmp/hello: No such file or directory da...@krebs:~$ LD_LIBRARY_PATH=/lib32 /lib32/ld-2.9.so /tmp/hello Hello, world! -- dann frazier Oh, I see what the problem is (after unpacking the deb instead of looking just at the file list): lrwxrwxrwx 1 mrvn mrvn 18 Jan 21 20:20 lib/ld-linux.so.2 - /lib32/ld-2.3.2.so -rwxr-xr-x 1 mrvn mrvn 115K Jul 27 21:09 lib32/ld-2.9.so* lrwxrwxrwx 1 mrvn mrvn9 Jan 21 20:20 lib32/ld-linux.so.2 - ld-2.9.so* Been a long time since that link was updated. That should be lrwxrwxrwx 1 root root 20 Oct 29 09:53 lib/ld-linux.so.2 - /lib32/ld-linux.so.2* like the libc6-i386 has on amd64 so it works for in libc6 version. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: [Pkg-ia32-libs-maintainers] Bug#563402: ia32-libs broken on ia64
Giuseppe Iuculano iucul...@debian.org writes: Il 16/01/2010 11:08, Goswin von Brederlow ha scritto: That usualy means one of the libraries can not be found. What does ldd i586-jdk/bin/unpack200 $ ldd i586-jdk/bin/unpack200 not a dynamic executable Cheers, Giuseppe. That is a bit odd. I do see /lib/ld-linux.so.2 and /usr/bin/ldd in ia32-libs:ia64 so that should work. What kind of ia64 CPU do you have? Is it old enough to still have the i386 emulation hardware? Newer ia64 afaik don't have that anymore and can't execute i386 code. Maybe your hardware just doesn't support it. If unsure maybe check previous versions of ia32-libs if any of them work. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: IA-32 Execution Layer
Package: ia32-libs Severity: normal Maybe this should be added to the docs: http://www.intel.com/cd/software/products/asmo-na/eng/219773.htm MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable-i386 APT policy: (1001, 'unstable-i386'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ia32-libs depends on: ii dpkg 1.15.4.1 Debian package management system ii lib32asound2 1.0.20-3 shared library for ALSA applicatio ii lib32gcc1 1:4.4.1-1 GCC support library (32 bit Versio ii lib32ncurses5 5.7+20090803-1shared libraries for terminal hand ii lib32stdc++6 4.4.1-1 The GNU Standard C++ Library v3 (3 ii lib32z11:1.2.3.3.dfsg-15 compression library - 32 bit runti ii libc6-i386 2.10.1-2 GNU C Library: 32-bit shared libra ii lsb-release3.2-23Linux Standard Base version report ia32-libs recommends no packages. Versions of packages ia32-libs suggests: pn ia32-libs-gtk none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563402: [Pkg-ia32-libs-maintainers] Bug#563402: ia32-libs broken on ia64
Giuseppe Iuculano iucul...@debian.org writes: Package: ia32-libs Version: 20090808 Severity: serious Hi, it seems ia32-libs is broken on ia64: $ file i586-jdk/bin/unpack200 i586-jdk/bin/unpack200: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped $ i586-jdk/bin/unpack200 -bash: i586-jdk/bin/unpack200: No such file or directory This cause a build failure of sun-java6 on ia64 Cheers, Giuseppe. That usualy means one of the libraries can not be found. What does ldd i586-jdk/bin/unpack200 say? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551620: DOS on the LAN when starting kvm with 2 network devices and bridging
Jan Luebbe jlue...@lasnet.de writes: Hi! On Mon, 2009-10-19 at 16:23 +0200, Goswin von Brederlow wrote: sudo kvm -m 256 -drive file=/scratch/ramdisk/build/build/hda.img,if=ide,boot=on -drive file=/scratch/ramdisk/build/build/hdb.img,if=ide,boot=off -net nic,model=e1000,macaddr=54:52:00:00:42:12 -net tap -net nic,model=e1000,macaddr=54:52:00:00:42:13 -net tap -smp 1 -kernel /scratch/ramdisk/build/build/chroot-amd64/boot/vmlinuz-2.6.27.34-1-ql-beowulf -append root=/dev/ram0 rw ramdisk_size=97872 console=ttyS0,115200 quiet --initrd /scratch/ramdisk/build/build/image-beobox-amd64-7.0.0-0.gz -nographic and the /etc/kvm/kvm-ifup script adds both devices to a bridge: The is an effect of how qemu's internal networking is designed. You defined 2 nics and *2 tap devices* on the same qemu-internal vlan. Bridging these devices together creates a loop. If you just want two devices in the same physical lan use '-net tap' only once. This will connect the two nics to the same tap device. You only need explicit vlans if you want to connect them to different bridges on the host. I don't think this is RC, maybe qemu should warn if more than one tap device is used on the same internal vlan. Jan Definetly warn if not automatically put them in different vlans by default. This behaviour is totaly unexpected. I created 2 tap devices for a reason and kvm just merged them again. They were intended for different bridges but the default kvm-ifup script put them into the same bridge. I can't think of any use case of having 2 tap devices in the same vlan so the default should be changed to something less dangerous. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551620:
Hi, setting VLAN=xx to different values for each interfaces solves this problem. By default interfaces seem to be put into the same VLAN and that creates a loop with the bridge. The default should put each interface in a different VLAN. I can't even think of a use case where devices should be in the same VLAN, that seems a totaly useless and harmfull feature. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551620: DOS on the LAN when starting kvm with 2 network devices and bridging
Package: kvm Version: 85+dfsg-4 Severity: critical Hi, I'm starting kvm with 2 network interfaces like this: sudo kvm -m 256 -drive file=/scratch/ramdisk/build/build/hda.img,if=ide,boot=on -drive file=/scratch/ramdisk/build/build/hdb.img,if=ide,boot=off -net nic,model=e1000,macaddr=54:52:00:00:42:12 -net tap -net nic,model=e1000,macaddr=54:52:00:00:42:13 -net tap -smp 1 -kernel /scratch/ramdisk/build/build/chroot-amd64/boot/vmlinuz-2.6.27.34-1-ql-beowulf -append root=/dev/ram0 rw ramdisk_size=97872 console=ttyS0,115200 quiet --initrd /scratch/ramdisk/build/build/image-beobox-amd64-7.0.0-0.gz -nographic and the /etc/kvm/kvm-ifup script adds both devices to a bridge: -- cat /etc/kvm/kvm-ifup #!/bin/sh # NOTE: For this script to operate properly, it is expected that # you have a br0 BRIDGE=br0 /sbin/ifconfig $1 0.0.0.0 up /usr/sbin/brctl addif $BRIDGE $1 -- The strange thing now is that somehow creates a network loop causing a DOS attack on the local network within seconds. In tcpdump I saw a DHCP Reply to 255.255.255.255 over and over and over again but I guess any broadcast will do. This causes 90% package loss making the local network completly unusable. Michael Tokarev (mjt on #debian-devel) could reproduce the problem. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540719: [Pkg-ia32-libs-maintainers] Bug#540719: failed to install/upgrade: trying to overwrite `/usr/lib32/libcrypto.so.0.9.8', which is also in package lib32ssl0.9.8
not-found 540719 18 found 540719 20090808 stop martvefun martin.trig...@gmail.com writes: Preparing to replace ia32-libs 18 (using .../ia32-libs_20090808_amd64.deb) ... Unpacking replacement ia32-libs ... dpkg: error processing /var/cache/apt/archives/ia32-libs_20090808_amd64.deb (--unpack): trying to overwrite `/usr/lib32/i686/cmov/libcrypto.so.0.9.8', which is also in package lib32ssl0.9.8 dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/ia32-libs_20090808_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) dpkg -i lib32ssl0.9.8 apt-cache policy lib32ssl0.9.8 Where did you get lib32ssl0.9.8 from? That is not part of Debian nor does it come from ia32-apt-get (which only has ia32-libssl0.9.8). MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540199: Copyright file incomplete
Package: ia32-libs Version: 20090804 Severity: serious Hi, http://packages.debian.org/changelogs/pool/main/i/ia32-libs/ia32-libs_20090804/ia32-libs.copyright shows you are still missing a lot of copyright info from included packages. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.4-frosties-2 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ia32-libs depends on: ii ia32-free 2.4.0-6.1~20 OpenGL Utility Toolkit ii ia32-less 1:0.95.0-2.3~20OSF/Motif 2.1 implementation relea ii ia32-liba 2.2.47-2~20Access control list shared library ii ia32-liba 0.3.107-6~20 Linux kernel AIO access library - ii ia32-liba 1.5.9-3~20 aRts sound system C support librar ii ia32-liba 0.3-1~20 Asyncronous name service query lib ii ia32-liba 1:2.4.43-3~20 Extended attribute shared library ii ia32-liba 1.9.2-1~20 Network Audio System - shared libr ii ia32-liba 0.2.6-7~20 Open-source version of SGI's audio ii ia32-libc 1.8.8-2~20 The Cairo 2D vector graphics libra ii ia32-libc 1:2.16-5~20support for getting/setting POSIX. ii ia32-libc 1:3.9.20060704-3.6~20 libraries for CAPI support ii ia32-libc 1.41.7-1~20common error description library ii ia32-libc 1.3.10-5~20Common UNIX Printing System(tm) - ii ia32-libd 1.2.14-3~20simple interprocess messaging syst ii ia32-libd 1.2.7-2~20 direct frame buffer graphics - sha ii ia32-libd 2.4.11-1~20Userspace interface to kernel DRM ii ia32-libe 0.2.41-5~20Enlightened Sound Daemon - Shared ii ia32-libe 0.6.17-1~20library to parse EXIF files ii ia32-libe 2.0.1-4~20 XML parsing C library - runtime li ii ia32-libf 1.1.9-6~20 Fast Light Toolkit - shared librar ii ia32-libf 2.6.0-4~20 generic font configuration library ii ia32-libf 2.3.9-5~20 FreeType 2 font engine, shared lib ii ia32-libg 1.4.4-2~20 LGPL Crypto library - runtime libr ii ia32-libg 7.4.4-1~20 A free implementation of the OpenG ii ia32-libg 7.4.4-1~20 A free implementation of the OpenG ii ia32-libg 7.4.4-1~20 The OpenGL utility library (GLU) ii ia32-libg 2.6.6-1~20 the GNU TLS library - runtime libr ii ia32-libg 1.6-1~20 library for common error values an ii ia32-libg 2.4.6-1~20 gphoto2 digital camera library ii ia32-libg 2.4.6-1~20 gphoto2 digital camera port librar ii ia32-libh 0.5.12~git20090406.46dc48-2~20 Hardware Abstraction Layer - share ii ia32-libi 2:1.0.5-1~20 X11 Inter-Client Exchange library ii ia32-libi 0.2.11-5~20cross-platform library for paralle ii ia32-libj 0.116.1-4~20 JACK Audio Connection Kit (librari ii ia32-libj 6b-14~20 The Independent JPEG Group's JPEG ii ia32-libk 1.2-10~20 Linux Key Management Utilities (li ii ia32-libl 1.18.dfsg-1~20 Color management library ii ia32-libl 2.4.15-1.1~20 OpenLDAP libraries ii ia32-libl 2.2.6a-4~20A system independent dlopen wrappe ii ia32-libl 2.03-1~20 data compression library ii ia32-libp 1.0.1-9~20 Pluggable Authentication Modules l ii ia32-libp 1.2.37-1~20PNG library - runtime ii ia32-libp 1.14-4~20 lib for parsing cmdline parameters ii ia32-libp 0.9.15-4~20PulseAudio client libraries ii ia32-libs 1.0.20-5~20API library for scanners ii ia32-libs 2.1.23.dfsg1-1~20 Cyrus SASL - authentication abstra ii ia32-libs 1.2.13-4+b1~20 Simple DirectMedia Layer (with X11 ii ia32-libs 2.0.82-1~20SELinux shared libraries ii ia32-libs 2.0.18-2~20type-safe Signal Framework for C++ ii ia32-libs 2:1.1.0-2~20 X11 Session Management library ii ia32-libs 0.9.8k-3~20SSL shared libraries ii ia32-libs 1:3.3.6-18~20 The GNU Standard C++ Library v3 ii ia32-libs 1:1.4.3-27~20 console SVGA display libraries ii ia32-libt 2.2-1~20 Manage ASN.1 structures (runtime) ii ia32-libt 3.8.2-12~20Tag Image File Format (TIFF) libra ii ia32-libu 2:0.1.12-13~20 userspace
Bug#540028: lib32gcc1_4.4.1-1+ia32.libs.20090804_ia64.deb will confuse debbugs and possibly DAK
Package: ia32-libs Version: 20090804 Severity: grave Hi, you are uploading a package with the same name as build by another source (gcc). Now debbugs and possibly DAK will be confused as to which source lib32gcc1 belongs too. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (499, 'unstable'), (2, 'experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-xen-1 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ia32-libs depends on: ii dpkg 1.15.3Debian package management system ii lib32asound2 1.0.20-3 shared library for ALSA applicatio ii lib32gcc1 1:4.4.0-10GCC support library (32 bit Versio ii lib32ncurses5 5.7+20090523-1.1 shared libraries for terminal hand ii lib32stdc++6 4.4.0-10 The GNU Standard C++ Library v3 (3 ii lib32z11:1.2.3.3.dfsg-14 compression library - 32 bit runti ii libc6-i386 2.9-18GNU C Library: 32-bit shared libra ii lsb-release3.2-22Linux Standard Base version report ia32-libs recommends no packages. Versions of packages ia32-libs suggests: pn ia32-libs-gtk none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536517: [Pkg-ia32-libs-maintainers] Bug#536517: ia32-libs-gtk: ia32-libs not installable
Michal Suchanek hramr...@centrum.cz writes: 2009/7/19 Goswin von Brederlow goswin-...@web.de: Michal Suchanek hramr...@centrum.cz writes: 2009/7/10 Goswin von Brederlow goswin-...@web.de: Michal Suchanek hramr...@centrum.cz writes: Package: ia32-libs-gtk Version: 21 Severity: grave ia32-apt-get conflicts with ia32-libs but ia32-libs depends on it. Because ia32-libs is pending removal/replacement and will be incompatible with ia32-apt-get. How do you install stuff that depends on ia32-libs or ia32-libs-gtk then? Thanks Michal You don't. You install the respective i386 deb instead that depends on the right 32bit libraries. That won't satisfy the dependencies of packages that depend on ia32-libs or ia32-libs-gtk. Michal Instead of the foo_amd64.deb that depends on ia32-libs you install the foo_i386.deb. Those won't have a dependency on ia32-libs. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535218: apt-get / aptitude segfault when Cache-Limit is too small
Hans-J. Ullrich hans.ullr...@loop.de writes: Workaround Just enter this into /etc/apt/apt.conf.d/20archive: APT::Cache-Limit 1; Worked well for me. Otherwise: You are right, there is NO apt.conf any more! Good luck! Hans That is no solution. libapt should never ever ever ever segfault. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535218: #535218 apt-get / aptitude segfault when Cache-Limit is too small
Drew Parsons dpars...@debian.org writes: Package: apt Version: 0.7.21 Severity: normal I'm suffering from the cache-limit error too after the upgrade to ia32-apt-get v20 (which has set up a diversion for /usr/bin/apt-get). I get, $ sudo apt-get update Updating for amd64... Hit http://mirror.linux.org.au unstable Release.gpg ... Ignoring mirror.linux.org.au_debian_dists_unstable_non-free_source_Sources.IndexDiff Updating for i386... Get:1 file: transitional Release.gpg [315B] Ign file: transitional/main Translation-en_AU Get:2 file: transitional Release [431B] Hit http://mirror.linux.org.au unstable Release.gpg ... Hit http://mirror.linux.org.au unstable/non-free Packages/DiffIndex Reading package lists... Done Ignoring mirror.linux.org.au_debian_dists_unstable_contrib_binary-i386_Packages.IndexDiff Ignoring mirror.linux.org.au_debian_dists_unstable_main_binary-i386_Packages.IndexDiff Ignoring mirror.linux.org.au_debian_dists_unstable_non-free_binary-i386_Packages.IndexDiff Merging ... Reading package lists... Error! E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Limit. Current value: 25165824. (man 5 apt.conf) E: Error occurred while processing warsow-server (NewVersion1) E: Problem with MergeList /var/lib/apt/lists/mirror.linux.org.au_debian_dists_unstable-i386_contrib_binary-amd64_Packages E: The package lists or status file could not be parsed or opened. $ echo $? 100 I have not set APT::Cache-Limit anywhere. It's not mentioned in any of the files in /etc/apt/apt.conf.d/. /etc/apt/apt.conf.d/00ia32-libs-tools does not define APT::Cache-Limit, it only has references to /usr/lib/ia32-libs-tools/mangle 25165824 is the default value if it isn't set anywhere and usualy is enough to handle for example unstable. But when you include multiple releases or other apt repositories in your sources.list you quickly hit that limit. Many people have therefore already configured a higher setting somewhere. Now, consider what happens if the user has set a limit and ia32-libs-tools would also set one. Which one would apt take now? What if it still isn't enough? I think that would do more harm then good in the long run. But apt should increases its default size so most people can stick with that even with ia32-apt-get installed. MfG Goswin PS: You are lucky though. Other people just get a segfault instead of the message to increase the limit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535486: [Pkg-ia32-libs-maintainers] Bug#535486: ia32-libs breaks multiarch buildd and adds useless dependency
Patrick Matthäi pmatth...@debian.org writes: Package: ia32-libs Version: 2.7 Severity: grave Justification: renders package unusable Hello, while trying to build fglrx on amd64 again (it needs ia32-libs on amd64) it still fails. 1) There is still a dependency on ia32-apt-get, which replaces dpkg-deb etc with it is own version, this isn't realy nice for a buildd, also for users who just needs some packages, I recommend to downgrade this dependency to suggest. What exactly did you need from ia32-libs? You build-depend on (only libs): libx11-6, libxext6, libgl1-mesa-glx, libxrandr2, libice6, libsm6, libfontconfig1, libxi6, libxcursor1, libxinerama-dev That looks a bit odd to me. I see the source just unpacks the binaries so I guess you need the libs for the shlibs files. But then why libxinerama-dev? Which of those do you actually need in 32bit to build? From looking at the package I see that there is fglrx-glx and fglrx-glx-ia32: Package: fglrx-glx Depends: libc6 (= 2.2.5), libxext6, fglrx-driver (= 1:9-5-1) Package: fglrx-glx-ia32 Depends: ia32-libs (= 2.4), lib32gcc1 (= 1:4.1.1), libc6-i386 (= 2.2), fglrx-driver (= 1:9-5-1) With ia32-apt-get this becomes: PackagePackage: fglrx-glx-ia32 Depends: ia32-libx11-6, ia32-libxext6, lib32gcc1 (= 1:4.1.1), fglrx-driver (= 1:9-6-2) So I guess it is only those 2 libraries you need. Do me one favour and try this with ia32-apt-get installed: WARNING: screws with the diversions! echo 'fglrx-glx +' /etc/ia32-libs-tools/rename.list apt-get update apt-get remove fglrx-glx-ia32 dpkg-divert --package ia32-fglrx-glx --divert /usr/lib32/fglrx/diversions/libGL.so.1.2 --rename /usr/lib32/libGL.so.1.2 dpkg-divert --package ia32-fglrx-glx --divert /usr/lib32/fglrx/diversions/libGL.so.1 --rename /usr/lib32/libGL.so.1 apt-get install ia32-fglrx-glx Does 32bit GL work with that? How do you feel about not building fglrx-glx-ia32 on amd64 and recommending ia32-fglrx-glx instead? It would need a little patch to the preinst and postrm for the diversion handling. Something like: if [ $(dpkg --print-architecture) = i386 ]; then LIBDIR=/usr/lib PKG=fglrx-glx else LIBDIR=/usr/lib32 PKG=ia32-fglrx-glx fi dpkg-divert --package $PKG --divert $LIBDIR/fglrx/diversions/libGL.so.1.2 --rename $LIBDIR/libGL.so.1.2 but only in the i386 deb. Alternatively, not sure yet if that is the right way to go, add a preinst.amd64 and postrm.amd64 (same for ia64?) file to DEBIAN/control. ia32-apt-get would then substitude that file when unpacking the maintainer scripts on amd64. Or as thrid option I (or fglrx-glx) could include a hook for ia32-apt-get to rewrite the preinst/postrm scripts on the fly while unpacking. 2) While ia32-apt-get is installed and replaces parts of the system it also wants to have more entropy on building keys in pbuilder, which needs user interaction - that is a no go for a automagic build. It just needs a source for random bits. Without the user as source it might take longer but buildds must have other sources too. Otherwise things like ssh or https wouldn't work. Cheers. MfG Goswin PS: fglrx-glx-ia32 needs to Pre-Depends: libc6 (= 2.9-18) if you keep it PPS: ia32-libs has not worked right for buildds making it neccessary to split out libc6-i386, lib32z1, lib32bz1, lib32asound, lib32ncurses5, lib32readline5. That Build-Depends was never quite right. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535190: Closing 535190
Hi, as it seems to have been a typo error in the config I'm closing this bug. The part about apt-get segfaulting is cloned and reassigned to apt so that part remains open. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535434: [Pkg-ia32-libs-maintainers] Bug#535434: ia32-apt-get freezes system when aptitude update is run when 'None' mode is selected
Edward Guldemond edward.guldem...@gmail.com writes: This also applies to the apt-get wrapper. In 'None' mode, it does not append the .real suffix either. The fix is similar, so I've not included a patch for it. They are the same source file. Fixed in svn. I could have sworn I did test that but I don't see how I could. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535190: [Pkg-ia32-libs-maintainers] Bug#535190: ia32-libs: Dynamic MMap ran out of room
Sebastian Luque splu...@gmail.com writes: Package: ia32-libs Version: 18 Severity: serious Installing ia32-libs seems to have broken apt functionality in the system reported here. 'apt-get update' checks for my sources as usual, but after the Reading package lists... Done message, it displays large number of lines starting with arch_all.list: deleting SOME_PACKAGE or arch_all.list: deleting SOME_PACKAGE, and finally ends with: Merging ... Reading package lists... Error! E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Limit. Current value: 25165824. (man 5 apt.conf) E: Error occurred while processing disc-cover (NewVersion1) E: Problem with MergeList /var/lib/apt/lists/ftp.ca.debian.org_debian_dists_sid-i386_main_binary-amd64_Packages E: The package lists or status file could not be parsed or opened. The error remains, no matter how large I set the cache-limit in /etc/apt/apt.conf. I cannot even remove the package, as the same error occurs immediately after 'apt-get remove ia32-libs'. I can send additional information, if requested. Thanks. Seb Are you sure you don't have a typo in /etc/apt/apt.conf? Does the value reported in the error go up as you increase it? Because the value reported above is exactly the default value, as if you hadn't increased it at all. The correct syntax is APT::Cache-Limit 50331648; If you want to remove it try dpkg --force-depends --purge ia32-apt-get apt-get update apt-get -f install After that you should probably go back to testing and reinstall ia32-libs and whatever else it needs to remove. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535190: [Pkg-ia32-libs-maintainers] Bug#535190: ia32-apt-get: If no APT::Cache-Limit is set, apt-get.real segfaults.
clone 535190 -1 reassign -1 apt retitle -1 apt-get / aptitude segfault when Cache-Limit is too small thanks Jan-Hendrik Palic pa...@billgotchy.de writes: Package: ia32-apt-get Version: 17 Severity: normal Hi, installing ia32-apt-get and run apt-get update leads to Reading package lists... Done Ignoring ftp.fi.debian.org_debian_dists_sid_contrib_binary-i386_Packages.IndexDiff Ignoring ftp.fi.debian.org_debian_dists_sid_main_binary-i386_Packages.IndexDiff Ignoring ftp.fi.debian.org_debian_dists_sid_non-free_binary-i386_Packages.IndexDiff Ignoring www.debian-multimedia.org_dists_sid_main_binary-i386_Packages.IndexDiff Ignoring www.debian-multimedia.org_dists_sid_main_i18n_Translation-en%5fUS Merging ... /usr/bin/apt-get: line 46: 712 Segmentation fault apt-get.real --no-list-cleanup --no-download update After setting APT::Cache-Limit 33554432; into /etc/apt/apt.conf.d/00ia32-libs-tools, apt-get update works again. Regards, Jan You are the 3rd person now that has run into this problem. There seems to be some bug in libapt that causes a buffer oveflow in the cache and a segfault instead of a message that the Cache-Limit needs to be increased. At least that is what I guess. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534965: [Pkg-ia32-libs-maintainers] Bug#534965: ia32-apt-get: is completely broken
Norbert Preining prein...@logic.at writes: # unmerging because it is a completely different issue than the one in # the above bug unmerge 534965 # could have set severity to grave again, now aptitude SIGSEGVs thanks On Mo, 29 Jun 2009, Goswin von Brederlow wrote: - aptitude UI with upgrading does not work, redownloads everything again and again I know update does not work in aptitude. I wasn't aware of other breakage. Can you provide some sort of log? This is a duplicate of 533746, merging. No log now, because now after calling /usr/share/ia32-apt-get/convert-all-sources.list I even get: mithrandir:~# aptitude Ouch! Got SIGSEGV, dying.. Segmentation fault mithrandir:~# Simple gdb-ing gave me: Program received signal SIGSEFC, Segmentation fault. [Switching to Thread =x7fcf06fe7710 (LWP 8165)] 0x7fcf06b60455 in DynamicMMap::WriteString () from /usr/lib/libapt-pkg-libc6.9-6.so.4.7 It is getting worse. That will be the same issue apt-get has. They both use libapt after all. As mentioned in NEWS and as of version 19 also in README.Debian for the time being you need to run /usr/share/ia32-apt-get/convert-all-sources.list when you change your sources.list. Yes but since that packages is *pulled*in* automatically how should anyone know about it??? I wasn't even aware that there is some magic going on. Ideally you shouldn't be aware of it at all. On install the sources.list are converted automatically once and the plan is to automatically update the converted list when needed. I just haven't had time to write the code for that yet. - calling apt-get update from the command line (recommended in another bug report) finishes in a core dump /usr/bin/apt-get: line 46: 30757 Segmentation fault apt-get.real --no-list-cleanup --no-download update One other user managed to produce that on irc today. I can't reproduce it and the user purged and reinstalled ia32-apt-get, thereby solving the problem for some reason, before I could ask him to send a tar of: /etc/apt /var/lib/apt /var/cache/apt (without archives/) 70M, I will try to upload from the slow link I have here. Should I put them on a web space or send by email to your personally?. Webspace is probably best. Not sure how soon such a large mail would get killed in my mail chain. But I highly doubt it would survive. Once you have a tar of them try if rm /var/cache/apt/*.bin /var/cache/apt/*/*.bin solves the problem. I don't know what causes this but something is triggering a bug in the real apt-get. Best guess apt-get manages to break its *.bin cache files. Maybe when it complains about the APT::Cache-Limit being too small. Did you have to increase APT::Cache-Limit just before you got the Segmentation fault? No, I didn't change anything in the cache or apt at all. Odd. I have sid and experimental in my sources.list and run out of space with the default size. Maybe it is experimental that pushes apt over the top. Best wishes Norbert MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535035: [Pkg-ia32-libs-maintainers] Bug#535035: ia32-apt-get tries to overwrite /usr/bin/apt-get
Iacopo Spalletti segnalazi...@nephila.it writes: Package: ia32-apt-get Version: 18 Severity: grave Justification: renders package unusable I cannot install ia32-apt-get due to the following error Preparing to replace ia32-apt-get 18 (using .../ia32-apt-get_18_all.deb) ... Unpacking replacement ia32-apt-get ... dpkg: error processing /var/cache/apt/archives/ia32-apt-get_18_all.deb (--unpack): trying to overwrite `/usr/bin/apt-get', which is also in package apt Errors were encountered while processing: /var/cache/apt/archives/ia32-apt-get_18_all.deb Fixed in 19. Diversions are created even on update if missing. Package cannot be removed because prerm tries to cancel diversions that don't exist Removing ia32-apt-get ... No diversion `diversion of /usr/bin/apt-get to /usr/bin/apt-get.real by ia32-apt-get', none removed No diversion `diversion of /usr/bin/dpkg-deb to /usr/bin/dpkg-deb.real by ia32-apt-get', none removed rm: cannot remove `/usr/share/ia32-apt-get/dists/transitional/Release.gpg': No such file or directory dpkg: error processing ia32-apt-get (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: ia32-apt-get Also fixed in 19. The attempt to remove the diversions actualy is not the problem. The rm is. If you touch /usr/share/ia32-apt-get/dists/transitional/Release.gpg you should be able to purge ia32-apt-get and then reinstall. As a matter of interest why did you cancel the initial install of ia32-apt-get half way through? This only happens when you stop it at a bad place. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534965: [Pkg-ia32-libs-maintainers] Bug#534965: ia32-apt-get: is completely broken
Norbert Preining prein...@logic.at writes: merge 534965 533746 thanks merging again, No log now, because now after calling /usr/share/ia32-apt-get/convert-all-sources.list I even get: mithrandir:~# aptitude Ouch! Got SIGSEGV, dying.. Segmentation fault mithrandir:~# lifting the Cache-Size fixed that. Best wishes Norbert Good to know. But that certainly should not end in a SIGSEGV. It indicates that the size check for the cache somehow does not detect an overflow. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534965: [Pkg-ia32-libs-maintainers] Bug#534965: ia32-apt-get: is completely broken
Norbert Preining prein...@logic.at writes: On Mo, 29 Jun 2009, Goswin von Brederlow wrote: That will be the same issue apt-get has. They both use libapt after all. ok. /etc/apt /var/lib/apt /var/cache/apt (without archives/) 70M, I will try to upload from the slow link I have here. Should I put them on a web space or send by email to your personally?. Webspace is probably best. Not sure how soon such a large mail would get killed in my mail chain. But I highly doubt it would survive. Is it needed in the light of the fact that increasing the cache size did fix the segv? Best wishes Norbert I would still like to find the bug in libapt that causes the segfault. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535081: [Pkg-ia32-libs-maintainers] Bug#535081: apt-get does not complete transition, and returns error 100
David david.mailli...@gmail.com writes: Package: ia32-apt-get Version: 18 Severity: grave No matter the number of times I run apt-get update, I always get (I copy the end of the output): [...] arch_all.list: adding makedev all arch_all.list: deleting openafs-modules-source amd64 arch_all.list: deleting samba-common amd64 arch_all.list: adding totem all arch_all.list: deleting totem-gstreamer amd64 arch_all.list: adding totem-mozilla all arch_all.list: deleting totem-xine amd64 Ignoring ftp.uk.debian.org_debian_dists_unstable_main_binary-i386_Packages.IndexDiff Ignoring ftp.uk.debian.org_debian_dists_unstable_non-free_binary-i386_Packages.IndexDiff Ignoring www.debian-multimedia.org_dists_experimental_main_i18n_Translation-en%5fGB Ignoring www.debian-multimedia.org_dists_unstable_main_binary-i386_Packages.ed Ignoring www.debian-multimedia.org_dists_unstable_main_binary-i386_Packages.IndexDiff Ignoring www.debian-multimedia.org_dists_unstable_main_i18n_Translation-en%5fGB Merging ... Reading package lists... Done Warning: apt-get returned error 100 This means one of the sub apt-gets returned error 100. Usualy one of the index files failed to download or the signature check. The error will be earlier then what you pasted. The Ignoring part just means that there where no changes to download, not that apt-get is actually ignoring that file. As a result, among other problems, I am missing any updates in 386-related packages. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492978: [Pkg-ia32-libs-maintainers] Bug#492978: ia32-apt-get upgrade dropped lines from source.list
Lionel Elie Mamane lio...@mamane.lu writes: Package: ia32-apt-get Version: 18 Severity: normal Not sure if it is the same bug, but for me it *dropped* a line and added lines that were not there. My source.list was (taken from a backup in the night): lion...@hair-dryer:~/O/etc/apt$ cat sources.list deb http://ftp.nl.debian.org/debian/ squeeze main contrib non-free deb http://ftp.nl.debian.org/debian/ sid main contrib non-free deb-src http://ftp.nl.debian.org/debian/ sid main contrib non-free deb http://security.eu.debian.org/ squeeze/updates main contrib non-free deb-src http://security.eu.debian.org/ squeeze/updates main contrib non-free ### ia32-apt-get entries ### #deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny-i386 main #deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid-i386 main #deb http://security.eu.debian.org/ lenny/updates-i386 main lion...@hair-dryer:~/O/etc/apt$ find native/ foreign/ -type f | while read f; do echo ; echo $f; echo --; cat $f; done native/sources.list -- deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid main deb-src http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main deb http://security.eu.debian.org/ lenny/updates main deb-src http://security.eu.debian.org/ lenny/updates main foreign/sources.list -- deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid main deb-src http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main deb http://security.eu.debian.org/ lenny/updates main deb-src http://security.eu.debian.org/ lenny/updates main I have no idea where these native and foreign files come from, I just edited sources.list, removed all ia32-apt-get lines (they were giving me too much trouble and grey hair) and switched to squeeze when lenny became stable. That comes from the ia32-apt-get prior to version 15, which was in violation of policy by modifying the sources.list directly. Version 15 introduced a new way that leaves all conffiles as they are and only creates new ones with a clear prefix to avoid name clashes. Updating from = 14 undoes the modifications to sources.list by restoring the original file. So that is what you are seeing. See /usr/share/doc/ia32-apt-get/NEWS.Debian.gz for a description of how it works now. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533472: [Pkg-ia32-libs-maintainers] Bug#533472: closed by Goswin von Brederlow goswin-...@web.de (Bug#533362: fixed in ia32-libs-tools 18)
Philip J. Clark p.j.cl...@ed.ac.uk writes: Thanks for this. Unfortunately, it seems to have caused me a few other problems. ia32-libs now installs ia32-libs-tools, was this the case before? It seems to need a ton of packages now (I only want to run 32 bit skype). Yes, that was intended. ia32-libs and ia32-libs-gtk are now just dummy packages depending on all the individual packages that were part of it. You did have them all installed, just not visibly as such. You can actually now download the skype i386 debian package and run dpkg -i skype_1.2.0.17-1_i386.deb and it will depend on the right ia32-* packages it needs. ia32-libs and ia32-libs-gtk can be savely removed and you only need to keep those ia32-* packages that skype actually needs. apt-get and aptitude should tell you which are no longer needed. So I've had to update the APT cache size to cope with this. Also when installing ia32-apt-get update the gpg key part ran out of memory or some random variables. I've now got a broken package. But You probably mean out of random bits, i.e. /dev/random run dry. That often happens when creating a gnupg key and just means you need to wait for some more randomness to appear. It can take a while so let it sit there. Doing other things in parallel increases the amount of random bits generated and passes the time. really don't know how to fix it. I can't purge it or reinstall without the error mesage below. Any ideas? dpkg -l | grep ia32-apt-get pH ia32-apt-get18 Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion hercules:/etc# dpkg --purge ia32-apt-get (Reading database ... 224237 files and directories currently installed.) Removing ia32-apt-get ... No diversion `diversion of /usr/bin/apt-get to /usr/bin/apt-get.real by ia32-apt-get', none removed No diversion `diversion of /usr/bin/dpkg-deb to /usr/bin/dpkg-deb.real by ia32-apt-get', none removed rm: cannot remove `/usr/share/ia32-apt-get/dists/transitional/Release.gpg': No such file or directory dpkg: error processing ia32-apt-get (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: ia32-apt-get Bug in the postrm script, fixed in svn. Run touch /usr/share/ia32-apt-get/dists/transitional/Release.gpg and try again or remove the set -e in /var/lib/dpkg/info/ia32-apt-get.postrm But before you do that could you send me the error you get when reinstalling ia32-apt-get? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533472: [Pkg-ia32-libs-maintainers] Bug#533472: closed by Goswin von Brederlow goswin-...@web.de (Bug#533362: fixed in ia32-libs-tools 18)
Philip J. Clark p.j.cl...@ed.ac.uk writes: Thanks for this. Unfortunately, it seems to have caused me a few other problems. ia32-libs now installs ia32-libs-tools, was this the case before? It seems to need a ton of packages now (I only want to run 32 bit skype). Hi again, small hint for skype. Add the following entry in /etc/apt/sources.list deb [arch=i386] http://download.skype.com/linux/repos/debian/ stable non-free and run /usr/share/ia32-apt-get/convert-all-sources.list apt-get update apt-get install skype MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533472: [Pkg-ia32-libs-maintainers] Bug#533472: closed by Goswin von Brederlow goswin-...@web.de (Bug#533362: fixed in ia32-libs-tools 18)
Philip J. Clark p.j.cl...@ed.ac.uk writes: Dear Goswin, Thank you for the very detailed comprehensive response. But before you do that could you send me the error you get when reinstalling ia32-apt-get? # apt-get --reinstall install ia32-apt-get Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded. 1 not fully installed or removed. Need to get 0B/20.1kB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? WARNING: The following packages cannot be authenticated! ia32-apt-get Install these packages without verification [y/N]? y Selecting previously deselected package ia32-apt-get. (Reading database ... 224238 files and directories currently installed.) Preparing to replace ia32-apt-get 18 (using .../ia32-apt-get_18_all.deb) ... Unpacking replacement ia32-apt-get ... dpkg: error processing /var/cache/apt/archives/ia32-apt-get_18_all.deb (--unpack): trying to overwrite `/usr/bin/apt-get', which is also in package apt Errors were encountered while processing: /var/cache/apt/archives/ia32-apt-get_18_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -Phil Thanks, fixed too. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534965: [Pkg-ia32-libs-maintainers] Bug#534965: ia32-apt-get: is completely broken
retitle 534965 ia32-apt-get breaks aptitude
severity 534965 serious
merge 534965 533746
thanks
Norbert Preining prein...@logic.at writes:
Package: ia32-apt-get
Version: 18
Severity: grave
Justification: renders package unusable
That package was pulled in automatically by libs-i386 and it breaks
nearly everything:
- aptitude UI with upgrading does not work, redownloads everything again
and again
I know update does not work in aptitude. I wasn't aware of other
breakage. Can you provide some sort of log? This is a duplicate of
533746, merging.
- changing /etc/apt/sources.list is not carried over to whereever that
package saves it dummy hosed sources.list (in /e/apt/{386,amd64})
As mentioned in NEWS and as of version 19 also in README.Debian for
the time being you need to run
/usr/share/ia32-apt-get/convert-all-sources.list
when you change your sources.list.
- calling apt-get update from the command line (recommended in another
bug report) finishes in a core dump
/usr/bin/apt-get: line 46: 30757 Segmentation fault apt-get.real
--no-list-cleanup --no-download update
One other user managed to produce that on irc today. I can't reproduce
it and the user purged and reinstalled ia32-apt-get, thereby solving
the problem for some reason, before I could ask him to send a tar of:
/etc/apt
/var/lib/apt
/var/cache/apt (without archives/)
I don't know what causes this but something is triggering a bug in
the real apt-get. Best guess apt-get manages to break its *.bin cache
files. Maybe when it complains about the APT::Cache-Limit being too
small. Did you have to increase APT::Cache-Limit just before you got
the Segmentation fault?
- telling the user *ONLY* in the NEWS file that we have to pin i386
packages otherwise they instead of the native ones will be installed
is *definitely* not enough. I have NOT decided to include i386 package
repositories in my sources.list, if ia32-apt-get adds that automatically
it has to make sure that this does not happen.
1) You do not just get i386 packages instead of native ones in
general. But you can on rare occasions and only in
unstable/experimental when i386 has a newer version than amd64. The
pining is only needed to prevent even those rare occasions.
2) There is also nothing I can do about this automatically as policy
forbids ia32-apt-get from changing /etc/apt/preferences, a conffile of
another package. Wether this can be improved upon depends on the apt
maintainer, for example they could add a /etc/apt/preferences.d/
directory like there is apt-conf.d/ and sources.list.d/.
3) You do have installed ia32-libs. As such you have selected to
install i386 debs on your system. ia32-apt-get extends that somewhat
and changes the way the debs are fetched but you already did choose to
install i386 debs when you selected ia32-libs however long ago that
was.
4) Unstable is as unstable says!
You get to keep the pices.
This is a new software that only a few people (74 acording to popcon)
have used so far. There are bound to be bugs and there are bound to be
missing features. Software isn't born perfect.
Is this a joke package? It is not April fool's day!
If you prefer I will open grave bugs for each of the above.
I only consider the first issue a real bug in ia32-apt-get and adding
support for aptitude and cupt is already on my ToDo. Actually cupt
support might come first as the maintainer has already fixed some
issues preventing ia32-apt-get to work. Aptitude will need a fix for
its update menu entry too and I don't know how long that is going to
take to write.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533746: #533746 ia32-apt-get breaks aptitude update
Hi, I'm afraid ia32-apt-get does not yet provide a wrapper for aptitude. For the time being you have to use apt-get update instead. In the future running aptitude update on the command line will be wraped and do the right thing but I'm afraid that upgrading from the interactive interface can not be made to work with ia32-apt-get without patching aptitude. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533753: cupt: overzelous signature checking breaks ia32-apt-get
Eugene V. Lyubimkin jackyf.de...@gmail.com writes: Cupt will need a wrapper so cupt update works right. The wrapper could also set the option to ignore signature checks other than when downloading. So that would work. Does cupt have an equivalent to apt-get.real --no-list-cleanup --no-download update That just parses the existing Packages files and updates its caches without fetching any files. This needs to be run by ia32-apt-get after mangling the Packages files to fit (in the cupt wrapper). Cupt doesn't have any cache files for indexes, it generates them on the fly by demand. Does this remove the problem for cupt update (besides the security problem above which will be fixed)? It removes the problem but not the need for a wrapper. The wrapper needs to run cups \ -o Dir::Etc::sourcelist=/etc/apt/$ARCH/sources.list \ -o Dir::Etc::sourceparts=/etc/apt/$ARCH/sources.list.d \ -o Dir::State=$LISTDIR/$ARCH \ -o Dir::Cache=/var/cache/apt/$ARCH \ -o Apt::Architecture=$ARCH \ update for each architecture and then mangle the Packages files for non-native architectures. I hope cups supports all those options and passing them on the command line. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
