Bug#633460: pu: package freebsd-utils/8.1-4+squeeze1
Robert, am Sun, Jul 10, 2011 at 01:32:52PM + hast du folgendes geschrieben: devd, the device state change daemon (similar to udev on Linux) was shipped in squeeze without its corresponding config file and init.d script, which makes it practically useless. This was reported (and fixed) as bug #630614 in sid. I'm proposing a backport of this fix, see attached diff. please go ahead. If it's causing any regressions after the next point release, please contact d-release@ so that we can push fixes through squeeze-updates. We are being more liberal with kfreebsd as regressions there only affect this `technology preview'. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#482092: partman-crypto: xts support
On Fri, Jun 22, 2012 at 04:30:11PM -0700, Matt Taggart wrote: If so, then I think all that's needed is to add xts-plain to debian-installer/packages/partman-crypto/ciphers/dm-crypt/ivalgorithm Sound correct? So there's nothing special about key sizes with xts as stated basically at the top of the bug report? Also I guess one should support xts-plain64 too? Is there any value in offering xts-plain at this point, shouldn't we go to 64bit sector numbers directly? Upstream even says that there's no performance penalty. Kind regards Philipp Kern, who also set up xts-plain manually (on a constrained SSD, hence no plain64) signature.asc Description: Digital signature
Bug#678668: RM: floppy-retriever -- ROM; obsolete
Package: ftp.debian.org Severity: normal floppy-retriever got renamed to media-retriever back in 2008. It should hence be dropped from unstable. Thanks Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64
On Sat, Jun 23, 2012 at 11:24:17AM -0400, Joey Hess wrote: Philipp Kern wrote: And what about floppy-retriever? It was renamed to media-retriever in 2008. Perhaps a RM bug was forgotten to be filed? ACK, thanks. Did so now. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#678814: does not provide icons for xdg folders
Package: tango-icon-theme Version: 0.8.90-5 Severity: normal Tags: upstream Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=43759 tango-icon-theme does not contain icons for xdg folders, which causes a weird icon mix in nautilus for instance, because the GNOME icons are used. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482092: partman-crypto: xts support
Matt, am Thu, Jun 28, 2012 at 01:27:02PM -0700 hast du folgendes geschrieben: Bastian Blank writes: We only want to support plain64 for Wheezy. I assume you mean for wheezy we just want the d-i partman-crypto UI to support selecting xts-plain64 and not xts-plain? The kernel support will still be there and you'll be able to mount an existing xts-plain based filesystem (or create one by hand in a shell) right? The ability to do so is still interesting for rescue purposes. AFAIUI plain64 is able to mount plain partitions. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679633: pu: package xserver-xorg-video-intel/2:2.13.0-7
On Sat, Jun 30, 2012 at 12:57:35PM +0200, Julien Cristau wrote: Simon McVittie reported a crash in the intel driver, and tracked down the fix in the upstream tree. The patch is simple and applies cleanly. debdiff follows, modulo dch -r. Please go ahead. Thanks Philipp Kern signature.asc Description: Digital signature
Bug#612398: closed by Goswin von Brederlow goswin-...@web.de (Closing ia32-libs bugs because it was superceeded by multiarch)
On Sat, Jun 30, 2012 at 11:24:04AM +, Debian Bug Tracking System wrote: with the introduction of multi-arch in wheezy the ia32-libs package can finally be retired. There will be a transitional package for ia32-libs to help users migrate more smoothly to multi-arch but that package is empty and depends on the relevant 32bit packages from i386 to preserve functionality. Because of this I am closing this bug-report. If the problem still exists under multi-arch then please file a new bug-report against the relevant 32bit package directly. This problem pretty obviously cannot be solved with multiarch. You'd need to depend on the libacl1-dev package, which cannot be multiarch-ified with the current spec. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#675971: what should we be doing?
On Wed, Jun 27, 2012 at 02:51:23PM -0400, Chris Knadle wrote: I've re-read what you had written to at least try to understand what options there there might be. If possible, I'd like some clarification on what the zero-ice snafu in the following statement means: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54 Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679405: ITP: python-fcgi -- Simple FastCGI module for Python
Hi, On Thu, Jun 28, 2012 at 02:49:04PM +0200, Marc Haber wrote: This is free software. You may use this software for any purpose including modification/redistribution, so long as this header remains intact and that you do not claim any rights of ownership or authorship of this software. This software has been tested, but no warranty is expressed or implied. this should not be part of the description in Debian IMO. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
Alexander, am Mon, Jul 02, 2012 at 11:11:51AM +0600 hast du folgendes geschrieben: 1) The installer should be able to install the system to a btrfs subvolume (except /home and /var, which should be on separate subvolumes). 2) On such system, dpkg and apt/aptitude, if requested by the user and/or by default, should make a writeable snapshot of the root subvolume, mount it to some temporary location, chroot into it and perform the upgrade there. During this process, the main system will, of course, continue to work. it is not sufficient on a Debian system to just branch off the root filesystem given that important state information of the package manager is stored in /var. Of course somebody could port the Nexenta snapshotting method (with ZFS) to Debian proper with btrfs... Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#612398: [Pkg-ia32-libs-maintainers] Bug#612398: closed by Goswin von Brederlow goswin-...@web.de (Closing ia32-libs bugs because it was superceeded by multiarch)
On Sat, Jun 30, 2012 at 03:40:52PM +0200, Goswin von Brederlow wrote: If that is a blocker for you then you can create a new package tivoli-libacl1-so-link (Architecture: i386) that contains /usr/lib/i486-linux-gnu/libacl.so - ../libacl.so.1.1.0 diverts the file from libacl1-dev (so a future multiarch libacl1-dev can be installed in parallel) and depends on libacl1. Unfortunately you can't conflict on libacl1-dev as that afaik would also conflict libacl1-dev:amd64. The diversion works around that. I wonder what would happen if another one did the same diversion. But yeah, thanks. That will work. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#610949: second ls lists empty directory
On Wed, Jul 04, 2012 at 12:07:40PM -0500, Jonathan Nieder wrote: In January, 2011, Philipp Kern wrote: * Create ~/Private with ecryptfs-setup-private. * Touch ~/Private/x. * ls ~/Private/ - x is listed. * ls ~/Private/ - x is NOT listed anymore. Thanks for reporting it. Do you happen to remember what kernel you were using? Hope that helps, Jonathan [...] Debian Release: 6.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable'), (100, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) That one. Most certainly on NFS, which is a known bug, I think. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#610949: second ls lists empty directory
On Wed, Jul 04, 2012 at 12:59:11PM -0500, Jonathan Nieder wrote: Philipp Kern wrote: On Wed, Jul 04, 2012 at 12:07:40PM -0500, Jonathan Nieder wrote: In January, 2011, Philipp Kern wrote: * Create ~/Private with ecryptfs-setup-private. * Touch ~/Private/x. * ls ~/Private/ - x is listed. * ls ~/Private/ - x is NOT listed anymore. Thanks for reporting it. Do you happen to remember what kernel you were using? [...] Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) That one. Most certainly on NFS, which is a known bug, I think. That's a package name (which includes the ABI version) rather than a version number. I ask because there have been some ecryptfs fixes in 2.6.32.y recently and I don't want to spend too much time hunting if the bug has already been fixed. Pretty sure the current version at the time I reported that bug (i.e. the most current stuff either in security or stable-proposed-updates). And no, sadly I don't have logs going back to Jan 2011. But we keep our clients up-to-date and test p-u. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#680275: [p-a-s] Remove sdl-stretch
On Wed, Jul 04, 2012 at 07:30:48PM +0100, Manuel A. Fernandez Montecelo wrote: We'll restrict the architectures in debian/control, […] Please do that first. Thanks Philipp Kern signature.asc Description: Digital signature
Bug#647837: buildd.debian.org: [p-a-s] remove gnumach and hurd
On Sun, Nov 06, 2011 at 07:54:05PM +0100, Samuel Thibault wrote: gnumach and hurd have proper Architecture: field, please drop them from Packages-arch-specific. For hurd I agree. For gnumach I'm confused why you say any-i386 hurd-i386. The former does include the latter… (And sorry for dragging this on so long. It seems that it somehow skipped my todo marking process.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#647837: buildd.debian.org: [p-a-s] remove gnumach and hurd
On Wed, Jul 04, 2012 at 10:52:36PM -0300, Samuel Thibault wrote: Philipp Kern, le Wed 04 Jul 2012 18:25:03 -0600, a écrit : On Sun, Nov 06, 2011 at 07:54:05PM +0100, Samuel Thibault wrote: gnumach and hurd have proper Architecture: field, please drop them from Packages-arch-specific. For hurd I agree. For gnumach I'm confused why you say any-i386 hurd-i386. The former does include the latter… That's because gnumach-image* are any-i386, but kernel-image-*-di are hurd-i386 (since they are only meaningful for the hurd d-i). Ok, I think that will be fixed with the new dpkg which should only keep the broader one. Will do the change in a bit, thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#406114: having a tool like ping
On Fri, Jul 06, 2012 at 01:50:24PM +0400, Michael Tokarev wrote: it is really trivial to enable ping applet in busybox and close this bugreport for good. […] Maybe it's a good idea to reassign it to busybox-udeb and fix it there finally, for good? I think that would be great. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#680518: kdeutils' ark binary got superseded by the ark source package
Package: kdeutils Version: 4:4.7.4-2 Severity: serious wanna-build cc9856fa36ea51dfcc1c451fb9b9b396494a0fe1 for sid on amd64 merge-v3 2012 Jul 06 14:12:42 kdeutils_4:4.7.4-2 (amd64, sid): skipped because binaries (assumed to be) overwritten (ark, 4:4.7.4-2 vs. 4:4.8.4-2) = kdeutils should drop the ark binary -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680520: superseded by libtext-bibtex-perl
Package: libbtparse Version: 0.34-3 Severity: serious libbtparse-dev got taken over by src:libtext-bibtex-perl and builds a newer SONAME of libbtparse. I guess that src:libbtparse should hence be removed. signature.asc Description: Digital signature
Bug#680622: unblock: goobox/3.0.1-4
On Sat, Jul 07, 2012 at 02:45:43PM +0200, Helge Kreutzmann wrote: However, the road was a little bumpy, thus 3.0.1-4 closes an RC bug (namely #679554). It has (finally) build on all architectures. | + # Due to bug #679554 / 679552 | +ifeq ($(DEB_HOST_ARCH),i386) | + docbook-to-man $(MANDIR)/goobox.en.sgml debian/goobox/usr/share/man/man1/goobox.1 | po4a -v -f debian/po4a.cfg | # po4a-translate is broken, c.f. #280882 | perl -i -p -e 's# refentrytitle\dhucpackage;#\dhucpackage;#ms' $(MANDIR)/goobox.de.sgml | perl -i -p -e 's#^\s*/refentrytitle##' $(MANDIR)/goobox.de.sgml | docbook-to-man $(MANDIR)/goobox.de.sgml debian/goobox/usr/share/man/de/man1/goobox.1 | recode latin1..utf8 debian/goobox/usr/share/man/de/man1/goobox.1 | +else | + cp -iv debian/pregenerated/goobox.1 debian/goobox/usr/share/man/man1/goobox.1 | + cp -iv debian/pregenerated/goobox.1.de debian/goobox/usr/share/man/de/man1/goobox.1 | +endif What kind of fix is that? If it builds on your machine use docbook-to-man, on the buildds use pregenerated stuff? Sorry, but no. As you said it's probably not goobox's fault so it needs to be fixed somewhere else. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#680699: unblock: flash-kernel/3.1
Hi, On Sun, Jul 08, 2012 at 03:16:41AM +0200, Hector Oron wrote: Please unblock package flash-kernel Hello, flash-kernel/3.1 adds device tree support for Dreamplug device (used by freedombox). Dreamplug support has been backported into linux/3.2.21-1, which we expect it to get into wheezy sometime. Therefore, it would be really nice if we can get flash-kernel/3.1 in wheezy. unblock flash-kernel/3.1 my only concern is that /proc/device-tree/model takes precedence over /proc/cpuinfo in any case with no fallback to the latter. So if any ARM SoC gets device-tree enabled by a backport it might potentially need a change to flash-kernel, if the Hardware string does not match up with what the model file delivers. Bdale argues that the device-tree changes could potentially incur other changes so an update of flash-kernel makes sense instead of the fallback solution. @debian-boot: Is it ok to unblock flash-kernel at this point or should that be done post-beta1? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#680711: RM: gnome-ppp [armel] -- basically ANAIS; b-ds on wvdial
Package: ftp.debian.org Severity: normal gnome-ppp now b-ds on wvdial, which is not available on armel. Please remove the old gnome-ppp binary so that it can finally migrate. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680898: build-depends on gcc-4.5/g++-4.6; build-conflicts against obsolete gcc version on x86
Package: starpu-contrib Version: 1.0.1-2 Severity: important Hi, starpu-contrib build-depends on gcc-4.5/g++-4.5 which should go away (see [0]). It also build-conflicts against gcc-4.6/g++-4.6, which are not the default compilers of x86 in wheezy anymore. Kind regards Philipp Kern [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675431 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666879: s390(x): please add a netboot image
On Tue, Apr 03, 2012 at 03:54:12PM +0200, Mattias Wadenstein wrote: On Mon, 2 Apr 2012, Philipp Kern wrote: am Mon, Apr 02, 2012 at 03:49:48PM +0100 hast du folgendes geschrieben: OK. We also don't make *any* s390x images at all at the moment, which I should probably fix. Is d-i working on s390x? If so, I'll add it to the normal set of daily and weekly images. it's supposed to be working. If we drop the regular CD images, we could at least offer the netboot stuff in the same place? If cd1 is useful, why not build just that for s390[x]? 2x700 meg is hardly big today, and I wouldn't expect 70M or 700M be a significant difference in download times for anywhere with an s390. It's rather 10M vs. 700M, but well... what should I say. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#680898: build-depends on gcc-4.5/g++-4.6; build-conflicts against obsolete gcc version on x86
On Mon, Jul 09, 2012 at 06:24:09AM +0200, Samuel Thibault wrote: Philipp Kern, le Sun 08 Jul 2012 17:17:47 -0600, a écrit : starpu-contrib build-depends on gcc-4.5/g++-4.5 which should go away (see [0]). It also build-conflicts against gcc-4.6/g++-4.6, which are not the default compilers of x86 in wheezy anymore. The problem is that nvcc tries to use the latest installed gcc, but does not actually support all of its syntax, leading to build failures. That's why this situation, which should be fine for wheezy. Wheezy+1, with a newer nvcc, will probably be an entirely different story. We're aiming to remove gcc-4.5 from wheezy, so I'm not sure how it can be fine for it. And can it actually be rebuilt given that 4.7 would be picked? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#674853: [Pkg-samba-maint] Bug#674853: winbind should depend on libpam-winbind and libnss-winbind for wheezy
# It seems that Christian missed to Cc control@, so copying the instructions # here. severity 674853 important thanks On Mon, May 28, 2012 at 08:48:54PM +0300, Adrian Bunk wrote: Either not installing Recommends (which is a *global* setting in Debian) is considered a valid setup through all of Debian, or it is anyway considered broken. In the latter case there would be no reason against changing the Recommends to Depends... I'm sorry that I have to quote policy to you: | Recommends | |This declares a strong, but not absolute, dependency. | |The Recommends field should list packages that would be found together |with this one in all but unusual installations. It's pretty clear that winbind can be used usefully without those two packages (e.g. for RADIUS auth against Active Directory), but that, as you said, they should be there in usual installations. That's the definition of recommends. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674853: [Pkg-samba-maint] Bug#674853: winbind should depend on libpam-winbind and libnss-winbind for wheezy
On Mon, May 28, 2012 at 10:45:40PM +0300, Adrian Bunk wrote: [ winbind only recommending libpam-winbind and libnss-winbind ] What I am talking about is the special case of how to ensure that everyone who had these installed in squeeze (due to them being part of winbind) will also have them installed in wheezy after upgrading. The definition of recommends implies that you should opt out of them only in a concious way and I don't see a way around reviewing missing recommends on upgrade. We should probably mention the fact that we expect users to review them in the release notes / upgrade instructions, though, if it isn't already. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#568362: upstream moved
So one problem is that it ships an outdated kernel module in usbip-source which should simply be dropped. The module is even activated in the Debian kernel, despite its staging status. But the other is that upstream moved into the kernel: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=drivers/staging/usbip/userspace;hb=dcd6c92267155e70a94b3927bce681ce74b80d1f So one would need to ensure that the library didn't mess with its symbols (or change the version accordingly) and preferably build it from something like linux-tools. For wheezy it should be sufficient to take the source of the appropriate kernel version, tar it and update the package; dropping usbip-source in the process. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675333: dpkg-source does not minimize the architecture list (linux-any vs. explicit listing)
Package: dpkg-dev Version: 1.16.3 Severity: normal The building of linux-tools yielded this architecture line: | Architecture: linux-any alpha amd64 armel armhf hppa i386 powerpc ppc64 s390 s390x sh4 sparc sparc64 This seems a tad ridiculous because linux-any is supposed to cover all those explicit architectures. (Which are listed for a single binary package.) Any tool looking for what to build on which architecture should only hit the linux-any bit. So I guess there should be an iteration in dpkg-dev to check equivalence with any wildcard specifiers in the list, to only add the architecture if it's not already covered? Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675717: override: infinoted-0.5:oldlibs/extra
Package: ftp.debian.org Severity: normal I changed infinoted-0.5 to be a transitional package and hence moved it from net/optional to oldlibs/extra. The overrides should be changed accordingly. Thanks Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677501: upgrade triggers systemd's cycle breaker due to rcS symlink
Package: schroot Version: 1.5.4-1 Severity: normal I just had to delete /etc/rcS.d/S22schroot to work around systemd's cycle breaker (which picked dbus.service annoyingly and hence breaks networking and gdm3): [ 71.726924] systemd[1]: Found ordering cycle on basic.target/start [ 71.726929] systemd[1]: Walked on cycle path to sockets.target/start [ 71.726932] systemd[1]: Walked on cycle path to dbus.socket/start [ 71.726934] systemd[1]: Walked on cycle path to sysinit.target/start [ 71.726937] systemd[1]: Walked on cycle path to schroot.service/start [ 71.726939] systemd[1]: Walked on cycle path to basic.target/start [ 71.726942] systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start [ 71.726949] systemd[1]: Found ordering cycle on basic.target/start [ 71.726952] systemd[1]: Walked on cycle path to sysinit.target/start [ 71.726954] systemd[1]: Walked on cycle path to schroot.service/start [ 71.726957] systemd[1]: Walked on cycle path to basic.target/start [ 71.726959] systemd[1]: Breaking ordering cycle by deleting job schroot.service/start The LSB headers do not agree with the rcS.d link being present at all (there's also no other rc2.d or anything symlink anymore): ### BEGIN INIT INFO # Provides: schroot # Required-Start:$local_fs $syslog $network $remote_fs # Required-Stop: $local_fs $syslog $network $remote_fs # Should-Start: lvm # Should-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Recover schroot sessions. # Description: Activate any persistent sessions after a reboot. #Setup scripts will be run to mount filesystems and #bring the chroot back to a working state. ### END INIT INFO 2012-06-13 12:58:09 upgrade schroot:amd64 1.4.26-1 1.5.4-1 pkern@spike:~$ find /etc/rc*.d -name '*schroot*' pkern@spike:~$ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages schroot depends on: ii libboost-filesystem1.49.0 1.49.0-3 ii libboost-iostreams1.49.01.49.0-3 ii libboost-program-options1.49.0 1.49.0-3 ii libboost-regex1.49.01.49.0-3 ii libboost-system1.49.0 1.49.0-3 ii libc6 2.13-33 ii libgcc1 1:4.7.0-8 ii liblockdev1 1.0.3-1.4+b2 ii libpam0g1.1.3-7.1 ii libstdc++6 4.7.0-8 ii libuuid12.20.1-5 ii schroot-common 1.5.4-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-modules | unionfs-modules none pn btrfs-tools none pn debootstrap 1.0.40 pn lvm22.02.95-4 pn qemu-user-staticnone -- Configuration Files: /etc/schroot/default/fstab changed [not included] -- 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#676686: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote: I did not suggest that. Anyway, maybe this will be a bit clearer. Let's say an existing package is at version +b1 on amd64, and it needs to get a binnmu, then a +b2 package is built on amd64, its changelog is taken and stuffed it into all of the other 'Multi-Arch: same' +b1 packages, which are now called +b2, and all of them uploaded. For various reasons you cannot do that without a rebuild. (Hint: Files must not change, new versions have their versions in various fields.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#676546: crashes after a random amount of time
Antoine, am Thu, Jun 14, 2012 at 04:44:54PM -0400 hast du folgendes geschrieben: Unfortunately, our crazy overuse of gobby 0.5 is now finished... due to the bug or the project being finished? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#677751: pu: package libmtp/1.0.3-1+squeeze1
On Sat, Jun 16, 2012 at 08:30:12PM +0200, Alessio Treglia wrote: On Sat, Jun 16, 2012 at 7:49 PM, Cyril Brulebois k...@debian.org wrote: this doesn't look too bad. Sure, a complete debdiff is attached. AFAICS you attached the same file again, which is not a debdiff. ;-) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#677501: [buildd-tools-devel] Bug#677501: upgrade triggers systemd's cycle breaker due to rcS symlink
On Sat, Jun 16, 2012 at 07:32:01PM +0100, Roger Leigh wrote: In 1.5, I fixed the LSB header to use standard runlevels. Unless dh_installinit isn't resetting the links automatically on upgrade, we probably want to force deletion and recreation of the links? I guess so, yeah. A bit strange that runlevel changes are not handled automatically… Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#678015: debian-installer: Guided partitioning took 26 hours to complete erasure of encripted LVM volume
On Mon, Jun 18, 2012 at 01:40:23PM -0300, Fernando J. RodrÃguez wrote: Please consider: a) changing the erase algorithm for someting more expeditive, even at the expense of some effectiveness; b) asking the user if she actually wants to erase the contents of the newly created volume; c) warning the user that the erasing could take more than 1 day. The latter probably makes sense. I'm pretty sure that the user is asked, because I always skipped it. On the other hand it's not for pre-existing data to be wiped but for the encrypted volume to appear completely random. Otherwise it's pretty obvious which blocks are allocated and which are not. (Not sure how useful that information is.) It's not about effectiveness but about security, sadly. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678172: zlib1g: binNMU broke multi-arch installability
On Wed, Jun 20, 2012 at 12:00:21AM +0100, Mark Brown wrote: Though looking at why this was done it's not clear to me why we're not doing this particular round of uploads for all arches... Because with the current buildd architecture you cannot get equal changelogs across all architectures, even if the version matches. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#678172: zlib1g: binNMU broke multi-arch installability
On Wed, Jun 20, 2012 at 12:00:21AM +0100, Mark Brown wrote: Though looking at why this was done it's not clear to me why we're not doing this particular round of uploads for all arches... I didn't get what you pointed at, but it was me who scheduled it. You built the package with an old version of debhelper and hence only the maintainer upload was using .gz. The buildd binaries were using .xz. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#406114: Processed: reopening 406114
On Tue, Jan 09, 2007 at 11:03:56PM +0100, Geert Stappers wrote: # Op 09-01-2007 om 19:09 schreef Frans Pop: # close 406114 # thanks # # Bug#406114: Installer netinst needs ping and better ifconfig # Bug reopened, originator not changed. # # There is absolutely no reason why this BR should remain open! As I said, # it's a duplicate and has absolutely no value by itself. # # Value in this bugreport is how to use wget as ping replacement # also is explained why ping is not in d-i Interestingly enough Ubuntu does ship a tiny ping in d-i which can tell you if $IP is alive or not. It would be very helpful to have. I cannot use wget to test if my gateway is reachable or not. And quite often (especially as d-i cannot cope sanely with /32 netmasks) I do need to ensure exactly that for the installer environment. A live CD wouldn't help. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678374: override: gobby:metapackages/optional
Package: ftp.debian.org Severity: normal The recent upload to NEW changed the section of gobby, too. It goes from net to metapackages, hence the override file needs editing to reflect this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678578: RM: rootskel-gtk [s390x] -- ROM; not supported on s390(x)
Package: ftp.debian.org Severity: normal I just blacklisted rootskel-gtk on s390 and s390x through P-a-s. On s390 it did not build due to it being in not-for-us. This was not copied over to s390x. Please remove the binary from unstable, thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64
On Sat, Dec 31, 2011 at 12:53:52PM -0400, Joey Hess wrote: Julien Cristau wrote: I'm not, I'm just looking at grep-excuses, which suggests either klibc-utils-floppy-udeb should exist on ia64 or rootskel-bootfloppy should be killed there. Quite likely rooskel-bootfloppy and klibc-utils-floppy-udeb should be killed *everywhere*. It's not like the kernel has fit on a floppy in 4 years on i386. At some point, leaving this cruft around in hopes that the kernel will magically be halfed in size is counterproductive. And what about floppy-retriever? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#678579: RM: lenny-support -- ROM; obsolete
Package: ftp.debian.org Severity: normal Lenny is no longer supported, hence this package (part of d-i) is no longer needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650060: NMU
On Fri, Jun 22, 2012 at 11:43:25PM +0200, Javier Fernandez-Sanguino wrote: Thanks for the NMU, I did not have time this week to make an upload myself. PS: If I have time I might make an upload soon with the same changes, in order to acknowledge the NMU FWIW you don't need to make an upload just to acknowledge a NMU, unless you have other changes planned. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#666879: s390(x): please add a netboot image
On Tue, Apr 03, 2012 at 03:54:12PM +0200, Mattias Wadenstein wrote: On Mon, 2 Apr 2012, Philipp Kern wrote: am Mon, Apr 02, 2012 at 03:49:48PM +0100 hast du folgendes geschrieben: OK. We also don't make *any* s390x images at all at the moment, which I should probably fix. Is d-i working on s390x? If so, I'll add it to the normal set of daily and weekly images. it's supposed to be working. If we drop the regular CD images, we could at least offer the netboot stuff in the same place? If cd1 is useful, why not build just that for s390[x]? 2x700 meg is hardly big today, and I wouldn't expect 70M or 700M be a significant difference in download times for anywhere with an s390. I don't consider CD1 useful for the reasons I mentioned in 20120516214232.gc20...@spike.0x539.de. It does make a time difference if you need to burn 700M instead of 70M as those additional bytes are wasted anyway. Is it possible to put the CD image somewhere FTPish verbatim and select it for installation? That would still mean that one would not use the CD directly unless it's not put into something s390'ish but a developer workstation. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#673671: wine-gecko-unstable: non-standard gcc/g++ used for build (gcc-4.5)
Package: wine-gecko-unstable Version: 1.0.0+dfsg-1.1 Severity: important User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.5 This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++. The build dependency in question: libstdc++6-4.5-dev Please keep this report open until the package uses the default compiler version for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.5 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes
Package: sbuild Version: 0.62.6-1 Severity: normal debian-archive-keyring does no longer include Debian archive keys in /etc/apt/trusted.gpg. sbuild-createchroot calls debootstrap specifying it explictly: I: Running debootstrap --arch=amd64 --variant=buildd --verbose --include=fakeroot,build-essential,debfoster --components=main --keyring=/etc/apt/trusted.gpg --resolve-deps sid /srv/chroots/sid-sbuild http://ftp.de.debian.org/debian/ debootstrap itself copes quite well without that setting. I'd suggest to only pass on --keyring if it got passed to the script itself. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sbuild depends on: ii adduser 3.113+nmu1 ii apt-utils 0.9.3 ii libsbuild-perl 0.62.6-1 ii perl5.14.2-9 ii perl-modules5.14.2-9 Versions of packages sbuild recommends: ii debootstrap 1.0.40 ii fakeroot 1.18.3-1 Versions of packages sbuild suggests: ii deborphan none ii wget 1.13.4-3 -- 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#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.
Niko, am Sun, May 20, 2012 at 10:59:28PM +0300 hast du folgendes geschrieben: It's a pointer cast in XML::LibXML::Document::toStringHTML, in LibXML.xs around line 2939. STRLEN len = 0; [...] htmlDocDumpMemory(self, result, (int*)len); [...] RETVAL = newSVpvn((char *)result, (STRLEN)len); (STRLEN is defined as a size_t via /usr/lib/perl/5.14/CORE/perl.h) See the attached patch, which just makes 'len' an int and removes the problematic pointer cast. I wonder if the STRLEN cast on becomes an issue, though. Is it possible that an int doesn't fit into a size_t variable somewhere? you cannot reinterpret a size_t as an int. size_t might be unsigned, might have another length, etc. On 64bit big endian you fill the top bits and leave the lower ones untouched, because size_t is 64bit. So yeah, that code was broken. (nbd had something similar, glib too. I don't know why it only turns up with 64bit big endian.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.
On Sun, May 20, 2012 at 10:37:00PM +0200, Bastian Blank wrote: On Sun, May 20, 2012 at 10:22:58PM +0200, Philipp Kern wrote: you cannot reinterpret a size_t as an int. size_t might be unsigned, might have another length, etc. On 64bit big endian you fill the top bits and leave the lower ones untouched, because size_t is 64bit. So yeah, that code was broken. (nbd had something similar, glib too. I don't know why it only turns up with 64bit big endian.) Because on little endian 64bit, it touches the lower bytes. Yeah, but that assumes that the other ones are 0? Or ok, maybe it's just working when going from size_t to int, because it's truncation, but it shouldn't work for the other way round? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#672658: please show the digest algorithm as a string in --list-packets
Hi Werner, thanks for your followup. On Wed, May 23, 2012 at 06:28:46PM +0200, Werner Koch wrote: On Sat, 12 May 2012 19:34, pk...@debian.org said: If I do --list-packets I get lines like this: digest algo 8, begin of digest cd 52 would be very helpful if gnupg could name the digest algorithm here (either --list-packets is a GnuPG debug aid and it is expected that a developer knows the algorithm ids. Fair enough. But --list-sigs doesn't list the signature algorithm used neither. It is exported anywhere accessible for the user? Indeed I do know how to decipher it[0]. However Debian did place an emphasis on using SHA256 instead of SHA1 (or MD5 for that matter) for signatures and providing a bit more visibility would've been helpful. Kind regards Philipp Kern [0] http://tools.ietf.org/html/rfc4880#section-9.4 signature.asc Description: Digital signature
Bug#681178: unblock: libburn/1.2.2-2
On Wed, Jul 11, 2012 at 08:27:23AM +0200, George Danchev wrote: I've got three minor bugfixes from not yet released libburn 1.2.4, which I'd like to apply to libburn/1.2.2-1. I've not yet uploaded libburn 1.2.2-2, so this is a request for upload to sid and unblock. Both, Thomas Schmitt and I agree we want them in wheezy. Our test suite found in libisoburn/releng, which tries to cover most of the libburn, libisofs, libisoburn functionality reveals no regressions. Please go ahead. I cannot do the unblock right away though. Please ping after it got accepted. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#681804: unblock: python-pyxattr/0.5.1-1.1
On Mon, Jul 16, 2012 at 01:49:17PM -0400, Scott Kitterman wrote: Fixes RC Bug #680859. Currently in delay/2. Given the maintainer's response in the bug report, I suggest that you reschedule that to 0-days. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Sun, Jul 15, 2012 at 07:05:35PM -0400, Michael Gilbert wrote: We are still in the early freeze where riskier changes are allowable, aren't we? No. There's no such thing as an early freeze that allows riskier changes this cycle. We might be convinced that certain delays in preparing a final package for the next release might have been someone else's fault, but that's no go for risky changes. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679554: Bug#680622: unblock: goobox/3.0.1-5, was Re: Bug#680622: unblock: goobox/3.0.1-4
On Thu, Jul 12, 2012 at 10:32:07PM +0200, Helge Kreutzmann wrote: unblock goobox/3.0.1-5 Done, thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#627174: Bug#681398: release.debian.org: maintainer (both Debian and upstream lost intrest) see #627174
On Thu, Jul 12, 2012 at 09:46:01PM +0100, Nicholas Bamber wrote: The Debian/upstream maintainer says: SD has fallen from my priorities, and to have it be worth keeping in Debian at this point, I think someone else will need to step up and work on maintenance upstream. I've asked in #debian-perl but noone has expressed an interest so I propose removing it. I've added a removal hint based on #627174. As Adam said: If nobody cares about it remaining in Debian, it should also be removed from unstable. If somebody steps up and fixes #627174 it can also be readded to testing, if it's within 20 days of the removal. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#682046: unblock: django-celery/2.5.5-2
On Thu, Jul 19, 2012 at 07:30:49AM +0200, Michael Fladischer wrote: It fixes a FTBFS which occured because it tried to connect to github while building the documentation. There's now a patch included to disable this behaviour in the upstream documentation during build, controllable through an environment variable. debdiff is attached. unblock django-celery/2.5.5-2 And the buildsystem uses hasattr or something similar to access the issuetracker* variables? Because they're now left undefined… Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#652593: grub-pc: fails to boot with unaligned pointer on KVM
On Sat, Jan 14, 2012 at 10:24:24PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
I would need grub.cfg.
It's a stock grub.cfg, as attached. It simply fails with qxl on kvm/wheezy and
works with cirrus as the video driver. Reproducable on a fresh squeeze-amd64
install on libvirt/kvm/wheezy.
= Installation/d-i boots fine; grub fails.
Kind regards
Philipp Kern
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set ccf0ea28-77f9-4597-82d0-867e320e8066
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set ccf0ea28-77f9-4597-82d0-867e320e8066
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian --class
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set ccf0ea28-77f9-4597-82d0-867e320e8066
echo'Loading Linux 2.6.32-5-amd64 ...'
linux /boot/vmlinuz-2.6.32-5-amd64
root=UUID=ccf0ea28-77f9-4597-82d0-867e320e8066 ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-2.6.32-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64 (recovery mode)' --class
debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set ccf0ea28-77f9-4597-82d0-867e320e8066
echo'Loading Linux 2.6.32-5-amd64 ...'
linux /boot/vmlinuz-2.6.32-5-amd64
root=UUID=ccf0ea28-77f9-4597-82d0-867e320e8066 ro single
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-2.6.32-5-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
signature.asc
Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
On Sat, Jul 21, 2012 at 11:02:33AM +0200, Jonas Smedegaard wrote: Then reject it, if you find it too unpleasing!!! I hope you realize that Cyril is only doing his job. You're not being helpful and albeit I'm tempted to just say No problem to that statement it would still leave an RC bug open. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#682314: pu: package debian-archive-keyring/2010.08.28(+squeeze1)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu I would like to update debian-archive-keyring in stable to add both the wheezy automatic (ftp-master) and wheezy stable (release) keys. The debdiff is attached. An upgrade to 2012.4 seems to work just fine. After that's accepted we should look at a soon to be done point release to include it. Kind regards Philipp Kern diff -Nru debian-archive-keyring-2010.08.28/active-keys/add-wheezy-automatic debian-archive-keyring-2010.08.28+squeeze1/active-keys/add-wheezy-automatic --- debian-archive-keyring-2010.08.28/active-keys/add-wheezy-automatic 1970-01-01 01:00:00.0 +0100 +++ debian-archive-keyring-2010.08.28+squeeze1/active-keys/add-wheezy-automatic 2012-07-21 14:54:37.0 +0200 @@ -0,0 +1,89 @@ +Comment: add Wheezy automatic key +Date: Sun, 13 May 2012 17:09:05 +0200 +Action: import +Data: + -BEGIN PGP PUBLIC KEY BLOCK- + Version: GnuPG v1.4.12 (GNU/Linux) + + mQINBE+a7rUBEADQiEKtLOgqiq8YY/p7IFODMqGPR+o1vtXaksie8iTOh3Vxab38 + cA3kK1iB5XYElbZ5b/x3vWiufHK2semOpn5MG2GRJUwmKxZbt3HLZiHtAadkby2l + rnMxeIzfxcTxloxsQ02TMRalq89Xvy6P7lgedcW5ujcMR6JbE6uL1c/jNlkIPNuN + 9paZsNJWXnZ03R+NrAJLjOPUZKZRPYgIwEci2sVNA/autsJL+HuW6X8PfldvMe5h + SdWelOoXMsZMX04JP8Efq8a09yIgKBfuXjoHJbtK0rTr9tjFKt/VM6MejLdJf4Dl + r6Zhx2ygmjcvj+FlWFoxDlPHdqfZ6mGsKR4eWDRu3bZtalDNvhZKvecwf0KaAWVU + M+GxkR+Ol3TsQ0tLbjbwZhWMioipR8Lsp6kZ1tLUjM0aOR3Mw/csyFJYKFiCo3GR + QSGY0++cDrfhQRwOJ9s2eeGGS1/I95vJZA5zZnx1ksnO0W2fHVBavICR821EBAEZ + slLzr+IOrbB16YE/aN2iA9nTcQVk69XeEh5gaeiCZ7JhA2nkAg8a/H1r4BVBC/cL + egzhUvP90kk94MmL1D2gY6UlyK4yTnHgVfjsQw6u2sPDlramyXBZehnKabIndM1P + 368IbW8GTNo0gNwg/oC/vENwYnAuX+S96/O/1XfQoBNr+epTVdS4VQHICQARAQAB + tEhEZWJpYW4gQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDcuMC93aGVl + enkpIDxmdHBtYXN0ZXJAZGViaWFuLm9yZz6JAj4EEwEIACgFAk+a7rUCGwMFCQ8J + nAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEItIrWJGklVTdQEQAMLCmMQr + 7SxFULYgprbr5eO6uAs/8nkIBhJBzUnenOUnwsOR3Io9/sHc8Cq/xv1DTsY5G5Qj + ojywslbeF44TxBZ0j3UwPU437bfNs7yTRkgPVhHK/rZ9ApbnZdCmud+BUkDOChLV + 8fzCZ17Pa5eMr5E4WI0bLM5AA3vVFLBgHFqJUgE7mSn95vA1S881/xOQ4lT1WHfa + O9K96X6ekn2zpPu/G8aq+oDyVGfo1AKQCPBJ3OCX0WB3GNWbcCb850gy9vtKlWDu + yAh1a9Cl5OPHlYqz8q+Hqj4ZeRgJiDgCgm8YAlKEooEG/vJzswaY+C3nz6uNfBeq + 60QhPfgaO8qGlriChGAFqzD68ZQ53NApJw/OuwV2p5CgnkyGAVGZ1WuYcXz/wHyU + awnXq3Bf69RJssbab6SqptJyYuiY8T/2vWRgQxej18KAZ0v1Vr/MC1azp6TWgfSl + s2fvGvPf9vEbKyBR3YFa5msRKGpRauv4wWmcLfZ+jMLbSAWBfILPK+fGLtRGz4AX + hRht9rX7c4neQvlBNDDgR3tuaE3s0B1B6gTcvq7EhuuP4pAzkBLhpuzolvw+ZFOV + 5mElfScYi8QbQgT9t2XjUDU1oz1ewviNhynpsxh51t5qxP5ETDGKvEx7RMv4S08p + 5VGG4Y+kjcsQWfAdVAGuLqWOI0sGzUzKYZppiEYEExECAAYFAk+a8vAACgkQcV7W + oH57isk7FACcCIOIMr39LUSv16Ec9V102uheqlsAnRqdAADYF7iJIrfqyb72s/54 + 3JFaiQJGBBMBCAAwBQJPmvMiBxpzdHJpbmchGmh0dHA6Ly9ncGcuZ2FubmVmZi5k + ZS9wb2xpY3kudHh0AAoJENsWz1uxJSXEhEYP/in+rib86H2vPG+ALZ35o4eh1+9P + KLtUwgHB3Wr/rmPuPY5uB02H/p3PxgJHXUXUPAleN6uajZvReO1wWLTYspPAK8ZF + 6p52vuyHgOZl+VmGkLgYKOG/cckqQqTTaHwQj0O8pllJjOJYVdt5iWAHkf1N1UAA + nXC2GdxV+ZVGvZjjCDL8WFWCfoY4HznslcEHQKxg7vzZvVMTjY6L+8NmWkVoD4JL + kYtQOrId1wWYInJiQRtilyn7n9mJ+rTBSETB9Evs3x+zmNa3ntY1/U8XINgxVA5U + GYyUfUug2DjZ90LfXyZUOXVLE5yM1x7oOpyg/1mMtl5xkmuqJHOTeVEjQBYfMRHi + sS4ainR5AoD1Z5KV4S0opt198LDMXGLNjUdJEG24QEK5tfgTFRgFRJYiufxDelI3 + Aq5uGVRrBJygjwaQiJLUVlMqBGHJi++zeWr767pHVWB1XqdmPRvvOqH2v/ez4bSW + zIkUDTr947qmjyAqNNmCv/jgV5viqbj5LNslBkFg8OS+6O7na2gU5ldXfBoC0nso + 3pdsCuOYUIrHyP/GjT1gvG0m+jZ/15bvoWvUv4Buh+3gYVyLwrgbq7UISRfwQEah + yzIrO5MvgS0MTIlOgO7Lxog2XMEkQ1ZCbLu5Rvm/8LC0UlSxW9aOIKBSC3hi7U8E + BuA24Mv5Iz7QvO+giQEcBBABAgAGBQJPmwDBAAoJEF7K+wCjrkSkkq8H/3M/M+Xb + vI0cY3MOkFMtyG7xmxPcny1/arnQDvjvpv1BhRBnVTstMxHWzAFQf3M8KttARWo4 + C6U5Cbc0Jx6avqXZwop91a8tQORErC9Kcrr27FJfNAOP5AVzXAofpZyXvouFYBig + ikHdRJlFrn9rydvK9Z5vg63ZzsRB7hTtHi/j1o7d0IpVmR2iTnbWGiUxpnRdLhEF + AnUU+TDFVg6EoJ6aeKsLa43UPHizq12WZPd72cJNSLMk/u+UZvg4sa7pOrkJNYN1 + jL7BSphwKCuA8vBc2lLO14uYDO8LHjd4opatMWCEEvnJQS98JytIkYcwJhJ/IgCz + tqAUo44SUcOodNGJAhwEEAECAAYFAk+bA/IACgkQvDciUsoc+WRWgA/9FYi1aqas + fJyRV4pfe90KhJ4uOO17ivnjULIDU4QFSdJpkCPznxadlDeyRbX/FhVu3RMzldIu + ZVly+VPqWwubudj9SVnqJxGkua2kEz8u3X96zif+nSB4wQuWLi4GOG9AYTnuNnZI + hO4RctYpEi9duBsPeewNi2zjUe8akhJacMhJflbW/XGsRf4goeL3WrB+k5DiDphm + nw2dge96uhZhM+Ih4hSoD9d+YLZbTqXX4L93jELE72UF4qnrZjYJtx8TSto9W2bj + sGFmpUB41viFtdnABLv5MhMsvlM37w8HTbKzzCYImgzBJNZ8Wr+VAeeQ/uB+izVv + Ls6aVKcwH2r8D+MMvh5d160lAJSUDXvZ0kdzawtBMzaNOIEYuQqoQxQGXvSAMRDV + 2xFEn/XRT4iRl1stLvX86SMpLksbBfxZnrV9Q+OfTpar5O21sb1dpkgfWoF6W0kc + rjuAAsI3EbMuX3eK8r5SjWCLfIaU9ton+CdeJjJipEsEox7Rlq075t+6S4LL4wqq + dJPX4Rcuwx4LPXi9NKZAuQHisp1nuVV4luXttMdYfFq5QtokhjUaedAOORDy4gsC + mAMyLWgU/2r0grK7+AVLfn1p9wFb9FoBGFILcjVMAiY3OE5tNVPay9wGoD6n/h0O + cteh2rBrB7kEpXjRqasNfRl8vvlz7nWhTIKJAhwEEAEIAAYFAk+bAq8ACgkQEbTl + /xWw/YKuew/9Fub3t/nejgJ5KkjhfFppQQkE1yg2VJP3cbnrrhrAYZX6E6jN7dAI + MlpKqm4YR6FFe5bkra61TeXd2CI5E/MDdW4Q+AD66tA0xKRm5RzVuPvWoR9vyCx/ + fPlRuVZptwczeV5bKTFyflICV3Z/R5llq2aT6M
Bug#682314: pu: package debian-archive-keyring/2010.08.28(+squeeze1)
On Sat, Jul 21, 2012 at 03:14:54PM +0100, Adam D. Barratt wrote: On Sat, 2012-07-21 at 15:04 +0200, Philipp Kern wrote: I would like to update debian-archive-keyring in stable to add both the wheezy automatic (ftp-master) and wheezy stable (release) keys. The debdiff is attached. An upgrade to 2012.4 seems to work just fine. Please go ahead; thanks. Uploaded. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#670603: ITP: php-mdb2 -- a merge of the PEAR DB and Metabase php database abstraction layers
On Fri, Apr 27, 2012 at 04:44:24PM +0800, Thomas Goirand wrote: * Package name: php-mdb2 Version : 2.5.0b3 php-mdb2 is already in Debian. This is a request from people packaging ownCloud. So why do they need to request this? Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#670597: libc6: /lib/ld-linux.so.3 symlink not set
On Fri, Apr 27, 2012 at 12:04:29PM +, Adam Conrad wrote: Closing this bug, as it was discovered that the failing binaries in question were from debian-ports, not from debian.org. Maintaining backward compat with non-official archives is a non-starter, and hopefully most people know how to work around this with violent apt-pinning sidegrades, or reinstalling from the official archive. However it would be nice if you could avoid breaking all our official buildds in the process next time. I.e. a notice *before* breaking the ports' users would've been helpful, especially as that change wasn't particularly time critical *for Debian*. Thanks Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670858: RM: node/0.3.2-7.1
On Sun, Apr 29, 2012 at 01:27:32PM -0500, Jonathan Nieder wrote: Please remove the ham radio server node from testing. The release-critical bug #614907 has had no action for several months despite a starting patch and various compromises offered, and I am not confident that the bug will be fixed in time for wheezy. nodejs is not in testing, so #614907 cannot, as a conflict solely within unstable, be a rationale by itself for testing removal. (I'm with you that it should be resolved with nodejs getting the name, but that's my personal opinion.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669427: apt segfaults on s390x
On Fri, Apr 20, 2012 at 11:26:57PM +0200, Philipp Kern wrote:
On Fri, Apr 20, 2012 at 10:04:28PM +0200, Philipp Kern wrote:
On Thu, Apr 19, 2012 at 09:12:09PM +0200, Mehdi Dogguy wrote:
On 19/04/12 20:21, Faidon Liambotis wrote:
Package: apt
Version: 0.9.1
Severity: serious
apt 0.9.1 currently segfaults on the zelenka (our s390/s390x porterbox)
sid_s390x chroot. Downgrading apt to 0.8.15.10 makes it work again.
Does it also segfault on s390? (s390x is not a release arch yet so
it doesn't warrant an RC severity, unless the maintainer thinks so).
It breaks many package builds on s390x and it's broken on an
architecture where it built before.
And wrt s390x I can pull a Hurd: The current progress is however
encouraging.
It's in the construction of the MD5SumValue. But I'm not prepared to curse at
bzr for the remainder of the evening, about a bisect plugin that frankly
doesn't do what it's supposed to do.
2129.4.17 kalnisc |/* Record the Description (it is not translated) */
|MD5SumValue CurMd5 = List.Description_md5();
|if (CurMd5.Value().empty() == true)
| return true;
|std::string CurLang = List.DescriptionLanguage();
|
|/* Before we add a new description we first search in
the group for
| a version with a description of the same MD5 - if so
we reuse this
| description group instead of creating our own for
this version */
|for (pkgCache::PkgIterator P = Grp.PackageList();
|P.end() == false; P = Grp.NextPkg(P))
|{
| for (pkgCache::VerIterator V = P.VersionList();
| V.end() == false; ++V)
| {
| if (IsDuplicateDescription(V.DescriptionList(),
CurMd5, ) == false)
|continue;
| Ver-DescriptionList = V-DescriptionList;
| return true;
| }
|}
When IsDuplicateDescription is called, calling md5() on the V.DescriptionList()
points to unallocated memory. Any idea why that could be?
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Bug#671066: ftp.debian.org: upload urgencies should not accumulate
On Tue, May 01, 2012 at 07:10:20PM +0200, Ansgar Burchardt wrote: Santiago Vila sanv...@unex.es writes: I see that diffutils_1:3.2-6, which was uploaded with urgency=low, will only need 5 days to enter testing, probably because I made 1:3.2-4 to be urgency=medium. I don't know when you changed the algorithm but I think it is a bad change. In this case, the reason to modify the urgency was that 1:3.2-4 just tried to disable a test which failed, while 1:3.2-6 has real code changes which IMHO, deserve the usual 10 days in unstable. The traditional meaning of urgency has always been the time required for *this* upload to supersede the version currently in testing and that's why I used urgency=low in 1:3.2-6. However, if urgencies accumulate, how are we supposed to really mean 10 days after an upload not of low priority? It's impossible! No. The idea is that if you specify urgency=medium that *this* *change* (not upload!) should go into testing in an expedited fashion. If you then go and upload something else in the meantime that's your problem, as we still want the change in testing. You could a) wait for the previous version to hit testing or b) ask the release team to override the urgency of your most recent upload. The only case where urgencies should not accumulate is if you take a different branch and upload it without the changes in the previous version. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#669427: apt segfaults on s390x
On Wed, May 02, 2012 at 05:23:30PM +0200, David Kalnischkies wrote:
2129.4.17 kalnisc | /* Record the Description (it is not translated) */
| MD5SumValue CurMd5 = List.Description_md5();
| if (CurMd5.Value().empty() == true)
| return true;
| std::string CurLang = List.DescriptionLanguage();
|
| /* Before we add a new description we first search
in the group for
| a version with a description of the same MD5 - if
so we reuse this
| description group instead of creating our own for
this version */
| for (pkgCache::PkgIterator P = Grp.PackageList();
| P.end() == false; P = Grp.NextPkg(P))
| {
| for (pkgCache::VerIterator V = P.VersionList();
| V.end() == false; ++V)
| {
| if (IsDuplicateDescription(V.DescriptionList(),
CurMd5, ) == false)
| continue;
| Ver-DescriptionList = V-DescriptionList;
| return true;
| }
| }
When IsDuplicateDescription is called, calling md5() on the
V.DescriptionList()
points to unallocated memory. Any idea why that could be?
So you mean the Description struct is invalid (V.DescriptionList()) or
the V.DescriptionList().md5() char* ?
The latter does not point to any initialized memory.
We are missing a bit of error checking here (callers of NewDescription() do
not check if return is != 0 and IsDuplicateDescription doesn't check if the
given Description is valid), but both shouldn't be a problem as NewDescription
can only really fail if new memory can't be allocated and as each version has
at least one description you shouldn't hit a problem in the dup check either.
Both wouldn't be limited to s390x either way:
We seem to have a similar bugreport from ppc64 (#669243),
if i understand right it's also bigendian 64bit, but no other report.
Yes. So would be sparc64. s390x is the only in-archive arch that's 64bit be.
The code in pkgcachegen.cc was reworked for multi-arch and especially the dup
check is new and the code as such works wih pointer left and right, but non of
it should be architecture dependent… Somehow i fear that it's more related to
our checksum changes. We had way to many problems with sha1 and sha2 to assume
md5 would be okay (the code for md5 itself is not new, but the code warping
around it).
At least the problem was not in constructing the checksum object, but in
retrieving the content for it (i.e. md5() in IsDuplicateDescription).
You mentioned bisecting? Any insigns which revisions are (not) effected?
(bzr has no bisect included by default, and last time i check the plugin was…
lets say suboptimal for us as we tend to have big merges)
Either the plugin was broken or the tree it acted upon was useless to bisect.
I don't know.
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Bug#671609: dot2texi broken with current texlive
Package: texlive-pictures
Version: 2011.20120424-1
Severity: important
Tags: patch
Hi,
dot2texi got broken by the recent texlive upload. According to [0], the
following line needs to be inserted after moreverb is loaded in dot2texi.sty:
\@ifundefined{verbatim@out}{\newwrite\verbatim@out}{}%
[0] https://groups.google.com/forum/?fromgroups#!topic/dot2tex-users/kbjZGRVT5SY
I can confirm that the file that worked with the old texlive then compiles
successfully with that fix. (And the output is identical, too.)
Thanks for maintaining (and updating!) texlive,
Philipp Kern
##
List of ls-R files
-rw-r--r-- 1 root root 1637 May 5 13:03 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Apr 23 16:04 /usr/share/texmf/ls-R -
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Apr 25 00:16 /usr/share/texlive/texmf/ls-R -
/var/lib/texmf/ls-R-TEXLIVEMAIN
-rw-rw-r-- 1 root staff 80 Jul 11 2011 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 31 Apr 25 00:16 /usr/share/texlive/texmf-dist/ls-R -
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Apr 25 00:16 /usr/share/texlive/texmf-dist/ls-R -
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Apr 25 00:16 /usr/share/texlive/texmf/ls-R -
/var/lib/texmf/ls-R-TEXLIVEMAIN
##
Config files
-rw-r--r-- 1 root root 1101 May 5 13:02 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 4745 May 5 13:03 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Apr 25 00:16 /usr/share/texmf/web2c/updmap.cfg -
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3886 May 5 13:03
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Mar 23 2011 mktex.cnf
-rw-r--r-- 1 root root 1101 May 5 13:02 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
055e06548bac99958d8ab2dd1248f2b4 /etc/texmf/texmf.d/80tex4ht.cnf
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages texlive-pictures depends on:
ii dpkg 1.16.2
ii luatex0.70.1-3
ii tex-common3.10
ii texlive-base 2011.20120424-1
ii texlive-binaries 2011.20120410-1
ii texlive-common2011.20120424-1
Versions of packages texlive-pictures recommends:
ii pgf 2.10-1
ii ruby4.8
ii ruby1.8 [ruby-interpreter] 1.8.7.352-2
ii texlive-pictures-doc2011.20120424-1
ii tk8.5 [wish]8.5.11-1
Versions of packages texlive-pictures suggests:
ii dot2tex 2.8.7+repack-1
Versions of packages tex-common depends on:
ii debconf [debconf-2.0] 1.5.42
ii dpkg 1.16.2
ii ucf3.0025+nmu3
Versions of packages tex-common suggests:
ii debhelper 9.20120419
Versions of packages texlive-pictures is related to:
ii tex-common3.10
ii texlive-binaries 2011.20120410-1
-- debconf information:
tex-common/check_texmf_wrong:
tex-common/check_texmf_missing:
-- debsums errors found:
debsums: changed file
/usr/share/texlive/texmf-dist/tex/latex/dot2texi/dot2texi.sty (from
texlive-pictures package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671609: dot2texi broken with current texlive
On Sat, May 05, 2012 at 11:30:09PM +0200, Hilmar Preuße wrote: Thanks for the bug report. I don't think that severity is important - lowering to normal. Fair enough. It does break a component, though. As I could see in the google groups thread the upstream author is already informed. So I just mark the bug as forwarded, no we don't intend to patch the file in Debian. Please install the fixed version in your local texmf tree. He's aware of it since a year, yes. Fact is: It's broken in Debian and it does break TeX files that use it. I didn't notice that it's some sort of contrib thing, which is what CTAN suggests. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#644705: FTBFS on s390: symbols out of sync
On Sat, Oct 08, 2011 at 01:04:06PM +0200, Lucas Nussbaum wrote: On 08/10/11 at 12:05 +0200, Philipp Kern wrote: Package: ruby1.9.1 Version: 1.9.3~rc1-2 Severity: serious On Sat, Oct 08, 2011 at 10:00:23AM +, buildd on zandonai wrote: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libruby1.9.1/DEBIAN/symbols doesn't match completely debian/libruby1.9.1.symbols --- debian/libruby1.9.1.symbols (libruby1.9.1_1.9.3~rc1-2_s390) +++ dpkg-gensymbolsMk4RbV 2011-10-08 10:00:22.0 + @@ -584,9 +584,9 @@ rb_find_file_ext@Base 1.9.2.0 rb_find_file_ext_safe@Base 1.9.2.0 rb_find_file_safe@Base 1.9.2.0 - rb_fix2int@Base 1.9.2.0 +#MISSING: 1.9.3~rc1-2# rb_fix2int@Base 1.9.2.0 Yes, kind-of expected. Do you know what's the correct way to handle different symbols on different archs, without generating one symbols file per arch? You can annotate it with (arch=!s390 !...|optional) I think. See geotranz for example. (But that's C++.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#593951: debian-archive-keyring: misses a call to `apt-key update' as a postrm script
clone 593951 -1 reassign -1 apt thanks On Sun, Aug 22, 2010 at 05:07:59PM +0200, Carsten Hey wrote: debian-archive-keyring should remove old keys on upgrades, see forwarded mail. The call to apt-key update should only be run if apt-key and gpg both can be found since dependencies are not guaranteed to be available in postrm. The check for gpg to be available is necessary because apt could possibly recommend gnupg in future and thus apt-key could be available but not gpg. So it could be something like this: | if [ -x /usr/bin/apt-key ] [ -x /usr/bin/gpg ]; then | /usr/bin/apt-key update | fi That doesn't actually work because `apt-key update' checks for the presence of the archive keyring prior to doing something. So this would either need to be unrolled into a loop calling `apt-key del' or by somehow passing in the archive keyring as a removed keyring as a prerm. (I also don't think it should be our job to check if all binaries used by apt-key are available.) Clone'd and reassign'd to apt for input by the apt maintainers if they intend to provide an interface for this (admittedly minor, at least for Debian) use case. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#629204: Patch
Hi, On Sat, Sep 10, 2011 at 12:27:53PM +0200, Federico Giménez Nieto wrote: tags 629204 patch 2011-08-17 Federico Gimenez Nieto fgime...@coit.es * Modified function calls for Modern GNU Objective-C runtime API following changes of source at http://svn.gna.org/viewcvs/gnustep/libs/gdl2/trunk/ your patch does not apply on top of the patch set that's already included in the package. Can you please fix this and prepare a MU? This blocks the completion of the gnustep transition. Thank you Philipp Kern signature.asc Description: Digital signature
Bug#531324: Current state
The current state of the ITP is as follows: The game is packaged and available from [0] for Ubuntu. The package should be policy compliant and is re-buildable on Debian as-is. (I build and use it on Debian.) The sounds as currently provided are not DFSG-free. Not shipping the sounds breaks network play, however, because the assets are checked on startup. The newest upstream release resolved the problems with not DFSG-free textures, so there's clearly progress. The game's assets are not built from the resource files, though, so we rely on them being regenerateable by other means. The resources tarball is just shipped to provide the original source files. It's not exactly guaranteed that the assets are updateable using main tools, but they probably are. [0] https://launchpad.net/~openclonkdevteam/+archive/release signature.asc Description: Digital signature
Bug#644935: must not use a fixed/predictable temporary file name
Package: minitube Version: 1.5-1 Severity: serious Playing /tmp/minitube-pkern.mp4 This allows a hostile user to overwrite any file the user controls with YouTube content. Bad. /tmp is world-writeable and must not be used with predictable filenames. Instead you need to employ secure temporary file creation. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minitube depends on: ii dbus-x111.4.16-1 ii gstreamer0.10-ffmpeg0.10.12-3 ii gstreamer0.10-plugins-bad 0.10.22-3 ii gstreamer0.10-plugins-good 0.10.30-1 ii gstreamer0.10-x 0.10.35-1 ii libc6 2.13-21 ii libgcc1 1:4.6.1-4 ii libphonon4 4:4.6.0really4.5.0-5 ii libqt4-dbus 4:4.7.3-5 ii libqt4-network 4:4.7.3-5 ii libqt4-xml 4:4.7.3-5 ii libqtcore4 4:4.7.3-5 ii libqtgui4 4:4.7.3-5 ii libstdc++6 4.6.1-4 ii phonon 4:4.6.0really4.5.0-5 ii phonon-backend-gstreamer4:4.6.0really4.5.1-1 minitube recommends no packages. minitube 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#645404: FTBFS: rm: cannot remove `debian/xye-data/usr/share/xye/res/detailed_COPYING': No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: xye Severity: serious Version: 0.11.2-1 The package FTBFSes on all architectures: On Thu, Oct 13, 2011 at 11:59:17PM +, buildd on zandonai wrote: /usr/bin/install -c -m 644 'res/default_icon.png' '/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2/debian/tmp/usr/share/xye/res/default_icon.png' /usr/bin/install -c -m 644 'res/kye_icon.png' '/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2/debian/tmp/usr/share/xye/res/kye_icon.png' /usr/bin/install -c -m 644 'res/detailed_COPYING' '/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2/debian/tmp/usr/share/xye/res/detailed_COPYING' make[2]: Leaving directory `/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2' make[1]: Leaving directory `/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2' debian/rules override_dh_install make[1]: Entering directory `/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2' dh_install rm debian/xye-data/usr/share/xye/res/detailed_COPYING rm: cannot remove `debian/xye-data/usr/share/xye/res/detailed_COPYING': No such file or directory make[1]: *** [override_dh_install] Error 1 make[1]: Leaving directory `/build/buildd-xye_0.11.2-1-s390-rSniQx/xye-0.11.2' make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 Build finished at 20111013-2359 FAILED [dpkg-buildpackage died] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAk6ZjsgACgkQ7Ro5M7LPzdhuXgCfb+boBm3kiiOsMEqprGU/hpUT ZT0AoOeX7UJjqy0uxgS2QtTZbkdVm9v8 =swTo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634413: [PATCH] build libgmock.a with tests
On Sat, Sep 10, 2011 at 04:12:42PM +0200, Philipp Kern wrote:
On Mon, Aug 29, 2011 at 09:01:12PM +0800, Daniel Hartwig wrote:
On 29 August 2011 01:36, Daniel Hartwig mand...@gmail.com wrote:
tags 634413 + patch
quit
Re: #634413 aptitude: FTBFS: ld: cannot find -lgmock
...
Nevermind, I have just seen that this was already fixed in git on 23/7
Should have checked ;)
can we have the fix in unstable, please? :)
I just uploaded the attached NMU to DELAYED/0-days. (And mailed a git
commit to dburrows for inclusion into the aptitude repository because
there's a bug in the recent gmock fix.)
Kind regards
Philipp Kern
diff -Nru aptitude-0.6.4/debian/changelog aptitude-0.6.4/debian/changelog
--- aptitude-0.6.4/debian/changelog 2011-05-16 18:05:00.0 +0200
+++ aptitude-0.6.4/debian/changelog 2011-10-16 22:30:18.0 +0200
@@ -1,3 +1,10 @@
+aptitude (0.6.4-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix FTBFS due to changes in google-mock. (Closes: #634413)
+
+ -- Philipp Kern pk...@debian.org Sun, 16 Oct 2011 22:29:57 +0200
+
aptitude (0.6.4-1) unstable; urgency=low
* New upstream release.
diff -Nru
aptitude-0.6.4/debian/patches/0001-Modify-autoconf-automake-scripts-to-handle-gmock-cha.patch
aptitude-0.6.4/debian/patches/0001-Modify-autoconf-automake-scripts-to-handle-gmock-cha.patch
---
aptitude-0.6.4/debian/patches/0001-Modify-autoconf-automake-scripts-to-handle-gmock-cha.patch
1970-01-01 01:00:00.0 +0100
+++
aptitude-0.6.4/debian/patches/0001-Modify-autoconf-automake-scripts-to-handle-gmock-cha.patch
2011-10-16 22:29:46.0 +0200
@@ -0,0 +1,113 @@
+From 942616a01dfdebe8e040ce459f07d7527220ed9b Mon Sep 17 00:00:00 2001
+From: Daniel Burrows dburr...@debian.org
+Date: Sat, 23 Jul 2011 15:51:23 -0700
+Subject: [PATCH 1/2] Modify autoconf/automake scripts to handle gmock
+ changes.
+
+---
+ configure.ac | 51 +--
+ tests/Makefile.am | 12 +++-
+ 2 files changed, 60 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index c0a6862..b0ef2a3 100644
+--- a/configure.ac
b/configure.ac
+@@ -23,8 +23,7 @@ ac_cv_c_const=yes
+ ac_cv_c_inline=yes
+
+ dnl Checks for libraries.
+-AC_CHECK_LIB(ncursesw, initscr, ,
+- [AC_MSG_ERROR([Can't find libncursesw -- please install
libncursesw5-dev])])
++AC_CHECK_LIB(ncursesw, initscr, , [AC_MSG_ERROR([Can't find libncursesw --
please install libncursesw5-dev])])
+ AC_CHECK_LIB(apt-pkg, main, , [AC_MSG_ERROR([Can't find the APT libraries --
please install libapt-pkg-dev])])
+
+ AC_MSG_CHECKING([whether apt includes the automatic dependency removal patch
(required)])
+@@ -482,6 +481,54 @@ AC_SUBST(BOOST_UNIT_TEST_LIBS)
+
+ # End Boost.Test check #
+
++# Check for Google Mock #
++
++dnl Google Mock's developers do not support prebuilt libraries (e.g.,
++dnl they pay no attention to ABI compatibility) and as a result have
++dnl asked Debian not to ship prebuilt libraries. So, if we are
++dnl running on a system where gmock isn't available in $LIBDIR, we
++dnl guess that maybe there's source available that we can compile
++dnl during our own build process.
++
++AC_MSG_CHECKING([how to link gmock])
++
++BUILD_LOCAL_GMOCK=0
++
++OLD_LIBS=$LIBS
++LIBS=$LIBS -lgmock
++
++AC_LINK_IFELSE([AC_LANG_SOURCE([
++#include gmock/gmock.h
++
++int main(int argc, char **argv)
++{
++ return 0;
++}])],
++[AC_MSG_RESULT([gmock is in in library path])]
++,
++dnl Ok, check whether we can link it if we include the gmock
++dnl source code. Note that it will require both pthreads and
++dnl gtest; no way around that.
++[LIBS=$OLD_LIBS -lpthread -lgtest
++ OLD_CPPFLAGS=$CPPFLAGS
++ CPPFLAGS=$CPPFLAGS -I/usr/src/gmock
++ AC_LINK_IFELSE([AC_LANG_SOURCE([
++#include src/gmock-all.cc
++
++int main(int argc, char **argv)
++{
++ return 0;
++}])],
++ [AC_MSG_RESULT([source is in /usr/src/gmock])
++BUILD_LOCAL_GMOCK=1],
++ [AC_MSG_ERROR([Can't figure out where Google Mock lives; either
install the google-mock package or place the library in the link path])])
++ CPPFLAGS=$OLD_CPPFLAGS
++ LIBS=$OLD_LIBS])
++
++AM_CONDITIONAL([BUILD_LOCAL_GMOCK], [test x$BUILD_LOCAL_GMOCK = x1])
++
++# End Google Mock check #
++
+ PKG_CHECK_MODULES(SQLITE3, sqlite3)
+
+ HAVE_GTK=1
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 5234d43..2ec9ec0 100644
+--- a/tests/Makefile.am
b/tests/Makefile.am
+@@ -2,7 +2,6 @@ MAINTAINERCLEANFILES = Makefile.in
+
+ INCLUDES = -I$(top_builddir) -I$(top_srcdir) -I$(top_srcdir)/src -I$(srcdir)
+ BOOST_TEST_LDFLAGS = @BOOST_UNIT_TEST_LIBS@
+-GMOCK_LDFLAGS = -lgmock -lgtest
+ AM_CPPFLAGS = -DBOOST_TEST_DYN_LINK -DSRCDIR=\$(srcdir)\
+ LDADD = $(top_builddir)/src/loggers.o\
+ $(top_builddir)/src/generic/apt/matching
Bug#645615: please support s390x
Package: ltrace Version: 0.5.3-2.1 Severity: important User: debian-s...@lists.debian.org Usertags: s390x Please add s390x to the list of supported architectures in debian/rules. I just compiled it there and it runs fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645630: must not use bzip2 for libtextwrap1-udeb
Package: libtextwrap Version: 0.1-12 Severity: serious libtextwrap1-udeb is compressed with bzip2, which is illegal for all udebs. This one is in the initrd, so nothing explodes in real use, but that doesn't make it legal. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645765: please consider allowing to load installer components from a different mirror
On 2011-10-18, Marc Haber mh+debian-packa...@zugschlus.de wrote: when entities deploy Debian via network install, point releases can pose challenges. For example, a site I consult for has a mirror which is rsynced daily, but the installation server is not updated automatically with the latest initrd and kernel files. There are debian-installer-6.0-netboot-* packages for this in squeeze now, FWIW. It helps in quite a bunch of cases, just maybe not in yours. (The install server needs to run on squeeze.) ;-) [1] I don't have the slightest idea why this issue has only surfaced after 6.0.3 It certainly happens for new kernel ABIs. But yeah, point releases regularly break d-i netboot images because of the way they work. Basically whenever we respin the kernel udebs and then d-i to incorporate new security updates / other misc bugfixes. I wonder what was different here if it didn't happen with .1 or .2 (which both had non-ABI breaking d-i kernel updates). Do you have some sort of failure message? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#645836: Missing build dependency on libfuse-dev
severity 645836 serious thanks On Tue, Oct 18, 2011 at 07:58:42PM -0400, Stephen Powell wrote: Package: s390-tools Version: 1.13.0-1 Severity: minor When doing $ cd /usr/src $ apt-get --only-source source s390-tools $ su # apt-get --only-source build-dep s390-tools # exit $ cd s390-tools-1.13.0 $ dpkg-buildpackage -uc -b -rfakeroot I get build errors. The file fuse.h is not found during compilation. Installing package libfuse-dev seems to fix the problem. There seems to be a missing build dependency on libfuse-dev in source package s390-tools version 1.13.0-1. Thanks for the report. I'll fix it in due course. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#645881: critical update 29 available
On Wed, Oct 19, 2011 at 03:28:02PM +0200, Thijs Kinkhorst wrote: What I'm wondering is if we tried to ask upstream whether they would be willing to extend the DLJ offer so we can keep security fixes for the sun-java6 version in stable coming in for the lifetime of this release, notwithstanding the fact that we're removing it from the next release. They won't. | I'm not familiar with the Debian Project's practices around security issues | in non-free packages to be able to make a specific recommendation other than to | recommend using the open source OpenJDK code base for Debian's packaging needs. | | Like I said on my blog, there won't be further Oracle JDK 6 releases published | under the DLJ license. Oracle's schedule for Critical Patch Updates (CPUs) is | public, and available at | http://www.oracle.com/technetwork/topics/security/alerts-086861.html (in the past the security team didn't care about this at all for the current oldstable). I don't know what this refers to, but it doesn't seem relevant because we're talking about the present. Well, non-free used to be unsupported security-wise AFAIK. doko is right that the security team still didn't care in the present, though, as the updates were through p-u and not the security archive. That said I'm glad that somebody stepped up and did the updates that were possible. There might be one other option, but one I probably wouldn't be happy with due to it probably being impossible to review: improve openjdk in stable enough to replace sun-java6. Apart from this it's either a DSA telling people that it contains known flaws (if they're critical enough) and that there will be no further security updates. OTOH the updates didn't pass security anyway because there's no non-free there. Or it's the removal of the package. Or we simply don't care because it's freaking non-free and people are supposed to use it in secure environments with a grain of salt. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#646095: Usage of private symbol
On Fri, Oct 21, 2011 at 01:57:42PM -0200, Gustavo Noronha Silva wrote: This is caused by midori using a symbol that was only exported for being used in the test runner. I can't see how a rebuild would fix it, are you sure it did? This means that you just introduced an ABI break and are obliged to bump SONAME and this would've been a transition that should've been asked for and handled properly. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#640495: Bug#564576: Package completely fails to support IPv6
severity 640496 serious severity 640495 serious thanks On Mon, Sep 05, 2011 at 12:05:55PM +0200, Philipp Kern wrote: On Wed, Feb 16, 2011 at 09:56:32AM -0500, Scott Kitterman wrote: I replied directly, rather than to the bug by mistake. I will contact the maintainers of the two rdepends (spfmilter and whitelister) to see if they will fix libspf0, port their packages to libspf2 (which does support IPv6), or have them removed. Given that the orphan bug is already quite old (2007, #433108) and that it causes data loss, let's get rid of it. Filing bugs against its reverse dependencies because the library is going away. I'll try to remember to ask for its removal in a few weeks and upgrade those bugs to serious then. Upgrading now. I'll ask for libspf0's removal at the end of the month. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#646220: debian-archive-keyring/experimental: removes all keys
On Sat, Oct 22, 2011 at 06:45:07AM -0500, Jonathan Nieder wrote: reassign 646220 debian-archive-keyring 2011.10.21 # letting version tracking do its work tags 646220 - experimental quit Jonathan Nieder wrote: | W: gpg: '//var/lib/cupt/lists/http___debian.uchicago.edu_debian_dists_sid_Release': public key 'AED4B06F473041FA' not found The changelog says: * Put debian-archive-keyring.gpg into trusted.gpg.d. * Remove old keys from trusted.gpg upon upgrade. so I guess this is a missing feature in cupt. I was too impatient. Now apt-get update finished running and it produces the same symptoms. Sorry for the nonsense, all. What's the output of `apt-key list' and `ls -al /etc/apt/trusted.gpg.d' post-installation? Is preventing mixed systems like this really an intended effect? Mixed in what way? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#640496: Bug#564576: Package completely fails to support IPv6
retitle 640496 RM: whitelister -- ROM; unmaintained upstream, obsolete reassign 640496 ftp.debian.org thanks Hi Pierre, On Sat, Oct 22, 2011 at 07:06:10PM +0200, Pierre Habouzit wrote: You can remove whitelsiter, I don't maintain (upstream) it anymore. then let's do that. ;) Kind regards and thanks for your reply! Philipp Kern signature.asc Description: Digital signature
Bug#646220: debian-archive-keyring/experimental: removes all keys
Hi Jonathan, On Sat, Oct 22, 2011 at 10:20:06AM -0500, Jonathan Nieder wrote: […] which removed the keys, as advertised. I can try upgrading again if other avenues of investigation get exhausted. can you delete everything[1] in /etc/apt/trusted.gpg.d (downgrades are not supported) and re-try with 2011.10.23, please? Kind regards and thanks, Philipp Kern [1] I.e. everything debian-archive-keyring*'ish. -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#645997: no space on device when installing kernel (lvm+btrfs)
Hi. On Sun, Oct 23, 2011 at 09:55:54PM +0100, Miguel Figueiredo wrote: i have installed a virtual machine using a daily businesscard image where i selected lvm (no encription) with btrfs and when it got to the part where kernel was about to installed it failed with the same error, no space left on device although the mounted filesystems are not full. Could you do a btrfsctl -i dev when that condition is reached? Is not full is… special with btrfs, as it leaves tons of disk space for (duplicated) metadata. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#646675: out of nowhere?
tag 646675 + security severity 646675 serious thanks Erhm, On Wed, Oct 26, 2011 at 10:06:14AM +0200, Holger Levsen wrote: severity 646675 important thanks am I the only one who has insanely loud alarm bells when reading his report, the ticket and everything? It includes a foreign site and we can be happy that suhosin blocks it. (I'm working from the information in the roundcube ticket[0]. I didn't investigate it myself.) But suhosin is not the default? Kind regards Philipp Kern [0] http://trac.roundcube.net/ticket/1488086 signature.asc Description: Digital signature
Bug#646220: debian-archive-keyring/experimental: removes all keys
On Sat, Oct 29, 2011 at 12:47:32AM -0500, Jonathan Nieder wrote: By the way, the code in cache.cpp makes me wonder: why does cupt need to copy the keyring to a private location when it is treating APT's keyring as authoritative anyway? It would be cool if cupt could loop over the keyrings instead of importing them. debian-archive-keyring won't trigger anything in its postinst anymore when the conversion is done. (That said, apt-key is pretty crappy and needs some fixes before that can happen. Bugs are not yet filed now, though.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#638368: sysconfig: please enable it for s390x
tag 638368 + pending
thanks
On Thu, Aug 18, 2011 at 10:57:25PM +0200, Aurelien Jarno wrote:
sysconfig is needed on s390x the same way as on s390. Could you please
enable support for it? The patch below should do it. Thanks in advance.
I just uploaded the attached NMU to DELAYED/2-days.
Kind regards
Philipp Kern
diff -Nru sysconfig-0.0.10/debian/changelog
sysconfig-0.0.10+nmu1/debian/changelog
--- sysconfig-0.0.10/debian/changelog 2010-10-30 17:10:12.0 +0200
+++ sysconfig-0.0.10+nmu1/debian/changelog 2011-10-29 14:15:44.0
+0200
@@ -1,3 +1,11 @@
+sysconfig (0.0.10+nmu1) unstable; urgency=low
+
+ * Porter NMU.
+ * Enable this port-specific package for the related port s390x.
+(Closes: #638368)
+
+ -- Philipp Kern pk...@debian.org Sat, 29 Oct 2011 14:10:30 +0200
+
sysconfig (0.0.10) unstable; urgency=medium
* Move udev rules files.
diff -Nru sysconfig-0.0.10/debian/control sysconfig-0.0.10+nmu1/debian/control
--- sysconfig-0.0.10/debian/control 2010-08-06 17:13:10.0 +0200
+++ sysconfig-0.0.10+nmu1/debian/control2011-10-29 14:15:08.0
+0200
@@ -6,7 +6,7 @@
Standards-Version: 3.6.2
Package: sysconfig-hardware
-Architecture: s390
+Architecture: s390 s390x
Priority: standard
Depends: ${misc:Depends}, udev
Description: Hardware configuration
diff -Nru sysconfig-0.0.10/debian/rules sysconfig-0.0.10+nmu1/debian/rules
--- sysconfig-0.0.10/debian/rules 2010-08-06 17:09:46.0 +0200
+++ sysconfig-0.0.10+nmu1/debian/rules 2011-10-29 14:15:08.0 +0200
@@ -21,7 +21,7 @@
install-sysconfig-hardware-%: export DH_OPTIONS = -psysconfig-hardware
-install-sysconfig-hardware-arch-s390: install-sysconfig-hardware-common
+install-sysconfig-hardware-arch-s390 install-sysconfig-hardware-arch-s390x:
install-sysconfig-hardware-common
dh_install etc/sysconfig/scripts/hardware/*-ccw*
etc/sysconfig/scripts/hardware
dh_install usr/share/initramfs-tools
signature.asc
Description: Digital signature
Bug#646220: debian-archive-keyring/experimental: removes all keys
On Sat, Oct 29, 2011 at 03:46:18PM +0300, Eugene V. Lyubimkin wrote: I wanted to do it this way from the very start but I could not since /etc/apt/trusted.gpg is somewhy readable only by root. Bug's filed (veeery late though). If the new keyring file installed by debian-archive-keyring/experimental (I didn't have a chance to play with it yet) installs a world-readable keyring, this would be a good start towards the goal (as for me). As long as it's a symlink, it will point to a world-readable file. Due to oddnesses in apt-key it will let gpg move the symlink to debian-archive-keyring.gpg~ and generate a new keyring at the old location. That one might or might not be world-readable. But that should really be fixed so that it's always readable. (You might want to mimick the logic in apt to ignore certain file extensions, though.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#640495: Bug#564576: Package completely fails to support IPv6
Mike, On Sat, Oct 22, 2011 at 07:06:10PM +0200, Pierre Habouzit wrote: On Fri, Oct 21, 2011 at 09:16:20PM +0200, Philipp Kern wrote: Upgrading now. I'll ask for libspf0's removal at the end of the month. You can remove whitelsiter, I don't maintain (upstream) it anymore. any opinion about spfmilter? Can it be fixed? Should it go? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#647317: CVE-2011-4091/CVE-2011-4092
On Tue, Nov 01, 2011 at 09:03:57PM +0100, Moritz Muehlenhoff wrote: Package: obby Severity: important Tags: security Hi, two CVE IDs have been assigned to two minor vulnerabilites in libobby: http://seclists.org/oss-sec/2011/q4/194 (plus followups from upstream) IMO this doesn't warrant a DSA. CVE-2011-4091 and CVE-2011-4093 can be fixed with an updated net6. CVE-2011-4092 is a design issue in obby that won't be fixed upstream unless somebody else steps up to implement/fix it. (libinfinity fixes this issue and is not affected by the other two issues.) I think fixing -4093 (and possibly -4091) in a stable update makes sense but I don't see a DSA for any of them. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#647317: Bug#647318: CVE-2011-4093
retitle 647318 CVE-2011-4091/CVE-2011-4093 retitle 647317 CVE-2011-4092 thanks On Tue, Nov 01, 2011 at 09:06:24PM +0100, Moritz Muehlenhoff wrote: Package: net6 Severity: important Tags: security Hi, CVE-2011-4093 has been assigned to a rather harmless vulnerability in libobby: http://seclists.org/oss-sec/2011/q4/194 (plus followups from upstream) CVE-2011-4091/CVE-2011-4093 will be fixed in a bit in unstable. (Upstream already released a new version.) That said the security-tracker[1] is wrong about the bug number of CVE-2011-4091 after this retitle. (That net6 is affected is already reflected there.) Moritz, can you please fix that? Thanks. Kind regards Philipp Kern [1] http://security-tracker.debian.org/tracker/CVE-2011-4091 signature.asc Description: Digital signature
Bug#647469: please add ttysclp0 for s390/s390x
Package: login Version: 1:4.1.4.2+svn3283-3 Severity: important Please add ttysclp0 as a secure TTY on Linux. It's the ASCII console you get in the web interface of mainframes running the s390 and s390x ports in LPAR mode. root logins are perfectly suitable as there's already access control beforehand. Thanks Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653308: value_from_ffi_type: broken on 64bit big endian
Source: glib2.0
Version: 2.30.2-4
Severity: important
Tags: patch
User: debian-s...@lists.debian.org
Usertags: s390x
gobject/gclosure.c:value_from_ffi_type in sid does conversions that are unsafe
on big endian architectures and cause breakage at least on 64bit big endian
architectures (such as s390x, sparc64 and ppc64). For G_TYPE_BOOLEAN you'd
get the first machine word (zeros) instead of the one in the second word
(MSB first). Hence glib-networking's testsuite broke.
This was already fixed upstream, they replaced the function with this[1]:
static void
value_from_ffi_type (GValue *gvalue, gpointer *value)
{
ffi_arg *int_val = (ffi_arg*) value;
switch (g_type_fundamental (G_VALUE_TYPE (gvalue)))
{
case G_TYPE_INT:
g_value_set_int (gvalue, (gint) *int_val);
break;
case G_TYPE_FLOAT:
g_value_set_float (gvalue, *(gfloat*)value);
break;
case G_TYPE_DOUBLE:
g_value_set_double (gvalue, *(gdouble*)value);
break;
case G_TYPE_BOOLEAN:
g_value_set_boolean (gvalue, (gboolean) *int_val);
break;
case G_TYPE_STRING:
g_value_set_string (gvalue, *(gchar**)value);
break;
case G_TYPE_CHAR:
g_value_set_schar (gvalue, (gint8) *int_val);
break;
case G_TYPE_UCHAR:
g_value_set_uchar (gvalue, (guchar) *int_val);
break;
case G_TYPE_UINT:
g_value_set_uint (gvalue, (guint) *int_val);
break;
case G_TYPE_POINTER:
g_value_set_pointer (gvalue, *(gpointer*)value);
break;
case G_TYPE_LONG:
g_value_set_long (gvalue, (glong) *int_val);
break;
case G_TYPE_ULONG:
g_value_set_ulong (gvalue, (gulong) *int_val);
break;
case G_TYPE_INT64:
g_value_set_int64 (gvalue, (gint64) *int_val);
break;
case G_TYPE_UINT64:
g_value_set_uint64 (gvalue, (guint64) *int_val);
break;
case G_TYPE_BOXED:
g_value_set_boxed (gvalue, *(gpointer*)value);
break;
case G_TYPE_ENUM:
g_value_set_enum (gvalue, (gint) *int_val);
break;
case G_TYPE_FLAGS:
g_value_set_flags (gvalue, (guint) *int_val);
break;
case G_TYPE_PARAM:
g_value_set_param (gvalue, *(gpointer*)value);
break;
case G_TYPE_OBJECT:
g_value_set_object (gvalue, *(gpointer*)value);
break;
default:
g_warning (value_from_ffi_type: Unsupported fundamental type: %s,
g_type_name (g_type_fundamental (G_VALUE_TYPE (gvalue;
}
}
At least for gboolean that looks much more sane and solves the problem. Given
the fact that a bunch of the other cases were also problematic, I'd suggest
replacing that function with the one above. I was told that FFI support is
pretty new, I don't know if there are more big endian issues lingering around.
The testsuite has a bunch of issues too.
If that could be fixed timely, that would be cool. (As long as it doesn't
break anything, but the old code looked obviously wrong.) It blocks a lot of
GNOME stuff being built on s390x, because glib-networking aborts on testsuite
failures.
Kind regards
Philipp Kern
[1] http://git.gnome.org/browse/glib/tree/gobject/gclosure.c#n1032
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648567: Wheezy installer : No usb detection on Sheevaplug (marvell armel kirkwood), installer stop with mess Error while running 'modprobe -v usb-storage'
Hi Maks, On Wed, Dec 14, 2011 at 11:07:31AM +, maximilian attems wrote: if there is not a soon release of 2.0 (meaning until this weekend), i'll upload fixed klibc this week. (which is probably as I didn't regain the kernel.org account yet) thanks for your patience and sorry for the mess. any progress on this? Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#653496: Re[02]: Bug#653496: FTBS: Debian 6.0.3 - Security Fix - acpid_2.0.7-1squeeze3
On Wed, Dec 28, 2011 at 07:35:17PM -0500, John L. Males wrote: I would think a maintainer would know what are the key elements related to such an issue. Not reading the remainding parts of your ramblings, I think you should work on your politeness, really. Insulting a member of the project that has experience is not helping you in your quest. Probably you're just leaking a -Werror from your environment to the package build. I'd try to build with env -i, but I don't know if that's guaranteed to work for a package build. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#653053: ldap2zone: Sending email every hour fill up the mail spool
On Fri, Dec 30, 2011 at 08:32:03PM +0100, Petter Reinholdtsen wrote: According to Philipp Kern, the stable release manager, on IRC, he agrees with your email and we can use your comments as authorative. Mentioning it here to make sure the package maintainer is aware of this. And as I told you on IRC he's even in charge as SRM. But then I see that the information of the organization page might have been misleading and it will be updated on the next regen, listing Adam twice. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#653335: closed by Philipp Kern pk...@debian.org ([p-a-s/sid] xserver-xorg-video-geode: dropped, specifies any-i386 in dsc)
On Sun, Jan 01, 2012 at 11:38:08PM +0200, Martin-Éric Racine wrote: Removing the entry is not what was requested. This package still won't build on anything else than an x86-32. The request was to add non-Linux i386 variants, namely kfreebsd-i386 and hurd-i386, i.e. any-i386. As I wrote you specify the arch in the .dsc, and we just take that instead. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
