Bug#899002: systemd: networking and rdma-load-modules@infiniband service run in parallel despite the declared dependency order
severity 899002 important clone 899002 -1 -2 retitle -2 Networking not waiting for USB Ethernet dongle to be detected thanks On Sun, Jan 27, 2019 at 02:40:06PM +0100, Benjamin Drung wrote: > severity 899002 grave The definition of grave is: “makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.” While it might make the package unusable on YOUR system, this is only an issue for some particular, not so common setups. Also, this issue has nothing to do with RDMA, and while there are similarities, I'll treat this as a separate bug. > This race condition bug hit me also with an Odroid HC1. This ARM boards > has an Ethernet controller connected over USB. Without this bugfix, the > networking service does not wait until the USB hub is initialised and > the Ethernet controller is found: Can you provide me with a copy of your /etc/network/interfaces file? In particular, did you use "auto eth0" or "allow-hotplug eth0"? If the interface's presence is delayed because of the USB hub being initialized in parallel, then using allow-hotplug might work around the issue for you. > Please get ifupdown >= 0.8.33 > into testing! Good point, I have to fix #900269 to do that. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#920791: New libglm-dev
Package: libglm-dev Version: 0.9.9.3-1 Severity: grave Justification: renders package unusable On Tue, Jan 29, 2019 at 12:09:37AM +0100, Sylvain Beucler wrote: > I receive lots of reports of GNU FreeDink not building with weird errors > from GLM - and I can't reproduce locally! > > I see you just made a new upload - any clue? > > * Build log: > https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=s390x&ver=109.4-1&stamp=1548702166&file=log > * Build log: > https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=ppc64el&ver=109.4-2&stamp=1548715950&file=log > * Build log: > https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=armel&ver=109.4-2&stamp=1548716184&file=log I cannot reproduce it either, but according to the logs it looks like it might be some #defines not working properly on some architectures. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#920791: New libglm-dev
retitle 920791 FTBFS on all non-SIMD architectures forwarded 920791 https://github.com/g-truc/glm/issues/865 thanks On Tue, Jan 29, 2019 at 07:50:44AM +0100, Guus Sliepen wrote: > I cannot reproduce it either, but according to the logs it looks like it > might be some #defines not working properly on some architectures. The issue is that the new version of GLM conditionally adds constexpr to some member functions where that would cause a compiler error. It so happens that constexpr is not used on any architecture with SIMD instructions supported by GLM, which are amd64 and arm64 as far as I can tell. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#880982: ifup does not trigger scripts any more after booting
Am 06.11.2017 um 17:53 schrieb Narcis Garcia: > Interface is declared at /etc/network/interfaces : > auto enp2s0 > allow-hotplug enp2s0 > iface enp2s0 inet dhcp > > An executable script: > /etc/network/if-up.d/test1 > only runs on boot (per each NIC). If network cable is plugged to enp2s0 > some minutes later, script is not run. > Same behavior when booting with network, and unplugging + plugging later. Hotplug in the context of udev is the hotplugging of a hardware PCI or USB device, not of a network cable. If you want to have a network interface brought up or down whenever a cable is (un)plugged, try installing the netplug package, edit /etc/netplug/netplugd.conf and add enp2s0 to it, and remove both "auto enp2s0" and "allow-hotplug enp2s0" from /etc/network/interfaces. Note that cable (un)plug events might not be properly supported by all network cards. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#880982: ifup does not trigger scripts any more after booting
On Tue, Nov 07, 2017 at 09:55:17PM +0100, Narcis Garcia wrote: > Thanks Guus for the suggestion about netplug as alternative. > Network interface's configurtaion (IP) is already done when hotplugging > the cable. > > What is not working on same event is the run-parts of scripts in > /etc/network/if-up.d [...] Aha. If you are using DHCP, then the DHCP client will probably detect that the cable is plugged in again at some point, and will assign it an address. However, ifupdown is never called when that happens, so ifupdown will not cause any of the scripts to run. Also, ifupdown will consider the interface to be up all the time, whether the cable is plugged in or not. Note that dhclient itself can also run scripts when it gets or loses a lease, see man dhclient-script. > (as non-Systemd Debian versions did) This has nothing to do with systemd vs. sysvinit. Maybe it is caused by changes in udev. But on my computers, I don't see udev generating any events when I plug or unplug a network cable... -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#900269: ifupdown: last version breaks upgrade
On Sun, Sep 02, 2018 at 03:34:46PM +0200, Michael Biebl wrote: > On Mon, 28 May 2018 11:08:00 +0200 Eric Valette > wrote: > > > When upgrading, you're stuck with the last message in console "setting up > > ifupdown" and nothing else. The machine dropped its ip address but > > seems to fails to acquire a new one. and stay like this for minutes. > > I'm suprised ifupdown reconfigures interfaces during package upgrades. > Guus, is that intentional? That's not intentional. It seems I forgot to add --no-start to the calls to dh_installsystemd. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#870217: glm: diff for NMU version 0.9.8.4-1.1
On Sun, Oct 22, 2017 at 03:34:53PM +0200, Tobias Frost wrote: > I've prepared an NMU for glm (versioned as 0.9.8.4-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. I was actually waiting for 0.9.8.6 or 0.9.9 to be released, but I won't mind this NMU :) -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#879518: ifupdown: fail to start with bridge_stp on and recursion detected in parent-lock with vlan after jessie upgrade
severity 879518 normal thanks On Sun, Oct 22, 2017 at 04:35:58PM +0200, Daniel wrote: > Severity: critical > Justification: breaks the whole system Downgrading to normal since this bug doesn't fit the definition of critical: “Makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.” > This setup was perfectly running on Jessie. After upgrading to Stretch, all > the network stuff was down, doesn't matter if local, VMs or Internet. > In the interfaces file below we changed the bridge-stp to off to get rid from > the "set forward delay failed: Numerical result out of range" error. > After this, interface bone was going up as well as eth0 but then we had the > parent-lock error. We commented the pre-up bone[.1|.2] on each interface who > call them > and the system started with all interfaces up. I see. Locking interfaces indeed prevents a VLAN interface from calling ifup on its parent interface. It's actually with good reason; while it may have worked on your bridge interface, it's not guaranteed to work correctly, and it will break in situations where interface are created on demand (like with tun/tap interfaces). That said, it's of course necessary for the parent interface to be up before you can bring up a VLAN interface. So I'll probably change ifupdown to do that for you. That way, you won't need pre-up ifup statements anymore. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#887664: openal-soft: FTBFS: nothing is built
Source: openal-soft Version: 1:1.18.2-1 Severity: serious Justification: Policy 4.9 Building openal-soft from source in a pbuilder environment fails. It seems like it thinks there is nothing to build: > sudo pbuilder build openal-soft_1.18.2-1.dsc [...] I: Running cd /build/openal-soft-1.18.2/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc -rfakeroot dpkg-buildpackage: info: source package openal-soft dpkg-buildpackage: info: source version 1:1.18.2-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Markus Koschany dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build openal-soft-1.18.2 fakeroot debian/rules clean dh clean --builddirectory=/build/openal-soft-1.18.2/build-tree debian/rules override_dh_auto_clean make[1]: Entering directory '/build/openal-soft-1.18.2' rm -rf /build/openal-soft-1.18.2/build-tree make[1]: Leaving directory '/build/openal-soft-1.18.2' dh_clean -O--builddirectory=/build/openal-soft-1.18.2/build-tree dpkg-source -b openal-soft-1.18.2 dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building openal-soft using existing ./openal-soft_1.18.2.orig.tar.gz dpkg-source: info: building openal-soft in openal-soft_1.18.2-1.debian.tar.xz dpkg-source: info: building openal-soft in openal-soft_1.18.2-1.dsc debian/rules build make: Nothing to be done for 'build'. fakeroot debian/rules binary dh binary --builddirectory=/build/openal-soft-1.18.2/build-tree debian/rules build make[1]: Entering directory '/build/openal-soft-1.18.2' make[1]: Nothing to be done for 'build'. make[1]: Leaving directory '/build/openal-soft-1.18.2' dh_testroot -O--builddirectory=/build/openal-soft-1.18.2/build-tree dh_prep -O--builddirectory=/build/openal-soft-1.18.2/build-tree debian/rules override_dh_auto_install make[1]: Entering directory '/build/openal-soft-1.18.2' dh_auto_install install -d debian/tmp/etc/openal [...lots of errors about missing files...] dh_install: libopenal-data missing files: usr/share/openal/hrtf dh_install: missing files, aborting debian/rules:34: recipe for target 'binary' failed make: *** [binary] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#888661: "configure: error: glm/glm.hpp not found. install glm" although libglm-dev is installed
reassign 888661 src:glm
forcemerge 888550 888661
thanks
On Sun, Jan 28, 2018 at 03:31:08PM +0100, Rene Engelhard wrote:
> >configure: WARNING: glm/glm.hpp: present but cannot be compiled
[...]
> /usr/include/glm/detail/setup.hpp:456:100: note: #pragma message: GLM: GCC
> older than 4.6 has a bug presenting the use of rgba and stpq components
> # pragma message("GLM: GCC older than 4.6 has a bug presenting the use of
> rgba and stpq components")
[...]
> Guus, any idea?
This seems to be a duplicate of 888550. So it's a bug in GLM.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: PGP signature
Bug#879458: inputlirc: diff for NMU version 23-2.1
On Tue, Feb 13, 2018 at 10:31:16PM +0100, Christoph Biedl wrote: > as I got confirmation from another side this patch fixes the issue, I've > prepared an NMU for inputlirc (versioned as 23-2.1) and uploaded it to > DELAYED/2. Please feel free to tell me if I should delay it longer. That's fine. > Additionally, I'd also like to see this fixed in an upcoming stretch > point release and might start the procedure on my own as well. Any "go" > or "no go" is appreciated. Go! -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#879458: inputlirc: diff for NMU version 23-2.1
For your information, I just updated the upstream repository to include the fix, and some other minor fixes as well (use /run instead of /var/run, check the result of daemon(), update the manual page). I already uploaded version 30-1 to unstable. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#1020619: libstdc++-arm-none-eabi-newlib: Fails to install because of incorrect versioned depency on gcc-arm-none-eabi
Package: libstdc++-arm-none-eabi-newlib Version: 15:10.3-2021.07-4+20 Severity: serious Justification: Policy 2.2.1 This package depends on gcc-arm-none-eabi (= 15:10.3-2021.07-4), however the latter version does not exist in main because there has been a binNMU, so the version present is 15:10.3-2021.07-4+b1. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libstdc++-arm-none-eabi-newlib depends on: ii gcc-arm-none-eabi15:10.3-2021.07-4+b1 ii libnewlib-arm-none-eabi 3.3.0-1.3 ii libnewlib-dev3.3.0-1.3 pn libstdc++-arm-none-eabi-dev Versions of packages libstdc++-arm-none-eabi-newlib recommends: ii binutils-arm-none-eabi 2.38.90.20220713-2+17 ii gcc-arm-none-eabi 15:10.3-2021.07-4+b1 libstdc++-arm-none-eabi-newlib suggests no packages.
Bug#558195: FTBFS: dpkg-source dies
On Thu, Nov 26, 2009 at 11:40:53PM +0100, Cyril Brulebois wrote: > your package FTBFS: [...] > | dpkg-source: info: applying spelling-error-in-binary-persistant > | 1 out of 1 hunk FAILED -- saving rejects to file > source/dat/clua/dungeon.lua.rej > | dpkg-source: error: patch -s -t -F 0 -N -p1 -u -V never -g0 -b -z > .dpkg-orig -E gave error exit status 1 > | FAILED [dpkg-source died] > > Build logs are the usual place: > https://buildd.debian.org/status/package.php?suite=unstable&p=crawl I'm a bit puzzled. I made sure the package could be built by running dpkg-source -x on the .dsc and rebuilding the package. Also, the sparc buildd seems to have built the package just fine. Do you have any idea how I could investigate this further? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#535758: gok: Doesn't do anything.
On Fri, Sep 25, 2009 at 01:29:45PM +0200, Emilio Pozuelo Monfort wrote: > I've just reproduced this with 2.26 and 2.28 while testing if the 2.28 update > was fine. The reason (pointed out by Mario Lang) was that at-spi-registryd > wasn't running (it should be if you have a11y enabled). Is it running for you > when hitting this bug? If you launch it (I did it by going to > gnome-at-properties and disabling and enabling "Enable a11y technology"), does > it work? The buttons should then work, and the keyboard itself is in compose. Ah, manually starting at-spi-registryd makes GOK work. But according to the Assistive Technologies configuration panel, it was enabled... Anyway, now that I see GOK in action I know that this is not what I expected of an "onscreen keyboard", so I guess I will not use it. But if you want me to test anything to see why it fails to run as it should, please ask. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#535758: gok: Doesn't do anything.
On Thu, Aug 13, 2009 at 12:34:50PM +0200, Josselin Mouette wrote: > > [...] None of these > > buttons seem to do anything. There is also no onscreen keyboard to be seen. > > Unless I'm missing something, I think this software is completely broken. > > I’m afraid I cannot reproduce that. If you don’t mind, I’m marking the > bug as found in testing so that gok can migrate (there have been very > few changes since 2.24 so your issue is unlikely to be triggered by the > upgrade). > > This might be caused by a missing dependency, though. Does it help if > you install libgail-gnome-module ? I will try that in a few days if I have a GNOME desktop around again. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#569448: libraw1394: FTBFS: openjade fails, tries to connect to the Internet
On Thu, Feb 11, 2010 at 08:03:34PM +0100, Lucas Nussbaum wrote: > Justification: FTBFS on amd64 > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > openjade:/build/user-libraw1394_2.0.5-1-amd64-aEFHqS/libraw1394-2.0.5/doc/libraw1394.sgml:3:61:E: > > error connecting to "www.oasis-open.org" (Connection refused) Great, openjade tries to connect to the Internet... it seems because the DOCTYPE refers to www.oasis-open.org, but this is required for DocBook XML documents. Perhaps this bug should be reassigned to docbook-utils? Are there similar problems with other packages? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#562492: zhone: Package is not installable
Package: zhone Version: 0-git20090610-5 Severity: serious Justification: Not installable Zhone depends on libevas-svn-03-engines-x which is not available anymore. Updating zhone to depend on libevas-svn-05-engines-x instead should solve this problem. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30.5 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575519: coriander: segfault
On Fri, Jul 23, 2010 at 05:18:32PM +0200, Laurent Bonnaud wrote: > > How about producing a coriander-dbg package ? > > I tried to recompile coriander myself from Debian sources to debug this > problem. The resulting binary sometimes works (allows me to capture and > display images) and sometimes segfaults. Can you provide me with a backtrace (using gdb, with the "bt full" command) when it does crash? > Therefore I tried again the official binary provided by the Debian > binary package and I observe the same behaviour: sometimes works, > sometimes segfaults. > > Somebody should run coriander with valgrind to find the cause of this > non deterministic behaviour... I did do this before I released updated packages in June, but it didn't complain much... By the way, what model Firewire camera and which Firewire card or onboard chip do you have? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#591811: crawl: FTBFS: mon-util.cc:4058: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
On Thu, Aug 05, 2010 at 07:28:21PM +0200, Philipp Kern wrote: > Source: crawl > Version: 2:0.7.1-1 > Severity: serious [...] > > mon-util.cc:4058: internal compiler error: in reload_cse_simplify_operands, > > at postreload.c:396 Why assign this bug to crawl? It's either a buggy buildd, or a bug in gcc. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#560238: tech-ctte: Default value for net.ipv6.bindv6only sysctl
reassign 560238 tech-ctte thanks Dear members of the Technical Committee, There has been an extensive discussion about the proper default value of the net.ipv6.bindv6only sysctl, both on the debian-devel mailing list and in bugreport 560238. Since people are clearly divided on the issue, and it is unlikely a compromise can be found, I have forwarded it to you for a decision. Please read the past discussion, but to summarise the arguments for both possible default values: net.ipv6.bindv6only = 0 --- * This is the default value of the Linux kernel. * This value is used as a default in many other Linux distributions. * This behaviour is the opposite of the default of the FreeBSD kernel. * Many applications work properly (ie, support both IPv4 and IPv6 simultaneously) only with this setting. * The behaviour of the network stack with this value conforms to RFC 3493 sections 3.7 and 5.3. * It is said to conform to POSIX 2008, Volume 2, Section 2.10.20. * Instead of IPv4 addresses, sockets return IPv6-mapped addresses, and not all software handles this properly (ie, and ACL for an IPv4 address gets ignored because the software only sees an IPv6 address). * This value does not introduce new bugs. * Setting this value now will keep unstable in a more usable state. net.ipv6.bindv6only = 1 --- * This restricts IPv6 addresses to IPv6 sockets, and IPv4 address to IPv4 sockets, making interpretation of addresses unambiguous, and hence increases security of programs. * This requires some applications to be adapted to support multiple sockets. * The behaviour of the network stack with this value is the same as the default behaviour of FreeBSD. * This value reduces security bugs, but introduces new bugs since some applications no longer work as expected. * This value will flush out all applications that cannot handle an alternative setting of net.ipv6.bindv6only. * Setting this value now will get more bugs fixed before the next release. In the past maintainers have pushed for new ways for doing things that upset the status quo. The idea is that introducing new functionality, although it will break some existing functionality, will result in faster convergence to a better situation. Opponents will argue that new functionality should preferrably only be introduced when it will not break exisiting functionality. I hope the Committee will issue a statement whether the former is, in general, accepted behaviour, or if Debian should be more conservative. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#575519: coriander: segfault
On Tue, Jun 22, 2010 at 10:11:23AM +0200, IOhannes m zmoelnig wrote: > i can confirm that coriander is currently unusable. > everytime i start coriander, i get a segmentation fault: [...] > this is on i386 running 2.6.32-3.686 (default debian; JuJu-stack) > other applications using libdc1394 (e.g. libdc1394-utils) don't have this > problem. On one machine I cannot reproduce this, on another I do see this problem with the JuJu stack, but it is because it doesn't see the cameras on the bus correctly, and libdc1394 returns a NULL pointer where it shouldn't, and coriander doesn't check for it. I will fix coriander, but the real problem is probably in the kernel. If possible, can you retry it with a vanilla 2.6.33 kernel with both stacks? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#575519: coriander: segfault
On Tue, Jun 22, 2010 at 02:22:28PM +0200, IOhannes m zmoelnig wrote: > > If possible, can you retry it with a vanilla 2.6.33 kernel with both stacks? > > with "vanilla" do you mean "debian" kernel (which, afaik only comes with > juju), or a self-compiled kernel with both stacks enabled? A self-compiled kernel. > for what it is worth, here is the output i get with one of the dc1394-utils: > > $ dc1394_vloopback > Using camera with GUID 814436102632378 > -- Camera information -- > Vendor: Unibrain > Model : Fire-i BCL 1.2 [...] Hm, that is different behaviour from two of my machines... It will take some more investigation before I know what the real problem is. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#575519: coriander: segfault
Hello, I have just uploaded coriander 2.0.1-1. I have included some return value checks that prevent crashes when libdc1394 cannot find any cameras or cannot allocate resources for them. I do not know if that helps with the segfaults, please let me know what your experiences are. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#832285: Symlink /usr/lib/libompitrace.so.0 pointing to wrong file
I'm writing a tool called debsyscheck that tries to find and repair problems with a debian installation. It found this problem on one of my systems: [guus@haplo]~/debsyscheck>sudo ./debsyscheck STAGE 1: gathering information about installed packages STAGE 2: checking for missing files [...] Missing file /usr/lib/libompitrace.so.0 from package libopenmpi2 Reinstalling libopenmpi2 does not fix the problem. After some digging, it looks like the package does contain this file, but it links to libompitrace.so.0.0.0, which is wrong. During the postinst phase, ldconfig notices the dangling symlink in /usr/lib and removes it. This symlink should not be in the package at all; ldconfig normally will create such symlinks automatically, and indeed it creates the correct symlink (libompitrace.so.20 -> libompitrace.so.20.0.0). -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#685232: glm: diff for NMU version 0.9.3.3+dfsg-0.1
On Thu, Aug 30, 2012 at 11:47:28PM -0400, David Prévot wrote: > I've prepared an NMU for glm (versioned as 0.9.3.3+dfsg-0.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > I'll take care of the unblock request. No problem! Thanks for fixing this. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#731834: libdc1394-22: raise priority to 'optional'
On Tue, Dec 10, 2013 at 01:46:47PM +0100, Guus Sliepen wrote:
reassign 731834 ftpmaster
thanks
Justification: section 2.5 "Packages must not depend on packages with lower
priority values (excluding build-time dependencies). In order to ensure this,
the priorities of one or more packages may need to be adjusted."
Either libdc1394-22 should be assigned priority optional, or its reverse
dependencies should be priority extra.
On Tue, Dec 10, 2013 at 11:33:52AM +0100, IOhannes m zmoelnig wrote:
> Package: libdc1394-22
> Version: 2.2.1-2
> Severity: minor
>
> Dear Maintainer,
> I noticed that this package has a priority "extra".
>
> according to debian policy, i don't see a reason to not have priority
> "optional", since the package does not have any "specialized requirements"
> such
> as mentioned in §2.5 of the Debian policy.
>
> the problem i'm experiencing is, that some packages of priority "optional"
> depend on this package, which is a direct violation of §2.5 ("Packages must
> not
> depend on packages with lower priority values").
> so either these packages or your package ought to have fixed priorities, and i
> think it that this package would be the better place :-)
>
> quoting from #debian-mentors:
>
> 10:27 < zmoelnig> i'm wondering about the "priorities" field: which priority
> should i use as default for "most" packages? "extra" or "optional"?
> [...]
> 10:30 < wRAR> zmoelnig: optional
> [...]
> 10:31 < wRAR> there is #660249
> 10:31 < wRAR> the only example in the text (debug symbols) hints (at least for
> me) that this is not really about specialized software, but about
> non-software packages.
> 10:32 < wRAR> other widely used example is transitional packages
> [...]
> 10:34 < wRAR> at this point someone usually remembers that distinctions
> between
> optional and extra do not have a real meaning and that priorities should
> be abolished.
>
>
> -- System Information:
> Debian Release: jessie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
> 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.11-2-686-pae (SMP w/4 CPU cores)
> Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages libdc1394-22 depends on:
> ii libc6 2.17-96
> ii libraw1394-11 2.1.0-1
> ii libusb-1.0-0 2:1.0.17-1+b1
> ii multiarch-support 2.17-96
>
> libdc1394-22 recommends no packages.
>
> libdc1394-22 suggests no packages.
>
> -- no debconf information
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#852292: fex: Installs weird symlink /:sexsend:sexget:
Source: fex Version: 20160328-1 Severity: serious Justification: Policy 9.1.1 Fex installs the following symlink in the root of the filesystem: lrwxrwxrwx root/root 0 2016-08-30 13:54 ./:sexsend:sexget: -> /usr/share/fex/htdocs/download/sexstream I assume this is an error. The link is created by debian/fex.links. In any case, no package should create symlinks in /. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (1001, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#852297: dnssec-trigger: Installs config files directly in the root of the filesystem
Package: dnssec-trigger Version: 0.13-3 Severity: serious Justification: Policy 9.1.1 It appears the dnssec-trigger package installs the following files directly in the root: -rw-r--r-- root/root 215 2016-12-22 12:01 ./dnssec-triggerd-keygen.service -rw-r--r-- root/root 573 2016-12-22 12:01 ./dnssec-triggerd.service -rw-r--r-- root/root 4640 2016-12-22 12:01 ./dnssec.conf This looks like a bug to me, in any case it would be a violation of the FHS. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (1001, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#841052: tinc: systemctl start tinc.service does not work, fails silently
On Mon, Oct 17, 2016 at 04:38:34AM -0400, clayton wrote: > However > > systemctl start tinc@netname.service > > DOES work. And thereafter > > systemctl restart tinc.service & > systemctl stop tinc.service > > work correctly. I can reproduce this at least on two recent stretch installs. Can you show me the output of: systemctl status tinc systemctl status tinc@netname Before and after systemctl start tinc@netname.service, and also after the subsequent systemctl restart tinc.service? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#841052: tinc: systemctl start tinc.service does not work, fails silently
On Sun, Mar 12, 2017 at 10:22:46PM +0100, Sebastian Schmachtel wrote: > after boot: > > root@oimel:/home/prisma# systemctl status tinc > ● tinc.service - Tinc VPN >Loaded: loaded (/lib/systemd/system/tinc.service; enabled; vendor [...] > root@oimel:/home/prisma# systemctl status tinc@malteser > ● tinc@malteser.service - Tinc net malteser >Loaded: loaded (/lib/systemd/system/tinc@.service; disabled; vendor It seems like you did not enable the tinc@malteser service. You can still manually start it, but starting != enabling in systemd. Only if it's enabled will it automatically start at boot. Try: systemctl enable tinc@malteser And then reboot and see if it comes up properly. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Hello Biedl & Biebl, > > retitle 857573 No longer umounts AoE/NBD-based file systems, causing data > > loss > Bug #857573 [ifupdown] systemd: Raise network interfaces fails to stop > cleanly on shutdown/reboot > Changed Bug title to 'No longer umounts AoE/NBD-based file systems, causing > data loss' from 'systemd: Raise network interfaces fails to stop cleanly on > shutdown/reboot'. > > severity 857573 grave > Bug #857573 [ifupdown] No longer umounts AoE/NBD-based file systems, causing > data loss > Severity set to 'grave' from 'important' I understand the gravity of this bug, the problem is that it's not ifupdown's fault. That it was ifupdown itself that kept a network interface up when it detected a network filesystem still being mounted was a *hack*. It's not ifupdown's job to patch over dependency issues in other packages, especially not now that we have systemd with its promise of being able to do this correctly. There are three components here: 1. ifupdown 2. AoE/NBD 3. the mounted filesystem Ideally, the filesystem mount should depend on AoE/NBD, and AoE/NBD should depend on the network being up. Looking at aoetools, if run under systemd, its service is masked, so /etc/init.d/aoetools is not called at boot or shutdown time. Under sysvinit, it would actually unmount filesystems mounted from AoE servers. Maybe this bug should be reassigned to aoetools to provide a proper systemd.service file? Another option is to explicitly add a dependency on the network for a given mount point in /etc/fstab, see the systemd.mount manpage. Basically, the following should work: /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target 0 2 With a proper aoetools.service, perhaps it should become x-systemd.requires=aoetools.service. I see nbd-client has a nbd@.service, but it requires you to write your own dev-%i.device script. I will duplicate this bug and reassign to aoetools and nbd-client. I'll also create a bug report for the kernel bug found. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#862530: aoetools: provide a systemd service to allow proper shutdown of AoE mounts
Users with filesystems mounted over AoE are surprised that these mount points are not unmounted before the network is shutdown. This can cause data loss. The documentation should be updated to tell users how to make mounts properly depend on the network (for example using filesystem options in fstab). Also, the SysV init script used to unmount these filesystems, but the aoetools package masks the systemd service. It would be better to provide a real systemd service script that restores the expected behaviour. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#862531: nbd-client: provide a systemd service to allow proper shutdown of NBD mounts
Users with filesystems mounted over NBD are surprised that these mount points are not unmounted before the network is shutdown. This can cause data loss. The documentation should be updated to tell users how to make mounts properly depend on the network (for example using filesystem options in fstab). I see there is currently a nbd@.service that replaces the SysV init script. However, it does not declare a dependency on network-online.target. There is a Before=dev-%i.device. I assume that should provide the necessary dependencies? However, I don't see a generator being created for such .device files, and no documentation in the package anywhere how to make those. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
On Sun, May 14, 2017 at 12:49:12PM +0200, Christoph Biedl wrote: > > Maybe this bug should be reassigned to aoetools to provide a > > proper systemd.service file? > > Wearing the aoetools maintainer's hat, I'll be happy to provide that but > will need help on it. Ok. I'll try to create one and send it to you. > > Another option is to explicitly add a dependency on the network for a > > given mount point in /etc/fstab, see the systemd.mount manpage. > > Basically, the following should work: > > > > /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target > > 0 2 > > How about block devices that were mounted manually i.e. are not listed > in /etc/fstag? I doubt they will handled in a sane way during shutdown. Then I would say it's the responsibility of the user to unmount it manually at the appropriate time. If aoetools can detect such mounts and unmount them at shutdown, that would be nice. But only if it's very easy to do. Having ifupdown keep network interfaces alive is not guaranteed to help either. What if you mount an NBD or AoE device via VPN? At some point the VPN daemon will be killed. Is that before or after the kernel unmounts things? > > With a proper aoetools.service, perhaps it should become > > x-systemd.requires=aoetools.service. I see nbd-client has a > > nbd@.service, but it requires you to write your own dev-%i.device > > script. I will duplicate this bug and reassign to aoetools and > > nbd-client. I'll also create a bug report for the kernel bug found. > > My gut feeling warns me about a dependency loop in case of more complex > mount setups like local block device mounted somewhere inside a mounted > AoE block device. A check of that situation will be part of the tests. Well, if all dependencies were correct when booting, then systemd should shut down everything in reverse order, right? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#860701: glm: FTBFS on i386: E: Build killed with signal TERM after 150 minutes of inactivity
On Wed, Apr 19, 2017 at 09:15:57AM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in stretch (in a stretch chroot, not a > sid chroot), your package failed to build on i386. [...] > > Start 24: test-core_func_exponential > > E: Build killed with signal TERM after 150 minutes of inactivity Found the cause; a case of i386 FPU having more precision in its floating point registers than IEEE floats have, and GLM using == comparisons between floats. Will upload a fix soon. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#832062: supertuxkart: source for GPL song Boom_boom_boom.ogg missing
Source: supertuxkart Version: 0.9.2-1 Severity: serious Justification: does not include source code of GPL licensed work Supertuxkart contains a song called "Boom boom boom" in Ogg Vorbis format. According to the credits and debian/copyright, this song is created by Matt Thomas, and is licensed under the GNU GPL v3 or later. The source of the .ogg file is missing. Although what consists the source of media assets can be unclear, I would like to point out that there is also a module tracker version of this song, which can reasonably considered the source, as it contains the score, the samples used and can be editted in any module editor: https://modarchive.org/index.php?request=view_by_moduleid&query=38184 This module contains the following text: > -kbx128- march 1993 > music for a crap amos > game written by my > brother.(only joking) There is also some doubt that Matt Thomas and kbx128 are the same person: http://forum.freegamedev.net/viewtopic.php?t=6562&p=66000 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#832116: edgar: Source missing for some GPL licensed assets
Source: edgar Severity: serious Justification: source missing for GPL licensed assets According to debian/copyright, the edgar-data package contains a number of songs which are licensed under the GPL-3+. However, only the final rendered music is present in the form of a .ogg file. > Files: > music/Battle?in?the?winter.ogg > music/Devilish?design.ogg > music/A?wintertale_0.ogg > music/Medicine.ogg > Copyright: Copyright (c) Johan Brodd > Comment: http://opengameart.org/users/jobromedia > License: GPL-3+ Upon checking OpenGameArt, I found out that "Battle in the winter" and "A winter tale" are dual-licensed, and available under the CC-BY 3.0 and CC-BY-SA 3.0 licenses respectively, so it should be a simple matter of updating the copyright notice here. However, "Devilish design" is only available under GPL 3.0. As such, I believe that unless the source can be found or Johan Brodd can be contacted and asked if the license could be changed, this song should be removed from the source package. Also, Medicine.ogg is, according to OpenGameArt.org, created by Alexander Zhelanov, and is licensed only under CC-BY 3.0. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#807645: ifupdown package fails to configure itself (by dpkg)
On Sat, Dec 26, 2015 at 02:14:31PM +0100, Marco d'Itri wrote:
> > Try using -ff instead of -f. If it's not obvious what the problem is
> > from the strace logs, could you send them to me in any case?
> I see the same problem on my system.
>
> A dbus call fails:
>
> sendmsg(3, {msg_name(0)=NULL,
> msg_iov(2)=[{"l\1\4\1$\0\0\0\1\0\0\0\242\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\3\1s\0\17\0\0\0EnableUnitFiles\0\2\1s\0
>
> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\4asbb\0\0\0\0\0\0\0",
> 184}, {"\27\0\0\0\22\0\0\0networking.service\0\0\0\0\0\0\0\0\0\0", 36}],
> msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 220
> recvmsg(3, 0xff8a5c84, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
> EAGAIN (Resource temporarily unavailable)
> ppoll([{fd=3, events=POLLIN}], 1, {24, 76000}, NULL, 8) = 1 ([{fd=3,
> revents=POLLIN}], left {24, 999763325})
> recvmsg(3, {msg_name(0)=NULL,
> msg_iov(1)=[{"l\3\1\1\20\0\0\0\1\0\0\0?\0\0\0\5\1u\0\1\0\0\0", 24}],
> msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
> recvmsg(3, {msg_name(0)=NULL,
> msg_iov(1)=[{"\4\1s\0%\0\0\0org.freedesktop.DBus.Error.FileExists\0\0\0\10\1g\0\1s\0\0\v\0\0\0File
> exists\0", 72}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 72
> writev(2, [{"Failed to execute operation: File exists", 40}, {"\n", 1}], 2) =
> 41
Hm, that sounds like a bug in systemd or in some other component that it
calls during "systemctl enable networking.service". Marco, can you see
from your strace logs what process did that dbus call?
The current version of ifupdown calls systemctl from postinst "by hand",
but the next version will use dh-systemd, maybe that will fix this issue
as well, but I'm not sure.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#809658: ifupdown: Upgrade 0.8.5 Removes 48 Unrelated Packages e.g. linux-image, xorg, udev (Sid Unstable)
found 809658 0.8.5 notfound 809658 0.8.4 severity 809658 normal thanks On Sat, Jan 02, 2016 at 08:25:56AM -0500, Cindy Sue Causey wrote: > Hi.. First, thank you all for the work you do! > > Next: I ran my usual "apt-get update" today. Found ifupdown needing upgraded > in Sid Unstable along with ~20+ other packages. When the upgrade process > began, I received an apt-get advisement that 48 packages were going to be > removed. > > Being familiar with this occurrence at this point, I manually installed > packages one by one and determined ifupdown to be the package performing the > removals. The following (extensive) output is what I receive when attempting > to install ifupdown by itself: Some files are being moved from the systemd and udev packages to the ifupdown package. As part of that, the ifupdown package declares that it breaks with older versions of systemd and udev. Normally that should cause apt to defer updating ifupdown until systemd and udev packages are available with the right version, but in this case it thinks it can also solve the dependencies by kicking out udev and systemd and installing sysvinit. There is nothing wrong with ifupdown itself, neither with apt or anything else. This is normal and will be resolved once new versions of systemd and udev are uploaded. This is also in no way critical, since nothing is actually broken on your system. I'll keep the bug open in any case until the the transition is complete. > My latest practice under these circumstances is to set the affecting package > to the side and wait for developers' newer release of the same. That's the correct practice :) You are running the unstable distribution, so unfortunately this kind of issue will pop up once in a while, but it is normal. If you want to avoid this problem, run can run testing instead. > Thank you again for all your work! You're welcome :) -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#807645: ifupdown package fails to configure itself (by dpkg)
On Sat, Dec 26, 2015 at 03:27:48PM +0100, Marco d'Itri wrote: > > Hm, that sounds like a bug in systemd or in some other component that it > > calls during "systemctl enable networking.service". Marco, can you see > > from your strace logs what process did that dbus call? > Just "systemctl enable networking.service". > > > The current version of ifupdown calls systemctl from postinst "by hand", > > but the next version will use dh-systemd, maybe that will fix this issue > > as well, but I'm not sure. > The problem is that networking.service is already enabled (by insserv), > but I expected the command to be idempotent anyway: Hm, it is idempotent on my machines, and I can't reproduce the issue you're having, whatever state I put networking.service in before upgrading the package. Can you check whether 0.8.4 works better? That one uses dh-systemd. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#809743: /var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'
severity 809743 normal forcemerge 809658 809743 thanks On Sun, Jan 03, 2016 at 11:52:49PM +0800, 積丹尼 Dan Jacobson wrote: > Unpacking libpam-systemd:i386 (228-3) over (228-2+b1) ... > dpkg: considering deconfiguration of ifupdown, which would be broken by > installation of systemd ... > dpkg: yes, will deconfigure ifupdown (broken by systemd) I'm assuming you are forcing the installation of packages somehow? Because apt-get would normally warn that installing the new systemd and udev packages would conflict with ifupdown. There is a small transition going on where some files are moved from the systemd and udev packages into the ifupdown package. In a few days, all mirrors should have the new versions of all three packages which can be coinstalled. Until then, just wait and don't force apt-get to install packages that it knows won't work together. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#809744: Bug#809743: /var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'
On Mon, Jan 04, 2016 at 08:58:57AM +0100, Martin Pitt wrote: > > But maybe it really is (also) a problem with udev's prerm script. > > It is indeed. It got fixed in 228-3, but we can't retroactively fix > the old one. Hm, I thought dpkg would try the prerm script from the new package if the one from the old one failed? > Michael's idea was to drop the Breaks: from ifupdown and > only keep the Replaces:, which will avoid deconfiguring udev and thus > avoid running into this old prerm bug. Upgrades will be fine with > that, it will just not work correctly with partial downgrades. But we > don't support these anyway. > > Unfortunately I don't have a better idea either. Guus, would you be > okay with dropping the Breaks: to udev again? If that's the only solution, sure. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#810666: install of version 0.8.6 remove systemd
severity 810666 normal thanks On Mon, Jan 11, 2016 at 07:12:28AM +0100, Jörg Frings-Fürst wrote: > Package: ifupdown > Version: 0.7.54 > Severity: critical > > ~# apt-get dist-upgrade > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > Paketaktualisierung (Upgrade) wird berechnet... Fertig > Die folgenden Pakete sind zurückgehalten worden: > ifupdown > 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert. dist-upgrade detects that there is a transition going on and that upgrading ifupdown now would cause other packages to be removed, that is why it keeps it back. > ~# apt-get install ifupdown Now you are telling apt-get to explicitly upgrade the ifupdown package: > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > The following additional packages will be installed: > sysvinit-core > Vorgeschlagene Pakete: > ppp rdnssd > Die folgenden Pakete werden ENTFERNT: > systemd systemd-sysv > Die folgenden NEUEN Pakete werden installiert: > sysvinit-core And it tells you here what will happen if you continue. > Die folgenden Pakete werden aktualisiert (Upgrade): > ifupdown > 1 aktualisiert, 1 neu installiert, 2 zu entfernen und 0 nicht aktualisiert. > Es müssen 204 kB an Archiven heruntergeladen werden. > Nach dieser Operation werden 17,9 MB Plattenplatz freigegeben. > Möchten Sie fortfahren? [J/n] n It asks you if you really want to do this or not. Note that your system would still be perfectly working when it installs sysvinit. So nothing is broken by the ifupdown package, therefore I'm reducing the severity. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#810785: ifupdown breaks debootstrap of Debian
severity 810785 serious thanks On Tue, Jan 12, 2016 at 10:23:49AM +0100, Raphaël Hertzog wrote: > Severity: critical > Justification: breaks the whole system While it is very annoying, it doesn't *break* the whole system. Also, it is only a problem when debootstrapping testing, so it still works fine in a lot of other situations. But the problem is in any case not in the ifupdown package itself; ifupdown has correct Breaks: headers. The package was moved to testing because it actually is installable (although on a normal testing system, trying to upgrade ifupdown to the latest version will cause sysvinit to be installed and systemd removed). So I rather believe the problem is that debootstrap doesn't handle the situation correctly: > debootstrap.log contains this: > > dpkg: regarding .../ifupdown_0.8.6_amd64.deb containing ifupdown: > ifupdown breaks systemd (<< 228-3~) > systemd (version 228-2+b1) is present and triggered. > > dpkg: error processing archive > /var/cache/apt/archives/ifupdown_0.8.6_amd64.deb (--unpack): > installing ifupdown would break systemd, and > deconfiguration is not permitted (--auto-deconfigure might help) Maybe debootstrap should ensure dpkg is called with --auto-deconfigure? > The problem is that stretch still has systemd 228-2 and 228-4 is unlikely > to migrate quickly since it just got updated and seems to have a new RC bug. > > I'm not sure what's the best way forward... possibly upload something to > testing-proposed-updates to drop that breaks temporarily until the package > migrates (and ensure 0.8.7 does not migrate before systemd). > > Or force migrate the new systemd despite the age and the bug... I would rather see two things happening: 1) that debootstrap handles this situation better, and 2) that packages that have Breaks: foo (<< x.y.z) are delayed migrating to testing until foo version x.y.z or later is also ready to migrate to testing. But I'll see if it's possible to remove the Breaks: without really breaking the system. > Ccing release team and systemd maintainers to have their opinion. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#810785: ifupdown breaks debootstrap of Debian
On Tue, Jan 12, 2016 at 11:24:00AM +0100, Julian Andres Klode wrote: > > > dpkg: error processing archive > > > /var/cache/apt/archives/ifupdown_0.8.6_amd64.deb (--unpack): > > > installing ifupdown would break systemd, and > > > deconfiguration is not permitted (--auto-deconfigure might help) > > > > Maybe debootstrap should ensure dpkg is called with --auto-deconfigure? > > So, you want an unconfigured init system or other unconfigured packages in > the base system? Really? > > That does not make any sense at all. No; what happens is that apt knows that it can upgrade two packages at the same time, where one of them Breaks: the old version of the other package. But dpkg processes packages individually, and when the old version of the other package is still installed, and dpkg tries to upgrade the first package, it notices the Breaks. It can temporarily deconfigure the other package, continue upgrading the first, then upgrading the other package and (re)configuring it. This is actually what happens when you are just doing an apt-get dist-upgrade on a testing system. The problem with debootstrap is that this --auto-deconfigure option is somehow not passed to dpkg. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#810785: ifupdown breaks debootstrap of Debian
On Tue, Jan 12, 2016 at 03:13:23PM +0100, Julian Andres Klode wrote: > We are talking about bootstrapping, not upgrading. Automatic > deconfiguration of packages is entirely irrelevant here. > > Please think first. Ok, fine, but then debootstrap shouldn't even have TRIED to install both ifupdown and systemd, because ifupdown >= 0.8.4 and systemd << 228-3~ are EXPLICITLY not coinstallable. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#816584: libraw1394: FTBFS: ! LaTeX Error: File `ulem.sty' not found.
reassign 816584 texlive-htmlxml thanks On Thu, Mar 03, 2016 at 08:34:53AM +, Chris Lamb wrote: > libraw1394 fails to build from source in unstable/amd64: > > [...] > > make[2]: Entering directory > '/home/lamby/temp/cdt.20160303080517.0tVkw1XhhH/libraw1394-2.1.1/doc' > db2pdf libraw1394.sgml > > [...] > > mktexfmt [INFO]: --- remaking pdfjadetex with pdftex mktexfmt: > running `pdftex -ini -jobname=pdfjadetex -progname=pdfjadetex > *pdfjadetex.ini' ... > > [...] > > ! LaTeX Error: File `ulem.sty' not found. I believe the error is in the texlive-htmlxml package; if it depends on ulem.sty, it should depend on texlive-generic-recommended. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#807645: ifupdown package fails to configure itself (by dpkg)
On Fri, Dec 11, 2015 at 10:16:18AM +0100, Vincent Danjean wrote: > Executing /lib/systemd/systemd-sysv-install enable networking > done 0 > Failed to execute operation: File exists > dpkg: error processing package ifupdown (--configure): > subprocess installed post-installation script returned error exit status 1 Hm, that's weird... > Using "strace -f -o /tmp/strace.out2 systemctl enable networking.service" did > not help me to find which file is already existing. Try using -ff instead of -f. If it's not obvious what the problem is from the strace logs, could you send them to me in any case? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#807617: FTBFS due to test-suite failures
On Thu, Dec 10, 2015 at 11:41:06PM +0100, Michael Biebl wrote: > Since version 0.8, the test-suite basically fails on all architectures > as can be seen at > https://buildd.debian.org/status/package.php?p=ifupdown&suite=unstable > > I can reproduce the problem on amd64 with a pbuilder build. > >From a cursory glance it looks like the test suite needs files from the > installed package (i.e. it looks for /lib/ifupdown/settle-dad.sh). > > Shouldn't it use ./settle-dad.sh instead when running the test-suite? It actually doesn't call settle-dad.sh at all. The problem is that the testsuite is running ifup with the --no-act option, and compares the output of it to the expected output as written in debian/testbuild-linux. Ifup only calls /lib/ifupdown/settle-dad.sh if it exists and is executable, but that of course depends on the build environment. The expected output was written with the assumption that /lib/ifupdown/settle-dad.sh is already there. So I'll have to fix that. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 11:09:09AM +0100, Matthias Klose wrote: > when building on i386: > > cd /build/buildd/glm-0.9.5.0/obj-i686-linux-gnu/test/gtx && /usr/bin/c++ > -D_CRT_SECURE_NO_WARNINGS -O2 -g -DNDEBUG -I/build/buildd/glm-0.9.5.0/. > -I/build/buildd/glm-0.9.5.0/./test/external-pedantic -o > CMakeFiles/test-gtx_associated_min_max.dir/gtx_associated_min_max.cpp.o -c > /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp > In file included from > /build/buildd/glm-0.9.5.0/test/gtx/gtx_associated_min_max.cpp:10:0: > /usr/lib/gcc/i686-linux-gnu/4.8/include/emmintrin.h:31:3: error: #error "SSE2 > instruction set not enabled" > # error "SSE2 instruction set not enabled" >^ > > This is not just for the glm build, but every package build-depending on this > will ftbfs on i386. I don't think reverse depends will FTBFS. The problem is that the tests (which are only run at build time and are not in any way included in the binary packages) unconditionally #include . Could you try removing those #includes from glm-0.9.5.0/test/gtx/*.cpp, and try building again? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 11:36:08AM +0100, Matthias Klose wrote: > > I don't think reverse depends will FTBFS. The problem is that the tests > > (which are only run at build time and are not in any way included in the > > binary packages) unconditionally #include . Could you try > > removing those #includes from glm-0.9.5.0/test/gtx/*.cpp, and try building > > again? > > I don't think this would be the correct fix, because the include machinery > provides several FORCE macros to support those targets as well. The #include does not #define any macro that changes the behaviour in GLM. In fact, GLM itself checks for the presence of __SSE2__ and automatically #includes if possible. Also, GLM version 0.9.4.6 did not #include in its tests, and only a few tests have the #include, I think it is just an oversight from the upstream maintainer. > Please check with a i386 chroot. An i386 chroot won't do me any good as I only have processors that support SSE2. It would be helpful if you could test the patch which I attached to this email on your i386 system. -- Met vriendelijke groet / with kind regards, Guus Sliepen --- a/test/gtx/gtx_associated_min_max.cpp +++ b/test/gtx/gtx_associated_min_max.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_bit.cpp +++ b/test/gtx/gtx_bit.cpp @@ -7,8 +7,6 @@ // File: test/gtx/bit.cpp /// -#include - #include #include --- a/test/gtx/gtx_closest_point.cpp +++ b/test/gtx/gtx_closest_point.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_color_space.cpp +++ b/test/gtx/gtx_color_space.cpp @@ -7,8 +7,6 @@ // File: test/gtx/color_space.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_color_space_YCoCg.cpp +++ b/test/gtx/gtx_color_space_YCoCg.cpp @@ -7,8 +7,6 @@ // File: test/gtx/color_space_YCoCg.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_component_wise.cpp +++ b/test/gtx/gtx_component_wise.cpp @@ -7,8 +7,6 @@ // File: test/gtx/component_wise.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_extented_min_max.cpp +++ b/test/gtx/gtx_extented_min_max.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_int_10_10_10_2.cpp +++ b/test/gtx/gtx_int_10_10_10_2.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include - #include #include #include --- a/test/gtx/gtx_mixed_product.cpp +++ b/test/gtx/gtx_mixed_product.cpp @@ -7,8 +7,6 @@ // File: test/gtx/associated_min_max.cpp /// -#include - #include #include #include signature.asc Description: Digital signature
Bug#735270: package build with SSE2 defaults on i386
On Tue, Jan 14, 2014 at 01:01:25PM +0100, Matthias Klose wrote: > > An i386 chroot won't do me any good as I only have processors that support > > SSE2. It would be helpful if you could test the patch which I attached to > > this email on your i386 system. > > this is a misunderstanding. The compiler doesn't define these on macros by > itself. it defaults to i586. So yes, a test in an i386 chroot does help. Ugh, I should have known that. I'll test it. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#735270: Tests fail to build on machines without SSE2 instructions
tags 735270 + fixed-upstream tags 735270 + pending thanks The problem has been fixed by upstream, it will be part of the upcoming release of 0.9.5.2. I already tested it in an i386 chroot :) -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#615019: blobwars-data: Song by Ambick isn't his to license
On Sat, Feb 26, 2011 at 10:59:28AM +0100, Guus Sliepen wrote: > > The song Ambick - Herbs (/usr/share/games/blobwars/music/end) isn't > > his so he can not give us permission to include it. It's Lizardking's > > Claustrophobia, which you can verify at > > http://modarchive.org/index.php?request=view_by_moduleid&query=34669 > > That certainly sounds very identical. I'll contact both Ambick and LizardKing > and ask them about this issue, and if necessary remove this song. Ambick confirms he has used Claustrophobia, and without intending any harm, mistakenly published it under his own name (possibly with some minor modifications). I am waiting for response from LizardKing whether we are still allowed to use this song in a DFSG compliant way, with correct attribution of course. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#615019: blobwars-data: Song by Ambick isn't his to license
tags 615019 + pending thanks On Sat, Feb 26, 2011 at 02:49:21PM +0100, Guus Sliepen wrote: > > > The song Ambick - Herbs (/usr/share/games/blobwars/music/end) isn't > > > his so he can not give us permission to include it. It's Lizardking's > > > Claustrophobia, which you can verify at > > > http://modarchive.org/index.php?request=view_by_moduleid&query=34669 > > > > That certainly sounds very identical. I'll contact both Ambick and > > LizardKing > > and ask them about this issue, and if necessary remove this song. > > Ambick confirms he has used Claustrophobia, and without intending any harm, > mistakenly published it under his own name (possibly with some minor > modifications). I am waiting for response from LizardKing whether we are still > allowed to use this song in a DFSG compliant way, with correct attribution of > course. After contacting him, LizardKing has allowed his song Claustrophobia to be used under the CC-BY-SA 3.0 license, which in turn allows Ambick to redistribute his version, we now just have to fix the attribution. When that is done the bug will be closed. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#604263: Preparations for the removal of the KDE3 and Qt3 libraries
On Sat, Mar 12, 2011 at 08:19:18PM +0100, Ana Guerrero wrote: > In the case of celestia, it provides a KDE 3 frontend that could be dropped. > We are trying to remove kdelibs3 soon from the archive, could you look at > this > soon please? AFAIK someone in the Celestia development team is working on providing a KDE4 front-end. However, that may take a while. So I will indeed remove the celestia-kde package. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#604263: Improved changelog for NMU.
On Wed, Mar 30, 2011 at 09:19:26AM +0200, Ana Guerrero wrote: > On Tue, Mar 29, 2011 at 10:04:41AM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi! I am attaching a patch with an improved changelog, making it more > > suitable > > for an NMU. > > I have sponsored Lisandro's NMU to delayed-7. Feel free to cancel the NMU and > make a upload maintainer fixing this bug. I'll see if I have time this week, otherwise I'll let the NMU go through. Anyway, thanks for the work, Lisandro! -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#632633: Alternate loop breaker.
On Tue, Aug 02, 2011 at 07:07:21PM +0200, Luk Claes wrote:
> Including full quote as submitter was not Cc-ed.
Thanks. I hate that part about the BTS.
> > Is there some particular reason why the simple
> > while loop tests
> >
> > while (count-- > 0) {
[...]
> width and cound are both unsigned, so it's not so much an issue that
> they become negative, but rather way too large.
Indeed. I would feel safer with for (i = 0; i < count; i++) here. But see
below.
> > Would
> > width = abs(misc_screen_width());
> > and
> > count = abs(width * gauge->value / 100);
> > improve robustness?
I decided not to fix the progress bar but to lobotomize it because it doesn't
have ANY added value, and who knows what other corner case is lurking in that
code. The rotating line combined with a numeric percentage are enough to
indicate progress, and don't need any loops or tricky arithmetic, and even if
the arithmetic is wrong it will only mess up the display a bit, not the whole
fsck.
> PS2: Should this bug not be tagged lfs?
No, this has nothing to do with large file support.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#632632: libaal-dev: Casts 64 bit integers to "int", breaking operations on filesystems with large bitmaps
Package: libaal-dev
Version: 1.0.5-5
Severity: critical
Justification: causes serious data loss
In bitops.c, several functions get offsets and sizes with type bit_t, which is
64 bit, but local variables which hold the result of calculations on those
bit_t variables are of type int, which of causes incorrect results for
filesystems with block bitmaps that are larger than 2 GiB. I'm marking this
critical as this causes fsck.reiserfs to work incorrectly on such filesystems,
potentially breaking it beyond repair.
I have attached a patch, but please have a good look at it to see if I did not
miss anything.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libaal-dev depends on:
ii libc6-dev [libc-dev] 2.13-8 Embedded GNU C Library: Developmen
libaal-dev recommends no packages.
libaal-dev suggests no packages.
-- no debconf information
--- libaal-1.0.5.orig/src/bitops.c
+++ libaal-1.0.5/src/bitops.c
@@ -80,7 +80,7 @@
bit_t size,
bit_t offset)
{
- int bit = offset & 7, res;
+ bit_t bit = offset & 7, res;
unsigned char *addr = map;
unsigned char *p = addr + (offset >> 3);
@@ -100,7 +100,7 @@
/* Finds zero bit in @byte starting from @offset */
static inline int aal_find_nzb(unsigned char byte, bit_t offset) {
-int i = offset;
+bit_t i = offset;
unsigned char mask = 1 << offset;
while ((byte & mask) != 0) {
@@ -119,9 +119,9 @@
bit_t offset)
{
unsigned char *addr = map;
-unsigned int byte_nr = offset >> 3;
-unsigned int bit_nr = offset & 0x7;
-unsigned int max_byte_nr = (size - 1) >> 3;
+bit_t byte_nr = offset >> 3;
+bit_t bit_nr = offset & 0x7;
+bit_t max_byte_nr = (size - 1) >> 3;
if (bit_nr != 0) {
unsigned int b = ~(unsigned int)addr[byte_nr];
@@ -152,8 +152,8 @@
bit_t start,
bit_t count)
{
- int end_byte;
- int start_byte;
+ bit_t end_byte;
+ bit_t start_byte;
char *addr = map;
bit_t left, right;
@@ -185,8 +185,8 @@
bit_t start,
bit_t count)
{
- int end_byte;
- int start_byte;
+ bit_t end_byte;
+ bit_t start_byte;
char *addr = map;
bit_t left, right;
Bug#632633: reiser4progs: Casts 64 bit integers to 32 bit, infinite loop in progress bar code
Package: reiser4progs
Version: 1.0.7-6
Severity: critical
Justification: causes serious data loss
I found two bugs in fsck.reiserfs, that affect filesystems larger than 16 TiB.
First is an explicit cast of a 64 bit block counter to 32 bit, which causes it
to not work correctly on such large filesystems, the second is that the code
that prints the progress bar can go into an infinite loop (which was triggered
by the bug I reported earlier against libaal-dev), because it
uses "while(width--) {...}", but width can start out to be negative. I've
marked this bug critical as the first bug could cause an incorrect repair of
the filesystem, and the second will prevent fsck.reiserfs from running at all.
I have attached a patch which fixes the first issue, and removes the progress
bar completely.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages reiser4progs depends on:
ii libc6 2.13-8 Embedded GNU C Library: Shared lib
ii libncurses5 5.9-1 shared libraries for terminal hand
ii libreadline6 6.2-2 GNU readline and history libraries
ii libuuid1 2.19.1-2 Universally Unique ID library
reiser4progs recommends no packages.
reiser4progs suggests no packages.
-- no debconf information
--- reiser4progs-1.0.7.orig/libmisc/gauge.c
+++ reiser4progs-1.0.7/libmisc/gauge.c
@@ -95,31 +95,8 @@
gauge->value_func(gauge);
if (gauge->value != -1) {
- uint32_t width, count;
-
- width = misc_screen_width();
- if (width < 10)
- goto done;
-
- width -= 10;
-
- if (width > 50)
- width = 50;
-
- fprintf(stderr, "[");
- count = width * gauge->value / 100;
- width -= count;
- while (count--) {
- fprintf(stderr, "=");
- }
-
misc_gauge_blit();
-
- while(width--) {
- fprintf(stderr, " ");
- }
-
- fprintf(stderr, "] %lld%%", gauge->value);
+ fprintf(stderr, " %lld%%", gauge->value);
} else {
misc_gauge_blit();
}
--- reiser4progs-1.0.7.orig/librepair/repair.c
+++ reiser4progs-1.0.7/librepair/repair.c
@@ -210,7 +210,8 @@
is a node). */
static errno_t cb_region_mark(blk_t blk, uint64_t count, void *data) {
repair_control_t *control = (repair_control_t *)data;
- uint32_t i;
+ //uint32_t i; // BUG! block number is 64 bit.
+ blk_t i;
aal_assert("vpf-561", control != NULL);
Bug#318719: [tecnoballz #318719] Bug still open?
reopen 318719 ! thanks 0.91cvs20060501-1 still segfaults on startup on amd64. ltrace shows it segfaults when calling SDL_FreeSurface(). -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#373166: tecnoballz: fails to install
Package: tecnoballz Version: 0.91cvs20060612-1 Severity: grave Justification: renders package unusable I tried to install tecnoballz on a computer where it was not installed before, and I got this result: Get:1 http://ftp.nl.debian.org unstable/main tecnoballz-data 0.91cvs20060612-1 [1527kB] Get:2 http://ftp.nl.debian.org unstable/main tecnoballz 0.91cvs20060612-1 [159kB] Fetched 1686kB in 2s (809kB/s) Selecting previously deselected package tecnoballz-data. (Reading database ... 183011 files and directories currently installed.) Unpacking tecnoballz-data (from .../tecnoballz-data_0.91cvs20060612-1_all.deb) ... Selecting previously deselected package tecnoballz. Unpacking tecnoballz (from .../tecnoballz_0.91cvs20060612-1_amd64.deb) ... preinst called with unknown argument `install' dpkg: error processing /var/cache/apt/archives/tecnoballz_0.91cvs20060612-1_amd64.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/tecnoballz_0.91cvs20060612-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc4 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318719: It still segfaults on amd64.
reopen 318719 found 318719 0.91cvs20060612-1 thanks On a machine were tecnoballz was previously installed, and where installation of the new package didn't fail: [EMAIL PROTECTED]>dpkg -l tecnoballz Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii tecnoballz 0.91cvs20060612-1 breaking block game ported from the Amiga platform [EMAIL PROTECTED]>tecnoballz --version LP64 configfile::fopen_data(): Warning: Unable to open the file "/home/users/guus/.tlkgames/tecnoballz.conf" for read!!! TECNOBALLZ 0.91+ (2005-08-26) copyright (c) 1991-2005 TLK Games website: http://linux.tlk.fr [EMAIL PROTECTED]>tecnoballz LP64 configfile::fopen_data(): Warning: Unable to open the file "/home/users/guus/.tlkgames/tecnoballz.conf" for read!!! [1]29049 segmentation fault tecnoballz -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#318719: Works on some amd64 machines
Hello, After being able to install tecnoballz (thanks to #373166 being fixed), I noticed that on one AMD64 machine, it does run, but on another one it still segfaults. The difference could be the graphics card (it works on the machine with an ATI card but fails on one with an nVidia card), or maybe some other hardware, but both are running a fairly identical Debian unstable. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#373733: balazar: segfaults when starting a game
Package: balazar Version: 0.3.1.ds1-2 Severity: grave Justification: renders package unusable Tofy starts up, but when I click on "Play Solo game" and then "Start", it crashes: [EMAIL PROTECTED]>balazar * Balazar * Balazar lives in /usr/share/games * Balazar * PyOpenAL not installed, trying PySDL_mixer... * Balazar * Warning! Neither PyOpenAL nor PySDL_mixer are installed; * music and sound are disabled! * Balazar * (Psyco not found ; if you are using an x86 processor, * installing psyco can speed up Balazar a little) * Soya * Using 8 bits stencil buffer * Soya * version 0.10.5 * Using OpenGL 2.0.5814 (8.25.18) * - renderer : MOBILITY RADEON X700 Generic * - vendor : ATI Technologies Inc. * - maximum number of lights: 8 * - maximum number of clip planes : 6 * - maximum number of texture units : 8 * - maximum texture size: 2048 pixels * Tofu * Creating new player guus... * Balazar * Creating level 0, 0... * Tofu * Level level_0_0 7430576 activated ! * Tofu * Player guus login ! [1]5270 segmentation fault balazar -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc4 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages balazar depends on: ii python-cerealizer 0.4-1 secure pickle-like module for Pyth ii python-pyvorbis 1.3-1 A Python interface to the Ogg Vorb ii python-tofu 0.5-1 high-level network game engine for ii python2.4 2.4.3-5An interactive high-level object-o ii python2.4-openal 0.1.6-1port for Python of the OpenAL libr ii python2.4-soya0.10.5-2 high level 3D engine for Python balazar recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358598: matrem: FTBFS: Xcursor library not found
reassign 358598 liballegro4.2-dev thanks On Thu, Mar 23, 2006 at 01:44:25PM +0100, [EMAIL PROTECTED] wrote: > Package: matrem > Version: 1.0-9 > Severity: serious > > Hi, > > building the package matrem in a clean sid build environment > (with pbuilder) on i386 results in: [...] > g++ -o matrem matrem10.o graphics.o creature.o config.o milkacow.o lion.o > jerremiah.o fish.o yourcreature.o -lm `allegro-config --libs` > /usr/bin/ld: cannot find -lXcursor > collect2: ld returned 1 exit status > make[1]: *** [matrem] Error 1 > make[1]: Leaving directory `/tmp/buildd/matrem-1.0' > make: *** [build-stamp] Error 2 > = Since matrem does not directly use the X11 libraries, but only functionality provided by Allegro, I am reassigning this to liballegro4.2-dev, which should probably include a build-dependency on libcursor-dev. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#374886: gimp-dimage-color: Uninstallable with latest gimp package
Package: gimp-dimage-color Version: 1.1.0-2 Severity: grave Justification: renders package unusable The latest version of the gimp package does not Provides: gimp2.0 any more. This makes gimp-dimage-color uninstallable, because it depends on gimp2.0. I suggest you replace it by a versioned dependency, for example gimp (>= 2.0). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc4 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages gimp-dimage-color depends on: ii gimp [gimp2.0] 2.2.11-1The GNU Image Manipulation Program ii libatk1.0-0 1.11.4-2The ATK accessibility toolkit ii libc62.3.6-15GNU C Library: Shared libraries ii libcairo21.0.4-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-7 generic font configuration library ii libgimp2.0 2.2.11-3Libraries necessary to Run the GIM ii libglib2.0-0 2.10.3-1The GLib library of C routines ii libgtk2.0-0 2.8.18-1The GTK+ graphical user interface ii libpango1.0-01.12.3-1Layout and rendering of internatio ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor1 1.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra gimp-dimage-color recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373733: balazar: segfaults when starting a game
On Wed, Jun 28, 2006 at 01:46:33AM +0200, Marc Dequènes wrote: > > Package: balazar > > Version: 0.3.1.ds1-2 > > Severity: grave > > Justification: renders package unusable > > Grave is: > makes the package in question unusable or mostly so, or causes data > loss, or introduces a security hole allowing access to the accounts of > users who use the package. > > Which is obviously wrong. > > Currently only amd64 architecture is impacted. This is a known bug in > the Soya library. I had the impression that since amd64 is a release architecture, such bugs should be grave, but I might be mistaken. That it is a known bug in the Soya library means you should reassign this bug to soya of course. > Btw bugreader, i'm still willing help to solve #281348, thanks. Ok, when I have some time I'll run balazar and slune through gdb on my amd64 machines and send the results! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#373733: balazar: segfaults when starting a game
On Wed, Jun 28, 2006 at 10:47:24AM +0200, Marc Dequènes wrote: > > Ok, when I have some time I'll run balazar and slune through gdb on my > > amd64 machines and send the results! > > I've got no amd64 available for tests, and i taggued +help the soya bug > since a while without success. So, i'd be glad to get a backtrace, > thanks :-) After digging into CDBS internals to find out how to create a python-soya with debugging symbols, I got the following result: [EMAIL PROTECTED]/tmp>balazar * Balazar * Balazar lives in /usr/share/games * Balazar * PyOpenAL not installed, trying PySDL_mixer... * Balazar * Warning! Neither PyOpenAL nor PySDL_mixer are installed; * music and sound are disabled! * Balazar * (Psyco not found ; if you are using an x86 processor, * installing psyco can speed up Balazar a little) * Soya * Using 8 bits stencil buffer * Soya * version 0.11.2 * Using OpenGL 2.0.2 NVIDIA 87.62 * - renderer : GeForce 6600/PCI/SSE2 * - vendor : NVIDIA Corporation * - maximum number of lights: 8 * - maximum number of clip planes : 6 * - maximum number of texture units : 4 * - maximum texture size: 4096 pixels * Tofu * Creating new player guus... * Balazar * Creating level 0, 0... * Tofu * Level level_0_0 8159424 activated ! * Tofu * Player guus login ! [1]15552 segmentation fault (core dumped) balazar [EMAIL PROTECTED]/tmp>mv core core.balazar [EMAIL PROTECTED]/tmp>gdb python2.4 core.balazar GNU gdb 6.4.90-debian ... Reading symbols from /var/lib/python-support/python2.4/soya/_soya.so...done. Loaded symbols for /var/lib/python-support/python2.4/soya/_soya.so .. Core was generated by `/usr/bin/python2.4 -O /usr/games/balazar'. Program terminated with signal 11, Segmentation fault. #0 __pyx_f_5_soya_5_Land__render (__pyx_v_self=0xbc30b0, __pyx_v_coordsyst=0xbc30b0) at _soya.c:52935 52935 ((struct __pyx_vtabstruct_5_soya__Material *)((struct __pyx_obj_5_soya__Material *)__pyx_2)->__pyx_base.__pyx_vtab)->_activate(((struct __pyx_obj_5_soya__Material *)__pyx_2)); (gdb) info frame Stack level 0, frame at 0x7fe2c290: rip = 0x2b6c798c1584 in __pyx_f_5_soya_5_Land__render (_soya.c:52935); saved rip 0x2b6c798bd05d called by frame at 0x7fe2c300 source language c. Arglist at 0x7fe2c258, args: __pyx_v_self=0xbc30b0, __pyx_v_coordsyst=0xbc30b0 Locals at 0x7fe2c258, Previous frame's sp is 0x7fe2c290 Saved registers: rbx at 0x7fe2c268, rbp at 0x7fe2c270, r12 at 0x7fe2c278, r13 at 0x7fe2c280, rip at 0x7fe2c288 (gdb) info locals __pyx_v_cur = __pyx_v_index = 14846752 __pyx_v_pack = __pyx_v_tri = __pyx_2 = (PyObject *) 0xabb92a50 (gdb) print *__pyx_2 Cannot access memory at address 0xabb92a50 (gdb) bt 10 #0 __pyx_f_5_soya_5_Land__render (__pyx_v_self=0xbc30b0, __pyx_v_coordsyst=0xbc30b0) at _soya.c:52935 #1 0x2b6c798bd05d in __pyx_f_5_soya_8Renderer__render_list (__pyx_v_self=0x9b70e0, __pyx_v_list=0x680480) at _soya.c:7352 #2 0x2b6c79891c1c in __pyx_f_5_soya_8Renderer__render (__pyx_v_self=0x9b70e0) at _soya.c:7100 #3 0x2b6c798cdf8e in __pyx_f_5_soya_7_Camera__subrender_scene (__pyx_v_self=) at _soya.c:22383 #4 0x2b6c7987f23f in __pyx_f_5_soya_7_Camera__render_scene (__pyx_v_self=0xb66ce0) at _soya.c:22428 #5 0x2b6c79825623 in __pyx_f_5_soya_7_Camera_render (__pyx_v_self=0xb66ce0, __pyx_args=, __pyx_kwds=) at _soya.c:22475 #6 0x004744a7 in PyEval_EvalFrame () #7 0x00474fec in PyEval_EvalCodeEx () #8 0x004bbd73 in PyClassMethod_New () #9 0x004139a0 in PyObject_Call () (More stack frames follow...) Looking in _soya.c tells me the generated code that segfaulted corresponded to "/home/jiba/src/soya/model/land.pyx":1148. There I see that it calls the function chunk_get_ptr(), which returns a void * type, which is then used and cast without any checks. I find chunk_get_ptr() in chunk.c. This file is dedicated to putting stuff into chunks and getting it out again, in the process completely removing any type information and doing potentially harmful pointer arithmetic. Anyway, debugging chunk.c didn't show any errors, the last call to chunk_get_ptr() before the crash returned the same pointer that was added to it with chunk_add_ptr(). Still, it could mean that the Pack that is being referenced in land.pyx around line 1148 has already been deleted earlier, or that the pointer it retrieves from renderer.data is not the pointer it expected. Anyway, here I quit, I hope you or the soya developers can use this information. Debugging results for slune will be added to #338913. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#376502: sensors-applet: crashes when started by gnome-panel
Package: sensors-applet Version: 1.7.1-1 Severity: grave Justification: renders package unusable When gnome-panel tries to start sensors-applet, sensors-applet immediately crashes. Reverting to 1.6.1-1 solves this problem. I have no idea what causes it. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.3 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages sensors-applet depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-3 The Bonobo UI library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-7 generic font configuration library ii libgconf2-42.14.0-1 GNOME configuration database syste ii libglib2.0-0 2.10.3-2 The GLib library of C routines ii libgnome-keyring0 0.4.9-1 GNOME keyring services library ii libgnome2-02.14.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-1 GNOME virtual file-system (runtime ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii libice61:1.0.0-3 X11 Inter-Client Exchange library ii liborbit2 1:2.14.0-2libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.14.2-1 library for GNOME 2 panel applets ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libpopt0 1.10-2lib for parsing cmdline parameters ii libsensors31:2.10.0-7library to read temperature/voltag ii libsm6 1:1.0.0-4 X11 Session Management library ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor11.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxml22.6.26.dfsg-2 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.0.2-4 X Rendering Extension client libra ii zlib1g 1:1.2.3-12compression library - runtime sensors-applet recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376502: sensors-applet: crashes when started by gnome-panel
On Mon, Jul 03, 2006 at 12:48:36PM +0100, Sam Morris wrote: > > When gnome-panel tries to start sensors-applet, sensors-applet > > immediately crashes. Reverting to 1.6.1-1 solves this problem. I have no > > idea what causes it. > > I think this is caused by the configuration format changing. Could you > please add a new instance of the applet to your panel and see if it, > too, crashes? > > Please don't remove the old instance of the applet, if the new instance > does not crash then we still need it to debug the old instance. A second one runs fine. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#376502: sensors-applet: crashes when started by gnome-panel
On Mon, Jul 03, 2006 at 02:43:53PM +0100, Sam Morris wrote:
> > A second one runs fine.
>
> Ok, can you get a stack trace of the crashing applet? I'm attaching a
> package that includes debugging symbols (if you want to compile your own
> instead, invoke 'debian/rules binary DEB_BUILD_OPTIONS=noopt,nostrip').
I have amd64 machines, so I have rebuilt the package myself. The result:
(sensors-applet:10249): Sensors Applet-DEBUG: creating new active sensor
(sensors-applet:10249): Sensors Applet-DEBUG: setting num samples to: 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47563759517168 (LWP 10249)]
0x00407194 in active_sensor_update (active_sensor=0x6f2490,
sensors_applet=0x5d8a20) at active-sensor.c:564
564 if ((sensor_value_range(sensor_value,
sensor_low_value, sensor_high_value) !=
sensor_value_range(active_sensor->sensor_values[0],
active_sensor->sensor_low_value, active_sensor->sensor_high_value)) ||
!(active_sensor->updated)) {
(gdb) bt full 6
#0 0x00407194 in active_sensor_update (active_sensor=0x6f2490,
sensors_applet=0x5d8a20) at active-sensor.c:564
model =
iter = {stamp = -2142798167, user_data = 0x628e40, user_data2 = 0x0,
user_data3 = 0x0}
path = (GtkTreePath *) 0x706aa0
sensor_path = (gchar *) 0x706b70 "sensor://it8712-isa-0290/51"
sensor_id = (gchar *) 0x706b20 "M/B Temp"
sensor_label = (gchar *) 0x706ba0 "M/B Temp"
sensor_type = TEMP_SENSOR
sensor_interface = LIBSENSORS
sensor_enabled = 1
sensor_low_value = 20
sensor_high_value = 60
sensor_alarm_enabled =
sensor_multiplier = 1
sensor_offset = 0
sensor_value = 298
icon_pixbuf =
graph_color =
value_text = (gchar *) 0x706ca0 "298"
scale =
error = (GError *) 0x0
tooltip = (gchar *) 0x5e8540 "M/B Temp 298"
__PRETTY_FUNCTION__ = "active_sensor_update"
#1 0x0040cbb5 in sensors_applet_sensor_enabled
(sensors_applet=0x5d8a20, path=) at sensors-applet.c:1004
active_sensor = (ActiveSensor *) 0x7068e0
__PRETTY_FUNCTION__ = "sensors_applet_sensor_enabled"
#2 0x0040d323 in sensors_applet_add_sensor_full_details
(sensors_applet=0x5d8a20, path=0x6edcc0 "sensor://it8712-isa-0290/51",
id=0x5edae0 "M/B Temp", label=0x5edae0 "M/B Temp", interface=LIBSENSORS,
type=TEMP_SENSOR, enable=1, low_value=20, high_value=60, alarm_enable=0,
alarm_command=0x412ff1 "", alarm_timeout=0, multiplier=1, offset=0,
icon_type=CPU_ICON, graph_color=0x411f24 "#ff") at sensors-applet.c:907
interfaces_iter = {stamp = -2142798167, user_data = 0x52c660,
user_data2 = 0x0, user_data3 = 0x0}
sensors_iter = {stamp = -2142798167, user_data = 0x628e40, user_data2 =
0x0, user_data3 = 0x0}
not_empty_tree =
node_interface = 7
not_end_of_interfaces =
not_end_of_sensors =
sensor_id = (gchar *) 0x6f3310 ""
icon =
tree_path = (GtkTreePath *) 0x6edca0
__PRETTY_FUNCTION__ = "sensors_applet_add_sensor_full_details"
#3 0x0040d4ac in sensors_applet_add_sensor (sensors_applet=0x7068e0,
path=0x6edcc0 "sensor://it8712-isa-0290/51",
id=0x1c , label=0x1 , interface=4278124287, enable=, type=1223419880,
icon_type=CPU_ICON) at sensors-applet.c:959
low_value = 0
high_value = 3.0604876669010184e-317
__PRETTY_FUNCTION__ = "sensors_applet_add_sensor"
#4 0x00410b4f in libsensors_sensors_interface_init
(sensors_applet=0x5d8a20) at libsensors-sensors-interface.c:225
visible = 1
icon = CPU_ICON
url = (gchar *) 0x710420 ""
__PRETTY_FUNCTION__ = "libsensors_sensors_interface_init"
#5 0x0040c7c9 in sensors_applet_init (sensors_applet=0x5d8a20) at
sensors-applet.c:1167
__PRETTY_FUNCTION__ = "sensors_applet_init"
(More stack frames follow...)
(gdb) print *active_sensor
$1 = {sensors_applet = 0x5d8a20, label = 0x701840, icon = 0x705810, value =
0x701920, graph = 0x704880, graph_frame = 0x568ca0,
label_event_box = 0x568310, icon_event_box = 0x568430, value_event_box =
0x5683a0, graph_event_box = 0x5684c0, graph_color = {pixel = 0, red = 0,
green = 0, blue = 0}, sensor_row = 0x6f2400, notification = 0x0, updated =
0, alarm_timeout_id = -1, alarm_command = 0x0, alarm_timeout = 0,
sensor_values = 0x0, num_samples = 0, sensor_low_value = 0, sensor_high_value
= 0}
(gdb) print *sensors_applet
$2 = {applet = 0x5bd000, size = 0, sensors = 0x5c1e70, selection = 0x0,
get_sensor_value = {0, 0x40ece0 ,
0x40fed0 , 0, 0, 0, 0, 0x410c30
, 0, 0, 0, 0},
timeout_id = 0, prefs_dialog = 0x0, table = 0x0
Bug#376502: sensors-applet: crashes when started by gnome-panel
On Mon, Jul 03, 2006 at 05:31:50PM +0100, Sam Morris wrote: > > I guess it crashes when trying to evaluate active_sensor->sensor_values[0], > > because sensor_values is a NULL pointer. > > Looks like the same crash I was debugging earlier. Can you please try > the attached patch? With the patch I no longer see crashes when I restart gnome with sensors-applet 1.7.1. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#336302: wireless-tools: Wireless won'g connect
severity 336302 important thanks On Sat, Oct 29, 2005 at 12:23:18PM +0100, Anthony Campbell wrote: > Package: wireless-tools > Version: 27+28pre10-1 > Severity: grave > Justification: renders package unusable Please. When you used reportbug, it said: "grave: makes the package in question UNUSABLE BY MOST OR ALL USERS, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package." > My Cisco Aironet has stopped connecting to the router. It keeps saying > the ESSID is "tsunami" and reports the access point as FF:FF: > > I made a fresh install of Debian on a spare partition via netinst and > everything worked perfectly. I then did a dist-upgrade to Sid and the > above error reappeared. > > I don't know whether the bug is in wireless-tools or libiw. Could you show me the full output of "iwconfig -a"? > Kernel: Linux 2.6.13.4 Is that a kernel from an official Debian kernel package, is it one from the netinst or is it a kernel you compiled yourself? If it is not the same kernel as installed by the netinst, could you try installing the one from netinst and check if that makes any difference? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#324118: libclanlib2c2: Package is empty.
Package: libclanlib2c2 Version: 0.6.5-1-2.3 Severity: grave Justification: renders package unusable The package libclanlib2c2 is empty, save for a /usr/share/doc/libclanlib2c2 directory. It should contain the shared libclanCore library, unless I'm mistaken... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.2 Locale: LANG=nl_NL, LC_CTYPE=nl_NL (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289586: FTBFS: Provides but also Build-Conflicts with libgnutls-dev
severity 289586 normal thanks On Mon, Jan 10, 2005 at 06:52:53AM +0100, Matthias Urlichs wrote: > > The source package gnutls11 Build-Conflicts: libgnutls-dev, but an > > already installed version of libgnutls11-dev will Provide: > > libgnutls-dev, so building will fail. Either the Build-Conflict, the > > Provides or both should be removed from debian/control. > > The point is that if the -dev package is installed, a build will link > with the installed libraries instead of the one I'm building (the > package has more than one shared library). > > Conflicting with -dev is better than playing linker games. Well, I think it would be an upstream bug if the binaries created by the gnutls11 package would link to the previously installed libraries instead of the libraries you just compiled. Anyway, I've looked at the build process more closely, and found that upstream does the right thing (it uses libtool which makes sure of that), but it is dh_shlibdeps called from debian/rules that checks the installed libraries instead of the compiled libraries. From the dh_shlibdeps manpage: Suppose that your source package produces libfoo1, libfoo-dev, and libfooâbin binary packages. libfooâbin links against libfoo1, and should depend on it. In your rules file, first run dh_makeshlibs, then dh_shlibdeps: dh_makeshlibs dh_shlibdeps âL libfoo1 âl debian/libfoo1/usr/lib This will have the effect of generating automatically a shlibs file for libfoo1, and using that file and the libfoo1 library in the debian/libfoo1/usr/lib directory to calculate shared library dependency information. Looking at CDBS, I guess you can set DEB_SHLIBDEPS_INCLUDE and DEB_SHLIBDEPS_LIBRARY_package to make it do what the manpage suggests. > Just deinstall gnutls11-dev before building a new version. > What's the problem? Apart from that being slightly anoying, it seems wrong to me that a package would Build-Conflict with itself. The build environment shouldn't brake down because of previously installed packages it doesn't Build-Depend on in my opinion. I also don't see many other source packages Build-Conflicting with their own -dev packages. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#293729: xsltproc: segfaults on some architectures, makes gmime2.1 FTBFS
Package: xsltproc Version: 1.1.12-3 Severity: serious Justification: makes another package FTBFS The autobuilders of some architectures fail to build gmime2.1. For example on sparc: cd ./html && gtkdoc-mkhtml gmime ../gmime-docs.sgml Computing chunks... /usr/bin/gtkdoc-mkhtml: line 45: 16526 Bus error /usr/bin/xsltproc --nonet --xinclude --stringparam gtkdoc.bookname $module --stringparam gtkdoc.version "1.3" $gtkdocdir/gtk-doc.xsl $document For more details, see http://buildd.debian.org/build.php?&pkg=gmime2.1. If the problem happens to be caused by another package, please reassign this bug. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-skas3-v7 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages xsltproc depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libgcrypt11 1.2.0-11 LGPL Crypto library - runtime libr ii libgpg-error0 1.0-1library for common error values an ii libxml2 2.6.16-1 GNOME XML library ii libxslt1.1 1.1.12-3 XSLT processing library - runtime ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293729: [xml/sgml-pkgs] Bug#293729: xsltproc: segfaults on some architectures, makes gmime2.1 FTBFS
On Sat, Feb 05, 2005 at 02:37:36PM +0100, Mike Hommey wrote: > Mm it *could* be due to the new libxml2 upload. An upload of libxslt > (and therefore xsltproc) is programmed soon and might solve the problem > if it is that. > > I'd be interested in getting a backtrace, though, if you could provide > one. Unfortunately it doesn't fail on x86, so I cannot dig into it myself. > BTW, I don't understand how buildds get packages from incoming when they > build a package. (libxml2 2.6.11-2 packages are still in incoming at the > moment and got used on sparc, ia64, s390 and arm) I don't know about that either, but the build log of the sparc autobuilder says: Selecting previously deselected package libxml2. Unpacking libxml2 (from .../libxml2_2.6.16-2_sparc.deb) ... Selecting previously deselected package libxslt1.1. Unpacking libxslt1.1 (from .../libxslt1.1_1.1.8-5_sparc.deb) ... Selecting previously deselected package xsltproc. Unpacking xsltproc (from .../xsltproc_1.1.8-5_sparc.deb) ... -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#294056: gmime2.1_2.1.11-1(m68k/unstable/jt7): fails to build from source
merge 294056 293729 thanks -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#304916: [FTBFS] schedutils need to be updated with the recent glibc change
tags 304916 + pending thanks On Sat, Apr 16, 2005 at 10:37:53PM +0900, GOTO Masanori wrote: > In the recent up coming glibc-2.3.2.ds1-21, two system call, > sched_setaffinity and sched_getaffinity, are changed. New interface > needs three argument (OTOH, glibc 2.3.2.ds1-20 has only two > arguments). The new upstream schedutils 1.4.0 is already released and > it uses new three-argument style system calls. > > If you plan to dupload schedutils 1.4.0, you rebuild package with > glibc 2.3.2.ds1-21 and dupload it. Don't forget to update > Build-Depends: libc6 (>= 2.3.2.ds1-21) in debian/control. If you plan > to change for the current 1.3.4 and dupload it, please apply my > attached patch, and dupload it. Actually I was waiting for a new glibc to come out so I could start uploading 1.4.0 :) I have a 1.4.0 package already prepared so I just need to compile it with the new glibc and I'll upload it soon. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#315203: gmime2.1: FTBFS: build-depends on mono, which is only available on i386/ppc
On Mon, Jun 20, 2005 at 11:03:00PM -0700, Steve Langasek wrote: > The most recent version of gmime2.1 fails to build on all architectures > except for i386 and powerpc, due to the addition of various mono-related > build-dependencies: Yes, I noticed. The amd64 autobuilders seem to compile gmime2.1 without problems as well. > I think the mono build-dependencies are not needed for all architectures, > only for those architectures for which the libgmime2.1-cil package will be > provided. In contrast, libgmime2.1 and libgmime2.1-dev *are* needed on all > architectures, because there are existing packages which depend on them. > Please make the build-dependencies on cli-common, mono-mcs, mono-gac, and > gtk-sharp conditional by architecture. I will. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#443561: Gnome Bugzilla link
forwarded 443561 http://bugzilla.gnome.org/show_bug.cgi?id=111511 thanks On Thu, Dec 06, 2007 at 11:12:12AM +0100, Thomas Viehmann wrote: > this bug has been reported upstream in gnome bugzilla > http://bugzilla.gnome.org/show_bug.cgi?id=501830 > > Guus, it would be cool if you could adopt forwarding bugs to the proper > locations instead of non-public (non-list) E-Mail adresses. That way > everyone gets to see the state of upstream work on it and other people > looking at upstream's bug tracking can find it as well. Well, I can't remember exactly, but when I took over gmime I think it wasn't yet an option to forward gmime bugs to bugzilla, and I had to contact upstream directly, and I'm still doing that. But you're right that I should forward bugs to the most proper place. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#174456: Planet textures moved to 'celestia-common-nonfree', which doesn't exist.
On Sat, May 31, 2008 at 10:05:23AM -0700, Geoffrey Broadwell wrote: > This version supposedly moved all of the data with unclear licenses > to 'celestia-common-nonfree', but that package doesn't seem to exist. > Nor are there instructions (that I can find) describing how to acquire > and install that data. > > Which is ... suboptimal ... when trying to show one's kids what Jupiter > or even Earth's moon looks like. :-) A celestia-common-nonfree package has been uploaded to Debian's non-free section at the same time as the DFSG-compliant celestia-common, but the -nonfree package has yet to be accepted for inclusion in Debian's archives by the ftp-masters. When it is accepted, you should be able to just apt-get install it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#484047: fair_0.5.1-1(hppa/unstable): FTBFS: missing build-depends?
On Sun, Jun 01, 2008 at 09:26:35PM -0600, [EMAIL PROTECTED] wrote: > There was an error while trying to autobuild your package: > > > ** Using build dependencies supplied by package: > > Build-Depends: autotools-dev, debhelper (>= 5), libavl-dev > [...] > > checking for avl_init_node in -lavl... no > > configure: error: No libavl found. Please install it before proceeding. > > See `config.log' for more details. > > make: *** [config.status] Error 1 > > dpkg-buildpackage: failure: debian/rules build gave error exit status 2 The build-dependency libavl-dev is there. Fair also build without problems on all other architectures. Would it be possible to get the config.log from this build daemon? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#459295: libgnutls26-dbg: Conflicts with libgnutls13-dbg
Package: libgnutls26-dbg Version: 2.2.0-1 Severity: serious Justification: Policy 3.9 The libgnutlsXX-dbg packages do not only contain versions of the libraries with debugging symbols, but also unstripped binaries from the gnutls-bin package. This prevents multiple -dbg packages from being installed simultaneously: Selecting previously deselected package libgnutls26-dbg. Unpacking libgnutls26-dbg (from .../libgnutls26-dbg_2.2.0-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libgnutls26-dbg_2.2.0-1_amd64.deb (--unpack): trying to overwrite `/usr/lib/debug/usr/bin/gnutls-cli', which is also in package libgnutls13-dbg Either the -dbg packages should conflict with each other, or the unstripped binaries should be moved to a new package, for example gnutls-bin-dbg. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.9 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnutls26-dbg depends on: ii libgnutls26 2.2.0-1the GNU TLS library - runtime libr libgnutls26-dbg recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459286: Fixed in gnuvd 1.0.5
On Sun, Jan 27, 2008 at 12:09:18PM +0100, Roel Huybrechts wrote: > This bug is fixed in gnuvd version 1.0.5 which can be downloaded from > http://www.djcbsoftware.nl/code/gnuvd/ Yes, but the gnovd component is broken in 1.0.5, I have told upstream, I'm waiting for a fix for that. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#463158: openglad: segfaults immediately
Package: openglad Version: 0.98-2 Severity: grave Justification: renders package unusable >openglad [1]30637 segmentation fault openglad When I start openglad, I see a window appearing for a split second, then it immediately crashes. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openglad depends on: ii libc6 2.7-6GNU C Library: Shared libraries ii libgcc1 1:4.3-20080127-1 GCC support library ii libsdl-mixer1.2 1.2.8-3 mixer library for Simple DirectMed ii libsdl1.2debian 1.2.13-1 Simple DirectMedia Layer ii libstdc++6 4.3-20080127-1 The GNU Standard C++ Library v3 openglad recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445761: Proposed NMU
On Fri, Oct 19, 2007 at 01:03:39AM +0530, Kumar Appaiah wrote: > I propose to NMU this package. the diff is attached with this > mail. The package is available here: > > dget -x http://mentors.debian.net/debian/pool/main/w/wbd/wbd_1.0ucl4-5.1.dsc No need, I'll look at the patches later tonight and upload new packages myself. Thanks for the help and willingness to NMU though! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#450607: oprofile-gui: oprof_start is linked with libbfd-2.18.so, which does not exist
Package: oprofile-gui Version: 0.9.3-1 Severity: grave Justification: renders package unusable [EMAIL PROTECTED]>oprof_start oprof_start: error while loading shared libraries: libbfd-2.18.so: cannot open shared object file: No such file or directory oprofile-gui depends on binutils, which does provide libbfd, but only these files are present on my system: [EMAIL PROTECTED]>ls -l /usr/lib/libbfd* -rw-r--r-- 1 root root 851368 Oct 27 19:49 /usr/lib/libbfd-2.18.20071027.so -rw-r--r-- 1 root root 8431724 Oct 27 19:49 /usr/lib/libbfd.a lrwxrwxrwx 1 root root 23 Oct 31 09:39 /usr/lib/libbfd.so -> libbfd-2.18.20071027.so Maybe this is a bug in the binutils package, I don't know. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages oprofile-gui depends on: ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina ii debconf [debconf-2. 1.5.16 Debian configuration management sy ii libc6 2.6.1-6 GNU C Library: Shared libraries ii libgcc1 1:4.2.2-3GCC support library ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libpopt01.10-3 lib for parsing cmdline parameters ii libqt3-mt 3:3.3.7-9Qt GUI Library (Threaded runtime v ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.2.2-3 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii oprofile0.9.3-1 system-wide profiler for Linux sys oprofile-gui recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471378: blobwars: Segmentation fault
On Tue, Mar 18, 2008 at 10:50:36AM -0300, David Roguin wrote: > I just download the debian source and compiled it. > And I can't reproduce the bug. Mark runs it on powerpc, it could be an endianness bug. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471378: blobwars: Segmentation fault
On Mon, Mar 17, 2008 at 09:52:36PM +1100, Mark Purcell wrote: > When trying to start blobwars, I get the initial screen that says > 'Loading...' then > I get a segmentation fault: > > $ blobwars > Segmentation fault > > Rebuilding against the current libraries in unstable doesn't help either. Did blobwars work for you before? Also, could you try building non-stripped binaries, and use gdb to get a backtrace of the stack from the core dump? If you don't know how I can show you. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471378: blobwars: Segmentation fault
Hello Cyril, Could you verify if blobwars crashes on powerpc? Below follows the original bugreport: On Mon, Mar 17, 2008 at 09:52:36PM +1100, Mark Purcell wrote: > Package: blobwars > Version: 1.08-1 > Severity: grave > > When trying to start blobwars, I get the initial screen that says > 'Loading...' then > I get a segmentation fault: > > $ blobwars > Segmentation fault > > Rebuilding against the current libraries in unstable doesn't help either. > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: powerpc (ppc) > > Kernel: Linux 2.6.24-1-powerpc > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages blobwars depends on: > ii libc6 2.7-9 GNU C Library: Shared libraries > ii libgcc11:4.3.0-1 GCC support library > ii libmikmod2 3.1.11-a-6A portable sound library > ii libsdl-image1.21.2.6-3 image loading library for Simple > D > ii libsdl-mixer1.21.2.8-3 mixer library for Simple > DirectMed > ii libsdl-ttf2.0-02.0.9-1 ttf library for Simple > DirectMedia > ii libsdl1.2debian1.2.13-2 Simple DirectMedia Layer > ii libstdc++6 4.3.0-1 The GNU Standard C++ Library v3 > ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime > > blobwars recommends no packages. > > -- no debconf information -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471378: blobwars: Segmentation fault
tags 471378 + unreproducible severity 471378 serious thanks On Mon, Mar 17, 2008 at 09:52:36PM +1100, Mark Purcell wrote: > $ blobwars > Segmentation fault I haven't heard a reply from you yet, and I asked Cyril Brulebois to reproduce the segmentation fault on PowerPC, but on his computer blobwars worked. Therefore I am downgrading this bug. I do hope you can produce a coredump and a backtrace so we can figure out what happens on your machine. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#443561: off_t size changed causing ABI breakage, but ABI was not bumped
severity 443561 important thanks On Sat, Sep 22, 2007 at 02:25:49PM +0200, Mirco Bauer wrote: > libgmime-2.0-2 introduced an ABI breakage in 2.2.10-1 by activating LFS. > GMime has a streaming API which uses off_t, and that changed size. AFAIK there are no packages in Debian that depend on gmime2.2 that do not work with the current version. The ABI should still have been bumped of course, but I think it is safe to let gmime2.2 migrate to testing. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#443561: Still RC
On Tue, Apr 01, 2008 at 02:10:43PM +0200, Marc 'HE' Brockschmidt wrote: > severity 443561 serious > thanks > > Even if packages in sid may work at this time, ahve you verified the > same for packages from lenny and/or stable? What about locally compiled > software? Simply bump the SONAME and be done with it. We will happily > schedule binNMUs for all of your r-depends. I can bump the soname but then I'd be out of sync with upstream, which unfortunately has other opinions about this issue. What about creating a .shlibs file that makes packages depending on the -dev package depend on libgmime-2.0-2 >= 2.2.11? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#443561: Suggested plan
On Sat, Apr 05, 2008 at 02:57:20AM +0100, Stephen Gran wrote: > Rename libgmime-2.0-2 to libgmime-2.0-2a. [...] > I'm happy to do an NMU doing the rename if you like. Not being an RM, I > can't start the binNMU campaign myself, but I'm happy to prod the RMs > about it. Go ahead! I don't have too much time at the moment so the help is welcome. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471378: blobwars: Segmentation fault
On Tue, Apr 01, 2008 at 11:06:49PM +1100, Mark Purcell wrote: > > I haven't heard a reply from you yet, and I asked Cyril Brulebois to > > reproduce the segmentation fault on PowerPC, but on his computer > > blobwars worked. Therefore I am downgrading this bug. I do hope you can > > produce a coredump and a backtrace so we can figure out what happens on > > your machine. > > Sorry about the delay in response. > > I am still having the issue with Segmentation Faults, but haven't yet been > able to produce a core dump. > > I have created my blobwars-dbg package with symbols, but when I run with gdb, > the startup 'loading' screen goes full screen and I can't control gdb any > further. I haven't played around with it too much though ;-( > > I see there is a -fullscreen option, but no -nofullscreen, so it must be a > compile time flag, if I can get that then I should be able to make some > further progress. Try to remove the config files: rm -R ~/.parallelrealities/blobwars By default, blobwars should start in windowed mode. But you don't need to start blobwars from within gdb. To get a core dump from a normally started blobwars, make sure you are in a directory that you have write access in (your home or /tmp), and give the following command (in bash): ulimit -c unlimited Then try running blobwars again. Now you should have a coredump that you can process with gdb. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#400874: grave?
I have this problem as well, I also have an amd64 system (unstable though, not etch). Maybe it is not grave, but serious. You wouldn't want to release etch with this bug. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#396964: Accepted lynx 2.8.5-2sarge2.2 (source i386)
On Thu, Nov 30, 2006 at 07:00:14AM -0500, Thomas Dickey wrote: > > > There's no possibility of including that patch upstream. > > > > So what? If upstream does not want to accept a patch that fixes a > > so what? Read the patch. You certainly didn't, or if you _did_ you > understand nothing of the change. > > The patch breaks existing functionality (hardcodes one of the configurable > selections). I didn't know PERSONAL_MAILCAP was run-time configurable (it looks a #define to me). If apt-get source wasn't segfaulting at the moment I'd check it. But this explaination is a lot more useful than "upstream won't accept it". But why did you send this to the debian-devel mailing list instead of as a follow-up to the bugreport? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
