Bug#704252: preparing the fix
On Fri, 2013-04-12 at 22:48 +0200, Paul Gevers wrote: 1) You used dpkg-architecture -qDEB_BUILD_ARCH instead of dpkg-architecture -qDEB_BUILD_GNU_CPU (you could simplify your rules file as well with this). Hmm, it seems like this was not a smart idea for i386. So the point is that either we have to fix i486 to i386 or amd64 to x86_64... Abou, what is your proposal, and what do you prefer? I can upload again tomorrow. Hi Paul, I'd rather keep what I did as it was the same code used for Lazarus. If there is an issue in the amd64 arch, please report it and I'll try to fix that. There is a translation table in the debian/rules that ensure we get the right arch. This should be probably resolved other way by patching fpcmake and the compiler to conform to debian lib path naming policy. Cheers, signature.asc Description: This is a digitally signed message part
Bug#454770: [Pkg-samba-maint] Bug#454770: Bug#454770: schannel_store.tdb should not be kept in /etc/samba
Control: tags -1 - patch Hi Steve, On Sun, Apr 14, 2013 at 11:08:47AM -0700, Steve Langasek wrote: Reviewing the diff at the svn revision where this regression was introduced, there are other parts of the patch that were also dropped: MACHINE.SID and idmap2.tdb also no longer have their location being patched. Both of these files still have references in the code, so the patch should be re-fixed to handle them. Thanks for checking this. I'm somewhat concerned about idmap2.tdb. If we get this one wrong, users can get the wrong unix uid's, which could be very bad on a fileserver. If only one version exists (in either /etc or /var/...) there should be no problem, but if both exist, it might be better to error out instead of picking one of them. That would need a debconf notification explaining the situation, which ideally would be translated as well. This problem could happen if someone installed samba from squeeze, upgraded to wheezy or backports, and then upgraded to the (future) final wheezy version. Also note that a real world setup will go silently wrong on this first upgrade. What do you think? For schannel_store.tdb, I don't know the impact of suddenly moving back to an old version (which would happen if there still was one left in /var/...). Can someone shed some light on this? Is it better to remove it in this case? (MACHINE.SID, at least, is a legacy file that's being read but not written for compatibility only, so we don't need to migrate it in the maintainer script.) It seems MACHINE.SID is deleted on startup by samba since before wheezy, so this one should not cause any problems (if I read the code correctly). I will try to do some tests with an idmap setup tonight. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: [Pkg-samba-maint] Bug#454770: Bug#454770: schannel_store.tdb should not be kept in /etc/samba
Processing control commands: tags -1 - patch Bug #454770 [samba] schannel_store.tdb should not be kept in /etc/samba Removed tag(s) patch. -- 454770: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454770 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701492: libatk-wrapper-java: Hangs starting applications
Samuel Thibault, le Mon 15 Apr 2013 02:00:36 +0200, a écrit : and warn that it is not stable with multithreaded applications. with *non-multithreaded* applications, actually :) Samuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: severity of 705306 is wishlist
Processing commands for cont...@bugs.debian.org: severity 705306 wishlist Bug #705306 [quagga] quagga package should not contain header files and static libraries Severity set to 'wishlist' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. -- 705306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705306 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705306: quagga package should not contain header files and static libraries
severity 705306 wishlist thank you The Policy Section 8 also says: --cut here-- This section deals only with public shared libraries: shared libraries that are placed in directories searched by the dynamic linker by default or which are intended to be linked against normally and possibly used by other, independent packages. Shared libraries that are internal to a particular package or that are only loaded as dynamic modules are not covered by this section and are not subject to its requirements. --cut here-- There are no reverse build dependencies on quagga package, so we can quite easily classify those libraries as internal. I am also not aware of any common software on top of quagga libraries. It would be nice to have quagga package cleanup and split into quagga, libquagga0 and libquagga-dev[*], but this hardly qualifies as RC bug. * or just to drop the *.h, *.a and *.la from the main package and add them only when somebody asks for them. Ondrej On Fri, Apr 12, 2013 at 8:30 PM, Len Sorensen lennartsoren...@ruggedcom.com wrote: Package: quagga Version: 0.99.22-1 Severity: serious Justification: Policy 8.4 As far as I understand packaging policy, header files and static libraries must go in a -dev package, and not be included in the main package. After all most people running a program are not going to be compiling add ons for it. Certainly the static library really doesn't make sense to include. It seems to me, quagga really should have a quagga package for the daemons, a libquagga for the shared libraries, and a libquagga-dev for the headers and static libraries. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 powerpc Kernel: Linux 3.8-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quagga depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii iproute20120521-3+b4 ii libc6 2.16-0experimental1 ii libcap21:2.22-1.2 ii libpam0g 1.1.3-9 ii libreadline6 6.2+dfsg-0.1 ii libtinfo5 5.9-10 ii logrotate 3.8.3-3 quagga recommends no packages. Versions of packages quagga suggests: pn snmpd none -- debconf information excluded -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di
On Mon, Apr 15, 2013 at 01:47:28AM +0100, Ben Hutchings wrote:
On Sun, 2013-04-14 at 23:41 +0200, Aurelien Jarno wrote:
[...]
Sorry to answer late, I only have been able to test it now.
Unfortunately the vexpress image is now broken, due to this change:
| * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
|images (Closes: #705118)
nic-modules is still needed on vexpress as it provides the module for
the on-board NIC.
Since any system with external USB ports should be able to work with
arbitrary USB Ethernet controllers, I added nic-{usb,wireless}-modules
packages and removed the USB modules you originally specified in
nic-modules. In the case of mx5 this left nic-modules empty, and I
removed it, but for vexpress there was that one module left, smsc911x.
Unfortunately I then removed nic-modules from the installer for *both*
flavours instead of just mx5.
I just tried adding smsc91xx back into the current daily netboot initrd
and it seems to work in QEMU (up to the point where the installer finds
I didn't attach a disk).
Yes, I have committed such a change, and I have been able to do a full
installation that way. The daily image that will be generated in a few
hours should have the fix, I will test it when available.
By the way, given that the majority of users for the vexpress flavour
will be running it in QEMU rather than a real Motherboard Express
(they're expensive!), is it possible to support an alternate model like
virtio_net that may be emulated more efficiently?
Unfortunately the vexpress board doesn't have PCI/PCIE support so the
standard virtio doesn't work there. People are working on virtio-mmio,
but it seems to be something difficult to get working correctly.
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
Package: docbook-xml Version: 4.5-7.1 Severity: serious The jenkins chroot upgrade testing discovered this problem. The upgrades of several test configurations fail with this message: E: Couldn't configure pre-depend xml-core for docbook-xml, probably a dependency cycle. The test configurations chroot-installation_squeeze_install_kde_upgrade_to_wheezy, chroot-installation_squeeze_install_full_desktop_upgrade_to_wheezy and chroot-installation_squeeze_install_kde-full_upgrade_to_wheezy all fail with this error message. The problem started 2013-04-08 around noon, and the test around noon the previous day was OK, so I guess the change triggering this problem was introduced that day. I notice that docbook-xml did not change in this period, but neither did xml-core, and thus I am not quite sure which package to atribute the problem to. Thus I just pick the one that fail to upgrade according to apt-get, and hope someone else is able to figure out exactly what is wrong. Is docbook-xml involved in some (pre-)dependency loop? The failing tests can be reviewed on URL: http://jenkins.debian.net/ . Setting severity to serious, as this block upgrade from squeeze to wheezy for normal KDE desktop users. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: base: Filesystem corruption issue
On Wed, 2013-04-10 at 08:17 -0400, Anthony Sheetz wrote: Steps to reproduce: Install Debian Testing from Netinstall CD, amd64. Choose LVM and Full Disk Encryption, with a separate /home Resize /home to be 80GB Install openswan, connect to remote network Install xen Set up a virtual machine with Debian Stable using logical volumes as the backing store. fs: ext3 network: NAT transfer a large (multigigabyte) file from a remote server over the internet to the virtual machine Expected behavior: File transfers fine, md5sum agrees with remote system Observed behavior: md5sum never matches, done enough times, the ext3 fs becomes corrupted Can I just confirm a few things please: The VM disk backend is an LVM volume which is included in the full disk encryption? I suppose it is using dm-crypt? The ext3 fs which becomes corrupted is the guest VM filesystem, not the dom0 filesystem nor a filesystem which is is what the the large multigigabyte file which is transferred over the network consists of? On the face of it it sounds to me like the network corruption (md5sum issue) and the eventual ext3 corruption must be separate issues. Or I suppose it is possible that the file is received correctly but is corrupted when written to the disk, but it's probably better to consider them separately until we know one way or the other. WRT the file transfer corruption: Is the file being transferred over the openswan link? Did you ever happen to try a transfer over a non-tunnelled connection? Were you able to successfully transfer the file to the dom0 filesystem or to any other system (e.g. one not running Xen) on this end of the openswan link? I'm not sure what error detection/correction scp/rsync or if they have any additional verification options which could be tried or perhaps it is possible to run md5sum on the stream before it hits the disk (can one rsync/scp to stdout? I doubt it). If you can transfer to dom0 OK then it might be interesting to try turning off the various offloads (GSO, SG etc) on the vif link. WRT the filesystem corruption: How did the ext3 corruption manifest itself? I wonder if the layering of crypto+lvm+xen-blkback is causing the barriers which ext3 requires to function correctly to not occur in the right places. Does something need to be manually configured to enable barriers at some layer? (or perhaps I am thinking of DISCARD support). If you were able to attempt to reproduce without the crypto bit in dom0 for the VM disk that would be really useful. It might also be interesting to try using the ext3 barrier mount option in the guest to switch barriers either off or on (I can't remember what the default was for Squeeze). I appreciate that you may have redeployed/downgraded the systems so some of the above experiments might be quite hard to try out but if you could setup a spare system or something it would be very much appreciated. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: [Pkg-xen-devel] Bug#705124: downgrading, we would like to upgrade our developers to Testing. However, this bug prevents us from doing so, and would prevent us from migrating to 7.0 when it
On Sat, 2013-04-13 at 19:48 +0800, Thomas Goirand wrote: On 04/10/2013 10:49 PM, Anthony Sheetz wrote: ___ Pkg-xen-devel mailing list pkg-xen-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel Hi, Could you please avoid writing a 1km long subject line, and write in the body of your message? I'm putting your subject line again here, for move visibility: downgrading, we would like to upgrade our developers to Testing. If I didn't know Chinese and lived in China for nearly 7 years now, I'd say that the above is Chinese. Though, I'd say it is hebrew to me (since I don't know Hebrew). FWIW in British English we talk about things being Greek to me... In other words: could you rephrase? They have downgraded to Squeeze. They would like to upgrade to testing but this issue prevents them doing do. However, this bug prevents us from doing so, and would prevent us from migrating to 7.0 when it becomes released. Pretty critical to the system's stability. We do understand that this bug is a problem for you. We all would like it to be solved. However, just saying that it is a big problem for you doesn't help. Please provide the output of lspci and dmidecode as I asked, so that we have a clue of what kind of hardware you are using. Also, I'm surprised that you are talking about problems with Debian 7, when your kernel log shows: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-48squeeze1) AIUI they are running Wheezy in dom0 and Squeeze in domU (which is where the logs are from), in each case with the appropriate matching kernel I suppose (so 3.2 in dom0 and 2.6.32 in domU). I infer that this issue does not occur with Squeeze on Squeeze. I suppose Wheezy on Wheezy hasn't been attempted? Maybe you could try just *running* the kernel 3.2, and not just try to upgrade your domU? This would be an interesting experiment. As would trying the plain 2.6.32-5-amd64 kernel in the Squeeze domU (the features of the -xen flavour in Squeeze mostly relate to dom0 IIRC). Ian. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704252: preparing the fix
On Sun, 2013-04-14 at 08:34 +0200, Paul Gevers wrote: On 14-04-13 01:45, peter green wrote: Sorry I could have been clearer in my last mail. I didn't intend to blame you for most of the issues with the patch (you just took a broken patch and made it differently broken) but I could see how it could have come across that way. Thanks for the clarification, I appreciate that. I like this end :) thanks. Still I firmly belive that the name in the changechangelog trailer should be the person who finalised the upload. Again, I also doubted. I am watching and contributing on the d-mentors@l.d.o list and see this happening once in a while. In this case I wanted to credit Abou for the change, instead, because it failed, it might look otherwise. Indeed, I am now convinced you are right. Next time I will credit in the log itself. If noone naks this in the next few days I will go ahead and upload it. Please go ahead. Lets get rid of this RC bug in Wheezy ASAP, so we can release. If I can help by filing and tracking the unblock after successful build (or I can even do the (unchanged :) ) upload for you), please let me know (here or in private). Sorry for late answer, but It is OK with me too. Cheers, signature.asc Description: This is a digitally signed message part
Processed: cloning 705268, reassign -1 to vlan, retitle -1 to don't act on VLAN interfaces supported by ifupdown
Processing commands for cont...@bugs.debian.org:
clone 705268 -1
Bug #705268 {Done: Andrew Shadura andre...@debian.org} [ifupdown] ifupdown:
ifdown Segmentation fault on vlan interfaces
Bug 705268 cloned as bug 705456
reassign -1 vlan
Bug #705456 {Done: Andrew Shadura andre...@debian.org} [ifupdown] ifupdown:
ifdown Segmentation fault on vlan interfaces
Bug reassigned from package 'ifupdown' to 'vlan'.
No longer marked as found in versions ifupdown/0.7.7.
No longer marked as fixed in versions ifupdown/0.7.8.
retitle -1 don't act on VLAN interfaces supported by ifupdown
Bug #705456 {Done: Andrew Shadura andre...@debian.org} [vlan] ifupdown:
ifdown Segmentation fault on vlan interfaces
Changed Bug title to 'don't act on VLAN interfaces supported by ifupdown' from
'ifupdown: ifdown Segmentation fault on vlan interfaces'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
705268: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705268
705456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705456
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705456: Processed: cloning 705268, reassign -1 to vlan, retitle -1 to don't act on VLAN interfaces supported by ifupdown
A patch fixing the issue. -- WBR, Andrew vlan.diff Description: Binary data
Processed: reopening 705456, severity of 705456 is important, found 705456 in 1.9-3
Processing commands for cont...@bugs.debian.org:
reopen 705456
Bug #705456 {Done: Andrew Shadura andre...@debian.org} [vlan] don't act on
VLAN interfaces supported by ifupdown
Bug reopened
Ignoring request to alter fixed versions of bug #705456 to the same values
previously set
severity 705456 important
Bug #705456 [vlan] don't act on VLAN interfaces supported by ifupdown
Severity set to 'important' from 'critical'
found 705456 1.9-3
Bug #705456 [vlan] don't act on VLAN interfaces supported by ifupdown
Marked as found in versions vlan/1.9-3.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
705456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705456
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: refers to missing include rrl.h
Processing commands for cont...@bugs.debian.org: severity 699834 serious Bug #699834 [libbind-dev] dlz-ldap-enum: FTBFS: /usr/include/dns/view.h:76:21: fatal error: dns/rrl.h: ENOENT Severity set to 'serious' from 'important' thanks Stopping processing here. Please contact me if you need assistance. -- 699834: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699834 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
On Mon, Apr 15, 2013 at 10:35:22AM +0200, Petter Reinholdtsen wrote: The jenkins chroot upgrade testing discovered this problem. The upgrades of several test configurations fail with this message: E: Couldn't configure pre-depend xml-core for docbook-xml, probably a dependency cycle. The test configurations chroot-installation_squeeze_install_kde_upgrade_to_wheezy, chroot-installation_squeeze_install_full_desktop_upgrade_to_wheezy and chroot-installation_squeeze_install_kde-full_upgrade_to_wheezy all fail with this error message. The problem started 2013-04-08 around noon, and the test around noon the previous day was OK, so I guess the change triggering this problem was introduced that day. Adam D. Barratt noticed that this coincides with the testing migration of sgml-base. That migration adds a versioned Pre-Dependency from sgml-base to wheezy's dpkg. I notice that docbook-xml did not change in this period, but neither did xml-core, and thus I am not quite sure which package to atribute the problem to. Thus I just pick the one that fail to upgrade according to apt-get, and hope someone else is able to figure out exactly what is wrong. Is docbook-xml involved in some (pre-)dependency loop? The failing tests can be reviewed on URL: http://jenkins.debian.net/ . Setting severity to serious, as this block upgrade from squeeze to wheezy for normal KDE desktop users. Note that chroot-installation_squeeze_install_developer_upgrade_to_wheezy does not fail even though it includes docbook-xml. So the issue is more involved. Even adding the reverse dependency kdoctools of docbook-xml is not enough. Note that dpkg has a Pre-Dependency on liblzma5 that causes it to be upgraded and pulls in multiarch-support forcing a glibc upgrade. To potential bug squashers with more bandwidth and diskspace than me: Reducing the set of packages that cause this failure would be great. To that end I would like to know whether the error also shows when doing a simulated dist-upgrade. That means adding a -s to apt-get -y dist-upgrade. That way downloading of the wheezy packages could be avoided. From there successive removal of packages can be used to reduce the involved package set. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705386: neard: FTBFS on several architectures: test-snep-read segmentation fault
Hi Aaron, On Sat, Apr 13, 2013 at 11:06:51PM -0400, Aaron M. Ucko wrote: Source: neard Version: 0.10+git20130325-1 Severity: serious Justification: fails to build from source Automated builds of neard on several architectures failed due to test-snep-read segmentation faults: https://buildd.debian.org/status/package.php?p=neardver=0.10+git20130325-1 Could you please take a look? We found the culprit and have a fix. I'll ask my dear sponsor to upload a new package soon. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705471: knode: trying to overwrite key.png, which is also in package libkpgp4
Package: knode Version: 4:4.10.2-1 Severity: serious Tags: experimental Justification: uninstallable When trying to upgrade KDE from sid to experimental (by means of installing the metapackages kde-full kde-plasma-desktop kdepim) I got a missing Replaces: Preparing to replace knode 4:4.4.11.1+l10n-3+b1 (using .../knode_4%3a4.10.2-1_i386.deb) ... Unpacking replacement knode ... dpkg: error processing /var/cache/apt/archives/knode_4%3a4.10.2-1_i386.deb (--unpack): trying to overwrite '/usr/share/kde4/apps/knode/pics/key.png', which is also in package libkpgp4 4:4.4.11.1+l10n-3+b1 Tagging as experimental so it doesn’t show up as RC bug otherwise. This probably depends on how apt orders. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static Versions of packages knode depends on: ii kde-runtime 4:4.8.4-2 iu kdepim-runtime 4:4.10.2-1 iu kdepimlibs-kio-plugins 4:4.10.2-1 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 iu libkabc44:4.10.2-1 iu libkcmutils44:4.10.2-2 iu libkde3support4 4:4.10.2-2 iu libkdecore5 4:4.10.2-2 iu libkdepim4 4:4.10.2-1 iu libkdeui5 4:4.10.2-2 iu libkhtml5 4:4.10.2-2 iu libkio5 4:4.10.2-2 iu libkmime4 4:4.10.2-1 iu libkontactinterface44:4.10.2-1 iu libkparts4 4:4.10.2-2 iu libkpgp44:4.10.2-1 iu libkpimidentities4 4:4.10.2-1 iu libkpimtextedit44:4.10.2-1 iu libkpimutils4 4:4.10.2-1 iu libmailtransport4 4:4.10.2-1 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-qt3support 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 knode recommends no packages. knode suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705385: mia: FTBFS on powerpc: test suite hangs
I can confirm that the test hangs on powerpc if more then one thread is used. The problem seems to lie somewhere in the thread cleanup routines of TBB, i.e. the parallel code of MIA is run, and then tbb::parallel_reduce/tbb:parallel_for do not return. According to the changelog the TBB release currently available in debian/sid is the very first that supported 32 bit powerpc, and that version is quite old (from 2011). I will check what happens with the latest version of TBB (4.1 update 2). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 705471
Processing commands for cont...@bugs.debian.org: tags 705471 = pending Bug #705471 [knode] knode: trying to overwrite key.png, which is also in package libkpgp4 Added tag(s) pending; removed tag(s) experimental. thanks Stopping processing here. Please contact me if you need assistance. -- 705471: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705471 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: base: Filesystem corruption issue
Replies in line below. On Mon, Apr 15, 2013 at 4:54 AM, Ian Campbell i...@hellion.org.uk wrote: On Wed, 2013-04-10 at 08:17 -0400, Anthony Sheetz wrote: Steps to reproduce: Install Debian Testing from Netinstall CD, amd64. Choose LVM and Full Disk Encryption, with a separate /home Resize /home to be 80GB Install openswan, connect to remote network Install xen Set up a virtual machine with Debian Stable using logical volumes as the backing store. fs: ext3 network: NAT transfer a large (multigigabyte) file from a remote server over the internet to the virtual machine Expected behavior: File transfers fine, md5sum agrees with remote system Observed behavior: md5sum never matches, done enough times, the ext3 fs becomes corrupted Can I just confirm a few things please: The VM disk backend is an LVM volume which is included in the full disk encryption? I suppose it is using dm-crypt? Correct on both accounts. The ext3 fs which becomes corrupted is the guest VM filesystem, not the dom0 filesystem nor a filesystem which is is what the the large multigigabyte file which is transferred over the network consists of? Correct again. On the face of it it sounds to me like the network corruption (md5sum issue) and the eventual ext3 corruption must be separate issues. Or I suppose it is possible that the file is received correctly but is corrupted when written to the disk, but it's probably better to consider them separately until we know one way or the other. WRT the file transfer corruption: Is the file being transferred over the openswan link? Yes. Dom0 is set up with the openswan connection, DomU is set up to use NAT through Dom0 - file was transferred that way. Did you ever happen to try a transfer over a non-tunnelled connection? Yes, tried file transfers from another machine on the local network - never had a problem with those. Were you able to successfully transfer the file to the dom0 filesystem or to any other system (e.g. one not running Xen) on this end of the openswan link? Yes - tried that several times, and was able to do the transfer with no corruption, and md5sum matched. I'm not sure what error detection/correction scp/rsync or if they have any additional verification options which could be tried or perhaps it is possible to run md5sum on the stream before it hits the disk (can one rsync/scp to stdout? I doubt it). Tried doing 'scp file.sql | md5sum' on DomU which resulted in a matching md5sum. We decided this eliminated the openswan link as the culprit. If you can transfer to dom0 OK then it might be interesting to try turning off the various offloads (GSO, SG etc) on the vif link. Any instructions on doing that? WRT the filesystem corruption: How did the ext3 corruption manifest itself? Initially with errors on the console (and in kernel.log and other places) about writes beyond the end of the logical volume. After a time, the filesystem would be set to read-only, and refuse to mount in read/write mode. I wonder if the layering of crypto+lvm+xen-blkback is causing the barriers which ext3 requires to function correctly to not occur in the right places. Does something need to be manually configured to enable barriers at some layer? (or perhaps I am thinking of DISCARD support). If you were able to attempt to reproduce without the crypto bit in dom0 for the VM disk that would be really useful. It might also be interesting to try using the ext3 barrier mount option in the guest to switch barriers either off or on (I can't remember what the default was for Squeeze). Google led me to try mounting the file system with barriers=0, and no luck. I appreciate that you may have redeployed/downgraded the systems so some of the above experiments might be quite hard to try out but if you could setup a spare system or something it would be very much appreciated. We planned for this, and once we have some ideas to try (with some detailed instructions for trying them) we'll be purchasing a spare hard drive to try them out. We'd like this problem solved, and we're willing to spend a little to do it. Ian.
Bug#705124: [Pkg-xen-devel] Bug#705124: downgrading, we would like to upgrade our developers to Testing. However, this bug prevents us from doing so, and would prevent us from migrating to 7.0 when it
(Just sending a copy to BTS) On Mon, 2013-04-15 at 08:20 -0400, Anthony Sheetz wrote: All correct, Ian, thanks. On Mon, Apr 15, 2013 at 5:00 AM, Ian Campbell i...@hellion.org.uk wrote: On Sat, 2013-04-13 at 19:48 +0800, Thomas Goirand wrote: On 04/10/2013 10:49 PM, Anthony Sheetz wrote: ___ Pkg-xen-devel mailing list pkg-xen-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel Hi, Could you please avoid writing a 1km long subject line, and write in the body of your message? I'm putting your subject line again here, for move visibility: downgrading, we would like to upgrade our developers to Testing. If I didn't know Chinese and lived in China for nearly 7 years now, I'd say that the above is Chinese. Though, I'd say it is hebrew to me (since I don't know Hebrew). FWIW in British English we talk about things being Greek to me... In other words: could you rephrase? They have downgraded to Squeeze. They would like to upgrade to testing but this issue prevents them doing do. However, this bug prevents us from doing so, and would prevent us from migrating to 7.0 when it becomes released. Pretty critical to the system's stability. We do understand that this bug is a problem for you. We all would like it to be solved. However, just saying that it is a big problem for you doesn't help. Please provide the output of lspci and dmidecode as I asked, so that we have a clue of what kind of hardware you are using. Also, I'm surprised that you are talking about problems with Debian 7, when your kernel log shows: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-48squeeze1) AIUI they are running Wheezy in dom0 and Squeeze in domU (which is where the logs are from), in each case with the appropriate matching kernel I suppose (so 3.2 in dom0 and 2.6.32 in domU). I infer that this issue does not occur with Squeeze on Squeeze. I suppose Wheezy on Wheezy hasn't been attempted? Maybe you could try just *running* the kernel 3.2, and not just try to upgrade your domU? This would be an interesting experiment. As would trying the plain 2.6.32-5-amd64 kernel in the Squeeze domU (the features of the -xen flavour in Squeeze mostly relate to dom0 IIRC). Ian. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: base: Filesystem corruption issue
On Mon, 2013-04-15 at 08:19 -0400, Anthony Sheetz wrote: Did you ever happen to try a transfer over a non-tunnelled connection? Yes, tried file transfers from another machine on the local network - never had a problem with those. So this issue isn't the tunnel, good. Were you able to successfully transfer the file to the dom0 filesystem or to any other system (e.g. one not running Xen) on this end of the openswan link? Yes - tried that several times, and was able to do the transfer with no corruption, and md5sum matched. I'm not sure what error detection/correction scp/rsync or if they have any additional verification options which could be tried or perhaps it is possible to run md5sum on the stream before it hits the disk (can one rsync/scp to stdout? I doubt it). Tried doing 'scp file.sql | md5sum' on DomU which resulted in a matching md5sum. We decided this eliminated the openswan link as the culprit. This was in the domU? That would, I think, eliminate corruption in the network at every stage including the dom0-domU link. That would suggest that the md5sum failures you saw before were caused by writing the file to disk and reading it back (which does at least mean we only have one bug to deal with...) If you can transfer to dom0 OK then it might be interesting to try turning off the various offloads (GSO, SG etc) on the vif link. Any instructions on doing that? The above makes me suspect this isn't a worthwhile experiment but in any case: ethtool -k device to examine and ethtool -K device offload off to turn the various things off. I'd do it both on the device inside the guest and the associated vifX.Y I wonder if the layering of crypto+lvm+xen-blkback is causing the barriers which ext3 requires to function correctly to not occur in the right places. Does something need to be manually configured to enable barriers at some layer? (or perhaps I am thinking of DISCARD support). If you were able to attempt to reproduce without the crypto bit in dom0 for the VM disk that would be really useful. It might also be interesting to try using the ext3 barrier mount option in the guest to switch barriers either off or on (I can't remember what the default was for Squeeze). Google led me to try mounting the file system with barriers=0, and no luck. How did you do this? IIRC getting mount options to the root filesystem to take effect involves more than just editing fstab (rootflags= on command line I think? No idea how one inserts a space there) For experimentation it might be useful to attach an xvdb to the domain and use that as the write target, it'll allow easier experimentation with mount options, and as a bonus you won't keep hosing your root filesystem (which I imagine is getting pretty tedious...) I appreciate that you may have redeployed/downgraded the systems so some of the above experiments might be quite hard to try out but if you could setup a spare system or something it would be very much appreciated. We planned for this, and once we have some ideas to try (with some detailed instructions for trying them) we'll be purchasing a spare hard drive to try them out. We'd like this problem solved, and we're willing to spend a little to do it. Other than the barriers thing I think the most worthwhile thing to try would be a Wheezy domU kernel. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: base: Filesystem corruption issue
Replies in line. On Mon, Apr 15, 2013 at 9:09 AM, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2013-04-15 at 08:19 -0400, Anthony Sheetz wrote: Did you ever happen to try a transfer over a non-tunnelled connection? Yes, tried file transfers from another machine on the local network - never had a problem with those. So this issue isn't the tunnel, good. Were you able to successfully transfer the file to the dom0 filesystem or to any other system (e.g. one not running Xen) on this end of the openswan link? Yes - tried that several times, and was able to do the transfer with no corruption, and md5sum matched. I'm not sure what error detection/correction scp/rsync or if they have any additional verification options which could be tried or perhaps it is possible to run md5sum on the stream before it hits the disk (can one rsync/scp to stdout? I doubt it). Tried doing 'scp file.sql | md5sum' on DomU which resulted in a matching md5sum. We decided this eliminated the openswan link as the culprit. This was in the domU? That would, I think, eliminate corruption in the network at every stage including the dom0-domU link. That would suggest that the md5sum failures you saw before were caused by writing the file to disk and reading it back (which does at least mean we only have one bug to deal with...) If you can transfer to dom0 OK then it might be interesting to try turning off the various offloads (GSO, SG etc) on the vif link. Any instructions on doing that? The above makes me suspect this isn't a worthwhile experiment but in any case: I'd agree - for now, in the interest of time, we'll shelve this avenue of investigation. ethtool -k device to examine and ethtool -K device offload off to turn the various things off. I'd do it both on the device inside the guest and the associated vifX.Y I wonder if the layering of crypto+lvm+xen-blkback is causing the barriers which ext3 requires to function correctly to not occur in the right places. Does something need to be manually configured to enable barriers at some layer? (or perhaps I am thinking of DISCARD support). If you were able to attempt to reproduce without the crypto bit in dom0 for the VM disk that would be really useful. It might also be interesting to try using the ext3 barrier mount option in the guest to switch barriers either off or on (I can't remember what the default was for Squeeze). Google led me to try mounting the file system with barriers=0, and no luck. How did you do this? IIRC getting mount options to the root filesystem to take effect involves more than just editing fstab (rootflags= on command line I think? No idea how one inserts a space there) Ah, ok. Did use fstab options. Will look in to other methods of specifying this. I'd imagine editing the boot option in pygrub might be a good avenue? For experimentation it might be useful to attach an xvdb to the domain and use that as the write target, it'll allow easier experimentation with mount options, and as a bonus you won't keep hosing your root filesystem (which I imagine is getting pretty tedious...) To be sure I understand: create a new lv, mount it, and use it as the write target. That's an excellent idea. Next time I experiment I'll be using that. I appreciate that you may have redeployed/downgraded the systems so some of the above experiments might be quite hard to try out but if you could setup a spare system or something it would be very much appreciated. We planned for this, and once we have some ideas to try (with some detailed instructions for trying them) we'll be purchasing a spare hard drive to try them out. We'd like this problem solved, and we're willing to spend a little to do it. Other than the barriers thing I think the most worthwhile thing to try would be a Wheezy domU kernel. Ok, will try that. If you've got instructions close to hand on installing and using a different kernel in domU, that'd save me the trouble of looking it up. No worries if not - my google foo is decent. Ian.
Bug#705124: base: Filesystem corruption issue
On Mon, 2013-04-15 at 09:21 -0400, Anthony Sheetz wrote: How did you do this? IIRC getting mount options to the root filesystem to take effect involves more than just editing fstab (rootflags= on command line I think? No idea how one inserts a space there) Ah, ok. Did use fstab options. Will look in to other methods of specifying this. I'd imagine editing the boot option in pygrub might be a good avenue? I think so. Or you can (probably) uses extra = foo in your domain configuration file. You can tell if you've edited the right place from /proc/cmdline. I'd expect there would be some indication in dmesg that barriers were or were not in use , but I didn't look For experimentation it might be useful to attach an xvdb to the domain and use that as the write target, it'll allow easier experimentation with mount options, and as a bonus you won't keep hosing your root filesystem (which I imagine is getting pretty tedious...) To be sure I understand: create a new lv, mount it, and use it as the write target. That's an excellent idea. Next time I experiment I'll be using that. Are you using LVM in the domU as well as the dom0? I had thought you were using it only in dom0 but the ambiguity here made me wonder. What I meant was to create a new LV in the dom0, edit the domain configuration to attach it as an extra disk (i.e. xvdb or whatever) and then to format/mount it from within the guest. [...] Ok, will try that. If you've got instructions close to hand on installing and using a different kernel in domU, that'd save me the trouble of looking it up. No worries if not - my google foo is decent. I expect backports.org has a reasonably recent Wheezy kernel which you could install or else I think the kernel is independent enough that a partial upgrade (i.e. add Wheezy to sources.list and apt-get install linux-image-foo) would not pull in too much of Wheezy. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705124: base: Filesystem corruption issue
On Mon, Apr 15, 2013 at 9:29 AM, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2013-04-15 at 09:21 -0400, Anthony Sheetz wrote: How did you do this? IIRC getting mount options to the root filesystem to take effect involves more than just editing fstab (rootflags= on command line I think? No idea how one inserts a space there) Ah, ok. Did use fstab options. Will look in to other methods of specifying this. I'd imagine editing the boot option in pygrub might be a good avenue? I think so. Or you can (probably) uses extra = foo in your domain configuration file. You can tell if you've edited the right place from /proc/cmdline. I'd expect there would be some indication in dmesg that barriers were or were not in use , but I didn't look For experimentation it might be useful to attach an xvdb to the domain and use that as the write target, it'll allow easier experimentation with mount options, and as a bonus you won't keep hosing your root filesystem (which I imagine is getting pretty tedious...) To be sure I understand: create a new lv, mount it, and use it as the write target. That's an excellent idea. Next time I experiment I'll be using that. Are you using LVM in the domU as well as the dom0? I had thought you were using it only in dom0 but the ambiguity here made me wonder. Sorry, domU's volumes are also logical volumes created initially in dom0. So, xvda is backed by a logical volume. What I meant was to create a new LV in the dom0, edit the domain configuration to attach it as an extra disk (i.e. xvdb or whatever) and then to format/mount it from within the guest. That's what I thought you meant, and what I will try. [...] Ok, will try that. If you've got instructions close to hand on installing and using a different kernel in domU, that'd save me the trouble of looking it up. No worries if not - my google foo is decent. I expect backports.org has a reasonably recent Wheezy kernel which you could install or else I think the kernel is independent enough that a partial upgrade (i.e. add Wheezy to sources.list and apt-get install linux-image-foo) would not pull in too much of Wheezy. Thanks, will check in to that. Ian.
Bug#705476: xapian-omega: make error when installing from source
Package: xapian-omega Version: 1.2.12-1 Severity: serious Justification: fails to build from source (but built successfully in the past) trying to build xapian-omega from source: vesuvius:/usr/src# apt-get -b source xapian-omega Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'xapian-omega' packaging is maintained in the 'Svn' version control system at: svn://svn.xapian.org/xapian/trunk/xapian-applications/omega Need to get 638 kB of source archives. Get:1 http://mirror.csclub.uwaterloo.ca/debian/ testing/main xapian-omega 1.2.12-1 (dsc) [1,969 B] Get:2 http://mirror.csclub.uwaterloo.ca/debian/ testing/main xapian-omega 1.2.12-1 (tar) [624 kB] Get:3 http://mirror.csclub.uwaterloo.ca/debian/ testing/main xapian-omega 1.2.12-1 (diff) [12.1 kB] Fetched 638 kB in 2s (266 kB/s) dpkg-source: info: extracting xapian-omega in xapian-omega-1.2.12 dpkg-source: info: unpacking xapian-omega_1.2.12.orig.tar.gz dpkg-source: info: unpacking xapian-omega_1.2.12-1.debian.tar.gz dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package xapian-omega dpkg-buildpackage: source version 1.2.12-1 dpkg-buildpackage: source changed by Olly Betts o...@survex.com dpkg-buildpackage: host architecture amd64 dpkg-source --before-build xapian-omega-1.2.12 debian/rules clean dpkg-buildflags: unknown option `--export=configure' dh_testdir dh_testroot rm -rf debian/build rm -f config.sub config.guess dh_clean debian/rules build dpkg-buildflags: unknown option `--export=configure' dh_testdir # Use the latest config.sub and config.guess from the autotools-dev # package. rm -f config.sub config.guess ln -s /usr/share/misc/config.sub config.sub ln -s /usr/share/misc/config.guess config.guess # Configure in a subdirectory, for neatness. mkdir -p debian/build cd debian/build ../../configure --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc Usage: dpkg-buildflags [action] Actions: --get flag output the requested flag to stdout. --origin flagoutput the origin of the flag to stdout: value is one of vendor, system, user, env. --list output a list of the flags supported by the current vendor. --export=(sh|make) output commands to be executed in shell or make that export all the compilation flags as environment variables. --help show this help message. --version show the version. --disable-dependency-tracking /bin/sh: Syntax error: ( unexpected make: *** [configure-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Build command 'cd xapian-omega-1.2.12 dpkg-buildpackage -b -uc' failed. E: Child process failed -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xapian-omega depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expressi ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libxapian22 1.2.12-2 Search engine library Versions of packages xapian-omega recommends: ii apache2 2.2.16-6+squeeze11 Apache HTTP Server metapackage ii apache2-mpm-prefork [ 2.2.16-6+squeeze11 Apache HTTP Server - traditional n Versions of packages xapian-omega suggests: ii antiword 0.37-6Converts MS Word files to text, PS ii catdoc 0.94.2-1.1MS-Word to TeX or plain text conve ii catdvi 0.14-11+b1DVI to plain text translator ii djvulibre-bin 3.5.23-3 Utilities for the DjVu image forma ii ghostscript8.71~dfsg2-9+squeeze1 The GPL Ghostscript PostScript/PDF ii libwpd-tools 0.8.14-1 Tools from libwpd for converting W ii libwps-tools 0.1.2-1 Tools from libwps for converting W ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction ii poppler-utils [xpd 0.12.4-1.2+squeeze1 PDF utilitites (based on libpopple ii unrtf 0.19.3-1.1+b1 RTF to other formats converter ii unzip 6.0-4 De-archiver for .zip files -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a
Bug#704987: gnome-shell: scrolling in libreoffice-writer freezes system
On 14.04.2013 18:51, Ben Hutchings wrote: On Sun, 2013-04-14 at 16:56 +0200, colliar wrote: This is probably a duplicate of #703715 but the severity should be raised like the reporter of #703715 already mentioned. It freezes a system constantly with potential data loss. Do not get me wrong I was thinking about severity critical. The major concern I have, that it did work much better with some crashes per month but now it reproducibly crashes ten times a day. For me this is a regression. No, see http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.1.2 I see. So it is up to the kernel team to decide which hardware is new and which not ? Are there any guidelines, introduced ~ one year before freeze ? If we were to treat every crash/hang as 'data loss' and hence grave then we would have a few hundred RC bugs and would never release Debian again. Or it would be really outdated. Colliar signature.asc Description: OpenPGP digital signature
Bug#705476: xapian-omega: make error when installing from source
Control: severity -1 normal On 15.04.2013 14:53, Chris Purves wrote: Package: xapian-omega Version: 1.2.12-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The information above refers to the package in wheezy / sid, but the system information indicates: Debian Release: 6.0.7 Packages are not required to be buildable on earlier releases. So long as 1.2.12-1 builds on wheezy, there's no RC bug here. (It might be useful to version the dpkg-dev build-dependency but that's a lower severity issue.) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#705476: xapian-omega: make error when installing from source
Processing control commands: severity -1 normal Bug #705476 [xapian-omega] xapian-omega: make error when installing from source Severity set to 'normal' from 'serious' -- 705476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705476 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705385: mia: FTBFS on powerpc: test suite hangs
The bug does not occur with the latest version of TBB (4.1 Update 2) . -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705385: mia: FTBFS on powerpc: test suite hangs
Gert Wollny gw.foss...@gmail.com writes: According to the changelog the TBB release currently available in debian/sid is the very first that supported 32 bit powerpc, and that version is quite old (from 2011). I will check what happens with the latest version of TBB (4.1 update 2). Please do, thanks! We're too deep into the wheezy freeze for TBB's maintainers to upload a new upstream version into unstable, but cherry-picked patches might qualify for a freeze exemption. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705386: marked as done (neard: FTBFS on several architectures: test-snep-read segmentation fault)
Your message dated Mon, 15 Apr 2013 15:02:59 + with message-id e1urkvr-0007u7...@franck.debian.org and subject line Bug#705386: fixed in neard 0.10+git20130415-1 has caused the Debian Bug report #705386, regarding neard: FTBFS on several architectures: test-snep-read segmentation fault to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 705386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705386 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: neard Version: 0.10+git20130325-1 Severity: serious Justification: fails to build from source Automated builds of neard on several architectures failed due to test-snep-read segmentation faults: https://buildd.debian.org/status/package.php?p=neardver=0.10+git20130325-1 Could you please take a look? Thanks! ---End Message--- ---BeginMessage--- Source: neard Source-Version: 0.10+git20130415-1 We believe that the bug you reported is fixed in the latest version of neard, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 705...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Samuel Ortiz sa...@linux.intel.com (supplier of updated neard package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 15 Apr 2013 16:07:16 +0200 Source: neard Binary: neard neard-tools neard-dev Architecture: source amd64 Version: 0.10+git20130415-1 Distribution: unstable Urgency: low Maintainer: Samuel Ortiz sa...@linux.intel.com Changed-By: Samuel Ortiz sa...@linux.intel.com Description: neard - Near Field Communication (NFC) management daemon neard-dev - neard development files neard-tools - neard command-line tools Closes: 705386 Changes: neard (0.10+git20130415-1) unstable; urgency=low . * New upstream snapshot: - SNEP unit test fragments list handling fixed (Closes: #705386) - LLCP validation server - WiFi handover fixes and unit testing - nfctool snap len usage fixed Checksums-Sha1: 06c7856ccd1a2020205fe0842f37c8db7555d6c2 1403 neard_0.10+git20130415-1.dsc 794ec30104356321204ab047f7bd795101676bb9 466868 neard_0.10+git20130415.orig.tar.gz c698c40a0c05d94d90c2968f02e2bff4d51dd58f 3704 neard_0.10+git20130415-1.debian.tar.gz 061e65df2859629a2bd34d663caa0ef72cc937c8 109938 neard_0.10+git20130415-1_amd64.deb 64e87426747bed99fb0c3bf14712a7ccd95a7287 26618 neard-tools_0.10+git20130415-1_amd64.deb b0477c73a3eb14fc99325ad083ee42b22960f0d4 15550 neard-dev_0.10+git20130415-1_amd64.deb Checksums-Sha256: 8effefd70a5ad2da9d0ab62f86221674ccc5e84290cb1b4766d939c757ad7c23 1403 neard_0.10+git20130415-1.dsc be1bd93973f9dcfdb9c1ad0457362025453c28049b973e25e3d5d2825ab6fc22 466868 neard_0.10+git20130415.orig.tar.gz 7cdbbcc5cc8ecb644f2b7d1468787112e70102042cb97ec9f5f7c8d21062db5f 3704 neard_0.10+git20130415-1.debian.tar.gz 67acfdd52455d057fd6355c11c94a3d52b149cd3bd107c5bd5fc521c2493ef7a 109938 neard_0.10+git20130415-1_amd64.deb 729fffb4d753d4df8ca0c4149ae67a8497ad72b8b5002ab67c8865f1e8f78a86 26618 neard-tools_0.10+git20130415-1_amd64.deb 6284356cfc1f877623d043d5adfe73efdf7ce6096aa9ae435fee310ff2b77e5e 15550 neard-dev_0.10+git20130415-1_amd64.deb Files: eac2521d5a5edb6650df8b8beb8befed 1403 net optional neard_0.10+git20130415-1.dsc 84c89be04e6238b470da19de35916672 466868 net optional neard_0.10+git20130415.orig.tar.gz bc85f8854fbd0aa92b7cc9ab3009debe 3704 net optional neard_0.10+git20130415-1.debian.tar.gz 0a13728c8ad6a68e868ee76aaa9ce034 109938 net optional neard_0.10+git20130415-1_amd64.deb 8cd93866a5c8a343316bfad94db769d0 26618 net optional neard-tools_0.10+git20130415-1_amd64.deb 87c64e714447d770fa6a8913764057e0 15550 devel optional neard-dev_0.10+git20130415-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlFsDUQACgkQuW9ciZ2SjJvOoACfTvDHCpENELlHnzDfreK0LNDR WXkAn2d8Pf9O4naQmuzD+8zkFRNqO5R8 =L2mM -END PGP SIGNATUREEnd Message---
Bug#704613: marked as done (cdebootstrap: signature verification bypass with manipulated InRelease file)
Your message dated Mon, 15 Apr 2013 15:02:35 + with message-id e1urkvt-0007k7...@franck.debian.org and subject line Bug#704613: fixed in cdebootstrap 0.5.10 has caused the Debian Bug report #704613, regarding cdebootstrap: signature verification bypass with manipulated InRelease file to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 704613: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704613 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: cdebootstrap Version: 0.5.9 Severity: grave Tags: security Usertags: gpg-clearsign cdebootstrap can be tricked into unsigned data from an InRelease file. This makes the verification of the gpg signature useless. The particular bug here is in libdebian-installer (0.85)'s parser. It treats -BEGIN PGP SIGNED MESSAGE- NOT as a marker for the start of the signed data (which it obviously isn't). So one can prepend a InRelease file looking like -BEGIN PGP SIGNED MESSAGE- NOT Hash: SHA1 insert malicious Release file contents here -BEGIN PGP SIGNATURE- NOT to a valid InRelease file. gpgv will see the signature in the later part and report that there is no problem, but cdebootstrap will use the first part of the file. The easy workaround is to disable InRelease support which was already done for apt. Other options are splitting InRelease into Release and Release.gpg and verifying those OR using gpg to both extract the signed data and check the signature. Ansgar ---End Message--- ---BeginMessage--- Source: cdebootstrap Source-Version: 0.5.10 We believe that the bug you reported is fixed in the latest version of cdebootstrap, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 704...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Bastian Blank wa...@debian.org (supplier of updated cdebootstrap package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 15 Apr 2013 16:23:16 +0200 Source: cdebootstrap Binary: cdebootstrap cdebootstrap-static cdebootstrap-udeb Architecture: source amd64 Version: 0.5.10 Distribution: unstable Urgency: low Maintainer: Bastian Blank wa...@debian.org Changed-By: Bastian Blank wa...@debian.org Description: cdebootstrap - Bootstrap a Debian system cdebootstrap-static - Bootstrap a Debian system - static binary cdebootstrap-udeb - Bootstrap a Debian system - udeb (udeb) Closes: 704613 Changes: cdebootstrap (0.5.10) unstable; urgency=low . * Disable InRelease support. (closes: #704613) Checksums-Sha1: 1435e8baff83136ede1e20a575f70d21452d087f 1024 cdebootstrap_0.5.10.dsc 97cb1e9a5481d9d0f778cb7806764523237bc791 160558 cdebootstrap_0.5.10.tar.gz 02ffc3758cdb56ae39215cb7c91a402c0a55fcf9 34308 cdebootstrap_0.5.10_amd64.deb fac5c83620a1cb445b934a357e0152e42cf28a3b 843376 cdebootstrap-static_0.5.10_amd64.deb 7e4cd1a9b41ed2cba4149a9081367c32d76c93fe 18680 cdebootstrap-udeb_0.5.10_amd64.udeb Checksums-Sha256: 50260daf1e7d2be255315ec0722b42e29b56ccb9081764e12ba63ddd08ae97fc 1024 cdebootstrap_0.5.10.dsc 8dd0e1ff0ebb3019a2abdda99630143d18ca5fed6823330f4c2754c3f0767980 160558 cdebootstrap_0.5.10.tar.gz e09afbfe6be4593aae251cbfd9fe005ddcb4552258e8d91d693a26c9f64a93ab 34308 cdebootstrap_0.5.10_amd64.deb 94373f6bc4e882681a75cf5c097c3746c0aa9b700295e3e39ab237fc1d05aeb9 843376 cdebootstrap-static_0.5.10_amd64.deb 3e6415a3d8bca48795785db61096ba4fa44688de926257c1e16705db68e890b8 18680 cdebootstrap-udeb_0.5.10_amd64.udeb Files: 3c01a965aa5bc46235a9c4f2af9d716a 1024 admin optional cdebootstrap_0.5.10.dsc 34ea8d2b87480b6c01170cee9d1ce55a 160558 admin optional cdebootstrap_0.5.10.tar.gz 2b2049e779288c83a89935b3a476f832 34308 admin optional cdebootstrap_0.5.10_amd64.deb f300f68f31b0ce08c8017283d706a9f9 843376 admin optional cdebootstrap-static_0.5.10_amd64.deb 5f7cc2fabdc032b6e105d1fba61b5b99 18680 debian-installer optional cdebootstrap-udeb_0.5.10_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlFsDjYACgkQLkAIIn9ODhH0TACfa5nSSPip6mnkZjzc4PIZrlfq +y4AoOsgRNubv97AR0fCN1STg9z+VFh0 =C3AU -END PGP SIGNATUREEnd Message---
Bug#704678: Further useful information.
Interestingly, this was not a problem with the version of argparse than I has packaged (1.2.1), but rather with the way I had packaged it. I put an __init__.py file along with argparse.py into a folder and simply added from argparse import * into __init.py__. This is where the problem lies because although argparse defines a __version__ attribute, it also defines an __all__ attribute which did not include __version__. So I added __version__ to the __all__ attribute list and now the ipython version check is OK. I'm wondering if this is something I should tell the argparse developers or am I just using it in a funny way? Cheers, Mat
Processed: fixed 656166 in 1:017-1~experimental2
Processing commands for cont...@bugs.debian.org: # same as #677154 fixed 656166 1:017-1~experimental2 Bug #656166 [firmware-b43legacy-installer] firmware-b43legacy-installer: unowned files after purge (policy 6.8) Marked as fixed in versions b43-fwcutter/1:017-1~experimental2. thanks Stopping processing here. Please contact me if you need assistance. -- 656166: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656166 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656166: marked as done (firmware-b43legacy-installer: unowned files after purge (policy 6.8))
Your message dated Mon, 15 Apr 2013 15:17:41 + with message-id e1urla5-0003u4...@franck.debian.org and subject line Bug#656166: fixed in b43-fwcutter 1:015-14.1 has caused the Debian Bug report #656166, regarding firmware-b43legacy-installer: unowned files after purge (policy 6.8) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 656166: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656166 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-b43legacy-installer Version: 1:015-11 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the attached log (scroll to the bottom...): 0m16.5s ERROR: FAIL: Package purging left files on system: /lib/firmware not owned /lib/firmware/b43legacynot owned /lib/firmware/b43legacy/a0g0bsinitvals2.fw not owned /lib/firmware/b43legacy/a0g0bsinitvals5.fw not owned /lib/firmware/b43legacy/a0g0initvals2.fw not owned /lib/firmware/b43legacy/a0g0initvals5.fw not owned /lib/firmware/b43legacy/a0g1bsinitvals5.fw not owned /lib/firmware/b43legacy/a0g1initvals5.fw not owned /lib/firmware/b43legacy/b0g0bsinitvals2.fw not owned /lib/firmware/b43legacy/b0g0bsinitvals5.fw not owned /lib/firmware/b43legacy/b0g0initvals2.fw not owned /lib/firmware/b43legacy/b0g0initvals5.fw not owned /lib/firmware/b43legacy/pcm4.fwnot owned /lib/firmware/b43legacy/pcm5.fwnot owned /lib/firmware/b43legacy/ucode11.fw not owned /lib/firmware/b43legacy/ucode2.fw not owned /lib/firmware/b43legacy/ucode4.fw not owned /lib/firmware/b43legacy/ucode5.fw not owned cheers, Andreas Start: 2012-01-11 10:29:13 CET Package: firmware-b43legacy-installer Source: b43-fwcutter Version: 1:015-11 Installed-Size: 33 Maintainer: Fabrizio Regalli fab...@fabreg.it Architecture: all Depends: b43-fwcutter (= 1:015-11), wget Recommends: linux-image Description: Installer package for firmware for the b43legacy driver This package installs the firmware needed for usage of the b43legacy kernel driver. . Supported chipsets: - BCM4301 - BCM4306/2 - BCM4306 Homepage: http://wireless.kernel.org/en/users/Drivers/b43 Section: contrib/kernel Priority: optional Filename: pool/contrib/b/b43-fwcutter/firmware-b43legacy-installer_015-11_all.deb Size: 8502 MD5sum: 745ae0f2d2942accf0d940679d3481cc SHA1: a9622fd219ce23267896f9ae62e6c2c7efd1ee5b SHA256: 7aa47688242fcc52eb9a3c3f1c0c25ae2e48a8f7f2b9933648ae0ce7f3f9fcf9 Executing: sudo /org/piuparts.debian.org/sbin/piuparts --warn-on-others --skip-logrotatefiles-test --scriptsdir /etc/piuparts/scripts/ --tmpdir /tmp/piupartss -ad sid -b ../../sid.tar.gz --mirror http://10.11.12.13/debian firmware-b43legacy-installer=1:015-11 Guessed: debian 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at http://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: -- 0m0.0s INFO: piuparts version 0.43~201201081836~0.42-3645-g3cb298b starting up. 0m0.0s INFO: Command line arguments: '/org/piuparts.debian.org/sbin/piuparts' '--warn-on-others' '--skip-logrotatefiles-test' '--scriptsdir' '/etc/piuparts/scripts/' '--tmpdir' '/tmp/piupartss' '-ad' 'sid' '-b' '../../sid.tar.gz' '--mirror' 'http://10.11.12.13/debian' 'firmware-b43legacy-installer=1:015-11' 0m0.0s INFO: Running on: Linux cake 3.1.0-1-amd64 #1 SMP Sun Dec 11 20:36:41 UTC 2011 x86_64 0m0.0s DEBUG: Created temporary directory /tmp/piupartss/tmpEEr4LP 0m0.0s DEBUG: Unpacking ../../sid.tar.gz into /tmp/piupartss/tmpEEr4LP 0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/piupartss/tmpEEr4LP', '-zxf', '../../sid.tar.gz'] 0m1.3s DEBUG: Command ok: ['tar', '-C', '/tmp/piupartss/tmpEEr4LP', '-zxf', '../../sid.tar.gz'] 0m1.3s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpEEr4LP', 'eatmydata', 'mount', '-t', 'proc', 'proc', '/proc'] 0m1.3s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpEEr4LP', 'eatmydata', 'mount', '-t', 'proc', 'proc', '/proc'] 0m1.3s DEBUG: Created policy-rc.d and chmodded it.
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
reassign 705452 sgml-base found 705452 1.26+nmu4 thanks I had a look at the set of packages changed in testing in the period, and I suspect this change triggered the problem: sgml-base (1.26+nmu4) unstable; urgency=low * Non-maintainer upload. * update-catalog --update-super ignores catalogs referencing non-existent files. (Closes: #676717) Thanks to Jakub Wilk for contributing the parser. * Remove warning about rebuilding packages as it may confuse users. * Quieten update-catalog during trigger and postinst, to avoid warnings for packages in rc state. * Pre-Depend on dpkg = 1.16.4 (Closes: #678902). Removed dependency on dpkg = 1.14.18. sgml-base highlights a bug in dpkg's trigger processing. -- Helmut Grohne hel...@subdivi.de Thu, 21 Jun 2012 16:09:07 +0200 -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#705452 docbook-xml: Fail to upgrade due to pre-depend problem
Processing commands for cont...@bugs.debian.org: reassign 705452 sgml-base Bug #705452 [docbook-xml] docbook-xml: Fail to upgrade due to pre-depend problem Bug reassigned from package 'docbook-xml' to 'sgml-base'. No longer marked as found in versions docbook-xml/4.5-7.1. Ignoring request to alter fixed versions of bug #705452 to the same values previously set found 705452 1.26+nmu4 Bug #705452 [sgml-base] docbook-xml: Fail to upgrade due to pre-depend problem Marked as found in versions sgml-base/1.26+nmu4. thanks Stopping processing here. Please contact me if you need assistance. -- 705452: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705452 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: bug 704645 is forwarded to https://bugs.g10code.com/gnupg/issue1486
Processing commands for cont...@bugs.debian.org: forwarded 704645 https://bugs.g10code.com/gnupg/issue1486 Bug #704645 [gnupg] gpg --verify suggests entire file was verified, even if file contains auxiliary data Changed Bug forwarded-to-address to 'https://bugs.g10code.com/gnupg/issue1486' from 'https://bugs.g10code.com/gnupg/msg4558' thanks Stopping processing here. Please contact me if you need assistance. -- 704645: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704645 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699834: dlz-ldap-enum: FTBFS: /usr/include/dns/view.h:76:21: fatal error: dns/rrl.h: ENOENT
This issue seems to have been solved by redhat [1] : This update also fixes the following bug: * Previously, rebuilding the bind-dyndb-ldap source RPM failed with a /usr/include/dns/view.h:76:21: error: dns/rrl.h: No such file or directory error. (BZ#928439) -Ralf. [1] http://rhn.redhat.com/errata/RHSA-2013-0689.html -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.univ-paris-diderot.fr/~treinen/ = New email address: trei...@pps.univ-paris-diderot.fr = -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tbb on powerpc needs to be fixed first
Processing commands for cont...@bugs.debian.org: package src:mia Limiting to bugs with field 'package' containing at least one of 'src:mia' Limit currently set to 'package':'src:mia' block 705385 by 705495 Bug #705385 [src:mia] mia: FTBFS on powerpc: test suite hangs 705385 was not blocked by any bugs. 705385 was not blocking any bugs. Added blocking bug(s) of 705385: 705495 End of message, stopping processing here. Please contact me if you need assistance. -- 705385: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705385 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
* Faidon Liambotis parav...@debian.org wrote: On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: I suspect the buildd (schroeder in this case) has a 32bit userland and thus has a HOSTTYPE of sparc instead of sparc64. I should be a one-line patch, but the only available sparc test machine (smetana) is sparc64 and so I don't have the ability to test this. It bothers me to make an upload simply to see if the sparc build machine will succeed. How would you handle this situation? The sparc Debian port is 32-bit userland, this has nothing to do with the buildd. The (upcoming) sparc64 port will be a separate, 64-bit userland port. It's currently residing on debian-ports.org and buildds are already building new uploads; it seems liburcu 0.7.6-1 built fine there: http://buildd.debian-ports.org/status/package.php?p=liburcusuite=sid Both schroeder and smetana have a 64-bit kernel, in fact I don't think the sparc port has a 32-bit kernel at all anymore. smetana has all the build dependencies to build liburcu on the sid chroot, if you want to experiment. Note that this isn't something that has recently changed, so this doesn't explain why sparc used to work with previous liburcu versions but stopped working. This probably has something to do with a liburcu upstream change, you should track this down. On the buildd machines that I cannot test on, autoconf sets $host_cpu to 'sparc' instead of 'sparc64'. This caused me to assume they had a 32bit kernel. On the machine that I can test on (smetana), autoconf sets $host_cpu correctly to 'sparc64' - and so liburcu builds and runs fine there. The buildd machines are distinctly different from smetana. I had previously mapped 'sparc' to 'sparc64' to fix this, which caused everything to build successfully. But without testing, I didn't feel it was the correct thing to do, so I removed the patch. This is why the build stopped working - not due to upstream changes. Without access to one of those machines to test on, I have two options: 1. Re-enable the mapping of 'sparc' to 'sparc64' so the package builds successfully and hope that it executes properly. 2. Remove sparc from the supported architectures so that users will not risk installing a broken package. Option 2 seems the only reasonable choice to me, unless you have a better suggestion. -- Jon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tbb on powerpc needs to be fixed first
Processing commands for cont...@bugs.debian.org: package src:mia Limiting to bugs with field 'package' containing at least one of 'src:mia' Limit currently set to 'package':'src:mia' block 705385 by 705495 Bug #705385 [src:mia] mia: FTBFS on powerpc: test suite hangs 705385 was blocked by: 705495 705385 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #705385 to the same blocks previously set End of message, stopping processing here. Please contact me if you need assistance. -- 705385: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705385 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: I suspect the buildd (schroeder in this case) has a 32bit userland and thus has a HOSTTYPE of sparc instead of sparc64. I should be a one-line patch, but the only available sparc test machine (smetana) is sparc64 and so I don't have the ability to test this. It bothers me to make an upload simply to see if the sparc build machine will succeed. How would you handle this situation? The sparc Debian port is 32-bit userland, this has nothing to do with the buildd. The (upcoming) sparc64 port will be a separate, 64-bit userland port. It's currently residing on debian-ports.org and buildds are already building new uploads; it seems liburcu 0.7.6-1 built fine there: http://buildd.debian-ports.org/status/package.php?p=liburcusuite=sid Both schroeder and smetana have a 64-bit kernel, in fact I don't think the sparc port has a 32-bit kernel at all anymore. smetana has all the build dependencies to build liburcu on the sid chroot, if you want to experiment. Note that this isn't something that has recently changed, so this doesn't explain why sparc used to work with previous liburcu versions but stopped working. This probably has something to do with a liburcu upstream change, you should track this down. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Also a good point, thank you for the suggestions. Great, thanks, looking forward to these changes. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701492: libatk-wrapper-java: Hangs starting applications
I'm unaware of any particularly interesting configuration of my gnome session. What would be a good way to test with as much configuration as possible removed other than enabling orca? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704775: Processed: found 704775 in 1.8.3+dfsg-4squeeze6
My recommendation is that this is not worth a DSA or stable fix for squeeze unless some Debian user comes forward and says that they're seeing crashes in the wild related to this. --Sam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705435: [kfreebsd] hangs on pulseaudio --start
So far as I can tell, this bug is a race condition; on one machine I can reproduce it about 75% of the time, less often under ktrace, and never under gdb. During gdm3/GNOME startup it is called several times and almost certainly means a non-starting session. Sometimes it prints 'Daemon startup fails' before the hang, and sometimes it does not. I think it hangs within the lock-autospawn code, for synchronisation between threads. I think if one of the threads is suspended, it does not resume, and so the other one waits for it indefinitely. This may be a quirk of kFreeBSD's threads implementation, or may happen if a signal is being masked that should not be. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di
Hello Aurélien!
Aurelien Jarno aure...@debian.org (14/04/2013):
Sorry to answer late, I only have been able to test it now.
Unfortunately the vexpress image is now broken, due to this change:
| * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
|images (Closes: #705118)
nic-modules is still needed on vexpress as it provides the module for
the on-board NIC.
no worries. Thanks for the heads-up and the fix, I'll be re-uploading
src:d-i in a few (dozens of) minutes accordingly.
tasksel and possibly gdm3/gnome-session were being considered for rc2
anyway, so that's not really delaying the release…
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#705124: Info received (base: Filesystem corruption issue)
Current status. New laptop hard drive purchased and installed. Experiment 1 Instead of LVM with full disk encryption, have used LVM without full disk encryption. Instead of transferring file to the lv used for DomU '/', have created a new lv mounted with 'mount /dev/xvda3 /mnt' insided DomU to use for transferring data to. Result: 4.9Gb file transferred fine! Experiment 2 Change from above (1): tried transferring to same lv as DomU's '/' Result: successful transfer. Experiment 3 Change from above (2): LVM with Full Disk Encryption Install package linux-image-3.2.0-0.bpo.4-amd64 from backports.debian.org data transferred to root filesystem. Result: md5sum fails, failure. Experiment 4 Change from above (3): experiment trying to disable barriers, with no luck. Tried booting with rootflags=barrier=0, putting barrier=0 in /etc/fstab. None of these prevented seeing blkfront: xvda2: barriers enabled in the kern.log. Couldn't proceed further. Discussion: file sizes are always correct, which is interesting. Seems that full disk encryption is the culprit. What's next?
Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di
On Mon, Apr 15, 2013 at 10:34:03AM +0200, Aurelien Jarno wrote:
On Mon, Apr 15, 2013 at 01:47:28AM +0100, Ben Hutchings wrote:
On Sun, 2013-04-14 at 23:41 +0200, Aurelien Jarno wrote:
[...]
Sorry to answer late, I only have been able to test it now.
Unfortunately the vexpress image is now broken, due to this change:
| * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
|images (Closes: #705118)
nic-modules is still needed on vexpress as it provides the module for
the on-board NIC.
Since any system with external USB ports should be able to work with
arbitrary USB Ethernet controllers, I added nic-{usb,wireless}-modules
packages and removed the USB modules you originally specified in
nic-modules. In the case of mx5 this left nic-modules empty, and I
removed it, but for vexpress there was that one module left, smsc911x.
Unfortunately I then removed nic-modules from the installer for *both*
flavours instead of just mx5.
I just tried adding smsc91xx back into the current daily netboot initrd
and it seems to work in QEMU (up to the point where the installer finds
I didn't attach a disk).
Yes, I have committed such a change, and I have been able to do a full
installation that way. The daily image that will be generated in a few
hours should have the fix, I will test it when available.
I have just done a test of the daily image from this morning, and the
installation was successful.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704484: solving the mod_vroot problem
Since this bug is wheezy RC, I'll try to contribute a little to solve it: Francesco P. Lovergine wrote: Adam D. Barratt wrote: mod_vroot used to be in proftpd-basic in squeeze, it's moved to a separate package in wheezy. and to be honest I would avoid to add proftpd-mod-vroot as a strict dependency. It is an optional (and experimental) module and the problem would be simply resolved by installing it by hand after a dist-upgrade. One solution to this problem is to force installation of proftpd-mod-vroot. Either by depending on it or by merging the module back into the proftpd package. The module is very tiny: Compressed Size: 17.0 k Uncompressed Size: 85.0 k relative to proftpd: Compressed Size: 2556 k Uncompressed Size: 4271 k so from the packagesize/bloat point of view depending on the package doesn't really change much. A weaker dependency would be to recommend it. Which would signal only deselect the proftpd-mod-vroot package if you really know what you are doing to the user. This option would pretty much keep the user safe from harm. If you make proftpd only suggest the proftpd-mod-vroot or won't depend on it at all then I think that change should both be noted in the NEWS file and in the wheezy release notes. Hope this helps *t -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705435: [kfreebsd] hangs on pulseaudio --start
On my system the daemon fails to start in any case with 'Daemon startup
failed', but that is a separate issue and less serious. There seem to
be two separate places where pulseaudio --start may hang indefinitely on
kfreebsd:
1. after printing 'Daemon startup failed' - the attached patch fixes
this hang (I believe some real-time signals are being blocked, which are
necessary for kFreeBSD's threads implementation, LinuxThreads, to work
properly);
2. before printing 'Daemon startup failed' - this happens approx. 10x
less frequently (so applying the patch is already an improvement) - I'm
not sure yet what causes this.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: pulseaudio-2.0/src/pulsecore/core-util.c
===
--- pulseaudio-2.0.orig/src/pulsecore/core-util.c 2012-05-13 14:26:37.0 +0100
+++ pulseaudio-2.0/src/pulsecore/core-util.c 2013-04-15 20:12:15.061854000 +0100
@@ -2492,7 +2492,8 @@
}
int pa_unblock_sigsv(const int except[]) {
-#ifndef OS_IS_WIN32
+/* :XXX: kFreeBSD bug #705435 */
+#if !defined(OS_IS_WIN32) !defined(__FreeBSD_kernel__)
int i;
sigset_t ss;
Bug#704521: virtuoso-opensource-6.1: use start-stop-daemon flags instead
Frode Severin Hatlevik writes: When calling '/etc/init.d/virtuoso-opensource-6.1 stop', virtuoso may still be running after the script completes. This might lead to database corruption, e.g. on system reboot. [...] I have modified the script to temporarily circumvent the situation on my system by enclosing part of this snippet in a while-loop [...] If the server does not exit cleanly at some point, I have effectively created an infinite loop. Instead of looping and calling stop_server that in turn would call start-stop-daemon, we can tell start-stop-daemon directly to wait and retry. From the start-stop-daemon manpage: Demonstration of a custom schedule for stopping food: start-stop-daemon --stop --oknodo --user food --name food \ --pidfile /run/food.pid --retry=TERM/30/KILL/5 So we could do something like this instead ## --- virtuoso-opensource-6.1.orig2013-04-15 21:37:29.948141713 +0200 +++ virtuoso-opensource-6.1 2013-04-15 21:38:53.476142007 +0200 @@ -153,7 +153,8 @@ # if we are using a daemonuser then look for process that match start-stop-daemon --stop --quiet --pidfile $PIDFILE \ --user $DAEMONUSER \ ---exec $DAEMON +--exec $DAEMON \ +--retry=TERM/30/KILL/5 errcode=$? fi ## The timeouts are of course purely arbitrary. Do they look about OK? That is sending a TERM, waiting 30 seconds for the process to terminate and if it's not dead then SIGKILLing it and waiting further 5 seconds for it to be cleaned up (that's at least how I interpret the start-stop-daemon manpage). This solution would seem a lot more robust than the loop. Since I am not running virtuoso (but trying to help to drive the wheezy RC bug count down) I'd be nice if you Frode could test that it actually works as expected and well? What do think of this solution José? *t
Bug#705037: FTBFS on sparc
On Mon, Apr 15, 2013 at 01:15:38PM -0400, Jon Bernard wrote: On the buildd machines that I cannot test on, autoconf sets $host_cpu to 'sparc' instead of 'sparc64'. This caused me to assume they had a 32bit kernel. On the machine that I can test on (smetana), autoconf sets $host_cpu correctly to 'sparc64' - and so liburcu builds and runs fine there. The buildd machines are distinctly different from smetana. I think this is because the buildds set the personality to be 32-bit as to always build for 32-bit sparc ports, no matter the running kernel of the buildd. This is just an interpretation of the effect I'm seeing, I can't back this up with a pointer to the code :) I think using $host_cpu for what liburcu uses it is flawed in this sense (also, host? why not target?). I could be wrong though, I don't claim to be an expert on such things. I'd suggest contacting the porter people and in particular the sparc porters. I had previously mapped 'sparc' to 'sparc64' to fix this, which caused everything to build successfully. But without testing, I didn't feel it was the correct thing to do, so I removed the patch. This is why the build stopped working - not due to upstream changes. Yeah, I think this is the wrong way to go. The current sparc port only support 64-bit kernels, so it'd probably work on all cases, but it's not right to use 64-bit asm on a 32-bit userland port. Without access to one of those machines to test on, I have two options: I have access to schroeder and can assure you that there's no difference whatsoever between the two. But try running linux32 dpkg-buildpackage if you want to emulate this. BTW, configure.ac seems to make some assumptions about ARM optimization falgs; I'm unsure if these are correct for Debian, you should double-check if you haven't already. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: r4213 - in branches/samba/wheezy/debian: . patches
Processing commands for cont...@bugs.debian.org: tags 454770 pending Bug #454770 [samba] schannel_store.tdb should not be kept in /etc/samba Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 454770: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454770 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454770: [Pkg-samba-maint] Bug#454770: Bug#454770: Bug#454770: schannel_store.tdb should not be kept in /etc/samba
Hi, On Mon, Apr 15, 2013 at 09:52:01AM +0200, Ivo De Decker wrote: I'm somewhat concerned about idmap2.tdb. If we get this one wrong, users can get the wrong unix uid's, which could be very bad on a fileserver. If only one version exists (in either /etc or /var/...) there should be no problem, but if both exist, it might be better to error out instead of picking one of them. That would need a debconf notification explaining the situation, which ideally would be translated as well. This problem could happen if someone installed samba from squeeze, upgraded to wheezy or backports, and then upgraded to the (future) final wheezy version. Also note that a real world setup will go silently wrong on this first upgrade. What do you think? For schannel_store.tdb, I don't know the impact of suddenly moving back to an old version (which would happen if there still was one left in /var/...). Can someone shed some light on this? Is it better to remove it in this case? (MACHINE.SID, at least, is a legacy file that's being read but not written for compatibility only, so we don't need to migrate it in the maintainer script.) It seems MACHINE.SID is deleted on startup by samba since before wheezy, so this one should not cause any problems (if I read the code correctly). I will try to do some tests with an idmap setup tonight. I committed a new version of the path, which also fixes the other files, and moves idmap2.tdb. I did a number of test with an idmap setup, and the upgrade seems to work fine. A situation with duplicate files for idmap2.tdb is easy to reproduce (install squeeze, upgrade to wheezy). In that case, the result from the new version might not be the right one (the postinst script will not overwrite an existing old version of idmap2.tdb). I'm still not sure what to do about this. I don't think this should stop the fix from getting into wheezy, so maybe the current version should just be uploaded. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454770: [Pkg-samba-maint] Bug#454770: Bug#454770: Bug#454770: schannel_store.tdb should not be kept in /etc/samba
On Mon, Apr 15, 2013 at 11:39:13PM +0200, Ivo De Decker wrote: I committed a new version of the path, which also fixes the other files, and moves idmap2.tdb. I did a number of test with an idmap setup, and the upgrade seems to work fine. A situation with duplicate files for idmap2.tdb is easy to reproduce (install squeeze, upgrade to wheezy). In that case, the result from the new version might not be the right one (the postinst script will not overwrite an existing old version of idmap2.tdb). I'm still not sure what to do about this. I don't think this should stop the fix from getting into wheezy, so maybe the current version should just be uploaded. I agree; I'm not sure we're going to get a perfect fix here, so we should at least get the 90% fix in ASAP. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#704775: Processed: found 704775 in 1.8.3+dfsg-4squeeze6
Sam Hartman hartm...@debian.org writes: My recommendation is that this is not worth a DSA or stable fix for squeeze unless some Debian user comes forward and says that they're seeing crashes in the wild related to this. --Sam Keep in mind that unmodified client software can trivially trigger this vulnerability. I can do an explicit check of the trigger against the 1.8 branch if you'd like confirmation. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696642: Bug present in 0.7.8
Greetings, Just a heads up, this problem has returned in 0.7.8. The problem is was not present in 0.7.6~test nor 0.7.7. Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704019: iceweasel: Iceweasel Crashes upon loading pages using JavaScript
Gene A Grimm: Nearly every page results in immediate crash of Iceweasel between 85-95% of the time ... #4 0xa8c551a7 in ?? () from /usr/lib/flashplugin-nonfree/libflashplayer.so ... #16 0xb6dc9e9f in nsPluginHostImpl::TrySetUpPluginInstance (this=0xaac043a0, aMimeType=0xaac03c18 application/x-shockwave-flash, aURL=0xaacbd950, aOwner=0xaad38470) Please try to disable the flash player plugin and check if the problem persists. Best wishes, Bob
Bug#454770: marked as done (schannel_store.tdb should not be kept in /etc/samba)
Your message dated Mon, 15 Apr 2013 22:48:50 + with message-id e1urscg-0002i2...@franck.debian.org and subject line Bug#454770: fixed in samba 2:3.6.6-6 has caused the Debian Bug report #454770, regarding schannel_store.tdb should not be kept in /etc/samba to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 454770: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454770 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: samba Version: 3.0.27a-2 Severity: normal This is a FHS violation, and schannel_store.tdb should likely be in /var/run/samba (or /var/lib, if it is ok to have the channel secrets persist boots). -- System Information: Debian Release: 4.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.9 (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/bash Versions of packages samba depends on: ii adduser 3.105 add and remove users and groups ii debconf [debconf-2.0] 1.5.17 Debian configuration management sy ii libacl1 2.2.45-1 Access control list shared library ii libattr1 1:2.4.39-1 Extended attribute shared library ii libc6 2.7-3 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libcomerr21.40.2-1 common error description library ii libcupsys21.3.4-2Common UNIX Printing System(tm) - ii libgnutls13 2.0.4-1the GNU TLS library - runtime libr ii libkrb53 1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries ii libldap2 2.1.30.dfsg-13.5 OpenLDAP libraries ii libpam-modules0.99.7.1-5 Pluggable Authentication Modules f ii libpam-runtime0.99.7.1-5 Runtime support for the PAM librar ii libpam0g 0.99.7.1-5 Pluggable Authentication Modules l ii libpopt0 1.10-3 lib for parsing cmdline parameters ii logrotate 3.7.1-3Log rotation utility ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip ii procps1:3.2.7-5 /proc file system utilities ii samba-common 3.0.27a-2 Samba common files used by both th ii update-inetd 4.27-0.6 inetd.conf updater ii zlib1g1:1.2.3.3.dfsg-7 compression library - runtime samba recommends no packages. -- debconf information: samba/generate_smbpasswd: false samba/run_mode: daemons ---End Message--- ---BeginMessage--- Source: samba Source-Version: 2:3.6.6-6 We believe that the bug you reported is fixed in the latest version of samba, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 454...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ivo De Decker ivo.dedec...@ugent.be (supplier of updated samba package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 15 Apr 2013 23:56:23 +0200 Source: samba Binary: samba samba-common-bin samba-common samba-tools smbclient swat samba-doc samba-doc-pdf libpam-smbpass libsmbclient libsmbclient-dev winbind libpam-winbind libnss-winbind samba-dbg libwbclient0 libwbclient-dev Architecture: source amd64 all Version: 2:3.6.6-6 Distribution: unstable Urgency: low Maintainer: Debian Samba Maintainers pkg-samba-ma...@lists.alioth.debian.org Changed-By: Ivo De Decker ivo.dedec...@ugent.be Description: libnss-winbind - Samba nameservice integration plugins libpam-smbpass - pluggable authentication module for Samba libpam-winbind - Windows domain authentication integration plugin libsmbclient - shared library for communication with SMB/CIFS servers libsmbclient-dev - development files for libsmbclient libwbclient-dev - Samba winbind client library - development files libwbclient0 - Samba winbind client library
Bug#696642: Oops.
Andrew, I fired that email off too quickly. After further examination, I noticed I had typo'd bridge_ports as bridge_port. The timing of my change coincided with running updates earlier, and the behavior was as it was when I had the issue, so I was too quick to report. ifupdown is working fine. Sincerest apologies, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: cloning 701492, severity of -1 is important
Processing commands for cont...@bugs.debian.org: clone 701492 -1 Bug #701492 [libatk-wrapper-java] libatk-wrapper-java: Hangs starting applications Bug 701492 cloned as bug 705511 severity -1 important Bug #705511 [libatk-wrapper-java] libatk-wrapper-java: Hangs starting applications Severity set to 'important' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 701492: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701492 705511: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705511 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 701492
Processing commands for cont...@bugs.debian.org: tags 701492 + pending Bug #701492 [libatk-wrapper-java] libatk-wrapper-java: Hangs starting applications Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 701492: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701492: marked as done (libatk-wrapper-java: Hangs starting applications)
Your message dated Mon, 15 Apr 2013 23:32:42 + with message-id e1urst8-0005nv...@franck.debian.org and subject line Bug#701492: fixed in java-atk-wrapper 0.30.4-3 has caused the Debian Bug report #701492, regarding libatk-wrapper-java: Hangs starting applications to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 701492: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: libatk-wrapper-java Version: 0.30.4-2 Severity: important Hi. I am using openjdk-6 (6b27-1.12.3-1) In uncommented libatk-wrapper which has been commented out of accessibility.properties in the openjdk packages because of startup problems. When I do that policytool works fine with orca. Then I tried running jexplorer. It hangs and spins; the window never opens. I could understand if an application didn't end up being very accessible, but failing to start with libatkwrapper-java seems like a significant libatk-wrapper-java bug. I'm happy to provide more info if it turns out aptitude install jxplorerjxplorer is not sufficient to reproduce -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 2.6.39-2-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/bash libatk-wrapper-java depends on no packages. Versions of packages libatk-wrapper-java recommends: ii libatk-wrapper-java-jni 0.30.4-2 libatk-wrapper-java suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: java-atk-wrapper Source-Version: 0.30.4-3 We believe that the bug you reported is fixed in the latest version of java-atk-wrapper, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 701...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Samuel Thibault sthiba...@debian.org (supplier of updated java-atk-wrapper package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 16 Apr 2013 00:52:17 +0200 Source: java-atk-wrapper Binary: libatk-wrapper-java libatk-wrapper-java-jni Architecture: source all amd64 Version: 0.30.4-3 Distribution: unstable Urgency: low Maintainer: Debian Accessibility Team debian-accessibil...@lists.debian.org Changed-By: Samuel Thibault sthiba...@debian.org Description: libatk-wrapper-java - ATK implementation for Java using JNI libatk-wrapper-java-jni - ATK implementation for Java using JNI (JNI bindings) Closes: 701492 Changes: java-atk-wrapper (0.30.4-3) unstable; urgency=low . * Document that accessibility is disabled by default in openjdk, how to re-enable it, and that this is because it is not stable with non-threaded applications (Closes: #701492). Checksums-Sha1: 89737b21f54620bf6b2082d2a3550ccd9e5b95f7 2228 java-atk-wrapper_0.30.4-3.dsc 305f6ac4f28a4679d21151d61cf1605b500821c4 2603 java-atk-wrapper_0.30.4-3.debian.tar.bz2 237da9dab279f8f89b6cb8fc5000663ddc2e28b3 31222 libatk-wrapper-java_0.30.4-3_all.deb 7c6da8eb350503636e7a8a5c0b6e3a1ee4355ba7 31792 libatk-wrapper-java-jni_0.30.4-3_amd64.deb Checksums-Sha256: 025fc975b93774ecaaf128f786eb334f03ae928ffbda0271e2fd496611ac88b6 2228 java-atk-wrapper_0.30.4-3.dsc ba1d8f8c30b7331829fcabbd52abdc4b64cea24674e833c5097d18847d5997a4 2603 java-atk-wrapper_0.30.4-3.debian.tar.bz2 a6ad75f691ccda4daff999894c0c7bdcf9923a1d88ff4e7b00cdd903acbb7206 31222 libatk-wrapper-java_0.30.4-3_all.deb 83eb7d42150df3ad90b4f2addb8bb00b95f08ac043fa494360f598413821a953 31792 libatk-wrapper-java-jni_0.30.4-3_amd64.deb Files: de31368906c09e66981f16150227aa6c 2228 java optional java-atk-wrapper_0.30.4-3.dsc 12d93b7c75033d7a9c2aab7886dc1ce1 2603 java optional java-atk-wrapper_0.30.4-3.debian.tar.bz2 f20b00a4c66116eedc9a6880907b0f80 31222 java optional libatk-wrapper-java_0.30.4-3_all.deb f5bcfa9a482585fe25f309d27e675dfa 31792 java optional libatk-wrapper-java-jni_0.30.4-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux)
Bug#704775: Processed: found 704775 in 1.8.3+dfsg-4squeeze6
Tom == Tom Yu t...@mit.edu writes: Tom Sam Hartman hartm...@debian.org writes: My recommendation is that this is not worth a DSA or stable fix for squeeze unless some Debian user comes forward and says that they're seeing crashes in the wild related to this. --Sam Tom Keep in mind that unmodified client software can trivially Tom trigger this vulnerability. I can do an explicit check of the Tom trigger against the 1.8 branch if you'd like confirmation. I understand. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#705435: [kfreebsd] hangs on pulseaudio --start
Processing control commands: tags -1 + patch Bug #705435 [pulseaudio] [kfreebsd] hangs on pulseaudio --start Added tag(s) patch. -- 705435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705435: [kfreebsd] hangs on pulseaudio --start
Control: tags -1 + patch
The simple task of starting a pulseaudio daemon, seems to require
creation of a lockfile, using an additional thread to synchronise that,
then forking, doing the same again using two more threads, and forking
once more.
Happily I found a much, much simpler solution in FreeBSD ports, where a
similar problem had already been reported in this code. The relevant
block is simply commented out and yet I don't notice any functional
difference. Only that it works reliably and allows GDM3 and GNOME
sessions to start (have tested this on kfreebsd-amd64).
http://svnweb.freebsd.org/ports/head/audio/pulseaudio/files/patch-src_daemon_main.c?r1=231972r2=231971pathrev=231972
Please could we apply the same change (attached, commented and cleaned
up) for kFreeBSD, to fix this bug for wheezy. The other patch I
suggested earlier is made unnecessary by this.
Thank you,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: pulseaudio-2.0/src/daemon/main.c
===
--- pulseaudio-2.0.orig/src/daemon/main.c 2012-05-13 14:26:37.0 +0100
+++ pulseaudio-2.0/src/daemon/main.c 2013-04-16 00:25:32.164872810 +0100
@@ -735,6 +735,10 @@
* first take the autospawn lock to make things
* synchronous. */
+/* This locking and thread synchronisation code doesn't work reliably
+ * on kFreeBSD (Debian bug #705435), or in upstream FreeBSD ports
+ * (bug reference: ports/128947, patched in SVN r231972). */
+#if !defined(__FreeBSD__) !defined(__FreeBSD_kernel__)
if ((autospawn_fd = pa_autospawn_lock_init()) 0) {
pa_log(Failed to initialize autospawn lock);
goto finish;
@@ -746,6 +750,7 @@
}
autospawn_locked = TRUE;
+#endif
}
if (conf-daemonize) {
Bug#699834: dlz-ldap-enum: FTBFS: /usr/include/dns/view.h:76:21: fatal error: dns/rrl.h: ENOENT
control: tag -1 patch, pending Hi, I've uploaded an nmu fixing this issue to delayed/5. Please see attached patch. Best wishes, Mike bind.patch Description: Binary data
Processed: re: dlz-ldap-enum: FTBFS: /usr/include/dns/view.h:76:21: fatal error: dns/rrl.h: ENOENT
Processing control commands: tag -1 patch, pending Bug #699834 [libbind-dev] dlz-ldap-enum: FTBFS: /usr/include/dns/view.h:76:21: fatal error: dns/rrl.h: ENOENT Added tag(s) pending and patch. -- 699834: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699834 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704987: gnome-shell: scrolling in libreoffice-writer freezes system
On Mon, 2013-04-15 at 15:53 +0200, colliar wrote: On 14.04.2013 18:51, Ben Hutchings wrote: [...] No, see http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.1.2 I see. So it is up to the kernel team to decide which hardware is new and which not ? Are there any guidelines, introduced ~ one year before freeze ? [...] 'New hardware' means anything not yet supported. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#704484: Upgrading from Squeeze to Wheezy breaks proftpd
Hi, I've uploaded an nmu adding proftpd-mod-vroot as a recommends to delayed/2. I believe this fixes the bug while respecting the maintainer's request. Please let me know if I should delay longer. Patch attached. Best wishes, Mike proftpd.patch Description: Binary data
Processed: your mail
Processing commands for cont...@bugs.debian.org: tag 704484 patch, pending Bug #704484 [proftpd-dfsg] Upgrading from Squeeze to Wheezy breaks proftpd Added tag(s) pending and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 704484: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704484 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
