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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Adam D. Barratt a...@adam-barratt.org.uk writes: On Sat, 2010-12-04 at 08:37 +0100, Thijs Kinkhorst wrote: On Thursday 18 November 2010 22:24:01 Thijs Kinkhorst wrote: On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: ia32-libs-core (20101117) unstable; urgency=low ia32-libs (20101117) unstable; urgency=low I just uploaded these to sid. I think ia32-libs-core still needs an unblock? Why was the Breaks on ia32-libs ( 20100418) dropped? That isn't Breaks readded as per policy 7.6.1: Overwriting files in other packages. Thanks for noticing. mentioned in the changelog. (Nor are the two lines that have retrospectively appeared in the changelog for ia32-libs-core 20100421). Good question actually. Seems like some changes crept in that I had commited locally but not pushed when Frederik uploaded 20100421. I've reverted the commit. Regards, Adam Uploading ia32-libs-core_20101207_source to mentors. Sponsors welcome. Packages updated: [ gcc-4.4 (4.4.5-8) unstable; urgency=low ] [ icu (4.4.1-7) testing-proposed-updates; urgency=high ] The upload contains one more change to the source which I hope is acceptable for squeeze. I replaced the older fetch-and-build script with the newer one from ia32-libs (and ia32-libs-gtk) so that they have the same script again. This includes the part that automatically generates the debian/changelog entries for the updated debs. So the future debian/changelog entries of ia32-libs-core, ia32-libs and ia32-libs-gtk will all look the same too. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605605: apt: uninteresting NEWS.Debian
David Kalnischkies kalnischkies+deb...@gmail.com writes: On Wed, Dec 1, 2010 at 19:26, Jakub Wilk jw...@debian.org wrote: | * Already included in the last version but now with better documentation | is the possibility to add/prefer different compression types while | downloading archive information, which can decrease the time needed for | update on slow machines. See apt.conf (5) manpage for details. I was told on d-devel that this is a great feature for e.g. s390 machines and of general usefulness, thats why it was enhanced and got this entry in the first place http://lists.debian.org/debian-devel/2009/08/msg00955.html It is a great feature and something users should be made aware of. They do need to modify their config to benefit from it. This should be mentioned in NEW once. Only remove this if the last version already had an entry for it please. | * APT manages his manpage translations now with po4a, thanks to Nicolas | François and Kurasawa Nozomu, who also provide the ja translation. | Thanks to Christian Perrier we have already a fr translation and | a few more are hopefully added in the near future. Having a translation of a manpage looks for me like a great feature. People get pinning for example always wrong, now they can read in their native tongue what is wrong. ;) Not to mention the various config options And last but not least it encourages maybe more translations :) We have btw currently complete documentation in de, es, fr and pt - ja only manpages and pl only some manpages After all, that are currently 1048 paragraphs(!) to translate In my humble opinion, thats a pretty big achievement. Obviously manpages are a good thing. But no reason for a NEWS entry. It really does not matter to the user how the manpages for apt where generated. Just that they are there. | * This version also introduces some _experimental_ configuration options | to make more aggressive use of dpkg's triggers. If you want to help | testing these _experimental_ options see apt.conf (5) manpage. Again something people asked for (e.g. for possible use in d-i). The major obstacle against defaulting to them left is the progress reporting Something which isn't shown in APT at all but its front-ends It avoids some pretty hard bugs caused by the need to split too long dpkg calls, which happens sometimes at the wrong position - and is even a small speed improvement - maybe even bigger if #526774 would show progress But yes, this one could possible be removed. Properly we could/should add others It very much depends on which angle you look at APT and as it used in many ways you can have many angles (best example is the first point) Given that this news-entry is more than a year old, it can't be useless for everyone after all. I think this should stay for unstable/experimental. But it has no place in stable/testing. The feature is experimental, it says so itself, and stable/testing users should not be invited to play with such dangerous things. Just my 2c, Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605516: Bug#602539: Successfull install creates broken system (mounting fs fails)
Samuel Thibault sthiba...@debian.org writes: Goswin von Brederlow, le Thu 02 Dec 2010 08:53:28 +0100, a écrit : You can warn during partitioning if there isn't even space for the standard task. Some people want to be able to install just the base system and only that. Me too and by that I usualy I mean including standard and ssh and nothing else. I specifically said warn above, just like DI warns if one does not have a swap partition (which I find rather silly with 4GB ram on a desktop). I think it is safe to assume people will install at least standard and if they really only want a bare minimal system and only use the minimal size for the filesystem then they will have to ignore the warning and continue anyway. As for size differences for each architecture you can know those. Nope. As said previously in the thread, it depends on the locale, some options in expert mode, etc. And dependencies change all the time depending on what maintainers add or remove. Install media should not matter. It surely does: when installing via network, you have to store all the debs in /var/cache Ahh, I thought you ment the media you install to, not from. Yes, a network install should know that it needs some extra space in /var. But the size of the debs is known before download so it can compute that easily enough. Filesystem type and blocksize might to some degree It can be very huge. Given that, at least for mke2fs, the blocksize depends on the filesystem size there isn't much variance there. If your /var partition is large enough to warrant 4k blocks it will have enough space anyway. And can you have anything but 4k blocks for /usr and still be big enough? but you can add some safety margin to the warning. We can not make any promises then. As to the users choices, like later selecting gnome or kde, you can then give a warning. Based on pure guess?... No. then as in when the user has selected kde or gnome but still before downloading kde/gnome. The important point is to prevent the download of all the debs just to fail at 90%. Sure, but it's extremely hard to predict without actually simulating everything, which _does_ need the download. So do simulate it. Download all the packages for a task, unpack them and run du on the relevant directories. Add 10% safety margin and you should have reasonable values to check against. It is enough if it covers the basic mountpoints like /usr and /var the installer already knows as common mountpoints. But package management doesn't. Samuel Unfortunately no. But listing size requirements for /, /usr, /var, ... for every package in Packages.gz is another wishlist bug. This does not need to (and can not) be perfect and should only warn. It doesn't need to be able to predict the required space down to the last block. If it comes to within 10% of the filesystem size that is plenty. One shouldn't fill up filesystems anyway. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605516: Bug#602539: Successfull install creates broken system (mounting fs fails)
Christian PERRIER bubu...@debian.org writes: Quoting Denis Laxalde (dlaxa...@gmail.com): clone 602539 -1 reassign -1 base-installer retitle -1 should check size of common mountpoints before proceeding to installation tags -1 d-i thanks On Fri, 05 Nov 2010 19:15:19 +0100, Goswin von Brederlow wrote: Install base system: + Check size of common mountpoints (/, /usr, /var) At first I made / too small and it failed much later during the installation of the kernel image. Debian kernels are HUGE compared to my usual build-to-fit custom kernel. It would be good if the installer would know the size requirement for all the usual mountpoints people use and check if the defined partitions have sufficient space. The numbers should be known for at least the standard task, more would be better. This may also be a wishlist. Why against base-installer? I would have thought partman and/or tasksel would have to do this. This wishlist is a chimera, imho. The best (or less worse) we can do is in partman-auto and have reasonable decent sizes there. Everything else is too dependent on user choices (or even the current *installation languages*, or the architecture...or the installation media... that imagining we'll find a solution to warn users when they create too small partitionsfor something they don't even have chosen already (what to install) is just science-fiction. You can warn during partitioning if there isn't even space for the standard task. As for size differences for each architecture you can know those. Install media should not matter. Filesystem type and blocksize might to some degree but you can add some safety margin to the warning. As to the users choices, like later selecting gnome or kde, you can then give a warning. The important point is to prevent the download of all the debs just to fail at 90%. It is enough if it covers the basic mountpoints like /usr and /var the installer already knows as common mountpoints. If the user does something too complicated, like having /usr/lib or /usr/share seperate then he probably knows what he is doing. The check doesn't need to be perfect. It just needs to catch the obvious cases. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605055: [Pkg-ia32-libs-maintainers] Bug#605055: ia32-libs: can not config ia32-libs-gtk when full-upgrade with ia32-libs
Kejiaæ¯å w.ke...@gmail.com writes: Hi Goswin, Thank you for the help. I've tried to remove package ia32-libs-workaround-499043, but failed: `` # aptitude remove ia32-libs-workaround-499043 Your system is in an inconsistent state. Forget about using aptitude, it doesn't do what you ask it to. Use apt-get or dpkg. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605055: [Pkg-ia32-libs-maintainers] Bug#605055: ia32-libs: can not config ia32-libs-gtk when full-upgrade with ia32-libs
Kejia w.ke...@gmail.com writes: Package: ia32-libs-gtk Version: 20100914 Severity: normal File: ia32-libs Hello, I tried to do a full-upgrade, which required installing ia32-libs, but failed because ia32-libs-gtk can not be configured correctly. Lucky, Kejia Please copypaste the actual error you get. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605080: Missing built-in sort option
Package: findutils Version: 4.4.2-1 Severity: wishlist File: /usr/bin/find Hi, I frequently find myself using a find | sort construct. With large number of directories and files this has some drawbacks though: - needs to complete the find before sort outputs anything - needs to buffer the complete find output - needs to compare the full path O(n * log n) times I wish that find had a built-in sort that would sort each individual directory and then recurse into subdirs in order. That way one would have an efficient incremental sorted output and no need for tempfiles for sort. MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (666, 'unstable'), (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 findutils depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib findutils recommends no packages. Versions of packages findutils suggests: ii locate4.4.2-1maintain and query an index of a d ii mlocate 0.22.2-1 quickly find files on the filesyst -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst th...@debian.org writes: On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: ia32-libs-core (20101117) unstable; urgency=low ia32-libs (20101117) unstable; urgency=low I just uploaded these to sid. Thx. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst th...@debian.org writes: On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: ia32-libs-core (20101117) unstable; urgency=low ia32-libs (20101117) unstable; urgency=low I just uploaded these to sid. I hope they can be unblocked and their urgency pushed by the release team if they think it's appropriate. What about ia32-libs-gtk, will there also be another update for that? Cheers, Thijs Petty sure all of them will need more updates as new libs are unblocked into squeeze. But there was nothing urgent to fix for ia32-libs-gtk. The current one can go in now and then a later unblock request will just deal with updated libs and have no source changes. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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
severity 603858 important thanks Steve Langasek vor...@debian.org writes: On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote: Package: initramfs-tools Version: 0.93.4 Severity: critical File: /usr/share/initramfs-tools/init Tags: patch How in the world does this count as critical? The /etc/init.d/mountall.sh script reports a red FAILED because of that. This is the only symptom you describe, and that's certainly not critical! Usualy a FAILED message also means the script returns an error, which in turn means insserv stops executing depending scripts in that runlevel and skips to the next. Looking closer at the script I see now that mountall.sh does not report errors through its exit code. So it just makes it impossible to see if something real failed to mount because proc always fails to mount. Sorry for the severity. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Michael Gilbert michael.s.gilb...@gmail.com writes: On Tue, 9 Nov 2010 16:21:19 +0100, Julien Cristau wrote: On Tue, Nov 9, 2010 at 15:41:56 +0100, Thijs Kinkhorst wrote: As for ia32-libs, I would be willing to sponsor it but I don't think we should be making uploads for such trivial cleanup operations, is this really necessary to get ia32-libs unblocked? No. I just didn't want to unblock it until the wine issue was resolved. I'm still not convinced ia32-libs-dev is a useful/sane thing to ship. Providing a working runtime environment for 32bit programs is one thing. Providing a build environment is another entirely, and the way it has to mangle .la files (and now .pc too) makes me wonder what other sort of brokenness it lets through. Why is it that ia32-libs provides all of these 32-bit libs as a monolithic package anyway? Wouldn't the saner solution be to provide each desired 32-bit lib from the original source package for that lib (for example bzip2 provides lib32bz2, lib32bz2-dev, etc)? In that case ia32-libs is could just be a metapackage, rather than the mess it is currently. Obviously this solution will need to be deferred to wheezy (perhaps as a release goal?) since time is short for squeeze. 1) bzip2 compiles a 32bit flavour on amd64. On ia64 it is included in ia32-libs (lenny) or ia32-lib-core (squeeze). No 32bit compiler on ia64. 2) Providing the same binary package from different source packages on different architectures is bad. Confuses the BTS and other things. Providing a lib32bz2 on ia64 not build from bzip2 would be bad. So it would have to be named something liike ia32-libbz2. 3) Ftp-master (Ganneff) rejected a split of ia32-libs into 54 source packages some while back. This was so that each source change would only require that source to be uploaded, preferably by the original maintainer. Also dependencies between libs would have been tracked correctly. 4) Ftp-master (Ganneff) removed ia32-apt-get from Debian. Ia32-apt-get generated the lib32* packages on-the-fly on the users system. It provided 32bit support for basically every library in Debian (or any repository) with instant (security) updates and also support for 3rd party apt repositories with only i386 (e.g. skype) to be directly installable. 5) We now have several conflicting packages that need 32bit support. E.g. nss-ldap and jackd. They should have been split out of ia32-libs already to allow installing the different flavours of them but that has to wait for post squeeze. Dependencies on them might require more splits. At some point doing the full split down to actual source package will be simpler. Someone might have to convince ftp-master to reverse their decision on 3 or 4. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Michael Gilbert michael.s.gilb...@gmail.com writes: On Tue, 9 Nov 2010 16:21:19 +0100 Julien Cristau wrote: On Tue, Nov 9, 2010 at 15:41:56 +0100, Thijs Kinkhorst wrote: As for ia32-libs, I would be willing to sponsor it but I don't think we should be making uploads for such trivial cleanup operations, is this really necessary to get ia32-libs unblocked? No. I just didn't want to unblock it until the wine issue was resolved. I'm still not convinced ia32-libs-dev is a useful/sane thing to ship. Providing a working runtime environment for 32bit programs is one thing. Providing a build environment is another entirely, and the way it has to mangle .la files (and now .pc too) makes me wonder what other sort of brokenness it lets through. I probably won't object to this if the current breakage gets fixed though, because I'm getting tired of this package and would rather do something useful instead. alsa-plugins also build-depends on ia32-libs, does it need a fix for the new stuff too? what about libvdpau? alsa-plugins, nspluginwrapper, fglrx-driver, nvidia-graphics-drivers, and sun-java6 all build-depend on ia32-libs, and build successfully without ia32-libs-dev. libvdpau doesn't. I've uploaded a fix for that to mentors: http://mentors.debian.net/debian/pool/main/l/libvdpau Mike Thanks. I checked in the past but overlooked libvdpau. Good to have this looked at by another set of eyeballs. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst th...@debian.org writes: As for ia32-libs, I would be willing to sponsor it but I don't think we should be making uploads for such trivial cleanup operations, is this really necessary to get ia32-libs unblocked? I can take a look at wine later this week if no-one beats me to it and if the release team approves the change for squeeze. Hi, I've just uploaded an updated ia32-libs-core and ia32-libs to mentors: ia32-libs-core (20101117) unstable; urgency=low . [ Goswin von Brederlow ] * Replace lib32icu42 with lib32icu44. * Update Packages: + alsa-lib 1.0.22-2 - 1.0.23-2.1 + blcr 0.8.2-13 - 0.8.2-15 + bzip2 1.0.5-4- 1.0.5-6 + eglibc2.10.2-9 - 2.11.2-7 + gcc 4.4_4.4.4-1- 4.4_4.4.5-6 + icu 4.2.1-3- 4.4.1-6 + libffi3.0.9-2- 3.0.9-3 + ncurses 5.7+20100313-2 - 5.7+20100313-4 ia32-libs (20101117) unstable; urgency=low . * Drop ia32-libs-dev from ia64. No 32bit compiler there (Closes: #603679, #540027). * Make ia32-libs-dev priority extra (sync with ftp-master overrides). * Add lintian override for executable stack in libSDL-1.2. . * Packages updated [ esound (0.2.41-8) unstable; urgency=low ] [ libxml2 (2.7.8.dfsg-1) unstable; urgency=low ] ... The ia32-libs-core contains the security update for libc6: * Add any/submitted-origin.diff from Andreas Schwab to forbid the use of $ORIGIN in privileged programs. Add any/cvs-audit-suid.diff to only load SUID audit objects in SUID binaries. Fix CVE-2010-3847. Closes: #600667. The ia32-libs fixes the grave bug of ia32-libs-dev being uninstallable on ia64. With wine in DELAYED/7 that hopefully only leaves the libvdpau patch as blocker for unblocking ia32-libs. I would welcome a sponsoring of these. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603798: debian-installer: /tmp is not created with 777 mode when doing manual disk partitionning
Eric Valette eric2.vale...@orange-ftgroup.com writes: Package: debian-installer Version: Debian Installer 14/11/2010 Severity: important Tags: d-i I reinstalled a machine this week-end. The install base smootly worked. I created a separate /tmp file system that was monted but with wrong permission. root.root 755. Visible effect is that kdm login loops as the X server does not manage to create some /tmp/ files. Doing a chmod 777 /tmp with file system monted solves the problem. And leaves you wide open to all sorts of exploits: drwxrwxrwt 11 root root 260 Nov 17 14:44 /tmp/ ^ The t is important. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602977: ITP: ocs -- Opal Compilation System
Benjamin Drung bdr...@ubuntu.com writes: Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@ubuntu.com * Package name: ocs Version : 2.3n Upstream Author : Opal Group, TU Berlin * URL : https://projects.uebb.tu-berlin.de/opal/ * License : GPL, LGPL (will probably change) Programming Lang: C, Opal Description : Opal Compilation System The Opal project is concerned with research into a programming environment in which advanced language concepts and formal development methods can be used for creating production-quality software. At the core of the project is the algebraic programming language, Opal, which integrates both concepts of algebraic specification and functional programming. A comprehensive set of tools supporting the language constitutes the Opal compilation system OCS. I am in direct contact with the upstream maintainer to get the package suitable for Debian (relicensing documentation under DFSG compliant license, FHS compliance, lintian fixes). We target to have a new upstream version at the end of the year and to get this into the archive. Just to recap from the irc discussion so it doesn't get lost: Ocs is a bad package name. There is already another ITP for ocs that is something completly different. Opal-compiler seems like a better choice. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602580: Ctrl-k no longer fills the copypaste buffer
Nicolas Duboc ndu...@debian.org writes: On Sat, Nov 06, 2010 at 07:26:19AM +0100, Goswin von Brederlow wrote: when cutting the end of a line with Ctrl-k one it is no longer put into the copypaste buffer, Ctrl-y no longer pastes it somewhere else. I miss that feature. I tried to reproduce this issue and Reuben explained me an issue affecting copy/paste buffer indeed. But that's not exactly the one I understand from your email. 1. open a new zile buffer 2. enter abcnewline 3. enter defnewline 4. enter ghinewline 5. move to start of second line 6. Ctrl-k (removes content of the line but keep the resulting empty line) 7. Ctrl-k (deletes the empty line) 8. move to end of buffer 9. Ctrl-y = paste the newline but not the expected initial def content Is that the bug you reported ? -- Nicolas Duboc ndu...@debian.org Yes. It should remeber any continious sequence of ctrl-k. It only seems to remember the last. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602580: Ctrl-k no longer fills the copypaste buffer
Package: zile Version: 2.3.18-1 Severity: normal Hi, when cutting the end of a line with Ctrl-k one it is no longer put into the copypaste buffer, Ctrl-y no longer pastes it somewhere else. I miss that feature. 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 zile depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-3 shared libraries for terminal hand zile recommends no packages. zile suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602628: sfdisk: Don't complain about partitions not ending on cylinder boundary
Package: util-linux Version: 2.17.2-3.1 Severity: normal File: /sbin/sfdisk Hi, trying to clone a partition table on a freshly installed squeeze system with sfdisk gives the following error: Device BootStart End #sectors Id System /dev/sdc1 2048 19531775 19529728 fd Linux raid autodetect /dev/sdc2 19531776 3907024064 3887492289 fd Linux raid autodetect /dev/sdc3 0 - 0 0 Empty /dev/sdc4 0 - 0 0 Empty Warning: partition 1 does not end at a cylinder boundary sfdisk: I don't like these partitions - nothing changed. (If you really want this, use the --force option.) The requirement to align to cylinder boundaries has been gone for a long time now. With the introduction of drives with 4k blocks and SSDs with 128k erasure blocks it has become neccessary to align to multiples of those instead. An alignment to 1MiB boundaries seems to become the new standard and is what DI uses in squeeze. Please change the sfdisk behaviour to recognice the new alignmet rules so --force is not required for a perfectly well aligned table. You might even fail with the old CHS alignment if the disk has 512 byte I/O size (See fdisk -l output). 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 util-linux depends on: ii dpkg1.15.8.5 Debian package management system ii initscripts 2.88dsf-12 scripts for initializing and shutt ii install-info4.13a.dfsg.1-5 Manage installed documentation in ii libblkid1 2.17.2-3.1 block device id library ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-3 shared libraries for terminal hand ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii libuuid12.17.2-3.1 Universally Unique ID library ii lsb-base3.2-23.1 Linux Standard Base 3.2 init scrip ii tzdata 2010l-1 time zone and daylight-saving time ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime util-linux recommends no packages. Versions of packages util-linux suggests: ii console-tools 1:0.2.3dbs-69 Linux console and font utilities ii dosfstools 3.0.9-1 utilities for making and checking pn util-linux-locales none(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544089: Does not start when Ipv6 is not available
Package: tftpd-hpa Version: 5.0-16 Severity: normal I just got hit by the same bug: Selecting previously deselected package tftpd-hpa. (Reading database ... 160286 files and directories currently installed.) Unpacking tftpd-hpa (from .../tftpd-hpa_5.0-16_amd64.deb) ... Processing triggers for man-db ... Setting up tftpd-hpa (5.0-16) ... Starting HPA's tftpd: in.tftpdinvoke-rc.d: initscript tftpd-hpa, action start failed. dpkg: error processing tftpd-hpa (--configure): subprocess installed post-installation script returned error exit status 71 Errors were encountered while processing: tftpd-hpa E: Sub-process /usr/lib/apt-ma-emu/dpkg returned an error code (1) This is seriously anoying behaviour. The package must not fail to install without IPv6. You should at least check in postinst if IPv6 support is available and give a meaningfull error message. You could also add -4 if IPv6 support is missing. 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/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 tftpd-hpa depends on: ii adduser 3.112 add and remove users and groups ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra tftpd-hpa recommends no packages. Versions of packages tftpd-hpa suggests: ii syslinux-common2:3.83+dfsg-3 Kernel loader which uses a FAT, ex -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602539: Successfull install creates broken system (mounting fs fails)
Package: installation-reports Severity: normal -- Package-specific info: Boot method: network Image version: http://http.us.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/netboot.tar.gz 20-Oct-2010 21:02 8.7M Date: Date and time of the install Machine: HP ProLiant MicroServer Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: Partitioning hard drives (DI uses title 'Partitioning disks'): - Creating raid 1 In the dialog it says: + A minimum of 2 active devices is required. The system will have 4 disks but 3 are full with data in the old system and need to be transfered disk by disk. So I wanted to create a raid 1 with 1 active disk and grow it later to 4 disks. + NOTE: this setting cannot be changed later. mdadm --grow can change it so this is simply not true. - Creating filesystem + Selecting a predefined mount point should set a coresponding label if none is set already. My root partition has label root, /usr has label usr, /var has label var and /home has label home. Install base system: + Check size of common mountpoints (/, /usr, /var) At first I made / too small and it failed much later during the installation of the kernel image. Debian kernels are HUGE compared to my usual build-to-fit custom kernel. It would be good if the installer would know the size requirement for all the usual mountpoints people use and check if the defined partitions have sufficient space. The numbers should be known for at least the standard task, more would be better. General: + Oerall a nice flow. Seems smoother than with lenny. During downloads the remaining time was displayed in seconds. That was a nice touch. + Missing moonbuggy or tetris. One does get bored watching it work. + Missing a text editor on tty5 for making notes during install. It should have a file (/tmp/notes.txt) open and copy it to /target/var/log/installer at the end. Post reboot: (Now we come to the real problems) - Mounting local filesystems...failed. WTF? Why? Why does it continue to boot? The new insserv just keeps on booting even with critial scripts failing. The problem seems to be that the /etc/fstab entry for /proc does not match the entry in /proc/mounts: /etc/fstab: proc/proc procdefaults0 0 /proc/mounts: none on /proc type proc (rw,nosuid,nodev,noexec,relatime) The mountall.sh script executes this command: # mount -v -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2 -O no_netdev; echo $? proc/proc procdefaults0 0 mount: proc already mounted = exit(32); vs. none/proc procdefaults0 0 mount: none already mounted on /proc = exit(0); The odd thing is that in /etc/init.d/mountkern.fs there is: domount proc /proc proc -onodev,noexec,nosuid The 4th argument is the DEVNAME used in mount. So the /proc should be mounted from 'proc' and not 'none'. Could it be /proc is kept from the initramfs? Is this only showing if /etc/mtab is linkd to /proc/mounts? (see below) - /etc/mtab is not a link to /proc/mounts I configured my / and /usr to be read-only. That means the /etc/mtab must be a link to /proc/mounts. I thought that was now standard for all new installations. It should definetly be a link if / is read-only. - /tmp not tmpfs When selecting / read-only and not having a seperate /tmp partition the installer could configure the system for tmpfs for /tmp. It could offer that option in general (include /var/run and /var/lock). Unfortunately there doesn't seem to be a variable for it. In /etc/default/rcS and /etc/default/tmpfs one can set TMPFS_SIZE, RW_SIZE, RAMRUN, RUN_SIZE, RAMLOCK and LOCK_SIZE. Maybe there should be a RAMTMP setting as well to activate /tmp as tmpfs. Alternative a fstab entry for /tmp does the job too. - /etc/network/run is directory, not link to /dev/shm/network This makes ifup fail during boot and the system is left without networking. The strange thing is that ifupdown support read-only / just fine normaly. The postinst script makes /etc/network/run a link to /dev/shm/network if /etc/network/run is mising and /dev/shm exists. So is /dev/shm missing during DI? The fix for this was quite easy: % rm -rf /etc/network/run % dpkg-reconfigure
Bug#602170: [libbz2-ocaml] exceptions don't get registered properly
Stéphane Glondu glo...@debian.org writes: tags 602170 + confirmed severity 602170 important thanks Le 02/11/2010 09:28, Joost Yervante Damad a écrit : whenever there's something wrong, the binding looks up the exception to be thrown, and throws it. [...] more details, including a patch with a possible solution can be found at: https://forge.ocamlcore.org/tracker/index.php?func=detailaid=768group_id=63atid=338 If you add let _ = Bz2.version;; at the beginning of your segfaulting example, it doesn't segfault any more. The reason why exceptions are not registered is because the Bz2 module is not linked in, and therefore its side-effects are not executed. This is because your example uses only externals that are declared as such in bz2.mli. This is unfortunate, but a known issue. I don't agree with you patch. The right fix IMHO would be to make one (or all) of the externals abstract in the .mli file. This would theoretically impact performances in bytecode, but I think not in native code because of inlining. But if performances are critical even in bytecode, I'd rather name the proposed function init instead of register_exceptions which doesn't look very elegant... Any other opinion on this would be welcome. Anyway, this would be an intrusive change (ABI change in interface - binNMU of all reverse-dependencies), the problem is known and can be worked around, and we are in freeze, so I'd rather fix it later, after Squeeze release. Therefore, I hereby downgrade the severity to important. Cheers, Please do fix this though. Make some/all externals abstract to force linking in the module. Some speed penalty is preferable to segfaults. Hoping users will call Bz2.version is just not going to work. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: unblock: ia32-libs/20100914
Philipp Kern pk...@debian.org writes: On Mon, Oct 25, 2010 at 08:16:41PM +0200, Julien Cristau wrote: You can't build 32bit packages for amd64 in a 32bit chroot. That results in the wrong arch and wrong dependencies. But you can use i386 packages on amd64 in a 32bit chroot. That results in much less crack smoking all around. It's also plain wrong considering that we do exactly that. The buildds run amd64 with linux32. Kind regards, Philipp Kern The i386 buildds run a amd64 kernel with i386 userspace and they build packages for i386. This was about building 32bit packages for *amd64*. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600262: apt: random_sleep should not be executed if anacron has started the cron.daily script
Teodor MICU mteo...@gmail.com writes: Hi, On Wed, Oct 20, 2010 at 3:33 PM, Goswin von Brederlow goswin-...@web.de wrote: Please apply this patch to avoid 'random_sleep' if the script was started by anacron. But if the system stays up all night then the jobs are also started by anacron. This time at the problematic time though. I don't know exactly how 'cron' and 'anacron' are supposed to handle the cron scripts but I've just let my workstation running over night to see the result. I've received this email from Anacron: | From: Anacron r...@fqdn | To: r...@fqdn | Subject: Anacron job 'cron.daily' on FQDN | Date: Sat, 23 Oct 2010 07:37:57 +0300 (EEST) | | /etc/cron.daily/apt: | Sat Oct 23 07:35:02 EEST 2010 | 14147 | Sat Oct 23 07:35:02 EEST 2010 (where 14147 was PID of anacron) So, it is clear that the 'apt' script was not executed by Cron but by Anacron. This is the expected behaviour when anacron is installed from /etc/crontab: | # m h dom mon dow user command | 25 6* * * roottest -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) To conclude, I don't think the patch I've proposed is causing the execution at the problematic time which seems to be 6:25AM. The script was executed clearly at 7:35. Also, desktop systems are not supposed to be running over night but those few exceptions are not many. Thanks There ae 2 problematic times. The first is 6:25 without anacron installed. The second is 7:35 with anacron installed. Anacron just runs later thatn cron: m...@frosties:~% cat /etc/cron.d/anacron 30 7* * * roottest -x /etc/init.d/anacron /usr/sbin/invoke-rc.d anacron start /dev/null and anacron waits 5 miutes before actualy running. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601023: apt: Version comparison broken
Alexey Salmin alexey.sal...@gmail.com writes: Package: apt Version: 0.7.25.3 Severity: important It seems that apt-get version comparison is broken (???). I have ia32-libs (20101012) and I can not install ia32-libs-libssh2 which requires ia32-libs (= 20090808). AFAIK (20101012 = 20090808) is true :) And so it is. That isn't the problem. ia32-libs-libssh2 is an example. I also can not instal bunch of other packages for the same reasons: flashplayer-mozilla ia32-libs-libcurl3 ia32-libs-libidn11 ia32-libs-libnspr4 ia32-libs-libnss3 sal...@salmin:~$ apt-cache show ia32-libs-libssh2 Package: ia32-libs-libssh2 Priority: optional Section: libs Installed-Size: 176 Maintainer: Christian Marillat maril...@debian.org Architecture: amd64 Version: 1.2.5-0.0 Depends: ia32-libs (= 20090808) Filename: pool/main/i/ia32-libs-libssh2/ia32-libs-libssh2_1.2.5-0.0_amd64.deb Size: 63204 MD5sum: 053992c4deafac232ee636bc206ca956 SHA1: 9d15c168e8b4f176251dd22053e161f864c4525a SHA256: 277e9f04cd6682e35eafc0890f60a4170649ab678dbec607b9bc2565465b3787 Description: libssh2 ia32 shared libraries This package delivers a set of pre-compiled ia32 (i386 family) shared libraries, so that third-party 32bit programs can use the SSH2 client-side Library on 64-bit systems that include appropriate emulation support. Bugs: mailto:maril...@debian.org sal...@salmin:~$ dpkg -l ia32-libs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii ia32-libs 20101012 ia32 shared libraries for use on amd64 and i sal...@salmin:~$ sudo apt-get install ia32-libs-libssh2 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: ia32-libs-libssh2: Depends: ia32-libs (= 20090808) but it is not going to be installed E: Broken packages That means what is say: No package ia32-libs with version = 20090808 is going to be installed. The big question now is WHY? Usualy this error means that ia32-libs depends on something that is uninstallable. To find out the simplest way is to run sudo apt-get install ia32-libs-libssh2 ia32-libs You might get the same kind of error again and then just keep adding the respective packages to the command line till it will give you a can not be installed error (or other). Then you've found the culprit. On a side note: libssh2-1 is already included in ia32-libs and you will get a file override conflict trying to install ia32-libs-libssh2 with current ia32-libs. Whatever needs this package needs to be rebuild against a newer ia32-libs. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600262: apt: random_sleep should not be executed if anacron has started the cron.daily script
Teodor mteo...@gmail.com writes: Package: apt Version: 0.8.6 Severity: wishlist Tags: patch Hi, Currently a 'random_sleep' function is implemented in /etc/cron.daily/apt to avoid a DoS on the mirrors. However, on desktop and workstation systems the script is not executed at 6:xx in the morning but later at random times after boot by anacron. The reason is simple, these systems are not up all the time. Please apply this patch to avoid 'random_sleep' if the script was started by anacron. But if the system stays up all night then the jobs are also started by anacron. This time at the problematic time though. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600682: Please add Build-Depends: ia32-libs-dev [amd64]
Package: wine Version: 1.0.1-3 Severity: important Hi, ia32-libs now has a proper ia32-libs-dev package with proper .so links, .la files and (in git, pending upload) .pc files. Wine must now Build-Depend on ia32-libs-dev to successfully compile on amd64. 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 wine depends on: ii libwine-alsa 1.0.1-3Windows API implementation - ALSA ii libwine-cms 1.0.1-3Windows API implementation - color ii libwine-gl1.0.1-3Windows API implementation - OpenG ii libwine-gphoto2 1.0.1-3Windows API implementation - camer ii libwine-ldap 1.0.1-3Windows API implementation - LDAP ii libwine-print 1.0.1-3Windows API implementation - print ii libwine-sane 1.0.1-3Windows API implementation - scann ii wine-bin 1.0.1-3Windows API implementation - binar ii wine-utils1.0.1-3Windows API implementation - utili Versions of packages wine recommends: pn ttf-liberationnone (no description available) Versions of packages wine suggests: pn avscan | klamav | clamav none (no description available) pn binfmt-supportnone (no description available) pn ttf-mscorefonts-installer none (no description available) pn winbind none (no description available) pn wine-doc none (no description available) Versions of packages libwine depends on: ii ia32-libs 20100914 ia32 shared libraries for use on a ii libc6-i3862.11.2-5 Embedded GNU C Library: 32-bit sha -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: unblock: ia32-libs/20100914
Julien Cristau jcris...@debian.org writes: On Wed, Oct 13, 2010 at 16:12:13 +0200, Goswin von Brederlow wrote: Julien Cristau jcris...@debian.org writes: On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote: Please unblock package ia32-libs and ia32-libs-gtk Some more questions now that 20101012 has been uploaded: - what's the point of the ia32-libs-dev package? nothing seems to depend on it, and it didn't exist on amd64 until now. I can't find an explanation or mention of this in the changelog either... - lib32gcc1.debhelper.log is still there, along with lib32gcc1.substvars Cheers, Julien It is now needed to build wine among other things. wine doesn't build-depend on it. Does that mean wine/amd64 is unbuildable at the moment? I'm afraid so. Should be fixed shortly. We had lots of requests from people wanting to compile 32bit stuff and lots of bugs about the hacked together links previously used being broken that it made sense to reintroduce the ia32-libs-dev package and do it properly. I'd rather they used chroots than clutter the debian archive with more of this. I have trouble with the word properly in your sentence. Cheers, Julien You can't build 32bit packages for amd64 in a 32bit chroot. That results in the wrong arch and wrong dependencies. The properly part is that now the *.so symlinks are taken from the packages. Before there was a hardcoded list of links to create and every time a library version changed the respective link would break. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599206: dpkg-cross should leave files in converted package
Loïc Minier loic.min...@linaro.org writes:
On Wed, Oct 06, 2010, Goswin von Brederlow wrote:
Create a wrapper script that defaults to the natgive arch but accepts an
arch triplet as argumen, like:
cat tclConfig.sh EOF
#!/bin/sh
ARCH=${1:$(DEB_HOST_GNU_TYPE)}
exec /usr/lib/$ARCH/tcl8.5/$0
EOF
Yup, that's fair; I would use /usr/share/$triplet, but it's alright.
Does dpkg-cross preserve pathnames below /usr/share/$triplet or
/usr/lib/$triplet though? Since we don't have multiarch, we do need to
dpkg-cross this, and that's why Marcin is trying to dpkg-cross
tcl8.5-dev.
--
Loïc Minier
share is for things that are architecture independent which this is
obviously not.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584254: dpkg should support a --force-unsafe-io option or such
Guillem Jover guil...@debian.org writes: 3) dpkg is pointlessly slow in such use cases as buildds where *sync() is not important at all. Well, even if the buildd chroot supposedly should be able to be recreated easily, if the zero-lenght file issues appear on it, then it might not be obvious something is wrong, and might produce bogus packages. Nah. If the buildd crashes while creating the chroot then it will just have to remove and recreate the chroot when it comes back. In configs where lvm snapshots, btrfs snapshots or cow hardlink farms are used this is the default. And only in such chroots would you use the unsafe IO option. 2) current dpkg is arguably not suitable for flash media (i.e. embedded devices). This hurts the universal part of Debian OS. 4) while typical dpkg could be work arounded with libeatmydata, there is no cure for debian-installer. Sure, I agree the user should be able to disable this, at their own risk. Or on specific cases, like on d-i. Maybe in unsafe mode dpkg should create /var/lib/dpkg/unsafe, sync(), do everything else unsafe, sync(), remove /var/lib/dpkg/unsafe. And when /var/lib/dpkg/unsafe exists already then it should start SCREAMING its head of. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: unblock: ia32-libs/20100914
Julien Cristau jcris...@debian.org writes: On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote: Please unblock package ia32-libs and ia32-libs-gtk Some more questions now that 20101012 has been uploaded: - what's the point of the ia32-libs-dev package? nothing seems to depend on it, and it didn't exist on amd64 until now. I can't find an explanation or mention of this in the changelog either... - lib32gcc1.debhelper.log is still there, along with lib32gcc1.substvars Cheers, Julien It is now needed to build wine among other things. We had lots of requests from people wanting to compile 32bit stuff and lots of bugs about the hacked together links previously used being broken that it made sense to reintroduce the ia32-libs-dev package and do it properly. I will think of something to write in the changelog and Debian.NEWS about it. I'm sure there will be another update needed and if that is OK I can add that then. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583337: reassign to dpkg-dev with request to support -sn for all formats?
Yaroslav Halchenko deb...@onerussian.com writes: CCing Dpkg Developers -- please reassign to dpkg-dev (dpkg-source) if you consider my concern valid I got the same warning while playing with reprepro's changelogs.example. It also relies on dpkg-source -sn -x to extract packaging only directory from the sources to obtain copyright and Debian changelog files. Although -sn is listed as a Format: 1.0 specific, it makes complete sense to have it supported for any other format to do precisely that -- Ensures that the original source is neither copied to the current directory nor unpacked. As a result of the absent V3 support for -sn, dpkg-source does a copy of the original sources, which in our case 1.7GB data package, thus not acceptable situation and demolishing the benefits for V3 having a neat .debian.tar.g. Since there is no other cross-format option for dpkg-source to extract Debian packaging only, I do not think it is viable to provide format-specific handling in every dependent tool (e.g. sbuild, reprepro) instead of fixing dpkg-source to provide such generic functionality across all (or major) formats. The same could be said for -sp, -su and --skip-debianization. The last is specified for 3.0 (quilt) but would make sense for 3.0 (git) and 3.0 (bzr) too [skip the checkout]. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599206: dpkg-cross should leave files in converted package
Neil Williams codeh...@debian.org writes: notfound 599206 2.5.8ubuntu2 found 599206 2.5.8 severity 599206 wishlist retitle 599206 dpkg-cross: document file removal process quit On Tue, 05 Oct 2010 18:10:32 +0200 Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: Package: dpkg-cross Version: 2.5.8ubuntu2 Wrong version - please report this in Launchpad only or reproduce in Debian before filing the bug. However, the bug as described is a result of how the code is designed to work in both Debian and Ubuntu. dpkg-cross by default removes lot of files from converted packages. This is to prevent file conflicts with the original package. i.e. if you need files from a package which are removed from the cross package by dpkg-cross, you need to ensure that the native version of that package is installed. dpkg-cross only cares about specific files types in the -cross package - typically files which are architecture-dependent and which are easily identifiable as such. I should care about the copyright and changelogs though. A dpkg-cross converted package is undistributable because of that. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599206: dpkg-cross should leave files in converted package
Loïc Minier loic.min...@linaro.org writes: On Tue, Oct 05, 2010, Neil Williams wrote: This script is a build-tool, it is not a cross-build-dependency in that it is not a header file, it is not a pkg-config file and it is not used when linking the cross built application. The file is therefore not architecture-dependent and cannot be handled by dpkg-cross. It is a build tool, but it's specific to the target architecture The fact that it's not a header, not a pkg-config file, and not used when linking cross built applications doesn't imply that it is architecture independent. I diffed tclConfig.sh on armel and amd64: @@ -18,10 +18,10 @@ TCL_MINOR_VERSION='5' TCL_PATCH_LEVEL='.8' # C compiler to use for compilation. - TCL_CC='x86_64-linux-gnu-gcc' + TCL_CC='arm-linux-gnueabi-gcc' # -D flags for use with the C compiler. - TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\iso8859-1\ -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\hidden\\)\)\) -DTCL_SHLIB_EXT=\.so\ -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 ' + TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\iso8859-1\ -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\hidden\\)\)\) -DTCL_SHLIB_EXT=\.so\ -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 ' # TCL_DBGX used to be used to distinguish debug vs. non-debug builds. # This was a righteous pain so the core doesn't do that any more. BTW in /usr/lib is actually a good indication that it might be arch-specific IMHO (by opposition to /usr/share where it must be arch-independent). Being in a subdir of usr/lib (usr/lib/tcl8.5) makes it less obvious that it's relevant for the crossed package since it might look like a plugin directory. If having the amd64 package around causes trouble, discuss with the tcl maintainers whether the script can be put into a -dev-common package or whether some more standard tool like pkg-config can be used instead. Not an option here since the script does differ across architectures. This is a recurring problem in cross-building. dpkg-cross cannot leave these files in place or the -cross package won't install. In an ideal
Bug#598226: FTBFS when configure is rebuild
Package: freeciv Version: 2.2.2-1 Severity: important Tags: patch Hi, the debian/patches/use_system_lua5.1 patch is broken: --- freeciv-2.2.1.orig/configure.ac +++ freeciv-2.2.1/configure.ac @@ -851,8 +851,8 @@ AC_CHECK_FUNCS([isatty popen _longjmp]) dnl In the future we probably get rid of our own lua tree and use dnl lua from system. dnl LUA_AS_DEPENDENCY should be empty when using lua outside own our tree. -LUA_CFLAGS=-I\$(top_srcdir)/dependencies/lua-5.1/src -LUA_LIBS=\$(top_builddir)/dependencies/lua-5.1/src/liblua.a +LUA_CFLAGS := $(shell pkg-config lua5.1 --cflags) +LUA_LIBS=/usr/lib/liblua5.1.a LUA_AS_DEPENDENCY=$LUA_LIBS AC_SUBST([LUA_CFLAGS]) AC_SUBST([LUA_LIBS]) --- freeciv-2.2.1.orig/configure +++ freeciv-2.2.1/configure @@ -29522,8 +29522,8 @@ fi done -LUA_CFLAGS=-I\$(top_srcdir)/dependencies/lua-5.1/src -LUA_LIBS=\$(top_builddir)/dependencies/lua-5.1/src/liblua.a +LUA_CFLAGS=\$(shell pkg-config lua5.1 --cflags) +LUA_LIBS=/usr/lib/liblua5.1.a LUA_AS_DEPENDENCY=$LUA_LIBS Notice how the LUA_CFLAGS in the two files differ? If anything triggers a rebuild of configure the working chunk in the configure file is replaced by the broken chunk from configure.ac and then the build fails with: /bin/sh ../../libtool --preserve-dup-deps --tag=CC --mode=compile x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../../server/scripting -I../.. -I../../../utility -I../../../common -I../../../server -I../../../dependencies/tolua-5.1/include -DLOCALEDIR=\/usr/share/locale\ -DDEFAULT_DATA_PATH=\.:data:~/.freeciv:/usr/share/games/freeciv\ -Wall -g -O2 -MT api_gen.lo -MD -MP -MF .deps/api_gen.Tpo -c -o api_gen.lo ../../../server/scripting/api_gen.c libtool: compile: x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../../server/scripting -I../.. -I../../../utility -I../../../common -I../../../server -I../../../dependencies/tolua-5.1/include -DLOCALEDIR=\/usr/share/locale\ -DDEFAULT_DATA_PATH=\.:data:~/.freeciv:/usr/share/games/freeciv\ -Wall -g -O2 -MT api_gen.lo -MD -MP -MF .deps/api_gen.Tpo -c ../../../server/scripting/api_gen.c -o api_gen.o In file included from ../../../server/scripting/api_gen.c:6: .../../../dependencies/tolua-5.1/include/tolua.h:33:17: error: lua.h: No such file or directory .../../../dependencies/tolua-5.1/include/tolua.h:34:21: error: lauxlib.h: No such file or directory The -I /usr/include/lua5.1 is now missing. MfG Goswin PS: Please consider asking for a freeze exception for this. The problem might occur if there has to be a security fix for freeciv and then the security team has to figure it all out again. -- 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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598226: clean deletes .pc dir breaking quilt
Package: freeciv Version: 2.2.2-1 Severity: normal Hi, I spotted another little bug. This doesn't prevent the source from building but it is damn anoying working with it. The debian/rules clean target removes the .pc dir while the quilt series is still applied. I assume this is a left over from before the package was changed to 3.0 (quilt) format. Attached patch removes the faulty line. 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 --- debian/rules~ 2010-08-28 23:26:51.0 +0200 +++ debian/rules2010-09-27 19:49:25.0 +0200 @@ -97,7 +97,6 @@ -rm -f config.cache config.sub config.guess -rm -f bootstrap/config.sub bootstrap/config.guess -rm -rf build-stamp build-xaw3d build-gtk build-sdl build-server - -rm -rf .pc/ dh_clean
Bug#598251: Warn about leftover *.debhelper.log and *.substvars
Package: lintian Version: 2.4.3 Severity: wishlist Hi, when a binary package is removed from debian/control then dh_clean will not remove some of the generated files from the last build. Namely the package.debhelper.log and package.substvars. There are probably more (package.postinst.debhelper?) but those are the only two I had in my case. Please warn if any of those generated files exist in a source package. 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 lintian depends on: ii binutils 2.20.1-14 The GNU assembler, linker and bina ii diffstat 1.53-1produces graph of changes introduc ii dpkg-dev 1.15.8.5 Debian package development tools ii file 5.04-5Determines file type using magic ii gettext0.18.1.1-2GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.1.1-2.1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.55-1module to manipulate and access UR ii locales2.11.2-5 Embedded GNU C Library: National L ii man-db 2.5.7-4 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-14 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch2.20.1-14 Binary utilities that support mult ii libtext-template-perl 1.45-1 Text::Template perl module ii man-db2.5.7-4on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: unblock: ia32-libs/20100914
FS: Can you check your source tree and remove debian/lib32gcc1* (see below) and then upload 20100927 from git please? Julien Cristau jcris...@debian.org writes: On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote: Please unblock package ia32-libs and ia32-libs-gtk Why does this use debian/README.Source instead of debian/README.source as policy recommends? Typo. Fixed in git. Why does this include the xorg package, which is everything but a library? It contains xorg because one of the deb packages included lists it as source: Package: libglu1-xorg Architecture: all Version: 1:7.5+7 Source: xorg Description: transitional package for Debian etch This package is provided to smooth upgrades from Debian 3.1 (sarge) to Debian etch. It may be safely removed from your system. I guess that can be savely removed. Makes no sense in ia32-libs. :) The real package (libglu1-mesa) is already included. Fixed in git. Why does this build-depend on a bunch of biarch libs, since aiui it's not actually building anything? It does run dpkg-shlibdeps to get the right versioned depends on the biarch libs. Without the libs dpkg-shlibsdeps complains and the depends would be incomplete. So those are intentional and required. Note that on ia64 it depends on ia32-libs-core for the same reason. The source package includes a bunch of debhelper log files and substvars for lib32gcc1. Not from my side. Must be cruft left from an earlier version on Fredericks side. Seems that debhelper only removes those files for packages in debian/control and they aren't tracked in git. So nothing would have removed them when updating the source with git pull. Filing bug against lintian to warn about them. the fix-la thing is made of ugly.. Seems to work and is simple. I didn't want to write a whole *.la file parser just to change the libdir. Patch welcome if you know something better. Cheers, Julien Updating the package (from 20100919) also updates: New source isdnutils 1:3.9.20060704+dfsg.1-3 New source openldap 2.4.23-6 [ isdnutils (1:3.9.20060704+dfsg.1-3) unstable; urgency=low ] * QA upload. * Replace tcl8.3-dev Build Dependency with tcl-dev (#590651). [ openldap (2.4.23-6) unstable; urgency=high ] * Check for an empty directory to prevent an rm -f /*. (#597704) MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598019: [Pkg-ia32-libs-maintainers] Bug#598019: libs.so.6 error
Heiko Ernst heiko.er...@aschershain.de writes: Package: ia32-libs Version: 20090808 I use the fold...@home projekt http://folding.stanford.edu/ and when i will istall the client it output the error: fah6: relocation error: /lib/libnss_files.so.2: symbol __rawmemchr, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference I am using Debian Squeeze, kernel 2.5.32-5 Please update and report if the bug still exists in the current squeeze version. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597986: [Pkg-ia32-libs-maintainers] Bug#597986: ia32-libs: fails to install
reassign 597986 libgl1-nvidia-alternatives-ia32 thanks Diego Lopez Leon dieguit...@gmail.com writes: Package: ia32-libs Version: 20100919 Severity: important Here is the output when manually try to install the package sandia:~# dpkg -i /var/cache/apt/archives/ia32-libs_20100919_amd64.deb (Reading database ... 325361 files and directories currently installed.) Unpacking ia32-libs (from .../ia32-libs_20100919_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/ia32-libs_20100919_amd64.deb (--install): unable to create `/usr/lib32/nvidia/diversions/libGL.so.1.2.dpkg-new' (while processing `./usr/lib32/libGL.so.1.2'): No such file or directory dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/ia32-libs_20100919_amd64.deb sandia:~# I think there is a typo somewhere b/c the dot prefixing ./usr/lib32/libGL.so.1.2 but I don't know where it could be. No, the ./ there is just an artefact from the process. And ia32-libs does no diverting so I believe this is a side effect of something else. I think the problem is that /usr/lib32/nvidia/diversions/ does not exist while there still is a diversion for /usr/lib32/libGL.so.1.2 to that place. Please run the following commands and send the output to this bug: dpkg -S libGL.so.1.2 ls -lhd /usr/lib32 ls -lhd /usr/lib32/nvidia ls -lhd /usr/lib32/nvidia/diversions ls -lh /usr/lib32/nvidia/diversions I'm reassigning the bug to nvidia on the above assumption. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596899: unblock: ia32-libs/20100914
Hi, ia32-libs has been updated again to fix an unreported RC bug (uninstallable on ia64), a simple bug and to cover package updates in squeeze: --- ia32-libs (20100919) unstable; urgency=high * Make dependency on lib32bz2-1.0 [amd64] only. * Add gcc-3.3 1:3.3.6ds1-20 for libstdc++5 (Closes: #597306) * Packages updated [ openldap (2.4.23-5) unstable; urgency=high ] [ Steve Langasek ] * High-urgency upload for RC bugfix. * debian/slapd.scripts-common: fix gratuitous (and wrong) use of grep in get_suffix(), which causes us to incorrectly parse any slapd.conf that uses tabs instead of spaces. #595672. * debian/slapd.init, debian/slapd.scripts-common: when $SLAPD_CONF is not set in /etc/default/slapd, we should always set a default value, giving precedence to slapd.d and falling back to slapd.conf. Users who don't want to use an existing slapd.d should point at slapd.conf explicitly. #594714, #596343. * debian/slapd.init: 'invoke-rc.d slapd stop' should not fail due to the absence of a slapd configuration; we should still exit 0 so that the package can be removed gracefully. #596100. * drop build-conflicts with libssl-dev; we explicitly pass --with-tls=gnutls to configure, so there's no risk of a misbuild here. * debian/slapd.default: now that we have a sensible default behavior in both slapd.init and the maintainer scripts, leave SLAPD_CONF empty to save pain later. * debian/slapd.scripts-common: ... and do the same in migrate_to_slapd_d_style, we just need to comment out the user's previous entry instead of blowing it away. * debian/slapd.scripts-common: call get_suffix in a way that lets us separate responses by newlines, to properly handle the case when a DN has embedded spaces. Introduces a few more stupid fd tricks to work around possible problems with debconf. #595466. * debian/slapd.scripts-common: when parsing the names of includes, handle double-quotes and escape characters as described in slapd.conf(5). #595784. * debian/slapd.scripts-common, debian/slapd.postinst: on upgrade from versions = 2.4.23-4, explicitly grant access to cn=Subschema, which otherwise is blocked by our added olcAccess settings. #596326. * debian/slapd.init.ldif: set the acl in the default LDIF for new installs, too. * Likewise, grant access to dn.exact= so that base dn autodiscovery works as intended. #596049. * debian/slapd.init.ldif: synchronize our behavior on new installs with that on upgrades, avoiding the non-standard cn=localroot,cn=config. * debian/slapd.scripts-common: don't run the migration code if slapd.d already exists. #593965. [ Matthijs Mohlmann ] * Remove upgrade_supported_from_backend, implemented patch from Peter Marschall pe...@adpm.de to automatically detect if an upgrade is supported. (#594712) [ Peter Marschall ] * debian/slapd.init: correctly set the slapd.conf argument even when SLAPD_PIDFILE is non-empty in /etc/default/slapd. #593880. * debian/slapd.scripts-common: pass -g to slapadd/slapcat, so that subordinate databases aren't incorrectly included in the dump/restore of the parent database. #594821. [ pam (1.1.1-6) unstable; urgency=low ] * Updated debconf translations: - Swedish, thanks to Martin Bagge brot...@bsnet.se (#575875) [ pam (1.1.1-5) unstable; urgency=low ] * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit interface. #579402. * Update debian/source.lintian-overrides to clean up some spurious warnings. * Bump Standards-Version to 3.9.1. * Add lintian overrides for a few more spurious warnings. * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for compatibility when it's not already set. #552043. * debian/local/pam-auth-update: Don't try to pass embedded newlines to debconf; backslash-escape them instead and use CAPB escape. * debian/local/pam-auth-update: sort additional module options before writing them out, so that we don't wind up with a different config file on every invocation. Thanks to Jim Paris j...@jtan.com for the patch. #594123. [ sane-backends (1.0.21-4) unstable; urgency=low ] * debconf translations: + it.po: courtesy of Luca Monducci (#593722). [ xorg (1:7.5+7) unstable; urgency=low ] [ Julien Cristau ] * Nuke x11-common's Conflicts. This was needed for upgrades from the monolith, which aren't relevant anymore. * Also drop Pre-Depends on debconf. The debconf interaction in x11-common.preinst was removed in 1:7.4+2. * Drop versioned build-dep on dpkg 1.7.0. Even woody had that.. * Drop x11-common Depends on debianutils 1.13. That was also in woody. * Add xserver-xorg-video-geode to -all on i386 (#567909). [ Cyril Brulebois ] * Add myself to Uploaders. * Update Debian po files by running
Bug#597030: Fails to start raids after growing
martin f krafft madd...@debian.org writes: also sprach Goswin von Brederlow goswin-...@web.de [2010.09.17.0943 +0200]: Must have. Something created the file initially and I only copied and edited existing entries when I added/removed/changed a raid device. But the initial file is quite old. Recreate it? If this is a bug, then it was a bug in mkconf back when your file wa written. I can at least confirm mkconf doesn't add it now: # definitions of existing MD arrays ARRAY /dev/md0 UUID=902a1719:24eb3529:e0a928ca:d1346d95 spares=1 ARRAY /dev/md1 UUID=d2c98d14:b463eebb:e0a928ca:d1346d95 ARRAY /dev/md2 UUID=faebec55:77b68d56:e0a928ca:d1346d95 MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597030: Fails to start raids after growing
martin f krafft madd...@debian.org writes: also sprach Goswin von Brederlow goswin-...@web.de [2010.09.16.0222 +0200]: after growing my raids by one disk the /etc/init.d/mdadm-raid refuses to start my raid arrays. The reason for this seems to be that I didn't adjust the num-devices listed in mdadm.conf yet. Correcting the num-devices makes the script work. Why do you have num-devices there? Did mkconf put it there? Must have. Something created the file initially and I only copied and edited existing entries when I added/removed/changed a raid device. But the initial file is quite old. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596841: dpkg-shlibdeps: do not stop on first error
Raphael Hertzog hert...@debian.org writes: severity 596841 wishlist thanks On Tue, 14 Sep 2010, Goswin von Brederlow wrote: So the respective library needs to be added and fetched and everything build again, a somewhat lengthy process. You know you can call dpkg-shlibdeps/dh_shlibdeps on the command line without rebuilding everything? = wishlist only Cheers, Sure I can call it manually. Doesn't help though since that just gives the same error again. The rebuild is needed to get the missing 32bit library in place. The pain that is ia32-libs. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597030: Fails to start raids after growing
Package: mdadm Version: 3.1.4-1+8efb9d1 Severity: normal File: /etc/init.d/mdadm-raid Hi, after growing my raids by one disk the /etc/init.d/mdadm-raid refuses to start my raid arrays. The reason for this seems to be that I didn't adjust the num-devices listed in mdadm.conf yet. Correcting the num-devices makes the script work. Imho the level and num-devices in mdadm.conf should be totaly ignored or be advisory only and only give a warning on mismatch. They should not cause raids to no start. Both values can be changed on the fly and it is easy to forget to change them in mdadm.conf (and the initrd) or the system may crash before one can change them leaving the user stranded. I consider it a real bug that no warning is given about the mismatch and failure to start a listed raid. And wishlist to ignore the values and start the raids by UUID alone. MfG Goswin -- Package-specific info: --- mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST frosties MAILADDR mrvn ARRAY /dev/md0 level=raid1 num-devices=2 UUID=902a1719:24eb3529:e0a928ca:d1346d95 ARRAY /dev/md1 level=raid5 num-devices=6 UUID=d2c98d14:b463eebb:e0a928ca:d1346d95 ARRAY /dev/md2 level=raid5 num-devices=7 UUID=faebec55:77b68d56:e0a928ca:d1346d95 --- /etc/default/mdadm INITRDSTART='/dev/md0' AUTOSTART=true AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS=--syslog VERBOSE=false --- /proc/mdstat: Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md1 : active raid5 sdg2[0] sdf2[1] sde2[6] sdb1[2] sdc1[3] sdd1[4] sda1[5] 8790815616 blocks level 5, 64k chunk, algorithm 2 [7/7] [UUU] bitmap: 0/11 pages [0KB], 65536KB chunk md2 : active raid5 sdl1[0] sdj1[1] sdk1[2] sdi1[6] sdh1[3] sdg4[4] sdf4[5] sde4[7] 1367508352 blocks level 5, 64k chunk, algorithm 2 [8/8] [] bitmap: 0/2 pages [0KB], 65536KB chunk md0 : active raid1 sdg1[0] sde1[2](S) sdf1[1] 50002176 blocks [2/2] [UU] bitmap: 1/191 pages [4KB], 128KB chunk unused devices: none --- /proc/partitions: major minor #blocks name 80 1465138584 sda 81 1465136001 sda1 8 16 1465138584 sdb 8 17 1465136001 sdb1 8 32 1465138584 sdc 8 33 1465136001 sdc1 8 48 1465138584 sdd 8 49 1465136001 sdd1 8 64 1953514584 sde 8 65 50002281 sde1 8 66 1465136032 sde2 8 67 243015255 sde3 8 68 195358432 sde4 8 80 1953514584 sdf 8 81 50002281 sdf1 8 82 1465136032 sdf2 8 83 243015255 sdf3 8 84 195358432 sdf4 8 96 1953514584 sdg 8 97 50002281 sdg1 8 98 1465136032 sdg2 8 99 243015255 sdg3 8 100 195358432 sdg4 90 50002176 md0 25207340032 dm-0 25212424832 dm-1 2522 33554432 dm-2 25232097152 dm-3 2524 262144 dm-4 8 112 195360984 sdh 8 113 195358401 sdh1 8 128 195360984 sdi 8 129 195358401 sdi1 8 160 195360984 sdk 8 161 195358401 sdk1 8 176 195360984 sdl 8 177 195358401 sdl1 8 144 199148544 sdj 8 145 199141708 sdj1 92 1367508352 md2 91 8790815616 md1 --- LVM physical volumes: PV VG Fmt Attr PSize PFree /dev/md0 rlvm2 a- 47.68g 4.12g --- mount output /dev/r/root on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) tmpfs on /tmp type tmpfs (rw) /dev/mapper/r-usr on /usr type ext3 (rw) /dev/mapper/r-var on /var type ext3 (rw) /dev/mapper/r-home on /home type ext3 (rw) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) nfsd on /proc/fs/nfsd type nfsd (rw) --- initrd.img-2.6.32-debian-xen-1: no initrd.img-2.6.32-debian-xen-1 found. --- /proc/modules: --- /var/log/syslog: --- volume detail: /dev/sda is not recognised by mdadm. /dev/sda1: Magic : a92b4efc Version : 0.90.00 UUID : d2c98d14:b463eebb:e0a928ca:d1346d95 (local to host frosties) Creation Time : Thu Feb 18 18:24:00 2010 Raid Level : raid5 Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB) Array Size : 8790815616 (8383.58 GiB 9001.80 GB) Raid Devices : 7 Total Devices : 7 Preferred Minor : 1 Update Time : Thu Sep 16 02:05:32 2010 State : clean Internal Bitmap : present Active Devices : 7 Working Devices : 7 Failed Devices : 0 Spare Devices : 0 Checksum : d1a19abc - correct Events : 234986 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this
Bug#596841: dpkg-shlibdeps: do not stop on first error
Package: dpkg-dev Version: 1.15.8.4 Severity: normal File: /usr/bin/dpkg-shlibdeps Hi, when we run dpkg-shlibdeps on ia32-libs* we get an error like this: dpkg-shlibdeps: error: couldn't find library libcanberra.so.0 needed by debian/ia32-libs-gtk/usr/lib32/gtk-2.0/modules/libcanberra-gtk-module.so (ELF format: 'elf32-i386'; RPATH: ''). So the respective library needs to be added and fetched and everything build again, a somewhat lengthy process. Then dpkg-shlibdeps fails again, this time with: dpkg-shlibdeps: error: couldn't find library libvorbisfile.so.3 needed by debian/ia32-libs-gtk/usr/lib32/gtk-2.0/modules/libcanberra-gtk-module.so (ELF format: 'elf32-i386'; RPATH: ''). It would be extremly helpfull if dpkg-shlibdeps would continue after the first error and print all errors it can detect before failing. 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 dpkg-dev depends on: ii base-files5.7Debian base system miscellaneous f ii binutils 2.20.1-10 The GNU assembler, linker and bina ii bzip2 1.0.5-4high-quality block-sorting file co ii libdpkg-perl 1.15.8.4 Dpkg perl modules ii make 3.81-8 An utility for Directing compilati ii patch 2.6-2 Apply a diff file to an original ii xz-utils 4.999.9beta+20100527-1 XZ-format compression utilities Versions of packages dpkg-dev recommends: ii build-essential 11.5 Informational list of build-essent ii fakeroot 1.14.4-1 Gives a fake root environment ii gcc [c-compiler] 4:4.4.4-2 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.4-5The GNU C compiler ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii gpgv 1.4.10-4 GNU privacy guard - signature veri pn libalgorithm-merge-perl none (no description available) Versions of packages dpkg-dev suggests: ii debian-keyring2010.06.08 GnuPG (and obsolete PGP) keys of D -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596848: emul/ia32-linux is no longer used
Package: lintian Version: 2.4.3 Severity: normal File: /usr/share/lintian/data/shared-libs/ldconfig-dirs The old /emul/ia32-linux/... directories are no longer used and all files have be transitioned to /lib32 and /usr/lib32. Ldconfig won't look in there anymore. 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 lintian depends on: ii binutils 2.20.1-10 The GNU assembler, linker and bina ii diffstat 1.47-1produces graph of changes introduc ii dpkg-dev 1.15.8.4 Debian package development tools ii file 5.04-2Determines file type using magic ii gettext0.18.1.1-1GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.54-1module to manipulate and access UR ii locales2.11.1-3 Embedded GNU C Library: National L ii man-db 2.5.7-3 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-14 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch2.20.1-10 Binary utilities that support mult ii libtext-template-perl 1.45-1 Text::Template perl module ii man-db2.5.7-3on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596498: sources.list: add option to mark unsigned (local) repository as trusted
Ansgar Burchardt ans...@43-1.org writes: tags 596498 + patch thanks It would be nice if a repository could be marked as trusted in the sources.list. This would make it easier to use local repositories with, for example, pbuilder without having to generate a PGP key, signing the repository and finally importing the key into apt, see also [1]. Attached is a patch to add a [trusted=1] option to sources.list. When present, the source is regarded as trusted even without a Release.gpg. Documentation of this feature is still missing. I did the following testing using apt 0.8.3 with the patch applied: Installing from an unsigned (or signed with unknown key) repository causes warning when [trusted=0] or no option is given in sources.list; installing from an unsigned (or signed with unknown key) repository does not warn when [trusted=1] is given in sources.list. I would have used 'trust=always', 'trust=key' (default) and 'trust=never'. But otherwise the patch looks good to me. Note that apt-get update still warns about unknown signatures even when [trusted=1] is given for the source. I do not think this is harmful as the option is mainly intended for unsigned (local) repositories anyway. I think that is a good idea. Consider the scenario that you have an unsigned repository and later a signature is added. You then see the warning about the new signature and can add the right key instad of continuing to use the source untrusted. Regards, Ansgar MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596097: Please let apt reduce the amount of spam we get
David Kalnischkies kalnischkies+deb...@gmail.com writes: tag 596097 patch thanks 2010/9/9 Carsten Hey cars...@debian.org: * David Kalnischkies [2010-09-09 15:25 +0200]: 2010/9/9 Carsten Hey cars...@debian.org: If we (or rather the backport.debian.org ftpmasters, I'm just trying to convince you to provide the apt feature that is a prerequisite for this) No need to convenience me (as long as you don't want to trick me into writing the patch ;) ) I am still not completely convinced that i will like this default behavior for backports, but thats not my cup of tea to decide and i can pin it differently anyway i am a bit more surprised that nobody feels the urgent need to do the work as it was a relatively low-hanging fruit and faster to implement than reading the complete thread especially as everybody likes it here and on d-release beside the nobody anyway, here it is, a more or less untested (in terms of real world usage) patch for APT to pin sources with ButAutomaticUpgrades with 100. NotAutomatic needs to be present for compatibility anyway so the sense is not completely lost and a bit easier to understand then NotAutomaticButUpgrades -- but a better name can always be suggest (until it is too late of course), maybe someone wants to do at least this Will be around for comment at least until 0.8.4 migration i guess Wouldn't it make more sense to have DefaultPin: 100 Or do you want to invent a new tag for every pin value that might be usefull for an archive to set? In combination with this (or in place of this) the pin should also be settable in sources.list: deb [pin=100] http://backports.debian.org/debian squeeze main MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596922: Wine should Build-Depend: ia32-libs-dev [amd64 kfreebsd-amd64]
Package: wine Version: 1.0.1-3 Severity: normal Hi, with ia32-libs 20100914 the ia32-libs-dev package has been reintroduced and contains the correct *.so links, *.la files and static libraries directly from the respective -dev packages. That means the links won't break on every update anymore. I compiled wine against ia32-libs-dev 20100914 and ia32-libs-gtk 20100914 successfully. I'm pushing to get that version into squeeze but the Release team might not accept it. Either way the wine in unstable should Build-Depend on the ia32-libs-dev package from now on. A similar split for ia32-libs-gtk (giving ia32-libs-gtk-dev) is planed but not yet done to avoid the NEW processing delay. The .so links are autogenerated already though, just still in ia32-libs-gtk itself. 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 wine depends on: ii libwine-alsa 1.0.1-3Windows API implementation - ALSA ii libwine-cms 1.0.1-3Windows API implementation - color ii libwine-gl1.0.1-3Windows API implementation - OpenG ii libwine-gphoto2 1.0.1-3Windows API implementation - camer ii libwine-ldap 1.0.1-3Windows API implementation - LDAP ii libwine-print 1.0.1-3Windows API implementation - print ii libwine-sane 1.0.1-3Windows API implementation - scann ii wine-bin 1.0.1-3Windows API implementation - binar ii wine-utils1.0.1-3Windows API implementation - utili Versions of packages wine recommends: pn ttf-liberationnone (no description available) Versions of packages wine suggests: pn avscan | klamav | clamav none (no description available) pn binfmt-supportnone (no description available) pn ttf-mscorefonts-installer none (no description available) pn winbind none (no description available) pn wine-doc none (no description available) Versions of packages libwine depends on: ii ia32-libs 20100914 ia32 shared libraries for use on a ii libc6-i3862.11.2-5 Embedded GNU C Library: 32-bit sha -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543448: Reassigning 543448 to lib32asound2-plugins
Hi, all lib32* package must be self contained, they can not Build-Depends on ia32-libs. The packages were specifically split from ia32-libs because they are Build-Depends of other things and must not suffer the horribly long update cycles of ia32-libs. I'm not sure is lib32asound2-plugins falls under that category but you joined the club of building it natively. This is further complicated that on ia64, which also has 32bit x86 runtime support, there is no 32bit compiler. All lib32* packages have to be provided there from ia32-libs-core (ia32-libs in stable). If one of the lib32* package would depend on ia32-libs that would create a dependency loop. It might be best to stop building lib32asound2-plugins and instead include it in ia32-libs or ia32-libs-gtk. Other than the missing libs I do see some others that already create a dependency cycle. If so give us a shout asap so we might still squeeze it into squeeze. MfG Goswin PS: libgdbm.so.3 was added to ia32-libs already and I've added libwrap0 for the next upload. But I would rather avoid the depends loop. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543448: 'Please add libgdbm3 and libwrap0'
Hi, small corrction: lrwxrwxrwx 1 root root 16 Sep 13 22:31 /lib32/libwrap.so.0 - libwrap.so.0.7.6 -rw-r--r-- 1 root root 31K May 23 16:45 /lib32/libwrap.so.0.7.6 Libwrap0 already is in ia32-libs too. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540027: #540027 ia32-libs-dev_20090804_ia64.deb completly useless
Hi, another note to myself. Ia32-libs-dev is back for amd64. Still should remove it for ia64 I think. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532986: #532986 Amazon MP3 downloader needs several 32 bits libraries
Hi, where can one download the Amazon.com MP3 downloader? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596426: [Pkg-ia32-libs-maintainers] Bug#596426: But I need to watch Maru!
Thomas Themel tho...@themel.com writes: Hi, could you point to a place to get the updated source package NOW, for those of us who can't live without their cat videos for an entire weekend? I don't mind building myself. ciao, -- [*Thomas Themel*] Wir muessen fuer die Freiheit planen und nicht nur fuer die [extended contact] Sicherheit, auch wenn vielleicht aus keinem anderen Grund [info provided in] als dem, dass nur die Freiheit die Sicherheit sichern kann. [*message header*] - Karl Popper, Die offene Gesellschaft und ihre Feinde Vcs-Browser: http://git.debian.org/?p=pkg-ia32-libs/ia32-libs-gtk.git Vcs-Git: git://git.debian.org/git/pkg-ia32-libs/ia32-libs-gtk.git MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596298: Please add DEB_HOST_ABI / DEB_BUILD_ABI
Package: dpkg-dev Version: 1.15.8.4 Severity: wishlist File: /usr/bin/dpkg-architecture Hi, recent discussions about multiarch, cross-compiling and the increasing number of ABIs used in ports have raised the issue that the GNU tripplet is not sufficiently unique to distinguish between different ABIs. This makes it problematic to use /usr/lib/$(DEB_HOST_GNU_TYPE)/ as libdir when compiling for multiarch or /usr/lib/pkg/$(DEB_HOST_GNU_TYPE)/ when building a cross-compiling tool. So something new is needed that is truely unique for each ABI. What that eventually is doesn't matter as long as it is unique. On the other hand the ABI we compile for is verry specific to each port and should be defined in exactly one place so there can be no conflicting values. It should be provided by dpkg-architecture. My wish is to add DEB_HOST_ABI / DEB_BUILD_ABI to the dpkg-architecture output and for now set it equal to DEB_HOST_GNU_TYPE / DEB_BUILD_GNU_TYPE. This is sufficient for the official release architectures (and is what our toolchain and ld.so uses and unlikely to change) while it fails some of the extra ports (which then can provide a more unique value). It would be best to include this in squeeze so that sources using it post squeeze don't need a versioned Build-Depends on dpkg-dev, which simplifies backporting any such sources as well. MfG Goswin PS: This is analog to the recently added DEB_*_ARCH_BITS that can be used for the biarch libdir [/usr]/lib/$(DEB_HOST_ARCH_BITS)/. -- 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 dpkg-dev depends on: ii base-files5.7Debian base system miscellaneous f ii binutils 2.20.1-10 The GNU assembler, linker and bina ii bzip2 1.0.5-4high-quality block-sorting file co ii libdpkg-perl 1.15.8.4 Dpkg perl modules ii make 3.81-8 An utility for Directing compilati ii patch 2.6-2 Apply a diff file to an original ii xz-utils 4.999.9beta+20100527-1 XZ-format compression utilities Versions of packages dpkg-dev recommends: ii build-essential 11.5 Informational list of build-essent ii fakeroot 1.14.4-1 Gives a fake root environment ii gcc [c-compiler] 4:4.4.4-2 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.4-5The GNU C compiler ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii gpgv 1.4.10-4 GNU privacy guard - signature veri pn libalgorithm-merge-perl none (no description available) Versions of packages dpkg-dev suggests: ii debian-keyring2010.06.08 GnuPG (and obsolete PGP) keys of D -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594179: dpkg armhf patch acceptance status?
Steve Langasek vor...@debian.org writes: On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote: This also causes issue with not being able to have installed two cross-toolchains for say armel and armhf as they share triplet, although you can use the armel toolchain with few options to build for armhf, but then you'd need to specify those as part of the CC variable. Also that also happens with biarch, you can produce i386 binaries from an x86_64 toolchain, yet they both have their own triplet. I'm just wondering if this is also the case for mips triarch, or do those have each their own triplet, and is only arm that has this issue? mips have distinct triplets for each of their archs, yes. Anyway, ideally I'd rather see this addressed by giving armhf a real triplet, which would also make multiarch life way easier as there'd not be any need to define an artificial set of neutral architecture names to be able to place objects in the file system. I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Cheers, Note that uclibc also suffers this problems. x86_64-linux-uclibc is in no way unique as different uclibc compile options create different ABIs all with the same tripplet. I filed a wishlist bug against dpkg-architecture to please provide DEB_HOST_ABI / DEB_BUILD_ABI and to start giving that as DEB_HOST_GNU_TYPE / DEB_BUILD_GNU_TYPE initialy. Ports where this is insufficient can then extend the table to give a unique value. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596201: Bad behaviour with symlinks and -u
Package: qiv Version: 2.1~pre12-5a0.mrvn.1 Severity: normal Hi, I tried running qiv -u . and noticed that qiv behaves badly with symlinks, esspecially symlinks that create a cycle: open(./chroot/sid-clean/lib64/modules/2.6.31.6-xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/modules/2.6.31.6--xen-2010.02.18/build/debian/linux-image-2.6.31.6--xen-2010.02.18/lib/mod ules/2.6.31.6--xen-2010.02.18/build/net, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC unfinished ... Maybe -u should not follow symlinks, only follow symlinks that point outside the search directories or simply don't scan directories it has already scanned (checked by inode/device number). If you think the default behviour is ok then please add something like a --no-symlink option. 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 qiv depends on: ii gdk-imlib11 1.9.15-8imaging library for use with gtk ii libc62.11.1-3Embedded GNU C Library: Shared lib ii libglib1.2ldbl 1.2.10-19 The GLib library of C routines ii libgtk1.21.2.10-18.1 The GIMP Toolkit set of widgets fo ii libx11-6 2:1.3.3-3 X11 client-side library ii libxinerama1 2:1.1-3 X11 Xinerama extension library qiv recommends no packages. qiv suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596238: status/package.php is confused about package status
Package: buildd.debian.org
Severity: normal
Hi,
I requested a binNMU of ia32-libs 20100908 for ia64 because the
manually build package is broken.
Now when I check on the progress of the binNMU I get the following:
==
% lynx --dump
https://buildd.debian.org/status/package.php?p=ia32-libssuite=unstable;
Debian Package Auto-Building
Buildd status for package(s): ia32-libs
[1]PTS - [2]Changelog - [3]Bugs - [4]packages.d.o
Package(s): ia32-libs___ Suite: [unstable___] Go
[ ] Compact mode
Architecture Version Status ForBuildd State Misc Logs
[6]amd64 20100908 Installed libs:optional no log
[11]ia64 20100908 Installed [12]caballero libs:optional no log
==
The wanna-build database contains this entry:
libs/ia32-libs_20100908: Installed by buildd_ia64-caballero
[optional:out-of-date:calprio{51}:days{1}]
Previous state was Built
State changed at 2010-09-08 13:19:31.793274
Previous state Built left ago
==
Which can't be right. The installed package is the broken one that was
uploaded. caballero should never have build the package and if it did
it did not upload it.
Shouldn't the database show this?
libs/ia32-libs_20100908: Built by buildd_ia64-caballero
[optional:out-of-date:binNMU{1}:calprio{51}:days{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.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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596246: Building with sudo looses DEB_BUILD_OPTIONS
Package: devscripts Version: 2.10.64 Severity: normal File: /usr/bin/debuild Hi, I have a package that supports DEB_BUILD_OPTIONS. When I build it with DEB_BUILD_OPTIONS=foo debuild -rfakeroot then everything works as expected. But when I build with DEB_BUILD_OPTIONS=foo debuild -rsudo The binary target fails because DEB_BUILD_OPTIONS is unset. It would be nice if debuild would preserve the environment across the sudo call by seting the standard variables like DEB_BUILD_OPTIONS in the call. MfG Goswin -- Package-specific info: --- /etc/devscripts.conf --- DEBUILD_ROOTCMD=fakeroot DEBUILD_PREPEND_PATH=/usr/lib/ccache --- ~/.devscripts --- Not present -- 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 devscripts depends on: ii dpkg-dev 1.15.8.4 Debian package development tools ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii perl 5.10.1-14 Larry Wall's Practical Extraction Versions of packages devscripts recommends: ii at3.1.12-1 Delayed job execution and batch pr ii bsd-mailx [mailx] 8.1.2-0.20100314cvs-1 simple mail user agent ii curl 7.20.1-2 Get a file from an HTTP, HTTPS or ii cvs 1:1.12.13-12 Concurrent Versions System ii dctrl-tools 2.14 Command-line tools to process Debi ii debian-keyring [d 2010.06.08 GnuPG (and obsolete PGP) keys of D ii dupload 2.6.6 utility to upload Debian packages ii elinks [www-brows 0.12~pre5-2advanced text-mode WWW browser ii equivs2.0.8 Circumvent Debian package dependen ii fakeroot 1.14.4-1 Gives a fake root environment ii git [git-core]1:1.7.1-1 fast, scalable, distributed revisi ii git-core 1:1.7.1-1 fast, scalable, distributed revisi ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii iceape-browser [w 2.0.4-2Iceape Navigator (Internet browser ii iceweasel [www-br 3.5.9-3Web browser based on Firefox ii libauthen-sasl-pe 2.1500-1 Authen::SASL - SASL Authentication ii libcrypt-ssleay-p 0.57-2 Support for https protocol in LWP pn libjson-perl none (no description available) ii libparse-debcontr 2.005-2Easy OO parsing of Debian control- ii libsoap-lite-perl 0.712-1Perl implementation of a SOAP clie ii libterm-size-perl 0.2-4+b1 Perl extension for retrieving term ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl 1.54-1 module to manipulate and access UR ii libwww-perl 5.836-1Perl HTTP/WWW client/server librar pn libyaml-syck-perl none (no description available) ii lintian 2.4.2 Debian package checker ii lsb-release 3.2-23.1 Linux Standard Base version report ii lynx-cur [www-bro 2.8.8dev.3-3 Text-mode WWW Browser with NLS sup ii lzma 4.43-14Compression method of 7z format in ii mailx 1:20081101-2 Transitional package for mailx ren ii man-db2.5.7-3on-line manual pager ii mercurial 1.5.2-1scalable distributed version contr ii openssh-client [s 1:5.5p1-4 secure shell (SSH) client, for sec ii patch 2.6-2 Apply a diff file to an original ii patchutils0.3.1-2Utilities to work with patches ii sensible-utils0.0.4 Utilities for sensible alternative ii strace4.5.20-2 A system call tracer ii subversion1.6.11dfsg-1 Advanced version control system ii unzip 6.0-4 De-archiver for .zip files ii w3m [www-browser] 0.5.2-4WWW browsable pager with excellent ii wdiff 0.6.3-1Compares two files word by word ii wget 1.12-2 retrieves files from the web ii xemacs21-nomule [ 21.4.22-3 highly customizable text editor -- ii xz-utils 4.999.9beta+20100527-1 XZ-format compression utilities Versions of packages devscripts suggests: ii build-essential 11.5 Informational list of build-essent pn cvs-buildpackage none (no description available) pn devscripts-el none (no description available) ii gnuplot
Bug#596238: status/package.php is confused about package status
Kurt Roeckx k...@roeckx.be writes: On Thu, Sep 09, 2010 at 05:38:21PM +0200, Goswin von Brederlow wrote: Package: buildd.debian.org Severity: normal Hi, I requested a binNMU of ia32-libs 20100908 for ia64 because the manually build package is broken. As far as I can see no binNMU has been done yet. Kurt Which leaves the question why it claims a buildd did build the package when it did not. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595139: apt: multiarch installation chokes on binNMUs
Steve Langasek vor...@debian.org writes: On Thu, Sep 02, 2010 at 02:42:35PM +0200, David Kalnischkies wrote: Hello (again) Simon Richter, 2010/9/1 Simon Richter s...@debian.org: when trying to install a multiarch package that has been binNMUed on one architecture, apt complains about being unable to resolve the implicit conflicts, as the version number is not the same across all architectures. This is really a problem⦠but not only here but in general as at least changelog.Debian.gz will differ (a bit) and can therefore not be shared between the installed packages. So, i guess it is a bug in the MultiarchSpec [0]. (cc'ing Steve Langasek) source:Version is a problem as the source version is not always the same version as the one the binary rebuild is based on - e.g. comerr-dev (bad example, but the first i found) which would have in a binary rebuild e.g. version 2.1-1.41.12-2+b1 while source is e2fsprogs (1.41.12-2)⦠Sorry, it's not a bug in the spec, but an acknowledged limitation. Multi-Arch: same packages *must* be kept in version lockstep across architectures, which means that binNMUs will be of reduced value for such packages. Neither multiarch support nor binNMU support is a hard requirement for packages in the archive. We will probably have to set some rules in policy about what the expected behavior is going forward, and we may want to tune the binNMU implementation in wanna-build to be more friendly to multiarch (or at least to fail gracefully); but ultimately there will be some use cases that just don't work anymore via binNMU, and it may be more straightforward to use sourceful NMUs for these packages. Given that multiarch packages should also be usable for cross-compile that means that any binNMU will have to rebuild ALL architectures of a package. No more binNMUs for just one or two archs or the packges will be uninstallable with the version skews. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596132: nmu: ia32-libs_20090808
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, the build of ia32-libs for ia64 on the recent upload was broken and the dependencies of the package are wrong. This was a problem of the build environment and it should work fine on the buildds. nmu ia32-libs_20100905 . ia64 . -m Rebuild to fix dpkg-shlibs generated dependencies Thanks 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594904: [dget] downloading binary packages is broken
Hi, please make sure this works with the following entries in sources.list: deb http://host/path suite component deb http://host/path dir/ deb [ arch=amd64 ] http://host/path suite component deb [ arch=amd64 ] http://host/path dir/ deb [ arch=armel ] http://host/path suite component deb [ arch=armel ] http://host/path dir/ deb [foo=bar;arch=amd64,armel;key=0x2763452] http://host/path suite component deb [foo=bar;arch=amd64,armel;key=0x2763452] http://host/path dir/ Assuming it runs on amd64 it shouldn't download from the arch=armel entries. Further in Line 277 I would suggest: -$apt = new IO::File(LC_ALL=C apt-cache --all-versions show $package |) +$apt = new IO::File(LC_ALL=C apt-cache --all-versions show $package=$version |) Line 293 should match for ^$ or end of input. Description might not always be the last entry. I can also think of two ways to make this function more robust: 1) Parse apt-get install [--reinstall] --print-uris $package 2) aptitude download $package Last please Recommend or Suggest apt (and aptitude if you use that). MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589504: eventfd manpage should mention EFD_SEMAPHORE
Michael Kerrisk mtk.manpa...@gmail.com writes: tags 589504 fixed-upstream thanks On Sun, Jul 18, 2010 at 12:34 PM, Goswin von Brederlow goswin-...@web.de wrote: Package: manpages-dev Version: 3.24-1 Severity: normal File: /usr/share/man/man2/eventfd.2.gz Hi, the eventfd manpage lists only 2 flags, EFD_NONBLOCK and EFD_CLOEXEC, while there is a thrid flag: EFD_SEMAPHORE. EFD_SEMAPHORE changes the behaviour of eventfd_read() to decrement the count by 1 and return 1 instead of the current count. Please add documentation for this to the manpage. Hello Goswin, This report finally prodded me to do something that had long been on my TODO list. I added the following text for man-pages 3.26: EFD_SEMAPHORE (since Linux 2.6.30) Provide semaphore-like semantics for reads from the new file descriptor. See below. ... * If EFD_SEMAPHORE was not specified and the eventfd counter has a nonzero value, then a read(2) returns 8 bytes containing that value, and the counter's value is reset to zero. * If EFD_SEMAPHORE was specified and the eventfd counter has a nonzero value, then a read(2) returns 8 bytes containing the value 1, and the counter's value is decremented by 1. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ Thanks. Much appreciated. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive
Eugene V. Lyubimkin jac...@debian.org writes: [ sorry for not proper 'mail-reply', used wrong mail address before ] Huh? The presense of Replaces allows the two to be both unpacked. The Repalces specifically disables the file conflict. Replaces is one-way dependency, Breaks is two-way one. If I unpack two packages, one having Breaks+Replaces, in the other order, I will have a file conflict. And a high-level package manager have right to do it, by the definition of Breaks, because slave package is not configured. That was a bug in dpkg that has been fixed a while now I think. Replaces has to be two-way so that unpacking the replaced package after the replacing one does not give a file overwrite error. If you think the issue still exists then please create a unit test in dpkg and file that as seperate bugreport against dpkg. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
David Claughton d...@eclecticdave.com writes: On 13/08/10 17:58, Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: As suggested by Ian on -devel (see attachment), it would be nice to have a way to remove files during unpack of a source package to hide non-free files from our users without stripping them from the original tarball. I also prefer this approach over repacking upstream files so let's implement this feature. I'm pretty sure ftp-master isn't going to allow source packages with non-free content in the main archive regardless of whether that content is hidden on unpack (I certainly wouldn't if I were them), so implementing this is kind of pointless for Debian. Another use-case might be to remove convenience copies of system libraries. Might be useful (e.g. for security reasons) to be able to guarantee that this code isn't being accidentally used by a build (in a way that can be easily checked by a script). Cheers, David. And I ask again: How does that differ from deleting them in debian/rules? Legally that should be the same. And practically you would have the useless files on the initial source unpack but they would be gone when debian/rules is invoked the first time. dpkg-source -x could run the clean target by default to make the files disapear directly. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593238: [Pkg-ia32-libs-maintainers] Bug#593238: ia32-libs: Please wrap long lines in debian/control
Stefano Rivera stef...@rivera.za.net writes: Package: ia32-libs Version: 20090808 Severity: wishlist This package includes some incredibly long lines in debian/control (Conflicts, Replaces). If those lines were wrapped, it'd be easier to read debdiffs involving this package (an issue in Ubuntu). Thanks, SR If you mean what I think you mean they should be replaced with Conflicts: ia32-abi instead. It is on my To-Do to fix the interoperability between ia32-libs and ia32-apt-get again which includes that change. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive
Eugene V. Lyubimkin ext-lyubimkin.eug...@nokia.com writes: Seconded. Specifically, Policy now allows use Breaks, not Conflicts if two packages has a file conflict. I consider it as a regression - a high-level package manager cannot assume anymore that two packages having Breaks can be installed (temporarily) without a file conflict, and IMO the whole purpose of Breaks (as opposed to Conflicts) is defeated. Please not write policy to reflect currently existing problems in some high-level package managers which do wrong thing seeing 'Conflicts+Replaces'. Huh? The presense of Replaces allows the two to be both unpacked. The Repalces specifically disables the file conflict. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
Raphael Hertzog hert...@debian.org writes: Package: dpkg-dev Version: 1.15.8 Severity: wishlist As suggested by Ian on -devel (see attachment), it would be nice to have a way to remove files during unpack of a source package to hide non-free files from our users without stripping them from the original tarball. I also prefer this approach over repacking upstream files so let's implement this feature. To be consistent with other features like debian/source/include-binaries I suggest to use a file named debian/source/remove-files (and not a field in .dsc) but if you have a better name, feel free to suggest it. Cheers, How does that differ (legally, from ftp-masters perspective) from running the clean target? From the users side would it really be so bad if those extra files exist initially after unpacking the source but get removed in debian/rules? MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive
Package: debian-policy Version: 3.8.4.0 Severity: normal Hi, in May there was a discussion about the right use of Breaks or Conflicts as part of Bug#582423, e.g. http://lists.debian.org/debian-ctte/2010/05/msg00012.html Since then I've noticed at least 3 people on #debian-devel asking questions about wether to use Breaks or Conflicts now. Imho the description of Breaks and Conflicts is unclear and contradictory in parts and the use of Replaces+Breaks in 7.6.1 is wrong (breaks when an upgrade is aborted). I think all the needed info is in policy and the above mentioned discussion and now a good word smith is needed to write it up all nice and understandable. Saddly that is not me so consider this a request for help from those of you good with words. 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 debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.5 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589821: (no subject)
Mark Brown broo...@sirena.org.uk writes: On 6 Aug 2010, at 22:18, Thomas Lange wrote: I'm also creating chroots and using NIS. currently I did not run into this bug, but I would like to see it fixed. I did not find other post script that are using killall. Can't you use invoke-rc.d for restarting (and stoping) the service? Or why don't you use something like this? The killall is there to work around issues in older versions that didn't manage to successfully stop the daemon prior to upgrade, it's a stopgap for broken versions of the init script and should do nothing in normal operation. In any case, the freeze has been announced now so I probably won't do any updates until after release. As a side node I can't reproduce this. Maybe it was just a freak occurance that nis died just around the time the cdebootstrap did run and not the killall. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
Petter Reinholdtsen p...@hungry.com writes: That late in the shutdown sequence, I believe all scripts are already well-ordered, but if you find an example where that could happen, we should have a look and fix it. When every script in the archive is ordered, sendsigs get its own sequence number for both runlevel 0 and 6, so I do not believe it is likely to happen. Only when the scripts do have the right dependencies. And they not always do. For example chrony depends only on $local_fs instead of $remote_fs and could be scheduled in parallel with sendsigs. People do get the depends wrong and it would be nice to have an extra level of protection for sendsigs. The reason why I looked into this is that with ubuntus half conversion to upstart sendsigs does run in parallel with other scripts and happily kills them. And I wondered how well Debian is protected from that. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
Petter Reinholdtsen p...@hungry.com writes: [Goswin von Brederlow] Only when the scripts do have the right dependencies. And they not always do. Of course. And buggy packages will give their users problems which hopefully will be reported and fixed by its maintainer. For example chrony depends only on $local_fs instead of $remote_fs and could be scheduled in parallel with sendsigs. I see #590888 is reported (thought its suggestion regarding networking should probably be changed to $network), so this seem to work. People do get the depends wrong and it would be nice to have an extra level of protection for sendsigs. This is another way to say that the boot system should hide bugs in packages, and I believe this to be a bad idea. It should be easy to detect when dependencies would allow scripts to be run in parallel with a specially flaged script, like sendsigs, and report a warning/error automatically. If you have a flag for this. I'm not saying the bug should be hidden. But hoping that someone notices when it happens will not work. The occurance is random and the effect might not even be visible to the user. In 99.99% the bad script might finish before sendigs is run and in 0.01% it blows up. The reason why I looked into this is that with ubuntus half conversion to upstart sendsigs does run in parallel with other scripts and happily kills them. And I wondered how well Debian is protected from that. Right. Suspect we will have similar problems that need to be fixed. :) Happy hacking, -- Petter Reinholdtsen So far it looks good for the software I have installed. But that is just a fraction of all software. Some automatic verification that sendsigs is indeed nevere going to run in parallel with something else would be nice. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
Package: insserv Version: 1.14.0-2 Severity: normal Hi, in Bug 458224, which implements the X-Interactive: true features it was said: At the moment, interactive scripts are listed in /etc/insserv.conf, and these scripts will get a unique boot sequence number to make sure it isn't executed in parallel with other scripts. My /etc/insserv.conf has the following line: interactive glibc udev console-screen keymap keyboard-setup console-setup cryptdisks cryptdisks-early checkfs-loop But: % ls /etc/rc0.d/K02* /etc/rc0.d/K02cryptdisks-early@ /etc/rc0.d/K02sysklogd@ /etc/rc0.d/K02spamassassin@ /etc/rc0.d/K02xend@ Shouldn't cryptdisks-early have a unique boot sequence number on shutdown too? Also I wonder why sendsigs is not listed there too. If that ever runs in parallel with any other script then it will kill the other script. 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 excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#160743: I want a very different autoclean feature
sacrificial-spam-addr...@horizon.com writes: Just to add a voice in opposition to automatic clean, or even automatic autoclean: What I'd like apt to do is keep pristine copies of all packages that have been installed within the last N days. That is, the package file would be kept until N days after the package was uninstalled (e.g. upgraded). That would give me N days to notice any problems and revert the upgrade, without depending on an external web site to archive the package for me. I'd also like an option to automatically download and keep the source package under the same conditions, for GPL compliance reasons. To put in my 2c I would forgo the time limit. Keep every available, installed and the previously installed version. This can be hacked together with a Dpkg::Post-Invoke method that creates a Packages file listing the respective versions and deb file:///path ./ in sources.list. But it's certainly not a clean solution. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590450: ITP: daemonfs -- real time monitoring software
Alessio Treglia ales...@debian.org writes: Package: wnpp Severity: wishlist Owner: Alessio Treglia ales...@debian.org * Package name: daemonfs Version : 1.0 Upstream Author : Giorgio Wicklein g.wickl...@giowisys.com * URL : https://launchpad.net/daemonfs * License : GPL Programming Lang: C++ Description : real time monitoring software DaemonFS is a simple and good looking application that can monitor your files and folders in real time. This tool lets you track modifications to your files. Every time a file gets modified, a notification launched from the tray icon appears. This software may be used for reverse engineering, hard disk usage tracking, software analysis and more. The URL is broken. Any other upstream url? Does daemonfs use inotify? Could it be named differently? DaemonFS makes it sound like a filesystem, like ftpfs or sshfs. The description indicates it is an fs daemon or better fs monitor. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#160743: I want a very different autoclean feature
sacrificial-spam-addr...@horizon.com writes: To put in my 2c I would forgo the time limit. Keep every available, installed and the previously installed version. I thought about that, but it's sometimes not the right thing; I've seen problems with a major new upstream release lead to a flurry of .deb releases, but I end up needing to revert to the old version. (I seem to remember this happening with samba a while ago.) So you update, it fails, you downgrade to the previously installed version. Previously installed, not just previous version. It should keep the installed and the last working version in cache. Even if it's pilot error and I just haven't forward-ported the local configuration properly to the new config file syntax, I can still need to revert to get it working NOW, damn it. On the other hand, I probably don't need the before-previous release of an infrequently-released package. (E.g. filters 2.46, which I installed October '08.) This can be hacked together with a Dpkg::Post-Invoke method that creates a Packages file listing the respective versions and deb file:///path ./ in sources.list. But it's certainly not a clean solution. Thanks for the hint; I might try something like that. I can keep a series of such files and roll them over in cron.weekly or some such. But while that will make apt-get autoclean do the right thing, it's still very easy to accidentally invoke apt-get clean via various front-ends. Especially if you bounce back and forth between machines with different package retention policies. It would still be nice to have a built-in feature to disable that. The alternative is to create a local mirror with reprepro. You can make a nightly snapshot or make a snapshot every time you apt-get upgrade/install (unless there already is one). A cron job can then remove the snapshot after 2 weeks. All just a workaround but maybe it helps you over the time till someone implements a configurable policy framework for apt-get (auto)clean. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590041: Mishandles Packages.gz from other archs
David Kalnischkies kalnischkies+deb...@gmail.com writes: Hi Goswin, 2010/7/23 Goswin von Brederlow goswin-...@web.de: r...@frosties:/var/lib/apt/lists# apt-cache show libc6-armel-cross E: Can't select versions from package 'libc6-armel-cross' as it purely virtual E: No packages found try: apt-cache show libc6-armel-cross:armel or as an alternative: apt-cache show libc6-armel-cross -o APT::Architecture=armel That works. Didn't know apt already supported the :arch. And now for the really spooky part: Testing some more I find that the problem is the Replaces line. Changing libc6-armel-cross to Changing libc6-armel-cross2 makes libc6-armel-cross appear. Changing it back makes it disapear. This happens as APT adds Replaces against all known architectures to the package. So what you get above is correct as you have requested package libc6-armel-cross:i386 and this one is virtual as it is only created for the Replaces line. Still i guess it should do the same for virtual packages as it does it already if the package doesn't exist at all: Get the next possible match if no architecture is requested explicit Best regards, David Kalnischkies The odd behaviour makes sense now. But shouldn't it show the entries for all architectures if no specific architecture is requested? Just like it shows all versions if no version is specified. Short of that it could say what it actualy searched for: E: Can't select versions from package 'libc6-armel-cross:amd64' as it purely virtual E: No packages found E: Unable to locate package libfoo-armel-cross:amd64 E: No packages found But showing the right thing would be better. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589963: preinst fails if awk is unpacked but not configured
Bastian Blank wa...@debian.org writes: On Sat, Jul 24, 2010 at 04:51:50PM -0700, Steve Langasek wrote: Only because it's a cdebootstrap bug. Unless you see something that causes initramfs-tools to be pulled into the essential set (which I do not), this is a cdebootstrap bug for not fulfilling the pre-depends of the essential packages before continuing. At least in Lucid, initramfs-tools is essential: util-linux - upstart(upstart-job) - mountall - plymouth - initramfs-tools You should know better, awk is not essential. Also essential means that it have to work _without_ being configured. I know quite well that awk *is* part of the essential closure, because it's a pre-dependency of an essential package. Even *unpacking* of base-files is not supposed to happen (in an ideal world) before awk has been configured, and you definitely shouldn't be trying to configure *other* packages before the pre-depends of essential packages have been satisfied. In an ideal world, it is possible to configure every essential package with its dependencies and pre-dependendies on its own. Bastian Maybe since awk is essential by way of being a pre-depends of base-files both mawk and gawk should behave as if they were essential. Meaning awk should work with [gm]awk unpacked but not yet configured. If both gawk and mawk create the awk link in preinst if it is missing then awk can be used with [mg]awk unpacked. Probably needs some special hand holding of update-alternatives in postinst for it to work though. But it should be managable. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590041: Mishandles Packages.gz from other archs
Package: apt
Version: 0.7.26~exp10
Severity: normal
Hi,
I have apt configured with Apt::Architectures = { amd64; armel; }
and a Apt::Post-Update hook that transforms the armel Packages.gz file
into something suitable for cross-compiling. But all packages that are
not Architecture: all are ignored from
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages.
Replacing the amd64 Packages file with the armel one makes all
packages suddenly appear.
As a testcase I have stripped down the Packages files to bare minimum:
# ls -lh /var/lib/apt/lists/*Packages
-rw-r--r-- 1 root root0 Jul 23 06:51
ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages
-rw-r--r-- 1 root root 3.5K Jul 23 06:50
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
# grep-dctrl -s Package,Architecture,Version
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
Package: banshee-extension-telepathy
Architecture: all
Version: 1.6.1-1
Package: libc6-armel-cross
Architecture: amd64
Version: 2.11.2-2~0.2
# apt-cache show banshee-extension-telepathy
Package: banshee-extension-telepathy
Architecture: all
Version: 1.6.1-1
...
# apt-cache show libc6-armel-cross
E: Can't select versions from package 'libc6-armel-cross' as it purely virtual
E: No packages found
# cp
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages
# apt-cache show libc6-armel-cross
Package: libc6-armel-cross
Architecture: amd64
Version: 2.11.2-2~0.2
...
This is a big regression from previous experimental versions.
MfG
Goswin
-- Package-specific info:
-- (/etc/apt/preferences present, but not submitted) --
-- (/etc/apt/sources.list present, but not submitted) --
-- 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 apt depends on:
ii debian-archive-keyring2009.01.31 GnuPG archive keys of the Debian a
ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib
ii libgcc1 1:4.4.4-5 GCC support library
ii libstdc++64.4.4-5The GNU Standard C++ Library v3
apt recommends no packages.
Versions of packages apt suggests:
ii apt-doc 0.7.25.3 Documentation for APT
ii aptitude 0.6.3-3terminal-based package manager (te
ii bzip2 1.0.5-4high-quality block-sorting file co
ii dpkg-dev 1.15.7.2 Debian package development tools
ii lzma 4.43-14Compression method of 7z format in
pn python-aptnone (no description available)
-- no debconf information
Package: banshee-extension-telepathy
Architecture: all
Version: 1.6.1-1
Conflicts: libc6-i386 ( 2.9-18), ia32-libs, ia32-libs-gtk
Depends: banshee-extensions-common (= 1.6.1-1), empathy (= 2.27.91),
telepathy-gabble (= 0.9), telepathy-mission-control-5 (= 5.3.1),
libc6-armel-cross (= 2.11~0.2) | libc6.1-armel-cross (= 2.11~0.2) |
libc0.1-armel-cross (= 2.11~0.2), libglib2.0-0-armel-cross (= 2.24.0~0.2),
libglib2.0-cil-armel-cross (= 2.12.10~0.2), libgtk2.0-cil-armel-cross (=
2.12.10~0.2), libmono-addins0.2-cil (= 0.4), libmono-corlib2.0-cil (=
1.2.2.1), libmono-posix2.0-cil (= 2.4), libmono-system-data2.0-cil (= 1.2.6),
libmono-system2.0-cil (= 2.4.3), libnotify0.4-cil (= 0.4.0~r2998)
Provides: ia32-abi, ia32-abi-1
Replaces: ia32-libs, ia32-libs-gtk
Description: Telepathy extension for Banshee
This extension provides integration between the Empathy instant messenger and
Banshee. It provides the following features:
.
* Download your friends' Banshee library metadata and check out what they
listen to, their ratings, BPM values, etc.
* View your friends' playlists and export them to disk
* Share what you're listening to with all your instant messaging friends by
advertising the track, artist, and album of the currently playing track in
Empathy's status message. This can be disabled.
* Download your friends' music; one track at a time or a selection. You can
cancel ones in progress, queued, individually or all at once. The sender has
the option to cancel all in progress or queued transfers only. Both sender
and receiver get a progress bar. File sharing can be disabled.
* Stream your friends' music. This feature can be disabled.
.
Banshee is a media management and playback application for the GNOME desktop.
Filename:
pool/main/b/banshee-community-extensions/banshee-extension-telepathy_1.6.1-1_all.deb
Homepage: http://gitorious.org/banshee-community-extensions
Installed-Size: 404
MD5sum: fb1f3f35e5817516f9b3cd5c642e79d0
Bug#589996: Insane dependency on apt causes kernel to be removed on update
Ben Hutchings b...@decadent.org.uk writes: On Thu, 2010-07-22 at 22:19 +0200, Goswin von Brederlow wrote: Package: linux-base Version: 2.6.32-17 Severity: important Hi, in the linux-image packages there is now a dependency chain from linux-image-2.6... - linux-base - libapt-pkg-perl - libapt-pkg-libc6.9-6-4.8. Which is the virtual package provided by apt to signal the ABI of its library and binary caches. In effect the kernels are locked to a specific ABI version of apt. The problem is that the ABI changes from time to time and every time it does an update of apt will now remove the kernel for the duration of the transition. For an example try installing apt from experimental. Well, that is life you might say. That is what is called a library transition. But here comes the insane part. The 1637 line long perl postinst script of linux-base only depends on apt because of this code at the end: [...] What's really insane is that we don't have a nice and stable library to do this and instead I have to fork every time I want to compare two strings. Ben. Yes, a nice and stable libdpkg is needed. But here it is ONE fork and the script aready forks a zillion times for other tools. So no harm done. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590041: Mishandles Packages.gz from other archs
David Kalnischkies kalnischkies+deb...@gmail.com writes:
2010/7/23 Goswin von Brederlow goswin-...@web.de:
I have apt configured with Apt::Architectures = { amd64; armel; }
and a Apt::Post-Update hook that transforms the armel Packages.gz file
into something suitable for cross-compiling. But all packages that are
not Architecture: all are ignored from
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages.
More specifically: It ignores packages which are not arch :all or :armel
in this file. Your libc6-armel-cross package is :amd64.
Its done more or less on intension as files which have a specific
architecture (in this case armel) shouldn't include other architectures
by design. Could be changed, sure, but i am unsure if this should be done.
APT has done it that way since ever so far
(expect the experimental versions in which i broke it
).
(dpkg/status and flat Packages files are different, from these APT will
include all packages included in the Architectures list).
I thought that could be the problem. But that isn't it, or not just
that (see spooky part below).
I 've put the mangled Packages file at
http://mrvn.homeip.net/ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages.bz2
if you want to try yourself.
r...@frosties:/var/lib/apt/lists# apt-get update
Get:1 http://chocos sid Release.gpg [197B]
Ign http://chocos/debian/ sid/main Translation-en
Get:2 http://chocos sid Release [7962B]
Ign http://chocos sid/main amd64 Packages
Get:3 http://chocos sid/main amd64 Packages [8996kB]
Get:4 http://ftp.de.debian.org sid Release.gpg [835B]
Ign http://ftp.de.debian.org/debian/ sid/main Translation-en
Get:5 http://ftp.de.debian.org sid Release [104kB]
Get:6 http://ftp.de.debian.org sid/main armel Packages [6649kB]
Fetched 15.8MB in 33s (476kB/s)
I: mangling chocos_debian_dists_sid_main_binary-amd64_Packages
I: mangling ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
Reading package lists... Done
r...@frosties:/var/lib/apt/lists# grep-dctrl -P libc6-armel-cross
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
Package: libc6-armel-cross
Architecture: armel
Version: 2.11.2-2~0.3
Breaks: locales ( 2.11), locales-all ( 2.11), nscd ( 2.11)
Conflicts: tzdata ( 2007k-1), tzdata-etch, libc6-i386 ( 2.9-18), ia32-libs,
ia32-libs-gtk
Depends: libc-bin (= 2.11.2-2), libgcc1-armel-cross
Provides: glibc-2.11-1-armel-cross, ia32-abi, ia32-abi-1
Replaces: ia32-libs, ia32-libs-gtk
Suggests: glibc-doc, debconf | debconf-2.0, locales
Description: Embedded GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
Filename: pool/main/e/eglibc/libc6_2.11.2-2_armel.deb
Homepage: http://www.eglibc.org
Installed-Size: 9740
MD5sum: f5b878ce5fb8aa01a7927fa1460df537
Maintainer: GNU Libc Maintainers debian-gl...@lists.debian.org
Priority: required
SHA1: 0464d597dfbf949e8c17a42325b1f93fb4914afd
SHA256: faca4a3d9ccff57568abf41f6cb81ddd835be7b5d8b0161e2d5f9a7f26aae3c0
Section: libs
Size: 4178958
Source: eglibc (2.11.2-2)
Tag: devel::lang:c, devel::library, implemented-in::c, protocol::ipv6,
role::shared-lib, suite::gnu
r...@frosties:/var/lib/apt/lists# apt-cache show libc6-armel-cross
E: Can't select versions from package 'libc6-armel-cross' as it purely virtual
E: No packages found
And now for the really spooky part:
r...@frosties:/var/lib/apt/lists# grep-dctrl -P libc6-armel-cross
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages t
r...@frosties:/var/lib/apt/lists# mv t
ftp.de.debian.org_debian_dists_sid_main_binary-armel_Packages
r...@frosties:/var/lib/apt/lists# apt-cache show libc6-armel-cross
Package: libc6-armel-cross
Architecture: armel
Version: 2.11.2-2~0.3
Breaks: locales ( 2.11), locales-all ( 2.11), nscd ( 2.11)
Conflicts: tzdata ( 2007k-1), tzdata-etch, libc6-i386 ( 2.9-18), ia32-libs,
ia32-libs-gtk
Depends: libc-bin (= 2.11.2-2), libgcc1-armel-cross
Provides: glibc-2.11-1-armel-cross, ia32-abi, ia32-abi-1
Replaces: ia32-libs, ia32-libs-gtk
Suggests: glibc-doc, debconf | debconf-2.0, locales
Description: Embedded GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
Filename: pool/main/e/eglibc/libc6_2.11.2-2_armel.deb
Homepage: http://www.eglibc.org
Installed-Size: 9740
MD5sum: f5b878ce5fb8aa01a7927fa1460df537
Maintainer: GNU Libc Maintainers debian-gl...@lists.debian.org
Priority: required
SHA1: 0464d597dfbf949e8c17a42325b1f93fb4914afd
SHA256: faca4a3d9ccff57568abf41f6cb81ddd835be7b5d8b0161e2d5f9a7f26aae3c0
Section
Bug#589821: Kills systems ypbind when installing in chroot
Mark Brown broo...@debian.org writes: severity 589821 important kthxbye On Wed, Jul 21, 2010 at 02:07:45PM +0200, Goswin von Brederlow wrote: Package: nis Version: 3.17-17 Severity: critical Please be realistic in the severity of your reports; this is a fairly obscure use case (it's been present for something in the region of ten years now...) for advanced users which is most likely going to fail anyway due to the two competing ypbinds trying to run simultaneously. This is in no way serious enough to justify blocking the release of the package. The server mostly stoped working for everyone, no new logins were possible and I had to walk down into the cellar and login as root on the console to restart nis. I think that fits the breaks the whole system description of critical. But I'm not going to start a severity war, it's your prerogative to change it. As to the obscurity of this scenario: I was creating a chroot to be used as filesystem for a kvm instance. While nis is not widely used, those that do use it probably want to use it in virtualization too, if they do virtualization. So this might crop up more often in the future. 10 years ago virtualization wasn't a buzz-word. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589821: Kills systems ypbind when installing in chroot
Mark Brown broo...@debian.org writes: On Thu, Jul 22, 2010 at 10:16:25AM +0200, Goswin von Brederlow wrote: As to the obscurity of this scenario: I was creating a chroot to be used as filesystem for a kvm instance. While nis is not widely used, those that do use it probably want to use it in virtualization too, if they do virtualization. So this might crop up more often in the future. 10 years ago virtualization wasn't a buzz-word. Most people do virtualisation rather than chroots (as you yourself were actually going to do) and with virtualisation you don't get the problem since the virtual system is a separate one. Virtualisation has pretty much removed the reason people used to do this by providing a superior alternative. You still have to create the filesystem for it first. I looked into writing a patch for this and looked into policy for what the right thing to do is. According to policy on a fresh install dpkg passes the Null argument as second argument but the killall ypbind is already portected with an $2 != . So on a fresh install the killall should not be triggered, right? But then what did kill the systems ypbind? I'm afraid of running the create FS for kvm script again because I'm not on site currently. So I can't make a strace of what happens just now. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589963: preinst fails if awk is unpacked but not configured
Package: initramfs-tools
Version: 0.96.1
Severity: normal
Hi,
when cdebootstraping an Ubuntu Lucid system initramfs-tools gets
installed now. The problem then is that at the point initramfs-tools
is unpacked the mawk package is unpacked but not configured. That
means the /usr/bin/awk alternative is not yet setup.
O: Selecting previously deselected package mawk.
O: dpkg: regarding .../mawk_1.3.3-15ubuntu2_amd64.deb containing mawk,
pre-dependency problem:
O: mawk pre-depends on libc6 (= 2.11~20100104-0ubuntu3)
O: libc6 is unpacked, but has never been configured.
O: dpkg: warning: ignoring pre-dependency problem!
O: Unpacking mawk (from .../mawk_1.3.3-15ubuntu2_amd64.deb) ...
P: Unpacking package mawk
D: Updating mawk to status 2
O: Selecting previously deselected package base-files.
O: dpkg: regarding .../base-files_5.0.0ubuntu20_amd64.deb containing
base-files, pre-dependency problem:
O: base-files pre-depends on awk
O: mawk provides awk but is unpacked but not configured.
O: dpkg: warning: ignoring pre-dependency problem!
O: Unpacking base-files (from .../base-files_5.0.0ubuntu20_amd64.deb) ...
P: Unpacking package base-files
D: Updating base-files to status 2
...
O: Selecting previously deselected package initramfs-tools.
O: Unpacking initramfs-tools (from .../initramfs-tools_0.92bubuntu78_all.deb) ..
.
P: Unpacking package initramfs-tools
D: Updating initramfs-tools to status 2
O: /var/lib/dpkg/tmp.ci/preinst: 59:
O: awk: not found
O:
O: /var/lib/dpkg/tmp.ci/preinst: 59:
O: awk: not found
O:
O: dpkg: error processing
/var/cache/bootstrap/initramfs-tools_0.92bubuntu78_all.deb (--unpack):
O: subprocess new pre-installation script returned error exit status 127
While this could be blamed on cdebootstrap I think it might be a good
idea to fix initramfs-tools. The relevant command is
awk ' { print $1 } '
which really does not need awk. cut would do instead and avoid the
rather probelamtic pseudo-essential awk issue.
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 initramfs-tools depends on:
ii cpio 2.11-4 GNU cpio -- a program to manage ar
ii findutils4.4.2-1 utilities for finding files--find,
ii klibc-utils 1.5.18-1small utilities built with klibc f
ii module-init-tools3.12~pre2-3 tools for managing Linux kernel mo
ii udev 157-1 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.15.3-1 Tiny utilities for small and embed
initramfs-tools suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589969: Goes into endless loop when installing lucid
Package: cdebootstrap
Version: 0.5.5ubuntu2
Severity: normal
Hi,
sorry for reporting a bug in an ubuntu version. But I think this could
also happen in debian. Attached is a strace output from cdebootstrap
on lucid and for lucid. It seems the fork to run wget goes haywire and
does not consider revents=POLLNVAL as an error. Instead it just loops
poll() calls endlessly untill killed manualy.
MfG
Goswin
PS: I've added lucid do /usr/share/cdebootstrap/suites. Please add
that and maveric there.
-- System Information:
Debian Release: squeeze/sid
APT prefers lucid-updates
APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-23-server (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages cdebootstrap depends on:
ii debian-archive-keyring 2009.01.31ubuntu1 GnuPG archive keys of the Debian a
ii gpgv 1.4.10-2ubuntu1 GNU privacy guard - signature veri
ii libc6 2.11.1-0ubuntu7.2 Embedded GNU C Library: Shared lib
ii libdebian-installer-ex 0.68ubuntu3 Library of some extra debian-insta
ii libdebian-installer4 0.68ubuntu3 Library of common debian-installer
ii wget 1.12-1.1ubuntu2 retrieves files from the web
cdebootstrap recommends no packages.
cdebootstrap suggests no packages.
-- no debconf information
execve(/usr/bin/cdebootstrap, [cdebootstrap, --debug, -v, -aamd64,
-q, --keyring, /scratch/ramdisk/build/build/chr..., lucid,
/scratch/ramdisk/build/build/chr..., http://ql-bak/debmirror/lucid/re;...,
-f, minimal, --include, autofs, --include, binutils, ...], [/* 14
vars */]) = 0
brk(0) = 0x21e7000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb94a238000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32778, ...}) = 0
mmap(NULL, 32778, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb94a22f000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libdebian-installer-extra.so.4, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360\16\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=10544, ...}) = 0
mmap(NULL, 2105560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb949e17000
mprotect(0x7fb949e19000, 2093056, PROT_NONE) = 0
mmap(0x7fb94a018000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fb94a018000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libdebian-installer.so.4, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200P\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=53712, ...}) = 0
mmap(NULL, 2148904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb949c0a000
mprotect(0x7fb949c15000, 2097152, PROT_NONE) = 0
mmap(0x7fb949e15000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7fb949e15000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0`\355\1\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1572232, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb94a22e000
mmap(NULL, 3680296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb949887000
mprotect(0x7fb949a01000, 2093056, PROT_NONE) = 0
mmap(0x7fb949c0, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x179000) = 0x7fb949c0
mmap(0x7fb949c05000, 18472, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb949c05000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb94a22d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb94a22c000
arch_prctl(ARCH_SET_FS, 0x7fb94a22d700) = 0
mprotect(0x7fb949c0, 16384, PROT_READ) = 0
mprotect(0x7fb949e15000, 4096, PROT_READ) = 0
mprotect(0x7fb94a018000, 4096, PROT_READ) = 0
mprotect(0x60a000, 4096, PROT_READ) = 0
mprotect(0x7fb94a23a000, 4096, PROT_READ) = 0
munmap(0x7fb94a22f000, 32778) = 0
rt_sigaction(SIGHUP, {0x404900, [HUP], SA_RESTORER|SA_RESTART, 0x7fb9498baaf0},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x404900, [INT], SA_RESTORER|SA_RESTART, 0x7fb9498baaf0},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART,
0x7fb9498baaf0}, {SIG_DFL, [], 0}, 8) = 0
Bug#589996: Insane dependency on apt causes kernel to be removed on update
Package: linux-base
Version: 2.6.32-17
Severity: important
Hi,
in the linux-image packages there is now a dependency chain from
linux-image-2.6... - linux-base - libapt-pkg-perl -
libapt-pkg-libc6.9-6-4.8. Which is the virtual package provided by apt
to signal the ABI of its library and binary caches. In effect the
kernels are locked to a specific ABI version of apt. The problem is
that the ABI changes from time to time and every time it does an
update of apt will now remove the kernel for the duration of the
transition. For an example try installing apt from experimental.
Well, that is life you might say. That is what is called a library
transition.
But here comes the insane part. The 1637 line long perl postinst
script of linux-base only depends on apt because of this code at the
end:
sub compare_versions {
return $AptPkg::Config::_config-system-versioning-compare(@_);
}
if ($ARGV[0] eq 'reconfigure' || defined($ENV{DEBCONF_RECONFIGURE}) ||
(!is_fresh_installation()
compare_versions($ARGV[1], $libata_transition_ver) 0)) {
DebianKernel::DiskId::transition();
}
Could I suggest replacing this with a call to
system('dpkg', '--compare-versions', $ARGV[1], '', $libata_transition_ver)
That way the dependency on apt can be droped completly.
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 linux-base depends on:
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg
ii libuuid-perl 0.02-3+b1 Perl extension for using UUID inte
ii udev 157-1 /dev/ and hotplug management daemo
ii util-linux2.17.2-3 Miscellaneous system utilities
linux-base recommends no packages.
linux-base suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
