Bug#720390: freemind: showing preferences fails with IllegalAccessError
Package: freemind Version: 0.9.0+dfsg-2 Severity: important Selecting the Preferences menu entry causes the following exception: STDERR: Exception in thread AWT-EventQueue-0 STDERR: java.lang.IllegalAccessError: tried to access method com.jgoodies.forms.layout.RowSpec.init(Ljava/lang/String;)V from class freemind.preferences.layout.OptionPanel$KeyProperty STDERR: at freemind.preferences.layout.OptionPanel$KeyProperty.layout(OptionPanel.java:403) STDERR: at freemind.preferences.layout.OptionPanel.buildPanel(OptionPanel.java:205) STDERR: at freemind.controller.Controller$PropertyAction.actionPerformed(Controller.java:1500) STDERR: at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) STDERR: at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) STDERR: at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) STDERR: at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) STDERR: at javax.swing.AbstractButton.doClick(AbstractButton.java:374) STDERR: at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:829) STDERR: at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:873) STDERR: at java.awt.Component.processMouseEvent(Component.java:6288) STDERR: at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) STDERR: at java.awt.Component.processEvent(Component.java:6053) STDERR: at java.awt.Container.processEvent(Container.java:2045) STDERR: at java.awt.Component.dispatchEventImpl(Component.java:4649) STDERR: at java.awt.Container.dispatchEventImpl(Container.java:2103) STDERR: at java.awt.Component.dispatchEvent(Component.java:4475) STDERR: at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4633) STDERR: at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4297) STDERR: at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4227) STDERR: at java.awt.Container.dispatchEventImpl(Container.java:2089) STDERR: at java.awt.Window.dispatchEventImpl(Window.java:2587) STDERR: at java.awt.Component.dispatchEvent(Component.java:4475) STDERR: at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:675) STDERR: at java.awt.EventQueue.access$300(EventQueue.java:96) STDERR: at java.awt.EventQueue$2.run(EventQueue.java:634) STDERR: at java.awt.EventQueue$2.run(EventQueue.java:632) STDERR: at java.security.AccessController.doPrivileged(Native Method) STDERR: at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) STDERR: at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:116) STDERR: at java.awt.EventQueue$3.run(EventQueue.java:648) STDERR: at java.awt.EventQueue$3.run(EventQueue.java:646) STDERR: at java.security.AccessController.doPrivileged(Native Method) STDERR: at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) STDERR: at java.awt.EventQueue.dispatchEvent(EventQueue.java:645) STDERR: at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) STDERR: at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) STDERR: at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) STDERR: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) STDERR: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) STDERR: at java.awt.EventDispatchThread.run(EventDispatchThread.java:138) -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720387: freemind: several bugus french translations
retitle 720387 freemind: several bugus french translations thanks Another one: Preferences should be Préférences, not Propriétés. Could it be that this software is using a sub-standard way of handling translations, instead of something like gettext ? -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720424: gnome-desktop-data: misleadingly advertises shipping .desktop files
Package: gnome-desktop-data Version: 2.32.1-2 Severity: normal No .desktop file in there, apparently. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720424: gnome-desktop-data: misleadingly advertises shipping .desktop files
On Wed, Aug 21, 2013 at 11:30:54PM +0200, Michael Biebl wrote: Am 21.08.2013 19:11, schrieb Yann Dirson: Package: gnome-desktop-data Version: 2.32.1-2 Severity: normal No .desktop file in there, apparently. Indeed not. Er, done ? What did I miss ? Description-en: Common files for GNOME desktop apps This package includes some files that are shared between several GNOME apps (Pixmaps, .desktop files and internationalization files). ^^ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666525: not fixed yet in pbuilder 0.215
found 666525 pbuilder/0.215 thanks I regularly got in the previous weeks, when working on gcompris, qgo, and today with tagua: [ 36%] Building CXX object src/CMakeFiles/tagua.dir/hlvariant/minichess5/variant.o ccache: FATAL: Failed to create /work/pbuilder/ccache/b/0: Permission denied make[3]: *** [src/CMakeFiles/tagua.dir/hlvariant/minichess5/variant.o] Error 1 Trying to avoid the problem, I had just regenerated by base.tgz from scratch, but it obviously did not help. I am using the shell on failure hook from http://bazaar.launchpad.net/%7Ekubuntu-members/pbuilder/pbuilder-hooks/, which helps me see what's wrong: # ls -l /work/pbuilder/ccache total 72 drwxr-xr-x 6 pbuilder pbuilder 4096 Aug 18 13:30 0 ... drwxr-xr-x 5 pbuilder pbuilder 4096 Aug 18 13:30 9 -rw-r--r-- 1 root root 190 Aug 18 13:22 CACHEDIR.TAG drwxr-xr-x 5 pbuilder pbuilder 4096 Aug 18 13:30 a drwxr-xr-x 2 root root 4096 Aug 18 13:22 b drwxr-xr-x 5 pbuilder pbuilder 4096 Aug 18 13:30 c drwxr-xr-x 3 pbuilder pbuilder 4096 Aug 18 13:30 d drwxr-xr-x 9 pbuilder pbuilder 4096 Aug 18 13:30 e drwxr-xr-x 3 pbuilder pbuilder 4096 Aug 18 13:30 f drwxr-xr-x 2 root root 4096 Aug 18 13:22 tmp The workaround I use is very far from satisfactory, but far less costly than rerunning the build from scratch: from the hook's shell run: chown -R pbuilder.pbuilder /work/pbuilder/ccache then let the build go on: dpkg-buildpackage -us -uc -nc ... and manually copy the generated files from the chroot before exiting the shell. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719496: freeorion: input textfields doesn't work after a while.
On Tue, Aug 13, 2013 at 07:18:32PM +0200, Markus Koschany wrote: On 13.08.2013 17:24, Marius Wegner wrote: I use Xfce, Nouveau and a Geforce GT 425M on amd64. Everything else in the game including mouse keeps working. Modifying x11_keyboard_grab to true doesn't help, but i started freeorion in xmonad today and it runs without the bug. probably its a problem with xfwm4. Thank you for providing additional information for this bug report. I think we are getting closer to the root cause of this issue. I have installed freeorion on a pure sid system with Openbox and I still can't reproduce this bug thus I will try with Xfce again tomorrow. I am myself using openbox with razor-qt, so the issue may not be that simple. Setting x11_keyboard_grab to true does correct the problem here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719496: freeorion: input textfields doesn't work after a while.
Package: freeorion Version: 0.4.3-1 Followup-For: Bug #719496 I have the exact same problem here. Nothing special to do, I cannot modify a textfield in-game. I am on amd64 as well, and I'm launching freeorion normally, from terminal or wm menu. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages freeorion depends on: ii freeorion-data0.4.3-1 ii libalut0 1.1.0-3 ii libboost-filesystem1.53.0 1.53.0-5 ii libboost-python1.53.0 1.53.0-5 ii libboost-serialization1.53.0 1.53.0-5 ii libboost-signals1.53.01.53.0-5 ii libboost-system1.53.0 1.53.0-5 ii libboost-thread1.53.0 1.53.0-5 ii libbulletcollision2.812.81-rev2613+dfsg-2 ii libc6 2.17-92 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.1-2 ii libgl1-mesa-glx [libgl1] 9.1.4-1 ii libglu1-mesa [libglu1]9.0.0-1 ii libjpeg8 8d-1 ii liblinearmath2.81 2.81-rev2613+dfsg-2 ii libogre-1.8.0 1.8.0+dfsg1-4 ii libois-1.3.0 1.3.0+dfsg0-5 ii libopenal11:1.14-4 ii libpng12-01.2.49-4 ii libpython2.7 2.7.5-5 ii libstdc++64.8.1-2 ii libtiff4 3.9.7-1 ii libvorbisfile31.3.2-1.3 ii zlib1g1:1.2.8.dfsg-1 freeorion recommends no packages. freeorion suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717291: smemcap: undeclared conflicts with previous smem
Package: smemcap Version: 1.3-2 Severity: serious Unpacking smemcap (from .../smemcap_1.3-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/smemcap_1.3-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man8/smemcap.8.gz', which is also in package smem 1.3-1 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages smemcap depends on: ii libc6 2.17-7 smemcap recommends no packages. smemcap suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715411: cookboob: should recommend python-cssselect ?
Package: weboob Version: 0.f-1 Severity: normal When searching with (q)cookboob, all backends fail: Bug(marmiton): cssselect seems not to be installed. See http://packages.python.org/cssselect/ === [ 0%] Getting http://updates.weboob.org/0.f/main/ Bug(cuisineaz): cssselect seems not to be installed. See http://packages.python.org/cssselect/ === [ 0%] Getting http://updates.weboob.org/0.f/main/ Bug(750g): cssselect seems not to be installed. See http://packages.python.org/cssselect/ === [ 0%] Getting http://updates.weboob.org/0.f/main/ Installing python-cssselect does the trick as expected. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages weboob depends on: ii python 2.7.5-2 ii python-html2text3.200.3-2 ii python-prettytable 0.6.1-1 ii python-weboob-core 0.f-1 weboob recommends no packages. weboob suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612402: Info received (Similar issue, system suddenly needs help to boot up)
Just to confirm: my situation is really the same that has been
described in this bugreport. When dropped into the initramfs shell I
can verify that ROOT=/dev/disk/by-uuid/, and furthermore, I also
have resume=UUID= trying to reference my swap partition.
If I just set them to the /dev/mapper/vg-lv paths expected by
local-top/lvm2 and rerun the script, the LVs are properly activated.
Now:
* I did not recall changing anything in that field, so whatever change
in whatever package, that is responsible for this seems to warrant
the critical severity this bug used to have. It may be more
tricky than just grub uses UUID by default and LVM does not want
that, but we have to track this problem.
* both ROOT and resume seem to be set by
/usr/share/initramfs-tools/init which belongs to package initramfs.
Although it was updated from 0.112 to 0.113 since the last succesful
boot, there is change in that area, and what it does to set ROOT
from the kernel commandline seems legit. I can't say the same for
resume, which apparently should go through the same processing but
fails to.
* that switches the focus to whoever sets root=UUID= on the
commandline, and /etc/grub.d/10_linux seems to be where the thing
originates. There we have a test looking at « uses_abstraction
${GRUB_DEVICE} lvm » that should just avoid the issue completely,
and obviously fails. Grub had been updated one month before from
1.99-27 to 1.99-27+deb7u1 - this change includes something labelled
TPU upload to lose dependency blockage on LVM. and in fact Daniel
Pocock already reported Bug#707831 with a short and clear statement,
just a pity this was not mentionned here...
I'll raise the severity of Bug#707831. You may want to keep this one
open so users are aware of the problem, or just reasign/merge with
that other bug...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707831: Broken UUID detection code makes another system unbootable
retitle 707831 Broken UUID detection code makes LVM systems unbootable after adding a new PV severity 707831 critical thanks I also got bitten by this issue, like others as seen in #612402. Since it makes (at least some) LVM systems unbootable, it surely deserves a higher severity. Now what happens ? As Daniel said, grub-probe is failing. More specifically: # /usr/sbin/grub-probe --device /dev/mapper/home-root --target=abstraction /usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map. So what does that message mean, ie. what does this pv1 comes from ? A bit of googling shows that the problem is linked to me having added a PV to the machine. The previous reboot was certainly the one during which I have plugged the drive, and the machine had had no need to reboot since its inclusion as PV into my VG. So well, does moving away the old map and running grub-mkdevicemap fix the problem ? Not really, since I now see many dozens of physical volume pv0 not found lines, where I used to have a single complaint about pv1. What happened ? If I look at the generated grub.cfg now, the linux commandline has changed back to using the correct /dev/mapper/ path, but the UUID used for search --set=root is now that of my /usr partition instead of that of the (non-LVM) /boot. Is this *only* used to load the background image and font from /usr ? In short: * grub-probe issues completely unhelpful messages about PVs, where it could surely give their Linux names, and give a hint that *checking* the device map is not going to be sufficient, and that grub-mkdevicemap may come handy * I surely missed something, or the use grub-mkdevicemap should not have generated a situation that just looks more messy * As the original report says, such problems should surely not propagate to grub.cfg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612402: Similar issue, system suddenly needs help to boot up
I just got a similar problem, where my testing amd64 machine stopped booting after I had to shut it down. Previous boot had occured on May 22th, and quite a lot of packages were updated since that time, including linux-image-3.2.0-4-amd64, which was the running kernel, from 3.2.41-2 to 3.2.46-1. As others described, I get a complain about a partition UUID not being found, get dropped to an initramfs shell, and after manually running vgchange -ay the boot does proceed fine. Any hint about what to look for ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709657: Resurecting serna
On Sat, Jun 22, 2013 at 10:19:55PM +0200, Yann Dirson wrote: I have started to work on bringing serna back into shape. Pushed preliminar work to the collab-maint repo, as branch wip/resurection. The result builds with today's jessie, but: - it does not follow git-dpm conventions - I did not take time to implement the proper fix for finding libs (multiarch locations broke their silly logic), and only added a hack for amd64 - when launched the app stays on splash screen, looping in the Qt event loop Surely more will come, but any help is welcome :) Most critical problems identified, and either fixed or worked around (pushed a rewound wip/resurection). Will need a proper fix for library detection/loading before thinking about an upload to experimental, though. To maintainers: what are your plans wrt serna ? Would you like to continue working on it ? Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709657: Resurecting serna
I have started to work on bringing serna back into shape. Pushed preliminar work to the collab-maint repo, as branch wip/resurection. The result builds with today's jessie, but: - it does not follow git-dpm conventions - I did not take time to implement the proper fix for finding libs (multiarch locations broke their silly logic), and only added a hack for amd64 - when launched the app stays on splash screen, looping in the Qt event loop Surely more will come, but any help is welcome :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703759: python-libpcap: new version available
Package: python-libpcap Version: 0.6.2-0.2 Severity: normal 0.6.2 is very old now, 0.6.4 has been released in 2012 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703773: impacket: new version available
Source: impacket Version: 0.9.6.0-3 Severity: normal Version 0.9.9.9 was published last July. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703784: python-impacket: incoherent doc for byte-order format specifiers, and doc typos
Package: python-impacket Version: 0.9.6.0-3 Severity: normal in the impacket.structure.Structure doc: | [little endian] ... | [little endian] | [big endian] other typos exist: | Q [unsigned long ong (quad)] and it includes literal \x00 in the docstring, where they should probably have been entered as \\x00, or the docstring should have been made a raw string. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-impacket depends on: ii python 2.7.3-4 ii python-support 1.0.15 Versions of packages python-impacket recommends: ii python-pcapy 0.10.8-1 Versions of packages python-impacket suggests: pn python-impacket-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702912: gtk2: overflown toolbar buttons barred from accessibility tools
reassign 702912 libgtk2.0-0 thanks After more experimentation, it appears the problem really is with gtk itself, but only occurs when the relevant button has never been realized. That is, it will happen whenever the app starts with a window size too small to hold the toolbar, and the overflow menu is there from the start. This is easily reproduced with the first toolbar example found by google [1], by changing the initial windiw with to 100. If I navigate with accerciser to the Save button and trigger its click action, I even get 3 consecutive occurences of the assertion: (foo:22253): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed (foo:22253): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed (foo:22253): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed [1] http://zetcode.com/tutorials/gtktutorial/menusandtoolbars/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702912: gtk2: overflown toolbar buttons barred from accessibility tools
Package: python-gtk2 Version: 2.24.0-3+b1 Severity: normal When a toolbar's parent is not big enough, some items are available to the user through the overflow menu. But for tools using the accessibility feature (for UI testing, or to allow the disabled to use computer programs), the arrow used by a normal user to get the overflow menu is not visible through AT-SPI. The accessibility client accesses all buttons that are children of the toolbar, and can trigger click actions on them, even on those not shown on screen (which can be distinguished though AT-SPI as not exhibiting the showing state). When the action is triggered this way on a non-showing button, standard Gtk apps work correctly (executing the action as normal), as I could test with eg. gnumeric, geany and gschem. But when doing so on an app using pygtk, it causes the following error: GtkWarning: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed gtk.main() At first I thought it would be a gtk issue, but the success with C apps makes me think the problem is rather on pygtk side. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgtk2.0-0 depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libcomerr2 1.42.5-1 ii libcups21.5.3-2.15 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgcrypt11 1.5.0-5 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgnutls26 2.12.20-4 ii libgssapi-krb5-21.10.1+dfsg-4 ii libgtk2.0-common2.24.10-2 ii libk5crypto31.10.1+dfsg-4 ii libkrb5-3 1.10.1+dfsg-4 ii libpango1.0-0 1.30.0-1 ii libx11-62:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxcursor1 1:1.1.13-1 ii libxdamage1 1:1.1.3-2 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.1-1 ii libxinerama12:1.1.2-1 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.7-1 ii multiarch-support 2.13-38 ii shared-mime-info1.0-1+b1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages libgtk2.0-0 recommends: ii hicolor-icon-theme 0.12-1 ii libgtk2.0-bin 2.24.17-1 Versions of packages libgtk2.0-0 suggests: ii gvfs 1.12.3-4 ii librsvg2-common 2.36.1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702913: emacs23: gtk toolbar not visible to accessibility clients
Package: emacs23 Version: 23.4+1-4 Severity: normal When eg. looking at emacs23 through accerciser, one can only see the menu bar and the panel used for buffers, as children of the main window. The toolbar, even when not hidden, does not appear, despite looking like a standard Gtk toolbar. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.4+1-4 ii gconf-service 3.2.5-1+build1 ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgconf-2-43.2.5-1+build1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgif4 4.1.6-10 ii libglib2.0-02.33.12+really2.32.4-5 ii libgpm2 1.20.4-6 ii libgtk2.0-0 2.24.17-1 ii libice6 2:1.0.8-2 ii libjpeg88d-1 ii libm17n-0 1.6.3-2 ii libncurses5 5.9-10 ii libotf0 0.9.12-2 ii libpango1.0-0 1.30.0-1 ii libpng12-0 1.2.49-1 ii librsvg2-2 2.36.1-1 ii libsm6 2:1.2.1-2 ii libtiff43.9.6-11 ii libtinfo5 5.9-10 ii libx11-62:1.5.0-1 ii libxft2 2.3.1-1 ii libxpm4 1:3.5.10-1 ii libxrender1 1:0.9.7-1 ii zlib1g 1:1.2.7.dfsg-13 emacs23 recommends no packages. Versions of packages emacs23 suggests: pn emacs23-common-non-dfsg none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699248: bash: displayed completion does not match the words used to complete
Package: bash
Version: 4.2+dfsg-0.1
Take the following simple completion script, not very different from what udisks
ships upstream, but simpler, and showing the same problem:
alias rmount='udisks --mount'
_removables() {
local IFS=$'\n'
_get_comp_words_by_ref cur prev
COMPREPLY=( $(compgen -W $(udisks --enumerate-device-files) -- $cur) )
}
complete -F _removables -o filenames rmount
Note: _get_comp_words_by_ref comes from git, and is used instead of local
cur=${COMP_WORDS[COMP_CWORD]}
in case the problem would have been Bug#601632, but does not appear to change
anything.
If I hit TAB after entering rmount , I do get the /dev/ unique prefix
completed,
and if I enter myself eg. dis + TAB, I get /dev/disks/by-. But if after
/dev/ I
hit TAB twice to see the available completions, I get shown only the basenames
of the
files, which happen to be correct for eg /dev/sd*, but is completely wrong for
/dev/disks/*,
as follows:
$ rmount /dev/
ata-XXX_XX
dm-1
ata-XXX_XX-part1
dm-2
ata-XXX_XX-part2
nbd0
[...]
dm-0
sr0
$ rmount /dev/
--
Yann Dirson - Bertin Technologies
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694945: foomatic: cannot get PPD for Canon-PIXMA-iP3000 and many others
On Tue, Dec 04, 2012 at 10:23:23AM +, Roger Leigh wrote: On Mon, Dec 03, 2012 at 08:38:17PM +0100, Yann Dirson wrote: On Mon, Dec 03, 2012 at 12:49:53AM +, Roger Leigh wrote: On Sun, Dec 02, 2012 at 04:45:07PM +0100, Yann Dirson wrote: Package: foomatic-db-engine Version: 4.0.8-3 Severity: normal There are apparently 3 CUPS drivers in Debian for the Pixma iP3000: gutenprint.5.2://bjc-PIXMA-iP3000/expert foomatic:Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd foomatic:Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd I have no idea why CUPS is using foomatic drivers here. The native CUPS driver is preferred. It was a test I wanted to do, to check if the foomatic one would support features not found in the gutenprint one (notably head cleaning) It's exactly the same driver, just using the foomatic/ijsgutenprint/ijs/gs workflow instead of the native CUPS driver. It's really only useful for people using non-CUPS spoolers like LPRng. It would be much less effort for the other spoolers to just support using CUPS filters! The foomatic stuff for gutenprint appears to break reasonably often--at least, that's the impression I get from the bug reports. Ah ok. [somewhat off-topic wrt to the bug subject] Maybe there could be some way to make this more obvious at first sight - I mean even if the foomatic-based chain gets removed from CUPS, if it stays for other spoolers maybe some wordings could be improved to make it clear they are not completely different (eg. so people not entirely satisfied with the cups driver don't go configuring lprng to check whether the foomatic driver is any better). Maybe what's missing would be something like identifying in driver package descriptions what protocol is used to talk to those drivers, maybe what other packages ship the same drivers for a different protocol (if such a situation exists), and identifying protocol adapters as such ? I admit I'm a bit lost between foomatic-db (which advertises working with CUPS, but if I understand you well should usually not be chosen for this use case), openprinting-ppds (which tells when you don't need the package but not when you need it), and printer-driver-* (not all of which tell they target CUPS). Ugh :) Well, I can't tell if there are printers for which they are useful. But there are definitely things that could be improved, like making sure drivers for a single printer sort close enough in the list :) I thought that it was ordered by manufacturer/model, with the driver in parentheses following (at least in the web UI). There are different separators (spaces fro gutenprint vs. hyphens for foomatic ones), which cause them to be grouped separately. ie. Canon PIXMA iP3000 - CUPS+Gutenprint v5.2.9 Canon PIXMA iP3100 - CUPS+Gutenprint v5.2.9 ... Canon PIXMA MX ... ... then only after many more lines: ... Canon PIXMA-iP3000 Foomatic/gutenprint-ijs.5.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694945: foomatic: cannot get PPD for Canon-PIXMA-iP3000 and many others
On Mon, Dec 03, 2012 at 12:49:53AM +, Roger Leigh wrote: On Sun, Dec 02, 2012 at 04:45:07PM +0100, Yann Dirson wrote: Package: foomatic-db-engine Version: 4.0.8-3 Severity: normal There are apparently 3 CUPS drivers in Debian for the Pixma iP3000: gutenprint.5.2://bjc-PIXMA-iP3000/expert foomatic:Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd foomatic:Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd I have no idea why CUPS is using foomatic drivers here. The native CUPS driver is preferred. It was a test I wanted to do, to check if the foomatic one would support features not found in the gutenprint one (notably head cleaning) Do you have the ijsgutenprint package installed? yes I'm afraid I can't help with the specifics of the foomatic issue itself since I'm not a foomatic expert. [Given the pain they cause, it might be best to remove the gutenprint foomatic packages entirely for jessie.] Well, I can't tell if there are printers for which they are useful. But there are definitely things that could be improved, like making sure drivers for a single printer sort close enough in the list :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694945: foomatic: cannot get PPD for Canon-PIXMA-iP3000 and many others
Package: foomatic-db-engine Version: 4.0.8-3 Severity: normal There are apparently 3 CUPS drivers in Debian for the Pixma iP3000: gutenprint.5.2://bjc-PIXMA-iP3000/expert foomatic:Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd foomatic:Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd If I try to use one of the latter two in CUPS, I get the following errors when selecting them from the Web UI (here copied from cups/error_log): E [02/Dec/2012:16:10:17 +0100] [CGI] Could not determine driver name for Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd! E [02/Dec/2012:16:10:17 +0100] copy_model: empty PPD file E [02/Dec/2012:16:10:17 +0100] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/Canon_iP3000_gutenprint_ijs) from localhost E [02/Dec/2012:16:10:23 +0100] [CGI] Could not determine driver name for Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd! E [02/Dec/2012:16:10:23 +0100] copy_model: empty PPD file E [02/Dec/2012:16:10:23 +0100] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/Canon_iP3000_gutenprint_ijs) from localhost The problem seems to come from /usr/lib/cups/driver/foomatic itself - whereas .../foomatic cat drv works with drivers that specify a last field with many info (MFG, etc), there seems to be a problem with those that only show DRV there, which seem to be all those shown by /usr/lib/cups/driver/foomatic list | grep -v MFG # /usr/lib/cups/driver/foomatic list | grep -i ip3000 foomatic:Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd en Canon Canon PIXMA-iP3000 Foomatic/gutenprint-ijs.5.2 DRV:Dgutenprint-ijs.5.2,M0,TF; foomatic:Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd en Canon Canon PIXMA-iP3000 Foomatic/gutenprint-ijs-simplified.5.2 DRV:Dgutenprint-ijs-simplified.5.2,M0,TF; # /usr/lib/cups/driver/foomatic cat foomatic:Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd ERROR: Could not determine driver name for Canon-PIXMA-iP3000-gutenprint-ijs.5.2.ppd! # /usr/lib/cups/driver/foomatic cat foomatic:Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd ERROR: Could not determine driver name for Canon-PIXMA-iP3000-gutenprint-ijs-simplified.5.2.ppd! # /usr/lib/cups/driver/foomatic cat foomatic:Epson-PictureMate_260-gutenprint-ijs.5.2.ppd|head -1 ERROR: Could not determine driver name for Epson-PictureMate_260-gutenprint-ijs.5.2.ppd! # /usr/lib/cups/driver/foomatic cat foomatic:Epson-Stylus_T20-gutenprint-ijs.5.2.ppd|head -1 ERROR: Could not determine driver name for Epson-Stylus_T20-gutenprint-ijs.5.2.ppd! ... -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages foomatic-db-engine depends on: ii bash 4.2-4 ii curl 7.26.0-1 ii foomatic-filters 4.0.17-1 ii libc6 2.13-37 ii libxml2 2.8.0+dfsg1-6 ii perl 5.14.2-15 ii wget 1.13.4-3 Versions of packages foomatic-db-engine recommends: ii cups 1.5.3-2.4 ii cups-client 1.5.3-2.4 ii foomatic-db 20120523-1 ii netcat-traditional [netcat] 1.10-40 Versions of packages foomatic-db-engine suggests: ii foomatic-db-gutenprint 5.2.9-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693257: wine and win-unstable conflict over manpages
Package: libwine-bin Version: 1.4.1-4 Severity: serious Unpacking libwine (from .../libwine_1.4.1-4_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libwine_1.4.1-4_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/wineserver.1.gz', which is also in package libwine-unstable:i386 1.5.6-2 Selecting previously unselected package libwine-bin:i386. Unpacking libwine-bin:i386 (from .../libwine-bin_1.4.1-4_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libwine-bin_1.4.1-4_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/regedit.1.gz', which is also in package libwine-bin-unstable:i386 1.5.6-2 Selecting previously unselected package wine-bin. Unpacking wine-bin (from .../wine-bin_1.4.1-4_i386.deb) ... dpkg: error processing /var/cache/apt/archives/wine-bin_1.4.1-4_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/wine-safe.1.gz', which is also in package wine-bin-unstable 1.5.6-2 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libwine-bin depends on: ii libc62.13-35 ii libncurses5 5.9-10 ii libtinfo55.9-10 pn libwine none libwine-bin recommends no packages. libwine-bin suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692514: skrooge: after import of a OFX account in EURO, amounts displayed as DOLLARS
Package: skrooge Version: 1.3.0-1 Severity: important The OFX file provided by my bank is in euro (and at least grisbi seems to correctly import it), but after import, the operations are all shown with US dollar as unit (which obviously gives wrong values). Quite strange, as the original balance imported from the same file is claimed to be in euros. FWIW, the OFX file has the following lines, which I interpret as declaring the EUR currency correctly: STMTRS CURDEFEUR -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages skrooge depends on: ii kde-runtime 4:4.8.4-2 ii libc62.13-35 ii libgcc1 1:4.7.1-7 ii libgrantlee-core00.1.4-1 ii libkdecore5 4:4.8.4-4 ii libkdeui54:4.8.4-4 ii libkio5 4:4.8.4-4 ii libknewstuff3-4 4:4.8.4-4 ii libkparts4 4:4.8.4-4 ii libkrosscore44:4.8.4-4 ii libnepomuk4 4:4.8.4-4 ii libnepomukutils4 4:4.8.4-4 ii libofx4 1:0.9.4-2.1 ii libplasma3 4:4.8.4-4 ii libqca2 2.0.3-4 ii libqca2-plugin-ossl 2.0.0~beta3-2 ii libqt4-dbus 4:4.8.2+dfsg-2 ii libqt4-network 4:4.8.2+dfsg-2 ii libqt4-script4:4.8.2+dfsg-2 ii libqt4-sql 4:4.8.2+dfsg-2 ii libqt4-sql-sqlite4:4.8.2+dfsg-2 ii libqt4-svg 4:4.8.2+dfsg-2 ii libqt4-xml 4:4.8.2+dfsg-2 ii libqtcore4 4:4.8.2+dfsg-2 ii libqtgui44:4.8.2+dfsg-2 ii libqtwebkit4 2.2.1-4+b1 ii libsoprano4 2.7.6+dfsg.1-1 ii libstdc++6 4.7.1-7 ii skrooge-common 1.3.0-1 skrooge recommends no packages. skrooge suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692515: homebank: OFX import interprets euros as million units
Package: homebank Version: 4.4-1 Severity: important My bank-provided OFX file has transaction ammounts correctly interpreted by at least grisbi, but for some reason homebank multiplies them by 1e6, which is highly disturbing. Example entry causing a claim that I was credited with 3000: STMTTRN TRNTYPEOTHER DTPOSTED20120803 TRNAMT+30.00 FITIDx NAME MEMOVIREMENT EN VOTRE FAVEUR /STMTTRN I am not even sure it really thinks these are million euros, since there is no unit in the displayed balance or apprently in any listing. Only if I activate euro mode and handcraft a euro currency with a rate of 1, do I get units displayed... and that time the amounts are correct. WTF !? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages homebank depends on: ii homebank-data 4.4-1 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libofx4 1:0.9.4-2.1 ii libpango1.0-0 1.30.0-1 Versions of packages homebank recommends: ii librsvg2-common 2.36.1-1 homebank suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692517: homebank: example file not shipped, I/O error reported to the user
Package: homebank Version: 4.4-1 Severity: normal When I click on Open the example file in the welcome dialog, I am told by a dialog: I/O error for file /usr/share/homebank/datas/example.xhb. This file is apparently not shipped by homebank or -data. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages homebank depends on: ii homebank-data 4.4-1 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libofx4 1:0.9.4-2.1 ii libpango1.0-0 1.30.0-1 Versions of packages homebank recommends: ii librsvg2-common 2.36.1-1 homebank suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690811: cairo-dock: segfault at startup after several failed assertions
Package: cairo-dock-core Version: 3.0.0-2 Severity: important Running under openbox, launching cairo-dock to get a look at it just causes a segfault. Nuking .config/cairo-dock and requesting it to disable OpenGL does not help. May be related to those failed assertions it shows first ? Gdb can't say much with a -dbg package to help, here is what I get: $ gdb cairo-dock ... Reading symbols from /usr/bin/cairo-dock...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/cairo-dock [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. WARNING: gnome-keyring:: couldn't connect to: /home/yann/.cache/keyring-QwVzYn/pkcs11: No such file or directory warning : (/tmp/buildd/cairo-dock-3.0.0/src/gldit/cairo-dock-opengl.c:cairo_dock_initialize_opengl_backend:209) couldn't find an appropriate visual, trying to get one without Stencil buffer (it may cause some little deterioration in the rendering) ... [New Thread 0x7fffeab10700 (LWP 20771)] Cairo-Dock version : 3.0.0 Compiled date : May 20 2012 12:27:29 Built with GTK : 3.4 Running with OpenGL: 0 _cairo_dock_create_surface_from_desktop_bg: assertion `iRootPixmapID != 0' failed warning : (/build/buildd-cairo-dock-plug-ins_3.0.0-1+b1-amd64-lfC_Cf/cairo-dock-plug-ins-3.0.0/switcher/src/applet-load-icons.c:cd_switcher_load_desktop_bg_map_surface:196) couldn't get the wallpaper cairo_dock_create_surface_from_image_simple: assertion `cImageFile != NULL' failed cairo_dock_create_surface_from_image_simple: assertion `cImageFile != NULL' failed Program received signal SIGSEGV, Segmentation fault. 0x734ca729 in cairo_dock_new_dialog () from /usr/lib/libgldi.so.3 (gdb) bt #0 0x734ca729 in cairo_dock_new_dialog () from /usr/lib/libgldi.so.3 #1 0x734cdd4a in cairo_dock_build_dialog () from /usr/lib/libgldi.so.3 #2 0x734ce4b4 in cairo_dock_show_dialog_full () from /usr/lib/libgldi.so.3 #3 0x734cea24 in cairo_dock_show_dialog_and_wait () from /usr/lib/libgldi.so.3 #4 0x00427b9a in cd_help_enable_composite () #5 0x00427e85 in ?? () #6 0x7517ad9b in g_timeout_dispatch (source=source@entry=0xb30190, callback=optimized out, user_data=optimized out) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3882 #7 0x7517a205 in g_main_dispatch (context=0x680400) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:2539 #8 g_main_context_dispatch (context=context@entry=0x680400) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3075 #9 0x7517a538 in g_main_context_iterate (context=0x680400, block=block@entry=1, dispatch=dispatch@entry=1, self=error reading variable: Unhandled dwarf expression opcode 0xfa) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3146 #10 0x7517a932 in g_main_loop_run (loop=0xa31800) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3340 #11 0x749c22e5 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #12 0x004102c5 in main () (gdb) q -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cairo-dock-core depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo-gobject2 1.12.2-2 ii libcairo2 1.12.2-2 ii libcurl3-gnutls 7.26.0-1 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.4-2 ii libglib2.0-0 2.32.3-1 ii libglu1-mesa [libglu1]8.0.4-2 ii libgtk-3-03.4.2-4 ii libpango1.0-0 1.30.0-1 ii librsvg2-22.36.1-1 ii libx11-6 2:1.5.0-1 ii libxcomposite11:0.4.3-2 ii libxinerama1 2:1.1.2-1 ii libxml2 2.8.0+dfsg1-6 ii libxrender1 1:0.9.7-1 ii libxtst6 2:1.2.1-1 Versions of packages cairo-dock-core recommends: pn cairo-dock-plugins none ii curl7.26.0-1 Versions of packages cairo-dock-core suggests: pn empathynone pn f-spot none pn gcalctool none ii gimp 2.8.2-1 ii inkscape 0.48.3.1-1.1 pn xcompmgr none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689006: gthumb: recommandation of bison/flex should at least be explained in package description, or webalbums plugin split
Package: gthumb Version: 3:3.0.1-2 bison and flex are so unrelated to the usage of an image viewer that a bit of a note about what they could be useful for in this context is the miminum we owe to our users. Given that, according to the changelog, only a webalbums plugin needs them (leaving me wondering why the hell it does...), it would IMHO make sense to split the offending plugin out, and possibly only have gthumb suggest it. -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688506: apt-listbugs: should show package arch when listing bugs
Package: apt-listbugs Version: 0.1.7 Severity: important It is quite confusing when multiarch is enabled, to have apt-listbugs forget to mention which arch it's talking about. In my case, I just added i386 as foreign arch to be able to install wine on an amd64 box. Then apt-listbugs complains about RC bugs impacting the i386 packages, but I have no way to tell: * whether we're talking about an i386 or amd64 package * whether impacted package already has a version for an other arch already installed -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt-listbugs depends on: ii apt0.8.15.10 ii libgettext-ruby1.8 2.2.1-2 ii libruby1.8 [libzlib-ruby1.8] 1.8.7.358-4 ii ruby-debian0.3.8+b1 ii ruby-gettext [libgettext-ruby1.8] 2.2.1-2 ii ruby-httpclient2.2.4-2 ii ruby-xmlparser 0.7.2-2 ii ruby1.81.8.7.358-4 apt-listbugs recommends no packages. Versions of packages apt-listbugs suggests: ii chromium [www-browser] 21.0.1180.89~r154005-1 ii debianutils 4.3.2 ii elinks [www-browser] 0.12~pre5-8 ii iceweasel [www-browser] 10.0.7esr-2 ii links2 [www-browser] 2.7-1 ii lynx-cur [www-browser] 2.8.8dev.12-2 ii reportbug6.4.3 ii uzbl [www-browser] 0.0.0~git.20120514-1 ii w3m [www-browser]0.5.3-8 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688506: apt-listbugs: should show package arch when listing bugs
On Sun, Sep 23, 2012 at 08:04:35PM +0200, Francesco Poli wrote: Control: severity -1 normal On Sun, 23 Sep 2012 19:43:57 +0200 Francesco Poli wrote: On Sun, 23 Sep 2012 11:54:52 +0200 Yann Dirson wrote: [...] Severity: important [...] (unless it fixes a release critical bug, but this one is definitely not RC). By the way, I think the severity of your report is a bit inflated. This bug does not have a major effect on the usability of apt-listbugs. Well, given that multi-arch is a release goal for wheezy, we're entering a blurry domain here :) I guess a level 0 support, like using the arch qualified package name (or whatever the exact term is - that is, libfoo:i386 instead of just libfoo, probably an info that can be queried from dpkg with little change), could be something not too intrusive to add, and which would even have the potential to be accepted into wheezy as participating to the release goal ? It could even be considered wishlist, since, so far, supporting multiarch is something that apt-listbugs has never attempted to do. Hence, this looks like a request for a new feature. But it's true that, when multiarch is enabled on a box, apt-listbugs works in a less useful manner. That's right, one can still find out the info by other means, it's still not very comfortable, and maybe not something everyone will want to do. Remember the situation which led me to seeing this problem: as it is, apt-listbugs is likely to loose at least some of its usefulness on all amd64 machines on which wine gets installed, since the latter now requires a multiarch setup. HTH, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687922: dash: pattern match failure in case
Package: dash Version: 0.5.7.3 $ dash -c 'case foo-rev0 in *-rev*[^0-9]*) echo boom;; esac' boom Problem seen in 0.5.5.1-3ubuntu2, still present in wheezy. All other tested shells (bas, zsh) behave as expected, only dash seems to think there is a non-numeral somewhere after -rev. -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Fri, Sep 07, 2012 at 12:41:36PM +0800, Daniel Hartwig wrote: Yann Dirson ydir...@free.fr wrote: I have many sources.list entries, and only want selected ones to take armel packages into account. The new [arch=] tag seems tailored for this, but then, APT::Architectures defaults to all foreign archs Hello Just following up on your experiences mentioned in this report and the related ones. It seems as though you were incorrectly using APT::Architectures and [arch=]. To be precise, the recommended configuration for the situation in your original report is: $ dpkg --print-architecture amd64 $ dpkg --print-foreign-architectures armel $ apt-config dump | grep -i ^APT::Architecture APT::Architecture amd64; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: armel; $ cat /etc/apt/sources.list deb [arch=amd64] ftp://ftp.debian.org/debian testing main deb ftp://ftp.debian.org/debian squeeze main Which I think you eventually implemented. It is important that APT::Architectures contains an entry for every architecture of an installed package. I understand that, while trying to sort this out, you removed armel from APT::Architectures and proceeded with an upgrade which caused some problems with libc6 on this system. That issue is tracked as #670668: apt is unaware of installed packages whose architecture is not in APT::Architectures. Did you ever recover your system from the libc6 issue? (Please do not close #670668 as the issue still applies to apt generally.) Yes, I eventually purged all remaining armel packages, as they prevented upgrades of the amd64 ones. Also, are you now using the correct configuration mentioned above (or something similar) No, since in fact the setup was not really adapted to my needs. and does this work as you expected? If so, I believe we can close this bug (#670322). Well, the only thing left I can think of, is that on a setup where I have a large number of apt sources, but only want a small subset of them to pick armel packages from, I cannot just tag them as such, but have to tag the large number as not taking them, precisely by *not* mentionning them in the [arch=] list. This is pretty much verbose and IMHO unintuitive. Maybe we could be have a DefaultSourceListArchs setting of some sort, which would default to the APT::Architectures list, but could be overriden to a subset thereof to eventually exclude the foreign arch by default, and be overriden per-line to re-enable it ? (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Ah cool, but my original note was based on misunderstanding of the feature: I cannot have different versions of a single package for different archs (which is in fact why the setup was not really adapted to my needs - I needed a chroot anyway) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682211: wheezy installation report: some rough edges
Subject: installation-reports: d630 Package: installation-reports Severity: normal (sorry for lack of logs, sending from different machine) -- Package-specific info: Boot method: Image version: http://cdimage.debian.org/cdimage/wheezy_di_alpha1/i386/iso-cd/debian-wheezy-DI-a1-i386-netinst.iso 12-May-2012 02:45 Date: Date and time of the install Machine: Dell Latitude D630 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [ ] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Install tasks: [E] Install boot loader:[O] Overall install:[O] Comments/Problems: * If I leave the domain field empty in the hostname selection screen, resolv.conf expectedly only gets a nameserver line, and the resolver does not resolve my (non-fully-qualified) proxy name. Although it is normal, I have to switch to tty4, where the log just tell that the mirror does not carry wheezy (sic). * I do not remember any prompt telling me to check time, but TZ is correctly set * when partitionning (assisted lvm), double clicking on a partition to see details, then back to main screen, the partition is still selected and clicking on continue unexpectedly just enters the same partition-editing dialogs again * only a single task to be selected in the installer (standard system utilities), probably why no desktop env has been installed (selected XFCE) * selecting task-french, task-french-desktop, task-xfce triggers conflict between - myspell-fr and myspell-fr-gut - hunspell-en-us and myspell-en-us * I would have expected http_proxy to be propagated to /etc/environment, not just to apt.conf (although for a laptop it is probably better not to do that) Those seem to be problems of the package versions on install CD, but fixed in current wheezy: * no extended package descriptions are downloaded by apt on first update after install, only on second update * aptitude with french l10n does not translate yes/no to oui/non in confirmation dialogs, but does it only accepts o instead of y (not any more after upgrade ?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680084: postinst script gets stuck
On Wed, Jul 04, 2012 at 08:48:59AM +0200, Harald Dunkel wrote: On 07/03/12 23:57, Yann Dirson wrote: This seems to show the debconf frontend script not dealing handling the termination of the memtest86+.postinst script. If any, it seems more plausible that the bug would be in debconf. Which debconf version is this ? Are you running squeeze or sid ? Testing. debconf is version 1.5.45 If I run dpkg-reconfigure memtest86+ here (wheezy/amd64), however, things go perfectly fine: | Generating grub.cfg ... | Found background image: /usr/share/images/desktop-base/desktop-grub.png | Found linux image: /boot/vmlinuz-3.2.0-2-amd64 | Found initrd image: /boot/initrd.img-3.2.0-2-amd64 [...] | Found memtest86 image: /memtest86.bin | Found memtest86+ image: /memtest86+.bin | Found memtest86+ multiboot image: /memtest86+_multiboot.bin | done | root# It would be interesting to know what the frontend process is doing when that happens. Can you retry, and show 1. the output of ps l pid root@ppcl007:~# ps l 3648 F UID PID PPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND 0 0 3648 3636 20 0 50532 11132 - S+ pts/1 0:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/memtest86+.postinst configure 2. the output of strace -p pid root@ppcl007:~# strace -p 3648 Process 3648 attached - interrupt to quit read(11, In that case, we'll need to know what's hidden behind file descriptor 11. You can use ls -l /proc/pid/fd/ to find out. You can also get info from debconf itself. Setting DEBCONF_DEBUG=developer while running dpkg can help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680084: postinst script gets stuck
On Tue, Jul 03, 2012 at 03:21:33PM +0200, Harald Dunkel wrote: The postinst script gets stuck on builing grub.cfg: : Selecting previously unselected package memtest86+. (Reading database ... 29792 files and directories currently installed.) Unpacking memtest86+ (from .../memtest86+_4.20-1.1_amd64.deb) ... Setting up memtest86+ (4.20-1.1) ... Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.2.0-3-amd64 Found initrd image: /boot/initrd.img-3.2.0-3-amd64 Found linux image: /boot/vmlinuz-3.2.0-0.bpo.2-amd64 Found initrd image: /boot/initrd.img-3.2.0-0.bpo.2-amd64 Found linux image: /boot/vmlinuz-2.6.32-5-amd64 Found initrd image: /boot/initrd.img-2.6.32-5-amd64 Found memtest86+ image: /memtest86+.bin Found memtest86+ multiboot image: /memtest86+_multiboot.bin File descriptor 3 (pipe:[7342]) leaked on lvs invocation. Parent PID 2698: /bin/sh grub-probe: error: no such disk. done done is the last line. ps -ef shows: ... root 2206 2202 0 14:58 pts/000:00:02 | \_ aptitude root 2252 2206 0 14:59 pts/100:00:00 | \_ /usr/bin/dpkg --status-fd 23 --configure memtest86+:amd64 root 2253 2252 0 14:59 pts/100:00:00 | \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/memtest86+.postinst configure root 2259 2253 0 14:59 pts/100:00:00 | \_ [memtest86+.post] defunct This seems to show the debconf frontend script not dealing handling the termination of the memtest86+.postinst script. If any, it seems more plausible that the bug would be in debconf. Which debconf version is this ? Are you running squeeze or sid ? If I run dpkg-reconfigure memtest86+ here (wheezy/amd64), however, things go perfectly fine: | Generating grub.cfg ... | Found background image: /usr/share/images/desktop-base/desktop-grub.png | Found linux image: /boot/vmlinuz-3.2.0-2-amd64 | Found initrd image: /boot/initrd.img-3.2.0-2-amd64 [...] | Found memtest86 image: /memtest86.bin | Found memtest86+ image: /memtest86+.bin | Found memtest86+ multiboot image: /memtest86+_multiboot.bin | done | root# It would be interesting to know what the frontend process is doing when that happens. Can you retry, and show 1. the output of ps l pid 2. the output of strace -p pid -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678324: glib2.0-dev: changes from 2.30.2 to 2.32.3 cause undeclared compatibility breakage for Qt
Package: libglib2.0-dev Version: 2.32.3-1 X-Debbugs-Cc: qt4-...@packages.debian.org For various reason I have for now postponned upgrading glib on my wheezy box, and it is still at 2.30.2-6. In this situation, the qbuild program fails to work (it is built and tested by the ./configure script from qtmoko, most easily found via git://github.com/radekp/qtmoko.git). Now for the details: * qbuild uses QtCore. With the 4.8.0-1 Qt packages from experimental, things were fine, but with the 4.8.1 and 4.8.2 packages things break - in fact, the test run does nearly work, but the program stays stuck waiting for a QWaitCondition, while the GLib main loop is polling. * if I use a set of Qt 4.8.2 packages, rebuilt on the samemachine, or if I run this test with QT_NO_GLIB=1, it does work fine. If I rebuild Qt in a sid chroot, the resulting packages do show the qbuild test lockup. If I just downgrade glib2.0-dev and the handful of packages that must be downgraded with it, in this chroot, the resulting packages DO NOT show the qbuild test lockup. The conclusion seems to be that something in libglib2.0-dev changed between 2.30.2 and 2.32.3, likely in header files, and related to g_main_loop, which is causing this breakage, and that somehow packages built against newer versions of glib (Qt in this case) should have inherited tighter versionned dependencies against glib in one way or another. But this may also come from an unwanted change in glib or another component, glib is just the most likely culprit at this point... -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armel Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libglib2.0-dev depends on: ii libc6 2.13-33 ii libglib2.0-02.30.2-6 ii libglib2.0-bin 2.30.2-6 ii pkg-config 0.26-1 ii zlib1g-dev 1:1.2.7.dfsg-11 Versions of packages libglib2.0-dev recommends: ii python 2.7.3~rc2-1 Versions of packages libglib2.0-dev suggests: pn libglib2.0-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678207: screen: (uncaught) compare-version errors at install
Package: screen Version: 4.1.0~20120320gitdb59704-3 Severity: serious See below install log in a pbuilder sid chroot. At the very least, $2 is used unquoted in debconf script. # aptitude install screen The following NEW packages will be installed: screen 0 packages upgraded, 1 newly installed, 0 to remove and 23 not upgraded. Need to get 670 kB of archives. After unpacking 984 kB will be used. Get: 1 ftp://ftp.debian.org/debian/ sid/main screen amd64 4.1.0~20120320gitdb59704-3 [670 kB] Fetched 670 kB in 1s (522 kB/s) Preconfiguring packages ... dpkg: error: --compare-versions takes three arguments: version relation version Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! Selecting previously unselected package screen. (Reading database ... 22422 files and directories currently installed.) Unpacking screen (from .../screen_4.1.0~20120320gitdb59704-3_amd64.deb) ... dpkg: error: --compare-versions takes three arguments: version relation version Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! Processing triggers for install-info ... Processing triggers for man-db ... Setting up screen (4.1.0~20120320gitdb59704-3) ... dpkg: error: --compare-versions takes three arguments: version relation version Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! root@home:/tmp/buildd# -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armel Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages screen depends on: ii dpkg 1.16.3 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-33 ii libncursesw5 5.9-8 ii libpam0g 1.1.3-7.1 screen recommends no packages. screen suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677656: Acknowledgement (qt4-x11: FTBFS when armel is declared as foreign arch)
To be complete, there is obviously another part of debian/rules that causes problems (which I had missed at first because I had commented out opengl flags completely): in the same way, -opengl es2 is passed to configure. ifeq ($(vendor),Ubuntu) gles2_architectures := armel armhf else gles2_architectures := none_for_now endif ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(gles2_architectures))) extra_configure_opts += -opengl es2 else extra_configure_opts += -opengl desktop \ -no-egl endif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677725: thunar: deleting files on removable media uses a trash with no command to empty it
Package: thunar Version: 1.2.3-3 Severity: normal Managing files on removable media is quite awkward: when files are deleted from thunar, they are just moved to a .Trash-$UID at the root of the media, similarly to what's done in the user's home dir. But in this case, there is no per-removable trash icon to see what's trashed and purge it. There is no empty removable media's trash command in context menu either. Heavy user of Thunar, have to use a workaround, like using cut-and-paste to their home/desktop/whatever, and use delete file from there - quite awkward, really :} -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages thunar depends on: ii desktop-file-utils 0.18-1 ii exo-utils 0.6.2-4 ii libatk1.0-0 2.2.0-2 ii libc6 2.13-33 ii libcairo2 1.12.2-1 ii libdbus-1-3 1.5.12-1 ii libdbus-glib-1-20.98-1 ii libexo-1-0 0.6.2-4 ii libgdk-pixbuf2.0-0 2.24.1-1 ii libglib2.0-02.30.2-6 ii libgtk2.0-0 2.24.10-1 ii libgudev-1.0-0 175-3.1 ii libice6 2:1.0.8-2 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.29.4-3+b1 ii libsm6 2:1.2.1-2 ii libthunarx-2-0 1.2.3-3 ii libxfce4ui-1-0 4.8.1-1 ii libxfce4util4 4.8.2-1 ii shared-mime-info0.90-1.1 ii thunar-data 1.2.3-3 Versions of packages thunar recommends: ii dbus-x111.5.12-1 ii gvfs1.10.1-2+b1 ii libfontconfig1 2.9.0-6 ii libfreetype62.4.9-1 ii thunar-volman 0.6.1-1 ii tumbler 0.1.24-1 ii xdg-user-dirs 0.14-1 ii xfce4-panel 4.8.6-3 Versions of packages thunar suggests: pn thunar-archive-plugin none pn thunar-media-tags-plugin none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677725: [Pkg-xfce-devel] Bug#677725: thunar: deleting files on removable media uses a trash with no command to empty it
On Sat, Jun 16, 2012 at 04:03:45PM +0200, Yves-Alexis Perez wrote: On sam., 2012-06-16 at 15:35 +0200, Yann Dirson wrote: Package: thunar Version: 1.2.3-3 Severity: normal Managing files on removable media is quite awkward: when files are deleted from thunar, they are just moved to a .Trash-$UID at the root of the media, similarly to what's done in the user's home dir. But in this case, there is no per-removable trash icon to see what's trashed and purge it. There is no empty removable media's trash command in context menu either. Heavy user of Thunar, have to use a workaround, like using cut-and-paste to their home/desktop/whatever, and use delete file from there - quite awkward, really :} Just empty the trash? Empty the trash from the trash's context menu only empties the trash located in the user's homedir, not any of the trashes on removable media - at least, not the in which Thunar moves deleted stuff on removable media... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677656: qt4-x11: FTBFS when armel is declared as foreign arch
Source: qt4-x11 Version: 4:4.8.2-1 Severity: important The following lines cause -arch armv6 to be used, on my amd64 box where armel is declared as foriegn arch. Now I'm not really sure why, since dpkg-architecture does not report it at all. Not sure about the severity either, but this may count as part of the multiarch release goal... ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(armv6_architectures))) extra_configure_opts += -arch armv6 endif -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675607: ltrace: new upstream version available
Package: ltrace Version: 0.5.3-2.1 Severity: normal Current version is damn old, even 0.6.0 has been out for a long time. Looking at the PTS, we may have to consider Juan MIA ? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ltrace depends on: ii libc6 2.13-32 ii libelfg0 0.8.13-3 ltrace recommends no packages. ltrace suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Wed, May 30, 2012 at 08:33:47AM +0200, Maarten Lankhorst wrote:
The current situation just makes some people (eg. me ;) break the
dependency link that's the weakest to get rid of useless drivers, with
the results described in my original report.
What are you gaining?
$ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls
-lh $f; fi; done|awk '{print $5}'
110K
5.1K
676
6.0K
117K
2.2K
27
If I check the Policy about Depends, This declares an absolute
dependency, which is clearly not the case here. Even the official
definition of Recommends makes me wonder if it would not be too
strong. After all, someone with a radeon is likely to select the
readon driver, then the ati wrapper will be selected as Recommended,
but the latter should IMHO have no reason to pull mach64 and r128,
that would not fit the packages that would be found together with
this one in all but unusual installations criteria.
The current situation ensures that X works by default. People can still
select this or that driver manually as explained previously, so it looks
to me like the current relationships are fine (and have been for I think
many years).
At least downgrading to Recommends would keep things working by
default. And even downgrading to Suggests, together with -all
depending on {radeon,r128,mach64}, would keep things working by
default - while allowing those who don't want extra stuff to avoid
cruft.
The extra cruft of a few 100kb? Make your own xorg.conf and remove ati.
You'll sacrifice auto config but whatever is more important to you. :-)
The problem is, I still do not see why the small changes I propose
would not work, and thus I don't see the need for whatever sacrifice
of the auto config feature.
If there are any arguments that I missed against lowering the Depends
of ati against those drivers it knows how to wrap (and I am not saying
there can be no reason, I only have a radeon to test - I'm just
pointing to the lack of arguments, whereas I did my best to find
arguments for my proposal), I'd be glad to see them before I send a patch...
Best regards,
--
Yann
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Tue, May 29, 2012 at 12:02:14AM +0200, Cyril Brulebois wrote:
The dependency in squeeze (and in other suites) is:
ati→{mach64,r128,radeon}
there's no:
radeon→ati
OK, my bad - surely some confusion on my side.
But the result is, GLX is entirely disabled, and we can see a fail to
loat ati messge in the log. Reinstalling them (Xorg.1.log.old
attached) suppresses the message, and shows much better init of
DRI/GLX stuff. Removing again just the -ati package, and those stop
to work again (Xorg.1.log attached).
ati is a wrapper which does the right thing, don't remove it. Or set
radeon as driver in xorg.conf if you insist on doing so (man radeon).
OK I understand that there is no absolute requirement for -ati, and
thus a Depends is probably not a good idea for some users. But for
the vast majority, who will want to use it, what about adding a note
in package descriptions of {mach64,r128,radeon} that the -ati package
is required to avoid manual Xorg configuration ? Adding somewhere the
suggestion to set the driver in xorg.conf (package desc or manpage),
to avoid depending on -ati, would also be a good idea.
Even then, why this Depends of ati on all 3 drivers ? I can dpkg -r
--force-depends both mach64 and r128, and ati+radeon does startup
without complaining at all. Shouldn't this be downgraded to a
Recommends as well ?
The current situation just makes some people (eg. me ;) break the
dependency link that's the weakest to get rid of useless drivers, with
the results described in my original report.
If I check the Policy about Depends, This declares an absolute
dependency, which is clearly not the case here. Even the official
definition of Recommends makes me wonder if it would not be too
strong. After all, someone with a radeon is likely to select the
readon driver, then the ati wrapper will be selected as Recommended,
but the latter should IMHO have no reason to pull mach64 and r128,
that would not fit the packages that would be found together with
this one in all but unusual installations criteria.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674952: xserver-xorg-video-radeon: fails to work properly without -ati
On Tue, May 29, 2012 at 11:45:45PM +0200, Cyril Brulebois wrote:
Even then, why this Depends of ati on all 3 drivers ? I can dpkg -r
--force-depends both mach64 and r128, and ati+radeon does startup
without complaining at all. Shouldn't this be downgraded to a
Recommends as well ?
This is very fine for you. What about mach64 and r128 users? Then we'll
get reports from people turning off Recommends. The usual fine line,
between Depends and Recommends, etc. Depends means being safer.
Well, as users of other video cards, they will be able to select just
the driver for their own card, and not eg. radeon.
The current situation just makes some people (eg. me ;) break the
dependency link that's the weakest to get rid of useless drivers, with
the results described in my original report.
What are you gaining?
$ for f in $(dpkg -L xserver-xorg-video-r128); do if [ -f $f ]; then ls -lh
$f; fi; done|awk '{print $5}'
110K
5.1K
676
6.0K
117K
2.2K
27
If I check the Policy about Depends, This declares an absolute
dependency, which is clearly not the case here. Even the official
definition of Recommends makes me wonder if it would not be too
strong. After all, someone with a radeon is likely to select the
readon driver, then the ati wrapper will be selected as Recommended,
but the latter should IMHO have no reason to pull mach64 and r128,
that would not fit the packages that would be found together with
this one in all but unusual installations criteria.
The current situation ensures that X works by default. People can still
select this or that driver manually as explained previously, so it looks
to me like the current relationships are fine (and have been for I think
many years).
At least downgrading to Recommends would keep things working by
default. And even downgrading to Suggests, together with -all
depending on {radeon,r128,mach64}, would keep things working by
default - while allowing those who don't want extra stuff to avoid
cruft.
Besides that, patches welcome: debcheckout xserver-xorg-video-ati
(mailto: 674...@bugs.debian.org, plus debian-x@ if you want to make sure)
OK :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673297: libxml2 and gzopen64@ZLIB_1.2.3.3 (Was: Please reschedule tagua 1.0~alpha2-10 on armel)
On Sat, May 26, 2012 at 12:32:50PM +0200, Julien Cristau wrote: On Wed, May 23, 2012 at 22:23:11 +0200, Yann Dirson wrote: Prev build was hit by the same problem as http://bugs.debian.org/673297, so it should work now. I guess you meant mips, not armel? Anyway, given back. Right, thanks :) However, looks like the new build attempt failed with the same issue. And https://buildd.debian.org/status/package.php?p=shelxle also shows the same error on other archs. Shouldn't #673297 be reopenned ? Note that according to google, the same libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3' error is not even Debian-specific. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#228227: freedroid: segmentation fault when i try to run it
This is clearly the same problem as described in https://bugs.launchpad.net/ubuntu/+source/freedroid/+bug/387371, which luckily provides a useful backtrace, which in turn points to a format-string argument mismatch. Easily fixed :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674050: latrace: compiled without C++ demangling support
Package: latrace Version: 0.5.11-1 Severity: normal Looks like support for this has been coded, but something is missing (a build dep ? hm, GNU libiberty is usually shipped in the source packages that use it - if it is what it's about) |$ latrace -Ad exiv2 --help|head |demangle support not compiled in, liberty not found |11139 _ZSt15future_categoryv [/usr/lib/x86_64-linux-gnu/libstdc++.so.6] |[...] -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages latrace depends on: ii libc6 2.13-32 latrace recommends no packages. latrace suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#228227: freedroid: segmentation fault when i try to run it
Hi Andrea, Just in case, do you still have this problem ? The root/non-root difference suggests some permission issue, eg. on a sound device, that would not be properly handled at some level (could be eg. a sound device), and maybe the freedroid code is not robust to such a situation. In this case, it could possibly more easily occur with an OSS or direct ALSA setup, but at least does not seem to be a problem with pulseaudio+consolekit, which works with changing permissions on devices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673520: ITA: qgo
Package: wnpp qgo has just been removed from the archive, apparently because of the upcoming removal of Qt3. Support for Qt4 is in unstable, and I intend to take over the package with an svn snapshot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673533: lintian: only one missing-license-paragraph-in-dep5-copyright is detected at a time
Package: lintian Version: 2.5.6 Severity: normal When several License stanzas are missing the detailed paragraph, only one is reported, possibly the last one seen. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.22-6 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.11-1 ii gettext0.18.1.1-7 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libc-bin 2.13-32 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.3 ii libemail-valid-perl0.190-1 ii libipc-run-perl0.91-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii locales2.13-32 ii man-db 2.6.1-2 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-9 ii unzip 6.0-6 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch none ii dpkg-dev 1.16.3 ii libhtml-parser-perl3.69-2 ii libtext-template-perl none ii man-db 2.6.1-2 ii xz-utils 5.1.1alpha+20110809-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672906: freedroid should build-depend on libjpeg-dev (and possibly others)
On Mon, May 14, 2012 at 04:55:38PM +0100, Manuel A. Fernandez Montecelo wrote: We're planning to remove some dependencies that were introduced for libsdl*-dev packages years ago that are actually not required, and we found that some packages fail to build when we remove them, because they rely on libsdl-*-dev packages pulling them. Please re-check the build-depends on your package. In particular, please check if your package really depends on the same packages as [1][2][3] do (e.g.: libdirectfb-dev, libcaca-dev, libogg-dev, libtiff4-dev, ...); otherwise your package will FTBFS in the near future. [1] http://packages.debian.org/sid/libsdl-image1.2-dev [2] http://packages.debian.org/sid/libsdl-mixer1.2-dev [3] http://packages.debian.org/sid/libsdl1.2-dev For example, your package uses JPEG: ... checking for SDL - version = 1.2.3... yes checking for SDL_Init in -lSDL... yes checking for jpeg_start_compress in -ljpeg... no configure: error: -- libjpeg needed to run Freedroid! see http://www.ijg.org/ And so it should build-depend on libjpeg-dev. It would be great to have those modified libsdl packages in experimental, so maints can do the full check in real situation and forget about it :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672819: [PATCH] embuilddeps makes pdebuild-cross fail if apt-get -f install requires user interaction
Package: xapt
Version: 2.2.18
Severity: normal
Tags: patch
The following patch:
1. allows to understand what command is being run to better diagnose
problems (and understand this one)
2. prevents embuilddeps to abort following a Do you want to continue [Y/n]?
Abort.
message from apt-get -f install, when the latter decides it should remove
packages
(not that I understand yet why it wanted those packages out...)
--- /usr/sbin/embuilddeps.orig 2012-05-13 23:50:25.0 +0200
+++ /usr/sbin/embuilddeps 2012-05-13 23:52:21.0 +0200
@@ -282,7 +282,7 @@
# the addition of libc6 and libc6-dev is a nasty hack
my $cmdline = $cmd /usr/sbin/xapt -a $arch $multiarch $preserve $list
libc6 libc6-dev;
run_command ($cmdline);
- $cmdline = $cmd /usr/bin/apt-get -f $noauth install;
+ $cmdline = $cmd /usr/bin/apt-get -y -f $noauth install;
run_command ($cmdline);
exit 0;
}
@@ -304,6 +304,7 @@
if (defined $dryrun) {
print $cmdline\n;
} else {
+ print $cmdline\n if $verbose = 1;
my $retval = system ($cmdline);
$retval /= 256;
exit ($retval) if ($retval != 0);
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xapt depends on:
ii apt 0.8.15.10
ii dpkg-cross 2.6.6
ii dpkg-dev 1.16.3
ii libconfig-inifiles-perl 2.70-1
ii libdpkg-perl 1.16.3
ii liblocale-gettext-perl 1.05-7+b1
ii perl 5.14.2-9
xapt recommends no packages.
xapt suggests no packages.
-- Configuration Files:
/etc/xapt.d/debian.conf changed:
[debian]
mirror=http://ftp.fr.debian.org/debian/
components=main contrib non-free
suite=
noauth=
checknewer=
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/sbin/embuilddeps (from xapt package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671929: ccache: trigger not multi-arch safe, prevents proper gcc upgrade
On Wed, May 09, 2012 at 08:54:18PM +0200, Joel Rosdahl wrote: Hi, I don't see anything in the triggered ccache postinst script that could cause this. Can you reproduce the problem? Well, it was systematic, and I have now purged the 3 foreign packages remaining from my first experiment with multi-arch - so things are now back in order. I suspect that the way to reproduce would be: * downgrade eg. libgcc1 * activate multiarch * install foreign libgcc1 (thus same version) * upgrade native libgcc1 (possibly while same foreign version still unavail, or make it unavail by disabling foreign ach in apt.conf ?) Could it be that something other than ccache's trigger that causes this? See for instance bug#665727. Hm, it *does* look like the same issue, it is definitely the same message (and I got this exact one with libgcc1 once I purged gcc-4.7-base:armel). It is perfectly possible that the message from ccache in the context was here purely by chance - sorry about misfiling. -- Joel On 8 May 2012 11:10, Yann Dirson ydir...@free.fr wrote: Package: ccache Version: 3.1.7-1 Severity: grave Cannot configure the new gcc-4.7-base: |Preparing to replace gcc-4.7-base:amd64 4.7.0-3 (using .../gcc-4.7-base_4.7.0-7_amd64.deb) ... |De-configuring gcc-4.7-base:armel ... |Unpacking replacement gcc-4.7-base:amd64 ... |Processing triggers for ccache ... |Updating symlinks in /usr/lib/ccache ... |dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance I have: |# dpkg -l 'gcc-4.7-base' |iU gcc-4.7-base:amd64 4.7.0-7 |iF gcc-4.7-base:armel 4.7.0-3 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ccache depends on: ii libc6 2.13-32 ii zlib1g 1:1.2.6.dfsg-2 ccache recommends no packages. Versions of packages ccache suggests: pn distcc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671929: ccache: trigger not multi-arch safe, prevents proper gcc upgrade
Package: ccache Version: 3.1.7-1 Severity: grave Cannot configure the new gcc-4.7-base: |Preparing to replace gcc-4.7-base:amd64 4.7.0-3 (using .../gcc-4.7-base_4.7.0-7_amd64.deb) ... |De-configuring gcc-4.7-base:armel ... |Unpacking replacement gcc-4.7-base:amd64 ... |Processing triggers for ccache ... |Updating symlinks in /usr/lib/ccache ... |dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance I have: |# dpkg -l 'gcc-4.7-base' |iU gcc-4.7-base:amd64 4.7.0-7 |iF gcc-4.7-base:armel 4.7.0-3 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ccache depends on: ii libc6 2.13-32 ii zlib1g 1:1.2.6.dfsg-2 ccache recommends no packages. Versions of packages ccache suggests: pn distcc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671486: aptitude: does not select prefered alternative on alternative replacement
Package: aptitude
Version: 0.6.6-1
* Base situation:
$ apt-cache policy phonon
phonon:
Installed: 4:4.6.0really4.5.1-1
Candidate: 4:4.6.0.0-1
alternative phonon-backend-vlc | phonon-backend provided by
phonon-backend-xine
* problem:
# aptitude dist-upgrade
The following packages will be upgraded:
phonon{b}
...
The following packages have unmet dependencies:
phonon : Conflicts: phonon-backend-xine but 4:4.6.0really4.4.4-4 is installed.
The following actions will resolve these dependencies:
Remove the following packages:
...
4) kdebase-runtime
...
15) phonon
16) phonon-backend-xine
...
Leave the following dependencies unresolved:
19) kdelibs5-plugins recommends kde-runtime
Accept this solution? [Y/n/q/?] r 15
Rejecting the removal of phonon
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Remove the following packages:
1) phonon-backend-xine
Install the following packages:
2) phonon-backend-null [4:4.6.0.0-1 (testing)]
= phonon-backend-null appears to be taken randomly, while there is a prefered
alternative listed
Also note the side problem of an alternative removing 18 packages and breaking
a Recommends
being prefered over selecting another alternative. Maybe worth split the bug
for this one ?
--
Yann Dirson - Bertin Technologies
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Mon, Apr 30, 2012 at 04:02:57PM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@free.fr writes: On Fri, Apr 27, 2012 at 09:53:26PM +0200, Yann Dirson wrote: On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@free.fr writes: Package: apt Version: 0.8.15.10 Severity: normal (found no changelog entry for 0.9.x looking like this problem) I have many sources.list entries, and only want selected ones to take armel packages into account. The new [arch=] tag seems tailored for this, but then, APT::Architectures defaults to all foreign archs This works the other way around. arch=... is to limit the architectures. The default is ment to be all APT::Architectures. Just to be sure: even if there is some way to setup sources the way I wanted to do it, there still appears to be a bug that prevents apt to even manipulate (even remove) a foreign package when its arch has been removed from APT::Architectures: # apt-get remove libc6:armel Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libc6:armel If I re-enable armel and proceed with removal (a newer libc6:amd64 had already been installed causing breakage, see Bug#670668), I get a cryptic error from dpkg, but can't be sure who's causing it - at least things seem back in working order as far as packages seem concerned: (Reading database ... 438877 files and directories currently installed.) Removing libgcc1:armel ... dpkg: libc6:armel: dependency problems, but removing anyway as you requested: locales depends on glibc-2.13-1; however: Package glibc-2.13-1 is not installed. Package libc6:armel which provides glibc-2.13-1 is to be removed. Package libc6:amd64 which provides glibc-2.13-1 is not configured yet. This is a bit ugly. I guess dpkg is technically right. locales depends on glibc-2.13-1 and libc6:amd64 (the last thig providing it) is not configured yet. So your action does break the dependency of locales. Locales would have to be deconfigured or libc6:amd64 would have to be configured. Removing libc6:armel ... dpkg: error: --configure needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance But then it goes and tries to configure libc6. Where did that come from and why is it still ambiguous? Do you have libc6:i386 installed too? But then the above error would have been wrong. Not at all, the only foreigth arch here is armel. What was your command line that caused this? Hm, should have been the apt-get remove libc6:armel show above Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover: Setting up libc6:amd64 (2.13-30) ... Setting up libc6-dbg:amd64 (2.13-30) ... Setting up libc-dev-bin (2.13-30) ... Setting up libc6-i386 (2.13-30) ... Setting up libc6-dev (2.13-30) ... Setting up libc6-dev-i386 (2.13-30) ... Press return to continue. That looks like aptitude. Can I assume aptitude called: dpkg --remove libc6:armel dpkg --configure libc6 dpkg --configure -a If this was from an aptitude run then that should be filed as a seperate bug against aptitude. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670881: schroot: main manpage should warn about type=plain not running setup scripts
Package: schroot Version: 1.4.25-1+b1 Severity: normal It takes some time to find out that, when using directory=... with the (default) plain type, the setup scripts are not run: only the schroot.conf manpage seem to show the info. Also, the run-setup-scripts seems to be ignored in the case of the plain type, which is not explicit either. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages schroot depends on: ii libboost-filesystem1.49.0 1.49.0-2 ii libboost-program-options1.49.0 1.49.0-2 ii libboost-regex1.49.01.49.0-2 ii libboost-system1.49.0 1.49.0-2 ii libc6 2.13-30 ii libgcc1 1:4.7.0-3 ii liblockdev1 1.0.3-1.4+b2 ii libpam0g1.1.3-7 ii libstdc++6 4.7.0-3 ii libuuid12.20.1-4 ii schroot-common 1.4.25-1 schroot recommends no packages. Versions of packages schroot suggests: ii aufs-modules | unionfs-modules none ii btrfs-tools none ii debootstrap 1.0.39 ii lvm22.02.88-2 -- Configuration Files: /etc/schroot/default/fstab changed [not included] /etc/schroot/schroot.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657211: Steps to reproduce
On Sat, Apr 28, 2012 at 12:26:24AM -0400, Scott Kitterman wrote: Please provide the exact steps you used to run this demo so I can try to reproduce the problem. Looking at /usr/share/doc/python-qt4-doc/examples/README, no exact command to run the examples is given, but the hint about examples/demos/qtdemo led me to launch: /usr/share/doc/python-qt4-doc/examples/demos/qtdemo/qtdemo.py and from there, select Qt declarative examples and Corkboards. Still happens on today's wheezy. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670774: pdebuild-cross: manpages point to wrong configfile path
Package: pdebuild-cross Version: 2.2.18 Severity: normal Manpages refer /etc/pdebuild/pdebuild-cross.rc and /etc/pdebuild-cross/pbuilder.rc instead of /etc/pdebuild-cross/pdebuild-cross.rc -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pdebuild-cross depends on: ii fakeroot 1.18.2-1 ii gettext-base 0.18.1.1-5 ii multistrap2.1.16 ii pbuilder 0.210 ii xapt 2.2.18 pdebuild-cross recommends no packages. Versions of packages pdebuild-cross suggests: pn svn-buildpackage none -- Configuration Files: /etc/pdebuild-cross/pdebuild-cross.rc changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#275674: please use traps to ensure removal of builddir
Maybe an intermediate measure could still be taken, by unmounting bindmounts from the builddir. Currently, data loss can happen when one blindly runs sudo rm -rf on such a builddir without first manually checking and unmounting those. The gravity of such a mistake depends on root perms on those bindmounted dirs, obviously, so it may happen that you only have nfs-mounted trees bindmounted, but hey, that's probably far from the common case (although, but luck, it is mine :) -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@free.fr writes: Package: apt Version: 0.8.15.10 Severity: normal (found no changelog entry for 0.9.x looking like this problem) I have many sources.list entries, and only want selected ones to take armel packages into account. The new [arch=] tag seems tailored for this, but then, APT::Architectures defaults to all foreign archs This works the other way around. arch=... is to limit the architectures. The default is ment to be all APT::Architectures. Ah OK. But then, apt should probably not fetch the package list for armel even when it is specified using arch=, isn't it ? -- /etc/apt/sources.list -- deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670668: aptitude: should not allow to select different versions for foreign packages
Package: aptitude Version: 0.6.6-1 Severity: important I have installed foreign packages (but disabled the foreign source as a temporary measure because of #670322. But aptitude still lets me select libc6:amd64 for upgrade, without considering that the existing libc6:armel would prevent its configuration. Maybe the problem has to be partly handled at the libapt level ? On the next libc6 upgrade: Setting up libc-bin (2.13-30) ... (Reading database ... 438878 files and directories currently installed.) Preparing to replace libc6:amd64 2.13-27 (using .../libc6_2.13-30_amd64.deb) ... De-configuring libc6:armel ... Unpacking replacement libc6:amd64 ... dpkg: error: --configure needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover: dpkg: error processing libc6:amd64 (--configure): package libc6:amd64 2.13-30 cannot be configured because libc6:armel is at a different version (2.13-27) dpkg: error processing libc6:armel (--configure): package libc6:armel 2.13-27 cannot be configured because libc6:amd64 is at a different version (2.13-30) [...] -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.6 compiled at Mar 27 2012 22:36:24 Compiler: g++ 4.6.3 Compiled against: apt version 4.10.1 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.10.1 aptitude linkage: linux-vdso.so.1 = (0x7fffcc9ff000) libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0x7f31ec10d000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f31ebede000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f31ebcb5000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f31ebab) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f31eb7a8000) libept.so.1 = /usr/lib/libept.so.1 (0x7f31eb54b000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f31eb14e000) libz.so.1 = /usr/lib/x86_64-linux-gnu/libz.so.1 (0x7f31eaf38000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f31eac9) libboost_iostreams.so.1.48.0 = /usr/lib/libboost_iostreams.so.1.48.0 (0x7f31eaa77000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f31ea85b000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f31ea553000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f31ea2d1000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f31ea0bb000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f31e9d33000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f31e9b3) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f31e992c000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f31e9726000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f31e9516000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f31e930d000) /lib64/ld-linux-x86-64.so.2 (0x7f31ec45) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg4.10] 0.8.15.10 ii libboost-iostreams1.48.0 1.48.0-3 ii libc6 2.13-30 ii libcwidget3 0.5.16-3.1 ii libept1 1.0.5 ii libgcc1 1:4.7.0-3 ii libncursesw5 5.9-6 ii libsigc++-2.0-0c2a2.2.10-0.1 ii libsqlite3-0 3.7.11-2 ii libstdc++64.7.0-3 ii libtinfo5 5.9-6 ii libxapian22 1.2.8-1 ii zlib1g1:1.2.6.dfsg-2 Versions of packages aptitude recommends: ii apt-xapian-index0.45 ii aptitude-doc-en | aptitude-doc none ii libparse-debianchangelog-perl 1.2.0-1 ii sensible-utils 0.0.6 Versions of packages aptitude suggests: ii debtags 1.9 ii tasksel 3.09 -- no debconf information
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@free.fr writes: Package: apt Version: 0.8.15.10 Severity: normal (found no changelog entry for 0.9.x looking like this problem) I have many sources.list entries, and only want selected ones to take armel packages into account. The new [arch=] tag seems tailored for this, but then, APT::Architectures defaults to all foreign archs This works the other way around. arch=... is to limit the architectures. The default is ment to be all APT::Architectures. Just to be sure: even if there is some way to setup sources the way I wanted to do it, there still appears to be a bug that prevents apt to even manipulate (even remove) a foreign package when its arch has been removed from APT::Architectures: # apt-get remove libc6:armel Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libc6:armel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670668: Acknowledgement (aptitude: should not allow to select different versions for foreign packages)
Since this possibly has an impact, I should also note that I am in the configuration described in Bug#670322, where APT::Architectures has been forced to amd64 only, while armel is accepted by dpkg, and the wheezey Packages file, from where libc6:armel comes, uses [arch=amd64,armel] and gets downloaded. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Fri, Apr 27, 2012 at 09:53:26PM +0200, Yann Dirson wrote: On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@free.fr writes: Package: apt Version: 0.8.15.10 Severity: normal (found no changelog entry for 0.9.x looking like this problem) I have many sources.list entries, and only want selected ones to take armel packages into account. The new [arch=] tag seems tailored for this, but then, APT::Architectures defaults to all foreign archs This works the other way around. arch=... is to limit the architectures. The default is ment to be all APT::Architectures. Just to be sure: even if there is some way to setup sources the way I wanted to do it, there still appears to be a bug that prevents apt to even manipulate (even remove) a foreign package when its arch has been removed from APT::Architectures: # apt-get remove libc6:armel Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libc6:armel If I re-enable armel and proceed with removal (a newer libc6:amd64 had already been installed causing breakage, see Bug#670668), I get a cryptic error from dpkg, but can't be sure who's causing it - at least things seem back in working order as far as packages seem concerned: (Reading database ... 438877 files and directories currently installed.) Removing libgcc1:armel ... dpkg: libc6:armel: dependency problems, but removing anyway as you requested: locales depends on glibc-2.13-1; however: Package glibc-2.13-1 is not installed. Package libc6:armel which provides glibc-2.13-1 is to be removed. Package libc6:amd64 which provides glibc-2.13-1 is not configured yet. Removing libc6:armel ... dpkg: error: --configure needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through `less' or `more' ! E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover: Setting up libc6:amd64 (2.13-30) ... Setting up libc6-dbg:amd64 (2.13-30) ... Setting up libc-dev-bin (2.13-30) ... Setting up libc6-i386 (2.13-30) ... Setting up libc6-dev (2.13-30) ... Setting up libc6-dev-i386 (2.13-30) ... Press return to continue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670673: aptitude: problem with dependencies and foreign archs
Package: aptitude Version: 0.6.6-1 Severity: normal When I installed libc6:armel, libgcc1:armel and gcc-4.7-base:armel were correctly pulled. However, when I removed libc6:armel, gcc-4.7-base:armel stayed there, and was even not marked automatic (any more?). Marking it automatic again does not seem to help, although listed reverse Depends are all uninstalled armel packages. Those listed by apt-cache, however, are different: # apt-cache rdepends gcc-4.7-base:armel gcc-4.7-base:armel Reverse Depends: gcc-4.7-base gcc-4.7-base gcc-4.7-base gcc-4.7-base libstdc++6-4.7-pic:armel libstdc++6-4.7-dev:armel [...] cpp-4.7:armel If I look to libc-bin:armel rdeps, it seems to also consider native packages: p--\ libc-bin:armel0 testing --\ Conflicts (4) p A libc-bin 2.11.3-2 0 stable i A libc-bin 2.13-30 4 testing,unstable plibc-bin:armel 2.11.3-2 1 stable plibc-bin:armel 2.13-302 testing --\ Depends (4) ilibc6 2.13-30 18 testing,unstable plibc6:armel 2.13-30 6 testing p A lintian 2.5.6~bpo60+1 4 squeeze-backports i A lintian 2.5.6 4 testing,unstable Here too, apt-cache shows slightly different results, although not different in the exact same way: # apt-cache rdepends libc-bin:armel libc-bin:armel Reverse Depends: libc-bin libc-bin libc6:armel libc6:armel libc6:armel libc-bin -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.6 compiled at Mar 27 2012 22:36:24 Compiler: g++ 4.6.3 Compiled against: apt version 4.10.1 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.10.1 aptitude linkage: linux-vdso.so.1 = (0x7fffbb339000) libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0x7f90be7f9000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f90be5ca000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f90be3a1000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f90be19c000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f90bde94000) libept.so.1 = /usr/lib/libept.so.1 (0x7f90bdc37000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f90bd83a000) libz.so.1 = /usr/lib/x86_64-linux-gnu/libz.so.1 (0x7f90bd624000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f90bd37c000) libboost_iostreams.so.1.48.0 = /usr/lib/libboost_iostreams.so.1.48.0 (0x7f90bd163000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f90bcf47000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f90bcc3f000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f90bc9bd000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f90bc7a7000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f90bc41f000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f90bc21c000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f90bc018000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f90bbe12000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f90bbc02000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f90bb9f9000) /lib64/ld-linux-x86-64.so.2 (0x7f90beb3b000) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg4.10] 0.8.15.10 ii libboost-iostreams1.48.0 1.48.0-3 ii libc6 2.13-30 ii libcwidget3 0.5.16-3.1 ii libept1 1.0.5 ii libgcc1 1:4.7.0-3 ii libncursesw5 5.9-6 ii libsigc++-2.0-0c2a2.2.10-0.1 ii libsqlite3-0 3.7.11-2 ii libstdc++64.7.0-3 ii libtinfo5 5.9-6 ii libxapian22 1.2.8-1 ii zlib1g1:1.2.6.dfsg-2 Versions of packages aptitude recommends: ii apt-xapian-index0.45 ii aptitude-doc-en | aptitude-doc none ii libparse-debianchangelog-perl 1.2.0-1 ii sensible-utils 0.0.6 Versions of packages aptitude suggests: ii debtags 1.9 ii tasksel 3.09 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Package: apt
Version: 0.8.15.10
Severity: normal
(found no changelog entry for 0.9.x looking like this problem)
I have many sources.list entries, and only want selected ones to take
armel packages into account. The new [arch=] tag seems tailored for
this, but then, APT::Architectures defaults to all foreign archs
(Sidenote: this situation is probably OK when foreign archs are
directly executable (eg. i386 on amd64), but for cross-compiling
purposes it it less OK)
... and apt ignores my tag and just downloads any armel Packages file
it can find - at least, I am able to install foreign packages, it just
does not installs by default the versions I want, and complains for
sources which do not provide an armel version.
(Sidenote: apt/preferences does not seem to allow scoring based on
arch, so I cannot pin armel packages to squeeze on this box where the
native packages are usually pinned to testing - maybe worth its own bugreport)
Now if I tell apt to only consider amd64 by default, with:
APT::Architectures { amd64; };
... then apt-get update *does* fetch only the correct files, with a
single armel Packages file, but then, neither of apt-get/apt-cache/aptitude
want to talk about armel packages again, even for installed ones:
# dpkg -l libc6:armel
...
ii libc6:armel 2.13-27
# apt-cache policy libc6:armel
N: Unable to locate package libc6:armel
And if I comment out this APT::Architectures line and run apt-get update again:
# apt-cache policy libc6:armel
libc6:armel:
Installed: 2.13-27
Candidate: 2.13-27
...
Maybe I'm just trying to use the wrong feature to do what I need - I
had to guess since the sources.list manpage does not really tell that
the [arch=] syntax is not expected to be useful out of the box, nor in
which situations it is expected to be useful.
-- Package-specific info:
-- apt-config dump --
APT::Architecture amd64;
...
APT::Architectures ;
APT::Architectures:: amd64;
-- (/etc/apt/preferences present, but not submitted) --
-- /etc/apt/sources.list --
deb ftp://ftp.debian.org/debian testing main contrib non-free
...
deb [ arch=amd64,armel ] ftp://ftp.debian.org/debian squeeze main
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages apt depends on:
ii debian-archive-keyring 2010.08.28
ii gnupg 1.4.12-4
ii libc6 2.13-27
ii libgcc1 1:4.7.0-3
ii libstdc++6 4.7.0-3
ii zlib1g 1:1.2.6.dfsg-2
apt recommends no packages.
Versions of packages apt suggests:
ii apt-doc none
ii aptitude0.6.6-1
ii bzip2 1.0.6-1
ii dpkg-dev1.16.2
ii python-apt 0.8.3+nmu1
ii xz-lzma [lzma] 5.1.1alpha+20110809-3
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670200: gdb: ships syscalls decls for unrelated archs
Package: gdb Version: 7.4really-1 Severity: normal X-Debbugs-CC: debian-embed...@lists.debian.org In /usr/share/gdb/syscalls/, the standard gdb package installs many files, seamingly for support of other archs, although set arch will make it obvious that very few of those are indeed usable with the installed binary. This makes it uncomfortable to simultaneously install cross gdb packages from emdebian, as those currently ship the same set of files - and even if they only shipped the relevant ones, there would be conflict on those files they seem the more legitimate to ship. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdb depends on: ii gdbserver 7.4really-1 ii libc6 2.13-27 ii libexpat1 2.1.0-1 ii libncurses5 5.9-6 ii libpython2.7 2.7.2-8 ii libreadline6 6.2-8 ii libtinfo5 5.9-6 ii zlib1g1:1.2.6.dfsg-2 gdb recommends no packages. Versions of packages gdb suggests: ii gdb-doc 7.4-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667664: libpcre3: upgrade from 8.12 to 8.30 breaks (oldstable-era) dansguardian
Package: libpcre3 Version: 1:8.30-4 Severity: normal X-Debbugs-CC: dansguard...@packages.debian.org Disclaimer: I am still using an old dansguardian (2.9.9.7-2.1, last pre-2.10 packaged version) because http://bugs.debian.org/536778 which in itself is a blow in the face of us developers, but that's another story which *should not* be related to compatibility breakages... After upgrading from 8.12-4 and restarting dansguardian (thanks logrotate), dansguardian began refusing virtually all pages. The cause appears to be any non-commented-out pattern from the bannedregexpurllist file. After downgrading just libpcre3 back to 8.12-4, it starts working again. Now dansguardian does not have a lot of debug traces to activate, and I didn't look at the libpcre API yet. Any idea of a particular change that could cause such a breakage ? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpcre3 depends on: ii libc6 2.13-27 ii multiarch-support 2.13-27 libpcre3 recommends no packages. libpcre3 suggests no packages. -- no debconf information -- debsums errors found: debsums: package libpcre3 is not installed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615921: sgt-puzzles: Please package game group from upstream
On Wed, Apr 04, 2012 at 02:06:32AM +0100, Ben Hutchings wrote: On Wed, 2012-04-04 at 00:05 +0200, Yann Dirson wrote: Ben said: I don't include the 'unfinished' games in the package. Well, the file says: * This is a perfectly playable and fully working puzzle, but I'm * leaving it for the moment in the 'unfinished' directory because * it's just too esoteric (not to mention _hard_) for me to be * comfortable presenting it to the general public as something they * might (implicitly) actually want to play. So that may finally sound like something that could be of release quality ? Upstream evidently doesn't want to release it, and I don't wish to override that decision. I understand that, but it's still a shame that a working game does not get to a wider audience, just because it does not target the whole population. Time for a sgt-puzzles-hard package ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615921: sgt-puzzles: Please package game group from upstream
Ben said: I don't include the 'unfinished' games in the package. Well, the file says: * This is a perfectly playable and fully working puzzle, but I'm * leaving it for the moment in the 'unfinished' directory because * it's just too esoteric (not to mention _hard_) for me to be * comfortable presenting it to the general public as something they * might (implicitly) actually want to play. So that may finally sound like something that could be of release quality ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661984: xscreensaver: does not reap child gdmflexiserver processes
Package: xscreensaver Version: 5.15-2 Severity: normal Some SIGGHLD handling probably has do be done: $ ps l $(pidof gdmflexiserver) F UID PID PPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND 0 1000 711 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 1346 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 2478 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 3924 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 4017 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1003 4967 29453 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1003 6032 29453 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1003 6802 29453 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 7169 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 7703 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 11030 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 12703 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1003 14465 29453 30 10 125420 692 ? SN ? 0:00 gdmflexiserver -ls 0 1000 19004 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 29873 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct 0 1000 32456 3007 30 10 0 0 ? ZN ? 0:00 [gdmflexiserver] defunct $ ps l 3007 29453 F UID PID PPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND 0 1000 3007 1 20 0 65108 2392 - S? 1:43 xscreensaver 0 1003 29453 29381 20 0 65180 2256 ? S? 0:20 xscreensaver -no-splash -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-0 2.2.0-2 ii libc6 2.13-26 ii libcairo2 1.10.2-6.2 ii libfontconfig1 2.8.0-3.1 ii libfreetype62.4.8-1 ii libgdk-pixbuf2.0-0 2.24.1-1 ii libglade2-0 1:2.6.4-1 ii libglib2.0-02.30.2-6 ii libgtk2.0-0 2.24.9-2 ii libice6 2:1.0.7-2 ii libpam0g1.1.3-7 ii libpango1.0-0 1.29.4-2 ii libsm6 2:1.2.0-2 ii libx11-62:1.4.4-4 ii libxext62:1.3.0-3 ii libxi6 2:1.4.5-1 ii libxinerama12:1.1.1-3 ii libxml2 2.7.8.dfsg-7 ii libxmu6 2:1.1.0-3 ii libxpm4 1:3.5.9-4 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.6-2 ii libxt6 1:1.1.1-2 ii libxxf86vm1 1:1.1.1-2 ii xscreensaver-data 5.15-2 Versions of packages xscreensaver recommends: ii libjpeg-progs 8d-1 ii perl [perl5]5.14.2-7 ii wamerican-large [wordlist] 7.1-1 ii wfrench [wordlist] 1.2.3-9 Versions of packages xscreensaver suggests: pn chromium [www-browser] 17.0.963.56~r121963-1 pn elinks [www-browser] 0.12~pre5-7 pn fortune-mod [fortune]1:1.99.1-4 pn gdm3 | kdm-gdmcompat none pn iceweasel [www-browser] 10.0.2-1 pn links2 [www-browser] 2.5-1 pn lynx-cur [www-browser] 2.8.8dev.9-3 pn qcam | streamer none pn uzbl [www-browser] 0.0.0~git.2028-2 pn xdaliclock none pn xfishtanknone pn xscreensaver-gl none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535759: PyQt4 splitup
What about simply doing the split, keeping python-qt4 as a metapackage that installs everything for compatibility, and letting individual package maintainers progressively adjust dependencies ? A lintian warning to discourage packages to depend on the metapackage could then be introduce to speed up migration. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661854: python-qt4: segfault calling family() on QFontInfo object
Package: python-qt4 Version: 4.9.1-1 Severity: normal $ python Python 2.7.2+ (default, Nov 30 2011, 19:22:03) [GCC 4.6.2] on linux2 Type help, copyright, credits or license for more information. from PyQt4 import QtCore, QtGui, QtSvg fi = QtGui.QFontInfo(QtGui.QFont()) fi PyQt4.QtGui.QFontInfo object at 0x7fbf89211b40 fi.family() Segmentation fault -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-qt4 depends on: ii libc6 2.13-26 ii libgcc1 1:4.6.2-12 ii libpython2.7 2.7.2-8 ii libqt4-dbus 4:4.7.4-2 ii libqt4-declarative4:4.7.4-2 ii libqt4-designer 4:4.7.4-2 ii libqt4-help 4:4.7.4-2 ii libqt4-network4:4.7.4-2 ii libqt4-script 4:4.7.4-2 ii libqt4-scripttools4:4.7.4-2 ii libqt4-svg4:4.7.4-2 ii libqt4-test 4:4.7.4-2 ii libqt4-xml4:4.7.4-2 ii libqt4-xmlpatterns4:4.7.4-2 ii libqtassistantclient4 4.6.3-3 ii libqtcore44:4.7.4-2 ii libqtgui4 4:4.7.4-2 ii libqtwebkit4 2.2.0-3 ii libstdc++64.6.2-12 ii python2.7.2-10 ii python-sip [sip-api-8.1] 4.13.2-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 python-qt4 recommends no packages. Versions of packages python-qt4 suggests: pn python-qt4-dbg none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659337: claws-mail gnores BASE in HTML mails
Package: claws-mail Version: 3.8.0-1 When a HTML mail has a base href=whatever tag in its head, it is not used and further non-absolute URLs are used as if they were relative, getting wrongly interpreted as file:// URLs in the end. This happens both with the standard HTML renderer and with the gtkhtml2_viewer plugin. -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658760: alsactl -h advertises non-existent command names
Package: alsa-utils Version: 1.0.24.2-4 Severity: normal # alsactl -h Usage: alsactl options command [...] Available commands: store card # save current driver setup for one or each soundcards to configuration file restore card # load current driver setup for one or each soundcards from configuration file initcard # initialize driver to a default state names card # dump information about all the known present (sub-)devices into configuration file (DEPRECATED) Not only that command is deprecated, but it appears it does not exist any more. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages alsa-utils depends on: ii dialog 1.1-20111020-1 ii libasound2 1.0.24.1-4 ii libc6 2.13-24 ii libncursesw5 5.9-4 ii libsamplerate0 0.1.8-1 ii libtinfo5 5.9-4 ii linux-sound-base 1.0.23+dfsg-4 ii lsb-base 3.2-28.1 ii module-init-tools 3.16-1 ii whiptail 0.52.14-7 Versions of packages alsa-utils recommends: ii alsa-base 1.0.23+dfsg-4 ii pciutils 1:3.1.8-2 alsa-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658762: arecord: manpage has typos in examples
Package: alsa-utils Version: 1.0.24.2-4 Severity: normal The examples in manpage talk about -max-file_time, while the correct name is --max-file-time (2 typos packed in one option, at least twice in the manpage). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages alsa-utils depends on: ii dialog 1.1-20111020-1 ii libasound2 1.0.24.1-4 ii libc6 2.13-24 ii libncursesw5 5.9-4 ii libsamplerate0 0.1.8-1 ii libtinfo5 5.9-4 ii linux-sound-base 1.0.23+dfsg-4 ii lsb-base 3.2-28.1 ii module-init-tools 3.16-1 ii whiptail 0.52.14-7 Versions of packages alsa-utils recommends: ii alsa-base 1.0.23+dfsg-4 ii pciutils 1:3.1.8-2 alsa-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657804: Please package latest upstream version (12.01)
On Sat, Jan 28, 2012 at 07:20:19PM -0500, Jeremy Bicha wrote: gcompris 9.5 was released over a year ago, and the latest version is now 12.01. Please package this; I have updated Ubuntu's packaging which you're welcome to use or I could format a patch for you. Thanks for your work. I integrated most of them, and created a collab-maint git repo to ease further maintainance. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658542: lintian: does not report inconsistencies between files and checksum sections in changes file
Package: lintian Version: 2.5.4 Severity: wishlist After adding by hand an upstream tarball to changes file and resigning it, lintian appeared to be happy; but then, the upload got rejected because I had not added the sha1 and sha256 sums for that file. Could be a good idea to check consistency to avoid putting the burden on the upload server ? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.22-4 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.09-2 ii gettext0.18.1.1-5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.25+b1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.1.2 ii libemail-valid-perl0.185-1 ii libipc-run-perl0.90-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.59-1 ii locales2.13-24 ii man-db 2.6.0.2-3 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-6 ii unzip 6.0-5 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch none ii dpkg-dev 1.16.1.2 ii libhtml-parser-perl3.69-1+b1 ii libtext-template-perl none ii man-db 2.6.0.2-3 ii xz-utils 5.1.1alpha+20110809-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616011: no mediawiki exporter
found 616011 1.1.1+LibO3.4.5-2 tags 616011 + patch thanks On current wheezy, I get the same problem: the exporter is not listed, and attempting to use the send to feature yields the same result as OP. How are exporters supposed to be registered ? Can we manually request a re-registration of that exporter, possibly with verbose traces ? Since the last time this worked on this machine (that was last september, and I did not attempt to use it since then), the following upgrades were done according to aptitude logs: [UPGRADE] libreoffice 1:3.3.3-4+b1 - 1:3.4.3-1 [UPGRADE] libreoffice-wiki-publisher 1.1.1+LibO3.3.3-4 - 1.1.1+LibO3.4.3-1 [UPGRADE] libreoffice 1:3.4.3-1 - 1:3.4.3-3 [UPGRADE] libreoffice-wiki-publisher 1.1.1+LibO3.4.3-1 - 1.1.1+LibO3.4.3-3 I get the problem with sun jre 1.6.0_26 and (openjdk from testing but listed as sun) _24, the previous success was probably with another version, since no jre was selected any more (this mechanism *does* suck, btw). Switching to FSF 1.5.0 (for which there are two identical lines in the dialog...) results in the send to mediawiki turning to non-selectable after restart. Since it used to work for me with 3.3.3 and problems have been reported with previous versions, I don't believe that downgrading would be of any help. René wrote: Please don't tell me you did intrusive changes like a complete LibO package upgrade while LibO was running? (Extension registration should be ok if done via unopkg, but I don't think it will work with the new preregistered way) Err... are you saying that no LibO or OOo program should be running during the upgrade or there is any risk of getting broken in ways noone imagines ? That would sound pretty broken, and a bold warning should be displayed from preinst, should that be the case. That said, I regularly launch upgrades while I'm continuing to work, and it surely occured that LibO got upgrade while it was running. Now what can be done to recover if that was the source of the breakage ? Looking at the various installed filters .xcu files, it looks like this one is the only one using oor:op=fuse, other (writer2latex, pdfimport) rather use oor:op=replace. Now I tried to replace fuse with replace for a test, and reregistering the thing: mv /usr/lib/libreoffice/share/extensions/wiki-publisher / /var/lib/dpkg/info/libreoffice-common.postinst triggered /usr/lib/libreoffice/share/extensions mv /wiki-publisher/ /usr/lib/libreoffice/share/extensions/ $EDITOR /usr/lib/libreoffice/share/extensions/wiki-publisher/Filter.xcu /var/lib/dpkg/info/libreoffice-common.postinst triggered /usr/lib/libreoffice/share/extensions ... and guess what ? it just worked :) Now the export filter is selectable in the export dialog, and send to finds it as well... So one question remains, what was this fuse supposed to do ? -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658188: sdcc: target list in description is incomplete, manpage has typo
Package: sdcc Version: 2.9.0-5 Severity: normal A number of target archs listed in the manpage are surely worth mentionning in the package description, most notably the GBA, but also the presumably uncommon microcontollers too. Also note that -mpic16 says PIC 14-bit, which is surely a typo, and -mxa51 has improper markup. The manpage could also mention vendors for TLCS-900/H (Toshiba) and XA-51 (NXP); manpage initial desc talks about 186, which is not mentionned in target selection flags - I don't suppose that could be old intel 80186 ? sdcc -h also mentions TININative which is not mentionned in the manpage. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sdcc depends on: ii libc6 2.13-24 ii sdcc-libraries 2.9.0-5 Versions of packages sdcc recommends: ii sdcc-doc 2.9.0-5 Versions of packages sdcc suggests: pn sdcc-ucsim none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#349000: this is a very annoying regression
On Sat, Jan 28, 2012 at 09:52:49PM +0100, Tormod Volden wrote: On Sat, Jan 28, 2012 at 3:51 PM, Yann Dirson ydir...@free.fr wrote: I'd say that old gdm has been prematurely removed from Debian... but this is another story. At least there will be people sticking to that package for some time, even if it does not come back. And I could verify that it indeed works fine with -s in my xscreensaver config. That seems to settle the issue, could you please reintroduce this flag in the next upload ? TIA, Yes, sure, if people still need to use the old gdm, we can reintroduce the -s option next time. I had myself to get back to old gdm, because it lacks at least AlwaysLoginCurrentSession=false and xnest support... (looks like it's getting an habit for some people to release less functionnal rewrites and call them next version, alas...) Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657746: prolix: under- and wrongly-documented, not working interactively at all
Package: prolix Version: 0.01-1 Severity: serious * the manpage does not give a synopsis or explanation of options, only example uses not directly usable on standard files. No proper documentation of interactive mode either. * trying a simple thing like: strings /usr/bin/gdmflexiserver|prolix -r '[a-z]' ... does filter, but I'm back to the shell without any possibility of interactive use * prolix -h tells that -v is --verbose, but attempting to use it makes it obvious that it is an alias to (undocumented) --version flag instead, and it does not even give prolix' version * -l says Option log requires an argument, which -h does not tell about well... that makes it *far* less useful than grep -v in its current state - looking forward to see it in better shape... -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages prolix depends on: ii libdata-munge-perl 0.04-1 ii libipc-run-perl0.90-1 ii libjson-perl 2.53-1 ii libmoose-perl 2.0401-1 ii libmoosex-configfromfile-perl 0.04-1 ii libmoosex-getopt-perl 0.37-1 ii libstring-shellquote-perl 1.03-1 ii libterm-readkey-perl 2.30-4+b2 ii libtry-tiny-perl 0.11-1 ii perl 5.14.2-6 prolix recommends no packages. prolix suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657747: gdm3: gdmflexiserver does not provide exit any more
Package: gdm3 Version: 3.0.4-4 Severity: normal When launching gdmflexiserver by hand from within a session with a running xscreensaver, that session gets properly locked. Selecting an active session to unlock instead of a new login, one gets asked for the user's passord, and then switched to the proper console... where xscreensaver is still locked, and the password has to be entered again! Looks like it should just offer a switch to this session button and let xscreensaver do its job, right ? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdm3 depends on: ii accountsservice0.6.15-2 ii adduser3.113 ii awesome [x-window-manager] 3.4.11-1 ii dconf-gsettings-backend0.10.0-3 ii debconf [debconf-2.0] 1.5.41 ii flwm [x-window-manager]1.02+cvs20080422-9 ii fvwm [x-window-manager]1:2.5.30.ds-1 ii gconf2 2.32.4-1 ii gnome-session-bin 3.2.1-1 ii gsettings-desktop-schemas 3.2.0-2 ii libaccountsservice00.6.15-2 ii libatk1.0-02.2.0-2 ii libattr1 1:2.4.46-5 ii libaudit0 1.7.18-1 ii libc6 2.13-24 ii libcairo-gobject2 1.10.2-6.2 ii libcairo2 1.10.2-6.2 ii libcanberra-gtk3-0 0.28-3 ii libcanberra0 0.28-3 ii libdbus-1-31.4.16-1 ii libdbus-glib-1-2 0.98-1 ii libfontconfig1 2.8.0-3 ii libfreetype6 2.4.8-1 ii libgconf2-42.32.4-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libglib2.0-0 2.30.2-4 ii libglib2.0-bin 2.30.2-4 ii libgtk-3-0 3.2.3-1 ii libpam-modules 1.1.3-6 ii libpam-runtime 1.1.3-6 ii libpam0g 1.1.3-6 ii libpango1.0-0 1.29.4-2 ii librsvg2-common2.34.2-2 ii libselinux12.1.0-4 ii libupower-glib10.9.15-1 ii libwrap0 7.6.q-22 ii libx11-6 2:1.4.4-4 ii libxau61:1.0.6-4 ii libxdmcp6 1:1.1.0-4 ii libxklavier16 5.1-3 ii libxrandr2 2:1.3.2-2 ii lsb-base 3.2-28 ii lxsession [x-session-manager] 0.4.6.1-1 ii openbox [x-window-manager] 3.5.0-2 ii policykit-1-gnome 0.105-1 ii upower 0.9.15-1 ii xfce4-session [x-session-manager] 4.8.2-3 ii xfwm4 [x-window-manager] 4.8.3-1 ii xterm [x-terminal-emulator]276-2 Versions of packages gdm3 recommends: ii at-spi 1.32.0-1 ii desktop-base 6.0.7 ii gnome-icon-theme 3.2.1.2-1 ii gnome-power-managernone ii gnome-settings-daemon none ii x11-xkb-utils 7.6+4 ii xserver-xephyr 2:1.11.3.901-2 ii xserver-xorg 1:7.5+8 ii zenity 3.2.0-1 Versions of packages gdm3 suggests: pn gnome-mag none pn gnome-orcanone pn gok none pn libpam-gnome-keyring 3.2.2-1 pn metacity none -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601106: gdmflexiserver in gdm3 has lost the xnest feature
$ gdmflexiserver -h Usage: gdmflexiserver [OPTION...] - New GDM login Help Options: -h, --helpShow help options Application Options: -c, --command=COMMAND Only the VERSION command is supported -n, --xnest Ignored — retained for compatibility -l, --no-lock Ignored — retained for compatibility -d, --debug Debugging output -a, --authenticateIgnored — retained for compatibility -s, --startnewIgnored — retained for compatibility --monte-carlo-pi --version Version of this application 'nuf said, it seems ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#349000: this is a very annoying regression
On Thu, Jun 30, 2011 at 10:47:16PM +0200, Tormod Volden wrote: On Thu, Jun 30, 2011 at 9:09 PM, Yann Dirson wrote: In which version does it say so ? In 2.20.11-4 it says: -s, --startnew Start new flexible session; do not show popup If they changed someting in gdm3, there may be a problem to be solved in one way or another. But it may be that they kept the -s flag for compatibility with gdm2. The gdm package was removed in February. Shouldn't you have been migrated to the gdm3 package (currently at version 2.30.5-10) by now? 1. nothing in aptitude brought me to notice this and ask myself whether I should do that, I had even not noticed that gdm had been removed before you wrote this. 2. I have now started to look at gdm3, and it looks like it has at least lost the --xnest feature, which is bad - this is a great feature, and I'm not the only one to think this, see #601106. I'd say that old gdm has been prematurely removed from Debian... but this is another story. At least there will be people sticking to that package for some time, even if it does not come back. As for the -s flag, here is what gdm3 says: $ gdmflexiserver -h Usage: gdmflexiserver [OPTION...] - New GDM login Help Options: -h, --helpShow help options Application Options: -c, --command=COMMAND Only the VERSION command is supported -n, --xnest Ignored — retained for compatibility -l, --no-lock Ignored — retained for compatibility -d, --debug Debugging output -a, --authenticateIgnored — retained for compatibility -s, --startnewIgnored — retained for compatibility --monte-carlo-pi --version Version of this application And I could verify that it indeed works fine with -s in my xscreensaver config. That seems to settle the issue, could you please reintroduce this flag in the next upload ? TIA, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657751: gdm3: error on package purge
Package: gdm3 Version: 3.0.4-4 Severity: serious Removing gdm3 ... Purging configuration files for gdm3 ... insserv: warning: script 'K02evms' missing LSB tags and overrides insserv: warning: script 'S20LOCAL-fw' missing LSB tags and overrides insserv: warning: script 'evms' missing LSB tags and overrides insserv: warning: script 'LOCAL-fw' missing LSB tags and overrides Removing user `Debian-gdm' ... Warning: group `Debian-gdm' has no more members. userdel: user Debian-gdm is currently logged in /usr/sbin/deluser: `/usr/sbin/userdel Debian-gdm' returned error code 8. Exiting. Could not remove Debian-gdm user. /usr/sbin/delgroup: `Debian-gdm' still has `Debian-gdm' as their primary group! Could not remove Debian-gdm group. insserv: warning: script 'K02evms' missing LSB tags and overrides insserv: warning: script 'S20LOCAL-fw' missing LSB tags and overrides insserv: warning: script 'evms' missing LSB tags and overrides insserv: warning: script 'LOCAL-fw' missing LSB tags and overrides userdel: user Debian-gdm is currently logged in /usr/sbin/deluser: `/usr/sbin/userdel Debian-gdm' returned error code 8. Exiting. /usr/sbin/delgroup: `Debian-gdm' still has `Debian-gdm' as their primary group! dpkg: error processing gdm3 (--purge): subprocess installed post-removal script returned error exit status 128 Processing triggers for man-db ... configured to not write apport reports Processing triggers for gconf2 ... Processing triggers for hicolor-icon-theme ... Errors were encountered while processing: gdm3 E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdm3 depends on: ii accountsservice0.6.15-2 ii adduser3.113 ii awesome [x-window-manager] 3.4.11-1 ii dconf-gsettings-backend0.10.0-3 ii debconf [debconf-2.0] 1.5.41 ii flwm [x-window-manager]1.02+cvs20080422-9 ii fvwm [x-window-manager]1:2.5.30.ds-1 ii gconf2 2.32.4-1 ii gnome-session-bin 3.2.1-1 ii gsettings-desktop-schemas 3.2.0-2 ii libaccountsservice00.6.15-2 ii libatk1.0-02.2.0-2 ii libattr1 1:2.4.46-5 ii libaudit0 1.7.18-1 ii libc6 2.13-24 ii libcairo-gobject2 1.10.2-6.2 ii libcairo2 1.10.2-6.2 ii libcanberra-gtk3-0 0.28-3 ii libcanberra0 0.28-3 ii libdbus-1-31.4.16-1 ii libdbus-glib-1-2 0.98-1 ii libfontconfig1 2.8.0-3 ii libfreetype6 2.4.8-1 ii libgconf2-42.32.4-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libglib2.0-0 2.30.2-4 ii libglib2.0-bin 2.30.2-4 ii libgtk-3-0 3.2.3-1 ii libpam-modules 1.1.3-6 ii libpam-runtime 1.1.3-6 ii libpam0g 1.1.3-6 ii libpango1.0-0 1.29.4-2 ii librsvg2-common2.34.2-2 ii libselinux12.1.0-4 ii libupower-glib10.9.15-1 ii libwrap0 7.6.q-22 ii libx11-6 2:1.4.4-4 ii libxau61:1.0.6-4 ii libxdmcp6 1:1.1.0-4 ii libxklavier16 5.1-3 ii libxrandr2 2:1.3.2-2 ii lsb-base 3.2-28 ii lxsession [x-session-manager] 0.4.6.1-1 ii openbox [x-window-manager] 3.5.0-2 ii policykit-1-gnome 0.105-1 ii upower 0.9.15-1 ii xfce4-session [x-session-manager] 4.8.2-3 ii xfwm4 [x-window-manager] 4.8.3-1 ii xterm [x-terminal-emulator]276-2 Versions of packages gdm3 recommends: ii at-spi 1.32.0-1 ii desktop-base 6.0.7 ii gnome-icon-theme 3.2.1.2-1 ii gnome-power-managernone ii gnome-settings-daemon none ii x11-xkb-utils 7.6+4 ii xserver-xephyr 2:1.11.3.901-2 ii xserver-xorg 1:7.5+8 ii zenity 3.2.0-1 Versions of packages gdm3 suggests: pn gnome-mag none pn gnome-orcanone pn gok none pn libpam-gnome-keyring 3.2.2-1 pn metacity none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of
Bug#656766: xscreensaver seems to ignore pam-blocked accounts
On Sat, Jan 21, 2012 at 06:21:01PM +0100, Yann Dirson wrote: In fact, the source says: /* We don't actually care if the account modules fail or succeed, * but we need to run them anyway because certain pam modules * depend on side effects of the account modules getting run. */ Looks like this decision was done using wrong assumptions. Not being familiar with libpam, I won't risk to propose a patch, but will be glad to test one. Well, it was too annoying, and I finally got a round tuit. You'll find my patch in branch 656766. Works fine here for now. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622395: Bug#389258: Request for permission to NMU memtest86
On Fri, Jan 27, 2012 at 11:50:24PM +0100, Aurelien Jarno wrote: The current version of memtest86 in unstable is 3 years old, and doesn't really support machines with = 4GB of RAM. Given this kind of machine is quite common nowadays, memtest86 is not really usable anymore. Version 4.0a supports 4GB of RAM, and is also able to use multiple CPUs for faster and better testing. The patch below is the diff of the debian/ directory necessary to bring the version to 4.0a. It can be used directly with the upstream tarball. Would it be possible to upload it as an NMU? OK, please do. Thanks! --- memtest86-3.5/debian/changelog2012-01-27 11:36:16.0 +0100 +++ memtest86-4.0a/debian/changelog 2012-01-27 11:34:08.590168321 +0100 @@ -1,3 +1,13 @@ +memtest86 (4.0a-0.1) unstable; urgency=low + + * Non-maintainer upload. + * New upstream version (Closes: #622395): +- Support machines with = 4GB of RAM. Closes: #522525, #572347, #582610, + #647756. +- Fix build with -O3. Closes: #389258. + + -- Aurelien Jarno aure...@debian.org Fri, 27 Jan 2012 23:49:59 +0100 + memtest86 (3.5-2.3) unstable; urgency=low * Non-maintainer upload. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657119: python2.7: stopped to provide python-argparse, forces install of python2.6
Package: python2.7 Version: 2.7.2-13 X-Debbugs-CC: python-argpa...@packages.debian.org A number of packages in the archive Depend on python-argparse, and until 2.7.2-12, python2.7 has provided this virtual package. -13 seems to drop this Provides, without a word in changelog.Debian, and the way to allow this new version to be installed without dropping any argparse-using package seems to install python2.6 and the compat python-argparse package. -- Yann Dirson - Bertin Technologies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657205: python-qt4-doc: qtdemo cannot launch a number of examples, and gives no hint
Package: python-qt4-doc Version: 4.9-2 Severity: normal I have not attempted to run all of the demos, but there are at least 3 categories of failure, with some examples listed here. Do they require additional packages ? are they not shipped because of DFSG conformance ? unsupported ? just broken ? Furthermore, there is very few info about how to use this tool, it could be good to advertise qtdemo.py -help in the README file, although the short help is not enough to understand what they are supposed to do (ever tried eg. -menu1 ?), it may be worth to point the reader to qtdemo/colors.py as where to start to look at to understand them, it's not they place where sane people would look first, IMHO. Using qtdemo.py -verbose does not help. So here is the list: * those that don't say a thing - painting / basicdrawing - painting / svg - demos / textedit - demos / embedded * those that say Could not launch the example. Ensure that it has been built. - demos / samegame * those for which the demo does not find doc about - demos / minehunt (which does launch, but only to a white window) - demos / osm (which does work) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-qt4-doc depends on: ii libjs-jquery 1.7.1-1 python-qt4-doc recommends no packages. Versions of packages python-qt4-doc suggests: ii qt4-doc 4:4.7.3-5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657211: python-qt4-doc: corkboards example fails saying Day is not a type
Package: python-qt4-doc Version: 4.9-2 Severity: normal The corkboards example fails with the following error: file:///usr/share/doc/python-qt4-doc/examples/declarative/toys/corkboards/corkboards.qml:113:19: Day is not a type -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-qt4-doc depends on: ii libjs-jquery 1.7.1-1 python-qt4-doc recommends no packages. Versions of packages python-qt4-doc suggests: ii qt4-doc 4:4.7.3-5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#349000: xscreensaver: New Login via gdmflexiserver impossible when 2 or more
Does adding the option systematically prevent gdm3 to work ? If no, the solution is obvious; if yes, then xscreensaver cannot be made to work with old gdm and needs a Break: gdm statement. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656766: xscreensaver seems to ignore pam-blocked accounts
Package: xscreensaver Version: 5.15-2 Severity: important Ob-important: pam-aware program apparently not respecting user policy Adding the following to common-account and setting up a config in time.conf does result in users getting barred from eg. login, and does trigger a xscreensaver: pam_time: user xxx rejected trace thanks to the debug flag, but xsceensaver nevertheless unlocks the session. I don't think that's normal at all... account required pam_time.so debug -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-0 2.2.0-2 ii libc6 2.13-24 ii libcairo2 1.10.2-6.2 ii libfontconfig1 2.8.0-3 ii libfreetype62.4.8-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libglade2-0 1:2.6.4-1 ii libglib2.0-02.30.2-4 ii libgtk2.0-0 2.24.8-2 ii libice6 2:1.0.7-2 ii libpam0g1.1.3-6 ii libpango1.0-0 1.29.4-2 ii libsm6 2:1.2.0-2 ii libx11-62:1.4.4-4 ii libxext62:1.3.0-3 ii libxi6 2:1.4.5-1 ii libxinerama12:1.1.1-3 ii libxml2 2.7.8.dfsg-5.1 ii libxmu6 2:1.1.0-3 ii libxpm4 1:3.5.9-4 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.6-2 ii libxt6 1:1.1.1-2 ii libxxf86vm1 1:1.1.1-2 ii xscreensaver-data 5.15-2 Versions of packages xscreensaver recommends: ii libjpeg-progs 8c-2 ii perl [perl5]5.14.2-6 ii wamerican-large [wordlist] 7.1-1 ii wfrench [wordlist] 1.2.3-9 Versions of packages xscreensaver suggests: pn chromium [www-browser] 15.0.874.121~r109964-1 pn elinks [www-browser] 0.12~pre5-7 pn fortune-mod [fortune]1:1.99.1-4 pn gdm3 | kdm-gdmcompat none pn iceweasel [www-browser] 8.0-3+b1 pn links2 [www-browser] 2.5-1 pn lynx-cur [www-browser] 2.8.8dev.9-3 pn qcam | streamer none pn uzbl [www-browser] 0.0.0~git.2028-1 pn xdaliclock none pn xfishtanknone pn xscreensaver-gl none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656766: xscreensaver seems to ignore pam-blocked accounts
In fact, the source says: /* We don't actually care if the account modules fail or succeed, * but we need to run them anyway because certain pam modules * depend on side effects of the account modules getting run. */ Looks like this decision was done using wrong assumptions. Not being familiar with libpam, I won't risk to propose a patch, but will be glad to test one. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655251: wxwidgets2.8: debug packages are useless to gdb
On Wed, Jan 11, 2012 at 03:35:27PM +1300, Olly Betts wrote: severity 655251 wishlist thanks On Mon, Jan 09, 2012 at 09:51:21PM +0100, Yann Dirson wrote: With both -dbg packages installed, gdb still cannot provide any sourceline information in backtraces. Looks like for some reason the provided files are shipped in /usr/lib/$ARCH with special names, instead of /usr/lib/$ARCH/debug with the original name. Symlinking them from /usr/lib/$ARCH/debug does not appear to work, though. How are those packages supposed to be used at all ? The lone decade-old /usr/share/doc/libwxbase2.8-0/README.Debian makes me suspicious it has nothing to do with the modern infrastructure in /usr/lib/debug. The package description seems fairly clear to me: This package provides a debug version of the wxGTK library. It is compiled both with -g for normal debugger tracing and with the __WXDEBUG__ flag which provides many internal checks by wxWidgets itself that are not performed on apps compiled with the 'release version' libs in the -dev package. So these -dbg packages aren't detached debug symbols as is typical for packages so named. Ron and I talked about this a few months ago and concluded that it would be less confusing to rename them to something else, but that it was probably not worth the disruption it would cause to do so for wx2.8, so the intention is to make this change in wx2.9/3.0 instead. As far as I can see, policy doesn't say that packages named -dbg have to contain detached debug symbols, nor that library packages have to provide detached debug symbols, so I'm setting the severity appropriately. Fair enough, this is more of an old-style -dbg package. But this seems to mean there is no way of providing a proper backtrace when reporting a crash of a wx app, right ? See eg. Bug#655280. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655280: gspiceui: segfaults when switching from gnucap to ngspice after a simulation
On Wed, Jan 11, 2012 at 09:09:44AM +0100, Gudjon I. Gudjonsson wrote: Hi Yann Does it work for ngspice if you start it as an ngspice simulator? In the case of the simulation currently loaded there are errors, which I have myself trouble to parse, and for which gspiceui displays an error popup without a message - I suspect the problem to come from a node named +5V by geda. Can you please send me the troubling schematic, or some simplified one. I'll try to, but it was after a long time of not using gspiceui so I had forgotten a bit about how it was supposed to be used, and I will have to attempt to recreate the simulation itself, just opening the schematic was not enough to get any simulation at all. And if so, do you need to be able to switch simulator during a session? I'm still discovering the tools, and thought that asking the other simulator when one does not give a clear-enough-for-me diag was a good way of getting some help without bothering an expert right away. I have to admit that I use easy_spice myself but since gspiceui seems much more promising I chose to package it. Well, after sorting out how gspiceui works, I indeed found myself completely lost when I had a look at easy_spice - the latter really looks very primitive compared to gspiceui, I'm looking forward to see a stable gspiceui :) Version 1.0.0 is packaged and can be found at mentors.debian.net. I will try to find a sponsor and see if solves the problem. Ah, that seems to advocate *me* being the sponsor, right ? :) Well, I just meant you could use it but I never say no to a sponsor :) The package can be found at: http://mentors.debian.net/debian/pool/main/g/gspiceui/gspiceui_1.0.00+dfsg-1.dsc There is no README.source file but the get-orig-source target in the rules file creates the +dfsg files correctly. OK I'll tryto find some time for this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
