Bug#1064726: reopen, still ftbfs
Hello Matthias, On Sun, 14 Apr 2024 20:45:07 +0200 Matthias Klose wrote: > Control: reopen -1 > > the package still build-depends on python3-distutils, removed in 3.12. > > the package then ftbfs with > > [...] > line 13, in > from six.moves import builtins as __builtin__ I just rebuilt 0ad from a clean & updated sid chroot and had no problem. I then found the problem: Python 3.12 is in experimental and not yet in sid. So the FTBFS occurs only with packages from experimental. I understand it will be a problem SOON. Maybe you should have created a *new* bug instead of reopening this one since that is not the same problem. I will work on the issue. Thanks
Bug#1064726: reopen, still ftbfs
Le 17/04/2024 à 14:17, Ludovic Rousseau a écrit : I will work on the issue. The problem with Python 3.12 is already known upstream in https://trac.wildfiregames.com/ticket/6895 It should be fixed with the next version of 0ad i.e. alpha 27. Bye -- Dr. Ludovic Rousseau
Bug#1064726: Should I upload 0ad involved in wxwidgets3.2 migration?
Hello Debian Release team, 0ad has a FTBFS bug #1064726. I have a new version with the fix ready for upload. But when trying to upload I get: - $ dupload --to debian-ssh *_source.changes --no dupload note: no announcement will be sent. Checking OpenPGP signatures before upload..signatures are ok Checking Debian transitions... Warning: Source package 0ad is part of ongoing transitions: <https://release.debian.org/transitions/html/auto-curl> <https://release.debian.org/transitions/html/auto-libpng1.6> <https://release.debian.org/transitions/html/auto-wxwidgets3.2> If the upload does not solve issues caused by these transitions, then it might disrupt them by adding delays or entangling them. For more information, please read: <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook> Note: If you are aware of this and do not want to be warned, you can disable this hook from the configuration file, skip it with --skip-hooks or set the one-off environment variable DUPLOAD_SKIP_HOOKS, or alternatively you can reply to the following prompt. Continue anyway? (yes/NO) - I see 0ad listed in https://release.debian.org/transitions/html/auto-wxwidgets3.2.html Of course the rebuild failed because the FTBFS fix is not yet in unstable. Should I upload a new version of 0ad to help the wxwidgets3.2 migration? Should I wait for 0ad to be removed from testing (planned in 5 days)? Please Cc: me on reply. Thanks -- Dr. Ludovic Rousseau
Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2
Le 03/03/2024 à 17:13, Adrian Bunk a écrit : Source: ausweisapp2 Version: 2.0.3-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Ludovic Rousseau https://buildd.debian.org/status/logs.php?pkg=ausweisapp2&ver=2.1.0-1 ... /<>/src/card/pcsc/PcscUtils.h:112:46: error: ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean ‘SCARD_E_UNKNOWN_RES_MSG’? 112 | Scard_E_Unknown_Res_Mng = returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error code was returned from a layered component. */ | ^~~ ... This is not a regression in the new ausweisapp2 upload, but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed): https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237 "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG" Exact. I now discover that Windows does define BOTH values: SCARD_E_UNKNOWN_RES_MSG 0x8010002B in https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpesc/9861f8da-76fe-41e6-847e-40c9aa35df8d SCARD_E_UNKNOWN_RES_MNG 0x8010002B in https://learn.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values I guess pcsc-lite will also have to define both values. I will release a new pcsc-lite version soon. Sorry. -- Dr. Ludovic Rousseau
Bug#1034209: pcscd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Le 11/04/2023 à 09:37, bi...@debian.org a écrit : Note that bookworm is currently in hard freeze, please limit the changes you are uploading to the ones fixing RC bugs. Also note that you might have to request a freeze exception to the release team. See: https://release.debian.org/testing/freeze_policy.html I asked release.debian.org for an unblock in #1034434 Bye -- Dr. Ludovic Rousseau
Bug#1013929: src:goffice: FTBFS on mips64el
Le 02/08/2022 à 11:27, Dmitry Smirnov a écrit : Hi Ludovic, On Sunday, 31 July 2022 12:36:04 AM AEST Ludovic Rousseau wrote: I am the Debian maintainer of the package grisbi that depends on libgoffice-0.10-10 I see no update on this bug since 3 weeks. It looks like the fix is proposed upstream at https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045 Sorry, I'm being very slow lately... I've applied the upstream patch but unfortunately it did not fix the problem... I think we now have a *different* issue. The initial build failure https://buildd.debian.org/status/fetch.php?pkg=goffice&arch=mips64el&ver=0.10.52-2&stamp=1656999642&raw=0 was during execution of dh_auto_build command: /usr/bin/ld: .libs/goffice-0.10-scan.o: in function `get_object_types': ./docs/reference/goffice-0.10-scan.c:207: undefined reference to `go_complexl_get_type' /usr/bin/ld: ./docs/reference/goffice-0.10-scan.c:207: undefined reference to `go_complexl_get_type' collect2: error: ld returned 1 exit status 2022-07-05 05:40:30,271:scangobj.py:execute_command:1289:WARNING:Linking scanner failed: 1, command: /bin/bash ../../libtool --tag=CC --mode=link mips64el-linux-gnuabi64-gcc -lgobject-2.0 -lglib-2.0 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -Wall -Werror=init-self -Werror=missing-include-dirs -Wsign-compare -Werror=pointer-arith -Wchar-subscripts -Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn -Werror=missing-prototypes -Werror=implicit-function-declaration -Wmissing-declarations -Wno-pointer-sign -Werror=format-security -Wstrict-prototypes -Wno-error=format-nonliteral -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib goffice-0.10-scan.lo ../../goffice/libgoffice-0.10.la -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgsf-1 -lrsvg-2 -lm -lxslt -lxml2 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib -o goffice-0.10-scan make[3]: *** [Makefile:695: scan-build.stamp] Error 1 make[3]: Leaving directory '/<>/docs/reference' make[2]: *** [Makefile:438: all-recursive] Error 1 make[2]: Leaving directory '/<>/docs' make[1]: *** [Makefile:552: all-recursive] Error 1 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j4 returned exit code 2 make: *** [debian/rules:70: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 With the new upstream patch the build failure is during ecxecution of dpkg-gensymbols command: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libgoffice-0.10-10/DEBIAN/symbols doesn't match completely debian/libgoffice-0.10-10.symbols --- debian/libgoffice-0.10-10.symbols (libgoffice-0.10-10_0.10.52-3_mips64el) +++ dpkg-gensymbolsz0mJDF 2022-08-02 08:51:19.169391884 + @@ -60,22 +60,22 @@ go__VOID__INT_BOOLEAN_BOOLEAN_BOOLEAN@Base 0.9.0 go_accumulator_add@Base 0.9.0 go_accumulator_add_quad@Base 0.9.1 - go_accumulator_add_quadl@Base 0.9.1 - go_accumulator_addl@Base 0.9.0 +#MISSING: 0.10.52-3# go_accumulator_add_quadl@Base 0.9.1 +#MISSING: 0.10.52-3# go_accumulator_addl@Base 0.9.0 go_accumulator_clear@Base 0.9.0 - go_accumulator_clearl@Base 0.9.0 +#MISSING: 0.10.52-3# go_accumulator_clearl@Base 0.9.0 [...] Some symbols, ending with "l", were previously defined but are no more present. From the header file https://gitlab.gnome.org/GNOME/goffice/-/blob/master/goffice/math/go-accumulator.h#L29 we see that the symbol go_accumulator_addl() is defined only if GOFFICE_WITH_LONG_DOUBLE is defined. But in debian/rules we still have "--without-long-double" option for mips64el. I think that is the source of the new problem. Have you tried to *revert* https://salsa.debian.org/debian/goffice/-/commit/3cd973d85f5b6d337100270e068f09fd30d8cea5 and keep only the new upstream patch? Hope this helps. -- Dr. Ludovic Rousseau
Bug#1013929: src:goffice: FTBFS on mips64el
Hello, I am the Debian maintainer of the package grisbi that depends on libgoffice-0.10-10 I see no update on this bug since 3 weeks. It looks like the fix is proposed upstream at https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045 Dmitry, do you need help? Thanks -- Dr. Ludovic Rousseau
Bug#953533: opensc: Fails to build due to missing bash_completion files
severity 953533 normal
thank
On Tue, 10 Mar 2020 08:10:06 + "Cirujano Cuesta, Silvano"
wrote:
> Package: opensc
> Version: 0.20.0-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Tags: ftbfs
>
> Trying to build fails. I've tried following two ways.
>
> I've tried
> apt-get source opensc ; debuild -b -uc -us
> and
> apt-get --build source opensc
>
>
> The error message is:
>
> dh_install: warning: Cannot find (any matches for)
> "debian/tmp/etc/bash_completion.d/*"
> (tried in ., debian/tmp)
> dh_install: warning: opensc missing files:
> debian/tmp/etc/bash_completion.d/*
> dh_install: error: missing files,aborting
> make: *** [debian/rules:4: binary] Error 25
I can reproduce your problem using "debuild" in testing.
But I can't reproduce it using "gbp buildpackage" and cowbuilder
When the package is built with debuild I have:
" OpenSC has been configured with the following options:
[...]
Bash completion: /usr/share/bash-completion/completions
[...] "
But when the package is built with gbp (or the Debian builders) I find:
" OpenSC has been configured with the following options:
[...]
Bash completion: /etc/bash_completion.d
[...] "
The problem is this piece of code in configure.ac:
if test "${completiondir}" = "detect"; then
echo completion ${completiondir}
PKG_CHECK_MODULES([BASH_COMPLETION], [bash-completion >= 2.0],
[completiondir="`pkg-config --variable=completionsdir
bash-completion`"],
[completiondir="${sysconfdir}/bash_completion.d"])
fi
If bash-completion package is installed then the scipt uses:
$ pkg-config --variable=completionsdir bash-completion
that returns:
/usr/share/bash-completion/completions
But if bash-completion is NOT installed then
${sysconfdir}/bash_completion.d i.e. /etc/bash_completion.d is used instead.
If you remove the package bash-completion then the build will succeed.
I changed the priority of this bug since it fails to build only in some
cases.
I wanted to push my patch to https://salsa.debian.org/opensc-team/opensc
but I am not a member of the "opensc-team" group on Salsa.
https://salsa.debian.org/opensc-team
My patch is attached so Eric can apply it.
>From ee128132d5ea8644151d7aa180fe580847de3c28 Mon Sep 17 00:00:00 2001
From: Ludovic Rousseau
Date: Sat, 29 Aug 2020 22:26:24 +0200
Subject: [PATCH] Fix "Fails to build due to missing bash_completion files"
Fix bash_completion path (Closes: #953533)
---
debian/changelog | 9 +
debian/control| 3 ++-
debian/opensc.install | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 404cedf5..6b72f71e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+opensc (0.20.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "Fails to build due to missing bash_completion files"
+Build-Depends: bash-completion so the correct path is found
+(Closes: #953533)
+
+ -- Ludovic Rousseau Sat, 29 Aug 2020 22:25:43 +0200
+
opensc (0.20.0-3) unstable; urgency=medium
* Fix patch to use /etc/opensc for opensc.conf (Closes: 949229)
diff --git a/debian/control b/debian/control
index 374a55f2..03c11d73 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,8 @@ Priority: optional
Section: utils
Maintainer: Debian OpenSC Maintainers
Uploaders: Eric Dorland
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: bash-completion,
+ debhelper-compat (= 12),
docbook-xsl,
flex,
help2man,
diff --git a/debian/opensc.install b/debian/opensc.install
index 6213ab66..753806cb 100644
--- a/debian/opensc.install
+++ b/debian/opensc.install
@@ -1,5 +1,5 @@
debian/tmp/usr/bin/*
-debian/tmp/etc/bash_completion.d/* usr/share/bash-completion/completions
+debian/tmp/usr/share/bash-completion/completions
debian/tmp/usr/share/man/man1/*
debian/tmp/usr/share/man/man5/*
--
2.28.0
Bug#953533: Additional information
Eric, I do plan to fix this issue and upload a fixed OpenSC to Debian. I will do an delayed upload to you can react if you want. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#delayed-incoming Bye On Wed, 11 Mar 2020 11:38:58 + "Cirujano Cuesta, Silvano" wrote: Sorry, I attached a wrong patch to my previous e-mail. Attached to this message I send a patch that works for me. -- Dr. Ludovic Rousseau
Bug#967118: 0ad: Unversioned Python removal in sid/bullseye
I tried to rebuild 0ad without python installed. The build fails with: [...] Building SpiderMonkey... SpiderMonkey build options: --enable-shared-js --disable-tests --without-intl-api --enable-shared-js --disable-tests --without-intl-api [...] checking for full perl installation... yes checking for python2.7... no checking for python... no configure: error: python was not found in $PATH [...] This is with SpiderMonkey from mozjs-38.2.1. The problem should be solved when 0ad will support a more recent version of SpiderMonkey. The problem is already knwon upstream. https://trac.wildfiregames.com/ticket/5694 Bye On Tue, 04 Aug 2020 09:27:36 + Matthias Klose wrote: > Package: src:0ad > Version: 0.0.23.1-4 > Severity: serious > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2unversioned > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > We will keep some Python2 package as discussed in > https://lists.debian.org/debian-python/2020/07/msg00039.html > but removing the unversioned python packages python-minimal, python, > python-dev, python-dbg, python-doc. > > Your package either build-depends, depends on one of those packages. > Please either convert these packages to Python3, or if that is not > possible, replaces the dependencies on the unversioned Python > packages with one of the python2 dependencies (python2, python2-dev, > python2-dbg, python2-doc). > > Please check for dependencies, build dependencies AND autopkg tests. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > >
Bug#927824: Grisbi 1.2.1-1 always crashes when creating a new transaction
Le 24/04/2019 à 15:51, Ludovic Rousseau a écrit : debian-release will not accept to migrate 1.2.2 into testing. Maybe they will. Grisbi version 1.2.2 is just a bug fix of version 1.2.1. I created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927881 asking for an unblock. Bye -- Dr. Ludovic Rousseau
Bug#879071: 0ad FTBFS with on armhf with gcc 7: error: call of overloaded 'abs(unsigned int)' is ambiguous
2017-11-21 1:25 GMT+01:00 peter green : > On 19/11/17 14:38, Ludovic Rousseau wrote: > > Peter, > > Please go with the NMU. > > Done, final debdiff attatched. > Thanks. I pushed your changes in https://anonscm.debian.org/ viewvc/pkg-games/packages/trunk/0ad/debian/ > You may also want to fix the arm64 build failure at the same time. > See https://buildd.debian.org/status/fetch.php?pkg=0ad&arch=arm6 > 4&ver=0.0.22-1&stamp=1508351579&raw=0 > > That looks like it is failing in buliding an embedded copy of mozjs. > > Is there some reason 0ad has to use an embedded copy of mozjs rather than > one of the versions packaged in Debian. > No idea. 0ad has its own list of patches above mozjs 38.2.1. See http://sources.debian.net/src/0ad/0.0.21-2/libraries/source/spidermonkey/ I have no idea if the official mozjs packaged in Debian can be used instead. That is something that could be experimented. I just maintain the 0ad package since 2 months. Bye, -- Dr. Ludovic Rousseau
Bug#879071: 0ad FTBFS with on armhf with gcc 7: error: call of overloaded 'abs(unsigned int)' is ambiguous
Peter, Please go with the NMU. You may also want to fix the arm64 build failure at the same time. See https://buildd.debian.org/status/fetch.php?pkg=0ad&arch=arm64&ver=0.0.22-1&stamp=1508351579&raw=0 Thanks 2017-11-19 13:38 GMT+01:00 peter green : > Jumping straight to removing an architecture from the architecture list > and filing a removal request over a build failure with no evidence of an > attempt at a fix and no attempt to bring it up with the porters is not in > line with "Packages must be supported on as many architectures as is > reasonably possible". > > I decided to take a look at actually fixing this bug. > > It seems that the cause is the signedness of wchar_t. It appears that on > arm linux wchar_t is unsigned whereas on x86 linux wchar_t is signed. > > The result is that on arm linux the subtraction produces an unsigned > result. The standard libary has no abs functions for unsigned types and so > you get the ambiguous call error. > > Casting both arguments of the subtraction to int fixes the error. > > Debdiff attatched, no immediate intent to NMU. > > ___ > Pkg-games-devel mailing list > pkg-games-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel > -- Dr. Ludovic Rousseau
Bug#879071: fixed in 0ad 0.0.22-2
2017-11-18 17:28 GMT+01:00 James Cowgill : > Hi, > > On 18/11/17 16:21, Ludovic Rousseau wrote: > > Hello, > > > > 2017-11-18 6:21 GMT+01:00 Petter Reinholdtsen : > > > >> [Ludovic Rousseau] > >>> 0ad (0.0.22-2) unstable; urgency=medium > >>> . > >>>* Fix "0ad FTBFS with on armhf with gcc 7: error: call of overloaded > >>> 'abs(unsigned int)' is ambiguous" by removing support of armhf > >>> (Closes: #879071) > >> > >> Note, this "fix" did not work, as there are armhf binaries in the > archive > >> and the new version is not allowed to propagate into testing until the > >> armhf binaries are updated to the latest version or removed. Did you > >> file a request for removal? > >> > > > > Adrian Bunk filed bug #880058 "RM: 0ad [armhf] -- NBS; no longer built on > > armhf" > > > > I am not sure it will be enough since the versions for arm64, > > kfreebsd-amd64 and kfreebsd-i386 must also be removed. > > Should I create 3 new bugs for the other 3 architectures? > > You can just retitle the original bug, with a message explaining the > situation (assuming it isn't closed before then). > > Currently we have: > 0ad | 0.0.21-2 | stretch | source, amd64, armhf, i386 > 0ad | 0.0.21-2 | sid | source, armhf, kfreebsd-amd64, kfreebsd-i386 > 0ad | 0.0.22-3 | sid | source, amd64, i386 > > So I think only armhf and kfreebsd-* need removing (not arm64). kfreebsd > doesn't affect testing migration in any case. > So bug #880058, as it is, will remove the armhf version and 0ad should then be able to migrate to testing. I should _not_ file new bugs. Exact? Thanks -- Dr. Ludovic Rousseau
Bug#879071: fixed in 0ad 0.0.22-2
Hello, 2017-11-18 6:21 GMT+01:00 Petter Reinholdtsen : > [Ludovic Rousseau] > > 0ad (0.0.22-2) unstable; urgency=medium > > . > >* Fix "0ad FTBFS with on armhf with gcc 7: error: call of overloaded > > 'abs(unsigned int)' is ambiguous" by removing support of armhf > > (Closes: #879071) > > Note, this "fix" did not work, as there are armhf binaries in the archive > and the new version is not allowed to propagate into testing until the > armhf binaries are updated to the latest version or removed. Did you > file a request for removal? > Adrian Bunk filed bug #880058 "RM: 0ad [armhf] -- NBS; no longer built on armhf" I am not sure it will be enough since the versions for arm64, kfreebsd-amd64 and kfreebsd-i386 must also be removed. Should I create 3 new bugs for the other 3 architectures? This bug just caused 0ad to be removed from testing. > Yes. I saw that. Thanks -- Dr. Ludovic Rousseau
Bug#881532: Please keep out of buster
2017-11-12 20:38 GMT+01:00 Laurent Bigonville : > Source: goffice-0.8 > Version: 0.8.17-8 > Severity: serious > Tags: sid buster > > Hi, > > goffice-0.8 is only used by gnucash and grisbi in the archive. > > Both gnucash and grisbi have already switched to goffice 0.10 in an > unstable version or in their git repository. > > At the time of the buster release, they'll hopefully have migrated to > that new major version of goffice, so it's probably a good idea to get > rid of goffice-0.8 for buster. > > I guess this can be revised when we are getting closer from the release. > I am the Debian Maintainer of grisbi. I have no idea when grisbi 1.1 (with support of goffice 0.10) will be released. The progress is very slow. At worst it is possible to build grisbi 1.0 without support of goffice-0.8. So goffice-0.8 can be removed. Bye -- Dr. Ludovic Rousseau
Bug#854703: disappears and never returns?
severity 854703 normal thank On Thu, 09 Feb 2017 11:49:56 -0500 Antoine Beaupre wrote: Package: pcscd Version: 1.8.20-1 Severity: grave Since I upgraded from 1.8.19-1 to 1.8.20-1 (or maybe it is because of scdaemon 2.1.18, unclear), I cannot reliably use pcscd for multiple days. After a while, the pcscd daemon just disappears, and then scdaemon cannot talk to it anymore: fév 09 11:37:57 curie gpg-agent[23116]: scdaemon[32496] pcsc_establish_context failed: no service (0x8010001d) This was partly documented in #854005 (GnuPG bug) and #854616 (scdaemon bug) which both have workarounds, and I was able to finally use my yubikey *without* pcscd. But I believe there is a pcscd-specific bug here that makes it basically unusable (hence the grave severity). Thanks for the 2 other bug numbers. You are the first one to report such a problem. I set the severity to normal. $ systemctl --system status pcscd â pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/etc/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) since Wed 2017-02-08 21:37:16 EST; 14h ago Process: 15485 ExecStart=/usr/sbin/pcscd --foreground --auto-exit --debug (code=exited, status=0/SUCCESS) Main PID: 15485 (code=exited, status=0/SUCCESS) As you may have noticed, I have modified the .service file to enable debugging: [Unit] Description=PC/SC Smart Card Daemon Requires=pcscd.socket [Service] ExecStart=/usr/sbin/pcscd --foreground --auto-exit --debug ExecReload=/usr/sbin/pcscd --hotplug [Install] Also=pcscd.socket After that, I have noticed that pcscd gladly commits suicide: fév 08 21:37:15 curie pcscd[15485]: 0023 pcscdaemon.c:225:signal_thread() Preparing for suicide This is expected. pcscd is started automatically by systemd when needed. See "pcscd auto start using systemd" https://ludovicrousseau.blogspot.fr/2011/11/pcscd-auto-start-using-systemd.html That time is about the time I stopped working last night. I unplugged my Yubikey and went to bed. The workaround is, obviously, to restart pcscd: sudo systemctl restart pcscd I guess you broke/disabled the socket activation. Use: sudo systemctl stop pcscd.socket sudo systemctl start pcscd.socket It is unclear to me why this regression happened. The systemd files haven't changed since 2011, so presumably the use of --auto-exit is normal. Maybe something changed in the --auto-exit algorithm? Looking upstream, I can't find anything specific. Maybe scdaemon doesn't talk to the right socket anymore, or that socket activation is failing somehow? I don't know or use scdaemon. Trying to access the same device (a smart card reader) from 2 processes is not a good idea. I don't know why the GnuPG people have reinvented the wheel instead of using PC/SC. I think they thought it was safer to do it their way. And now we have problems... The safest default configuration for scdaemon should be "disable-ccid" so it "Just works ™". For users that _really_ know what they do they can use the scdaemon internal ccid driver. Am I the only one seeing this behavior? Yes, AFAIK. It is not a pcsc-lite bug. So unless you prove otherwise I will just close it "soon". Bye -- Dr. Ludovic Rousseau
Bug#827716: Non-maintainer upload to fix RC bugs
Le 28/06/2016 à 20:55, Ondřej Surý a écrit : It was not in the d/control, so I pushed imported package to collab-maint/tidy-html5. I'll import my and LoB patches on top of tidy.git and push it tomorrow. OK. Daniel James already closed some of the bugs in https://anonscm.debian.org/cgit/collab-maint/tidy.git/ Your merge may not be easy. I already asked [1] Daniel to do the merge. Since there is no urgency now I propose to let Daniel integrate your changes. Bye [1] https://github.com/htacg/tidy-html5/issues/354#issuecomment-229114742 -- Dr. Ludovic Rousseau
Bug#827716: Non-maintainer upload to fix RC bugs
Le 28/06/2016 à 15:49, Ondřej Surý a écrit : JFTR I took your patch and did a direct upload to sid to finally fix these two RC bugs. Also Ludovic, could you please take more care next time you sponsor an upload? Unplanned transitions and FTBFS on r-deps are not something we are very happy about. Yes. Sorry about that. I was not aware that the library was used by other packages. It looks like you have not pushed your changes to the project at collab-maint https://anonscm.debian.org/cgit/collab-maint/tidy.git/ Is it intentional? I guess you just was not aware that the package was maintained in collab-maint. This information is not (yet) present in debian/control. Thanks -- Dr. Ludovic Rousseau
Bug#823426: asedriveiiie: FTBFS: install: cannot stat 'libASEDriveIIIe-USB.so': No such file or directory
Hello, I can't reproduce the problem on a freshly upgraded sid system. Your log contains a strange error: /usr/bin/ld: cannot find /lib/ /usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4 collect2: error: ld returned 1 exit status Maybe the problem is on your build system? Do you have the package libusb-dev correctly installed? Bye Le 04/05/2016 à 18:16, Chris Lamb a écrit : Source: asedriveiiie Version: 3.7-5 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, asedriveiiie fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'asedriveiiie-build-deps' in '../asedriveiiie-build-deps_3.7-5_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package asedriveiiie-build-deps. (Reading database ... 23072 files and directories currently installed.) Preparing to unpack asedriveiiie-build-deps_3.7-5_all.deb ... Unpacking asedriveiiie-build-deps (3.7-5) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following additional packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config Suggested packages: pcscd The following NEW packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 229 kB of archives. After this operation, 717 kB of additional disk space will be used. Get:1 http://httpredir.debian.org/debian sid/main amd64 libusb-dev amd64 2:0.1.12-29 [36.9 kB] Get:2 http://httpredir.debian.org/debian sid/main amd64 libpcsclite1 amd64 1.8.16-1 [56.2 kB] Get:3 http://httpredir.debian.org/debian sid/main amd64 libpcsclite-dev amd64 1.8.16-1 [73.1 kB] Get:4 http://httpredir.debian.org/debian sid/main amd64 pkg-config amd64 0.29-4 [62.5 kB] Fetched 229 kB in 0s (19.4 MB/s) Selecting previously unselected package libusb-dev. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23076 files and directories currently installed.) Preparing to unpack .../libusb-dev_2%3a0.1.12-29_amd64.deb ... Unpacking libusb-dev (2:0.1.12-29) ... Selecting previously unselected package libpcsclite1:amd64. Preparing to unpack .../libpcsclite1_1.8.16-1_amd64.deb ... Unpacking libpcsclite1:amd64 (1.8.16-1) ... Selecting previously unselected package libpcsclite-dev. Preparing to unpack .../libpcsclite-dev_1.8.16-1_amd64.deb ... Unpacking libpcsclite-dev (1.8.16-1) ... Selecting previously unselected package pkg-config. Preparing to unpack .../pkg-config_0.29-4_amd64.deb ... Unpacking pkg-config (0.29-4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for libc-bin (2.22-7) ... Setting up libusb-dev (2:0.1.12-29) ... Setting up libpcsclite1:amd64 (1.8.16-1) ... Setting up libpcsclite-dev (1.8.16-1) ... Setting up pkg-config (0.29-4) ... Setting up asedriveiiie-build-deps (3.7-5) ... Processing triggers for libc-bin (2.22-7) ... dpkg-buildpackage -rfakeroot -D -us -uc -b dpkg-buildpackage: info: source package asedriveiiie dpkg-buildpackage: info: source version 3.7-5 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Ludovic Rousseau dpkg-source --before-build asedriveiiie-3.7 dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp touch asedriveiiie-usb/Makefile.inc /usr/bin/make -C asedriveiiie-usb clean make[1]: Entering directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' rm -f *~ *.o *.so || true make[1]: Leaving directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' touch asedriveiiie-serial/Makefile.inc /usr/bin/make -C asedriveiiie-serial cle
Bug#812087: [pcscd] takes 100 % cpu
Le 24/03/2016 18:56, Ludovic Rousseau a écrit : Le 15/03/2016 19:14, Ludovic Rousseau a écrit : Maybe enabling libusb debug would help. I will try to document how to do that easily. Philippe, Gustavo, Eric, can you do: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt generate the problem and send me the created log.txt file? Sorry, the correct command is: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT 2>&1 | tee log.txt libusb sends the debug messages to stderr and this was not redirected in log.txt :-( Eric, can you do it again ? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 15/03/2016 19:14, Ludovic Rousseau a écrit : Maybe enabling libusb debug would help. I will try to document how to do that easily. Philippe, Gustavo, Eric, can you do: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt generate the problem and send me the created log.txt file? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Hello,
For an unknown reason this email is not visible on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812087
Sending it again.
Le 15/03/2016 19:14, Ludovic Rousseau a écrit :
On Mon, 7 Mar 2016 21:14:48 +0100 Philippe Teuwen
wrote:
>
>
> On 03/07/2016 07:34 PM, Ludovic Rousseau wrote:
> > printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
>
> fds: 0 1
> always
>
> I also printed udev_dev from udev_monitor_receive_device()
> it's always null
>
> So we get fds[1].revents but don't get anything from
> udev_monitor_receive_device() so it's looping forever.
>
>
> You may try to trigger the bug from your side:
> It probably requires the same versions as me.
> kernel 4.3.0-1-amd64
> libusb-1.0-0 2:1.0.20-1
> libudev1 229-2
> I've a Yubikey neo-n plugged in.
> I start pcscd.
> I plug a usb hub (or anything else)
> => CPU at 100%
I am using:
$ uname -a
Linux debian 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64
GNU/Linux
$ apt-cache policy libusb-1.0-0
libusb-1.0-0:
Installé : 2:1.0.20-1
Candidat : 2:1.0.20-1
Table de version :
*** 2:1.0.20-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy libudev1
libudev1:
Installé : 229-2
Candidat : 229-2
Table de version :
*** 229-2 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy pcscd
pcscd:
Installé : 1.8.15-1
Candidat : 1.8.15-1
Table de version :
*** 1.8.15-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy libccid
libccid:
Installé : 1.4.22-1
Candidat : 1.4.22-1
Table de version :
*** 1.4.22-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
And I can't reproduce the problem :-(
I tried connecting a USB memory, my Android phone, a USB hub but it
all worked as expected.
That bug is even more strange now.
Maybe enabling libusb debug would help. I will try to document how to
do that easily.
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
On Mon, 7 Mar 2016 21:14:48 +0100 Philippe Teuwen wrote:
>
>
> On 03/07/2016 07:34 PM, Ludovic Rousseau wrote:
> > printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
>
> fds: 0 1
> always
>
> I also printed udev_dev from udev_monitor_receive_device()
> it's always null
>
> So we get fds[1].revents but don't get anything from
> udev_monitor_receive_device() so it's looping forever.
>
>
> You may try to trigger the bug from your side:
> It probably requires the same versions as me.
> kernel 4.3.0-1-amd64
> libusb-1.0-0 2:1.0.20-1
> libudev1 229-2
> I've a Yubikey neo-n plugged in.
> I start pcscd.
> I plug a usb hub (or anything else)
> => CPU at 100%
I am using:
$ uname -a
Linux debian 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64
GNU/Linux
$ apt-cache policy libusb-1.0-0
libusb-1.0-0:
Installé : 2:1.0.20-1
Candidat : 2:1.0.20-1
Table de version :
*** 2:1.0.20-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libudev1
libudev1:
Installé : 229-2
Candidat : 229-2
Table de version :
*** 229-2 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy pcscd
pcscd:
Installé : 1.8.15-1
Candidat : 1.8.15-1
Table de version :
*** 1.8.15-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libccid
libccid:
Installé : 1.4.22-1
Candidat : 1.4.22-1
Table de version :
*** 1.4.22-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
And I can't reproduce the problem :-(
I tried connecting a USB memory, my Android phone, a USB hub but it all
worked as expected.
That bug is even more strange now.
Maybe enabling libusb debug would help. I will try to document how to do
that easily.
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
Le 07/03/2016 10:21, Philippe Teuwen a écrit :
I recompiled libusb with debug symbols:
Normal CPU:
Thread 5 (Thread 0x7f0238fcb700 (LWP 24364)):
#0 0x7f02394dfb6d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x7f0238fdbafc in poll (__timeout=-1, __nfds=2,
__fds=0x7f0238fcaee0)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:175
#3 0x7f02397ab284 in start_thread (arg=0x7f0238fcb700)
at pthread_create.c:333
#4 0x7f02394e8a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
100% CPU:
Thread 5 (Thread 0x7fbeac2a4700 (LWP 24181)):
#0 0x7fbeaca8cbdd in recvmsg () at ../sysdeps/unix/syscall-template.S:81
#1 0x7fbead2806ec in udev_monitor_receive_device ()
from /lib/x86_64-linux-gnu/libudev.so.1
#2 0x7fbeac2b4b8b in linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:186
#3 0x7fbeaca84284 in start_thread (arg=0x7fbeac2a4700)
at pthread_create.c:333
#4 0x7fbeac7c1a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
So the diff happens in that code from libusb/os/linux_udev.c:
usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
if (fds[0].revents & POLLIN) {
r = usbi_read(udev_control_pipe[0], &dummy, sizeof(dummy));
if (r <= 0) {
usbi_warn(NULL, "udev control pipe read failed");
}
break;
}
if (fds[1].revents & POLLIN) {
usbi_mutex_static_lock(&linux_hotplug_lock);
udev_dev = udev_monitor_receive_device(udev_monitor);
if (udev_dev)
udev_hotplug_event(udev_dev);
usbi_mutex_static_unlock(&linux_hotplug_lock);
}
}
usbi_dbg("udev event thread exiting");
I added error msgs in the loop.
When 100% CPU, the poll() is non-blocking and the loop becomes a busy loop.
Great.
I reported the problem on the libusb mailing list
https://sourceforge.net/p/libusb/mailman/message/34914342/
Do you know a sequence of manipulations that triggers the bug?
I would like to reproduce the bug on my side.
Can you change the code of libusb to display the values fds[0].revents and
fds[1].revents
Something like:
--- /tmp/XP5vZa_linux_udev.c2016-03-07 19:32:06.353701710 +0100
+++ libusb/os/linux_udev.c 2016-03-07 19:31:56.613374793 +0100
@@ -173,6 +173,7 @@ static void *linux_udev_event_thread_mai
usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
+ printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
if (fds[0].revents & POLLIN) {
/* activity on control pipe, read the byte and exit */
r = usbi_read(udev_control_pipe[0], &dummy, sizeof(dummy));
What is the result when the problem occurs?
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
On Sun, 6 Mar 2016 23:10:07 +0100 Philippe Teuwen wrote:
Mmm activating libudev debug didn't bring much I think.
I attached one log with LIBUSB_DEBUG=99 and one with recompiled pcscd
with udev debug support.
For both I just ran pcscd with the yubikey plugged in then plugged a USB
hub that triggered the CPU to 100%
libccid1.4.22-1
libusb-1.0-0 2:1.0.20-1
udev 228-6
I'll see if I can get more from gdb...
Cheers
Phil
Thanks Philippe for the libudev trace.
hotplug_libudev.c contains an infinite for() loop.
But for each loop execution a line is logged:
0022 hotplug_libudev.c:619:HPEstablishUSBNotifications()
Since you do not get a infinite of these logs I guess the infinite loop occurs
inside a function called in the for() loop.
I have an idea. Can you test with the proposed patch:
--- /var/folders/sg/t7kts8_n6j13n11r6_tgr36rgn/T//3ql5ya_hotplug_libudev.c
2016-03-07 00:38:32.0 +0100
+++ src/hotplug_libudev.c 2016-03-07 00:38:08.0 +0100
@@ -621,7 +621,7 @@ static void HPEstablishUSBNotifications(
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
/* wait for a udev event */
- r = TEMP_FAILURE_RETRY(poll(&pfd, 1, -1));
+ r = poll(&pfd, 1, -1);
if (r < 0)
{
Log2(PCSC_LOG_ERROR, "select(): %s", strerror(errno));
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
On Thu, 3 Mar 2016 09:30:36 +0100 Philippe Teuwen wrote: Hi Ludovic, Hello Philippe, I'm getting the same problem with my Debian Testing. I'll try to generate more logs related to libusb as explained in the bug thread but here are some things I noticed: I also suspect a bug in libudev, not just libusb. Can you rebuild pcscd as explained in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812087#75 to enable libudev logs? I've a Yubikey Neo-n plugged constantly. When the 100% problem arises, nothing special in pcscd logs, even with -f -a -d cf attached log. And pcscd and Yubikey remain fully functional despite the 100%. Now the interesting bits: Without the yubikey inserted the problem never occurs. With the yubikey inserted there are two cases: 1) works as normal, the problem never arises 2) sometimes when yubikey gets inserted or when pcscd service is restarted I get the following error in syslog: pcscd[26168]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed pcscd[26168]: 0012 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:1050/0115:libudev:0:/dev/bus/usb/001/025) pcscd[26168]: 0002 readerfactory.c:372:RFAddReader() Yubico Yubikey NEO U2F+CCID init failed. What version of libccid do you use? What was the pcscd log line just before CreateChannelByNameOrChannel() failed? At this point besides those lines in syslog, yubikey is functional and CPU is ok *but* starting from this situation, whenever there will be a change on another usb port, no matter what (inserting or removing anything, even a simple USB hub) => CPU goes to 100% Restarting pcscd brings CPU back to normal till another USB insert/remove event. That is really interesting. You can reproduce the problem even after a complete restart of pcscd. So the problem may not be in libusb or pcscd but in libudev or another "system" component used by pcscd. Another idea is to attach a debugger to pcscd and get a backtrace of all the threads when the CPU goes 100%. That could help identify the function or library causing the issue. Thanks -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Hello, I got no news from my latest email. Do you still have the 100% CPU load for pcscd? Can you help me fix the problem? Thanks Le 25/01/2016 17:33, Ludovic Rousseau a écrit : Hello Alexander and Eric, Le 25/01/2016 01:13, Alexander Mikhailian a écrit : Package: pcscd Version: 1.8.15-1 Followup-For: Bug #812087 Dear Maintainer, I have the same problem with pcscd, and I did not even have to insert a USB mass storage device, when I plug my notebook into the dock station, fans go off like mad and pcscd takes on CPU cycles. This bug is quiet strange. Alexander, have you tried to generate libusb debug using: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa You may have to downgrade libusb-1.0-0 to version 1.0.19 from stable. Another idea is to rebuild pcscd with hotplug debug enabled. No need to install pcscd so you can't break your installation. 1. Get the source code of pcsc-lite, for example from https://alioth.debian.org/frs/?group_id=30105&release_id=2019#pcsclite-_1.8.15-title-content 2. install the build dependencies using: $ sudo apt-get build-dep pcscd 3. edit the file PCSC/src/hotplug_libudev.c and change the line 66 from #undef DEBUG_HOTPLUG to #define DEBUG_HOTPLUG 4. configure pcsc-lite using "./configure" 5. run pcscd using: $ sudo ./src/pcscd -dfa 6. try to reproduce the 100% CPU consumption problem This may generate a lot of logs if the problem is with libudev. Bye -- Dr. Ludovic Rousseau
Bug#814805: marked as pending
tag 814805 pending thanks Hello, Bug #814805 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=python-modules/packages/pyscard.git;a=commitdiff;h=35dfaae --- commit 35dfaae1a20cad7e0de353207769d0091f12b782 Author: Ludovic Rousseau Date: Sat Feb 20 18:03:20 2016 +0100 Add back suport of Python 2 We now support all Python 2 version (only python2.7 in sid) and all version of Python 3 (Python 3.4 and Python 3.5 in sid now). diff --git a/debian/changelog b/debian/changelog index 766adfe..eb56015 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +pyscard (1.9.2-2) unstable; urgency=medium + + * Provide a version for Python 2 and Python 3 versions + * Fix "Dropped python-pyscard without explanation" build python-pyscard for +Python 2 again (Closes: #814805) + * debian/python-pyscard.examples: examples for python-pyscard + + -- Ludovic Rousseau Fri, 19 Feb 2016 22:02:16 +0100 + pyscard (1.9.2-1) unstable; urgency=medium * New upstream release
Bug#814805: pyscard: Dropped python-pyscard without explanation
On Mon, 15 Feb 2016 16:12:00 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= wrote: Source: pyscard Version: 1.9.2-1 Severity: serious User: de...@kali.org Usertags: origin-kali This version of pyscard dropped the Python 2 version without any explanation on why this was needed. In the process, you made yubioath-desktop uninstallable (as well as another package which is only available in Kali). The move to Python 3 was not really needed. But since the upstream code is now working with Python 3 it was a good idea to provide python3-pyscard. Please restore the Python 2 version of the module. OK. I will try to work on it. A patch for https://anonscm.debian.org/cgit/python-modules/packages/pyscard.git/ would greatly help. Thanks -- Dr. Ludovic Rousseau
Bug#814594: yubioauth-desktop depends on cruft package python-pyscard.
On Sat, 13 Feb 2016 14:02:23 + Peter Green wrote: Package: yubioauth-desktop Severity: serious x-debbugs-cc: pysc...@packages.debian.org yubioauth-desktop depends on python-pyscard which is no longer built by pyscard. pyscard dropped the binary package in it's most recent upload with no explanation given in the changelog. The PyScard wrapper moved to Python 3. I forget to make it explicit in the debian/changelog. The package is now called python3-pyscard https://packages.debian.org/sid/python3-pyscard yubioath-desktop should be moved to Python 3 as well. Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Hello Alexander and Eric, Le 25/01/2016 01:13, Alexander Mikhailian a écrit : Package: pcscd Version: 1.8.15-1 Followup-For: Bug #812087 Dear Maintainer, I have the same problem with pcscd, and I did not even have to insert a USB mass storage device, when I plug my notebook into the dock station, fans go off like mad and pcscd takes on CPU cycles. This bug is quiet strange. Alexander, have you tried to generate libusb debug using: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa You may have to downgrade libusb-1.0-0 to version 1.0.19 from stable. Another idea is to rebuild pcscd with hotplug debug enabled. No need to install pcscd so you can't break your installation. 1. Get the source code of pcsc-lite, for example from https://alioth.debian.org/frs/?group_id=30105&release_id=2019#pcsclite-_1.8.15-title-content 2. install the build dependencies using: $ sudo apt-get build-dep pcscd 3. edit the file PCSC/src/hotplug_libudev.c and change the line 66 from #undef DEBUG_HOTPLUG to #define DEBUG_HOTPLUG 4. configure pcsc-lite using "./configure" 5. run pcscd using: $ sudo ./src/pcscd -dfa 6. try to reproduce the 100% CPU consumption problem This may generate a lot of logs if the problem is with libudev. Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 16:05, eric2.vale...@orange.com a écrit : On 01/22/2016 03:52 PM, Ludovic Rousseau wrote: Le 22/01/2016 15:18, eric2.vale...@orange.com a écrit : On 01/22/2016 03:06 PM, Ludovic Rousseau wrote: Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit : On 01/20/2016 03:07 PM, Ludovic Rousseau wrote: It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks Here is the requested log file. Note that I'm not sure the trace will help: 1) As soon as I launch it, I have continuous traces but process does not even appaers in the top first twenty line, You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC for card status. That is a very bad PC/SC behaviour. You should try to identify the bogus application and fix it. I guess I have installed a binary blob packages given my a key manufacturer :-( SACSrv il you kinow wht it is... Will kill it and retry You can identify a process using PC/SC using: $ sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 [sudo] password for ceva6380: /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0: 14662m 19 r-x-ceva6380:~->ps ax | grep 14662 14662 ?Sl11:53 /usr/bin/iceweasel 22156 pts/5S+ 0:00 grep 14662 Quite strange!!! Not really. You (or an installation script) has configured a PKCS#11 token in iceveasel. See https://github.com/OpenSC/OpenSC/wiki/Installing-OpenSC-PKCS%2311-Module-in-Firefox,-Step-by-Step Maybe a problem in libusb. What version of libusb are you using? dpkg -l libusb* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-=- ii libusb-0.1-4:amd642:0.1.12-28 amd64 userspace USB programming library ii libusb-1.0-0:amd642:1.0.20-1 amd64 userspace USB programming library ii libusb-1.0-0-dev:amd642:1.0.20-1 amd64 userspace USB programming library development files ii libusb-1.0-doc2:1.0.20-1 all documentation for userspace USB programming ii libusb-dev2:0.1.12-28 amd64 userspace USB programming library development files ii libusbmuxd-dev:amd64 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - devel ii libusbmuxd-tools 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - tools ii libusbmuxd4:amd64 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - library 2 r-x-ceva6380:~->su Run pcscd as: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa Bye attached log : no specific usb trace while pcscd is at 100% cpu. Strange. I also have the Debian package for libusb (1.0.19 from stable) and I get libusb logs. Can you downgrade libusb to version 1.0.19 and test again? bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 15:18, eric2.vale...@orange.com a écrit : On 01/22/2016 03:06 PM, Ludovic Rousseau wrote: Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit : On 01/20/2016 03:07 PM, Ludovic Rousseau wrote: It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks Here is the requested log file. Note that I'm not sure the trace will help: 1) As soon as I launch it, I have continuous traces but process does not even appaers in the top first twenty line, You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC for card status. That is a very bad PC/SC behaviour. You should try to identify the bogus application and fix it. I guess I have installed a binary blob packages given my a key manufacturer :-( SACSrv il you kinow wht it is... Will kill it and retry You can identify a process using PC/SC using: $ sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 Maybe a problem in libusb. What version of libusb are you using? Run pcscd as: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit :
On 01/20/2016 03:07 PM, Ludovic Rousseau wrote:
It does not look like the problem is the Broadcom reader.
Can you generate a log as documented in
https://pcsclite.alioth.debian.org/pcsclite.html#support ?
Start the log and then connect your problematic mass-storage USB key.
Thanks
Here is the requested log file. Note that I'm not sure the trace will help:
1) As soon as I launch it, I have continuous traces but process does not
even appaers in the top first twenty line,
You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC
for card status. That is a very bad PC/SC behaviour.
You should try to identify the bogus application and fix it.
2) As soon as I plug the USB key, it reaches 100% CPU and top first place
but do not show anything diffrent in the log.
will try a strace...
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
Maybe a problem in libusb.
Do you have kernel errors in dmesg output?
What is the output of "lsusb -v" with the USB key plugged in?
Bye
--
Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 20/01/2016 14:02, eric2.vale...@orange.com a écrit : Note that in the laptop there is a build in broadcom credit card format crypto key reader (that you see in the log), but I do not use it although for testing purpose I have enabled the driver. But the bug is only if I insert a USB key. daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: 0032 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: 0004 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: 0027 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: 0005 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: 0026 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: 0004 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Main process exited, code=killed, status=9/KILL daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Unit entered failed state. daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Failed with result 'signal'. < killed it by kill -9 to get CPU back daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: 0022 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: 0003 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 20/01/2016 13:03, Eric Valette a écrit : Package: pcscd Version: 1.8.15-1 Severity: critical Justification: breaks unrelated software Twice in two days, I noticed my laptop fan was going carsy allthough I was only doing many mail activity. Twice I found that pcscd was eating a complete CPU and remembered that each time I had inserted a regular mass storage USB key (two different keys) not my crypto key. - top - 12:56:25 up 3:14, 5 users, load average: 2.03, 1.56, 1.31 Tasks: 242 total, 2 running, 239 sleeping, 0 stopped, 1 zombie %Cpu(s): 34.1 us, 21.1 sy, 0.0 ni, 44.8 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 8219052 total, 3472188 free, 2336828 used, 2410036 buff/cache KiB Swap: 16383996 total, 16383996 free,0 used. 5812264 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1687 root 20 0 394560 2916 2120 S 100.3 0.0 147:37.75 pcscd 14477 ceva6380 20 0 424288 57364 37792 R 99.7 0.7 2:59.83 konsole 2921 ceva6380 20 0 1410776 448992 87860 S 15.9 5.5 6:48.46 icedove 4463 ceva6380 20 0 1435116 363080 97112 S 1.7 4.4 4:12.69 iceweasel Do you have some pcscd related logs in /var/log/* ? Bye -- Dr. Ludovic Rousseau
Bug#784256: usemod-wiki: Undefined subroutine CGI::startform
2015-05-14 21:13 GMT+02:00 Christoph Berg : > Re: Ludovic Rousseau 2015-05-04 > <20150504153158.27553.98664.report...@linutop.apdu.fr> >> I upgraded my system to Jessie (Debian 8.0) and now my wiki is no more >> working :-( >> >> I get this error as an HTML page: >> « Software error: >> >> Undefined subroutine CGI::startform >> at /usr/lib/cgi-bin/wiki.pl line 1503. > > Hi Ludovic, > > I've just fixed this for unstable, thanks for the report! > > For jessie, the problem is only there when you have libcgi-pm-perl > installed. If you remove that, the CGI.pm version bundled with perl > works. Is that workaround good enough, or should we look into > preparing a package for proposed-updates? Hello Christoph, In my setup libcgi-pm-perl is installed because it is a dependency of smokeping. So I can't really remove this package. The popularity of usemod-wiki [1] is quiet low. But the popularity of libcgi-pm-perl [2] is high. Maybe it is a good idea to prepare a package for proposed-updates if it is not too much work for you. Regards, [1] https://qa.debian.org/popcon.php?package=usemod-wiki [2] https://qa.debian.org/popcon.php?package=libcgi-pm-perl -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784256: usemod-wiki: Undefined subroutine CGI::startform
Package: usemod-wiki
Version: 1.0.5-3
Severity: grave
Tags: upstream patch
Justification: renders package unusable
Dear Maintainer,
I upgraded my system to Jessie (Debian 8.0) and now my wiki is no more
working :-(
I get this error as an HTML page:
« Software error:
Undefined subroutine CGI::startform
at /usr/lib/cgi-bin/wiki.pl line 1503.
For help, please send mail to the webmaster (webmaster@localhost), giving this
error message and the time and date of the error. »
Line 1503 of /usr/lib/cgi-bin/wiki.pl is:
sub GetFormStart {
return $q->startform("POST", "$ScriptName",
"application/x-www-form-urlencoded");
}
The problem is similar to #767960 and is very easy to fix.
I hope the problem will be fixed in the next update of stable.
Proposed patch:
--- wiki.pl 2015-05-04 15:29:26.0 +0200
+++ /usr/lib/cgi-bin/wiki.pl2015-05-04 15:43:16.781540995 +0200
@@ -1471,7 +1471,7 @@
$result .= '' . T('Config file error:') . ' '
. $ConfigError . '';
}
- $result .= $q->endform;
+ $result .= $q->end_form;
if ($FooterNote ne '') {
$result .= T($FooterNote);
}
@@ -1500,7 +1500,7 @@
}
sub GetFormStart {
- return $q->startform("POST", "$ScriptName",
+ return $q->start_form("POST", "$ScriptName",
"application/x-www-form-urlencoded");
}
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages usemod-wiki depends on:
ii apache2 [httpd] 2.4.10-10
ii apache2-mpm-prefork [httpd] 2.4.10-10
ii perl 5.20.2-3
Versions of packages usemod-wiki recommends:
ii apache2 [httpd] 2.4.10-10
ii apache2-mpm-prefork [httpd] 2.4.10-10
Versions of packages usemod-wiki suggests:
ii exim4-daemon-light [mail-transport-agent] 4.84-8
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752352: syncbbdb: uninstallable: libpda-pilot-perl is gone
Le 22/06/2014 22:31, Niko Tyni a écrit : Package: syncbbdb Version: 2.6-2 Severity: grave Tags: sid X-Debbugs-Cc: pilot-l...@packages.debian.org The syncbbdb and pilot-manager packages are no longer installable on current sid: The following packages have unmet dependencies: syncbbdb : Depends: pilot-manager (>= 1.107-3) but it is not going to be installed Depends: pilot-link-perl but it is not installable or libpda-pilot-perl but it is not installable Recommends: bbdb pilot-manager : Depends: pilot-link-perl but it is not installable or libpda-pilot-perl but it is not installable Recommends: pilot-link but it is not going to be installed This is because pilot-link recently dropped the libpda-pilot-perl package: Changes: pilot-link (0.12.5-dfsg-1) unstable; urgency=medium . [...] * remove libpda-pilot-perl package as it does not build anymore Cc'ing the pilot-link maintainer. I don't see a bug about the build issue, but I suppose the debian-perl list could try to help if you like. After discussion with the syncbbdb maintainer in bug #751244 I decided to NOT provide libpda-pilot-perl any more. The idea is to remove syncbbdb from Debian. The popcon score [1] of syncbbdb is very low. pilot-link is no more maintained upstream. Barak, maybe you should file a bug against ftp.debian.org requesting the removal of syncbbdb (your package). Bye [1] http://qa.debian.org/popcon.php?package=syncbbdb -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749280: [jpilot] segmentation fault
Le 25/05/2014 23:14, Marco Righi a écrit : Package: jpilot Version: 1.8.1.2-4 Severity: grave --- Please enter the report below this line. --- Hi, Hello, after a apt-get upgrate, if I try to execute jpilot I got a segmentation fault. Follow the exact error in Italian: Command 505 of 7 $jpilot Errore di segmentazione Please write me if you need more information. I would need a debugger backtrace. Just do in a terminal: $ gdb jpilot $ run wait for the crash $ backtrace Then send me the output. Regards, -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720277: [pcscd]
severity 720277 normal retitle 720277 infinite loop in the installation of pcscd thank Le 21/08/13 00:30, Marco Righi a écrit : What happened if you tried to remove the pcscd package _without_ this trick? Still blocked on the same message? Yes Bad luck. It will be hard to fix if you do not have the problem any more. I remember that to reproduce ths bug I executed synaptic, I search packages using pcsd keyword and I installed all packages. I can't reproduce the problem. I have no idea of the source of the problem. I keep this bug open in case someone else also have the same problem. Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720277: [pcscd]
Le 20/08/13 23:49, Marco Righi a écrit : Il 20/08/2013 18:45, Ludovic Rousseau ha scritto: Le 20/08/13 04:03, Marco Righi a écrit : Package: pcscd Version: 1.8.8-4 Severity: critical --- Please enter the report below this line. --- After the installation of pcscd I have an infine loop on [] Restarting PCSC Lite resource manager: pcscd What exactly do you call an infinite loop? The message loops endlessly? The screen was locked on the message [] Restarting PCSC Lite resource manager: pcscd Even Ctrl-c does not stop the task, I have to use "killall" The command do not return but do not print anything else? The dpkg configuration did not return... it remained freezed on [] Restarting PCSC Lite resource manager: pcscd What have you done to stop the "infinite loop"? killall apt-get or dpkg (I have try to configure the package using various methods). To uninstall the package I used a trick, cp /etc/init.d/apache2 /etc/inid.d/pcscd What happened if you tried to remove the pcscd package _without_ this trick? Still blocked on the same message? so that the process returned and apt-get removed successfully the package pcscd. Can you reproduce the problem? no, sorry. After the test I have just described you, I tried the command apt-get install pcscd libpcsclite1 pcsc-tools libccid and it finished without errors! Bad luck. It will be hard to fix if you do not have the problem any more. It is a strange case. Please ask me. I would like you to resolve this bug. It may be related to systemd. It looks like you do not have systemd installed. Do you confirm? Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720277: [pcscd]
Le 20/08/13 04:03, Marco Righi a écrit : Package: pcscd Version: 1.8.8-4 Severity: critical --- Please enter the report below this line. --- After the installation of pcscd I have an infine loop on [] Restarting PCSC Lite resource manager: pcscd What exactly do you call an infinite loop? The message loops endlessly? The command do not return but do not print anything else? What have you done to stop the "infinite loop"? Can you reproduce the problem? Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718473: pcscd: 100% CPU usage
Le 02/08/13 11:39, Eugen Dedu a écrit : On 02/08/13 11:20, Ludovic Rousseau wrote: Le 02/08/13 11:03, Eugen Dedu a écrit : On 02/08/13 10:56, Ludovic Rousseau wrote: Can you: 1. run pcscd inside gdb I have a problem here: (gdb) run Starting program: /usr/sbin/pcscd 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". [Inferior 1 (process 7795) exited normally] (gdb) It looks like a known problem :-( http://sourceware.org/bugzilla/show_bug.cgi?id=13097 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711913 Note also the following output generated a few days ago: I see a seg fault at exit but no infinite loop in the log. That is not the same bug. Can you reproduce the 100% CPU problem using "pcscd -d -f" now? Ok, I see. Right after a suspend/resume, pcscd goes to 100% CPU. So this is related to suspend/resume. The output generated after the suspend/resume is: 12796601 hotplug_libudev.c:587:HPEstablishUSBNotifications() Device removed 8392 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0001, path: /dev/bus/usb/003/001 00019374 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0001, path: /dev/bus/usb/003/001 [...] 0802 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 0529 hotplug_libudev.c:587:HPEstablishUSBNotifications() Device removed 4667 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0001, path: /dev/bus/usb/003/001 [..] 9838 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 9786 hotplug_libudev.c:587:HPEstablishUSBNotifications() Device removed 2195 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0001, path: /dev/bus/usb/003/001 [...] 1705 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 0460 hotplug_libudev.c:587:HPEstablishUSBNotifications() Device removed 00015193 hotplug_libudev.c:260:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0001, path: /dev/bus/usb/003/001 [similar lines] Thanks. It may be a libudev bug. Or a wrong way pcscd uses it. I do not have a laptop to test suspend/resume. So it may be a bit complex to debug. You can install systemd so that pcscd is started only when needed. So if you do not use pcscd at the suspend time you will not have the problem. Note that the segmentation fault appears after pressing ctrl-c. I would need a gdb backtrace to debug that. BYe -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718473: pcscd: 100% CPU usage
Le 02/08/13 11:03, Eugen Dedu a écrit : On 02/08/13 10:56, Ludovic Rousseau wrote: Can you: 1. run pcscd inside gdb I have a problem here: (gdb) run Starting program: /usr/sbin/pcscd 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". [Inferior 1 (process 7795) exited normally] (gdb) It looks like a known problem :-( http://sourceware.org/bugzilla/show_bug.cgi?id=13097 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711913 Note also the following output generated a few days ago: I see a seg fault at exit but no infinite loop in the log. That is not the same bug. Can you reproduce the 100% CPU problem using "pcscd -d -f" now? Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718473: pcscd: 100% CPU usage
Le 01/08/13 07:39, Eugen Dedu a écrit : Subject: pcscd: 100% CPU usage Package: pcscd Version: 1.8.8-3 Severity: grave Dear Maintainer, Hello, Since a few weeks, pcscd has been using 100% CPU, as shown by 'top': PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2132 root 20 0 312348 5972984 S 99.7 0.1 60:19.06 pcscd 3553 ededu 20 0 1059924 196788 47844 S 2.0 4.9 3:21.04 iceweasel I put this bug as grave because it affects the machine as a whole, feel free to change it to suit your needs. I will need more debug information. Can you: 1. run pcscd inside gdb 2. stop pcscd using Ctrl-C while in the 100% CPU loop 3. use the "bt" gdb command to generate a backtrace 4. send the result 5. kill any running pcscd 6. run in a terminal "sudo pcscd -dfa" 7. send me the result Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707756: pcscd: failed upgrade squeeze -> wheezy
severity707756normal fixed 7077561.8.8-1 thank Le 11/05/13 01:26, Holger Burkhardt a écrit : It would be nice to have a fix in the package for the next point release (7.0.1) Since the bug do not happen with a normal upgrade from squeeze to wheezy I don't know yet if I will submit a new version for the next point release. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707756: pcscd: failed upgrade squeeze -> wheezy
Le 11/05/13 01:26, Holger Burkhardt a écrit :
Package: pcscd
Version: 1.8.4-1
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
Hello,
* What led up to the situation?
Upgrade squeeze -> wheezy failed due to the postinstall-script exiting with
error code 1. Exact error code was:
"dpkg: Fehler beim Bearbeiten von pcscd (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1
zurück"
A debug session on irc showed the following problems of the post-install-
scirpt:
a) The pcscd-group was already existing on my computer due to the previous
install. However, it was not a system group at that time. Making the output of
the postinstall-script more verbose, one could see that the script breaks at
that point: ("addgroup: Die Gruppe »pcscd« existiert bereits und ist keine
Systemgruppe. Programmende.").
-> Proposed patch from the IRC-experts: Replace the line
"addgroup --system pcscd --quiet"
by
"if ! getent group pcscd > /dev/null 2>&1 ; then addgroup --system pcscd
--quiet; fi"
The use of the pcscd group was added with pcsc-lite 1.6.0 and removed with
pcsc-lite 1.8.0.
Debian old-stable (squeeze) provided pcsc-lite 1.5.5-4
Debian stable (wheezy) provides pcsc-lite 1.8.4-1
You had a problem with the upgrade because you created the pcscd group
yourself. I guess you installed some pcsc-lite version by hand. Exact?
I upgrade pcscd from old-stable to stable without problem here:
[...]
Preparing to replace pcscd 1.5.5-4 (using .../pcscd_1.8.4-1_i386.deb) ...
Unpacking replacement pcscd ...
[...]
Setting up pcscd (1.8.4-1) ...
Installing new version of config file /etc/init.d/pcscd ...
[...]
I already removed the use of addgroup in pcsc-lite 1.8.8-1 (I should have done that for
version 1.8.0-1 but "forgot").
b) the follwoing line seems also to be problematic and the following
replacement was proposed:
Instead of
[ -x /bin/systemctl ] && [ -d /sys/fs/cgroup/systemd ] && systemctl enable
pcscd.socket
rather
if [ -x /bin/systemctl -a -d /sys/fs/cgroup/systemd ]; then systemctl enable
pcscd.socket; fi
Can you explain what the problem is with the previous version?
Thanks
--
Dr. Ludovic Rousseau
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678080: AttributeError: 'module' object has no attribute 'uses_fragment'
Le 19/06/12 03:39, jida...@jidanni.org a écrit :
Package: plucker
Version: 1.8-33+b2
Severity: grave
Upon update of python we now get
Traceback (most recent call last):
File "/usr/bin/plucker-build", line 39, in
from PyPlucker import Parser, ConfigFiles, __version__
File "/usr/lib/python2.7/dist-packages/PyPlucker/Parser.py", line 12, in
from PyPlucker import TextParser, ImageParser, PluckerDocs,
ConversionParser
File "/usr/lib/python2.7/dist-packages/PyPlucker/TextParser.py", line 66, in
from PyPlucker import Url
File "/usr/lib/python2.7/dist-packages/PyPlucker/Url.py", line 22, in
urlparse.uses_fragment.append ('plucker')
AttributeError: 'module' object has no attribute 'uses_fragment'
I can't reproduce the problem.
You do not give the Python version or anything else so I can reproduce
the problem.
You make me lose my time with those bug reports :-(
--
Dr. Ludovic Rousseau
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667840: pam-pkcs11: FTBFS: -Werror=format-security
Le 07/04/12 00:30, Christoph Egger a écrit : Package: src:pam-pkcs11 Version: 0.6.7-2 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on all the buildds: pam_pkcs11.c:295:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:325:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:340:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:360:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:376:9: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:398:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:411:7: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:427:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:438:7: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:446:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:459:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:468:2: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:486:5: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:507:5: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:517:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:537:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:550:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:566:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:590:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:624:5: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:641:5: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:663:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:673:3: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:694:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:709:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:729:4: error: format not a string literal and no format arguments [-Werror=format-security] pam_pkcs11.c:811:4: error: format not a string literal and no format arguments [-Werror=format-security] Full build log at https://buildd.debian.org/status/fetch.php?pkg=pam-pkcs11&arch=kfreebsd-amd64&ver=0.6.7-2&stamp=1333749276 Exact. The build fails in pbuilder but not in my sid chroot. Strange. I will try to fix the bugs upstream and make a new upstream release. Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666661: pcsc-cyberjack: FTBFS: winscard.h:20:22: fatal error: pcsclite.h: No such file or directory
Le 04/04/12 21:37, Lucas Nussbaum a écrit : On 01/04/12 at 09:07 +0200, Frank Neuber wrote: Hi, in the build log I found: checking if PC/SC should be used... yes checking for pcsc includes... -I/usr/include -I/usr/include/PCSC configure: WARNING: No pcsc libraries found, SCard driver will not be available. This is why pcsclite.h is not found. I wonder why /usr/include/PCSC/winscard.h is available. The pcsclite.h file is in the same package! sct@u110432b:~$ dpkg -S winscard.hlibpcsclite-dev libpcsclite-dev: /usr/include/PCSC/winscard.h sct@u110432b:~$ dpkg -S pcsclite.h libpcsclite-dev: /usr/include/PCSC/pcsclite.h Could it be a problem with the libpcsclite-dev on the build system. I don't know how the build system works. On my system it builds well. I just tried, and could reproduce the failure (see attachment). Could you post a diff between your build log (inside sbuild or pbuilder) and mine? The build should fail if you use libpcsclite-dev version 1.8.3-1 or above. This version is in unstable since Fri, 30 Mar 2012. The problem is explained at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61#15 The build failure error message is very misleading. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666661: pcsc-cyberjack: FTBFS: winscard.h:20:22: fatal error: pcsclite.h: No such file or directory
Le 01/04/12 09:07, Frank Neuber a écrit :
Hi,
Hello,
in the build log I found:
checking if PC/SC should be used... yes
checking for pcsc includes... -I/usr/include -I/usr/include/PCSC
configure: WARNING: No pcsc libraries found, SCard driver will not be available.
This is why pcsclite.h is not found.
I wonder why /usr/include/PCSC/winscard.h is available. The pcsclite.h file is
in the same package!
sct@u110432b:~$ dpkg -S winscard.hlibpcsclite-dev
libpcsclite-dev: /usr/include/PCSC/winscard.h
sct@u110432b:~$ dpkg -S pcsclite.h
libpcsclite-dev: /usr/include/PCSC/pcsclite.h
Could it be a problem with the libpcsclite-dev on the build system.
I don't know how the build system works. On my system it builds well.
The problem is that libpcsclite1 is now a multi arch library.
So the lib libpcsclite.so is no more in /usr/lib/libpcsclite.so but in
/usr/lib/x86_64-linux-gnu/libpcsclite.so on AMD64 systems.
The configure script of pcsc-cyberjack searches the library using a
fixed list of directories. From m4/pcsc.m4 line 68:
AC_ARG_WITH(pcsc-libs, [ --with-pcsc-libs=DIR adds pcsc library
path],
[pcsc_search_lib_dirs="$withval"],
[pcsc_search_lib_dirs="/usr/lib64 \
/usr/lib \
/usr/local/lib \
/usr/lib/pcsc/lib \
/usr/local/pcsc/lib \
/lib"])
dnl search for pcsc libs
for d in $pcsc_search_lib_dirs; do
AQ_SEARCH_FILES("$d",$pcsc_search_lib_names)
if test -n "$found_file" ; then
pcsc_libraries="-L$d"
pcsc_lib="-l`echo $found_file | sed 's/lib//;s/\.so*//;s/\.a//'`"
break
fi
done
As you can see /usr/lib/x86_64-linux-gnu is not in the list.
A (too) simple patch is:
--- ../pcsc.m4 2012-04-01 12:18:38.0 +0200
+++ m4/pcsc.m4 2012-04-01 12:27:48.0 +0200
@@ -68,6 +68,7 @@
AC_ARG_WITH(pcsc-libs, [ --with-pcsc-libs=DIR adds pcsc library
path],
[pcsc_search_lib_dirs="$withval"],
[pcsc_search_lib_dirs="/usr/lib64 \
+ /usr/lib/x86_64-linux-gnu \
/usr/lib \
/usr/local/lib \
/usr/lib/pcsc/lib \
But build will fail on all the other Debian architectures.
The problem should be solved upstream. Using a fixed list of library
directories is a bad idea. The correct solution is to _link_ with
libpcsclite to know if the library is found by the linker.
Or in debian/rules use something like (untested):
--with-pcsc-libs=/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
Bye
--
Dr. Ludovic Rousseau
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664630: libpcsclite1
severity 664630 normal thank Le 19/03/12 15:13, Hendricus Kabouter a écrit : Package: libpcsclite1 Subject: libpcsclite1 Version: 1.8.2-1 Justification: renders package unusable Severity: grave -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages libpcsclite1 depends on: ii libc6 2.13-27 libpcsclite1 recommends no packages. Versions of packages libpcsclite1 suggests: ii pcscd 1.8.2-1 -- no debconf information libpcsclite1 (1.8.2-1) for AMD64 and libccid (1.8.2-1) for AMD64 prevent the Reiner-SCT-RFID-Komfort-Cardreader (Germany) from working. It is necessary to install the previous versions (1.5.5-4), but any upgrade of Wheezy again installs the unworkable versions 1.8.2-1. Hello, I guess the Reiner-SCT-RFID-Komfort-Cardreader driver is not available from Debian as a package. Exact? Have you reported the problem to the Reiner-SCT-RFID-Komfort-Cardreader maintainer? Please (re)install libpcsclite1 (1.8.2-1) and libccid (1.8.2-1). Then generate and send me logs as described in http://pcsclite.alioth.debian.org/pcsclite.html#support Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656562: patch for libusb2-dev
tags 656562 +patch
Here is a patch for /usr/include/libusb.h
This bug is blocking the compilation of my package libccid on kfreebsd
https://buildd.debian.org/status/fetch.php?pkg=pcsc-lite&arch=kfreebsd-i386&ver=1.8.2-1&stamp=1327085304
Thanks
--
Dr. Ludovic Rousseau
--- /usr/include/libusb.h.orig 2012-01-20 21:46:52.0 +0100
+++ /usr/include/libusb.h 2012-01-20 22:55:59.0 +0100
@@ -251,7 +251,7 @@
uint8_t bMaxBurst;
uint8_t bmAttributes;
uint16_t wBytesPerInterval;
-} libusb_ss_endpoint_companion_descriptor __aligned(sizeof(void *));
+} libusb_ss_endpoint_companion_descriptor
__attribute__((__aligned(sizeof(void *;
typedef struct libusb_interface_descriptor {
uint8_t bLength;
@@ -293,7 +293,7 @@
uint8_t bDevCapabilityType;
uint32_t bmAttributes;
#define LIBUSB_USB_2_0_CAPABILITY_LPM_SUPPORT (1 << 1)
-} libusb_usb_2_0_device_capability_descriptor __aligned(sizeof(void *));
+} libusb_usb_2_0_device_capability_descriptor
__attribute__((__aligned(sizeof(void *;
typedef struct libusb_ss_usb_device_capability_descriptor {
uint8_t bLength;
@@ -309,7 +309,7 @@
uint8_t bFunctionalitySupport;
uint8_t bU1DevExitLat;
uint16_t wU2DevExitLat;
-} libusb_ss_usb_device_capability_descriptor __aligned(sizeof(void *));
+} libusb_ss_usb_device_capability_descriptor
__attribute__((__aligned(sizeof(void *;
typedef struct libusb_bos_descriptor {
uint8_t bLength;
@@ -318,7 +318,7 @@
uint8_t bNumDeviceCapabilities;
struct libusb_usb_2_0_device_capability_descriptor *usb_2_0_ext_cap;
struct libusb_ss_usb_device_capability_descriptor *ss_usb_cap;
-} libusb_bos_descriptor __aligned(sizeof(void *));
+} libusb_bos_descriptor __attribute__((__aligned(sizeof(void *;
typedef struct libusb_control_setup {
uint8_t bmRequestType;
Bug#650174: pcscd: Fails to configure
Le 27/11/11 12:22, Mark Brown a écrit : Package: pcscd Version: 1.8.1-1 Severity: serious Attempting to configure pcscd fails for me with no useful diagnostic output being produced: | Setting up pcscd (1.8.1-1) ... | dpkg: error processing pcscd (--configure): | subprocess installed post-installation script returned error exit status 1 | configured to not write apport reports What is the output of: $ apt-cache policy systemd and of: $ systemctl status pcscd.socket Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650174: pcscd: Fails to configure
Le 27/11/11 12:22, Mark Brown a écrit : Package: pcscd Version: 1.8.1-1 Severity: serious Attempting to configure pcscd fails for me with no useful diagnostic output being produced: | Setting up pcscd (1.8.1-1) ... | dpkg: error processing pcscd (--configure): | subprocess installed post-installation script returned error exit status 1 | configured to not write apport reports I can reproduce an installation problem. Maybe it is the same. Thanks for the report. -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with Reiner SCT card reader)
Le 06/03/11 21:09, Jens Körner a écrit : Thanks for the nice reply... I guess there is a little misunderstanding. To my knowledge the pscs daemon should provide an entrance in /var/log/pscd/. If this directory is empty there must be something wrong with pcscd at startup. Right? No. After starting pcscd manually, # pcscd, there is pcscd.comm and pcscd.pid located in /var/run/pcscd. To my knowledge these 2 files should be there after the start of the system. This has changed. pcscd is no more started at system start up. If these 2 Files are missing there must be some misbehavior. Or am I wrong? You are wrong. See http://ludovicrousseau.blogspot.com/2010/09/pcscd-auto-start.html -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with Reiner SCT card reader)
Le 06/03/11 19:19, Jens Körner a écrit : More informations: libccid 1.4.2-2 libpcsclite1 1.6.6-2 Reiner SCT Kartensysteme GmbH cyberJack pinpad(a) pcsc-lite version 1.6.6. Enabled features: Linux x86_64-pc-linux-gnu serial usb libhal usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/etc/reader.conf.d wheezy/sid Note that the support of Reiner SCT Kartensysteme GmbH cyberJack pinpad(a) has been removed in release 1.3.11 of libccid. See changelog http://svn.debian.org/wsvn/pcsclite/tags/ccid/ccid-1.4.2/README 1.3.11 - 28 July 2009, Ludovic Rousseau - remove support of Reiner-SCT cyberJack pinpad(a) on request of Reiner-SCT. You should user the Reiner-SCT driver instead See also http://pcsclite.alioth.debian.org/ccid/disabled.html#0x0C4B0x0300 A weird and unexpected behavior appeared after killing and then restarting pcscd. No process was killed and the card reader started to work when pcscd was called... I checked the syslog for pcscd, there was no entrance and /var/run/pcscd was an empty directory after a fresh restart of the system. This is new. Shall I open a new bug for this one? You want to open a bug report because your reader now works as expected? If you still have a problem with your Reiner reader please contact Reiner support. Thanks. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with castles SCT card reader)
Le 01/03/11 13:30, Pádraig Brady a écrit : I upgraded from 1.6.4 to 1.6.7 and... pcscd logs end with: readerfactory.c:1301:RFWaitForReaderInit() Waiting init for reader: CASTLES EZ710PU 00 01 Clients are blocked like: futex(0x2c6260, FUTEX_WAIT_PRIVATE, 2, NULL... Note this device presents 2 readers. 00 00 = smartcard, 00 01 = rfid Some more logs... hotplug_libhal.c:367:HPAddDevice() Adding USB device: usb_device_ca6_3050_noserial_if0 readerfactory.c:934:RFInitializeReader() Attempting startup of CASTLES EZ710PU 00 00 using /usr/lib/pcsc/drivers/ez7usb.bundle/Contents/Linux/ez7usb.so readerfactory.c:824:RFBindFunctions() Loading IFD Handler 3.0 readerfactory.c:965:RFInitializeReader() Open Port 0x20 Failed (USB:0CA6/3050:LIBHAL:/ORG/FREEDESKTOP/HAL/DEVICES/USB_DEVICE_CA6_3050_NOSERIAL_IF0) readerfactory.c:275:RFAddReader() CASTLES EZ710PU init failed. readerfactory.c:985:RFUnInitializeReader() Attempting shutdown of CASTLES EZ710PU 00 00. readerfactory.c:861:RFUnloadReader() Unloading reader driver. hotplug_libhal.c:464:HPAddDevice() trying libusb scheme with: usb:0ca6/3050:libusb:006:002 readerfactory.c:934:RFInitializeReader() Attempting startup of CASTLES EZ710PU 00 00 using /usr/lib/pcsc/drivers/ez7usb.bundle/Contents/Linux/ez7usb.so readerfactory.c:824:RFBindFunctions() Loading IFD Handler 3.0 readerfactory.c:290:RFAddReader() Using the pcscd polling thread readerfactory.c:934:RFInitializeReader() Attempting startup of CASTLES EZ710PU 00 01 using /usr/lib/pcsc/drivers/ez7usb.bundle/Contents/Linux/ez7usb.so readerfactory.c:738:RFLoadReader() Reusing already loaded driver for /usr/lib/pcsc/drivers/ez7usb.bundle/Contents/Linux/ez7usb.so readerfactory.c:824:RFBindFunctions() Loading IFD Handler 3.0 readerfactory.c:447:RFAddReader() Using the pcscd polling thread hotplug_libhal.c:319:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 hotplug_libhal.c:319:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 hotplug_libhal.c:319:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 readerfactory.c:1301:RFWaitForReaderInit() Waiting init for reader: CASTLES EZ710PU 00 01 It looks like a bug in the ez7usb driver. It has nothing to do with a castles SCT card reader. I could not find any Debian package providing this driver. Report the bug to the ez7usb maintainer. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with Reiner SCT card reader)
Le 26/02/11 18:27, Jens Körner a écrit : Same here. After an update to the testing version 1.5.5-4 -> 1.6.6-2 pcscd fails to work. Installing the unstable version of pcscd and dependency same result, not working. Downgrading to the stable versions of libpcsclite1_1.5.5-4, libccid_1.3.11-2 and pcscd_1.5.5-4 (all amd64.deb) the cardreader started to work again. Please provide logs. Follow http://pcsclite.alioth.debian.org/ccid.html#support Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
2011/2/24 Christoph Egger : > Ludovic Rousseau writes: >> Also note that you will have to change the pincode of your card. It >> appears in the log. > > Oh! where is that? APDU: 00 20 00 82 06 32 34 30 35 39 30 The second byte 0x20 is VERIFY http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_12 Your PIN is/was 240590 -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
2011/2/24 Christoph Egger : > Ludovic Rousseau writes: >> 1. Make sure no pcscd is running (just kill it if needed) >> 2. start pcscd as "sudo pcscd --foreground --debug --apdu" >> 3. run "gpg --card-status" >> 4. send me the pcscd and gpg logs >> >> Bye > > > was a gpg --card-status ; trying to use the auth-key for ssh ; gpg > --card-status in another terminal > > gpg just hangs, no ouotput. I do not see any error in the pcscd log. > there's some brabel in .gnupg/gpg-agent.log: > > /= > 2011-02-24 10:44:44 gpg-agent[6897] failed to unprotect the secret key: Bad > passphrase > 2011-02-24 10:44:44 gpg-agent[6897] failed to read the secret key > 2011-02-24 10:44:44 gpg-agent[6897] DBG: detected card with S/N > D2760001240102050531 > \= It looks like the problem is on the gnupg side. I will try to play with my GPG card. But I only have a V1 card and you have a V2 [1] card. Also note that you will have to change the pincode of your card. It appears in the log. Bye [1] http://smartcard-atr.appspot.com/parse?ATR=3BDA18FF81B1FE751F030031C573C00140009C -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
2011/2/24 Christoph Egger : > Ludovic Rousseau writes: >> 2011/2/24 Christoph Egger : >>> Ludovic Rousseau writes: >>>> Have you tried to reboot? >>> >>> Hm rebooted and upgraded gnupg2 to 2.0.17 -- one of these steps seems to >>> help -- kind of. some gpg-agent related processes seem to hang now, not >>> sure it's pcscd related (e.g. email signing) >> >> Does "gpg --card-status" work now? > > It's hanging now instead of not returning anything usefull OK. 1. Make sure no pcscd is running (just kill it if needed) 2. start pcscd as "sudo pcscd --foreground --debug --apdu" 3. run "gpg --card-status" 4. send me the pcscd and gpg logs Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
2011/2/24 Christoph Egger : > Ludovic Rousseau writes: >> Have you tried to reboot? > > Hm rebooted and upgraded gnupg2 to 2.0.17 -- one of these steps seems to > help -- kind of. some gpg-agent related processes seem to hang now, not > sure it's pcscd related (e.g. email signing) Does "gpg --card-status" work now? Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
Le 23/02/11 00:57, Christoph Egger a écrit : Ludovic Rousseau writes: Have you tried to unplug and replug the reader? Jep I've done that -- unfortunately it didn't help What is the output of: $ ls -la /var/run/pcscd -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
Le 23/02/11 00:57, Christoph Egger a écrit : Ludovic Rousseau writes: Have you tried to unplug and replug the reader? Jep I've done that -- unfortunately it didn't help Can you try again using pcscd 1.6.7-1 from unstable and libccid 1.4.2-1 from unstable? Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
Le 23/02/11 00:57, Christoph Egger a écrit : Ludovic Rousseau writes: Have you tried to unplug and replug the reader? Jep I've done that -- unfortunately it didn't help Have you tried to reboot? -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614376: pcscd: fails to work (with gemalto card reader)
Le 21/02/11 15:57, Christoph Egger a écrit : Package: pcscd Version: 1.5.5-4 Severity: grave After todays update (migrated to wheezy) my USB cardreader stopped to work. Downgrading to 1.5.5-4 fixes the problem. Syslog information is below: Feb 21 15:48:03 hepworth pcscd: ccid_usb.c:439:OpenUSBByName() Can't libusb_open(2/4): -3 Feb 21 15:48:03 hepworth pcscd: ifdhandler.c:101:IFDHCreateChannelByName() failed Feb 21 15:48:03 hepworth pcscd: readerfactory.c:962:RFInitializeReader() Open Port 0x20 Failed (usb:08e6/3438:libhal:/org/freedesktop/Hal/devices/usb_device_8e6_3438_noserial_if0) Feb 21 15:48:03 hepworth pcscd: readerfactory.c:273:RFAddReader() Gemalto GemPC Key init failed. Have you tried to unplug and replug the reader? A udev rule (in libccid 1.4.1) is used to set the correct access rights to the device. The error is: /** Access denied (insufficient permissions) */ LIBUSB_ERROR_ACCESS = -3, Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607781: pcsc-lite: buffer overflow
severity 607781 important tags 607781 fixed-upstream thank Le 22/12/2010 00:10, Michael Gilbert a écrit : package: pcsc-lite version: 1.4.102-1+lenny3 severity: serious tags: security an advisory has been issued for pcsc-lite: http://labs.mwrinfosecurity.com/files/Advisories/mwri_pcsc-atr-handler-buffer-overflow_2010-12-13.pdf i have checked that the vulnerable code is present in both lenny and sid. The problem has been fixed upstream in version pcsc-lite 1.6.5. pcsc-lite 1.6.6 is available in experimental ans will be uploaded to sid after squeeze is out. The attacker needs to have a physical access to the computer and a specially crafter smart card. I don't plan to fix the problem in squeeze (so lowering the severity). Thanks -- Ludovic -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607780: ccid: buffer overflow
severity 607780 important tags 607780 upstream thank Le 22/12/2010 00:08, Michael Gilbert a écrit : package: ccid version: 1.3.8-1 severity: serious tags: security an advisory has been issued for the pcsc-lite ccid driver: http://labs.mwrinfosecurity.com/files/Advisories/mwri_pcsc-libccid-buffer-overflow_2010-12-13.pdf Thanks. i have checked that the vulnerable code is present in both lenny and To trigger the bug the attacker needs to connect a serial reader to the host. And then needs to have a physical access to the computer. To enable the serial reader the attacker needs to edit the file /etc/reader.conf and configure the use of the connected serial reader. So the attacker must have root access to trigger the buffer overflow. I downgrade the severity to important. I don't think I will fix the bug for squeeze. Bye -- Ludovic -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593638: FTBFS: with pcsc-lite >= 1.6.0 (from experimental)
Package: beid
Version: 3.5.2.dfsg-10
Severity: serious
Tags: experimental patch
Justification: fails to build from source
beid fails to build from source when built with pcsc-lite >= 1.6.0
Such a version of pcsc-lite is available from exprimental and will be
uploaded in unstable once squeeze is out.
The build fails because:
- SCARD_W_INSERTED_CARD is/was a pcsc-lite specific error code and has
been removed in pcsc-lite 1.6.0
- SCARD_READERSTATE should be used instead of SCARD_READERSTATE_A and
the later was removed
See
http://ludovicrousseau.blogspot.com/2010/08/pcsc-lite-16x-breaks-some-programs-at.html
for more information.
I provide a patch:
diff -ru beid-3.5.2.dfsg.before/_src/beid-2.6/src/Belpic PCSC
Service/CardChangeMonitor.cpp beid-3.5.2.dfsg/_src/beid-2.6/src/Belpic PCSC
Service/CardChangeMonitor.cpp
--- beid-3.5.2.dfsg.before/_src/beid-2.6/src/Belpic PCSC
Service/CardChangeMonitor.cpp 2009-04-28 10:21:20.0 +0200
+++ beid-3.5.2.dfsg/_src/beid-2.6/src/Belpic PCSC Service/CardChangeMonitor.cpp
2010-08-19 21:16:25.0 +0200
@@ -62,7 +62,7 @@
if(hContext != 0)
{
-SCARD_READERSTATE_A rgscState[MAXIMUM_SMARTCARD_READERS] = {0};
+SCARD_READERSTATE rgscState[MAXIMUM_SMARTCARD_READERS] = {0};
long lReturn;
int iCount = 0;
int i, j;
diff -ru beid-3.5.2.dfsg.before/_src/beid-2.6/src/Belpic PCSC
Service/PCSCManager.cpp beid-3.5.2.dfsg/_src/beid-2.6/src/Belpic PCSC
Service/PCSCManager.cpp
--- beid-3.5.2.dfsg.before/_src/beid-2.6/src/Belpic PCSC
Service/PCSCManager.cpp2009-04-28 10:21:20.0 +0200
+++ beid-3.5.2.dfsg/_src/beid-2.6/src/Belpic PCSC Service/PCSCManager.cpp
2010-08-19 21:17:01.0 +0200
@@ -334,8 +334,8 @@
unsigned long ulReaders = 0;
pMessage->Get("Timeout", ulTimeout);
pMessage->Get("ReadersLen", (long *)&ulReaders);
-SCARD_READERSTATE_A *prgReaderStates = new
SCARD_READERSTATE_A[ulReaders];
-memset(prgReaderStates, 0, sizeof(SCARD_READERSTATE_A) *
ulReaders);
+SCARD_READERSTATE *prgReaderStates = new
SCARD_READERSTATE[ulReaders];
+memset(prgReaderStates, 0, sizeof(SCARD_READERSTATE) * ulReaders);
char szReaders[MAXIMUM_SMARTCARD_READERS][64] = {0};
for(unsigned int i = 0; i < ulReaders; ++i)
{
diff -ru
beid-3.5.2.dfsg.before/_src/beid-2.6/src/newpkcs11/src/libopensc/reader-pcsc.c
beid-3.5.2.dfsg/_src/beid-2.6/src/newpkcs11/src/libopensc/reader-pcsc.c
---
beid-3.5.2.dfsg.before/_src/beid-2.6/src/newpkcs11/src/libopensc/reader-pcsc.c
2009-04-28 10:21:26.0 +0200
+++ beid-3.5.2.dfsg/_src/beid-2.6/src/newpkcs11/src/libopensc/reader-pcsc.c
2010-08-19 21:15:22.0 +0200
@@ -82,7 +82,7 @@
struct pcsc_slot_data {
SCARDHANDLE pcsc_card;
- SCARD_READERSTATE_A readerState;
+ SCARD_READERSTATE readerState;
};
static int pcsc_detect_card_presence(struct sc_reader *reader, struct
sc_slot_info *slot);
@@ -300,7 +300,7 @@
struct sc_context *ctx;
SCARDCONTEXT pcsc_ctx;
LONG ret;
- SCARD_READERSTATE_A rgReaderStates[SC_MAX_READERS];
+ SCARD_READERSTATE rgReaderStates[SC_MAX_READERS];
unsigned long on_bits, off_bits;
time_t end_time, now, delta;
int i;
@@ -348,7 +348,7 @@
/* Wait for a status change and return if it's a card insert/removal
*/
for( ; ; ) {
- SCARD_READERSTATE_A *rsp;
+ SCARD_READERSTATE *rsp;
/* Scan the current state of all readers to see if they
* match any of the events we're polling for */
diff -ru beid-3.5.2.dfsg.before/_src/beid-2.6/src/winscarp/winscarp.cpp
beid-3.5.2.dfsg/_src/beid-2.6/src/winscarp/winscarp.cpp
--- beid-3.5.2.dfsg.before/_src/beid-2.6/src/winscarp/winscarp.cpp
2009-04-28 10:21:30.0 +0200
+++ beid-3.5.2.dfsg/_src/beid-2.6/src/winscarp/winscarp.cpp 2010-08-19
21:14:20.0 +0200
@@ -72,7 +72,8 @@
typedef GUID *LPGUID;
typedef char *LPWSTR;
typedef const char *LPCWSTR;
-typedef SCARD_READERSTATE_A *LPSCARD_READERSTATE_W;
+typedef SCARD_READERSTATE *LPSCARD_READERSTATE_A;
+typedef SCARD_READERSTATE *LPSCARD_READERSTATE_W;
typedef const char *LPCSTR;
#endif //_WIN32
@@ -1591,9 +1592,6 @@
case SCARD_W_REMOVED_CARD:
strcpy(strError, "Card was removed.");
break;
- case SCARD_W_INSERTED_CARD:
- strcpy(strError, "Card was inserted.");
- break;
case SCARD_E_UNSUPPORTED_FEATURE:
strcpy(strError, "Feature not supported.");
break;
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR
Bug#591782: ccid: FTBFS on kfreebsd-*: configure: error: libusb.h not found
tags 591782 upstream pending severity 591782 important thank Le 05/08/10 17:12, Cyril Brulebois a écrit : Source: ccid Version: 1.4.0-1 Severity: serious Justification: FTBFS User: debian-...@lists.debian.org Usertags: kfreebsd The package is in experimental only. I downgrade the severity to not make the bug release critical. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591782: ccid: FTBFS on kfreebsd-*: configure: error: libusb.h not found
Le 05/08/10 17:12, Cyril Brulebois a écrit : Source: ccid Version: 1.4.0-1 Severity: serious Justification: FTBFS User: debian-...@lists.debian.org Usertags: kfreebsd Hi, your package no longer builds on kfreebsd-*: | checking for LIBUSB... yes | checking libusb-1.0/libusb.h usability... no | checking libusb-1.0/libusb.h presence... no | checking for libusb-1.0/libusb.h... no | configure: error: libusb.h not found, install libusb or use ./configure LIBUSB_CFLAGS=... | ==> config.log<== Full build logs: https://buildd.debian.org/status/package.php?p=ccid&suite=experimental This package has a Build-Depends: libusb-1.0-0-dev And from the build log I see: Need libusb-1.0-0-dev, but it isn't available The buildd installed libusb2-dev instead and the build fails. I identified the problem and will fix it "soon". Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569426: pilot-link: FTBFS: dpkg-shlibdeps: error: couldn't find library libpisock.so.9 needed by debian/libpisync1/usr/lib/libpisync.so.1.0.3 (ELF format: 'elf64-x86-64'; RPATH: '').
Le 11/02/10 22:14, Lucas Nussbaum a écrit : On 11/02/10 at 22:09 +0100, Ludovic Rousseau wrote: Hello Lucas, The problem you discovered is not related to problem dpkg-shlibdeps error but a _dependency_ problem in my debian/rules file. My source package generates different binary packages with dependencies between them. And problems arrive if make uses more than 1 job (MAKEFLAGS=-j2 for example) You could rebuild the package with MAKEFLAGS=-j1 and see if the build also fails. If the build fails only with more than one jobs then the problem is with parallel build. Maybe you should suggest searching in this direction in your next FTBFS bugs. I'm not using MAKEFLAGS, but DEB_BUILD_OPTIONS=parallel=8. If your debian/rules handles that, then it means that it should be supported, and that your package should build correctly. So it would probably be better (and a proper fix) to just disable the support for building using several jobs. My package (should) support DEB_BUILD_OPTIONS=parallel=8 now. Thanks for spotting the bug -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569426: pilot-link: FTBFS: dpkg-shlibdeps: error: couldn't find library libpisock.so.9 needed by debian/libpisync1/usr/lib/libpisync.so.1.0.3 (ELF format: 'elf64-x86-64'; RPATH: '').
gencontrol -p libpisock-dev dh_shlibdeps -p libpisync1 -l debian/libpisock9/usr/lib dh_shlibdeps -p libpda-pilot-perl -l debian/libpisock9/usr/lib dh_installdeb -p python-pisock dpkg-shlibdeps: error: couldn't find library libpisock.so.9 needed by debian/libpisync1/usr/lib/libpisync.so.1.0.3 (ELF format: 'elf64-x86-64'; RPATH: ''). Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. dh_shlibdeps: dpkg-shlibdeps -Tdebian/libpisync1.substvars debian/libpisync1/usr/lib/libpisync.so.1.0.3 returned exit code 2 make: *** [libpisync1] Error 9 The full build log is available from: http://people.debian.org/~lucas/logs/2010/02/11/pilot-link_0.12.5-1_lsid64.buildlog A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565896: closed by Ludovic Rousseau (Bug#565896: fixed in pcsc-lite 1.5.5-2)
Le 31/01/10 10:24, Tollef Fog Heen a écrit : reopen 565896 found 565896 1.5.5-2 thanks ]] (Debian Bug Tracking System) |* debian/update-reader.conf: add a SHA1 on the first line of the | configuration file to detect manual edition. Closes: #565896 "pcscd: | overwrites changes in configuration files" | urgency=medium because of RC bug. This isn't enough, you still don't handle the case of /etc/readers.conf being deleted. Wouldn't it be easier just to use ucf than to reinvent it? Using ucf would also allow the user to review any updates and merge them if appropriate. I don't handle many cases. An admin shall not edit or modify /etc/reader.conf directly. He shall edit the files in /etc/reader.conf.d/ instead or use "dpkg-reconfigure package-name" if the driver provides this. I do not plan to support stupid admins. I had a look at ucf but I don't think that is adapted to my case. The file /etc/reader.conf is the concatenation of files in /etc/reader.conf.d/ Also note that the file /etc/reader.conf is _only_ used for smart card readers connected to the host using the serial port. These readers are really deprecated by USB and ExpressCard readers. Do you have such a serial smart card reader yourself? Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565896: pcscd: overwrites changes in configuration files
Le 19/01/10 14:42, Tollef Fog Heen a écrit : Package: pcscd Version: 1.5.5-1 Severity: serious update-reader.conf is called unconditionally in the postinst and overwrites admin changes to /etc/reader.conf. This is a violation of policy 10.7.3. The /etc/reader.conf contains a "warning": # Do NOT edit this file directly but use update-reader.conf(8) instead. update-reader.conf(8) checks that the /etc/reader.conf contains the line: ### This file is automatically generated by update-reader.conf So a config file written by hand from scratch is _not_ overwritten. What should the update-reader.conf if the file have been manually modified? Do you have an example of an update-foo command that does what you request for? Bye -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510567: Enable gpgconf support (gpa, kleopatra, ...)
Hello, This bug is open since 3 Jan 2009. It is very easy to fix. If you do not have time to take care of your packages please consider orphaning them. Otherwise an NMU would be welcome to solve this RC bug. Please do something. Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554088: [Jppy-devel] (fwd) Bug#554088: jppy - FTBFS: KeyError: 'TERM'
This bug is mine :-( I added support of TERM in http://jppy.alioth.debian.org/changeset/bae16bd60932db72de23eb09fc8691f8e41dce6a But the build fails if TERM is not defined, as is the case in an automatic build system. I just corrected the bug upstream in http://jppy.alioth.debian.org/changeset/67b659e0ca5b61b0adb46d03c74626253e933767 Bye 2009/11/4 Nicholas Piper : > - Forwarded message from Bastian Blank - > > From: Bastian Blank > Subject: Bug#554088: jppy - FTBFS: KeyError: 'TERM' > To: sub...@bugs.debian.org > X-Spam-Level: > Resent-To: debian-bugs-d...@lists.debian.org > X-Debian-PR-Message: report 554088 > X-Debian-PR-Package: src:jppy > X-Debian-PR-Keywords: > X-Debian-PR-Source: jppy > Date: Mon, 2 Nov 2009 22:41:43 +0100 > X-Debian: PTS > X-Debian-Package: jppy > X-PTS-Package: jppy > X-PTS-Keyword: bts > X-originally-to: deb...@nickpiper.co.uk > > Source: jppy > Version: 0.0.53-1 > Severity: serious > > There was an error while trying to autobuild your package: > >> sbuild (Debian sbuild) 0.58.2 (31 Jul 2009) on debian-31.osdl.marist.edu > [...] >> scons: Reading SConscript files ... >> Please remember that SCons does NOT automatically use your shell >> environment variables. This script uses PKG_CONFIG_PATH explicitly. >> KeyError: 'TERM': >> File "/build/buildd-jppy_0.0.53-1-s390-4AhqYb/jppy-0.0.53/SConstruct", >> line 63: >> 'TERM' : os.environ['TERM'],} >> File "/usr/lib/python2.5/UserDict.py", line 22: >> raise KeyError(key) >> make: *** [build-python2.5-stamp] Error 2 >> dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > > > - End forwarded message - > > ___ > Jppy-devel mailing list > jppy-de...@zanu.org.uk > http://mail.zanu.org.uk/mailman/listinfo/jppy-devel > -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536877: Fwd: Bug#535667: kpilot: Possible runtime problem with libpisock9 0.12.4
-- Forwarded message -- From: Ludovic Rousseau Date: 2009/7/18 Subject: Re: Bug#535667: kpilot: Possible runtime problem with libpisock9 0.12.4 To: Sune Vuorela Cc : Ludovic Rousseau , 535...@bugs.debian.org Sune Vuorela a écrit : > > On Saturday 04 July 2009 11:19:54 Ludovic Rousseau wrote: >> >> Package: kpilot >> Severity: normal >> >> Hello, >> >> Your package kpilot (and also kdepim-kfile-plugins) depends on >> libpisock9. I uploaded a new upstream version of pilot-link 0.12.4 and >> users discovered unplanned problems (#532798 #535565 #535588) with >> jpilot, another application also using libpisock9. >> >> The problem appears when jpilot is compiled against libpisock-dev 0.12.3 >> but executed using libpisock9 0.12.4. > > Hi. That kind of behaviour changes is not acceptable. Packages with their > dependencies fulfilled should just work. > > You basically have the following possibilities: > Rename the libpisock9 package or > roll back the libpisock9 behaviour change or > put in appropriate breaks to libpisock9 I never used Breaks: before. Do I need something like: Package: libpisock9 Breaks: kpilot (<< 4:4.2.4-1), gnome-pilot (<< 2.0.15-2.4), etc. How do I get the exact release number of the broken packages? I you upload kpilot 4:4.2.4-2 to unstable but still linked with the old version of libpisock9 the breaks rule will be incorrect. Or maybe I should only take care of version numbers of the broken packages in Lenny and only support the Lenny -> Squeeze upgrade? Thanks -- Dr. Ludovic Rousseau -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
On Tue, Nov 4, 2008 at 1:29 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: > Ok, I changed the mkstemp back to mktemp. Do you plan to release the 2.85 version soon? I can only find version 2.84 on [1]. Bye [1] http://www.sentex.net/~mwandel/jhead/ -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504194: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
severity 504194 important thank On Sat, Nov 1, 2008 at 4:36 PM, Ludovic Rousseau <[EMAIL PROTECTED]> wrote: > Nico Golde a écrit : >> >> Hi Ludovic, >> * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-11-01 15:55]: >>> If I understand correctly it will just delete >>> files with names derived from existing files. I cannot be used to >>> delete arbitrary files. >> >> Why is this unlink needed anyway? > > Because jhead is used to modify files but the commands called by jhead can't > use the file "in place" but use a source and a target. jhead then rename the > target file to the source file. > > The temp file is first removed (if any). > the transformation command is called > the source files is unlinked > the target file is renamed to the source file > > Maybe the unlink() calls can be removed but that would not solve the > problem. The temporary file would still be created by the command called by > jhead (like mogrify of jpegtran). I change the severity from RC to important. jhead can't remove arbitrary files but just files whose filenames have one character changed from the filename given to the command. jhead is not setuid. I don't think it is more dangerous than the rm(1) command. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
clone 503645 -1 reopen -1 retitle -1 CVE-2008-4640: insecure file handling thank Nico Golde a écrit : Hi Ludovic, * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-11-01 15:55]: On Sat, Nov 1, 2008 at 1:36 PM, Nico Golde <[EMAIL PROTECTED]> wrote: Hi Bruno, * Bruno De Fraine <[EMAIL PROTECTED]> [2008-10-29 18:43]: [...] Nico, do you think this would be sufficient to rule out the vulnerability? I didn't get this message because you didn't CC me. I just had a look at the applied patch and I think this is sufficient. You didn't fix CVE-2008-4640 in this version, did you? Exact. CVE-2008-4640 is still present. I don't think it is an important problem. Please reopen this bug then or clone it and reopen the clone. Just done. If I understand correctly it will just delete files with names derived from existing files. I cannot be used to delete arbitrary files. Why is this unlink needed anyway? Because jhead is used to modify files but the commands called by jhead can't use the file "in place" but use a source and a target. jhead then rename the target file to the source file. The temp file is first removed (if any). the transformation command is called the source files is unlinked the target file is renamed to the source file Maybe the unlink() calls can be removed but that would not solve the problem. The temporary file would still be created by the command called by jhead (like mogrify of jpegtran). bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
On Sat, Nov 1, 2008 at 1:36 PM, Nico Golde <[EMAIL PROTECTED]> wrote: > Hi Bruno, > * Bruno De Fraine <[EMAIL PROTECTED]> [2008-10-29 18:43]: > [...] >> Nico, do you think this would be sufficient to rule out the vulnerability? > > I didn't get this message because you didn't CC me. > I just had a look at the applied patch and I think this is > sufficient. > You didn't fix CVE-2008-4640 in this version, did you? Exact. CVE-2008-4640 is still present. I don't think it is an important problem. If I understand correctly it will just delete files with names derived from existing files. I cannot be used to delete arbitrary files. But if someone has a fix for CVE-2008-4640 I will apply it and upload a new version. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
On Mon, Oct 27, 2008 at 5:03 PM, Nico Golde <[EMAIL PROTECTED]> wrote: > Hi Ludovic, > * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-10-27 16:47]: >> On Mon, Oct 27, 2008 at 1:06 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: >> > So what is the security vulnerability? >> > >> > You can use it to delete files, but why not just use "rm"? >> >> If I understand correctly we have two problems (from [1]) >> 2 - unsafe temp file creation > > Yes but this is not exactly the same problem like the static > name that was used before. > >> 4 - shell escapes >> >> I think "unsafe temp file creation" is referring to the use of >> unlink() at line 329 of jhead.c. I don't think it is a grave problem. > > Correct. > >> "shell escapes" is more serious since you use system() at line 339 of >> jhead.c without escaping any special characters a file name could >> contain. > > Correct, that is the problem. Crafted file names can execute > commands in the shell. > >> For example if you have a file named "foo.jpg ; rm -rf ~" you could >> make bad things without noticing. >> Yes, you should be stupid to use such a file name. > > All the issues recently released for jhead are not really > important, the problem are non-interactive setups where > jhead is called from scripts. > >> > Unless of course you run it as setuid root, but why would you go out ot >> > your >> > way to do that? >> >> A solution would be to use one of the exec(3) system calls instead of >> system(3). > > Yes or to filter the string. I may try to implement a filter mechanism. I think the idea is to stop the execution with an error message if a special character is found. What would be the list of normal characters? [a-z][A-Z][0-9][-.]? How to filter file names in UTF-8? with accents or non ASCII characters? An easier solution is to refuse special characters like & and ; but that may not completely solve the problem. I need help here. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: Fwd: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
>From upstream. -- Forwarded message -- From: Matthias Wandel <[EMAIL PROTECTED]> Date: Mon, Oct 27, 2008 at 4:13 PM Subject: Re: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling To: Ludovic Rousseau <[EMAIL PROTECTED]> Ah, the use of "exec" had been suggested before, but I didn't see a good reason for it. I suppose if its used for something that processes files from random users on a server, this could potentially be exploited. I should make that change, though I won't have time for it right away. Though if somebody had a patch, that would be quicker to integrate. The unsafe temp file creation I won't worry about for the moment. Matthias ----- Original Message - From: "Ludovic Rousseau" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 27, 2008 9:52 AM Subject: Re: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling > On Mon, Oct 27, 2008 at 1:06 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: >> >> So what is the security vulnerability? >> >> You can use it to delete files, but why not just use "rm"? > > If I understand correctly we have two problems (from [1]) > 2 - unsafe temp file creation > 4 - shell escapes > > I think "unsafe temp file creation" is referring to the use of > unlink() at line 329 of jhead.c. I don't think it is a grave problem. > > "shell escapes" is more serious since you use system() at line 339 of > jhead.c without escaping any special characters a file name could > contain. > For example if you have a file named "foo.jpg ; rm -rf ~" you could > make bad things without noticing. > Yes, you should be stupid to use such a file name. > >> Unless of course you run it as setuid root, but why would you go out ot your >> way to do that? > > A solution would be to use one of the exec(3) system calls instead of > system(3). > > Bye > > [1] http://www.openwall.com/lists/oss-security/2008/10/16/3 > > -- > Dr. Ludovic Rousseau > -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
On Mon, Oct 27, 2008 at 1:06 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: > So what is the security vulnerability? > > You can use it to delete files, but why not just use "rm"? If I understand correctly we have two problems (from [1]) 2 - unsafe temp file creation 4 - shell escapes I think "unsafe temp file creation" is referring to the use of unlink() at line 329 of jhead.c. I don't think it is a grave problem. "shell escapes" is more serious since you use system() at line 339 of jhead.c without escaping any special characters a file name could contain. For example if you have a file named "foo.jpg ; rm -rf ~" you could make bad things without noticing. Yes, you should be stupid to use such a file name. > Unless of course you run it as setuid root, but why would you go out ot your > way to do that? A solution would be to use one of the exec(3) system calls instead of system(3). Bye [1] http://www.openwall.com/lists/oss-security/2008/10/16/3 -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503645: Fwd: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
>From upstream author. -- Forwarded message -- From: Matthias Wandel Date: Mon, Oct 27, 2008 at 1:06 PM Subject: Re: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling To: Ludovic Rousseau <[EMAIL PROTECTED]> So what is the security vulnerability? You can use it to delete files, but why not just use "rm"? Unless of course you run it as setuid root, but why would you go out ot your way to do that? Matthias - Original Message ----- From: "Ludovic Rousseau" <[EMAIL PROTECTED]> To: Sent: Monday, October 27, 2008 4:25 AM Subject: Fwd: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling > Hello Matthias, > > Are you aware of this new security problems? > Are you working on the problem? > Do you plan to release a version 2.85 of jhead with a fix? > > Thanks > > -- Forwarded message -- > From: Nico Golde <[EMAIL PROTECTED]> > Date: Mon, Oct 27, 2008 at 10:10 AM > Subject: Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command > injection via filename and insecure file handling > To: [EMAIL PROTECTED] > > > Package: jhead > Severity: grave > Tags: security > > Hi, > the following CVE (Common Vulnerabilities & Exposures) ids were > published for jhead. > > CVE-2008-4641[0]: > | The DoCommand function in jhead.c in Matthias Wandel jhead 2.84 and > | earlier allows attackers to execute arbitrary commands via shell > | metacharacters in unspecified input. > > CVE-2008-4640[1]: > | The DoCommand function in jhead.c in Matthias Wandel jhead 2.84 and > | earlier allows local users to delete arbitrary files via vectors > | involving a modified input filename in which (1) a final "z" character > | is replaced by a "t" character or (2) a final "t" character is > | replaced by a "z" character. > > If you fix the vulnerabilities please also make sure to include the > CVE ids in your changelog entry. > > For further information see: > > [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4641 > http://security-tracker.debian.net/tracker/CVE-2008-4641 > [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4640 > http://security-tracker.debian.net/tracker/CVE-2008-4640 > > -- > Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF > For security reasons, all text in this mail is double-rot13 encrypted. > > > > -- > Dr. Ludovic Rousseau > -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503206: pcsc-lite does not build without libusb-dev
Hello, Xavier Luthi a écrit : Hi, I've tried to reproduce your bug in a freshly installed chroot environment as well as on a running system. On my systems, all packages are successfully build: pcscd, libpcsclite-dev and libpcsclite1. Are you sure libusb-dev is a build dependency for pcsc-lite source package? pcsc-lite does not use libusb on Linux since version 1.4.100 but use libhal instead. pcsc-lite has a Build-Depends: on libhal-dev and that should work. Thanks Xavier to confirm the package builds correctly. I also checked the package build using sid in pbuilder. I now close this bug. Daniel, if you still think the package has a build problem then please reopen the bug and most importantly provide a build log. Thanks -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352615: Removing coldsync?
On Sat, Aug 9, 2008 at 8:23 PM, Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > Hi, > > coldsync has been orphaned for a very long time now and I am evaluating > whether a request for removal should be finally filed. > > You are receiving this mail because: > - your name showed up somewhere in the history of the package > - I think that you might be interested for some reason > - or you maintain a related/similar package > > Are you interested in adopting this package? Do you know potential adopters? > If so, please could you forward them this mail, Ccing the BTS and me? > > If there is no action from anyone, I'll request the removal of this package > from Debian after a month. The latest version coldsync-3.0-pre4 is from February 2004. The CVS host is dead: cvs.coldsync.org do not even have an IP address I think you can ask for the the removal of this package. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477421: jpilot: makes palm Z22 crash after sync
tags 477421 upstream forwarded 477421 http://bugs.jpilot.org/1918 severity 477421 important thank Erwan David a écrit : Package: jpilot Version: 0.99.9.22-1 Severity: critical Justification: causes serious data loss After a sync with jpilot of my palm Z22, the palm is blocked with message "Fatal error AddressLib.c, Line:395, Invalid AppInfo Block" soft resetting the palm does nothing I need to hard reset it (thus the data loss). I tried with a new profile (no .jpilot directory). The data where almost all gathered from the palm, except the categories for the contacts. In case it helps... You are not the only one to suffer from this bug. It has been reported [1] to the jpilot mailing list. According to [2] the bug was not present in jpilot-0.99.9.18. I have reported the bug in the upstream bug tracker. Bye [1] http://lists.jpilot.org/pipermail/jpilot/2008-April/007302.html [2] http://lists.jpilot.org/pipermail/jpilot/2008-May/007314.html -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477421: jpilot: makes palm Z22 crash after sync
Erwan David a écrit : On Wed, Apr 23, 2008 at 04:15:33PM CEST, Erwan David <[EMAIL PROTECTED]> said: On Wed, Apr 23, 2008 at 03:43:40PM CEST, Ludovic Rousseau <[EMAIL PROTECTED]> said: Que ce passe t'il avec : $ pilot-xfer --port usb: --backup repertoire_de_sauvegarde pilot-xfer est disponible dans le paquet pilot-link Je vais tester dès que possible. Cependant je ne passe pas par la libusb mais par le module visor : impossible d'avoir une connexion en usb: (et sans module visor du coup). C'est une incompatibilité qu'on retrouve sur google... En tout cas voilà ce que ça donne sur un palm sans données pilot-xfer --port /dev/pilot --backup test-backup-palm Listening for incoming connection on /dev/pilot... connected! Ça marche aussi pour un palm avec données. Pas de problème. Pour les prochains tests si ça foire je tenterai le pilot-xfer -r. Je suspecte que la base de donnée DatebookDB soit corrompue. Je propose de tester la manip suivante : - réinstaller tout sur le Palm (depuis le Mac) - écraser la base DatebookDB par une base vide (depuis le backup du Palm vide fait avec pilot-xfer par exemple) - vérifier que l'application carnet d'adresse fonctionne sur le Palm (elle doit être vide) - faire une synchro avec jpilot -- Dr. Ludovic Rousseau
Bug#477421: jpilot: makes palm Z22 crash after sync
Erwan David a écrit : On Wed, Apr 23, 2008 at 03:43:40PM CEST, Ludovic Rousseau <[EMAIL PROTECTED]> said: Que ce passe t'il avec : $ pilot-xfer --port usb: --backup repertoire_de_sauvegarde pilot-xfer est disponible dans le paquet pilot-link Je vais tester dès que possible. Cependant je ne passe pas par la libusb mais par le module visor : impossible d'avoir une connexion en usb: (et sans module visor du coup). C'est une incompatibilité qu'on retrouve sur google... En tout cas voilà ce que ça donne sur un palm sans données pilot-xfer --port /dev/pilot --backup test-backup-palm Comment tu remets les données sur le Palm après le hard reset et avant de faire une synchro avec jpilot vierge ? -- Dr. Ludovic Rousseau
Bug#477421: jpilot: makes palm Z22 crash after sync
Erwan David a écrit : On Wed, Apr 23, 2008 at 09:45:44AM CEST, Ludovic Rousseau <[EMAIL PROTECTED]> said: Erwan David a écrit : Package: jpilot Version: 0.99.9.22-1 Severity: critical Justification: causes serious data loss After a sync with jpilot of my palm Z22, the palm is blocked with message "Fatal error AddressLib.c, Line:395, Invalid AppInfo Block" soft resetting the palm does nothing I need to hard reset it (thus the data loss). I tried with a new profile (no .jpilot directory). The data where almost all gathered from the palm, except the categories for the contacts. In case it helps... I am not sure to understand the procedure you used. You start with an non-existant ~/.jpilot directory You start jpilot You do a first sync After the sync the Palm is blocked. Is that the exact procedure you used? bye Oui. (le français sera plus simple). Que ce passe t'il avec : $ pilot-xfer --port usb: --backup repertoire_de_sauvegarde pilot-xfer est disponible dans le paquet pilot-link -- Dr. Ludovic Rousseau
Bug#477421: jpilot: makes palm Z22 crash after sync
Erwan David a écrit : Package: jpilot Version: 0.99.9.22-1 Severity: critical Justification: causes serious data loss After a sync with jpilot of my palm Z22, the palm is blocked with message "Fatal error AddressLib.c, Line:395, Invalid AppInfo Block" soft resetting the palm does nothing I need to hard reset it (thus the data loss). I tried with a new profile (no .jpilot directory). The data where almost all gathered from the palm, except the categories for the contacts. In case it helps... I am not sure to understand the procedure you used. You start with an non-existant ~/.jpilot directory You start jpilot You do a first sync After the sync the Palm is blocked. Is that the exact procedure you used? bye -- Dr. Ludovic Rousseau
Bug#456877: coolkey: FTBFS: /usr/bin/ld: cannot find -lsoftokn3
Lucas Nussbaum a écrit : Package: coolkey version: 1.1.0-3 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20071217 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: > make[3]: Entering directory `/build/user/coolkey-1.1.0/src/install' > if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I /usr/include/nss -I /usr/include/nspr/-g -O2 -MT pk11install.o -MD -MP -MF ".deps/pk11install.Tpo" -c -o pk11install.o pk11install.c; \ > then mv -f ".deps/pk11install.Tpo" ".deps/pk11install.Po"; else rm -f ".deps/pk11install.Tpo"; exit 1; fi > /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -o pk11install pk11install.o -lnss3 -lsoftokn3 -ldl -lz > mkdir .libs > gcc -g -O2 -o pk11install pk11install.o -lnss3 -lsoftokn3 -ldl -lz > /usr/bin/ld: cannot find -lsoftokn3 > collect2: ld returned 1 exit status > make[3]: *** [pk11install] Error 1 > make[3]: Leaving directory `/build/user/coolkey-1.1.0/src/install' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/build/user/coolkey-1.1.0' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/build/user/coolkey-1.1.0' > make: *** [build-stamp] Error 2 > dpkg-buildpackage: failure: debian/rules build gave error exit status 2 The libsoftokn3.so library has moved to /usr/lib/nss/ with nss version 3.12.0~1.9b1-1 with the changelog.Debian.gz [1] entry: + Install libsoftokn3 and the new libnssdbm3 in /usr/lib/nss. I tried to hack src/install/Makefile.in to add -L/usr/lib/nss. The build works fine but the generated /usr/bin/pk11install binary will not find the libsoftokn3. I also tried to add -rpath /usr/lib/nss but libtool removed this argument. I guess the only solution now is to use dlopen(). Mike, as nss maintainer, do you have a better idea/solution? Thanks, [1] http://packages.debian.org/changelogs/pool/main/n/nss/nss_3.12.0~1.9b1-2/changelog -- Dr. Ludovic Rousseau
Bug#443576: Strict aliasing problem
Le 23.09.2007, à 10:22:15, Falk Hueffner a écrit:
> "Phil Endecott" <[EMAIL PROTECTED]> writes:
>
> >> I think I found a bug in gcc-4.2
> >
> >> int i, j;
> >> printf("%d %d\n", j, (void *)(j));
> >
> > This looks like a strict-aliasing issue to me; you're casting from an
> > int to a void*, which is undefined.
>
> Casting from int to void* is not undefined, but implementation
> defined. Also, this clearly has nothing to do with aliasing, since
> aliasing is about accessing objects using an lvalue of a bad type, and
> not about casting.
>
> I would rather guess this is the same problem as #440545 (caused by a
> bug in SCEV).
It looks like the same bug. The bug was discovered when using the glib
GINT_TO_POINTER() macro. Exactly as in #440545.
The sample code provided in #440545 is also very similar to mine.
The upstream bug report (http://gcc.gnu.org/PR33381) has a patch
included. So I hope the bug will not stay opened too long.
Maybe Debian will have to auto-rebuild the complete archive after the
bug is solved to remove any miss-compiled code.
Thanks
--
Dr. Ludovic Rousseau[EMAIL PROTECTED]
-- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --
Bug#443576: gcc-4.2: -O2 generates wrong code
Package: gcc-4.2
Version: 4.2.1-5
Severity: critical
Justification: breaks unrelated software
Hello,
I think I found a bug in gcc-4.2. The bug is easy to reproduce. I have
it under sid and also under testing.
I provide a simple test program (gint_to_pointer.c):
#include
int main(void)
{
int i, j;
for (i=0; i<6; i++)
{
j = i-1;
printf("%d %d\n", j, (void *)(j));
}
}
When compiled with make gint_to_pointer CFLAGS="-O0" the execution gives:
-1 -1
0 0
1 1
2 2
3 3
4 4
But when compiled with make gint_to_pointer CFLAGS="-O2" the execution gives:
-1 -1
0 -1
1 -1
2 -1
3 -1
4 -1
I generated the assembly for the two cases.
With -O0
.file "gint_to_pointer.c"
.section.rodata
.LC0:
.string "%d %d\n"
.text
.globl main
.type main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
subl$36, %esp
movl$0, -12(%ebp)
jmp .L2
.L3:
movl-12(%ebp), %eax
subl$1, %eax
movl%eax, -8(%ebp)
movl-8(%ebp), %eax
movl%eax, 8(%esp)
movl-8(%ebp), %eax
movl%eax, 4(%esp)
movl$.LC0, (%esp)
callprintf
addl$1, -12(%ebp)
.L2:
cmpl$5, -12(%ebp)
jle .L3
addl$36, %esp
popl%ecx
popl%ebp
leal-4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.2.1 (Debian 4.2.1-5)"
.section.note.GNU-stack,"",@progbits
with -O2:
.file "gint_to_pointer.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d %d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ebx
xorl%ebx, %ebx
pushl %ecx
subl$16, %esp
movl$-1, 8(%esp)
movl$-1, 4(%esp)
movl$.LC0, (%esp)
callprintf
.p2align 4,,7
.L2:
movl%ebx, 4(%esp)
addl$1, %ebx
movl$-1, 8(%esp)
movl$.LC0, (%esp)
callprintf
cmpl$5, %ebx
jne .L2
addl$16, %esp
popl%ecx
popl%ebx
popl%ebp
leal-4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.2.1 (Debian 4.2.1-5)"
.section.note.GNU-stack,"",@progbits
I do not read i386 assembly so can't help spot the bug.
Notes:
I have no problem if I use "i" or "i+1" instead of "i-1".
I have no problem if I start the loop at 1 instead of 0.
I discovered the bug because of my package does not work correctly anymore.
Other packages compiled with gcc-4.2 may also fail in very obscure ways.
Thanks,
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-2-686 (SMP w/2 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.2 depends on:
ii binutils 2.18-1 The GNU assembler, linker and bina
ii cpp-4.2 4.2.1-5The GNU C preprocessor
ii gcc-4.2-base 4.2.1-5The GNU Compiler Collection (base
ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries
ii libgcc1 1:4.2.1-5 GCC support library
ii libgomp1 4.2.1-5GCC OpenMP (GOMP) support library
Versions of packages gcc-4.2 recommends:
ii libc6-dev 2.6.1-1+b1 GNU C Library: Development Librari
pn libmudflap0-4.2-dev(no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434329: mail-notification crashes
Le 11.08.2007, à 01:52:12, Erich Schubert a écrit: > Hi, Hello, > Archived packages of gmime2.0 version 2.2.9 can be found at > http://snapshot.debian.net/archive/2007/07/22/debian/pool/main/g/gmime2.2/ > > Maybe the bug can be reproduced in a debug build when it is compiled > with the -dev package in version 2.2.9 and then run with 2.2.10? I tried that. I installed libgmime-2.0-2_2.2.9-1_i386.deb and libgmime-2.0-2-dev_2.2.9-1_i386.deb and rebuilt mail-notification. But I can't reproduce the crash when I execute mail-notification. I then upgraded libgmime to 2.2.10 and I have the crash. The good news is that I have a mail-notification compiled with debug so I can use gdb. $ gdb ./mail-notification [...] Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1226266960 (LWP 5644)] (mail-notification:5644): GLib-GObject-WARNING **: specified instance size for type `MNGMimeStreamVFS' is smaller than the parent type's `GMimeStream' instance size (mail-notification:5644): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type `' [New Thread -1229612144 (LWP 5649)] (mail-notification:5644): GLib-GObject-WARNING **: specified instance size for type `MNGMimeStreamVFS' is smaller than the parent type's `GMimeStream' instance size (mail-notification:5644): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1229612144 (LWP 5649)] 0x0808b0b0 in mn_gmime_stream_vfs_new (handle=0xb6202d20, uri=0xb6206070, result=0xb6b591e4) at mn-gmime-stream-vfs.gob:266 266 selfp->handle = handle; (gdb) p selfp No symbol "selfp" in current context. (gdb) p self $1 = (Self *) 0x0 selfp is a macro defined as #define selfp (self->_priv) So dereferencing a NULL pointer is not a good idea. The previous line in mn-gmime-stream-vfs.gob is: self = GET_NEW; and GET_NEW is (I am using a Maildir mailbox format): #define GET_NEW ((MNMaildirMailboxBackend *)g_object_new(mn_maildir_mailbox_backend_get_type(), NULL)) So the g_object_new() fails, return NULL and mail-notification crashes. > P.S. if you are affected by this bug, you can probably download the > libgmime package from there and install it. Then use "aptitude hold > libgmime-2.0-2" to prevent it from being automatically upgraded on your > next upgrade run. I am not sure the problem is with libgmime-2.0-2. mail-notification compiled and executed with version 2.2.9 is fine. mail-notification compiled and executed with version 2.2.10 is fine. mail-notification compiled with version 2.2.9 and executed with version 2.2.10 crashes. It looks like an ABI incompatibility for libgmime-2.0-2 between 2.2.9 and 2.2.10. But I may be wrong. I propose to just rebuild mail-notification using a binNMU or something similar. bye -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --
