Bug#763335: jam -- Add support for multiarch
On Mon, Sep 29, 2014 at 02:22:18PM +0200, Jörg Frings-Fürst wrote: jam has no support for multiarch. Are you thinking about any particular problem ? 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#763390: bash: malloc assertion failed at bashline.c:1745
Package: bash Version: 4.3-9.2 Severity: normal I messed my fingers while editing a commandline and trying to get a a completion, resulting in this assertion: yann@home:omaha2 (wip/multistep|REBASE-i 54/60)$ noset Omaha.test.test_shogi:test_loadpgn yann@home:omaha2 (wip/multistep|REBASE-i 54/60)$ yann@home:omaha2 (wip/multistep|REBASE-i 54/60)$ nosete Omaha.test.test_shogi:test_loadpgn malloc : .././bashline.c:1745 : assertion manquée free : appelé avec un bloc déjà libéré comme argument dernière commande : ./scripts/omaha Omaha.test.test_shogi:test_loadpgn Annulation... The cursor was after the nosete string, and I expected the completion to find nosetests. I had just modified the line, from the previous command, and a couple of unwanted keystrokes had resulted in psychadelic results that are hard to describe after the fact (notably insertion of unwanted text of undetermined origin). Could not reproduce afterwards. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bash depends on: ii base-files 7.5 ii dash 0.5.7-4 ii debianutils 4.4 ii libc62.19-11 ii libtinfo55.9+20140913-1 Versions of packages bash recommends: ii bash-completion 1:2.1-4 Versions of packages bash suggests: pn bash-doc none -- Configuration Files: /etc/bash.bashrc 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#763160: gcc-4.7: suggests non-existant packages: libmudflap0*, libppl9, libpwl5, libcloog-ppl0
Package: gcc-4.7 Version: 4.7.4-2 Severity: normal Some of those packages seem to have differnt version numbers now, it is not clear whether the new versions would help. Some others are just not in the archive anymore (mudflap). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.7 depends on: ii binutils2.24.51.20140903-1 ii cpp-4.7 4.7.4-2 ii gcc-4.7-base4.7.4-2 ii libc6 2.19-11 ii libgcc-4.7-dev 4.7.4-2 ii libgmp102:6.0.0+dfsg-6 ii libmpc3 1.0.2-1 ii libmpfr43.1.2-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages gcc-4.7 recommends: ii libc6-dev 2.19-11 Versions of packages gcc-4.7 suggests: ii binutils [binutils-gold] 2.24.51.20140903-1 ii gcc-4.7-doc 4.7.4-1 pn gcc-4.7-locales none pn gcc-4.7-multilib none ii libcloog-ppl0 0.15.11-5 pn libgcc1-dbg none pn libgomp1-dbg none pn libitm1-dbg none pn libmudflap0-4.7-dev none pn libmudflap0-dbg none ii libppl-c4 1:1.1-3 ii libppl9 0.11.2-8 pn libpwl5 none pn libquadmath0-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#763161: gcc-4.8: suggests non-existant packages: binutils-gold, libbacktrace1-dbg
Package: gcc-4.8 Version: 4.8.3-11 Severity: normal Those packages are apparently not part of Debian any more. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.8 depends on: ii binutils2.24.51.20140903-1 ii cpp-4.8 4.8.3-11 ii gcc-4.8-base4.8.3-11 ii libc6 2.19-11 ii libcloog-isl4 0.18.2-1 ii libgcc-4.8-dev 4.8.3-11 ii libgmp102:6.0.0+dfsg-6 ii libisl100.12.2-2 ii libmpc3 1.0.2-1 ii libmpfr43.1.2-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages gcc-4.8 recommends: ii libc6-dev 2.19-11 Versions of packages gcc-4.8 suggests: ii binutils [binutils-gold] 2.24.51.20140903-1 ii gcc-4.8-doc 4.8.3-1 pn gcc-4.8-locales none pn gcc-4.8-multilib none pn libasan0-dbg none pn libatomic1-dbgnone pn libbacktrace1-dbg none pn libgcc1-dbg none pn libgomp1-dbg none pn libitm1-dbg none pn libquadmath0-dbg none pn libtsan0-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#763162: gcc-4.9: suggests non-existant packages: binutils-gold, libvtv0-dbg
Package: gcc-4.9 Version: 4.9.1-14 Severity: normal The gcc-4.9 source does not build libvtv any more but the deb still suggests it. Binutils-gold is not a separate package any more. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.9 depends on: ii binutils2.24.51.20140903-1 ii cpp-4.9 4.9.1-14 ii gcc-4.9-base4.9.1-14 ii libc6 2.19-11 ii libcloog-isl4 0.18.2-1 ii libgcc-4.9-dev 4.9.1-14 ii libgmp102:6.0.0+dfsg-6 ii libisl100.12.2-2 ii libmpc3 1.0.2-1 ii libmpfr43.1.2-1 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages gcc-4.9 recommends: ii libc6-dev 2.19-11 Versions of packages gcc-4.9 suggests: ii binutils [binutils-gold] 2.24.51.20140903-1 ii gcc-4.9-doc 4.9.1-2 pn gcc-4.9-locales none ii gcc-4.9-multilib 4.9.1-14 pn libasan1-dbg none pn libatomic1-dbgnone pn libcilkrts5-dbg none pn libgcc1-dbg none pn libgomp1-dbg none pn libitm1-dbg none pn liblsan0-dbg none pn libquadmath0-dbg none pn libtsan0-dbg none pn libubsan0-dbg none pn libvtv0-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#763274: lisaac: homepage link is dead
Source: lisaac Version: 1:0.39~rc1-3 Severity: normal lisaac.org looks as if cybersquatted... -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, 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#762729: lightdm: shows systemd-related error on reconfigure when kdm is the default
Package: lightdm Version: 1.10.1-3 Severity: normal I have kdm set to be the default display manager, although I also have lightdm installed for testing purposes. After switching from sysvinit to systemd, when running dpkg-reconfigure lightdm, after confirming my kdm choice, I get the following error: ERROR: /lib/systemd/system/kdm.service is the selected default display manager but does not exist This message does not occur when I do the same choice with dpkg-reconfigure kdm (which apparently does not know about systemd), but does not appear either when I dpkg-reconfigure slim (which does seem to know about systemd). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.6-4 ii dbus 1.8.6-2 ii debconf [debconf-2.0] 1.5.53 ii libc6 2.19-11 ii libgcrypt111.5.4-3 ii libglib2.0-0 2.40.0-5 ii libpam-systemd 208-8 ii libpam0g 1.1.8-3.1 ii libxcb11.10-3 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: pn accountsservice none ii upower 0.99.1-3 -- debconf information: * shared/default-x-display-manager: kdm lightdm/daemon_name: /usr/sbin/lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762731: lightdm: issues strange error message when requested to start but is non-default dm
Package: lightdm Version: 1.10.1-3 Severity: normal kdm is the default dm here, and I just switched from systemd. When hunting various dm issues, I found that asking lightdm to start results in the following unexpected error (it does start as expected when set to be the default, however). It should surely check the default dm settings, like eg. xdm does, and does not even attempt to start. # service lightdm start Job for lightdm.service failed. See 'systemctl status lightdm.service' and 'journalctl -xn' for details. # systemctl status lightdm.service lightdm.service - Light Display Manager Loaded: loaded (/lib/systemd/system/lightdm.service; enabled) Active: failed (Result: start-limit) since mer. 2014-09-24 21:13:26 CEST; 1min 55s ago Docs: man:lightdm(1) Process: 8079 ExecStartPre=/bin/sh -c [ $(cat /etc/X11/default-display-manager 2/dev/null) = /usr/sbin/lightdm ] (code=exited, status=1/FAILURE) Main PID: 7122 (code=exited, status=0/SUCCESS) sept. 24 21:13:25 home systemd[1]: Failed to start Light Display Manager. sept. 24 21:13:25 home systemd[1]: Unit lightdm.service entered failed state. sept. 24 21:13:26 home systemd[1]: lightdm.service holdoff time over, scheduling restart. sept. 24 21:13:26 home systemd[1]: Stopping Light Display Manager... sept. 24 21:13:26 home systemd[1]: Starting Light Display Manager... sept. 24 21:13:26 home systemd[1]: lightdm.service start request repeated too quickly, refusing to start. sept. 24 21:13:26 home systemd[1]: Failed to start Light Display Manager. sept. 24 21:13:26 home systemd[1]: Unit lightdm.service entered failed state. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.6-4 ii dbus 1.8.6-2 ii debconf [debconf-2.0] 1.5.53 ii libc6 2.19-11 ii libgcrypt111.5.4-3 ii libglib2.0-0 2.40.0-5 ii libpam-systemd 208-8 ii libpam0g 1.1.8-3.1 ii libxcb11.10-3 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: pn accountsservice none ii upower 0.99.1-3 -- debconf information: * shared/default-x-display-manager: kdm lightdm/daemon_name: /usr/sbin/lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762731: [Pkg-xfce-devel] Bug#762731: lightdm: issues strange error message when requested to start but is non-default dm
On Wed, Sep 24, 2014 at 09:24:59PM +0200, Yves-Alexis Perez wrote: On mer., 2014-09-24 at 21:17 +0200, Yann Dirson wrote: kdm is the default dm here, and I just switched from systemd. When hunting various dm issues, I found that asking lightdm to start results in the following unexpected error (it does start as expected when set to be the default, however). It should surely check the default dm settings, like eg. xdm does, and does not even attempt to start. Well, that's exactly what it's doing… I'm not sure if you're saying that it does check the dm settings. If it's the case, then it looks like it causes the service start to error out, causing systemd to retry to launch it, whereas it is a perfectly legal situation for a dm to be disabled. In that case, it is a change from what we've been used to, and I'm not sure to see the advantages of doing so. I tried to lookup any policy information about display managers, but could not find any. That makes me even more curious about how the collaboration among maintainers of dm packages is organized. The only mildly-official page that is mildly relevant to how an admin can deal with dm's (that I could find) is https://wiki.debian.org/DisplayManager, and it does not say anything on that matter either. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762729: [Pkg-xfce-devel] Bug#762729: lightdm: shows systemd-related error on reconfigure when kdm is the default
On Wed, Sep 24, 2014 at 09:13:15PM +0200, Yves-Alexis Perez wrote: On mer., 2014-09-24 at 21:02 +0200, Yann Dirson wrote: Package: lightdm Version: 1.10.1-3 Severity: normal I have kdm set to be the default display manager, although I also have lightdm installed for testing purposes. After switching from sysvinit to systemd, when running dpkg-reconfigure lightdm, after confirming my kdm choice, I get the following error: ERROR: /lib/systemd/system/kdm.service is the selected default display manager but does not exist This message does not occur when I do the same choice with dpkg-reconfigure kdm (which apparently does not know about systemd), but does not appear either when I dpkg-reconfigure slim (which does seem to know about systemd). My guess is that they don't handle the default display manager unit file. I'm not familiar with systemd yet - I assume that by unit file you mean something like what's described in systemd.unit(5). As far as I've understood the systemd migration, Debian should still support good old init.d scripts, which is what kdm and xdm still use. Why then would they be required to get information for a systemd-specific file, to do a job they've basically always done right ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762731: [Pkg-xfce-devel] Bug#762731: lightdm: issues strange error message when requested to start but is non-default dm
On Wed, Sep 24, 2014 at 09:47:47PM +0200, Yves-Alexis Perez wrote: On mer., 2014-09-24 at 21:44 +0200, Yann Dirson wrote: On Wed, Sep 24, 2014 at 09:24:59PM +0200, Yves-Alexis Perez wrote: On mer., 2014-09-24 at 21:17 +0200, Yann Dirson wrote: kdm is the default dm here, and I just switched from systemd. When hunting various dm issues, I found that asking lightdm to start results in the following unexpected error (it does start as expected when set to be the default, however). It should surely check the default dm settings, like eg. xdm does, and does not even attempt to start. Well, that's exactly what it's doing… I'm not sure if you're saying that it does check the dm settings. If it's the case, then it looks like it causes the service start to error out, causing systemd to retry to launch it, whereas it is a perfectly legal situation for a dm to be disabled. In that case, it is a change from what we've been used to, and I'm not sure to see the advantages of doing so. Well, the same thing happens with sysvrc, the init.d script checks for the default display manager and errors out if it's not the selected one. AFAICT, it really looks like it just does exit 0, as do other DMs. I tried to lookup any policy information about display managers, but could not find any. That makes me even more curious about how the collaboration among maintainers of dm packages is organized. See #733220 You mean, bugreports are the only collaboration ? I would have thought that eg. the debconf stuff that has to be shared (duplicated ?) in the various DM packages, could come from a central package (a debhelper tool ?), around which some sort of DM policy would live ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563000: closed by Sandro Tosi mo...@debian.org (Re: [Python-apps-team] Bug#563000: pylint: wrongly tries to open emacs locks)
reopen 563000 ydir...@free.fr found 563000 pylint/1.3.0-1 thanks On Fri, Sep 19, 2014 at 9:28 PM, Sandro Tosi mo...@debian.org wrote: Bug reporter's email is failing, so no confirmation is possible - closing. Looks like I did not get or missed that email (that old account is known to be unreliable). Is this still happening with the latest version of pylint in sid? The problem still happens today: * Module Omaha.Games.abstract..#PlayerPools F: 1, 0: error while code parsing: Unable to load file '/work/yann/games/omaha2/Omaha/Games/abstract/.#PlayerPools.py' ([Errno 2] No such file or directory: '/work/yann/games/omaha2/Omaha/Games/abstract/.#PlayerPools.py') (parse-error) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761649: lintian: could warn about files installed in /usr/share/mime/ other than in packages/
Package: lintian Version: 2.5.26 Severity: wishlist The spec in /usr/share/doc/shared-mime-info/ tells that most stuff under /usr/share/mime/ is a cache generated from /usr/share/mime/packages/. This was arguably a design decision that violates the FHS and does not help anyone to understand what's going on, and when some upstream packages installs such a file by error, it's not so easy to track the reason for the resulting piuparts failures (see http://bugs.debian.org/749582 and http://bugs.debian.org/726799) A lintian check seems to be a good idea in that case. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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.24.51.20140903-1 ii bzip2 1.0.6-7 ii diffstat 1.58-1 ii file 1:5.19-2 ii gettext0.19.2-2 ii hardening-includes 2.5+nmu1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b2 ii libarchive-zip-perl1.38-1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.37-1+b1 ii libdpkg-perl 1.17.13 ii libemail-valid-perl1.194-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2+b1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.09-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.64-1 ii man-db 2.6.7.1-1 ii patchutils 0.3.3-1 ii perl [libdigest-sha-perl] 5.20.0-6 ii t1utils1.37-2 Versions of packages lintian recommends: ii libautodie-perl 2.25-1 ii libperlio-gzip-perl 0.18-3+b1 ii perl5.20.0-6 ii perl-modules [libautodie-perl] 5.20.0-6 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.13 ii libhtml-parser-perl3.71-1+b2 ii libtext-template-perl 1.46-1 ii libyaml-perl 1.09-1 ii xz-utils 5.1.1alpha+20120614-2 -- 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#726799: #726799: not a shared-mime-info bug726...@bugs.debian.org
On Sun, Sep 14, 2014 at 01:44:01PM +0200, Pino Toscano wrote: On 2014-09-14 13:28, Yann Dirson wrote: On Sun, Sep 14, 2014 at 10:12:41AM +0200, Pino Toscano wrote: Hi, first of all, the behaviour of update-mime-database is correct: it deletes files in *generated* directories. Yes, the various application, audio, text, subdirectories under /usr/share/mime are business of update-mime-database, where it places the XML mimetypes generated from the XML definitions in /usr/share/mime/packages. It is exactly in this directory where applications should install XML definitions of mime types to have them registered in the XDG mime type system. Installing stuff directly to e.g. /usr/share/mime/text is like installing to, say, /var/cache (i.e., you shouldn't). Furthermore, qgo is installing wrong things, and I will send the proper explanation and fix to #749582. This is not a bug in shared-mime-info, hence closing. Ah, that's interesting. But then: * why are those directories in /usr/ and not in /var/ in the first place ? Isn't this part of the shared-mime-info spec against the spirit of the FHS ? Possibly, although changing at this point is not exactly an easy task. Well, if it's just a cache, there should not be too much problems, I guess. If any of this has to be used externally (ie. has been made part of an official API), then probably symlinks to /var would have to be generated for some transition period - but we've been through a number of more disruptive transitions, I'd say :) * if it is deemed the right place for generated files, then we surely want a lintian check to spot the problem early Feel free to file a wishlist bug for lintian. Done. * the update-mime-database manpage is quite terse, and does not explain that different parts of MIME-DIR have different roles. It is awkward to have to read the spec to get such important information I guess you are referring to the update-mime-database man page, right? This seems just specific to the tool itself, so IMHO what it lacks is pointers to the specifications. Another option would be having the specifications themselves as man page. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749582: #749582: qgo installs a generated file
On Sun, Sep 14, 2014 at 01:34:17PM +0200, Pino Toscano wrote: This has been forwarded [1] and accepted upstream. That's cool, thanks work working this out :) Maybe we'd want to go further in MIME-related cleanups ? * submitted a patch for multi-file handling in qgo.desktop * if the official MIME-type to be used is application/x-go-sgf, wouldn't it be better to use it in qgo.desktop ? (not sure if it has any impact, since there is a text/x-sgf alias) * there is an src/sgf.desktop file, that gets installed to /usr/share/mimelnk/text/, which seems to describe yet another MIME type (text/go-sgf). Not sure who uses that file anyway: we have no dpkg trigger on this, a fedora18-era (not so old) book says that KDE uses this to build the main menu, and some info from 2004 mentionned that at that time a special package installed files there for openoffice integration with KDE. Given the few files remaining there, I'd be tempted to think it's not of any use whatsover nowadays. 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#761421: gdb-python2: does not tell what the package is
Package: gdb-python2 Version: 7.8-1 Severity: normal There is only generic gdb2 info in this package's description, and that description does not mention python as supported by gdb. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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#749582: qgo: file goes missing after upgrade from jessie
block 749582 by 726799 thanks On Wed, May 28, 2014 at 12:22:09PM +0200, Holger Levsen wrote: Package: qgo Version: 2.1~git-20140518-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package looses a file while upgrading from jessie to sid. That's a clear sign of some error, (without analysing it) I just don't know causes this... :-) From the attached log (scroll to the bottom...): 1m6.6s ERROR: FAIL: debsums reports modifications inside the chroot: debsums: missing file /usr/share/mime/text/x-sgf.xml (from qgo package) This is the same as bug 726799, which has been reassigned to shared-mime-info some time ago. Let's keep that one open as an reminder so that a new one does not get opened next month :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753627: Please accept proposed patch for memtest86+ 5.01 or fix grave bug in anotger way
On Wed, Sep 10, 2014 at 11:02:02AM +0300, UAB 'Bona Mens' wrote: On Sun, Aug 31, 2014, Yann Dirson ydir...@free.fr wrote: If nobody has the detailed info, I'll try to find the time this week to identify the faulty flag. Please accept proposed patch for memtest86+ 5.01 or fix grave bug in anotger way :) Right, it does not much good to wait - let's see how that one will break ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760816: fairymax: new upstream available
Package: fairymax Version: 4.8q-2 Severity: wishlist Current version is 4.8s. It's been out for 18 months, probably a watch file would help. I realize upstream does not ship numbered tarballs, but his git repos can be polled, like I do eg. in hachu: http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=hachu.git;a=tags \ /cgi-bin/gitweb.cgi\?p=hachu.git;a=shortlog;h=refs/tags/(.+) s/hachu/fairymax/ should do the trick. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 fairymax depends on: ii libc6 2.19-10 fairymax recommends no packages. fairymax 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#760816: fairymax: new upstream available
On Mon, Sep 08, 2014 at 08:14:05AM -0400, Vincent Legout wrote: Hi Yann, Yann Dirson ydir...@free.fr writes: Current version is 4.8s. It's been out for 18 months, probably a watch file would help. I realize upstream does not ship numbered tarballs, but his git repos can be polled, like I do eg. in hachu: http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=hachu.git;a=tags \ /cgi-bin/gitweb.cgi\?p=hachu.git;a=shortlog;h=refs/tags/(.+) s/hachu/fairymax/ should do the trick. Thanks for letting me know, I didn't notice the new version. I'll add the watch file and update the package soon. Cool, thanks. Also note that today's activity on the repo hints for an uncoming 4.8t :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753627: memtest86+: Bug #753627 confirmed
On Sun, Aug 31, 2014 at 01:09:31AM +0100, Jose M Calhariz wrote: I can confirm the Bug. Following the discussion in http://forum.canardpc.com/threads/83443-Memtest86-V5.01-crashes-with-gcc-4.7.2-or-later reducing the optimization from -O1 to -O0 and a small patch to the file io.h make memtest86 work again. Thanks for finding this! http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/SRPMS/core/release/memtest86+-5.01-5.mga4.src.rpm also have other interesting fixes, BTW. However I have issues with the patch: -O0 disables quite a lot of optimisations, and we surely don't want to disable all those that are not buggy. I haven't looked in depth, but the additional required changes are probably a consequence of this. Additionally, we don't even know what the gcc problem is, ir even if it has been reported to the gcc team. Having more detailed information would allow to link to 2 problems. If nobody has the detailed info, I'll try to find the time this week to identify the faulty flag. 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#759519: ITP: shogivar -- UI to play many shogi variants against human or computer
Package: wnpp Severity: wishlist Owner: Yann Dirson dir...@debian.org * Package name: shogivar Version : 1.55a+git Upstream Author : Steve Evans, H.G.Muller * URL : http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=shogivar.git;a=shortlog;h=refs/heads/C-port * License : GPL Programming Lang: C Description : UI to play many shogi variants, with builtin computer player This is a C/Gtk port by HGM of the Shogi Variants program written in VB for windows by S.Evans in the late 90's (http://www.users.on.net/~ybosde/), whose source was published in 2011 (https://groups.yahoo.com/neo/groups/shogivar/conversations/messages/1755), and finally released under the GPL at HGM's request. This is the only free-software program with an AI for most Shogi variants. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756856: xscorch: clean target removes shipped file
Package: xscorch Version: 0.2.1-1+b1 Severity: normal Tags: upstream File sgame/shelpdata.c is removed by debian/rules clean, but it is shipped in the source. There is probably no need to ship it to start with, since its removal does not prevent the build. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 xscorch depends on: ii libatk1.0-0 2.12.0-1 ii libc62.19-7 ii libcairo21.12.16-2 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.24-1 ii libmikmod3 3.3.6-4 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 Versions of packages xscorch recommends: ii xfonts-100dpi 1:1.0.3 xscorch 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#753516: Acknowledgement (xscorch: fails to parse its data file)
tags 753516 + patch upstream
thanks
The problem is caused by a use of strcpy for overlapping regions.
Patch attached, uploading NMU to the DELAYED queue.
Description: Use memmove instead of memcpy for overlapping src/dst
Author: Yann Dirson ydirson@free;fr
Bug-Debian: http://bugs.debian.org/753516
--- xscorch-0.2.1.orig/libj/jstr/str_trim.c
+++ xscorch-0.2.1/libj/jstr/str_trim.c
@@ -47,7 +47,7 @@ char *trim(char *s) {
SET_LAST_NWS(ws, s);
/* Copy the non-ws characters in s. */
- if(ws.fnws d) MEMCPY(d, ws.fnws, NWS_SIZE(ws));
+ if(ws.fnws d) MEMMOVE(d, ws.fnws, NWS_SIZE(ws));
*(d + NWS_SIZE(ws)) = '\0';
return(d);
@@ -93,7 +93,7 @@ char *ltrim(char *s) {
if(s != NULL) {
SKIM_WHITESPACE(s);
- MEMCPY(d, s, STRLEN(s) + 1);
+ MEMMOVE(d, s, STRLEN(s) + 1);
return(d);
}
return(NULL);
Bug#569813: There still is a potential purpose
Hi, On Mon, Jul 28, 2014 at 09:11:27PM -0700, Elliott Mitchell wrote: There is still a potential purpose for dh-kpatches. Maintainance of patches that are likely to remain outside the kernel (linux-patch-debianlogo) may remain easier with dh-kpatches. Additionally dh-kpatches may also fulfill the role of keeping kernel patch-handling UIs together, rather than having them drift apart; a change though is needed since instead of needing to be consistent for make-kpkg --added_patches, it needs to be handy for humans on a command-line. Isn't it simpler to import those patches in a git branch (if their home is not a git tree to start with, that is) and just manage them with git merge to apply them and git reset --hard to unapply them ? Or, possibly better, use git-reintegrate (which I incidentely uploaded to unstable a couple of days ago), which can even give you version-control of the baseline + patch sets you'll have used over time ? Right now I'm wondering whether try to take advantage of dh-kpatches for handling some special purpose patches, versus rolling my own for the situations *I* expect to handle. Notable weaknesses of dh-kpatches for my purposes, I need tarball handling and handling of hundreds of patches and a few patch dependancies. Why do bugs #355502 and #359063 remain unresolved 8 years after reportting when they seem near-trivial to solve? Mostly because I don't have any interest left in that package, and noone stepped for maintainance in 4 years despite the RFA. In fact, I should really orphan the package to reflect its true state... 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#756332: dh-make: sample new Vcs-Browser URLs are wrong
Package: dh-make Version: 1.20140617 Severity: normal Tags: patch A /gitweb component is missing from the anonscm URLs. Pushed a fix to branch fix-vcsbrowser. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 dh-make depends on: ii debhelper 9.20140613 ii dpkg-dev 1.17.10 ii make 4.0-8 ii perl 5.18.2-7 dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 11.6 -- 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#755957: ITP: git-reintegrate -- Git extension to manage integration branches
Package: wnpp Severity: wishlist Owner: Yann Dirson dir...@debian.org X-Debbugs-CC: Felipe Contreras felipe.contre...@gmail.com * Package name: git-reintegrate Version : 0.3 Upstream Author : Felipe Contreras felipe.contre...@gmail.com * URL : https://github.com/felipec/git-reintegrate * License : GPL Programming Lang: Ruby Description : Git extension to manage integration branches This tools allows to define which feature branches will be part of your integration branches, and help you update the latter as new versions of the feature branches are available. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753516: xscorch: fails to parse its data file
Package: xscorch Version: 0.2.1-1+b1 Severity: grave Not sure since when it started to fail, but it does not start up at all today: $ xscorch XScorch version 0.2.1 Copyright(c) 2000-2004 Justin David Smith Copyright(c) 2000-2009 Jacob Luna Lundberg Licensed under the GNU General Public License, version 2 See the Help menu for the license and a list of contributors. /usr/share/games/xscorch//profiles.def: error: Malformed value for tetRadius: 11 13 /usr/share/games/xscorch//profiles.def:9: error: Failed to add variable tetRadius to block Standard(7) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for mob: t true /usr/share/games/xscorch//profiles.def:11: error: Failed to add variable mob to block Standard(7) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for tetRadius: 11 13 /usr/share/games/xscorch//profiles.def:24: error: Failed to add variable tetRadius to block DoubleTrack(22) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for efiency: 1 115 /usr/share/games/xscorch//profiles.def:26: error: Failed to add variable efiency to block DoubleTrack(22) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for hness: 99 90 /usr/share/games/xscorch//profiles.def:27: error: Failed to add variable hness to block DoubleTrack(22) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for mob: t true /usr/share/games/xscorch//profiles.def:28: error: Failed to add variable mob to block DoubleTrack(22) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for tetRadius: 11 13 /usr/share/games/xscorch//profiles.def:41: error: Failed to add variable tetRadius to block Fortification(39) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for haess: 1 125 /usr/share/games/xscorch//profiles.def:43: error: Failed to add variable haess to block Fortification(39) (continuable error) /usr/share/games/xscorch//profiles.def: error: Malformed value for mobi: falsese /usr/share/games/xscorch//profiles.def:44: error: Failed to add variable mobi to block Fortification(39) (continuable error) /usr/share/games/xscorch//profiles.def: warning: __null isn't a valid class in this context, for variable Standard. /usr/share/games/xscorch//profiles.def: warning: __null isn't a valid class in this context, for variable DoubleTrack. /usr/share/games/xscorch//profiles.def: warning: __null isn't a valid class in this context, for variable Fortification. config_new: failed to build tanks_profile, or no tanks in def file. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 xscorch depends on: ii libatk1.0-0 2.12.0-1 ii libc62.19-4 ii libcairo21.12.16-2 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.24-1 ii libmikmod3 3.3.6-2 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 Versions of packages xscorch recommends: ii xfonts-100dpi 1:1.0.3 xscorch 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#753223: libc0.3-dev: signal.h and other require size_t definition
Source: libc0.3-dev Version: 2.18-3 Severity: important gnushogi fails to build on hurd-i386 [1], because /usr/include/i386-gnu/bits/thread-attr.h, indirectly included by signal.h, uses size_t without including a proper header for its definition. [1] https://buildd.debian.org/status/fetch.php?pkg=gnushogiarch=hurd-i386ver=1.4.2-3stamp=1398220374 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
found 726799 shared-mime-info/1.2-1 thanks On Sat, Jun 21, 2014 at 03:40:34PM +0200, intrigeri wrote: Hi, is there any indication that this bug does *not* affect the version currently in testing (1.2-1)? As impacting 1.0 and 1.3, it would be have been funny not to affect 1.2. Just downgraded it for a check, and I confirm 1.2-1 is impacted too. If not, maybe we should mark it as affected too, so that this bug doesn't block the migration of 1.3-1 to testing for wrong reasons. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#304997: gcompris: real fullscreen support
tags 304997 fixed-upstream thanks This is addressed in the ongoing rewrite to use Qt. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748796: piuparts: should not use dist-upgrade to check for a single package upgrade
On Wed, May 21, 2014 at 11:33:19PM +0200, Andreas Beckmann wrote: On 2014-05-21 13:08, Holger Levsen wrote: On Dienstag, 20. Mai 2014, Yann Dirson wrote: http://bugs.debian.org/726799 shows that, while using dist-upgrade may be useful and can reveal problems, it does not test *just* the package upgrade it claims to be testing (sounds obvious, but well... ;). Yes, it's obvious and I'd also argue it's obviously the right thing to do. So in fact I'm also considering to just close your bug (as not a bug, but design) and/or make it wishlist and close it then. The usual way to upgrade the system is precisely to use apt-get upgrade or apt-get dist-upgrade and _not_ to upgrade a single package with apt-get install $package/$version - that's not a common real world use case. Right, but that's the point of unitary testing in general: uncovering potential problems before they bite. Something that is more common is, on a machine which has not been updated in a long time (yes, I occasionally get my hands on such badly-maintained beasts, unfortunately), and there is an urgent task to achieve that requires a new package or a new version of a package. There, aptitude helps much in selecting the minimal set of packages to upgrade, and the situation is much closer to single-package upgrade than to dist-upgrade. Not sure if there is a 100% accurate way to get that minimal set without interaction, though, but if there were, that could provide an interesting way of testing, that would be an intermediate between install and dist-upgrade. IIRC piuparts even did the apt-get install way in the past - this usually failed if the upgrade involved a bigger transition that requires removal of some packages... I might consider doing apt-get install upgrade tests (since they operate on valid systems as long as no --force-* options get involved) in addition to the normal distupgrade tests if they can uncover problems not found by distupgrade tests - but only if they don't create false positives (or these can be filtered automatically). And I'd like to see an example first... Bug#726799 would have been uncovered and quickly characterized, when testing an upgrade of shared-mime-info with gqo installed. But well, it may well be that piuparts is not the best tool for this, you know better :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
reassign 726799 shared-mime-info retitle 726799 update-mime-database.real deletes files installed by other packages severity 726799 grave seen 726799 shared-mime-info/1.0-1+b1 seen 726799 shared-mime-info/1.3-1 thanks I got hit by this issue again myself, so well... Tried a couple of downgrade-to-testing and back-to-sid, with no disappearance appearing. In the meantime, looks like current piuparts runs are OK. So what ? On Fri, Dec 13, 2013 at 11:11:32PM +0100, Yann Dirson wrote: On Fri, Dec 13, 2013 at 01:58:31AM +0100, Andreas Beckmann wrote: On 2013-12-03 22:30, Yann Dirson wrote: I'm wondering if that could not be caused by a bug in the mime trigger, that would have been fixed already. That would be easier to test - what package is it? I was thinking about the mime-support trigger, but that package has not been changed for 6 months, so the problem must be somewhere else. I notice in the log sent in OP that *shared-mime-info* got upgraded at the same time, when piuparts runs dist-upgrade. Good news, there is a new version in sid, let's install it. Bum. So: root@home:~# aptitude reinstall qgo ... root@home:~# ls /usr/share/mime/text/x-sgf.xml /usr/share/mime/text/x-sgf.xml root@home:~# update-mime-database.real /usr/share/mime Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' root@home:~# ls /usr/share/mime/text/x-sgf.xml ls: cannot access /usr/share/mime/text/x-sgf.xml: No such file or directory Culprit found - but piuparts seems to be based on very wrong assumptions... Since the OP involves a version of this package that's nearly that of wheezy, we may want to consider some stable update as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748796: piuparts: should not use dist-upgrade to check for a single package upgrade
Source: piuparts Severity: important http://bugs.debian.org/726799 shows that, while using dist-upgrade may be useful and can reveal problems, it does not test *just* the package upgrade it claims to be testing (sounds obvious, but well... ;). In this case, a number of hours have been wasted hunting for a seemingly-unreproducible bug, that was in fact perfectly reproducible, but just wrongly characterized. So: * we surely need a better test procedure for package ugrades = what's wrong with just apt-get install $PACKAGE/sid ? * we do need a test procedure that would reproducibly find this kind of bugs What I'm thinking of is something like a tool that would start with a large installation of packages from testing, and which would test-upgrade each one of those packages separately. Similarly, triggers could be tested from a similar setup (both for testing and sid). (and probably a ton of other tests like that) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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#748449: aptitude: inconsistency around become root when openning the packages database read-only as root
Package: aptitude Version: 0.6.10-1 Severity: normal Launching aptitude (as root) while a dpkg is running results in a message saying the packages db is openned RO (that's expected), and says that no changes will be saved until I select become root (that is slightly awkward, but still understandable from my point of view). However, the Become root menu item is greyed out, so the awkward message may just reveal an unhandled corner case. -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.10 compiled at Feb 20 2014 17:26:22 Compiler: g++ 4.8.2 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.11 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140118 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7fffafbfe000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f4fa5f23000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f4fa5cee000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f4fa5ac3000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f4fa58be000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f4fa55b7000) libept.so.1.aptpkg4.12 = /usr/lib/x86_64-linux-gnu/libept.so.1.aptpkg4.12 (0x7f4fa535a000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f4fa4f5c000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f4fa4d44000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f4fa4a87000) libboost_iostreams.so.1.54.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0 (0x7f4fa486d000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f4fa465) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f4fa4344000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f4fa4041000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f4fa3e2b000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f4fa3a8) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f4fa387d000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f4fa3679000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f4fa3468000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f4fa3245000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f4fa303f000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f4fa2e37000) /lib64/ld-linux-x86-64.so.2 (0x7f4fa68c7000) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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 aptitude depends on: ii aptitude-common 0.6.10-1 ii libapt-pkg4.121.0.3 ii libboost-iostreams1.54.0 1.54.0-5 ii libc6 2.18-5 ii libcwidget3 0.5.17-1 ii libept1.4.12 1.0.12 ii libgcc1 1:4.9.0-2 ii libncursesw5 5.9+20140118-1 ii libsigc++-2.0-0c2a2.2.11-3 ii libsqlite3-0 3.8.4.3-3 ii libstdc++64.9.0-2 ii libtinfo5 5.9+20140118-1 ii libxapian22 1.2.17-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages aptitude recommends: ii apt-xapian-index0.46 pn aptitude-doc-en | aptitude-doc none ii libparse-debianchangelog-perl 1.2.0-1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii debtags 1.12 ii tasksel 3.20 -- 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#723982: [amd64/g++] Suspected toolchain bug causing dlopen to segfault
Thanks much Aurelien for the analysis! Just had a look, and there are several things to note: * the cpuid calls occur from OGDF, and the latest snapshot still has the same code * the variables set using cpuid info are never used in the OGDF subset shipped with tulip * the code calling cpuid is inside #if !defined(OGDF_DLL) || !defined(OGDF_SYSTEM_UNIX). OGDF_DLL is defined only for win32 for some reason, and strangely OGDF_SYSTEM_UNIX is not: we're apparently just using that useless faulty code by mistake... But setting OGDF_DLL causes other errors in basic.cpp: the case where OGDF_DLL is defined but not OGDF_SYSTEM_WINDOWS is obviously missing the closing brace for 'extern C' clause - this problem is fixed in the latest OGDF snapshot (by removing this useless extra clause). After all this, it finally builds, and as expected does not crash any more. On Tue, May 06, 2014 at 10:25:45PM +0200, Aurelien Jarno wrote: reassign 723982 tulip thanks On Sat, Feb 01, 2014 at 02:27:49PM +0100, Yann Dirson wrote: [resend with bugs CC'd] Hello, Context: http://bugs.debian.org/734318 - tulip: [amd64] segfaults inside dlopen when loading plugins http://bugs.debian.org/723982 - dlopen: segfaults right inside call_init What we get here is a number of plugins that when dlopen'd cause an obscure segfault inside libc code. Upstream (CC'd) say they have heard of such problems (on Ubuntu 13.10), that people have worked around by downgrading the compiler. This sounds like either a toolchain regression, or possibly some edge-case that worked by chance with old compilers and now fail. This is exactly that the bug is in tulip and up to know it worked only by chance on x86_64. The segfault occurs in dl-init.c when call_init is calling all the init functions from DT_INIT_ARRAY. This is done in C by this code: | addrs = (ElfW(Addr) *) (init_array-d_un.d_ptr + l-l_addr); | for (j = 0; j jm; ++j) |((init_t) addrs[j]) (argc, argv, env); which is translated in assembly code into: |0x77deb926 +134: lea0x8(%rbx,%rax,8),%r14 |0x77deb92b +139: nopl 0x0(%rax,%rax,1) |0x77deb930 +144: mov%r13,%rdx |0x77deb933 +147: mov%r12,%rsi |0x77deb936 +150: mov%ebp,%edi |0x77deb938 +152: callq *(%rbx) |0x77deb93a +154: add$0x8,%rbx |0x77deb93e +158: cmp%r14,%rbx |0x77deb941 +161: jne0x77deb930 call_init+144 |0x77deb943 +163: pop%rbx |0x77deb944 +164: pop%rbp |0x77deb945 +165: pop%r12 |0x77deb947 +167: pop%r13 |0x77deb949 +169: pop%r14 |0x77deb94b +171: retq As you can see the value of addrs is stored in %rbx and is incremented by 8 at each loop. The segfault occurs at address 0x77deb938 when trying to dereference %rbx. When it happens, %rbx has its upper 32 bits clobbered and thus point to the lower 32-bit of addrs[j]. Tracing that with GDB, it appeared %rbx is clobbered in the System::init constructor from tulip. This code probes among other things uses the CPUID instruction using assembly code: |__asm__ __volatile__ (xchgl%%ebx,%0\n\t |cpuid \n\t |xchgl %%ebx,%0\n\t |: +r (b), =a (a), =c (c), =d (d) |: 1 (infoType), 2 (c)); As you can see %ebx is saved with xchgl before the %cpuid instruction and restored after the same way. While that works correctly on x86, on x86_64 the 32 upper bits get zeroed. BOOM ! I would suggest to use cpuid.h (which is available since GCC 4.4) instead of this buggy assembly code to probe the CPU. In the meantime I am reassigning the bug to tulip. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B 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#712178: gcompris: crash after emitting some sounds (gstreamer=crash, sdl-mixer=stable) GStreamer-CRITICAL pad preroll_audio_src0:src
Hello, On Thu, Jun 13, 2013 at 11:48:15PM +0200, Guy Baconniere wrote: Package: gcompris Version: 12.01-1 Severity: important Tags: patch Dear Maintainer, What led up to the situation? starting gcompris on PowerPPC G4 (MacMini) with no special arguments will crash shortly after gcompris is emitting some sounds. Is it still the case with the latest version ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#423430: Gcompris game for drawing crash when click on the canvas
Hello, Do you still get this problem ? 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#593869: Gcompris dies when selecting a game
Hi all, Do any of you still get this problem ? On Mon, Dec 12, 2011 at 03:59:10PM -0500, elven decker wrote: I have this same problem. I've been working around it for a year by using the -m option and turning off the music, buy my youngest grand-daughter is now ready to start playing and needs the audio. I'm running gcompris 9.6.1 on Oneiric right now with Lubuntu and LXDE. My machine is an APTIVA but it has been more than reliable until this point. It only has 384KB of RAM, but it's able to run choppy streaming video if we care to watch. Sound card is ESS Technology ESS1969 Solo-1 Audiodrive (rev 01). Anything else I can add? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593869: Gcompris dies when selecting a game
Hi all, Do any of you still get this problem ? On Mon, Dec 12, 2011 at 03:59:10PM -0500, elven decker wrote: I have this same problem. I've been working around it for a year by using the -m option and turning off the music, buy my youngest grand-daughter is now ready to start playing and needs the audio. I'm running gcompris 9.6.1 on Oneiric right now with Lubuntu and LXDE. My machine is an APTIVA but it has been more than reliable until this point. It only has 384KB of RAM, but it's able to run choppy streaming video if we care to watch. Sound card is ESS Technology ESS1969 Solo-1 Audiodrive (rev 01). Anything else I can add? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725208: fixed 725208 in 13.11-1
fixed 725208 13.11-1 thanks Since 13.11, upstream has changed things so that we ship and use a compatible gcompris-gnuchess program. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726799: Cannot reproduce, lowering severity
tags + 726799 unreproducible moreinfo severity 726799 important thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743729: ruby-debian: lacks ruby2.0 support, breaks dependant packages
Even worse, the apt-listbugs hook is impacted, and prevents installation of any package: /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:289:in `require' from /usr/sbin/apt-listbugs:289 E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (1) E: Failure running script /usr/sbin/apt-listbugs apt Failed to perform requested operation on package. Trying to recover: 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#743729: ruby: badly handle transition away from alternatives, breaks dependant packages
reassign 743729 ruby retitle 743729 ruby: badly handles transition away from alternatives, breaks dependant packages found 743729 ruby/1:2.0.0.1 thanks The problem is not as simple as I originally thought (trused updatedb locate cache too much): strace reveals the ruby version for which debian_version is looking for is 1.8, and current ruby-debian only ships modules for 1.9.1 and 2.0.0. # ls -l /usr/bin/ruby lrwxrwxrwx 1 root root 22 Apr 5 18:15 /usr/bin/ruby - /etc/alternatives/ruby # update-alternatives --config ruby There is only one alternative in link group ruby (providing /usr/bin/ruby): /usr/bin/ruby1.8 Nothing to configure. I guess the problem comes from stopping using alternatives, without properly declares a Conflicts with obsolete ruby versions ? Well, #740733 seems to show that this was done in the past, and this issue is already discussed in its followup... As for unbreaking the impacted machines: * purging ruby1.8 leaves the system without /usr/bin/ruby or any of the symlinks previously managed as alternatives * although those symlinks are still listed as part of the ruby package, no mechanism seems to prevent this deadly interference with alternatives * creating a ruby - ruby2.0 manually allows to easily require reinstallation of the ruby package Isn't the real problem that dpkg allowed unpacking of conflicting symlinks in the first place ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743729: ruby-debian: lacks ruby2.0 support, breaks dependant packages
Package: ruby-debian Version: 0.3.8+b2 Severity: grave I guess this should have been spotted before ruby2.0 reaches testing :} $ how-can-i-help /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/bin/how-can-i-help:20:in `require' from /usr/bin/how-can-i-help:20 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-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 ruby-debian depends on: ii libapt-pkg4.120.9.16.1 ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libruby1.9.1 1.9.3.484-2 ii libruby2.02.0.0.484+really457-1 ii libstdc++64.8.2-16 ii ruby 1:2.0.0.1 ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2 ii ruby2.0 [ruby-interpreter]2.0.0.484+really457-1 ruby-debian recommends no packages. ruby-debian 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#743330: fotoxx: recommends on xgd-open, should be xdg-utils ?
Source: fotoxx Version: 14.03.1-1 Severity: important Thinko+typo in Recommends field ? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-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#741468: python-flufl.enum: includes symlink in docdir to contents of suggested -doc package
Package: python-flufl.enum Version: 3.3.2-1 Severity: serious /usr/share/doc/python-flufl.enum/rst is a symlink to html/_sources, which is even not installed by the -doc package, which puts everything under /usr/share/doc/python-flufl.enum-doc/. Instead, including a /usr/share/doc/python-flufl.enum/doc symlink to ../python-flufl.enum-doc/ in the -doc package itself would be much more interesting. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-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-flufl.enum depends on: ii python 2.7.5-5 ii python2.6 2.6.8-2 ii python2.7 2.7.6-7 python-flufl.enum recommends no packages. Versions of packages python-flufl.enum suggests: pn python-flufl.enum-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#741132: lives: opening a file makes the program crash
seen 741132 2.2.0~ds0-1 thanks I can reproduce this problem in testing, with the mp4 fetched using youtube-dl from http://www.youtube.com/watch?v=wE3fmFTtP9g * when run as lives foo.mp4 I get a dialog telling LiVES was unable to open it and the terminal window just says failed * when using the File/Open menu, I get the same crash. More precisely: Failed to open file - I tried: LANGUAGE=en LANG=en /usr/bin/mplayer -quiet -osdlevel 0 -vo png:z=1:alpha -lavdopts o=threads=4 -noframedrop -ao pcm:fast:nowaveheader -mc 0 WildCat-wE3fmFTtP9g.mp4 /dev/null Maybe you are missing a library in mplayer (or it is not a valid media file) ? avformat detected format: mov,mp4,m4a,3gp,3g2,mj2 /usr/lib/lives/lives-exe: symbol lookup error: /usr/lib//lives/plugins/decoders/zzavformat_decoder.so: undefined symbol: av_find_stream_info According to https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2011-August/039866.html LiVES could be trying to use an old API call, but I don't see anything about that in the libavformat changelog. I could downgrade to 2.0.6~ds0-2 and open the file through File/Open, but still get the same puzzling behaviour when requesting the file on commandline. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740111: icedtea-netx: NullPointerException in SwingUtilities.appContextGet
Package: icedtea-netx Version: 1.3.2-1 Severity: serious Tring to understand why the KGS Go client at http://files.gokgs.com/javaBin/cgoban.jnlp would not start: * default javaws (using openjdk-6) even explodes when passed no argument: $ /usr/lib/jvm/java-6-openjdk-amd64/bin/javaws Exception in thread main java.lang.NullPointerException at javax.swing.SwingUtilities.appContextGet(SwingUtilities.java:1859) at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1829) at javax.swing.JWindow.init(JWindow.java:185) at javax.swing.JWindow.init(JWindow.java:137) at net.sourceforge.jnlp.runtime.JNLPSecurityManager.init(JNLPSecurityManager.java:121) at net.sourceforge.jnlp.runtime.JNLPRuntime.initialize(JNLPRuntime.java:231) at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:181) at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:51) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:172) * using openjdk-7, the same call produces a usage message, but when launching against cgoban.jnlp the same NPE occurs, so I guess it is not specific to this particular app (hence the severity): $ /usr/lib/jvm/java-7-openjdk-amd64/bin/javaws /tmp/cgoban.jnlp Exception in thread main java.lang.NullPointerException at javax.swing.SwingUtilities.appContextGet(SwingUtilities.java:1859) at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1829) at javax.swing.JWindow.init(JWindow.java:185) at javax.swing.JWindow.init(JWindow.java:137) at net.sourceforge.jnlp.runtime.JNLPSecurityManager.init(JNLPSecurityManager.java:121) at net.sourceforge.jnlp.runtime.JNLPRuntime.initialize(JNLPRuntime.java:231) at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:181) at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:51) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:172) -- 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.12-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 icedtea-netx depends on: ii icedtea-netx-common 1.3.2-1 ii openjdk-6-jre6b30-1.13.1-1 ii openjdk-7-jre7u21-2.3.9-5 icedtea-netx recommends no packages. icedtea-netx 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#740111: Fixed in unstable
notfound 740111 1.4.2-1 thanks The problem does not happen with 1.4.2-1, currently in unstable. Works well with both openjdk 6 and 7. Sidenote: trying to install 1.4-3~deb7u2, it wanted to deinstall icedtea-6-plugin, so I did not test that one after all. Isn't that another bug ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740111: Fixed in unstable
fixed 740111 1.4.2-1 thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Wed, Feb 12, 2014 at 10:38:51PM +0100, Yann Dirson wrote: On Tue, Feb 11, 2014 at 08:02:39PM +0100, Vincent Legout wrote: I've just uploaded this snapshot to experimental. I tried running hachu and it seems to be working for the mighty lion and cho shogi variants, but not using the shogi (9x9) variant. Let me know if you need anything in XBoard to improve the hachu integration. * games defaulting to gnu(mini)shogi require xboard support, I'll upload a gnushogi master snapshot into experimental as well; they work well with the correct binaries in $PATH The 1.5~git20140217 snapshot is in experimental now, with xboard support. 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#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
Hi Andreas, Did you find the time systemtap this issue ? On Fri, Jan 10, 2014 at 10:41:39PM +0100, Yann Dirson wrote: Hi Andreas, On Fri, Dec 13, 2013 at 11:11:32PM +0100, Yann Dirson wrote: On Fri, Dec 13, 2013 at 01:58:31AM +0100, Andreas Beckmann wrote: On 2013-12-03 22:30, Yann Dirson wrote: I'm wondering if that could not be caused by a bug in the mime trigger, that would have been fixed already. That would be easier to test - what package is it? I was thinking about the mime-support trigger, but that package has not been changed for 6 months, so the problem must be somewhere else. Can you please retry the test, reproducible in jessie- sid and wheezy-sid updates to version 2.0~git-20131123-1 and if it still fails, run it while the following stap script is running: That may take some time ... I'll need to rerun the piuparts test manually in a chroot ... and on a different machine ... Any news on your side ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Sun, Feb 16, 2014 at 11:57:48PM +0100, h.g.muller wrote: Op Zo, 16 februari, 2014 12:53 pm schreef Yann Dirson: I wouldn't think so, since during the game arrows ane pieces were drawn at the same place, and the dot was even drawn on top of pieces IIRC. OK, that is very significant. Such dots are drawn on squares for which the corresponding element of a board-size array 'markers' is non-zero. Did you also see other such dots appear on other squares to indicate the moves of the piece you ppicked up, during the game? Normally it would clear the entire array 'markers' every time the user releases a piece on its destination square, and it should not be possible for a stray dot to survive that, no matter what caused it to appear in the first place. (Unless it would be caused by some out-of-bound access elsewhere, that happened again and again on every move.) Unless it would never draw the dots because the option is off, in which case it would also never erase them. I could only see the dots for the pieces I selected prior to launching two-engine mode. If I attempt to select one while the engines are playing, existing dots are removed, and (correctly) no new dot is drawn. Looks like it is just the list of dots that should be cleared when an engine is assigned a side. Oh I see. It does work, although it is affected by the lack of tile resize I already noticed, so xboard -fcp shogi shows a shogi board with the bottom row off-screen. xboard -fcp gnushogi, I presume. I will address the sizing problem. Right :) Wouldn't it be easier to just drop an OrientalChu file in an xboard.conf.d/ dir, so that installing a new theme does not require running xboard ? One reason for running XBoard for this is that the engine or theme package might not know where to find the XBoard data files, or even its .conf file. Their location depends on whether XBoard was installed from source or as binary package. Issuing XBoard as a command would by definition invoke the currently active XBoard. OK. OTOH, make install is also often run as root, and the less stuff you run that way, the safer you get. Calling xboard to request the paths to be used could be done at configure time (typically *not* run as root), together with substitutions to conf files if needed (although ~~/ probably makes it unnecessary). Then make install would just use those pre-specified paths. It would also have the nice property that, when xboard ships a new xboard.conf, it does not overwrite the previously-added themes. Indeed, this is a problem I had not thought of yet. If themes are to be dropped as individual files, we might as well drop them in ~~/themes/conf, where the chu and shogi files are dropped now already. It would require XBoard to run through the contents of this directory in addition to reading its master settings file every time it is launched, however. But then it would have to distinguish between those meant to be specified through @preset and those to be unconditionally read. And since they are really confs, as opposed to presets, they are much better located in /etc/. For engines we could do the same, in another directory. Actually I think this is a problem that transcends XBoard, as engines are also usable by other GUIs. There are plenty of GUIs that support XBoard protocol or UCI. So IMO there really is need for a standardized way for engines to announce themselves. E.g. in Debian the directory /usr/games/engines/cecp could be used for engines that support CECP, and /usr/games/engines/uci for engines that support UCI (and .../usi for Shogi engines that support USI, etc.) Engines could then drop a file there with some essential information, like the variant(s) they play, and the command for starting them, and perhaps some extra, protocol-specific info (like for CECP whether they use v1 or v2 of the protocol). All GUIs could then draw on that information, by looking in the directories for the protocols they support. It's not that easy, as not all engine requires the same information. However, I guess that could be done with little effort using the debian menu framework - it is, however, specific to Debian and derived distros, so it would probably count as not generic enough. The idea is that packages that need to announce themselves just drop a file in /usr/share/menu, describing what they declare (eg. here needs=XBoard), and the various parameters. On the other side, consumer packages (for menus, that's window managers, taskbars and the like, including an XDG backend generating .desktop files) provide a kind of script that will generate their config file(s) from the provided data. In Omaha I have opted for .desktop files, describing plugins in a more generic framework (also used to describe game, themes, etc). But the framework could be easily adapted to other formalisms (support for Zillions rules are on my todo list, albeit near the end of it ;) Best
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Sat, Feb 15, 2014 at 10:57:20PM +0100, h.g.mul...@hccnet.nl wrote:
Op Za, 15 februari, 2014 9:44 pm schreef Yann Dirson:
First a new small bug: have hachu played a full Chu game, probably
after having selecting a white piece, and noticed that the dot stayed there
till end of the game: http://imagebin.org/293529
OK, this is a dot from the 'Show target squares' option, that apparently
was not properly erased. This is always a bit tricky, because it can be
that it is actually erased on the board, but that the corresponding expose
event to actually update the display was never performed. (A check for
that is to flip the view, because that redraws the entire board. But I
guess it is too late for that now.)
I wouldn't think so, since during the game arrows ane pieces were
drawn at the same place, and the dot was even drawn on top of pieces
IIRC.
It would be helpful to know if you were playing with legality checking on
or off: when it is on XBoard itself marks the target squares with dots
when you 'lift' a piece, drawing on its internal move generator and rule
knowledge, while when it is off it follows the instructions sent to it by
the engine for marking the squares (and HaChu uses that).
So it seems I have legality checking on by default with @chu, but not
with @shogi. I assume GNU Shogi misses the necessary support.
It would also be helpful to see the entire game, and know the moment when
this dot first appeared. (Presumably when a piece was lifted that could
move to that square.) Or was the dot there already when the game started?
The dot was there at first. I must have clicked on one piece or 2 to
show my son how things worked, then started two-machines mode with the
dot still displayed, and it stays here as the engines start to play.
Easily reproducible, in fact.
I see. However, the problem of giving easy access to all those
GUI-only users not willing to dive into manpages to discover that,
will still be there.
When the engine sends the 'setup' command, the user would not have to
worry about rule knowledge. And I think I also made it such that when an
engine does not report it plays variant normal of fischerandom, that
XBoard would automatically switch to the variant that the engine does
play.
Oh I see. It does work, although it is affected by the lack of tile
resize I already noticed, so xboard -fcp shogi shows a shogi board
with the bottom row off-screen.
That leaves setting the theme. The various theme 'components', such as
pieceImageDirectory and square background textures or square colors can
already be set through the GUI, but it is a bit inconvenient that he would
have to set all aspects separately. In WInBoard I solved this by adding a
View-Themes dialog, very similar to the Load Engine dialog. (Cloned from
it, in fact.) The idea is that the user sees a list of theme names where
he sees engine nick-names in Load Engine, and can select those by clicking
them. A theme (like an engine) is a line in a multiline option stored in
the settings file (-themeNames in stead of -firstChessProgramNames). The
line consist of a sequence of XBoard options, processed as if they formed
a command line when the user selects that theme. The rest of the dialog
contains controls to set options that define the theme (basically what is
now in the View-Board dialog), plus a text entry for the 'theme name'
that is initialized empty. If the user uses the dialog not to select an
existing theme but to modify individual settings, XBoard would just
implement the new settings on 'OK'. But if he provided also a theme name,
the combination of settings would forget into a line, and added under the
given name to the list of themes, so next time he can recall it with a
single click.
I recently added a new class of options to XBoard (of which -installEngine
was the first representative), which would add their value (a text string)
as a new line to the end of a multi-line option (-firstChessProgramNames,
in this case). I could make another such option, -installTheme, which
would add to -themeNames. This could be used to make newly installed
themes automatically appear in the theme list of all users, by in the
install script of a theme package write the command
xboard -addMasterOption {-installTheme 'Oriental Chu -pid ~~/themes/chu
-lightSquareColor #FFE040 -darkSquareColor #FFE040'} -autoClose
which then would add the line
-installTheme 'Oriental Chu -pid ~~/themes/chu -lightSquareColor #FFE040
-darkSquareColor #FFE040 -variant chu'
at the end of the xboard.conf master settings file, so that every future
user would get to see it, and get the line
Oriental Chu -pid ~~/themes/chu -lightSquareColor #FFE040
-darkSquareColor #FFE040
added to his -themeNames list, so he could select it with a simple click.
Basically the line to be added contains the same as what is now in the
conf files like ~~/conf/chu, except on a single line
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Fri, Feb 14, 2014 at 12:30:59PM +0100, h.g.mul...@hccnet.nl wrote: Op Do, 13 februari, 2014 10:10 pm schreef Yann Dirson: * @shogi @sho gives a strange result, with no traditional tile for the elephant, ... This is because we don't have a tile for the Elephant yet in the Shogi kanji piece set. ($(datadir)/xboard/themes/shogi/WhiteElephant.svg etc.) This set was simply ripped from some GPL'ed shogi program, which apparently did not support Sho. I don't like them much anyway, I think the old xShogi pieces were much nicer (but alas, not SVG). If we have an easy way to convert a TTF font's glyphs to SVG, we can easily compose new pieces. In Omaha, I compose a virgin SVG piece with rendering of a TTF font - it will make it easier to customise, letting users select their own font; you might want to go this way as well. ... whereas @shogi @chu is more consistent by forcing the western theme to avoid the problem Well, @chu defines its own -pieceImageDirectory, which overrules the one defined in the @shogi file. Apparently you don't have the chu pieces installed, that it falls back on the default set. Hm, -pid ~~/themes/chu assumes hachu installed the svg, it seems. Wouldn't it be better to ship the theme with xboard ? If 2 humans can play Chu in xboard without hachu installed, with western style, why not letting them play with japanese style in the same conditions ? * with @mini, two-machine game, the white king starts by capturing his own pawn. Have to investigate: I have not tested gnuminishogi much in xboard mode, relying on shogi tests only till now. At least I have no such problem in Omaha, there may be something linked to the commands sent by xboard (omaha is very minimalist in what it requests). Will keep you informed on this. OK, I will have a look to this as well. Don't spend too much time on this, I will polish a fix and push it this WE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
First a new small bug: have hachu played a full Chu game, probably after having selecting a white piece, and noticed that the dot stayed there till end of the game: http://imagebin.org/293529 On Fri, Feb 14, 2014 at 11:48:16AM +0100, h.g.mul...@hccnet.nl wrote: * games defaulting to hachu (@chu and @sho) look OK * games defaulting to gnu(mini)shogi require xboard support, I'll upload a gnushogi master snapshot into experimental as well; they work well with the correct binaries in $PATH * @mini should I think default to japanese theme Mini-Shogi is not an officially-defined variant of XBoard, and thus needs some user configuration to be played. In cases like that, it seemed best to separate the theme config file from the rules config file. (I guess the same in principle holds for Sho Shogi, but I probably figured that there would be no interest outside the traditional Shogi community for that anyway. While for mini-Shogi I see a good future, provided that people get the opportunity to play it in a 'kanji-free version'.) The need for user rule configuration would disappear completely if GNU miniShogi would use the engine-defined-variants feature of XBoard-exp, however, and I think this is the way to go. I should simply announce feature variants=mini,5x5+5_shogi and respond to the variant mini command with setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi rbsgk/4p/5/P4/KGSBR w 0 1 Then it could be played by simply selecting mini from the New Variant menu, and no rule configuration would be needed anymore. The 5x5+5_shogi would only be mentioned in the variants feature for compatibility with older interfaces and older engines. (E.g. if you want to play engine vs engine, and the opponent engine would not support 'variant mini'.) Then only theme configuration would remain, and you could use @shogi for that: xboard @shogi -fcp gnuminishogi would overrule gnushogi as default engine specified in @shogi. I see. However, the problem of giving easy access to all those GUI-only users not willing to dive into manpages to discover that, will still be there. * @xq board drawing is messed with large window sizes here, although OK with smaller window sizes (see http://imagebin.org/292981), otherwise seems OK That is a matter of the size of the bitmap provided for the Xiangqi board. XBoard cuts tiles the size of a square from this bitmap. For a square grid of NxN squares that would in principle allow cutting 2Nx2N squares out of it before you start to see the next grid line, but with the diagonal lines in the Palace you already see artifacts when the square size gets N. These are not very annoying, however. My attitude was pertty much that if people would think the board is too messy, they should simply switch to smaller square size. In older XBoard (before it used Cairo) the only sizes for which there were built-in westernized Xiangqi piece bitmaps were 33, 49 and 72 anyway, and the bitmap of teh Xiangqi board was made with 49x49 grid. Hm, with today's large screen sizes, it's not very friendly to require keeping a small window. What about using SVG there instead ? * I feel .desktop files for shipped confs would be needed to make them more visible to users Indeed, the confs are only useful from the command line. OTOH, confs can be combined on the command line, which is useful when they configure different aspects (game rules, board theme, engine). It would be hard to provide desktops for every possible combination of those. But if there are a few obvious combinations of theme + rules + engine (e.g. because GNU also features an engine, such as with GNU Shogi), we could make desktop files for those. Or maybe provide a launcher to select theme/rules/engine and run xboard with proper options, at least until those are made selectable from within xboard itself ? There are tools to help for this (remember seeing new packages in Debian for this months if not years ago), but I can't find the right keywords to find them again. * Trying to switch to Dai or Tenjiku is refuse with Engine did not send setup for non-standard variant * Maybe a @hachu conf would be useful for easy access to those games ? Maybe better shipped by hachu itself ? The current XBoard does not support Dai or Tenjiku, and could not be made to support them even through user configuring. The number of piece types needed for thos games exceeds XBoard's current maximum (44 piece types, which was already doubled compared to 4.7.x in order to support Chu Shogi). Only the WinBoard 'Alien Edition' fork currently supports those variants (as well as Dai Dai, Maka Dai Dai and Tai), but the piece images are constructed from scratch in the WinBoard front-end in the 'mnemonic' theme, so this does not work for XBoard. In addition, Tenjiku is not fully implemented in HaChu yet. The move generator still doesn't do 'area moves'. My original plan was to first finish
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Wed, Feb 12, 2014 at 10:38:51PM +0100, Yann Dirson wrote: * Tried Mighty Lion by starting xboard -fcp hachu -scp hachu and selecting that variant, looks like hachu crashed (xboard -debug output attached for comment by HGM, hachu is current master, ie version 0.17-3-g3460d0c). The same technique is OK with Sho and Chu. Oops, I forgot the attachement. * @mini should I think default to japanese theme I remembered afterwards that you told me about combining @shogi with other variants. In fact xboard @shogi @mini does work, but: * @shogi @sho gives a strange result, with no traditional tile for the elephant, whereas @shogi @chu is more consistent by forcing the western theme to avoid the problem * while this gives flexibility to @mini, there is no such flexibility for using non-theme flags from @shogi with a western theme, it seems Also forgot a couple of problems I did see yesterday: * @chu fails with Unrecognized argument -roarSound in settings file: maybe xboard requires some extra lib at configure-time to activate support for this flag ? * with @mini, two-machine game, the white king starts by capturing his own pawn. Have to investigate: I have not tested gnuminishogi much in xboard mode, relying on shogi tests only till now. At least I have no such problem in Omaha, there may be something linked to the commands sent by xboard (omaha is very minimalist in what it requests). Will keep you informed on this. recognized 'normal' (-1) as variant normal recognized 'normal' (-1) as variant normal recognized 'normal' (-1) as variant normal shuffleOpenings = 0 Requested font set for list -*-helvetica-medium-r-normal--14-*-*-*-*-*-*-*,-misc-fixed-medium-r-normal--14-*-*-*-*-*-*-*,-*-*-*-*-*-*-14-*-*-*-*-*-*-* got list -*-helvetica-medium-r-normal--14-*-*-*-*-*-*-*,-misc-fixed-medium-r-normal--14-*-*-*-*-*-*-*,-*-*-*-*-*-*-14-*-*-*-*-*-*-*, locale fr_FR.UTF-8 got charset -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1 got charset -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1 got charset -adobe-helvetica-medium-r-normal--14-101-100-100-p-0-iso8859-2 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-3 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-4 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-5 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-koi8-r got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-7 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-9 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-13 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-14 got charset -adobe-helvetica-medium-r-normal--14-101-100-100-p-0-iso8859-15 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0 got charset -daewoo-gothic-medium-r-normal--14-101-100-100-c-0-ksc5601.1987-0 got charset -isas-fangsong ti-medium-r-normal--14-101-100-100-c-0-gb2312.1980-0 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-jisx0201.1976-0 got charset -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso10646-1 Requested font set for list -*-helvetica-bold-r-normal--34-*-*-*-*-*-*-*,-misc-fixed-bold-r-normal--34-*-*-*-*-*-*-*,-*-*-*-*-*-*-34-*-*-*-*-*-*-* got list -*-helvetica-bold-r-normal--34-*-*-*-*-*-*-*,-misc-fixed-bold-r-normal--34-*-*-*-*-*-*-*,-*-*-*-*-*-*-34-*-*-*-*-*-*-*, locale fr_FR.UTF-8 got charset -adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso8859-1 got charset -adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso8859-1 got charset -adobe-helvetica-bold-r-normal--34-246-100-100-p-0-iso8859-2 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-3 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-4 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-5 got charset -etl-fixed-medium-r-normal--34-246-100-100-c-0-koi8-r got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-7 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-9 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-13 got charset -misc-fixed-bold-r-normal--34-246-100-100-c-0-iso8859-14 got charset -adobe-helvetica-bold-r-normal--34-246-100-100-p-0-iso8859-15 got charset -jis-fixed-medium-r-normal--34-246-100-100-c-0-jisx0208.1983-0 got charset -daewoo-gothic-medium-r-normal--34-246-100-100-c-0-ksc5601.1987-0 got charset -isas-fangsong ti-medium-r-normal--34-246-100-100-c-0-gb2312.1980-0 got charset -misc-fixed-medium-r-normal--34-246-100-100-c-0-jisx0201.1976-0 got charset -adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso10646-1 Requested font set for list -*-helvetica-bold-r-normal--14-*-*-*-*-*-*-*,-misc-fixed-bold-r-normal--14-*-*-*-*-*-*-*,-*-*-*-*-*-*-14-*-*-*-*-*-*-* got list -*-helvetica-bold-r-normal--14-*-*-*-*-*-*-*,-misc-fixed-bold-r-normal--14-*-*-*-*-*-*-*,-*-*-*-*-*-*-14
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
On Thu, Feb 13, 2014 at 10:10:00PM +0100, Yann Dirson wrote: * with @mini, two-machine game, the white king starts by capturing his own pawn. Have to investigate: I have not tested gnuminishogi much in xboard mode, relying on shogi tests only till now. At least I have no such problem in Omaha, there may be something linked to the commands sent by xboard (omaha is very minimalist in what it requests). Will keep you informed on this. Found a bug in gnushogi: when I introduced COL/ROW_NAME years ago I did not notice that the reverse transform (ie. name to number) were identical, so wrote no macro for the reverse transform. Now for xboard protocol, the recoprocal transform is not identical any more, and this breaks EditBoard. Fix under way - and no problem on xboard side. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
Hi Vincent, On Tue, Feb 11, 2014 at 08:02:39PM +0100, Vincent Legout wrote: Yann Dirson ydir...@free.fr writes: 4.8 features many new features, including support for new large shogi variants, and overall better support for non-chess (xboard @shogi and friends), including the ability for a compatible engine to declare itself to xboard. I have packaged hachu some time ago, as the only available DFSG program able to play those large variants (I've kept it in experimental till now, since there is no GUI yet in unstable to play them). Having a compatible xboard there would allow to start working on hachu/xboard integration, and to give more precise feedback to upstream to make sure that those new features are packaging-friendly. A master-20140119 snapshot was tagged recently, it looks like a good version to package. I've just uploaded this snapshot to experimental. I tried running hachu and it seems to be working for the mighty lion and cho shogi variants, but not using the shogi (9x9) variant. Let me know if you need anything in XBoard to improve the hachu integration. Thanks! (H.G.Müller CC'd as upstream for these features) Had a quick test: * games defaulting to hachu (@chu and @sho) look OK * games defaulting to gnu(mini)shogi require xboard support, I'll upload a gnushogi master snapshot into experimental as well; they work well with the correct binaries in $PATH * @mini should I think default to japanese theme * @xq board drawing is messed with large window sizes here, although OK with smaller window sizes (see http://imagebin.org/292981), otherwise seems OK * I feel .desktop files for shipped confs would be needed to make them more visible to users * Tried Mighty Lion by starting xboard -fcp hachu -scp hachu and selecting that variant, looks like hachu crashed (xboard -debug output attached for comment by HGM, hachu is current master, ie version 0.17-3-g3460d0c). The same technique is OK with Sho and Chu. * Trying to switch to Dai or Tenjiku is refuse with Engine did not send setup for non-standard variant * Maybe a @hachu conf would be useful for easy access to those games ? Maybe better shipped by hachu itself ? * Switching to Chu from xboard -fcp hachu -scp hachu enlarges the window while keeping the same tile size, which always make it too big for my screen, since xboard already starts up using the full screen height for 8 tiles. * I guess xboard shipping chu and sho confs make those in hachu.git redundant ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737680: git: please ship git-subtree
Package: git Version: 1:1.8.5.3-1 Severity: wishlist git-subtree is included in contrib/subtree/, it would be good to have it in one of the debs. -- 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.12-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 git depends on: ii git-man 1:1.8.5.3-1 ii libc62.17-97 ii libcurl3-gnutls 7.35.0-1 ii liberror-perl0.17-1.1 ii libexpat12.1.0-4 ii libpcre3 1:8.31-2 ii perl-modules 5.18.2-2 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages git recommends: ii less 458-2 ii openssh-client [ssh-client] 1:6.4p1-2 ii patch2.7.1-4 ii rsync3.1.0-2 Versions of packages git suggests: ii gettext-base 0.18.3.2-1 pn git-arch none pn git-bzr none ii git-cvs 1:1.8.5.3-1 pn git-daemon-run | git-daemon-sysvinit none pn git-doc none ii git-el1:1.8.5.3-1 ii git-email 1:1.8.5.3-1 ii git-gui 1:1.8.5.3-1 pn git-mediawiki none ii git-svn 1:1.8.5.3-1 ii gitk 1:1.8.5.3-1 pn gitwebnone -- 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#723982: [amd64/g++] Suspected toolchain bug causing dlopen to segfault
[resend with bugs CC'd] Hello, Context: http://bugs.debian.org/734318 - tulip: [amd64] segfaults inside dlopen when loading plugins http://bugs.debian.org/723982 - dlopen: segfaults right inside call_init What we get here is a number of plugins that when dlopen'd cause an obscure segfault inside libc code. Upstream (CC'd) say they have heard of such problems (on Ubuntu 13.10), that people have worked around by downgrading the compiler. This sounds like either a toolchain regression, or possibly some edge-case that worked by chance with old compilers and now fail. Any insights ? 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#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure
Package: xboard Version: 4.7.3-1 Severity: wishlist 4.8 features many new features, including support for new large shogi variants, and overall better support for non-chess (xboard @shogi and friends), including the ability for a compatible engine to declare itself to xboard. I have packaged hachu some time ago, as the only available DFSG program able to play those large variants (I've kept it in experimental till now, since there is no GUI yet in unstable to play them). Having a compatible xboard there would allow to start working on hachu/xboard integration, and to give more precise feedback to upstream to make sure that those new features are packaging-friendly. A master-20140119 snapshot was tagged recently, it looks like a good version to package. -- 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.12-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 xboard depends on: ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-02.36.4-1 ii libice6 2:1.0.8-2 ii librsvg2-2 2.40.0-1 ii libsm6 2:1.2.1-2 ii libx11-62:1.6.2-1 ii libxaw7 2:1.0.12-1 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.4-1 Versions of packages xboard recommends: ii fairymax 4.8q-2 ii xfonts-100dpi 1:1.0.3 ii xfonts-75dpi 1:1.0.3 Versions of packages xboard suggests: ii xterm [x-terminal-emulator] 300-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#21818: closed by Solveig deb...@solveig.org (Closing old emacs21 bugs)
reopen 21818 seen 21818 23.4+1-4.1+b1 thanks Date: Thu, 23 Jan 2014 04:17:43 + From: Solveig deb...@solveig.org To: destinataires inconnus: ; Subject: Closing old emacs21 bugs Hi! I'm closing this bug, since it affected emacs21, and the current version is 23. If you still encounter this problem, please feel free to re-open it and move it to the appropriate package, or ask me to do it. Still there... $ mkdir tmp $ cp doc/gnushogi.6 !$ cp doc/gnushogi.6 tmp $ gzip tmp/gnushogi.6 $ tar -zcf foo.tar.gz tmp/ Open the resulting file in emacs, open the manpage, get raw gzipped data in nroff mode. Date: Tue, 28 Apr 1998 20:37:59 +0200 (CEST) From: Yann Dirson ydir...@a2points.com To: Debian bug-system submission sub...@bugs.debian.org Subject: tar-mode: badly handles compressed files inside tarball X-Mailer: VM 6.46 under Emacs 19.34.1 Package: emacs19, emacs20 Version: 19.34-15, 20.2-6 The tar-mode in both current emacs19 and emacs20 is ill-behaved regarding compressed files. I only make 1 bug-report, as finding a fix for one will most probably give a fix for the other. When browsing through a tar-file that contains compressed manpages, for example, it does not uncompress the gzipped data, and thus displays the binary data, but switches to nroff-mode ! I agree that nroff-mode sould be called, but I think the file should be uncompressed first. -- Yann Dirson ydir...@a2points.com | Stop making M$-Bill richer richer, alt-email: dir...@univ-mlv.fr | support Debian GNU/Linux: debian-email: dir...@debian.org | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735121: [tulip] Non free files
On Sun, Jan 12, 2014 at 09:46:19PM +, bastien ROUCARIES wrote: Package: tulip Severity: serious x-cc-debug: ftpmas...@ftp-master.debian.org The following file are not free: Gasp. Those bundle-everything project are a real hell to maintain... I'll nuke those fonts from the orig tarball. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
Hi Andreas, On Fri, Dec 13, 2013 at 11:11:32PM +0100, Yann Dirson wrote: On Fri, Dec 13, 2013 at 01:58:31AM +0100, Andreas Beckmann wrote: On 2013-12-03 22:30, Yann Dirson wrote: I'm wondering if that could not be caused by a bug in the mime trigger, that would have been fixed already. That would be easier to test - what package is it? I was thinking about the mime-support trigger, but that package has not been changed for 6 months, so the problem must be somewhere else. Can you please retry the test, reproducible in jessie- sid and wheezy-sid updates to version 2.0~git-20131123-1 and if it still fails, run it while the following stap script is running: That may take some time ... I'll need to rerun the piuparts test manually in a chroot ... and on a different machine ... Any news on your side ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697863: ftgl: diff for NMU version 2.1.3~rc5-4+nmu1
tags 697863 + pending
tags 701732 + pending
tags 718100 + patch
tags 718100 + pending
tags 734159 + patch
tags 734159 + pending
thanks
Dear maintainer,
I've prepared an NMU for ftgl (versioned as 2.1.3~rc5-4+nmu1) and
uploaded it to DELAYED/8. Please feel free to tell me if I
should delay it longer.
Note: a collab-maint repo would have allowed me to independently
commit diffs for all changes.
Regards.
diff -Nru ftgl-2.1.3~rc5/debian/changelog ftgl-2.1.3~rc5/debian/changelog
--- ftgl-2.1.3~rc5/debian/changelog 2011-11-26 11:15:46.0 +0100
+++ ftgl-2.1.3~rc5/debian/changelog 2014-01-05 17:20:22.0 +0100
@@ -1,3 +1,15 @@
+ftgl (2.1.3~rc5-4+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix FTBFS at generation of pdf doc (Closes: #718100).
+ * Switch to multiarch (Closes: #734159), but don't mark the -dev package
+as such, as it was not tested as such.
+ * Include debian/watch from Nick Black (Closes: #697863).
+ * Update libtool at build time using dh-autoreconf, in order to fix a
+build failure on x32 (Daniel Schepler, Closes: #701732).
+
+ -- Yann Dirson dir...@debian.org Sun, 05 Jan 2014 17:20:22 +0100
+
ftgl (2.1.3~rc5-4) unstable; urgency=low
* drop doxygen and texlive-* (except texlive-fonts-recommended) and
diff -Nru ftgl-2.1.3~rc5/debian/control ftgl-2.1.3~rc5/debian/control
--- ftgl-2.1.3~rc5/debian/control 2011-11-26 11:09:37.0 +0100
+++ ftgl-2.1.3~rc5/debian/control 2014-01-05 17:17:32.0 +0100
@@ -2,7 +2,7 @@
Section: libs
Priority: optional
Maintainer: Sam Hocevar s...@debian.org
-Build-Depends: debhelper (= 5.0), quilt, libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libfreetype6-dev ( 2.0.9), doxygen-latex, freeglut3-dev, libcppunit-dev, imagemagick, texlive-fonts-recommended, ghostscript
+Build-Depends: debhelper (= 8.1.3), quilt, libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libfreetype6-dev ( 2.0.9), doxygen-latex, freeglut3-dev, libcppunit-dev, imagemagick, texlive-fonts-recommended, ghostscript, dh-autoreconf
Standards-Version: 3.9.2
Vcs-Svn: svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/ftgl
Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/ftgl/
@@ -24,7 +24,9 @@
Package: libftgl2
Section: libs
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
Description: library to render text in OpenGL using FreeType
FTGL binds OpenGL and FreeType together in order to offer and easy to use
and flexible text rendering library. It offers several rendering modes:
diff -Nru ftgl-2.1.3~rc5/debian/libftgl-dev.install ftgl-2.1.3~rc5/debian/libftgl-dev.install
--- ftgl-2.1.3~rc5/debian/libftgl-dev.install 2008-06-15 17:28:51.0 +0200
+++ ftgl-2.1.3~rc5/debian/libftgl-dev.install 2014-01-04 14:30:54.0 +0100
@@ -1,7 +1,7 @@
usr/include
-usr/lib/lib*.a
-usr/lib/lib*.so
-usr/lib/pkgconfig/*.pc
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/*.pc
usr/share/doc/libftgl-dev/html
usr/share/doc/libftgl-dev/ftgl.pdf
usr/share/doc/libftgl-dev/*.txt
diff -Nru ftgl-2.1.3~rc5/debian/libftgl2.install ftgl-2.1.3~rc5/debian/libftgl2.install
--- ftgl-2.1.3~rc5/debian/libftgl2.install 2008-06-15 17:28:51.0 +0200
+++ ftgl-2.1.3~rc5/debian/libftgl2.install 2014-01-04 14:29:45.0 +0100
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
diff -Nru ftgl-2.1.3~rc5/debian/patches/fix-pdf-generation ftgl-2.1.3~rc5/debian/patches/fix-pdf-generation
--- ftgl-2.1.3~rc5/debian/patches/fix-pdf-generation 1970-01-01 01:00:00.0 +0100
+++ ftgl-2.1.3~rc5/debian/patches/fix-pdf-generation 2014-01-04 16:25:45.0 +0100
@@ -0,0 +1,33 @@
+Description: Fix PDF refman generation
+ This just remove a pre-latex-processing hack that just breaks nowadays.
+ The Makefile.in was updated by hand, since autostuff is way old and
+ apparently more work is needed to make regeneration work properly.
+Author: Yann Dirson dir...@debian.org
+Bug-Debian: http://bugs.debian.org/718100
+
+--- ftgl-2.1.3~rc5.orig/docs/Makefile.am
ftgl-2.1.3~rc5/docs/Makefile.am
+@@ -33,9 +33,7 @@ stamp-doxygen: doxygen.cfg stamp-eps
+
+ latex/ftgl.pdf: stamp-latex
+ stamp-latex: stamp-doxygen
+- rm -f latex/ftgl.tex latex/ftgl.pdf
+- mv latex/refman.tex latex/ftgl.tex
+- sed 's/setlength{/renewcommand{/' latex/ftgl.tex latex/refman.tex
++ rm -f latex/ftgl.pdf
+ cd latex $(MAKE) $(AM_CFLAGS) refman.pdf || (cat refman.log; exit 1)
+ mv latex/refman.pdf latex/ftgl.pdf
+ touch stamp-latex
+--- ftgl-2.1.3~rc5.orig/docs/Makefile.in
ftgl-2.1.3~rc5/docs/Makefile.in
+@@ -460,9 +460,7 @@ stamp-doxygen: doxygen.cfg stamp-eps
+
+ latex/ftgl.pdf: stamp-latex
+ stamp-latex: stamp-doxygen
+- rm -f latex/ftgl.tex latex/ftgl.pdf
+- mv latex/refman.tex latex/ftgl.tex
+- sed 's/setlength{/renewcommand{/' latex/ftgl.tex latex/refman.tex
++ rm -f latex/ftgl.pdf
+ cd latex $(MAKE) $(AM_CFLAGS) refman.pdf || (cat refman.log; exit 1
Bug#734318: tulip: [amd64] segfaults inside dlopen when loading plugins
Package: tulip Version: 4.4.0dfsg-1 Severity: serious This happens on amd64, but not in an i386 chroot, or when running the i386 binary on an amd64 machine. See http://bugs.debian.org/723982 for what's happening inside the dlopen call. With an additional trace to identify the plugin being loaded we get: | loadPlugins info: /home/yann/.local/share/data//Tulip 4.4/plugins//lib/tulip/ - No such file or directory | [Thread 0x7fffe6c7a700 (LWP 29463) exited] | dlopening '/usr/lib/../lib/tulip//libreverseedges-4.4.0.so' aka '/usr/lib/../lib/tulip//libreverseedges-4.4.0.so' | dlopening '/usr/lib/../lib/tulip//libogdfvisibility-4.4.0.so' aka '/usr/lib/../lib/tulip//libogdfvisibility-4.4.0.so' | | Program received signal SIGSEGV, Segmentation fault. | | (gdb) bt | #0 0x77de99c4 in call_init (env=0x7fffdd28, argv=0x7fffdd18, argc=1, l=optimized out) at dl-init.c:84 | #1 call_init (l=optimized out, argc=1, argv=0x7fffdd18, env=0x7fffdd28) at dl-init.c:34 | #2 0x77de9aaa in _dl_init (main_map=main_map@entry=0x822a40, argc=1, argv=0x7fffdd18, env=0x7fffdd28) at dl-init.c:133 | #3 0x77dedb09 in dl_open_worker (a=a@entry=0x7fffd2d8) at dl-open.c:577 | #4 0x77de9806 in _dl_catch_error (objname=objname@entry=0x7fffd2c8, errstring=errstring@entry=0x7fffd2d0, mallocedp=mallocedp@entry=0x7fffd2c7, | operate=operate@entry=0x77ded790 dl_open_worker, args=args@entry=0x7fffd2d8) at dl-error.c:177 | #5 0x77ded339 in _dl_open (file=0x71d648 /usr/lib/../lib/tulip//libogdfvisibility-4.4.0.so, mode=-2147483646, caller_dlopen=optimized out, nsid=-2, argc=1, argv=0x7fffdd18, | env=0x7fffdd28) at dl-open.c:667 | #6 0x71c7b026 in dlopen_doit (a=a@entry=0x7fffd4e0) at dlopen.c:66 | #7 0x77de9806 in _dl_catch_error (objname=0x6b56e0, errstring=0x6b56e8, mallocedp=0x6b56d8, operate=0x71c7afc0 dlopen_doit, args=0x7fffd4e0) at dl-error.c:177 | #8 0x71c7b5ec in _dlerror_run (operate=operate@entry=0x71c7afc0 dlopen_doit, args=args@entry=0x7fffd4e0) at dlerror.c:163 | #9 0x71c7b0c1 in __dlopen (file=optimized out, mode=optimized out) at dlopen.c:87 | #10 0x77aa6194 in tlp::PluginLibraryLoader::loadPluginLibrary (filename=..., loader=loader@entry=0x7900d0) | at /work/yann/deb/tulip/tulip/library/tulip-core/src/PluginLibraryLoader.cpp:121 | #11 0x77aa63ea in tlp::PluginLibraryLoader::initPluginDir (this=0x698030, loader=loader@entry=0x7900d0) | at /work/yann/deb/tulip/tulip/library/tulip-core/src/PluginLibraryLoader.cpp:261 | #12 0x77aa73d4 in tlp::PluginLibraryLoader::loadPlugins (loader=loader@entry=0x7900d0, folder=...) at /work/yann/deb/tulip/tulip/library/tulip-core/src/PluginLibraryLoader.cpp:67 | #13 0x77593ac8 in tlp::initTulipSoftware (loader=loader@entry=0x7900d0, removeDiscardedPlugins=removeDiscardedPlugins@entry=true) | at /work/yann/deb/tulip/tulip/library/tulip-gui/src/TlpQtTools.cpp:211 | #14 0x0041cb56 in main (argc=1, argv=optimized out) at /work/yann/deb/tulip/tulip/software/tulip/src/main.cpp:169 -- 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.11-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 tulip depends on: ii binutils 2.24-2 ii libc6 2.17-97 ii libfreetype6 2.5.2-1 ii libftgl2 2.1.3~rc5-4+nmu1 ii libgcc1 1:4.8.2-10 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libgzstream-tulip4.4.04.4.0dfsg-1 ii libogdf-tulip4.4.04.4.0dfsg-1 ii libpython2.7 2.7.6-4 ii libqt4-network4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-opengl 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-xml4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-xmlpatterns4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore44:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii libqtwebkit4 2.2.1-7 ii libquazip-tulip4.4.0 4.4.0dfsg-1 ii libqxt-tulip4.4.0 4.4.0dfsg-1 ii libstdc++64.8.2-10 ii libtulip-core-4.4 4.4.0dfsg-1 ii libtulip-gui-4.4 4.4.0dfsg-1 ii libtulip-ogdf-4.4 4.4.0dfsg-1 ii libtulip-ogl-4.4 4.4.0dfsg-1 ii libtulip-python-4.4 4.4.0dfsg-1 ii libyajl-tulip4.4.04.4.0dfsg-1 ii ttf-dejavu-core 2.33+svn2514-3 ii zlib1g1:1.2.8.dfsg-1 tulip recommends no packages. tulip suggests no packages. -- no debconf information --
Bug#734159: ftgl: not multiarch-enabled
Package: libftgl2 Version: 2.1.3~rc5-4 Severity: normal This would be needed to be able to install eg. dependent i386 programs on amd64. I need this to test strange things with tulip, and will have to rebuild the package for this. If there's no objection, I'll upload it as a delayed NMU. -- 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.11-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 libftgl2 depends on: ii libc6 2.17-97 ii libfreetype6 2.5.1-1 ii libgcc1 1:4.8.2-10 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libstdc++64.8.2-10 ii zlib1g1:1.2.8.dfsg-1 libftgl2 recommends no packages. libftgl2 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#703041: Status of tulip 4.4 package
retitle 703041 new tulip version available tag 703041 + help thanks * pushed my work on 4.4 to the git.d.o repo http://anonscm.debian.org/gitweb/?p=collab-maint/tulip.git;a=summary * 4.4 (as did 4.3) cannot start on amd64, it gets a segfault within dlopen, for which the origin is unclear. Maybe some plugins are malformed, but dlopen should be more helpful. http://bugs.debian.org/723982 * 4.4 built for i386 does start in a 32bit chroot (but segfaults quite easily when trying to import a random graph, this is also something that requires work) * I would test the i386 package as a foreign multiarch one, but libftgl and binutils do not seem to be multiarch-enabled yet. I could override the binutils dep, but libftgl is a real problem here, I'll have to do something there. http://bugs.debian.org/734159 * I'm also working on activating the run of unit tests, just in case they would show something... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734170: ftgl: make clean fails
Package: libftgl2 Version: 2.1.3~rc5-4 Severity: serious $ debuild clean dh_testdir dh_testroot rm -f build-stamp configure-stamp [ ! -f Makefile ] || /usr/bin/make distclean make[1]: Entering directory `/work/yann/deb/tulip/ftgl-2.1.3~rc5' Making distclean in msvc make[2]: Entering directory `/work/yann/deb/tulip/ftgl-2.1.3~rc5/msvc' make[2]: *** No rule to make target `distclean'. Stop. make[2]: Leaving directory `/work/yann/deb/tulip/ftgl-2.1.3~rc5/msvc' make[1]: *** [distclean-recursive] Error 1 make[1]: Leaving directory `/work/yann/deb/tulip/ftgl-2.1.3~rc5' make: *** [clean] Error 2 debuild: fatal error at line 1346: couldn't exec fakeroot debian/rules: The use of SUBDIRS is obviously violating the way automake should be used. Adding msvc to SUBDIRS at it probably should is probably enough, given the lack of build targets in this dir. -- 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.11-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 libftgl2 depends on: ii libc6 2.17-97 ii libfreetype6 2.5.1-1 ii libgcc1 1:4.8.2-10 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libstdc++64.8.2-10 ii zlib1g1:1.2.8.dfsg-1 libftgl2 recommends no packages. libftgl2 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#718100: ftgl: FTBFS: manual build failed
The log shows:
| LaTeX Warning: There were undefined references.
|
| LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
As warnings, they could be innocuous (although the 1st one remains
even if we force the latex runs, and probably should not be there
anyway), but there loads of other strange things starting with:
| ! Missing number, treated as zero.
| to be read again
|\relax
| l.104 \begin{center}
| %
| A number should have been here; I inserted `0'.
| (If you can't figure out why I needed to see a number,
| look up `weird error' in the index to The TeXbook.)
... and latex inserts lots of Ocm and similar texts as printable in
the pdf, the first of which seems to occur within the \begin{center}
expansion in refman.tex:
| %= C O N T E N T S =
|
| \begin{document}
|
| % Titlepage ToC
| \pagenumbering{roman}
| \begin{titlepage}
| \vspace*{7cm}
| \begin{center}%
| {\Large F\-T\-G\-L \\[1ex]\large 2.\-1.\-3$\sim$rc5 }\\
In fact the problem seems to stem with a strange processing done on
doxygen output before feeding it to latex:
mv latex/refman.tex latex/ftgl.tex
sed 's/setlength{/renewcommand{/' latex/ftgl.tex latex/refman.tex
Getting rid of those lines allows the build to proceed, but that
requires autoreconfiguration. Will push a fix to svn if I can get
something clean.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703041: found 723982 in eglibc/2.17-92+b1, found 723982 in eglibc/2.17-97
found 723982 eglibc/2.17-92+b1 found 723982 eglibc/2.17-97 block 703041 with 723982 thanks Bug#723982 is still reproducible in current jessie, using libc6 2.17-97, and impairs debugging of the problems preventing an upload of tulip 4.x. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
On Fri, Dec 13, 2013 at 01:58:31AM +0100, Andreas Beckmann wrote: On 2013-12-03 22:30, Yann Dirson wrote: I'm wondering if that could not be caused by a bug in the mime trigger, that would have been fixed already. That would be easier to test - what package is it? I was thinking about the mime-support trigger, but that package has not been changed for 6 months, so the problem must be somewhere else. Can you please retry the test, reproducible in jessie- sid and wheezy-sid updates to version 2.0~git-20131123-1 and if it still fails, run it while the following stap script is running: That may take some time ... I'll need to rerun the piuparts test manually in a chroot ... and on a different machine ... OK -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727638: memtest new release
On Tue, Dec 10, 2013 at 04:05:26PM +1100, Jackson Doak wrote: Can you please package the new memtest86+ release? It adds a huge number of fixes. Will do - there is a bit of work with existing patches, however... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731378: nss-passwords fails to decrypt
Package: nss-passwords Version: 0.1.1-1 Severity: important nss-passwords, which I only run occasionally, fails today with the following message: Fatal error: exception Main.NSS_decrypt_failed(base64 here, -5977, 0) After trying several accounts on commandline, it looks like it succeeds in finding the password entry but just can't decypher it any more. Could it be some change in libnss that broke something ? -- 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.11-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 nss-passwords depends on: ii libc6 2.17-93 ii libncurses5 5.9+20130608-1 ii libnspr4-0d 2:4.10.2-1 ii libnss3-1d 2:3.15.3-1 ii libsqlite3-03.8.1-1 ii libtinfo5 5.9+20130608-1 ii pinentry-curses [pinentry] 0.8.1-1 nss-passwords recommends no packages. nss-passwords 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#731378: nss-passwords fails to decrypt
On Wed, Dec 04, 2013 at 11:22:42PM +0100, Stéphane Glondu wrote: Le 04/12/2013 20:46, Yann Dirson a écrit : nss-passwords, which I only run occasionally, fails today with the following message: Fatal error: exception Main.NSS_decrypt_failed(base64 here, -5977, 0) After trying several accounts on commandline, it looks like it succeeds in finding the password entry but just can't decypher it any more. Could it be some change in libnss that broke something ? [...] Versions of packages nss-passwords depends on: ii libc6 2.17-93 ii libncurses5 5.9+20130608-1 ii libnspr4-0d 2:4.10.2-1 ii libnss3-1d 2:3.15.3-1 ii libsqlite3-03.8.1-1 ii libtinfo5 5.9+20130608-1 ii pinentry-curses [pinentry] 0.8.1-1 I've got exactly the same versions as you, and it works for me. What version of Iceweasel are you using? That's 24.1.0esr-1. Now that you ask, I realize that I usually used nss-passwords against archived profiles that I don't open any more - and it does still work on them. Only on the currently-in-use profile does it exhibit the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731378: nss-passwords fails to decrypt
On Wed, Dec 04, 2013 at 11:56:32PM +0100, Stéphane Glondu wrote: Le 04/12/2013 23:39, Yann Dirson a écrit : nss-passwords, which I only run occasionally, fails today with the following message: Fatal error: exception Main.NSS_decrypt_failed(base64 here, -5977, 0) After trying several accounts on commandline, it looks like it succeeds in finding the password entry but just can't decypher it any more. Could it be some change in libnss that broke something ? [...] I've got exactly the same versions as you, and it works for me. What version of Iceweasel are you using? That's 24.1.0esr-1. Now that you ask, I realize that I usually used nss-passwords against archived profiles that I don't open any more - and it does still work on them. Only on the currently-in-use profile does it exhibit the problem. I've got also the same Iceweasel version, and nss-passwords works on the currently-in-use profile, if by that you mean used by a currently running instance of Iceweasel. That's what I meant. Do you get the error no matter which password you query? Yes What happens when you query (the empty string)? The same Can you reproduce the bug with a fresh new profile? No. If I create a new profile, record a password, and query for , I do get the recorded password. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726799: qgo: deletes a shipped file during upgrades: /usr/share/mime/text/x-sgf.xml
On Sat, Oct 19, 2013 at 01:09:39PM +0200, Andreas Beckmann wrote:
Package: qgo
Version: 2.0~git-20130914-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package deletes one of its
shipped files during upgrades.
debsums reports modification of the following files,
from the attached log (scroll to the bottom...):
0m50.7s ERROR: FAIL: debsums reports modifications inside the chroot:
debsums: missing file /usr/share/mime/text/x-sgf.xml (from qgo
package)
This is very strange. When I started to investigate, that file had
disappeared from my system too, so it looks like there *is* a bug
somewhere.
However, after reinstalling the testing version, then upgrading to the
sid one, then reinstalling the sid version (under supervision of a
stap script sending SIGSTOP to anyone unlinking that file), I could
not reproduce the problem: only dpkg itself ever gets caught, once,
unlinking the file, which looks reasonable, and the file is there at
the end of the run.
I'm wondering if that could not be caused by a bug in the mime
trigger, that would have been fixed already.
Can you please retry the test, and if it still fails, run it while the
following stap script is running:
--- 8 --- sgf.stap ---
probe begin { println(go...) }
probe syscall.unlink {
if (isinstr(pathname, /x-sgf.xml)) {
println(unlink , kernel_string($pathname))
printf(process traceback:\n %s\n, pstrace(task_current()))
raise(19) # SIGSTOP
}
}
--- 8 ---
(run as stap -g sgf.stap as a user in groups stapdev and stapusr,
with the linux-image-*-dbg matching you running kernel installed)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729738: arguments in macro changed
Hi,
I have started to work on tulip 4.x, but the resulting binary from the
4.3 package (source in git on alioth) is completely unusable, and I
have not located the problem yet. 4.4 has been released recently,
I'll update and we'll see...
(that is, don't spend too much time on 3.7 :)
On Sat, Nov 23, 2013 at 12:57:29PM +0100, Andreas B. Mundt wrote:
Hi,
the number of arguments in QT4_CREATE_MOC_COMMAND seems to have
changed [1]. I tried to fix this by applying the following patch:
--- tulip-3.7.0dfsg.orig/UseTulip.cmake
+++ tulip-3.7.0dfsg/UseTulip.cmake
@@ -47,7 +47,7 @@ MACRO (TULIP_QT4_WRAP_CPP outfiles )
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(it ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/moc_${outfile}.cpp)
-QT4_CREATE_MOC_COMMAND(${it} ${outfile} ${moc_flags} ${moc_options})
+QT4_CREATE_MOC_COMMAND(${it} ${outfile} ${moc_flags} ${moc_options}
${moc_target})
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH(it)
ENDMACRO (TULIP_QT4_WRAP_CPP)
--- tulip-3.7.0dfsg.orig/FindTULIP3.cmake
+++ tulip-3.7.0dfsg/FindTULIP3.cmake
@@ -228,7 +228,7 @@ MACRO (TULIP_QT4_WRAP_CPP outfiles )
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(it ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/moc_${outfile}.cpp)
-QT4_CREATE_MOC_COMMAND(${it} ${outfile} ${moc_flags} ${moc_options})
+QT4_CREATE_MOC_COMMAND(${it} ${outfile} ${moc_flags} ${moc_options}
${moc_target})
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH(it)
ENDMACRO (TULIP_QT4_WRAP_CPP)
However, the build still fails (perhaps) unrelated, see below. As I
have no idea about cmake and my machine takes ages to compile the
sources, I stop here for the time being and hope the provided
information is helpful to fix this thoroughly.
Best Regards,
Andi
[1]
URL:http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ce60ff509c4ff27fe861fc5b2080f50897a68c4
8
[ 62%] Building CXX object
library/tulip-qt/src/CMakeFiles/tulip-qt4-3.7.dir/MainController.cpp.o
cd /tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu/library/tulip-qt/src
/usr/bin/c++ -DQT_CORE_LIB -DQT_DLL -DQT_GUI_LIB -DQT_NO_DEBUG
-DQT_OPENGL_LIB -DQT_THREAD_SUPPORT -Dtulip_qt4_3_7_EXPORTS -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wunused
-DHAVE_LIBJPEG -DHAVE_LIBPNG -D_LINUX -DQT_ASSISTANT='assistant'
-DI64 -Wno-deprecated -Wno-deprecated-declarations -O2 -g -DNDEBUG
-fPIC -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui
-isystem /usr/include/qt4/QtCore -isystem /usr/include/qt4/QtOpenGL
-I/tmp/buildd/tulip-3.7.0dfsg/library/tulip-qt/src/../include
-I/tmp/buildd/tulip-3.7.0dfsg/library/tulip-qt/src/../include/tulip
-I/tmp/buildd/tulip-3.7.0dfsg/library/tulip/include
-I/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu/library/tulip/include
-I/tmp/buildd/tulip-3.7.0dfsg/library/tulip-ogl/include
-I/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu/library/tulip-qt/include
-I/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu/library/tulip-qt/include/tulip
-o CMakeFiles/tulip-qt4-3.7.dir/MainController.cpp.o -c
/tmp/buildd/tulip-3.7.0dfsg/library/tulip-qt/src/MainController.cpp
In file included from
/tmp/buildd/tulip-3.7.0dfsg/library/tulip-qt/src/MainController.cpp:51:0:
/tmp/buildd/tulip-3.7.0dfsg/library/tulip-qt/src/../include/tulip/TabWidget.h:33:33:
fatal error: tulip/TabWidgetData.h: No such file or directory
#include tulip/TabWidgetData.h
^
compilation terminated.
make[4]: ***
[library/tulip-qt/src/CMakeFiles/tulip-qt4-3.7.dir/MainController.cpp.o]
Error 1
make[4]: Leaving directory
`/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu'
make[3]: *** [library/tulip-qt/src/CMakeFiles/tulip-qt4-3.7.dir/all]
Error 2
make[3]: Leaving directory
`/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/tmp/buildd/tulip-3.7.0dfsg/obj-x86_64-linux-gnu'
dh_auto_build: make -j1 returned exit code 2
make[1]: *** [override_dh_auto_build-arch] Error 2
make[1]: Leaving directory `/tmp/buildd/tulip-3.7.0dfsg'
make: *** [binary] Error 2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730019: systemtap: insufficient versionned builddep on libdw-dev friends
On Wed, 20 Nov 2013 19:28:16 +0200 Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Yann Dirson dir...@bertin.fr writes: On Wed, 20 Nov 2013 18:10:03 +0200 Timo Juhani Lindfors timo.lindf...@iki.fi wrote: thanks for filing a bug. However, I'm bit puzzled: are you trying to build systemtap 2.3-1 on ubuntu lucid? Yes, to be able to build the lttng tools which build-depend on it. However, ltt does not require such a recent version, and I was able to easily backport 1.7-1 instead. Ok, in that case you should know that the packaging was never designed to work like that. You can't just take a source package from debian wheezy and expect it to build on ubuntu lucid. Yes, I was ready to do some backporting - I would have backported elfutils if required, I'm just glad 1.7 was less work :) -- Yann Dirson - Bertin Technologies 1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730019: systemtap: insufficient versionned builddep on libdw-dev friends
Package: systemtap Version: 2.3-1 Severity: serious ./configure bails out it elfutils older than 0.148. The current build-deps are satisfied eg. on ubuntu lucid, but in fact it won't build at all :) -- Yann Dirson - Bertin Technologies 1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730019: systemtap: insufficient versionned builddep on libdw-dev friends
On Wed, 20 Nov 2013 18:10:03 +0200 Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Hi, Yann Dirson dir...@bertin.fr writes: Package: systemtap Version: 2.3-1 Severity: serious ./configure bails out it elfutils older than 0.148. The current build-deps are satisfied eg. on ubuntu lucid, but in fact it won't build at all :) thanks for filing a bug. However, I'm bit puzzled: are you trying to build systemtap 2.3-1 on ubuntu lucid? Yes, to be able to build the lttng tools which build-depend on it. However, ltt does not require such a recent version, and I was able to easily backport 1.7-1 instead. In any case, please provide full build log. I'm afraid I won't be able to for various reasons. Retranscribing the last lines: checking for ebl_get_elfmachine in -lebl... no checking for dwfl_module_getsym in -ldw... yes checking for dwarf_next_unit in -ldw... no configure: error: elfutils, libdw too old, need 0.148+ and then config.log shows ld: cannot find -lebl and undefined reference to dwarf_next_unit HTH -- 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#729987: lives: missing dep on libmjpegutils-2.1-0
Package: lives Version: 2.0.6~ds0-1 Severity: serious $ lives test.mov /usr/lib/lives/lives-exe: error while loading shared libraries: libmjpegutils-2.1.so.0: cannot open shared object file: No such file or directory Installing libmjpegutils-2.1-0 fixes the problem. -- 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.11-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 lives depends on: ii frei0r-plugins1.1.22git20091109-1.4 ii imagemagick 8:6.7.7.10-6 ii libasound21.0.27.2-3 ii libatk1.0-0 2.10.0-2 ii libavc1394-0 0.5.4-2 ii libavcodec54 6:9.10-1 ii libavformat54 6:9.10-1 ii libavutil52 6:9.10-1 ii libc6 2.17-93 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libdv41.0.0-6 ii libgcc1 1:4.8.2-1 ii libgdk-pixbuf2.0-02.28.2-1 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglee0d15.4.0-2 ii libglib2.0-0 2.36.4-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgtk-3-03.8.4-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libmjpegutils-2.0-0 1:2.0.0+debian-2 ii libogg0 1.3.1-1 ii liboil0.3 0.3.17-2 ii libpango-1.0-01.36.0-1 ii libpangocairo-1.0-0 1.36.0-1 ii libpng12-01.2.49-5 ii libpulse0 4.0-6+b1 ii libraw1394-11 2.1.0-1 ii libsdl1.2debian 1.2.15-8 ii libstdc++64.8.2-1 ii libswscale2 6:9.10-1 ii libtheora01.1.1+dfsg.1-3.1 ii libunicap20.9.12-2 ii libweed0 2.0.6~ds0-1 ii libx11-6 2:1.6.2-1 ii libxrender1 1:0.9.8-1 ii lives-data2.0.6~ds0-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 ii ogmtools 1:1.5-3+b1 ii perl 5.18.1-4 ii procps1:3.3.4-2 ii python2.7.5-5 ii sox 14.4.1-3 ii zlib1g1:1.2.8.dfsg-1 Versions of packages lives recommends: pn dvgrab none pn icedax none ii libtheora-bin 1.1.1+dfsg.1-3.1 ii mencoder 2:1.0~rc4.dfsg1+svn34540-1+b2 pn mkvtoolnix none ii pulseaudio 4.0-6+b1 ii x11-utils 7.7+1 ii youtube-dl 2013.10.23-1 Versions of packages lives suggests: ii ffmpeg 6:0.8.9-1 pn libdv-bin none pn mjpegtools 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#729918: flufl.enum: upstream version 4.0 available
Package: python-flufl.enum Version: 3.3.2-1 Severity: normal 4.0 has many useful things not in 3.3.2, and it's a bit frustrating to read about them in the doc and not having them here :) -- 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.11-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 python-flufl.enum depends on: ii python 2.7.5-5 ii python2.6 2.6.8-2 ii python2.7 2.7.5-8 python-flufl.enum recommends no packages. Versions of packages python-flufl.enum suggests: pn python-flufl.enum-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#728658: dogtail: cannot deal with unicode chars in window title
Package: python-dogtail Version: 0.8.2-1 Severity: important Looking for a window with name omaha - Gliński's Chess: Gliński's Chess ... activate on [icon | ] Traceback (most recent call last): File ./scripts/uitest.py, line 81, in module excercise_game(game) File ./scripts/uitest.py, line 24, in excercise_game window = app.window(omaha - + game) File /usr/lib/python2.7/dist-packages/dogtail/tree.py, line 1039, in window result = self.findChild (predicate.IsAWindowNamed(windowName=windowName), recursive) File /usr/lib/python2.7/dist-packages/dogtail/tree.py, line 793, in findChild result = self._fastFindChild(pred.satisfiedByNode, recursive) File /usr/lib/python2.7/dist-packages/dogtail/tree.py, line 760, in _fastFindChild if pred(child): return child File /usr/lib/python2.7/dist-packages/dogtail/predicate.py, line 223, in satisfiedByNode return node.roleName=='frame' and stringMatches(self.windowName, node.name) File /usr/lib/python2.7/dist-packages/dogtail/predicate.py, line 13, in stringMatches return scriptName.matchedBy(reportedName) File /usr/lib/python2.7/dist-packages/dogtail/i18n.py, line 172, in matchedBy return stringsMatch(self.untranslatedString, string) File /usr/lib/python2.7/dist-packages/dogtail/i18n.py, line 145, in stringsMatch inString = str(inS) UnicodeEncodeError: 'ascii' codec can't encode character u'\u0144' in position 11: ordinal not in range(128) Obviously, the use of class str here is a very bad idea... -- 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.10-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 python-dogtail depends on: ii python 2.7.5-5 ii python-apt 0.9.1 ii python-gi3.8.2-1 ii python-gi-cairo 3.8.2-1 ii python-pyatspi 2.10.0+dfsg-1 ii xvfb 2:1.12.4-6 Versions of packages python-dogtail recommends: ii imagemagick 8:6.7.7.10-6 pn python-celementtree | python-elementtree none python-dogtail 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#726444: how-can-i-help: can't convert nil into Array
Package: how-can-i-help Version: 0.6 Severity: normal When upgrading yesterday: Processing triggers for libc-bin ... /usr/bin/how-can-i-help:102:in `': can't convert nil into Array (TypeError) from /usr/bin/how-can-i-help:102:in `block in main' from /usr/bin/how-can-i-help:99:in `each' from /usr/bin/how-can-i-help:99:in `main' E: Problem executing scripts DPkg::Post-Invoke '[ ! -e /usr/bin/how-can-i-help ] || /usr/bin/how-can-i-help' E: Sub-process returned an error code A package failed to install. Trying to recover: This problem is not triggered any more now, either from commandline or from further package upgrades. -- 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.10-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 how-can-i-help depends on: ii ruby 1:1.9.3 ii ruby-debian 0.3.8+b1 ii ruby-json 1.8.0-1 ii ruby1.8 [ruby-interpreter]1.8.7.358-8 ii ruby1.9.1 [ruby-interpreter] 1.9.3.448-1 how-can-i-help recommends no packages. how-can-i-help 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#723982: dlopen: segfaults right inside call_init
Source: libc6 Version: 2.17-92+b1 Severity: normal While updating the tulip package to new upstream version, I get a systematic segfault when tulip attempts to load its plugins. I would understand that call_init() would call some code inside the dlopen'd module and segfault there, but in this case the backtrace seems to tell that the segfault is occuring inside libc. According to the backtrace reproduced below, the presumably-faulty code at dl-init.c:84 is: addrs = (ElfW(Addr) *) (init_array-d_un.d_ptr + l-l_addr); for (j = 0; j jm; ++j) 84: ((init_t) addrs[j]) (argc, argv, env); Looks like either addrs would be bogus, or any the pointers therein, and this code does not check either of them, and does not seem to provide any simple means of knowing which of those conditions occured (and recompiling libc just for this may be seen as a bit like overkill :). Even looking at the call_init() code, it is not obvious which code is supposed to be run, as dlopen(3) only mentions _init and __attribute__((constructor)) as possible hooks, and the code talks about DT_INIT_ARRAY. Looking at the elf sections in the plugin, .init_array looks like a good candidate, but is it really necessary to read the libc code and infer such things to reach such a conclusion ? $ objdump -s -j .init_array /usr/lib/tulip//libogdfvisibility-4.3.0.so /usr/lib/tulip//libogdfvisibility-4.3.0.so: file format elf64-x86-64 Contents of section .init_array: 2102e8 0090 e071 .q.. I assume this can be an array of 64bit pointers, or relocatable addresses in the plugin itself that would have been relocated already when used - but I can't find what they would refer to in this .so file. Any hint of a simple way to track such a problem ? Wouldn't it be possible to make call_init() more helpful in case of failure ? Reading symbols from /usr/bin/tulip...Reading symbols from /usr/lib/debug/.build-id/d0/b7ce81909c9154903346982ab0ba3e52f06725.debug...done. done. (gdb) r Starting program: /usr/bin/tulip warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Fontconfig warning: /etc/fonts/conf.d/41-arphic-uming.conf, line 16: Having multiple family in alias isn't supported and may not work as expected ... Fontconfig warning: /etc/fonts/conf.d/64-arphic-uming.conf, line 47: Having multiple values in test isn't supported and may not work as expected No probe DLL specified. [New Thread 0x7fffe8dd4700 (LWP 4127)] [New Thread 0x7fffe332c700 (LWP 4128)] [New Thread 0x7fffe2923700 (LWP 4129)] [Thread 0x7fffe332c700 (LWP 4128) exited] Program received signal SIGSEGV, Segmentation fault. 0x77de99e4 in call_init (env=0x7fffdd18, argv=0x7fffdd08, argc=1, l=optimized out) at dl-init.c:84 84 dl-init.c: No such file or directory. (gdb) bt #0 0x77de99e4 in call_init (env=0x7fffdd18, argv=0x7fffdd08, argc=1, l=optimized out) at dl-init.c:84 #1 call_init (l=optimized out, argc=1, argv=0x7fffdd08, env=0x7fffdd18) at dl-init.c:34 #2 0x77de9aca in _dl_init (main_map=main_map@entry=0x79d410, argc=1, argv=0x7fffdd08, env=0x7fffdd18) at dl-init.c:133 #3 0x77dedaf9 in dl_open_worker (a=a@entry=0x7fffd2d8) at dl-open.c:566 #4 0x77de9826 in _dl_catch_error (objname=objname@entry=0x7fffd2c8, errstring=errstring@entry=0x7fffd2d0, mallocedp=mallocedp@entry=0x7fffd2c7, operate=operate@entry=0x77ded780 dl_open_worker, args=args@entry=0x7fffd2d8) at dl-error.c:177 #5 0x77ded329 in _dl_open (file=0x7c92c8 /usr/lib/tulip//libogdfvisibility-4.3.0.so, mode=-2147483646, caller_dlopen=optimized out, nsid=-2, argc=1, argv=0x7fffdd08, env=0x7fffdd18) at dl-open.c:656 #6 0x71ef6026 in dlopen_doit (a=a@entry=0x7fffd4e0) at dlopen.c:66 #7 0x77de9826 in _dl_catch_error (objname=0x6ad9d0, errstring=0x6ad9d8, mallocedp=0x6ad9c8, operate=0x71ef5fc0 dlopen_doit, args=0x7fffd4e0) at dl-error.c:177 #8 0x71ef65ec in _dlerror_run (operate=operate@entry=0x71ef5fc0 dlopen_doit, args=args@entry=0x7fffd4e0) at dlerror.c:163 #9 0x71ef60c1 in __dlopen (file=optimized out, mode=optimized out) at dlopen.c:87 #10 0x77ad3f36 in tlp::PluginLibraryLoader::loadPluginLibrary (filename=..., loader=loader@entry=0x772db0) at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:120 #11 0x77ad40fd in tlp::PluginLibraryLoader::initPluginDir (this=0x691030, loader=loader@entry=0x772db0) at /work/yann/deb/tulip/tulip-git/library/tulip-core/src/PluginLibraryLoader.cpp:260 #12 0x77ad4be0 in tlp::PluginLibraryLoader::loadPlugins (loader=loader@entry=0x772db0, folder=...) at
Bug#722685: libproxy0: recommends obsolete libmozjs10d
Package: libproxy0 Version: 0.3.1-6 All in title - Possibly libmozjs could use a Provides to avoid the need to update libproxy dependencies on each new iceweasel revision ? -- 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#666525: trying to disable ccache locally, failing
tags 666525 + patch
thanks
On Sat, Aug 31, 2013 at 06:42:01PM +0200, Joel Rosdahl wrote:
Hi,
ccache seems to ignore the request [...] Is there some ccache subtlety
I'm missing?
ccache doesn't ignore the request, it just happens to make sure that the
ccache directory exists before reacting to CCACHE_DISABLE (or
CCACHE_READONLY)... Looks like it has been that way since day one (well,
day two, actually:
http://gitweb.samba.org/?p=ccache.git;a=commit;h=10920460b5b00b77316602eb4e7c998a80464a88
).
I've fixed the bug now (upstream), but there's no workaround in currently
released ccache versions, I'm afraid.
Well, here is one that, although arguably kludgy, does works for me:
simply forcing the dpkg-architecture run to write somewhere else.
--- /usr/lib/pbuilder/pbuilder-satisfydepends.orig 2013-08-29
23:34:32.0 +0200
+++ /usr/lib/pbuilder/pbuilder-satisfydepends 2013-08-31 19:35:14.0
+0200
@@ -59,7 +59,7 @@
function checkbuilddep_internal () {
# Use this function to fulfill the dependency (almost)
-local ARCH=$($CHROOTEXEC dpkg-architecture -qDEB_HOST_ARCH)
+local ARCH=$($CHROOTEXEC env CCACHE_DIR=${TMPDIR:-/tmp}/faraway/ccache
dpkg-architecture -qDEB_HOST_ARCH)
local BUILD_DEP_DEB_DIR
local BUILD_DEP_DEB_CONTROL
local DEPENDS
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721528: freeorion: could provide planning bookkeping
Package: freeorion Version: 0.4.3-1 Severity: wishlist Playing a large game typically requires to mentally keep track of plans in several parts of the galaxy, and the larger the empire the worse it becomes - especially when a long game is played across several sessions. What could be cool to help with this, is a place where one can keep track of things such as to colonize X, I must build/move battleships there, then troops, I build a colony ship of species Y, and bring it there. Could be as simple as tagging a fleet, but then a way to list such tagged fleets as a reminder would be great. OTOH, a real link between tasks would also help in other places: techs can be researched in batch by double-clicking, but once the requirements are stacked in the list, and some costly techs get removed from the list for one reason or another, we can loose track of why we ever requested some dependant tech. Well, just a thought, anyway, I'll try to keep my number of plans down :) -- 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.10-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 freeorion depends on: ii freeorion-data0.4.3-1 ii libalut0 1.1.0-3 ii libboost-filesystem1.53.0 1.53.0-6 ii libboost-python1.53.0 1.53.0-6 ii libboost-serialization1.53.0 1.53.0-6 ii libboost-signals1.53.01.53.0-6 ii libboost-system1.53.0 1.53.0-6 ii libboost-thread1.53.0 1.53.0-6 ii libbulletcollision2.812.81-rev2613+dfsg-3 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.6-2 ii libglu1-mesa [libglu1]9.0.0-1 ii libjpeg8 8d-1 ii liblinearmath2.81 2.81-rev2613+dfsg-3 ii libogre-1.8.0 1.8.0+dfsg1-4+b1 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#721326: xul-ext-debianbuttons: new version available
Package: xul-ext-debianbuttons Version: 1.9-1 Firefox addon-update system claims availability of 1.10 since quite some time now. -- 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#721328: xul-ext-stylish: new version available
Package: xul-ext-stylish Version: 1.3.1+git20130116-1 1.3.3 is available. The watchfile seems uneffective. -- 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#713764: gcompris: FTBFS: rsvg-cairo.h:27:2: error: #warning Including librsvg/rsvg-cairo.h directly is deprecated. [-Werror=cpp]
On Sat, Jun 22, 2013 at 03:27:50PM +0200, David Suárez wrote: Source: gcompris Version: 12.01-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130620 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[5]: Entering directory `/«PKGBUILDDIR»/src/algebra_by-activity' CC algebra.lo In file included from ../../src/goocanvas/src/goocanvassvg.h:13:0, from ../../src/goocanvas/src/goocanvas.h:22, from ../../src/gcompris/gcompris.h:26, from algebra.c:22: /usr/include/librsvg-2.0/librsvg/rsvg-cairo.h:27:2: error: #warning Including librsvg/rsvg-cairo.h directly is deprecated. [-Werror=cpp] #warning Including librsvg/rsvg-cairo.h directly is deprecated. ^ cc1: all warnings being treated as errors make[5]: *** [algebra.lo] Error 1 About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. Hm, did you inject -Werror through dpkg-buildflags ? In pbuilder I get the warning for 12.11-1 as well but there is no -Werror to make it fatal. Makes me wonder if this qualifies for FTBFS at all... -- 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.
Hi Markus, On Sun, Aug 18, 2013 at 05:01:16PM +0200, Markus Koschany wrote: Hi Yann and Marius, I'm in contact with the developers of FreeOrion and they asked me to relay a question to you. Quote from http://www.freeorion.org/forum/viewtopic.php?f=25t=7719 This is still easily repeatable for me today, I can open up options, go to the directories page, confirm I can type, alt-tab out, click back in, and then I cannot type (or rather, it doesn't accept my input, I think it is reading it all as 'alt-a', 'alt-b', etc) until I hit the ALT key again (has to be the same one I used to alt-tab), and then everything is fine. The alt-lock does not get initiated just by hitting the alt-key a first time, it seems to only start by alt-tab. You can switch with ALT-Tab between different windows and FreeOrion and sometimes you can't type because this locks your keyboard input. Can you confirm that pressing ALT again in this case allows you to type again? With the workaround I do have Al-TAB issues: If I try hit Alt-TAB, nothing seems to happen; on second Alt-TAB press the border of the fullscreen window flashes and I can then use desktop shortcuts (Here Win-F1 to switch desktop, or simply Alt-TAB). Eg Win-F1 is completely ignored unless I hit Alt-TAB first, Alt alone is not sufficient. When I get back to the desktop where FreeOrion is running, I can switch away immediately, as long as I did not click the game first, after which I'm back into the locked mode. Is that what you meant, or did you mean without the workaround ? Another idea: Reading the debian bug about the inconsistent time this problem occurs I would like to know if some notification mechanism snitches away the focus of the window. Maybe that is something your user should test with some x11 event tracing. xtrace or xev maybe show us the relevant hint. Can you try reproducing this bug and showing us the output of xtrace? xtrace freeorion xtrace.log Perhaps another application interferes with FreeOrion and this might be a way to track down the issue. Thanks in advance. Regards, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666525: trying to disable ccache locally, failing
By tuning the stap script to SIGSTOP the offending process, we can get
a much better view of the situation - here using pstree:
pbuilder,4611 /usr/sbin/pbuilder --build --buildresult .. --debbuildopts
--debbuildopts -i ../cssc_1.3.0-1.dsc
└─pbuilder-buildp,4612 /usr/lib/pbuilder/pbuilder-buildpackage --buildresult
.. --debbuildopts --debbuildopts -i ../cssc_1.3.0-1.dsc
└─pbuilder-satisf,5767 /usr/lib/pbuilder/pbuilder-satisfydepends
--control ../cssc_1.3.0-1.dsc --chroot /work/pbuilder/build//4612
--internal-chrootexec chroot /work/pbuilder/build//4612 --binary-all
└─pbuilder-satisf,5768 /usr/lib/pbuilder/pbuilder-satisfydepends
--control ../cssc_1.3.0-1.dsc --chroot /work/pbuilder/build//4612
--internal-chrootexec chroot /work/pbuilder/build//4612 --binary-all
└─dpkg-architectu,5769 /usr/bin/dpkg-architecture -qDEB_HOST_ARCH
└─sh,5770 -c ${CC:-gcc} -dumpmachine
└─gcc,5771 -dumpmachine
A quick test can be done of reqesting disabling of ccache while calling
dpkg-architecture.
Test:
--- /usr/lib/pbuilder/pbuilder-satisfydepends.orig 2013-08-29
23:34:32.0 +0200
+++ /usr/lib/pbuilder/pbuilder-satisfydepends 2013-08-29 23:36:23.0
+0200
@@ -59,7 +59,7 @@
function checkbuilddep_internal () {
# Use this function to fulfill the dependency (almost)
-local ARCH=$($CHROOTEXEC dpkg-architecture -qDEB_HOST_ARCH)
+local ARCH=$($CHROOTEXEC env CCACHE_DISABLE=1 dpkg-architecture
-qDEB_HOST_ARCH)
local BUILD_DEP_DEB_DIR
local BUILD_DEP_DEB_CONTROL
local DEPENDS
For some reason, the stap script still traps a mkdir done as root,
while I can check through /proc that dpkg-architecture and gcc do have
CCACHE_DISABLE=1 in their env.
Another try: if ccache ignores the disable request, maybe we can ask
it not to touch the cache ?
--- /usr/lib/pbuilder/pbuilder-satisfydepends.orig 2013-08-29
23:34:32.0 +0200
+++ /usr/lib/pbuilder/pbuilder-satisfydepends 2013-08-29 23:56:48.0
+0200
@@ -59,7 +59,7 @@
function checkbuilddep_internal () {
# Use this function to fulfill the dependency (almost)
-local ARCH=$($CHROOTEXEC dpkg-architecture -qDEB_HOST_ARCH)
+local ARCH=$($CHROOTEXEC env CCACHE_READONLY=1
CCACHE_TEMPDIR=${TMPDIR:-/tmp} dpkg-architecture -qDEB_HOST_ARCH)
local BUILD_DEP_DEB_DIR
local BUILD_DEP_DEB_CONTROL
local DEPENDS
... but similarly, ccache seems to ignore the request, which can be
seen in the processes' env.
Is there some ccache subtlety I'm missing ? Could ccache maints lend a hand
here ?
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#666525: culprit located as dpkg-architecture ?
Running a build with systemtap set to intercept:
* calls to mkdir() as root under ccache
* mkdir failures with EACCESS
... reveals quite constant shape of the process tree leading to the
suspect mkdir's, and strong correlation with the EACCESS problems (and
with the actual ccache subdirs owned by root, as expected):
$ stap /work/yann/deb/cssc/mkdir.stap
go...
mkdir /work/pbuilder/ccache/tmp
process traceback:
gcc(32018) sh(32017) dpkg-architectu(32016) pbuilder-satisf(32015)
pbuilder-satisf(32014) pbuilder-buildp(30987) pbuilder(30986) sudo(30985)
pdebuild(29971) bash(4485) screen(4306)
mkdir /work/pbuilder/ccache/2
process traceback:
gcc(32018) sh(32017) dpkg-architectu(32016) pbuilder-satisf(32015)
pbuilder-satisf(32014) pbuilder-buildp(30987) pbuilder(30986) sudo(30985)
pdebuild(29971) bash(4485) screen(4306)
mkdir /work/pbuilder/ccache/2/4 = EACCESS
mkdir /work/pbuilder/ccache/2/5 = EACCESS
mkdir /work/pbuilder/ccache/2/d = EACCESS
mkdir /work/pbuilder/ccache/2/6 = EACCESS
mkdir /work/pbuilder/ccache/2/e = EACCESS
mkdir /work/pbuilder/ccache/2/e = EACCESS
...
dpkg-architecture launching gcc ? Now that's a funny surprise :)
I hope this information will be of some help...
probe begin { println(go...) }
probe syscall.mkdir.return {
err = errno_p(returnval())
if (err == 13) {
println(mkdir , kernel_string($pathname), = EACCESS)
}
}
probe syscall.mkdir {
if ((uid() == 0) isinstr(pathname, /ccache/)) {
println(mkdir , kernel_string($pathname))
printf(process traceback:\n %s\n, pstrace(task_current()))
}
}
Bug#720512: override: gcompris*:education/optional
Package: ftp.debian.org Severity: normal To make use of the new education section. All gcompris* packages are concerned. 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#720387: freemind: bogus french transation for find and replace
Package: freemind Version: 0.9.0+dfsg-2 Severity: important Find and replace in french would be Chercher et remplacer, not Montrer l'historique de la carte which means Show map history ! -- 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#720388: freemind: fails to locate jgoodies ButtonBarFactory class
Package: freemind Version: 0.9.0+dfsg-2 Severity: important Selecting the Find and replace menu entry causes the following exception: STDERR: Exception in thread AWT-EventQueue-0 STDERR: java.lang.NoClassDefFoundError: com/jgoodies/forms/factories/ButtonBarFactory STDERR: at accessories.plugins.time.TimeList.startupMapHook(TimeList.java:298) STDERR: at freemind.modes.mindmapmode.MindMapController.invokeHook(MindMapController.java:1722) STDERR: at freemind.modes.mindmapmode.actions.MindMapControllerHookAction.actionPerformed(MindMapControllerHookAction.java:48) 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.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) 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) STDERR: Caused by: java.lang.ClassNotFoundException: com.jgoodies.forms.factories.ButtonBarFactory STDERR: at java.net.URLClassLoader$1.run(URLClassLoader.java:217) STDERR: at java.security.AccessController.doPrivileged(Native Method) STDERR: at java.net.URLClassLoader.findClass(URLClassLoader.java:205) STDERR: at java.lang.ClassLoader.loadClass(ClassLoader.java:321) STDERR: at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) STDERR: at java.lang.ClassLoader.loadClass(ClassLoader.java:266) STDERR: ... 42 more -- 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
