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=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#1064636: libpcsclite-dev: The i386 libpcsclite-dev 2.0.1-1+b1 package conflicts with the amd64 one
Le 25/02/2024 à 12:00, Francois Gouget a écrit : Package: libpcsclite-dev Version: 2.0.1-1+b1 Severity: normal Dear Maintainer, Hello, The 2.0.1-1+b1 version of the libpcsclite-dev broke multiarch support because the i386 /usr/share/man/man1/pcsc-spy.1.gz file differs from the amd64 one: $ zdiff -u amd64/share/man/man1/pcsc-spy.1.gz i386/share/man/man1/pcsc-spy.1.gz --- /dev/fd/5 2024-02-25 11:56:37.995245350 +0100 +++ - 2024-02-25 11:56:38.000871866 +0100 @@ -55,7 +55,7 @@ .\" .\" .IX Title "PCSC-SPY 1" -.TH PCSC-SPY 1 2024-02-23 "pcsc-lite 2.0.1" "PC/SC lite" +.TH PCSC-SPY 1 2024-02-22 "pcsc-lite 2.0.1" "PC/SC lite" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l Maybe the build was done around midnight causing this date change. Clearly it would be best to either not include the date in the man page, or to use a source for the date that ensures it will be the same for all builds of a given version (maybe take it from the latest changelog entry?). Fixed upstream in https://github.com/LudovicRousseau/PCSC/commit/e3bfa449df5283cd7389d505399cc57d2065e637 In the meantime this makes it impossible to install both the 32-bit and 64-bit libpcsclite-dev which hampers development of the Wayland support in Wine. Sorry for that. I do plan to release a new upstream version "soon". In the mean time you can use locally rebuild packages.
Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc
Hello,
Le 24/01/2024 à 22:07, Ludovic Rousseau a écrit :
Le 24/01/2024 à 19:43, Ludovic Rousseau a écrit :
Le 24/01/2024 à 18:09, Laurent Bigonville a écrit :
Package: pcscd
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Hello,
When looking at the logs of pcscd, I see the following messages:
jan 22 09:47:37 edoras pcscd[1663]: auth.c:125:IsClientAuthorized()
Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
Process not found
jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized()
Process 1565 (user: 115) is NOT authorized for action: access_pcsc
It seems that GDM is not allowed to talk to pcscd.
GDM has the functionality to detect whether there is a smartcard in the
reader and then use the gdm-smartcard PAM service instead of the
gdm-password one to perform login.
I guess that GDM should be whitelisted to allow it to use pcscd?
Exact.
Good point.
You can add polkit config file until I fix the issue.
https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/
The fix is quite easy.
Create a new file /etc/polkit-1/rules.d/03-polkit-pcscd.rules containing:
polkit.addRule(function(action, subject) {
if ((action.id == "org.debian.pcsc-lite.access_pcsc"
|| action.id == "org.debian.pcsc-lite.access_card")
&& subject.user == "Debian-gdm") {
return polkit.Result.YES;
}
});
What I don't know is if this new file should be provided by the pcscd package
or by the gdm3 package.
I would say gdm3 but I am not sure.
I started a discussion on the pcsclite-muscle list at
https://lists.infradead.org/pipermail/pcsclite-muscle/2024-January/001457.html
The problem is also present on Fedora 39.
It is surprising because Fedora has enabled polkit in pcsc-lite since a long
time (2014?)
I opened a ticket at gdm upstream
https://gitlab.gnome.org/GNOME/gdm/-/issues/904
I think the fix should be provided by gdm itself.
So I reassign this ticket to the Debian gdm package.
Bye
--
Dr. Ludovic Rousseau
Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc
Le 24/01/2024 à 19:43, Ludovic Rousseau a écrit :
Le 24/01/2024 à 18:09, Laurent Bigonville a écrit :
Package: pcscd
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Hello,
When looking at the logs of pcscd, I see the following messages:
jan 22 09:47:37 edoras pcscd[1663]: auth.c:125:IsClientAuthorized()
Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
Process not found
jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized()
Process 1565 (user: 115) is NOT authorized for action: access_pcsc
It seems that GDM is not allowed to talk to pcscd.
GDM has the functionality to detect whether there is a smartcard in the
reader and then use the gdm-smartcard PAM service instead of the
gdm-password one to perform login.
I guess that GDM should be whitelisted to allow it to use pcscd?
Exact.
Good point.
You can add polkit config file until I fix the issue.
https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/
The fix is quite easy.
Create a new file /etc/polkit-1/rules.d/03-polkit-pcscd.rules containing:
polkit.addRule(function(action, subject) {
if ((action.id == "org.debian.pcsc-lite.access_pcsc"
|| action.id == "org.debian.pcsc-lite.access_card")
&& subject.user == "Debian-gdm") {
return polkit.Result.YES;
}
});
What I don't know is if this new file should be provided by the pcscd package
or by the gdm3 package.
I would say gdm3 but I am not sure.
I started a discussion on the pcsclite-muscle list at
https://lists.infradead.org/pipermail/pcsclite-muscle/2024-January/001457.html
Bye
--
Dr. Ludovic Rousseau
Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc
Le 24/01/2024 à 18:09, Laurent Bigonville a écrit : Package: pcscd Version: 2.0.1-1 Severity: normal X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org Hello, When looking at the logs of pcscd, I see the following messages: jan 22 09:47:37 edoras pcscd[1663]: auth.c:125:IsClientAuthorized() Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Process not found jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() Process 1565 (user: 115) is NOT authorized for action: access_pcsc It seems that GDM is not allowed to talk to pcscd. GDM has the functionality to detect whether there is a smartcard in the reader and then use the gdm-smartcard PAM service instead of the gdm-password one to perform login. I guess that GDM should be whitelisted to allow it to use pcscd? Exact. Good point. You can add polkit config file until I fix the issue. https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/ Bye -- Dr. Ludovic Rousseau
Bug#1058770: globalplatform: establish_context failed with error 0x8010006A (Access denied.)
Le 16/12/2023 à 19:44, Simon Josefsson a écrit : Ludovic Rousseau writes: I am trying to find a long term solution in pcsc-lite. The idea is to start pcscd with polkit disabled. Thanks -- I was just experimenting with solutions based on /usr/share/polkit-1/rules.d/ after reading https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/ but I'm not able to get anything but PCSCD_ARGS=--disable-polkit to work. Do I need to restart something to get pcscd to re-read the polkit files? Yes. Use: "sudo systemctl restart pcscd.service" I can push this patch in salsa and close this bug if you want. Just tell me. Please open a merge request on Salsa and I will review, merge and do a new upload. Done. https://salsa.debian.org/auth-team/globalplatform/-/merge_requests/1 Bye -- Dr. Ludovic Rousseau
Bug#1058770: globalplatform: establish_context failed with error 0x8010006A (Access denied.)
On Fri, 15 Dec 2023 22:29:46 +0100 Ludovic Rousseau wrote: > Is it possible to modify the tests in globalplatform so that the error > 0x8010006A is NOT considered as a failure? No need to disable your tests. I found the solution. > I am trying to find a long term solution in pcsc-lite. The idea is to start pcscd with polkit disabled. In debian/tests/control you add (for both tests): Restrictions: needs-sudo In your test files cli and lib you add: # setup pcscd with NO polkit control to avoid " Access denied." errors echo "PCSCD_ARGS=--disable-polkit" | sudo tee /etc/default/pcscd sudo systemctl restart pcscd.service Proposed patch: diff --git a/debian/tests/cli b/debian/tests/cli index 298088b..1e19f2a 100755 --- a/debian/tests/cli +++ b/debian/tests/cli @@ -2,6 +2,10 @@ set -e +# setup pcscd with NO polkit control to avoid " Access denied." errors +echo "PCSCD_ARGS=--disable-polkit" | sudo tee /etc/default/pcscd +sudo systemctl restart pcscd.service + cat<
Bug#1058770: globalplatform: establish_context failed with error 0x8010006A (Access denied.)
Source: globalplatform Version: 2.3.1+dfsg-3 Severity: normal Dear Maintainer, The package has some autopkgtests in debian/tests/ that now fail with pcsc-lite 2.0.1. The tests in globalplatform create a regression and prevent pcsc-lite 2.0.1 to migrate from unstable to testing. For example see https://ci.debian.net/packages/g/globalplatform/testing/ppc64el/40915103/#S8 43s autopkgtest [04:47:35]: test cli: [--- 43s enable_trace 43s establish_context 43s establish_context failed with error 0x8010006A (Access denied.) 44s autopkgtest [04:47:36]: test cli: ---] 44s cli FAIL non-zero exit status 1 This is because pcsc-lite 2.0.1 now enables polkit by default. See https://blog.apdu.fr/posts/2023/11/new-version-of-pcsc-lite-201/ and https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/ It looks like the way the autopkgtest environment is set makes pcscd to consider the connection is not local. Since no user session is started polkit is not configured correctly. Is it possible to modify the tests in globalplatform so that the error 0x8010006A is NOT considered as a failure? I am trying to find a long term solution in pcsc-lite. Thanks -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1041344: AttributeError: module 'pyflakes.messages' has no attribute 'RedefinedInListComp'
Hello, I propose a fix in https://salsa.debian.org/python-team/packages/pylama/-/merge_requests/3
Bug#1041344: AttributeError: module 'pyflakes.messages' has no attribute 'RedefinedInListComp'
Package: pylama
Version: 7.4.3-5
Severity: important
Dear Maintainer,
I installed pylama and I get this error:
$ pylama
Traceback (most recent call last):
File "/usr/bin/pylama", line 33, in
sys.exit(load_entry_point('pylama==7.4.3', 'console_scripts', 'pylama')())
^^
File "/usr/bin/pylama", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/pylama/main.py", line 8, in
from .config import parse_options, CURDIR, setup_logger
File "/usr/lib/python3/dist-packages/pylama/config.py", line 12, in
from .lint.extensions import LINTERS
File "/usr/lib/python3/dist-packages/pylama/lint/extensions.py", line 26, in
from pylama.lint.pylama_pyflakes import Linter
File "/usr/lib/python3/dist-packages/pylama/lint/pylama_pyflakes.py", line
10, in
checker.messages.RedefinedInListComp.message = "W0621 list comprehension
redefines %r from line %r"
AttributeError: module 'pyflakes.messages' has no attribute
'RedefinedInListComp'
I see that the Debian version of the software is 7.4.3. This version was
released unstream in Sept 2017.
The current upstream version is 8.4.1 released in Aug 2022.
The current upstream file pylama/lint/pylama_pyflakes.py is very
different from
/usr/lib/python3/dist-packages/pylama/lint/pylama_pyflakes.py provided
by the Debian package.
Maybe it is time for a new upstream upload?
Do you need help for that?
I do not find that pylama is an orphaned Debian package.
Regards,
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pylama depends on:
ii python3 3.11.2-1+b1
ii python3-pylama 7.4.3-5
pylama recommends no packages.
pylama suggests no packages.
-- no debconf information
Bug#1039078: logcheck: Force LANG locale for journalctl to get date in English format
On Sun, 25 Jun 2023 16:47:59 +0100 Richard Lewis
wrote:
On Sun, 25 Jun 2023, 15:09 Ludovic Rousseau, wrote:
>
> It looks like journalctl now displays the month using the configured
> locale.
>
> Compare:
> # journalctl -t smartd -S "Jun 25 10:00:00"
> juin 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribu>
> juin 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribu>
>
> with:
> # LANG=C journalctl -t smartd -S "Jun 25 10:00:00"
> Jun 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribut>
> Jun 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
> Attribut
>
>
Thanks for the report and patch.
The patch sets LANG to C before running logcheck: i can see this is a
solution that will work in the short-term.
I think it should be C.UTF-8 instead of plain C?
I suspect it would also work to simply write LANG=C into
/etc/logcheck/logcheck.conf (untested)
I tried adding the line:
LANG=C.UTF-8
at the end of /etc/logcheck/logcheck.conf and it works also fine for me.
It is a better solution since I do not have to patch a script for the same
result.
Thanks for the suggestion.
In the long-term:
- I wonder if locale is something we should allow the user to customize
anyway?
- what if rsyslog starts doing something similar? we cant change its locale
as we work after it has written the log.
- hardcoding locale means you wont be able to manually match things
logcheck reports to what you see when running journalctl by hand, unless
you know to.manually change the locale i dont see a way round this :(
It was not easy to find the source of the problem because in in /var/log/syslog
the same log lines are:
2023-06-25T11:09:27.454813+02:00 zotac smartd[548]: Device: /dev/sda [SAT],
SMART Usage Attribute: 194 Temperature_Celsius changed from 33 to 34
2023-06-25T13:39:27.531540+02:00 zotac smartd[548]: Device: /dev/sda [SAT],
SMART Usage Attribute: 194 Temperature_Celsius changed from 34 to 35
Here the date does not include the month name (either Jun or juin).
But we should document that locale is fixed for journalctl (but not for
rsyslog!), and make the autopkgtests use a non-english locale as well to
help spot future issues.
My first patch was to change the \w{3} by \w+ in my personal rules. (for example in
"^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) ...")
But since the problem was also present in "official" rules provided by the
package it was not a good/practical solution.
I have no idea what the correct/best solution should be.
Bye
--
Dr. Ludovic Rousseau
Bug#1039078: logcheck: Force LANG locale for journalctl to get date in English format
Package: logcheck
Version: 1.4.2
Severity: normal
Tags: patch
Hello,
Since Debian Bookworm I get emails from logcheck because lines from
journalctl are no more ignored.
For example in the logcheck email I have:
juin 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage
Attribute: 194 Temperature_Celsius changed from 34 to 35
Note the first word of the line: "juin". It is the french word for June.
It looks like journalctl now displays the month using the configured
locale.
Compare:
# journalctl -t smartd -S "Jun 25 10:00:00"
juin 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage Attribu>
juin 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage Attribu>
with:
# LANG=C journalctl -t smartd -S "Jun 25 10:00:00"
Jun 25 11:09:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage Attribut>
Jun 25 13:39:27 zotac smartd[548]: Device: /dev/sda [SAT], SMART Usage Attribut
I have:
# cat /etc/default/locale
# File generated by update-locale
LANG="fr_FR.UTF-8"
The patch is easy and attached.
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages logcheck depends on:
ii adduser3.134
ii cron [cron-daemon] 3.0pl1-162
ii exim4-daemon-light [mail-transport-agent] 4.96-15
ii lockfile-progs 0.1.19
ii logtail1.4.2
ii mime-construct 1.12+really1.11-1
Versions of packages logcheck recommends:
ii logcheck-database 1.4.2
Versions of packages logcheck suggests:
ii rsyslog [system-log-daemon] 8.2302.0-1
-- Configuration Files:
/etc/logcheck/header.txt [Errno 13] Permission non accordée:
'/etc/logcheck/header.txt'
/etc/logcheck/logcheck.conf [Errno 13] Permission non accordée:
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission non accordée:
'/etc/logcheck/logcheck.logfiles'
/etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permission non
accordée: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles'
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permission non
accordée: '/etc/logcheck/logcheck.logfiles.d/syslog.logfiles'
-- no debconf information
--- /usr/sbin/logcheck.orig 2023-06-25 14:18:48.716846520 +0200
+++ /usr/sbin/logcheck 2023-06-25 14:19:02.501495257 +0200
@@ -508,7 +508,7 @@
offsettime="--since=-5h"
fi
debug "Running $JOURNALCTL
${JOURNALCTL_OPTS[*]} -q $offsettime"
- "$JOURNALCTL"
"${JOURNALCTL_OPTS[@]}" --quiet "$offsettime" \
+ LANG=C "$JOURNALCTL"
"${JOURNALCTL_OPTS[@]}" --quiet "$offsettime" \
>> "$TMPDIR/logoutput/$file" 2>&1 \
|| error "Could
not run journalctl or save output"
touch "$offsetfile"
Bug#1037294: Recommends: libapache2-mod-wsgi-py3 instead of libapache2-mod-wsgi
Package: linkchecker-web Version: 10.2.1-1 Severity: important Tags: patch Hello, linkchecker-web defines: Recommends: apache2 | httpd, libapache2-mod-wsgi | httpd-wsgi But libapache2-mod-wsgi is no more available in Debian and has been replaced by libapache2-mod-wsgi-py3 (since version 3.3-1 of mod-wsgi in 2010?) /etc/apache2/conf-available/linkchecker-web.conf contains: So if libapache2-mod-wsgi-py3 is not installed and enabled then the web page http://localhost/lconline/ returns: Not Found The requested URL was not found on this server. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linkchecker-web depends on: ii linkchecker 10.2.1-1 ii python3 3.11.2-1+b1 Versions of packages linkchecker-web recommends: ii apache2 [httpd] 2.4.57-2 pn libapache2-mod-wsgi | httpd-wsgi linkchecker-web suggests no packages. -- no debconf information
Bug#1037293: linkchecker-web: could not create plugin directory '/var/www/.local/share/linkchecker/plugins': 'Permission denied'
Package: linkchecker-web Version: 10.2.1-1 Severity: important Hello, Using the default apache2 configuration I get in /var/log/apache2/error.log: [Sat Jun 10 14:06:46.551803 2023] [wsgi:error] [pid 5730:tid 140547016611520] [client 127.0.0.1:35694] could not create plugin directory '/var/www/.local/share/linkchecker/plugins': PermissionError(13, 'Permission denied'), referer: http://localhost/lconline/lc_cgi.html I have not tried to fix this problem. I used the command line version instead. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linkchecker-web depends on: ii linkchecker 10.2.1-1 ii python3 3.11.2-1+b1 Versions of packages linkchecker-web recommends: ii apache2 [httpd] 2.4.57-2 pn libapache2-mod-wsgi | httpd-wsgi linkchecker-web suggests no packages. -- no debconf information
Bug#1035627: libpcsclite-dev: Multiarch doesn't work for libpcsclite-dev (needed by current wine git)
Le 08/05/2023 à 13:27, Patrick Hibbs a écrit : Hello, Yes, I have. That works for wine's 64bit build, but wine's 32bit build will not recognize it. I just installed a new Debian 11 (stable) system amd64 with multiarch for i386. I have no problem installing libpcsclite-dev for both amd64 and i386. $ LANG=C dpkg -l libpcsc* 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 libpcsclite-dev:amd64 1.9.1-1 amd64Middleware to access a smar> ii libpcsclite-dev:i386 1.9.1-1 i386 Middleware to access a smar> ii libpcsclite1:amd641.9.1-1 amd64Middleware to access a smar> ii libpcsclite1:i386 1.9.1-1 i386 Middleware to access a smar> I am also able to build a sample PC/SC code for i386 on this system: $ /usr/bin/i586-linux-gnu-gcc `pkg-config libpcsclite --cflags`sample.c `pkg-config libpcsclite --libs` -o sample $ file sample sample: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=435a71bbacb507f1e61c30ca3943da130490796c, for GNU/Linux 3.2.0, not stripped $ ldd sample linux-gate.so.1 (0xf7fa2000) libpcsclite.so.1 => /lib/i386-linux-gnu/libpcsclite.so.1 (0xf7f83000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d9b000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7d79000) /lib/ld-linux.so.2 (0xf7fa4000) I guess the problem is because libpcsclite-dev declares: Recommends: python3 Use: $ apt install --no-install-recommends libpcsclite-dev:i386 Bye -- Dr. Ludovic Rousseau
Bug#1034434: unblock: pcsc-lite/1.9.9-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pcsc-l...@packages.debian.org
Control: affects -1 + src:pcsc-lite
Please unblock package pcsc-lite
[ Reason ]
Version 1.9.9-2 fixes the RC bug #1034209
" pcscd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system "
[ Impact ]
The daemon may not start as expected if systemd files are in /usr/lib/
instead of /lib/
[ Tests ]
Manual tests on my system.
[ Risks ]
Low or inexistent.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
It is linked to #1031695
" dh_installsystemd doesn't handle files in /usr/lib/systemd/system "
unblock pcsc-lite/1.9.9-2
diff -Nru pcsc-lite-1.9.9/debian/changelog pcsc-lite-1.9.9/debian/changelog
--- pcsc-lite-1.9.9/debian/changelog2022-09-11 16:43:51.0 +0200
+++ pcsc-lite-1.9.9/debian/changelog2023-04-11 19:15:00.0 +0200
@@ -1,3 +1,11 @@
+pcsc-lite (1.9.9-2) unstable; urgency=medium
+
+ * Fix "dh_installsystemd doesn't handle files in
+/usr/lib/systemd/system" (Closes: #1034209)
+ * d/control: remove lsb-base dependency and fix lintian error
+
+ -- Ludovic Rousseau Tue, 11 Apr 2023 19:15:00 +0200
+
pcsc-lite (1.9.9-1) unstable; urgency=medium
* new upstream release
diff -Nru pcsc-lite-1.9.9/debian/control pcsc-lite-1.9.9/debian/control
--- pcsc-lite-1.9.9/debian/control 2022-09-11 16:43:51.0 +0200
+++ pcsc-lite-1.9.9/debian/control 2023-04-11 19:15:00.0 +0200
@@ -17,7 +17,7 @@
Package: pcscd
Architecture: any
-Depends: libccid | pcsc-ifd-handler, ${shlibs:Depends}, ${misc:Depends},
lsb-base, libpcsclite1 (= ${binary:Version})
+Depends: libccid | pcsc-ifd-handler, ${shlibs:Depends}, ${misc:Depends},
libpcsclite1 (= ${binary:Version})
Suggests: systemd
Multi-Arch: foreign
Pre-Depends: ${misc:Pre-Depends}
diff -Nru pcsc-lite-1.9.9/debian/pcscd.install
pcsc-lite-1.9.9/debian/pcscd.install
--- pcsc-lite-1.9.9/debian/pcscd.install2022-09-11 16:43:51.0
+0200
+++ pcsc-lite-1.9.9/debian/pcscd.install2023-04-11 19:15:00.0
+0200
@@ -1,3 +1,3 @@
usr/sbin/pcscd
-usr/lib/systemd/system/pcscd.socket
-usr/lib/systemd/system/pcscd.service
+lib/systemd/system/pcscd.socket
+lib/systemd/system/pcscd.service
diff -Nru pcsc-lite-1.9.9/debian/rules pcsc-lite-1.9.9/debian/rules
--- pcsc-lite-1.9.9/debian/rules2022-09-11 16:43:51.0 +0200
+++ pcsc-lite-1.9.9/debian/rules2023-04-11 19:15:00.0 +0200
@@ -12,7 +12,7 @@
override_dh_auto_configure:
dh_auto_configure -- $(EXTRA_CONFIGURE_ARGS) \
- --with-systemdsystemunitdir=/usr/lib/systemd/system \
+ --with-systemdsystemunitdir=/lib/systemd/system \
--enable-usbdropdir=/usr/lib/pcsc/drivers \
--enable-ipcdir=/run/pcscd \
$(shell dpkg-buildflags --export=configure)
Bug#1034397: yubikey-agent: New upstream available: v0.1.6
Package: yubikey-agent Version: 0.1.4-2+b7 Severity: wishlist A new upstream version 0.1.6 is available since December 2022. Version 0.1.4 was released from April 2021 (2 years ago). I need the new upstream version because it allows to use a yubikey on a laptop with an internal smart card reader. See https://github.com/FiloSottile/yubikey-agent/pull/130 -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yubikey-agent depends on: ii init-system-helpers 1.65.2 ii libc62.36-8 ii libpcsclite1 1.9.9-1 yubikey-agent recommends no packages. yubikey-agent suggests no packages. -- no debconf information
Bug#914035: Adopt influxdb (and friends) packages
Le 29/12/2022 à 18:21, Ludovic Rousseau a écrit : Le 16/11/2022 à 22:56, Ludovic Rousseau a écrit : I am *completely* new to Go. So maybe this error is easy to fix. Before I adopt influxdb I would need some help from knowledgeable people :-) Can you help me? After some tries and the help of the Go packaging team [1] I was able to rebuild version 1.6 (current version in Debian). I then tried to upgrade to version 1.8.10 (or even version 2.6.0) but I have Go errors. I am not ready to invest a huge amount of time into learning Go. I give up trying to package influxdb. In case it can be used, my current patches are available at https://salsa.debian.org/rousseau/influxdb Bye -- Dr. Ludovic Rousseau
Bug#914035: Adopt influxdb (and friends) packages
Le 16/11/2022 à 22:56, Ludovic Rousseau a écrit : I am *completely* new to Go. So maybe this error is easy to fix. Before I adopt influxdb I would need some help from knowledgeable people :-) Can you help me? After some tries and the help of the Go packaging team [1] I was able to rebuild version 1.6 (current version in Debian). I then tried to upgrade to version 1.8.10 (or even version 2.6.0) but I have Go errors. I am not ready to invest a huge amount of time into learning Go. I give up trying to package influxdb. The package is still available for adoption. Bye [1] https://lists.debian.org/debian-go/2022/11/msg00052.html -- Dr. Ludovic Rousseau
Bug#1024770: libpcsclite1: multi-arch installation not possible
Hello, Le 24/11/2022 à 16:07, Stephan Brunner a écrit : Package: libpcsclite1 Version: 1.9.1-1 Severity: minor When trying to install libpcsclite-dev, and therefore libpcsclite1, via multi-arch (host is x86-64), e.g. apt install libpcsclite-dev libpcsclite-dev:arm64 , the installation would break the system. See the output below. I wanted to install this package to my build host, which does cross compilation for some architectures in an CI environment. I am using Debian 11 on x86-64. Latest updates installed as of 2022-11-24. Example output of the apt install example above: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: distro-info-data iso-codes libffi-dev libmpdec3 libncurses-dev libpfm4 libpython3-stdlib libpython3.9-minimal libpython3.9-stdlib libtinfo-dev libz3-dev llvm-11 llvm-11-runtime lsb-release python-apt-common python3-certifi python3-chardet python3-debconf python3-debian python3-httplib2 python3-idna python3-pkg-resources python3-pygments python3-requests python3-six python3-urllib3 Use 'apt autoremove' to remove them. The following additional packages will be installed: libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9- minimal:arm64 libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64 uuid-runtime zlib1g:arm64 Suggested packages: gpm:arm64 pcscd:arm64 python3-doc:arm64 python3-tk:arm64 python3-venv:arm64 python3.9-venv:arm64 python3.9-doc:arm64 binutils:arm64 The following packages will be REMOVED: apt-listchanges llvm-11-dev llvm-11-tools python3 python3-apt python3-debianbts python3-minimal python3-pycurl python3-pysimplesoap python3-reportbug python3-yaml python3.9 python3.9-minimal reportbug The following NEW packages will be installed: libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 libpcsclite-dev:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9-minimal:arm64 libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64 uuid-runtime zlib1g:arm64 0 upgraded, 24 newly installed, 14 to remove and 0 not upgraded. Need to get 8,185 kB of archives. After this operation, 202 MB disk space will be freed. Do you want to continue? [Y/n] ^C libpcsclite-dev includes a Python 3 script: pcsc-spy. Hence the dependency on python3. Since it is a Recommends: and not a Depends: you should be able to install libpcsclite-dev:arm64 even if the dependency is not satisfied. But you will then have another problem since libpcsclite-dev and libpcsclite-dev:arm64 will both try to install the same files: /usr/bin/pcsc-spy /usr/include/PCSC/debuglog.h /usr/include/PCSC/ifdhandler.h /usr/include/PCSC/pcsclite.h /usr/include/PCSC/reader.h /usr/include/PCSC/winscard.h /usr/include/PCSC/wintypes.h /usr/share/man/man1/pcsc-spy.1.gz How do you propose to fix that? Bye -- Dr. Ludovic Rousseau
Bug#914035: Adopt influxdb (and friends) packages
Hello Alexandre and the Go packaging team, I am a Debian Developer and I use influxdb. I see that influxdb is available for adoption: #914035 Some of it's Build-Depends packages are also available for adoption. But I can't find the list of these packages. My current problem is that I am not able to rebuild influxdb from the source code in salsa at https://salsa.debian.org/go-team/packages/influxdb I already fixed a Build-Depends package name change in https://salsa.debian.org/rousseau/influxdb/-/commit/10ba6177d2b58754fbedf1e58edfd8584d009df9 But if I build the package using: gbp buildpackage I get the error: src/github.com/influxdata/influxdb/models/points.go:19:2: cannot find package "github.com/influxdata/platform/models" in any of: /usr/lib/go-1.19/src/github.com/influxdata/platform/models (from $GOROOT) /build/influxdb-1.7.0/_build/src/github.com/influxdata/platform/models (from $GOPATH) src/github.com/influxdata/influxdb/cmd/influx/cli/flux.go:6:2: cannot find package "github.com/influxdata/flux" in any of: /usr/lib/go-1.19/src/github.com/influxdata/flux (from $GOROOT) /build/influxdb-1.7.0/_build/src/github.com/influxdata/flux (from $GOPATH) src/github.com/influxdata/influxdb/cmd/influx/cli/flux.go:7:2: cannot find package "github.com/influxdata/flux/csv" in any of: /usr/lib/go-1.19/src/github.com/influxdata/flux/csv (from $GOROOT) /build/influxdb-1.7.0/_build/src/github.com/influxdata/flux/csv (from $GOPATH) [...] The complete build log is available at https://people.debian.org/~rousseau/influxdb_build.log I am *completely* new to Go. So maybe this error is easy to fix. Before I adopt influxdb I would need some help from knowledgeable people :-) Can you help me? Thanks -- Dr. Ludovic Rousseau
Bug#1020649: 0ad: New upstream release - version 0.0.26
On Sat, 24 Sep 2022 14:53:32 -0500 "David W. Kennedy" wrote: Package: 0ad Version: 0.0.25b-2+b2 Severity: wishlist Dear Maintainer, Hello, Version 0.0.26 of 0ad was just released. New Features in version 0.0.26. * A new civilization: The Han. * New campaign maps: Tarim basin and Yangtze. * Now units have acceleration. * Twenty-six new music tracks. * New and updated art. * Bug fixes for newer hardware * More improvements. Source is available at https://play0ad.com/download/source/ Build instructions are available at https://trac.wildfiregames.com/wiki/BuildInstructions I am on it. The build works fine (on AMD64). Then I get an error during the auto tests: [...] # Note: Avoid running tests from root dir of build, otherwise certain # tests (i.e. in testsuite MeshManager) may not work as intended and # create spurious directories above root dir (../data/mods). cd binaries/system/ && LD_LIBRARY_PATH=. ./test -libdir . Running cxxtest tests (391 tests)...Skipping map generator tests (can't find binaries/data/mods/public/maps/random/tests/) . In TestCGUIText::test_regression_rP26522: ./source/gui/tests/test_CGUIText.h:319: Error: Expected ((g_VFS->Mount(L"", DataDir() / "mods" / "mod" / "", VFS_MOUNT_MUST_EXIST)) == INFO::OK), found (-110100 != 0) ERROR: Failed to open font file fonts/sans-bold-13.fnt ERROR: Failed to open font file fonts/sans-10.fnt ./source/gui/tests/test_CGUIText.h:332: Error: Expected (text.GetSize().Height == 14 + 9 + 8 * 2), found (22. != 39) .Skipping globalscripts tests (can't find binaries/data/mods/public/globalscripts/tests/) .Skipping component scripts tests (can't find binaries/data/mods/public/simulation/components/tests/setup.js) Failed 1 and Skipped 0 of 391 tests Success rate: 99% make[1]: *** [debian/rules:51: override_dh_auto_test] Error 1 The complete log is available at https://people.debian.org/~rousseau/0ad_0.0.26-1_amd64.build I am in contact with upstream to solve the problem. Bye -- Dr. Ludovic Rousseau
Bug#1020381: RFP: jpilot -- GUI app to view & edit your old Palm device's data
Le 20/09/2022 à 21:20, unforgettableid a écrit : Package: wnpp Severity: wishlist X-Debbugs-CC: rouss...@debian.org * Package name: jpilot Version : 2.0.1 Upstream Author : multiple authors * URL : http://www.jpilot.org/ * License : GPLv2 Programming Lang: GTK+ Description : GUI app to view & edit your old Palm device's data jpilot was part of Debian until a few years ago. It was removed from unstable at the request of then-maintainer Ludovic Rousseau, back when upstream maintenance had slowed and/or stopped. (Please see: https://bugs.debian.org/938958). jpilot is now maintained upstream again, in a non-default branch of its official GitHub repository. The newest version is 2.0.1, which now supports GTK+ 3. I myself, as well as some other people, still use old Palm OS devices. It would be good if you could please package jpilot again, so that we can enjoy the high-quality packages which the Debian developers are known to produce. jpilot depends on pilot-link, which is now maintained at <https://github.com/desrod/pilot-link>. pilot-link was removed from Debian a few years ago as well (https://bugs.debian.org/938957). pilot-link is mature and stable, but please expect at least one bug fix every few years. The pilot-link Readme file is very outdated; I've recently submitted a pull request which fixes that. Thank you for reading this! The Debian files are still available https://sources.debian.org/src/jpilot/ (latest update in 2017) https://sources.debian.org/src/pilot-link/ (latest update in 2015) Maybe I have the CVS (or SVN?) repository somewhere, but I am not sure. If someone is interested I can have a look. Bye -- Dr. Ludovic Rousseau
Bug#1019322: pcscd: Prints warnings due to obsolescent egrep usage
Le 07/09/2022 à 12:34, Guillem Jover a écrit : Package: pcscd Version: 1.9.8-1 Severity: normal Hi! With the recent grep 2.8 release, egrep usage, which has been slated for removal for a long time, now generates warnings, such as: egrep: warning: egrep is obsolescent; using grep -E When checking the /etc on my systems, I noticed pcscd uses egrep at least on its init script (checking the source seems that's the only relevant instance). Fixed in https://salsa.debian.org/debian/pcsc-lite/-/commit/9759a1c84b5639e3a15bc972f19e79e1b773abf1 I will try to release and push a new upstream release soon. Thanks -- 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=mips64el=0.10.52-2=1656999642=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#920596: new upstream influxdb
Hello, On Sat, 11 Sep 2021 11:34:02 +0200 Daniel Baumann wrote: > any progress on this? influxdb is seriously outdated in debian now.. influxdb package is available for adoption since Nov 2018. See #914035 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914035 So I am not surprised there is no activity here. I use influxdb myself but am not a expert in Go (the language). So I may not be very useful. The packaging is available at https://salsa.debian.org/go-team/packages/influxdb
Bug#1008778: pcscd: Conflict between Yubikey and Firefox around pcscd
Le 01/04/2022 à 14:25, Yadd a écrit : Hi, Hello, problem description: * Env: * I'm using a Yubikey to store my GPG key * I'm using a certificate to access to tracker.debian.org * I'm running a Debian testing without local changes * User-Story: * when I alternately access TDO and use my YB, the pcscd process hangs, consumes a lot of CPU and blocks Firefox. As soon as I kill the pcscd process, Firefox starts working again Maybe you have a conflict between GnuPG and pcscd. See https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html Tell me if that fixed your issue. Bye -- Dr. Ludovic Rousseau
Bug#1006614: libccid: support for Solo2 and Nitrokey 3
Le 28/02/2022 à 18:25, Dave Love a écrit : Package: libccid Version: 1.4.34-1~solo2+1 Severity: wishlist X-Debbugs-Cc: none, Dave Love Hello Dave, Various functions of the new free software/hardware Solo 2 security key don't work in Debian 11 because libccid doesn't support it. The same probably goes for the Nitrokey 3 when it's available as it shares basic firmware. It seems worth supporting them since they're free devices, either by backporting from unstable or patching the version in stable. I don't know which is the best solution (or whether patching for extra support is within policy), but I've tried both with success. I built 1.5 from unstable on buster and bullseye (lowering the debhelper version so it would also work on 10, and also Ubuntu 18.04 and 20.04). Installing it solves at least that part of problems with the solo2 cli. Then I tried the version from bullseye plus the /etc/libccid_Info.plist from 1.5, which works; I'll probably post it for Solo 2 users. As that worked I rebuilt the bullseye version with a patch for readers/supported_readers.txt to add Solo2 and Nitrokey entries, though I guess it could have all the additions from the 1.5 version. The results are under <https://build.opensuse.org/repositories/home:fx>. Obviously I can send a patch if that's helpful. I can't fix or upgrade packages in Debian stable, unless that is a security issue. What you can do instead is backport the libccid package from unstable to stable. That is what you did. This is also handled by the Debian backports project https://backports.debian.org/ Feel free to provide backported versions on your own web site if you want. For the libccid package in Debian unstable, support of the Nitrokey 3 and SoloKeys Solo 2 is already included https://ccid.apdu.fr/ccid/shouldwork.html#0x20A00x42B2 https://ccid.apdu.fr/ccid/shouldwork.html#0x12090xBEEE So I have nothing to fix in Debian unstable. I plan to close this bug report unless you think I can do something. Bye -- Dr. Ludovic Rousseau
Bug#1005939: libccid: invoke-rc.d pcscd restart might fail in postinst
Le 18/02/2022 à 11:46, Uwe Kleine-König a écrit : Hello Ludovic, On 2/18/22 10:47, Ludovic Rousseau wrote: Why do you install pcscd if you mask it? What is your use case? I have pcscd since I installed yubikey-manager. I masked pcscd because it sometimes interfered with yubikey usage. I don't remember the exact details, it's some time ago already. I guess you have problems with GnuPG. See https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html Bye -- Dr. Ludovic Rousseau
Bug#1005939: libccid: invoke-rc.d pcscd restart might fail in postinst
Le 17/02/2022 à 16:33, Uwe Kleine-König a écrit : Package: libccid Version: 1.5.0-1 Severity: important Hello, Hello Uwe, I currently encounter: uwe@taurus:~$ sudo apt install Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 626 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up libccid (1.5.0-1) ... Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) dpkg: error processing package libccid (--configure): installed libccid package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: libccid E: Sub-process /usr/bin/dpkg returned an error code (1) This is similar to #1001155, but a bit more hairy to fix, because libccid restarts a service that isn't "owned" by the package. I think the fix is to not restart pcscd when libccid is updated. Other libs also don't care for their consumers and it's a well-known (to me at least) duty to check for binaries using old versions of an updated lib after a package update. I restart pcscd so that the list of supported smart card readers is reloaded by pcscd. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995814#15 Why do you install pcscd if you mask it? What is your use case? (Side note: libccid doesn't even transitively depend on pcscd, so I can even make libccid's postinst fail with: invoke-rc.d: unknown initscript, /etc/init.d/pcscd not found. Yeah. Good point. Thanks -- Dr. Ludovic Rousseau
Bug#1005306: fuse: failed to exec fusermount3: No such file or directory
Package: flatpak-builder Version: 1.2.2-2 Severity: normal Hello, I think the package should Depends: on fuse3. If fuse3 is not installed I get an error when using the Hello World example: $ flatpak-builder --force-clean build-dir org.flatpak.Hello.yml Emptying app dir 'build-dir' Downloading sources Starting build of org.flatpak.Hello Cache miss, checking out last cache hit fuse: failed to exec fusermount3: No such file or directory Building module hello in /home/rousseau/Documents/flatpak/test1/.flatpak-builder/build/hello-2 Running: install -D hello.sh /app/bin/hello.sh error: Build directory /home/rousseau/Documents/flatpak/test1/.flatpak-builder/rofiles/rofiles-l2iLXI not initialized, use flatpak build-init Error: module hello: Le processus fils s’est terminé avec le code 1 After I installed fuse3 I get no error: $ flatpak-builder --force-clean build-dir org.flatpak.Hello.yml Emptying app dir 'build-dir' Downloading sources Starting build of org.flatpak.Hello Cache miss, checking out last cache hit Building module hello in /home/rousseau/Documents/flatpak/test1/.flatpak-builder/build/hello-3 Running: install -D hello.sh /app/bin/hello.sh Committing stage build-hello to cache Cleaning up Committing stage cleanup to cache Finishing app Please review the exported files and the metadata Committing stage finish to cache Pruning cache -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flatpak-builder depends on: ii debugedit 1:5.0-4 ii flatpak 1.12.4-1 ii gir1.2-flatpak-1.0 1.12.4-1 ii libc6 2.33-5 ii libcurl3-gnutls 7.81.0-1 ii libelf1 0.186-1 ii libglib2.0-02.70.3-1 ii libjson-glib-1.0-0 1.6.6-1 ii libostree-1-1 2022.1-3+b1 ii libsoup2.4-12.74.2-3 ii libxml2 2.9.12+dfsg-5+b1 ii libyaml-0-2 0.2.2-1 ii ostree 2022.1-3+b1 Versions of packages flatpak-builder recommends: ii binutils 2.37.90.20220207-1 ii elfutils 0.186-1 ii git 1:2.34.1-1 ii patch 2.7.6-7 ii unzip 6.0-26 ii xz-utils 5.2.5-2 ii zstd 1.4.8+dfsg-3 Versions of packages flatpak-builder suggests: pn brz ii p7zip-full 16.02+dfsg-8 ii subversion 1.14.1-3+b2 -- no debconf information
Bug#1004297: libpcsclite1: SCardConnect is blocking but not cancellable
Hello Ievgenii, Le 24/01/2022 à 15:12, Ievgenii Meshcheriakov a écrit : Package: libpcsclite1 Version: 1.9.5-1 Severity: normal X-Debbugs-Cc: eu...@debian.org ScardConnect() call is blocking when another process has started a transaction on the same card, but it is impossible to cancel it using SCardCancel(). This makes it harder to use the library reliably in an asynchronous manner. I'm attaching source code that demonstrates the problem. After building it run 'cardlock' executable followed by 'cardlock_cancel' in a different terminal. A card should be in the used card reader. Both executables accept reader ID as arguments. My expectation is that 'cardlock_cancel' could exit after 5 second sleep, but it does not. This problem is not Debian specific. Please follow the discussion on the MUSCLE list https://lists.infradead.org/pipermail/pcsclite-muscle/2022-January/001233.html If you really want to open a ticket please open it upstream at salsa or github https://salsa.debian.org/rousseau/PCSC/-/issues https://github.com/LudovicRousseau/PCSC/issues Bye -- Dr. Ludovic Rousseau
Bug#1004127: libguestfs-tools: Typo in package description: libguestfs-teest-tool
Package: libguestfs-tools Version: 1:1.44.2-1.1 Severity: minor Dear Maintainer, The package description mentions "libguestfs-teest-tool". It should be "libguestfs-test-tool" in fact. Remove the duplicate "e" in "teest" Thanks -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libguestfs-tools depends on: ii curl 7.81.0-1 ii libc6 2.33-2 ii libconfig9 1.5-0.4 ii libcrypt1 1:4.4.27-1 ii libfuse2 2.9.9-5 ii libguestfs-perl1:1.44.2-1.1 ii libguestfs01:1.44.2-1.1 ii libintl-perl 1.26-3 ii libjansson42.13.1-1.1 ii liblzma5 5.2.5-2 ii libpcre2-8-0 10.39-3 ii libreadline8 8.1.2-1 ii libstring-shellquote-perl 1.04-1 ii libsys-virt-perl 7.10.0-1 ii libtinfo6 6.3-1 ii libtirpc3 1.3.2-2 ii libvirt0 7.10.0-3 ii libwin-hivex-perl 1.3.21-1+b2 ii libxml22.9.12+dfsg-5+b1 Versions of packages libguestfs-tools recommends: ii gnupg 2.2.27-3 ii virt-p2v 1.42.0-4 libguestfs-tools suggests no packages. -- no debconf information
Bug#985489: 0ad freezes with 0.0.24b1
Hello, On Sat, 3 Apr 2021 11:55:33 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: > Dear Maintainer, > I tried to have a look at this savegame and when loaded > shows these freezes to me too. > > An attached gdb shows that leaving VertexPathfinder::ComputeShortPath > takes some minutes, while the game is frozen. > > Upstream might have already some optimizations > for this issue in [1]. Is the problem still present in version 0.0.25b? Regards,
Bug#1001155: Fails to update when service is masked
On Mon, 20 Dec 2021 23:21:39 +0100 =?utf-8?q?Uwe_Kleine-K=C3=B6nig?=
wrote:
Hello,
Hello Uwe,
I just encountered the same problem. Digging into it (and before having
found this bug in the BTS) I saw the postinst script of pcscd restarts
the daemon twice. Once explicitly in debian/pcscd.postinst:
case "$1" in
configure|reconfigure)
# restart pcscd (PCSC daemon)
invoke-rc.d pcscd restart
;;
and again later added by dh_installinit/13.5.2:
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ]
|| [ "$1" = "abort-remove" ] ; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/etc/init.d/pcscd" ]; then
update-rc.d pcscd defaults >/dev/null
invoke-rc.d --skip-systemd-native pcscd restart || exit
1
fi
fi
I added the first "restart" by hand in
https://salsa.debian.org/debian/pcsc-lite/-/commit/9bf51b9f1bd362dfce3fb6976aa2ce520487a433
to fix #995814
The second "restart" call is added by dh_installinit as you noted.
My fix is not correct. pcscd WAS already restarted on install or
upgrade. I had not checked myself what Philipp wrote in #995814.
Thanks for the notice.
Even if you consider it a bug to mask pcscd.socket but not pcscd.service
(I disagree BTW), I still ask you to remove the explicit call to
invoke-rc.d pcscd restart, as the snippet added by dh_installinit should
serve the same purpose and this doesn't fail with pcscd.socket masked.
Done in
https://salsa.debian.org/debian/pcsc-lite/-/commit/935e0eaeaa02fdd1bef30c6f1a93db571a027fbb
The latter invocation of invoke-rc.d is also better as it honors policy
9.3.3 "Maintainer scripts for packages including init scripts must use
update-rc.d [...]." So keeping the status quo might even justify a
serious severity for this bug.
(Note: There is one relevant difference, where I'm unsure if the snippet
added by dh_installinit is better: The explicit call also triggers for
$1 == reconfigure.)
It should not be a problem to NOT restart pcscd in case of "reconfigure"
because the same pcscd binary was already present. A restart is not
needed in this case.
Thanks for your comments.
Bye
Bug#1001155: Fails to update when service is masked
Le 11/12/2021 à 16:36, Yuri D'Elia a écrit : On Sat, Dec 11 2021, Ludovic Rousseau wrote: What do you get if you run "sudo invoke-rc.d pcscd restart"? # invoke-rc.d pcscd restart Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) but I just noticed reading now the error above I effectively masked the socket without masking the service :/ If you mask both the socket and the service (or just the service) then you do not have any problem. Exact? If yes, may I close this bug report? My bad. No problem. I had to install pcscd to use a smart-card reader once in a while, however I noticed that having pcscd running and/or starting anything using pkcs11 was taking _seconds_. I didn't want to remove the service, however I probably disabled socket by tabbing one-too-many times. You may want to discuss this performance issue on the MUSCLE mailing list https://lists.infradead.org/mailman/listinfo/pcsclite-muscle Bye -- Dr. Ludovic Rousseau
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Hello Paride, Do you still have the problem with pcsc-lite 1.9.5? Regards, On Mon, 6 Apr 2020 12:47:27 +0200 Paride Legovini wrote: Ludovic Rousseau wrote on 06/04/2020: > Le 05/04/2020 à 16:40, Paride Legovini a écrit : >> Hello Ludovic, >> >> On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau >> wrote: > >>> When it fails: >>> - is the socket /var/run/pcscd/pcscd.comm still present? >> >> This was a hint in the right direction and I think it makes most of the >> logs I collected useless. Apparently when the problem occurs the >> /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still >> have a file descriptor open for it, as I found out using lsof: >> >> COMMAND PID TID TASKCMD USER FD TYPE DEVICE >> SIZE/OFF NODE NAME >> systemd 1 root 45u unix 0xa066a5154400 >> 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM >> >> I think the systemd socket unit (pcscd.socket) does not recreate the >> socket because of this, and passes a "dead" file descriptor to pcscd. >> What exactly deletes the pcscd.comm socket is not clear to me. Now after >> fiddling with pcscd I don't think I have clean logs to provide, I prefer >> to wait for the problem to happen again and then check if anything >> relevant is logged. I did try to suspend/resume a few times but but I >> didn't manage to reproduce the issue. But maybe you know what could be >> deleting the socket. > > pcscd can remove the /var/run/pcscd/pcscd.comm socket but only when NOT > started by systemd. This is done on init and exit of pcscd. > When pcscd is started by systemd you have a log message like: > Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() > Started by systemd > > Maybe, sometimes, pcscd does not detect it is started by systemd. But in > this case the socket should be re-created by pcscd so that should not be > the correct explanation. > > Or maybe the problem is on the systemd side? > > You can continue generating logs. They are a good indication of what is > happening. > You can limit logs to the info level using --info instead of --debug. > You can also remove the --apdu argument. > > If I read correctly your previous message you have logs with: > - pcscd is started by systemd > - pcscd correctly indicates "Started by systemd" > - but the communication is broken (pcsc_scan fails) and I guess the file > /var/run/pcscd/pcscd.comm is missing > - you stop pcscd: systemctl stop pcscd > - you start pcscd: systemctl start pcscd > - pcscd correctly indicates "Started by systemd" > - the communication is still broken and, I guess, the file > /var/run/pcscd/pcscd.comm is still missing All correct, this fits what I observe and I think it is what is happening, but before digging more I want to collect some cleaner logs, just to be sure. While trying to debug this I tried different things, -- Dr. Ludovic Rousseau
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Hello Nicolas, Do you still have the problem with pcsc-lite 1.9.5? Thanks On Wed, 05 Sep 2018 16:34:18 +0200 Nicolas Braud-Santoni wrote: Package: pcscd Version: 1.8.23-3 Severity: normal Hi, pcscd fails to detect my Yubikey 4 Nano when resuming from suspend-to-disk, resulting in GnuPG prompting me to insert the device; the problem persists even if I unplug and replug the device, and until I restart pcscd. I found a work-around, which is simply to make systemd stop pcscd upon resuming from suspend (it's unnecessary to restart it, as it is a socket-activated service): > #!/bin/sh -e > # Executable script in /lib/systemd/system-sleep/pcscd.sh > > if [ "$1" = "post" ]; then > logger -t systemd-sleep "Shutting down pcscd after resuming from suspend." > exec systemctl stop pcscd.service > fi Best, nicoo -- Dr. Ludovic Rousseau
Bug#905630: SCardConnect sometimes hangs
Hello Wouter, Can you reproduce the problem using pcsc-lite 1.9.5? I fixed some bugs since pcsc-lite 1.8.23 you used. Thanks On Wed, 29 Aug 2018 19:05:58 +0200 Wouter Verhelst wrote: Hi Ludovic, On Wed, Aug 29, 2018 at 04:11:14PM +0200, Ludovic Rousseau wrote: > Le 07/08/2018 à 13:24, Wouter Verhelst a écrit : > > I'm not sure where this is coming from, but would be happy to perform > > any required debugging steps. > > Thanks Wouter for the bug report. > > I have some questions: > - do you also have the problem if you use only 1 reader instead of 3 > (so if you do _not_ use vsmartcard) I haven't tried this in a while, but I'll try to do so tomorrow and will let you know. > - do you start the second instance of the program immediately after > the first run? or you can run the second instance 1 second after the > first and still get the problem? I started the two instances of that program in two different terminal windows, manually. I don't know *exactly* how much time there was between both instances, but typing "./test", move mouse to other terminal, and typing again "./test" does take more than a fraction of a second; so whatever the problem may be does not require that things are changed *immediately*. > I can reproduce the behaviour you get by removing/commenting the line > 288 at > https://salsa.debian.org/rousseau/PCSC/blob/master/src/winscard.c#L288 > I am suspecting a race condition issue somewhere. But I have no idea > how to reproduce it. I don't think it is a race. Instead, I suspect some internal state corruption. Once the problem occurs once, it is easy to reproduce, but only until I restart pcscd; then I have to play with stuff again until I somehow trigger the magic incantation which makes it reappear. > What could help is to get pcscd logs when the problem occurs. But I > understand it is not easy if you don't know how to reproduce the > problem. > https://pcsclite.apdu.fr/#support I'll try anyway. -- Dr. Ludovic Rousseau
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Hello Luke, On Sat, 21 Apr 2018 17:54:54 +0200 Ludovic Rousseau wrote: Le 17/04/2018 à 21:09, Ludovic Rousseau a écrit : > I should receive a Yubikey 4 (USB-C) in the next few days. It will be much simpler for me to debug. > I may ask you to test some patches. Good news: I received the Yubikey 4 (USB-C). But I can't reproduce your problem. Removing the reader does generate just the expected logs. I am also using Linux 4.15.0-2-amd64 and libudev 238. [...] I suggest to search for a firmware update from Dell. Maybe the USB-C is (partly) bogus on your mother board. For example I found a BIOS update on Dell web site: Dell XPS 13 9360 System BIOS Importance: Urgent Version: 2.6.2 ,2.6.2 Older versions Release Date: 22 Mar 2018 File Name: XPS_9360_2.6.2.exe File size: 10.69 MB Description: XPS 13 9360 2.6.2 BIOS Tell me if a BIOS upgrade fixes the problem. Any news or fix with the BIOS upgrade? I would like to close this bug report. Thanks -- Dr. Ludovic Rousseau
Bug#720277: [pcscd]
Hello Marco, I can't reproduce the problem. Maybe the problem is fixed in newer version of pcscd or drivers. I close this issue. Thanks On Fri, 30 Aug 2013 20:52:58 +0200 Ludovic Rousseau wrote: 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 -- Dr. Ludovic Rousseau
Bug#459827: pcscd: flood syslog as soon as a PCMCIA card is removed
Hello Luca, I still have no solution for your bug report. I guess PCMCIA laptops and readers are now very rare. GemPC Express readers (like the Gemalto GemPC Express) are much more easier to use than PCMCIA readers since they are seen as USB instead of serial readers. https://ccid.apdu.fr/ccid/shouldwork.html#0x08E60x34EC I do not plan to work on this bug and would like to close it. Is it OK for you? Bye On Wed, 09 Jan 2008 00:01:25 +0100 Luca Capello wrote: Package: pcscd Version: 1.4.4-3 Severity: normal Hello, I've a IBM/Lenovo ThinkPad X60s, which has only one PCMCIA slot. My Gemplus GemPC card reader works flawlessy with libccid/pcscd, but as soon as the card is removed, /var/log/syslog is flooded: = Jan 8 23:38:07 localhost vmunix: pccard: PCMCIA card inserted into slot 0 Jan 8 23:38:07 localhost vmunix: pcmcia: registering new device pcmcia0.0 Jan 8 23:38:07 localhost vmunix: 0.0: ttyS0 at I/O 0x3f8 (irq = 16) is a 16450 Jan 8 23:38:15 localhost pcscd: readerfactory.c:1113:RFInitializeReader() \ Attempting startup of GemPCTwin serial 00 00 using /usr/lib/pcsc/drivers/serial/libccidtwin.so Jan 8 23:38:15 localhost pcscd: readerfactory.c:980:RFBindFunctions() Loading IFD Handler 3.0 Jan 8 23:38:15 localhost pcscd: ifdhandler.c:1239:init_driver() LogLevel: 0x0003 Jan 8 23:38:15 localhost pcscd: ifdhandler.c:1249:init_driver() DriverOptions: 0x Jan 8 23:38:15 localhost pcscd: ifdhandler.c:77:IFDHCreateChannelByName() \ lun: 0, device: /dev/ttyS0:GemPCTwin Jan 8 23:38:15 localhost pcscd: ccid_serial.c:727:OpenSerialByName() \ Set serial port baudrate to 115200 and correct configuration Jan 8 23:38:15 localhost pcscd: ccid_serial.c:759:OpenSerialByName() Firmware: GemTwin-V2.10-GB01 Jan 8 23:38:16 localhost pcscd: ifdhandler.c:271:IFDHGetCapabilities() lun: 0, tag: 0xFAE Jan 8 23:38:16 localhost pcscd: ifdhandler.c:313:IFDHGetCapabilities() Reader supports 1 slot(s) Jan 8 23:38:16 localhost pcscd: pcscdaemon.c:507:main() pcsc-lite 1.4.4 daemon ready. Jan 8 23:38:25 localhost vmunix: pccard: card ejected from slot 0 Jan 8 23:38:25 localhost pcscd: ccid_serial.c:208:WriteSerial() write error: Input/output error Jan 8 23:38:25 localhost pcscd: ifdwrapper.c:494:IFDStatusICC() Card not transacted: 612 Jan 8 23:38:25 localhost pcscd: eventhandler.c:309:EHStatusHandlerThread() \ Error communicating to: GemPCTwin serial 00 00 Jan 8 23:38:25 localhost pcscd: ccid_serial.c:208:WriteSerial() write error: Input/output error Jan 8 23:38:25 localhost pcscd: ifdwrapper.c:494:IFDStatusICC() Card not transacted: 612 Jan 8 23:38:25 localhost pcscd: eventhandler.c:309:EHStatusHandlerThread() \ Error communicating to: GemPCTwin serial 00 00 Jan 8 23:38:26 localhost pcscd: ccid_serial.c:208:WriteSerial() write error: Input/output error Jan 8 23:38:26 localhost pcscd: ifdwrapper.c:494:IFDStatusICC() Card not transacted: 612 Jan 8 23:38:26 localhost pcscd: eventhandler.c:309:EHStatusHandlerThread() \ Error communicating to: GemPCTwin serial 00 00 [and so on] = Is it possible to reduce this number? Even with --critical (which option BTW cannot be easily set) the ccid_serial.c error line is still printed. Thx, bye, Gismo / Luca -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Dr. Ludovic Rousseau
Bug#1001155: Fails to update when service is masked
Hello Yuri, I got no answer to my questions. Since I can't reproduce the problem I can fix it. Your help is needed. Thanks Le 05/12/2021 à 15:57, Ludovic Rousseau a écrit : On Sun, 5 Dec 2021 13:09:01 +0100 Yuri D'Elia wrote: Package: pcscd Version: 1.9.5-1 Severity: normal Errors were encountered while processing: pcscd E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up pcscd (1.9.5-1) ... Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) I consider this a bug. During an upgrade, if the service isn't started, the upgrade script shouldn't fail trying to restart it. I can't reproduce this problem. I have masked both pcscd.socket and pcscd.service: $ systemctl status pcscd.socket ○ pcscd.socket Loaded: masked (Reason: Unit pcscd.socket is masked.) Active: inactive (dead) $ systemctl status pcscd.service ○ pcscd.service Loaded: masked (Reason: Unit pcscd.service is masked.) Active: inactive (dead) But restart works fine (no restart and no error): $ sudo invoke-rc.d pcscd restart $ I can also reinstall the package with no error: $ sudo dpkg -i pcscd_1.9.5-1_amd64.deb (Lecture de la base de données... 261489 fichiers et répertoires déjà installés.) Préparation du dépaquetage de pcscd_1.9.5-1_amd64.deb ... Dépaquetage de pcscd (1.9.5-1) sur (1.9.5-1) ... Paramétrage de pcscd (1.9.5-1) ... Traitement des actions différées (« triggers ») pour man-db (2.9.4-2) ... I note I get the same error if I use service(8) instead of invoke-rc.d(8) to restart pcscd: $ sudo service pcscd restart Failed to restart pcscd.service: Unit pcscd.service is masked. Have you modified invoke-rc.d configuration or something like that? What do you get if you run "sudo invoke-rc.d pcscd restart"? Thanks -- Dr. Ludovic Rousseau
Bug#1001155: Fails to update when service is masked
On Sun, 5 Dec 2021 13:09:01 +0100 Yuri D'Elia wrote: > Package: pcscd > Version: 1.9.5-1 > Severity: normal > > Errors were encountered while processing: > pcscd > E: Sub-process /usr/bin/dpkg returned an error code (1) > Setting up pcscd (1.9.5-1) ... > Failed to restart pcscd.service: Unit pcscd.socket is masked. > invoke-rc.d: initscript pcscd, action "restart" failed. > ○ pcscd.service - PC/SC Smart Card Daemon > Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor > preset: enabled) > Active: inactive (dead) >Docs: man:pcscd(8) > > I consider this a bug. > > During an upgrade, if the service isn't started, the upgrade script > shouldn't fail trying to restart it. I can't reproduce this problem. I have masked both pcscd.socket and pcscd.service: $ systemctl status pcscd.socket ○ pcscd.socket Loaded: masked (Reason: Unit pcscd.socket is masked.) Active: inactive (dead) $ systemctl status pcscd.service ○ pcscd.service Loaded: masked (Reason: Unit pcscd.service is masked.) Active: inactive (dead) But restart works fine (no restart and no error): $ sudo invoke-rc.d pcscd restart $ I can also reinstall the package with no error: $ sudo dpkg -i pcscd_1.9.5-1_amd64.deb (Lecture de la base de données... 261489 fichiers et répertoires déjà installés.) Préparation du dépaquetage de pcscd_1.9.5-1_amd64.deb ... Dépaquetage de pcscd (1.9.5-1) sur (1.9.5-1) ... Paramétrage de pcscd (1.9.5-1) ... Traitement des actions différées (« triggers ») pour man-db (2.9.4-2) ... I note I get the same error if I use service(8) instead of invoke-rc.d(8) to restart pcscd: $ sudo service pcscd restart Failed to restart pcscd.service: Unit pcscd.service is masked. Have you modified invoke-rc.d configuration or something like that? What do you get if you run "sudo invoke-rc.d pcscd restart"? Thanks
Bug#1000235: 0ad: Ignore parallel jobs limit during building
Le 20/11/2021 à 01:48, Boyuan Yang a écrit : Source: 0ad Severity: important Version: 0.0.25b-1 X-Debbugs-CC: vch...@debian.org rouss...@debian.org Dear 0ad package maintainers, Hello, https://sources.debian.org/src/0ad/0.0.25b-1/debian/rules/#L15 : PARALLEL_JOBS=$(shell getconf _NPROCESSORS_ONLN) ifeq ($(findstring parallel=,$(DEB_BUILD_OPTIONS)),) export DEB_BUILD_OPTIONS+=parallel=$(PARALLEL_JOBS) endif This really does not make sense; specifying parallel jobs to be the same as CPU core number will override -j parameter passed to dpkg-buildpackage and external DEB_BUILD_OPTIONS environment variable (if defined), which may cause troubles. For example, when preparing backport build for 0ad, my build machine OOMed due to having too many CPU cores but limited RAM. Exact. parallel (or not) compilation should now be handled by dpkg-buildpackage. Thanks for the bug report. Bye -- Dr. Ludovic Rousseau
Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start
Hello Philipp, Le 19/10/2021 à 08:03, Philipp Marek a écrit : Do I read you correctly that the default Debian package doesn't restart pcscd upon installing a new version? Exact. My idea was to NOT break already running applications. But it looks like it is more problematic. pcscd should also be restarted after a driver is installed so pcscd rescan the driver directory. Yeah, right! I wanted to work on the issue but I am not able to reproduce it any more :-( Initial status: $ systemctl status pcscd ● pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset> Active: active (running) since Fri 2021-11-12 17:35:28 CET; 3min 16s ago TriggeredBy: ● pcscd.socket Docs: man:pcscd(8) Main PID: 2246 (pcscd) Tasks: 4 (limit: 4650) Memory: 712.0K CPU: 3ms CGroup: /system.slice/pcscd.service └─2246 /usr/sbin/pcscd --foreground --auto-exit nov. 12 17:35:28 debian systemd[1]: Started PC/SC Smart Card Daemon. $ ls -l /var/run/pcscd/ total 4 srw-rw-rw- 1 root root 0 12 nov. 17:32 pcscd.comm -rw-r--r-- 1 root root 6 12 nov. 17:35 pcscd.pid pcscd if running with pid=2246 The socket pcscd.comm is present in /var/run/pcscd/ I restart pcscd: $ sudo systemctl restart pcscd $ systemctl status pcscd ● pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset> Active: active (running) since Fri 2021-11-12 17:39:15 CET; 2s ago TriggeredBy: ● pcscd.socket Docs: man:pcscd(8) Main PID: 2644 (pcscd) Tasks: 3 (limit: 4650) Memory: 672.0K CPU: 4ms CGroup: /system.slice/pcscd.service └─2644 /usr/sbin/pcscd --foreground --auto-exit nov. 12 17:39:15 debian systemd[1]: Started PC/SC Smart Card Daemon. pcscd is now running with pid=2644 So the process HAS BEEN restarted. $ ls -l /var/run/pcscd/ total 4 srw-rw-rw- 1 root root 0 12 nov. 17:32 pcscd.comm -rw-r--r-- 1 root root 6 12 nov. 17:39 pcscd.pid The socket pcscd.comm is still present and has NOT been removed during the restart. The date of creation of the socket file is still the same. So the socket file has NOT been removed and recreated. The socket /var/run/pcscd/pcscd.comm is removed only if pcscd is NOT started by systemd. I also tried with "sudo service pcscd restart" but again a new pcscd process is started and the socket is NOT removed. From the systemd changelog I see that since your initial bug report "Wed, 06 Oct 2021" systemd has been updated in testing. https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_249.5-2_changelog The current version in testing is now 249.5-2. I guess the previous version was 247.9-4, uploaded in unstable on Fri, 01 Oct 2021. Can you check if you can reproduce the issue on your system? That would explain why I needed the last month to debug a problem... my pcscd was updated on 2021-08-31, but seems to have been running the old binary until I rebooted - at which point my VPN didn't work anymore, and the recently (2 weeks) installed packages didn't offer any clue about the offending package... Sorry. Never mind... I learned a thing or two ;) I still plan to restart pcscd on upgrade or when a new version of libccid is installed. Thanks -- Dr. Ludovic Rousseau
Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start
Le 06/10/2021 à 16:12, Philipp Marek a écrit : Thanks for the information... perhaps the socket should depend on pcscd and so be restarted along with it? Good idea. I will have a look. Why do you want to restart pcscd? When switching between package versions. Do I read you correctly that the default Debian package doesn't restart pcscd upon installing a new version? Exact. My idea was to NOT break already running applications. But it looks like it is more problematic. pcscd should also be restarted after a driver is installed so pcscd rescan the driver directory. That would explain why I needed the last month to debug a problem... my pcscd was updated on 2021-08-31, but seems to have been running the old binary until I rebooted - at which point my VPN didn't work anymore, and the recently (2 weeks) installed packages didn't offer any clue about the offending package... Sorry. Please set the socket as a dependency, so that a simple "restart" works as expected (by me, at least ;) I will look at this. Thanks for the feedback. Bye -- Dr. Ludovic Rousseau
Bug#995814: socket /run/pcscd/pcscd.comm immediately removed upon start
Le 06/10/2021 à 13:50, Philipp Marek a écrit : Package: pcscd Version: 1.9.4-1 Severity: normal X-Debbugs-Cc: phil...@marek.priv.at I noticed that 1.9.4-1 removes the /run/pcscd/pcscd.comm socket after starting up; at least, after a "systemctl restart" I can see pcscd having that socket open (via "lsof"), but it doesn't exist in the filesystem - and so client services (like "p11tool --list-tokens") don't see any hardware tokens. I can reproduce the problem if I use "sudo systemctl restart pcscd". You should NOT do that. If you really need to restart pcscd you should do something like: $ systemctl stop pcscd.service $ systemctl stop pcscd.socket $ systemctl start pcscd.socket See https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html Why do you want to restart pcscd? Bye -- Dr. Ludovic Rousseau
Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens
Le 08/09/2021 à 12:34, Vladimir K a écrit :
Thank you!
As there may be other even older revisions out in the wild (and I now know of
some),
wouldn't it be more robust to have a highest known affected ('<= 0x0013')
condition?
I prefer to write specific patch for verified issues.
Maybe a token with firmware 0.10 will not be affected by this bug for one
reason or another.
--
Dr. Ludovic Rousseau
Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens
Le 07/09/2021 à 19:22, Vladimir K a écrit : Hello. Hello, I've tested the patch, it fixes the issue, but only for tokens with firmware 0.12 It appears that one of my tokens has firmware 0.13 and it is still affected by the bug. Adding 0x0013 to the condition also fixes 0.13 tokens. Fixed upstream in https://salsa.debian.org/rousseau/CCID/-/commit/26ad96076523472e9d0d383d014e7b1ad241fd5b Thanks -- Dr. Ludovic Rousseau
Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens
tags 993647 upstream fixed-upstream pending thank Le 06/09/2021 à 12:16, Vladimir K a écrit : Hello. Hello, safenetauthenticationclient maintains some sort of binary cache in /var/tmp/eToken.cache/. It masks the problem after libccid upgrae for a while. I was able to fully reproduce it on a fresh test eToken 5110, the problem appears after the cache is cleared. 3 logs of pcscd attached: 1. with libccid 1.4.35, success 2. with libccid 1.4.36, just after upgrade, success 3. with libccid 1.4.36, after cleaning SAC cache, fail. Each log is gathered while the following actions were performed: 1. connected token. 2. run p11tool --login --list-all 'pkcs11:token=Test%20Token', entered PIN 3. disconnected token Thanks for the logs. I fixed the issue upstream in https://salsa.debian.org/rousseau/CCID/-/commit/b48e1e697010431b7f03d4ecfe917ceee95e2c64 I have no idea when I will make a new upstream release of the CCID driver. In the mean time I propose you to apply the fix and rebuild the driver yourself. Bye -- Dr. Ludovic Rousseau
Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens
007 ifdwrapper.c:543:IFDTransmit() Card not transacted: 612 Sep 04 10:13:23 hostname pcscd[677]: 0005 winscard.c:1620:SCardTransmit() Card not transacted: 0x80100016 Sep 04 10:13:24 hostname pcscd[677]: 0965 openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card first. Sep 04 10:13:24 hostname pcscd[677]: 0004 ifdwrapper.c:543:IFDTransmit() Card not transacted: 612 Sep 04 10:13:24 hostname pcscd[677]: 0003 winscard.c:1620:SCardTransmit() Card not transacted: 0x80100016 Sep 04 10:13:24 hostname pcscd[677]: 00332464 ccid_usb.c:902:ReadUSB() read failed (1/7): -8 LIBUSB_ERROR_OVERFLOW Sep 04 10:13:24 hostname pcscd[677]: 0052 ifdwrapper.c:364:IFDStatusICC() Card not transacted: 612 Sep 04 10:13:24 hostname pcscd[677]: 0015 eventhandler.c:336:EHStatusHandlerThread() Error communicating to: SafeNet eToken 5100 [eToken 5110 SC] 00 00 Downgrading libccid to 1.4.34 and clearing middleware cache from /var/tmp fixes the issue. That is surprising. From the error logs it looks like a communication problem at the libusb and/or USB level. But that would not explain why it works fine with version 1.4.34 It also very strange that it fails "after a while". Can you provide more logs as documented at https://ccid.apdu.fr/#support ? Thanks -- Dr. Ludovic Rousseau
Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz
On Fri, 6 Aug 2021 19:26:56 +0900 Roger Shimizu wrote: > should be caused by: > - https://bugs.debian.org/897653 > > if you upgrade tar to buster version 1.30+dfsg-6 or later, it should > be resolved. I am on buster with: ii pristine-tar 1.49 amd64regenerate pristine tarballs ii tar1.34+dfsg-1 amd64GNU version of the tar archiving utility and I still have the problem. I try to upgrade the package 0ad to a new upstream version but that fails: $ gbp import-orig --uscan gbp:info: Launching uscan... gbp:info: Using uscan downloaded tarball ../0ad_0.0.25.orig.tar.xz What is the upstream version? [0.0.25] gbp:info: Importing '../0ad_0.0.25.orig.tar.xz' to branch 'upstream'... gbp:info: Source package is 0ad gbp:info: Upstream version is 0.0.25 gbp:error: Import of ../0ad_0.0.25.orig.tar.xz failed: Couldn't commit to 'pristine-tar' with upstream 'c98ef96af6f9638844dce03af30a3060b677fee2': pristine-xz failed to reproduce build of ../0ad_0.0.25.orig.tar.xz (Please file a bug report.) pristine-tar: failed to generate delta gbp:error: Error detected, Will roll back changes. gbp:info: Rolling back branch upstream by resetting it to 86bb850b0a939ace014cbd3b7126410c258fc25c gbp:info: Rolling back branch pristine-tar by resetting it to f0bd6693182069f87ebd7f5ab8e28911ffc157db gbp:error: Rolled back changes after import error. I tried with a fresh "git clone" of 0ad but the problem is still present. I don't want to regerenrate old tarballs, but to add a new one. I extracted the upstream 0ad_0.0.25.orig.tar.xz and regenerated a new .tar.xz file and this time the inclusion worked: $ gbp import-orig ../0ad_0.0.25.orig.tar.xz What is the upstream version? [0.0.25] gbp:info: Importing '../0ad_0.0.25.orig.tar.xz' to branch 'upstream'... gbp:info: Source package is 0ad gbp:info: Upstream version is 0.0.25 gbp:info: Replacing upstream source on 'master' gbp:info: Successfully imported version 0.0.25 of ../0ad_0.0.25.orig.tar.xz But, of course, the archived version is not more a "pristine-tar" since that is one that I re-created myself. I have no idea what version of tar was used by upstream. Upsteam file is available at https://releases.wildfiregames.com/0ad-0.0.25-alpha-unix-data.tar.xz Bye
Bug#992785: Please allow blacklisting a particular card reader
Le 23/08/2021 à 13:31, Wouter Verhelst a écrit : Package: pcscd Version: 1.9.1-1 Severity: wishlist Hi, Hello Wouter, My laptop has a builtin (i.e., impossible to remove or disable) smart card reader. It connects through USB. Unfortunately, it is broken: it continuously reports that a card is in the device (even when that is not the case). When something tries to read from the card, the only way for me to discover that things failed is in the fact that the read times out. Unfortunately my laptop's firmware does not allow me to disable it, which means I'd have to tell pcscd to ignore the reader; but I can't find any setting to do so. Please add an option to blacklist a particular card reader. It is already possible :-) Use PCSCLITE_FILTER_IGNORE_READER_NAMES= in /etc/default/pcscd I just added this possibility in the latest pcsc-lite version. See https://ludovicrousseau.blogspot.com/2021/08/pcsc-lite-configuration-using.html Bye -- Dr. Ludovic Rousseau
Bug#990154: pcscd: legacy conffiles leftover
Le 27/06/2021 à 17:07, Christoph Anton Mitterer a écrit : On Sun, 2021-06-27 at 16:50 +0200, Ludovic Rousseau wrote: What is the output of the commmand: cat /var/lib/dpkg/info/pcscd.conffiles Just: /etc/init.d/pcscd Not sure where dpkg keeps actually track of it's (obsolete) conffiles, I think it's in: /var/lib/dpkg/status: /etc/reader.conf.d/0comments 5ca480422c33bfe1fdcf7299289a12c9 obsolete The "remove-on-upgrade" flag as documented in remove-on-upgrade(5) may be a better option. Probably. Maybe this simply creates a dpkg-maintscript-helper line in the maintainer scripts. My problem is that the file has been removed from the pcscd package 10 years ago. So it will be time consuming (on my side) to check the fix is working. I will need to install a Debian distribution from 10 years ago (Debian 5.0 Etch) and upgrade it up to the next-Bullseye Debian 12 stable (that should be available in 2-3 years). Hmm I don't think this is really necessary... or do you see any big dangers in "blindly" removing an obsolete conffile, that was anyway just a README file? Can't you just erase the file from your system? Well I for my self have already cleaned it up manually... but how many tens of thousands Debian installations are out there which will have such legacy cruft lingering around forever? According to popcon pcscd is installed on 23796 systems. But 10 years ago it was almost 0 (maybe less than 1000) https://ludovicrousseau.blogspot.com/2020/04/smart-card-usage-in-debian-popcon.html Therefore I think it's always good practise to properly clean that up for the benefit of everyone. I agree. I tried conffiles as documented in deb-conffiles(5) and also dpkg-maintscript-helper but with no success. After some debug I have in dpkg-maintscript-helper logs: DEBUG: dpkg-maintscript-helper: File '/etc/reader.conf.d/0comments' not owned by package 'pcscd:amd64', skipping rm_conffile So I guess dpkg-maintscript-helper can be used only when you upgrade from a version of pcscd that provides the file /etc/reader.conf.d/0comments to a newer version that uses dpkg-maintscript-helper to remove the conf file. If the file /etc/reader.conf.d/0comments is not owned by the *current* version of pcscd then it will not be removed on upgrade. And since the last version of pcscd that owned the /etc/reader.conf.d/0comments file is 10 years old... My last option is to force the removal of /etc/reader.conf.d/0comments using something simple like "rm -f /etc/reader.conf.d/0comments" but I think that is a dangerous idea. I should be safer (and simpler) to just keep the file where it is. Regards, -- Dr. Ludovic Rousseau
Bug#990154: pcscd: legacy conffiles leftover
Hello, Le 23/06/2021 à 18:36, Christoph Anton Mitterer a écrit : On Wed, 2021-06-23 at 15:18 +0200, Ludovic Rousseau wrote: /etc/reader.conf.d/0comments was listed in debian/pcscd.install so it should have been removed on upgrade unless you modified it. No? Hmm I don't think I'd have ever modified it... and even then I think it should be unregistered as a conffile, but just left over as a "normal" file. What is the output of the commmand: cat /var/lib/dpkg/info/pcscd.conffiles What do you suggest? My understanding is that such files should be cleaned up with: dpkg-maintscript-helper rm_conffile The version that needs to be given is, AFAIU, not the version in which the conffile was dropped, but "the latest version of the package whose upgrade should trigger the operation". The manpage has an example section which describes that pretty well. And then I'd guess one should add this to the maintainer scripts and leave it until next-stable+1 or so? The "remove-on-upgrade" flag as documented in remove-on-upgrade(5) may be a better option. My problem is that the file has been removed from the pcscd package 10 years ago. So it will be time consuming (on my side) to check the fix is working. I will need to install a Debian distribution from 10 years ago (Debian 5.0 Etch) and upgrade it up to the next-Bullseye Debian 12 stable (that should be available in 2-3 years). Can't you just erase the file from your system? Bye -- Dr. Ludovic Rousseau
Bug#990154: pcscd: legacy conffiles leftover
On Mon, 21 Jun 2021 19:27:23 +0200 Christoph Anton Mitterer wrote: > Package: pcscd > Version: 1.9.1-1 > Severity: normal > > > Hi. Hello, > Apparently the package used to contain the conffiles: > /etc/reader.conf.d/0comments > but no longer does so. > > Please properly clean them up using dpkg-maintscript-helper(1). > (AFAIU, the version that needs to be specified for that is NOT > the version where the conffile was dropped, but rather "the > latest version of the package whose upgrade should trigger > the operation" > > Quoting the manpage: >For example, for a conffile removed in version 2.0-1 of a package, >prior-version should be set to 2.0-1~. This will cause the conffile >to be removed even if the user rebuilt the previous version 1.0-1 >as 1.0-1local1. Or a package switching a path from a symlink >(shipped in version 1.0-1) to a directory (shipped in version >2.0-1), but only performing the actual switch in the maintainer >scripts in version 3.0-1, should set prior-version to 3.0-1~. The file /etc/reader.conf.d/0comments was remove in pcsc-lite 1.6.0-1 released in May 2010, 11 years ago! See https://salsa.debian.org/debian/pcsc-lite/-/commit/c29340f729c897ffcbcc5e98f46202640438#696a33843270964798b69cfe91b67ccc717d3f35 /etc/reader.conf.d/0comments was listed in debian/pcscd.install so it should have been removed on upgrade unless you modified it. No? > Also, it hadn't "registered" /etc/reader.conf.d/ so that will probably be left > over, too, unless some other package that contains it is installed (like > libccid). pcscd does not provide or install /etc/reader.conf.d/ This directory is created by libccid for example. I am not sure what I can/will do something about this issue. What do you suggest? Bye
Bug#854703: disappears and never returns?
On Sat, 11 Feb 2017 17:11:13 +0100 Ludovic Rousseau wrote: On Sat, 11 Feb 2017 15:07:58 + "Iain R. Learmonth" wrote: > Please let me know if there are any log files that would be useful, this is > a massive pain for me so I'm very willing to help. Do you have "disable-ccid" in your scdaemon.conf? Do you see your reader using pcsc_scan? See https://ludovicrousseau.blogspot.fr/2014/03/level-1-smart-card-support-on-gnulinux.html To use GnuPG and pcscd at the same time you should disable the CCID driver in GnuPG. See https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html I close this bug. -- Dr. Ludovic Rousseau
Bug#989316: pcscd: very long delays in apps configured to use reader
Le 01/06/2021 à 16:23, Maurizio Avogadro a écrit : It worked perfectly and solved indeed the issue with browsers! Great! Please notice that in your page you affirm that the Debian init script for pcscd sources the /etc/default/pcscd file; while this is true for the old SysV script, for the systemd unit it isn't and the service file has to be modified manually. Would it be possible to have the pcsc-lite binary packages configured with the filter enabled and with 'EnvironmentFile=-/etc/default/pcscd' in pcscd.service to make things easier in such situations? pcscd is already configured with the filter enabled. It is the default configuration now. I also used your suggestion to use EnvironmentFile in https://salsa.debian.org/rousseau/PCSC/-/commit/de70032e4eff6c03d8e58f142e075205b64f0678 It will be part of the next Debian package. Thanks -- Dr. Ludovic Rousseau
Bug#989316: pcscd: very long delays in apps configured to use reader
Le 01/06/2021 à 02:45, Maurizio Avogadro a écrit : Package: pcscd Version: 1.9.1-1 Severity: important Dear Maintainer, Hello, when adding a Bit4ID miniLector CIE Plus smartcard reader to nssdb, Chromium becomes unable to connect to SSL websites. The reader, actually a rebranded FEITIAN R502-Dual, has 4 slots: contactless, contact and 2 SAM slots well hidden under the device; as stated by the user manual, the SAM slots don't support hotplug and the SIM cards should be inserted before plugging the reader to the USB port. The pcscd log shows that the daemon is constantly trying to power on some card (the empty SAM slots?) and this introduces a huge delay that easily makes the browser reach the timeout. As you can see from the pcsc_scan output: $ pcsc_scan Using reader plug'n play mechanism Scanning present readers... 0: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 CLESS] 00 00 1: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 Contact] 01 00 2: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 SAM1] 02 00 3: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 SAM2] 03 00 Tue Jun 1 01:28:51 2021 Reader 0: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 CLESS] 00 00 Event number: 0 Card state: Card removed, Reader 1: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 Contact] 01 00 Event number: 0 Card state: Card removed, Reader 2: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 SAM1] 02 00 Event number: 0 Card state: Card inserted, Unresponsive card, Reader 3: BIT4ID mLector AIR DI V3 [miniLector AIR DI v3 SAM2] 03 00 Event number: 0 Card state: Card inserted, Unresponsive card, The reader reports a card is inserted in "SAM1" & "SAM2" readers "Card inserted, Unresponsive card," But the "card" is unresponsive. Of course, since there is no card. The same happens when loading the opensc-pkcs11.so library in Firefox and this renders the browsers unusable with the reader. Can you do something, or should I submit this issue to the hardware vendor? The reader should not report a card is present if no card is present. I understand that the SAM slots do not have an card insertion mechanism. But maybe the reader could be smart enough to ignore the slot if a first power up fails? Reporting the problem to the hardware vendor could help. I guess the problem is that opensc-pkcs11.so tries to connect to the "non-present cards". The driver will try to power up the card but that fails after 200 ms. And you have 2 empty slots so at least 400 ms is lost each time. It is possible to configure pcscd so that some readers are NOT reported to the application. See https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html It may solve your problem. Use something like: PCSCLITE_FILTER_IGNORE_READER_NAMES="SAM" Bye -- Dr. Ludovic Rousseau
Bug#965059: Syntax warnings with Python 3.8
On Wed, 15 Jul 2020 11:34:38 +0100 Sam Morris wrote: > Package: python3-yubico > Version: 1.3.3-0.3 > Severity: normal > > $ ipa user-find sam > /usr/lib/python3/dist-packages/netaddr/strategy/__init__.py:189: > SyntaxWarning: "is not" with a literal. Did you mean "!="? > if word_sep is not '': > /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:288: SyntaxWarning: > "is" with a literal. Did you mean "=="? > if mode is 'nand': > /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:294: SyntaxWarning: > "is" with a literal. Did you mean "=="? > elif mode is 'and': > /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:306: SyntaxWarning: > "is" with a literal. Did you mean "=="? > if mode is 'nand': > /usr/lib/python3/dist-packages/yubico/yubikey_config.py:478: SyntaxWarning: > "is" with a literal. Did you mean "=="? > if slot is 1: > /usr/lib/python3/dist-packages/yubico/yubikey_config.py:483: SyntaxWarning: > "is" with a literal. Did you mean "=="? > elif slot is 2: > [...] The problem is already fixed upstream in https://github.com/Yubico/python-yubico/commit/b4a53389c3e6ad41c836aa82998149f427fe1ad8 since September 2019. But the change is not yet available in a released version of python-yubico. Maybe the Debian package could use the upstream patch?
Bug#838055: 0ad: Embedded libsquish library now available in debian
On Mon, 24 Aug 2020 15:22:06 +0200 Fabio Pedretti wrote: Hi, I closed this issue years ago because actually 0ad doesn't use the squish library which is in the 0ad source. It's a problem strictly related to the nvidia-texture-tools package. Actually 0ad source could also be repackaged to remove squish and nvtt directory, which are not used. Since there is already bug #838056 for nvidia-texture-tools there is nothing to be done here and this one could actually be closed. But I'll leave that up to you. Related: https://github.com/castano/nvidia-texture-tools/pull/244 0ad alpha 24 now uses the embedded nvtt library because it needs nvtt 2.1 and Debian only has 2.0.8 in stable. So 0ad also uses the embedded squish library in https://salsa.debian.org/games-team/0ad/-/tree/master/libraries/source/nvtt/src/src/nvtt/squish Bye -- Dr. Ludovic Rousseau
Bug#794562: nvtt 2.1 now required
On Mon, 24 Aug 2020 09:25:24 +0200 Fabio Pedretti wrote: SVN version of 0ad now includes nvtt 2.1.1: https://trac.wildfiregames.com/changeset/23305 And also require a new version to properly build: https://trac.wildfiregames.com/changeset/23974 0ad alpha 24 depends on nvtt 2.1. nvtt 2.1 is still only in Debian experimental since May 2016. The package was not updated since then. I don't know if nvtt 2.1 will ever be moved to unstable one day. For now the 0ad alpha 24 build uses the embedded nvtt. Maybe we can close this bug? Bye -- Dr. Ludovic Rousseau
Bug#810438: libnfc: please switch to libusb 1.0
forwarded 810438 https://github.com/nfc-tools/libnfc/issues/191 tags 810438 upstream thank On Fri, 8 Jan 2016 19:37:54 +0100 Aurelien Jarno wrote: Package: libnfc Version: 1.7.1-4 Severity: wishlist Dear Maintainer, libnfc has a build-depends on libusb-dev. A few years ago upstream has released a new major version libusb 1.0 with a different API which aims to fix design deficiencies with USB 2.0 and 3.0 in mind. The old libusb 0.1 package is not supported upstream anymore and should be considered deprecated. If libnfc supports the new libusb 1.0 library, please consider switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not please inform upstream that porting the software to the new API is recommended. This problem has also been reported upstream in https://github.com/nfc-tools/libnfc/issues/191 Bye -- Dr. Ludovic Rousseau
Bug#976096: munin-plugins-core: acpi plugins does not support 'fetch' argument
Package: munin-plugins-core
Version: 2.0.49-1
Severity: normal
Tags: patch
Hello,
I use munin-node-c instead of munin-node.
The plugins are called with the argument 'fetch' or 'config'.
The acpi plugin does not handle the 'fetch' argument and returns
nothing.
$ /usr/share/munin/plugins/acpi
thermal_zone0.value 26.8
$ /usr/share/munin/plugins/acpi fetch
$
I propose the patch:
--- /usr/share/munin/plugins/acpi 2019-05-16 01:21:08.0 +0200
+++ acpi2020-11-29 17:55:14.533609387 +0100
@@ -56,6 +56,10 @@
fi
+do_fetch () {
+do_
+}
+
do_ () { # Fetch
for ZONE in $ATZ; do
TEMP=$(cat "$ZONE/temp")
@@ -93,7 +97,7 @@
}
case $1 in
-config|autoconf|'')
+config|autoconf|fetch|'')
"do_$1"
esac
I wanted to report the problem upstream but I could not find an acpi
plugin in
https://github.com/munin-monitoring/munin/tree/master/plugins/node.d.linux
I also could not find an acpi plugin in version 2.999.15-3 available in
experimental.
It looks like the acpi plugin has been deprecated and removed.
In that cas you can just ignore this bug report.
Thanks
-- System Information:
Debian Release: 10.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.49-1
ii perl 5.28.1-6+deb10u1
Versions of packages munin-plugins-core recommends:
ii libnet-snmp-perl 6.0.1-5
Versions of packages munin-plugins-core suggests:
ii acpi 1.7-1.1
ii conntrack 1:1.4.5-2
ii default-mysql-client 1.0.5
pn ethtool
pn hdparm
ii libcache-cache-perl 1.08-2
ii libdbd-mysql-perl 4.050-2
pn libdbd-pg-perl
ii libhttp-date-perl 6.02-1
pn liblwp-useragent-determined-perl
ii libnet-dns-perl 1.19-1
ii libnet-ip-perl1.26-2
pn libnet-irc-perl
pn libnet-ldap-perl
pn libnet-netmask-perl
pn libnet-telnet-perl
ii libxml-parser-perl2.44-4
pn libxml-simple-perl
ii lm-sensors1:3.5.0-3
ii logtail 1.3.20
ii net-tools 1.60+git20180626.aebd88e-1
ii python3 3.7.3-1
ii ruby 1:2.5.1
ii smartmontools 6.6-1
-- no debconf information
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#969027: O: jhead -- manipulate the non-image part of Exif compliant JPEG files
Package: wnpp Severity: normal I intend to orphan the jhead package. jhead is an EXIF parser and has MANY problems with the parser. It works fine in normal cases. But the parser has NO defencive check so it is very easy to make it crash or exploit buffer overflows. - The upstream maintainer is not reactive. - I do not use this package any more. - I do not have time and energy to fix myself the crashes and possibly security issues. The package description is: jhead is a command line driven utility for extracting digital camera settings from the Exif format files used by many digital cameras. It handles the various confusing ways these can be expressed, and displays them as F-stop, shutter speed, etc. It is also able to reduce the size of digital camera JPEGs without loss of information, by deleting integral thumbnails that digital cameras put into the Exif header.
Bug#961229: libnfc: New upstream version: 1.7.2
New version is uploaded. libnfc6 is a new package so in the NEW queue. We have to wait for a manual intervention. https://ftp-master.debian.org/new/libnfc_1.8.0-1.html -- 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#967971: jhead: A Segmentation fault error in jhead 1:3.04-2
I can reproduce the problem now. Thanks Le 07/08/2020 à 18:48, Anshunkang Zhou a écrit : Hi, here is the steps to reproduce this bug, you should unzip the attached file and run it: ``` seviezhou@ubuntu:~$ git clone https://salsa.debian.org/debian/jhead.git Cloning into 'jhead'... remote: Enumerating objects: 814, done. remote: Counting objects: 100% (814/814), done. remote: Compressing objects: 100% (311/311), done. remote: Total 814 (delta 436), reused 755 (delta 392), pack-reused 0 Receiving objects: 100% (814/814), 179.29 KiB | 283.00 KiB/s, done. Resolving deltas: 100% (436/436), done. Checking connectivity... done. seviezhou@ubuntu:~$ cd jhead/ seviezhou@ubuntu:~/jhead$ CC="gcc -g -fsanitize=address" make -j gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jhead.c -o jhead.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jpgfile.c -o jpgfile.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c jpgqguess.c -o jpgqguess.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c paths.c -o paths.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c exif.c -o exif.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c iptc.c -o iptc.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c gpsinfo.c -o gpsinfo.o gcc -g -fsanitize=address -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c makernote.c -o makernote.o gcc -g -fsanitize=address -Wl,-Bsymbolic-functions -Wl,-z,relro -o jhead ./jhead.o ./jpgfile.o ./jpgqguess.o ./paths.o ./exif.o ./iptc.o ./gpsinfo.o ./makernote.o -lm ./jhead.o: In function `DoCommand': /home/seviezhou/jhead/jhead.c:379: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' seviezhou@ubuntu:~/jhead$ ./jhead -ft -exifmap -de -purejpg -di -dx ./SEGV-Get32s-exif-333 Map: 8-00158: Directory Map: 00158-00167: Data for tag 010f Map: 00168-00184: Data for tag 0110 Map: 00184-00192: Data for tag 011a Map: 00192-00200: Data for tag 011b Nonfatal Error : './SEGV-Get32s-exif-333' Too many components -65535 for tag 0002 in Exif Map: 00200-00211: Data for tag 0131 Map: 00212-00232: Data for tag 0132 Map: 00232-00237: Data for tag 8298 Map: 00266-00704: Directory Map: 00704-00712: Data for tag 829a Map: 00712-00720: Data for tag 829d Nonfatal Error : './SEGV-Get32s-exif-333' Inappropriate format (3) for Exif GPS coordinates! Nonfatal Error : './SEGV-Get32s-exif-333' Inappropriate format (3) for Exif GPS coordinates! ASAN:SIGSEGV = ==77365==ERROR: AddressSanitizer: SEGV on unknown address 0x61a3f28c (pc 0x0040a901 bp 0x sp 0x7ffeadf0f830 T0) #0 0x40a900 in Get32s /home/seviezhou/jhead/exif.c:333 #1 0x410d94 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:138 #2 0x40d282 in ProcessExifDir /home/seviezhou/jhead/exif.c:866 #3 0x40d209 in ProcessExifDir /home/seviezhou/jhead/exif.c:852 #4 0x40d947 in process_EXIF /home/seviezhou/jhead/exif.c:1041 #5 0x407fbf in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287 #6 0x408210 in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379 #7 0x404e66 in ProcessFile /home/seviezhou/jhead/jhead.c:905 #8 0x4025d5 in main /home/seviezhou/jhead/jhead.c:1756 #9 0x7f8d56c7c83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) #10 0x403b08 in _start (/home/seviezhou/jhead/jhead+0x403b08) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/exif.c:333 Get32s ==77365==ABORTING ``` On 08/8/2020 00:33，Ludovic Rousseau <mailto:ludovic.rouss...@free.fr> wrote： Hello, I can't reproduce the crash. I tried with the normal binary and also a new build using your arguments. I get a lot of "Nonfatal Error : 'SEGV-Get32s-exif-333' Illegal number format 1024 for tag in Exif" but NO crash. How can I reproduce the problem? Bye Le 06/08/2020 à 05:14, Anshunkang Zhou a écrit : Package: jhead Version: 1:3.04-2 Severity: important Dear Maintainer, I found a segmentation fault in the latest version of jhead, detailed information is as follows, the poc is in the mail attachment. ## System info Ubuntu x86_64, gcc , jhead (latest 1:3.04-2) ## Configure CFLAGS="-g -fsanitize=address&quo
Bug#967924: jhead: A Segmentation fault error in jhead 1:3.04-2
Hello, I can't reproduce the crash. I get a lot of "Nonfatal Error : 'SEGV-ProcessGpsInfo-gpsinfo-122' Maximum Exif directory nesting exceeded (corrupt Exif header)" but NO crash. How can I reproduce the problem? Thanks On Wed, 5 Aug 2020 12:13:01 +0800 Anshunkang Zhou wrote: > Package: jhead > Version: 1:3.04-2 > Severity: important > > Dear Maintainer, > > I found a segmentation fault in the latest version of jhead, detailed > information is as follows, the poc is in the mail attachment. > > ## System info > > Ubuntu x86_64, gcc , jhead (latest 1:3.04-2) > > ## Configure > > CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make > > ## Command line > > ./jhead -ft -exifmap -de -purejpg -di -dx @@ > > ## Output > > ``` > Segmentation fault > ``` > > ## AddressSanitizer output > > ``` > ASAN:SIGSEGV > = > ==27891==ERROR: AddressSanitizer: SEGV on unknown address > 0x61a3f288 (pc 0x0042cb79 bp 0x0002 sp 0x7ffefb7a18f0 > T0) > #0 0x42cb78 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:122 > #1 0x42411f in ProcessExifDir /home/seviezhou/jhead/exif.c:866 > #2 0x423e0e in ProcessExifDir /home/seviezhou/jhead/exif.c:852 > #3 0x4255e1 in process_EXIF /home/seviezhou/jhead/exif.c:1041 > #4 0x4103ad in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287 > #5 0x4117ce in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:126 > #6 0x4117ce in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379 > #7 0x408e4e in ProcessFile /home/seviezhou/jhead/jhead.c:905 > #8 0x402e40 in main /home/seviezhou/jhead/jhead.c:1756 > #9 0x7ff98ecdf83f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) > #10 0x406c88 in _start (/home/seviezhou/jhead/jhead+0x406c88) > > AddressSanitizer can not provide additional info. > SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/gpsinfo.c:122 > ProcessGpsInfo > ==27891==ABORTING > ```
Bug#967971: jhead: A Segmentation fault error in jhead 1:3.04-2
Hello, I can't reproduce the crash. I tried with the normal binary and also a new build using your arguments. I get a lot of "Nonfatal Error : 'SEGV-Get32s-exif-333' Illegal number format 1024 for tag in Exif" but NO crash. How can I reproduce the problem? Bye Le 06/08/2020 à 05:14, Anshunkang Zhou a écrit : Package: jhead Version: 1:3.04-2 Severity: important Dear Maintainer, I found a segmentation fault in the latest version of jhead, detailed information is as follows, the poc is in the mail attachment. ## System info Ubuntu x86_64, gcc , jhead (latest 1:3.04-2) ## Configure CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make ## Command line ./jhead -ft -exifmap -de -purejpg -di -dx @@ ## Output ``` Segmentation fault ``` ## AddressSanitizer output ``` ASAN:SIGSEGV = ==17939==ERROR: AddressSanitizer: SEGV on unknown address 0x61a3f28c (pc 0x0041a7f0 bp 0x sp 0x7ffc54eee3a0 T0) #0 0x41a7ef in Get32s /home/seviezhou/jhead/exif.c:333 #1 0x42c908 in ProcessGpsInfo /home/seviezhou/jhead/gpsinfo.c:138 #2 0x42411f in ProcessExifDir /home/seviezhou/jhead/exif.c:866 #3 0x423e0e in ProcessExifDir /home/seviezhou/jhead/exif.c:852 #4 0x4255e1 in process_EXIF /home/seviezhou/jhead/exif.c:1041 #5 0x4103ad in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:287 #6 0x4117ce in ReadJpegSections /home/seviezhou/jhead/jpgfile.c:126 #7 0x4117ce in ReadJpegFile /home/seviezhou/jhead/jpgfile.c:379 #8 0x408e4e in ProcessFile /home/seviezhou/jhead/jhead.c:905 #9 0x402e40 in main /home/seviezhou/jhead/jhead.c:1756 #10 0x7ffacc7e783f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) #11 0x406c88 in _start (/home/seviezhou/jhead/jhead+0x406c88) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/seviezhou/jhead/exif.c:333 Get32s ==17939==ABORTING ``` -- Dr. Ludovic Rousseau
Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark
tag 943639 fixed-upstream pending thank Le 28/10/2019 à 17:28, Ludovic Rousseau a écrit : Le 28/10/2019 à 13:31, Roberto C. Sánchez a écrit : On Sun, Oct 27, 2019 at 06:30:08PM +0100, Ludovic Rousseau wrote: Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit : Package: grisbi Version: 1.2.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When I changed my GTK theme to Adwaita-Dark much of the UI text became unreadable. It appears that some UI elements are specified for particular colors while others are left with default values. This resulted in things like white text on white background, which was impossible to read. I may try to fix this myself, but I am not sure when I may find time. I can reproduce the problem. Screen copy attached. I have no idea how to fix it. I reported the issue upstream in https://www.grisbi.org/bugsreports/view.php?id=1980 If you know how to fix it please share your knowledge. I may try to fix it myself. I don't know how to fix it, as I've never developed anything for GTK. That said, it seems like a good learning opportunity, so I may make an attempt when I can find some time. Nothing is better than your own motivation to fix a bug :-) Feel free to ask for help on the Grisbi developer list at http://listes.grisbi.org/mailman/listinfo/devel or access the upstream project on github at https://github.com/grisbi/grisbi This bug is now fixed upstream. I will close it when the new upstream version is available in Debian. It may already be fixed in version 1.9.91 available in Debian experimental https://packages.debian.org/experimental/grisbi Bye -- Dr. Ludovic Rousseau
Bug#961229: libnfc: New upstream version: 1.7.2
retitle 961229 libnfc: New upstream version: 1.8.0 thank On Fri, 22 May 2020 13:39:28 +0200 Ludovic Rousseau wrote: > On Thu, 21 May 2020 18:37:38 +0200 Ludovic Rousseau > wrote: > > Package: libnfc > > Severity: normal > > > > Hello, > > > > A new upstream version of libnfc is now available (after 5 years). > > https://github.com/nfc-tools/libnfc/releases/tag/libnfc-1.7.2 > > > > Maybe it is a good time to package it. > > Note that the ABI has changed. > A new version 1.8.0 is planned to change the library soname. > > See https://github.com/nfc-tools/libnfc/issues/596 Version 1.8.0 is now available. https://github.com/nfc-tools/libnfc/releases/tag/libnfc-1.8.0 Bye
Bug#961229: libnfc: New upstream version: 1.7.2
On Thu, 21 May 2020 18:37:38 +0200 Ludovic Rousseau wrote: > Package: libnfc > Severity: normal > > Hello, > > A new upstream version of libnfc is now available (after 5 years). > https://github.com/nfc-tools/libnfc/releases/tag/libnfc-1.7.2 > > Maybe it is a good time to package it. Note that the ABI has changed. A new version 1.8.0 is planned to change the library soname. See https://github.com/nfc-tools/libnfc/issues/596 Bye
Bug#961229: libnfc: New upstream version: 1.7.2
Package: libnfc Severity: normal Hello, A new upstream version of libnfc is now available (after 5 years). https://github.com/nfc-tools/libnfc/releases/tag/libnfc-1.7.2 Maybe it is a good time to package it. Thanks -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Le 05/04/2020 à 16:40, Paride Legovini a écrit : Hello Ludovic, On Fri, 3 Apr 2020 15:37:20 +0200 Ludovic Rousseau wrote: When it fails: - is the socket /var/run/pcscd/pcscd.comm still present? This was a hint in the right direction and I think it makes most of the logs I collected useless. Apparently when the problem occurs the /var/run/pcscd/pcscd.comm socket is not there anymore, but systemd still have a file descriptor open for it, as I found out using lsof: COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd1 root 45u unix 0xa066a5154400 0t0 3172053 /run/pcscd/pcscd.comm type=STREAM I think the systemd socket unit (pcscd.socket) does not recreate the socket because of this, and passes a "dead" file descriptor to pcscd. What exactly deletes the pcscd.comm socket is not clear to me. Now after fiddling with pcscd I don't think I have clean logs to provide, I prefer to wait for the problem to happen again and then check if anything relevant is logged. I did try to suspend/resume a few times but but I didn't manage to reproduce the issue. But maybe you know what could be deleting the socket. pcscd can remove the /var/run/pcscd/pcscd.comm socket but only when NOT started by systemd. This is done on init and exit of pcscd. When pcscd is started by systemd you have a log message like: Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() Started by systemd Maybe, sometimes, pcscd does not detect it is started by systemd. But in this case the socket should be re-created by pcscd so that should not be the correct explanation. Or maybe the problem is on the systemd side? You can continue generating logs. They are a good indication of what is happening. You can limit logs to the info level using --info instead of --debug. You can also remove the --apdu argument. If I read correctly your previous message you have logs with: - pcscd is started by systemd - pcscd correctly indicates "Started by systemd" - but the communication is broken (pcsc_scan fails) and I guess the file /var/run/pcscd/pcscd.comm is missing - you stop pcscd: systemctl stop pcscd - you start pcscd: systemctl start pcscd - pcscd correctly indicates "Started by systemd" - the communication is still broken and, I guess, the file /var/run/pcscd/pcscd.comm is still missing To re-create the file /var/run/pcscd/pcscd.comm you need to use: systemctl stop pcscd.socket systemctl start pcscd.socket See also https://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html I still have no clue when and why the socket file is removed. PS: maybe you should change your smart card password if it starts with "c". That was already a temporary password as I did fear the debugging logs might leak it, but thanks for the warning :) Adding a note on the website where the instructions on how to collect logs are given might be a good idea. Good point. Done. Bye -- Dr. Ludovic Rousseau
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Hello Paride, Le 03/04/2020 à 13:20, Paride Legovini a écrit : Hi, I'm also hitting this issue, but after trying a few things I'm not convinced it is strictly a "resume after suspend" problem. But let's proceed with order. I normally keep a OpenPGP smartcard in my laptop's smartcard reader and I use it via scdaemon with disable-ccid. Sometimes when I suspend and resume my laptop I lose access to the smartcard: gnupg/scdaemon can't find it anymore. Restarting pcscd helps (systemctl restart pcscd) often but *not always* helps. I tried to collect logs running pcscd in foreground in a shell, but guess what, it *never* happens if I run it like this. The problem seems to happen only when pcscd is started by systemd, and I found out that I can reproduce it by restarting pcscd several time with systemctl. So I modified pcscd.service like this: [Service] Environment=LIBCCID_ifdLogLevel=0x000F ExecStart=/usr/sbin/pcscd --foreground --debug --apdu #ExecStart=/usr/sbin/pcscd --foreground --auto-exit #ExecReload=/usr/sbin/pcscd --hotplug in order to collect the relevant logs. Here they are. Thanks a lot for your tests and logs. When you write "trying to access the smartcard doesn't work." what happens exactly? Do you have an error from gpg or scdaemon? I ask because I don't see any error reported by pcscd. So maybe the problem is between pcscd and libpcsclite. When it fails: - is the socket /var/run/pcscd/pcscd.comm still present? - what do you get when you run pcsc_scan? (from the pcsc-tools package) Thanks PS: maybe you should change your smart card password if it starts with "c". -- Dr. Ludovic Rousseau
Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog
Le 20/03/2020 à 17:34, Roberto C. Sánchez a écrit : On Fri, Mar 20, 2020 at 05:30:10PM +0100, Ludovic Rousseau wrote: Le 20/03/2020 à 16:40, Roberto C. Sanchez a écrit : Package: grisbi Version: 1.2.2-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems that when choosing "Save" (for example, with Ctrl+S) that the presented dialog does not function correctly. Speceifically, the dialog contains two options: "Cancel" and "Save". Pressing the "Escape" key seems like it should be equivalent to a "Cancel" selection. However, when I attempt this (pressing "Escape" to not have the changes saved), Grisbi still saves the changes. This seems to make it not possible to discard changes in the expected way. Exact. I fixed the problem in Grisbi upstream at https://github.com/grisbi/grisbi/commit/76c4dbb62bae791129b509b297800c98b2b0cd96 Do you think it is important enough that I need to make a new Debian version of Grisbi just to fix this issue? I don't think a special release is needed for this. I am glad that it is fixed already :-) OK I've tagged this bug fixed-upstream to ensure that others who may encounter it know that a fix will come with a future upstream release. If you want you can use Gribi 1.9.90 from Debian experimental. Your bug is not fixed in this version but you may want to try a newer Grisbi. Bye -- Dr. Ludovic Rousseau
Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog
Le 20/03/2020 à 16:40, Roberto C. Sanchez a écrit : Package: grisbi Version: 1.2.2-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems that when choosing "Save" (for example, with Ctrl+S) that the presented dialog does not function correctly. Speceifically, the dialog contains two options: "Cancel" and "Save". Pressing the "Escape" key seems like it should be equivalent to a "Cancel" selection. However, when I attempt this (pressing "Escape" to not have the changes saved), Grisbi still saves the changes. This seems to make it not possible to discard changes in the expected way. Exact. I fixed the problem in Grisbi upstream at https://github.com/grisbi/grisbi/commit/76c4dbb62bae791129b509b297800c98b2b0cd96 Do you think it is important enough that I need to make a new Debian version of Grisbi just to fix this issue? Regards -- Dr. Ludovic Rousseau
Bug#948402: pcsc-lite: please don't build pcscd on i386
Le 08/01/2020 à 09:09, Gianfranco Costamagna a écrit : Package: pcsc-lite Version: 1.8.26-1 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch Dear maintainers, Hello, In Ubuntu, we are in the process of moving the i386 architecture to a compatibility-only layer on amd64. We are keeping pcsc-lite on i386 because it's a build-dependency of a lot of packages, e.g. openjdk* wpa and others, but the pcscd package built from this source has dependencies on other packages that are not being kept as part of the compatibility library set (libccid). We would like to drop this binary package rather than keeping it around in the Ubuntu archive and uninstallable. Would you please consider applying the attached patch, or something like it, to omit building these binary packages on Ubuntu? Thanks for considering, AFAIK Debian does *not* plan to drop support of i386. Why not use the proposed patch on Ubuntu *only*? Bye -- Dr. Ludovic Rousseau
Bug#947883: Enable reader name filter in pcscd
Le 01/01/2020 à 17:51, Pawel Boguslawski a écrit : Package: pcscd Version: 1.8.25-3 Please add --enable-filter option to configure to allow one to use reader name filter build in pcscd: https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html Useful for ignoring USB reader on host and passing it to guest. See also: https://bugs.archlinux.org/task/51912 See also this Ubuntu bug https://bugs.launchpad.net/bugs/1857118 Since this request is now more frequent I plan, as the upstream maintainer of pcsc-lite, to change the configuration to have the filtering enabled by default. So it will not be needed for each GNU/Linux distribution to change the packaging of pcsc-lite. I should release a new upstream version and a new Debian package within a week. Regards, -- Dr. Ludovic Rousseau
Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark
Le 28/10/2019 à 13:31, Roberto C. Sánchez a écrit : On Sun, Oct 27, 2019 at 06:30:08PM +0100, Ludovic Rousseau wrote: Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit : Package: grisbi Version: 1.2.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When I changed my GTK theme to Adwaita-Dark much of the UI text became unreadable. It appears that some UI elements are specified for particular colors while others are left with default values. This resulted in things like white text on white background, which was impossible to read. I may try to fix this myself, but I am not sure when I may find time. I can reproduce the problem. Screen copy attached. I have no idea how to fix it. I reported the issue upstream in https://www.grisbi.org/bugsreports/view.php?id=1980 If you know how to fix it please share your knowledge. I may try to fix it myself. I don't know how to fix it, as I've never developed anything for GTK. That said, it seems like a good learning opportunity, so I may make an attempt when I can find some time. Nothing is better than your own motivation to fix a bug :-) Feel free to ask for help on the Grisbi developer list at http://listes.grisbi.org/mailman/listinfo/devel or access the upstream project on github at https://github.com/grisbi/grisbi Bye -- Dr. Ludovic Rousseau
Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark
Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit : Package: grisbi Version: 1.2.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When I changed my GTK theme to Adwaita-Dark much of the UI text became unreadable. It appears that some UI elements are specified for particular colors while others are left with default values. This resulted in things like white text on white background, which was impossible to read. I may try to fix this myself, but I am not sure when I may find time. I can reproduce the problem. Screen copy attached. I have no idea how to fix it. I reported the issue upstream in https://www.grisbi.org/bugsreports/view.php?id=1980 If you know how to fix it please share your knowledge. I may try to fix it myself. Thanks -- Dr. Ludovic Rousseau
Bug#930446: popularity-contest: unable to submit report, impossible to debug
Le 01/09/2019 à 09:51, Bill Allombert a écrit : On Sat, Aug 31, 2019 at 06:22:03PM +0200, Ludovic Rousseau wrote: Hello Ludovic, This report is about Stefan problem. Stefan problem is that popcon is reporting twice, one with cron.d time and one with the cron.daily fallback, which means somehow the mechanism to detect that the report was already sent did not work. Is it your problem too ? According to the email you send me, your report is also sent at 6:25 which suggests this is the case, since the cron.daily fallback run at 6:25. My problem is the same as the original issue reported by Stefan Fritsch. In my logs I get (same as Stefan): Aug 29 06:25:15 PiHole popularity-contest: unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi. Aug 29 06:25:15 PiHole popularity-contest: unable to submit report I have no idea if the submission worked or not. Check /etc/cron.d/popularity-contest for the time of the cron.d report. $ cat /etc/cron.d/popularity-contest SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 57 7 * * * roottest -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest --crond So the cron job is executed at 7h57. In which case, could you check what is the issue with the timestamp (see the full buildlog) ? Can you be more specific about what you want me to check? What gives ls -l /var/log/popularity-contest* $ LANG=C ls -l /var/log/popularity-contest* -rw-r--r-- 1 root root 24169 Aug 29 07:57 /var/log/popularity-contest -rw-r--r-- 1 root root 0 Aug 29 07:57 /var/log/popularity-contest.0 -rw-r--r-- 1 root root 5563 Aug 22 07:57 /var/log/popularity-contest.1.gz -rw-r--r-- 1 root root41 Aug 22 07:57 /var/log/popularity-contest.2.gz -rw-r--r-- 1 root root 5541 Aug 15 07:57 /var/log/popularity-contest.3.gz -rw-r--r-- 1 root root41 Aug 15 07:57 /var/log/popularity-contest.4.gz -rw-r--r-- 1 root root 5583 Aug 8 07:57 /var/log/popularity-contest.5.gz -rw-r--r-- 1 root root41 Aug 8 07:57 /var/log/popularity-contest.6.gz -rw-r--r-- 1 root root 8451 Aug 1 07:57 /var/log/popularity-contest.new.gpg Do you run some program that change the timestamp of the file /var/log/popularity-contest ? maybe logrotate ? Not that I am aware of. In you have an unrelated problem, please open a separate bug report. The debug output you got just means that the server failed to answer. Sure. Why did the server failed to answer? Probably too many people are trying to submit at the same time. Hence the move to cron.d with a user specific submission time. popcon.debian.org is hosted by pinel.debian.org. I could not find a real load issue from munin graphs at https://munin.debian.org/debian.org/pinel.debian.org/index.html (login dsa-guest, password dsa-guest) Ah OK. popularity-contest has TWO cron configurations: - /etc/cron.daily/popularity-contest - /etc/cron.d/popularity-contest Should I just ignore the messages generated by the cron.daily job? Bye -- Dr. Ludovic Rousseau
Bug#930446: popularity-contest: unable to submit report, impossible to debug
Le 31/08/2019 à 16:05, Bill Allombert a écrit : On Thu, Aug 29, 2019 at 10:38:29PM +0200, Ludovic Rousseau wrote: On Wed, 12 Jun 2019 22:52:59 +0200 Bill Allombert wrote: On Wed, Jun 12, 2019 at 09:46:58PM +0200, Stefan Fritsch wrote: Package: popularity-contest Version: 1.67 Severity: normal Dear Maintainer, on several of my hosts, popularity-contest logs unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi. unable to submit report. But it does not log why and there is no way that I could find to trigger the sending from the command line with debug output enabled. http://popcon.debian.org/cgi-bin/pop is reachable from the host via curl. Also, according to the documentation it should fall back to email, which it does not do. It does not log why it does not do that. Hello Stefan! This comes from /etc/cron.daily/popularity-contest: # try to post the report through http POST if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then for URL in $SUBMITURLS ; do if setsid /usr/share/popularity-contest/popcon-upload \ -u $URL -f $POPCON 2>/dev/null ; then SUBMITTED=yes else logger -t popularity-contest "unable to submit report to $URL." fi done fi /usr/share/popularity-contest/popcon-upload has an option -d for debugging that you could try. I added the -d to get some more debug. Hello Ludovic, This report is about Stefan problem. Stefan problem is that popcon is reporting twice, one with cron.d time and one with the cron.daily fallback, which means somehow the mechanism to detect that the report was already sent did not work. Is it your problem too ? According to the email you send me, your report is also sent at 6:25 which suggests this is the case, since the cron.daily fallback run at 6:25. My problem is the same as the original issue reported by Stefan Fritsch. In my logs I get (same as Stefan): Aug 29 06:25:15 PiHole popularity-contest: unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi. Aug 29 06:25:15 PiHole popularity-contest: unable to submit report I have no idea if the submission worked or not. In which case, could you check what is the issue with the timestamp (see the full buildlog) ? Can you be more specific about what you want me to check? In you have an unrelated problem, please open a separate bug report. The debug output you got just means that the server failed to answer. Sure. Why did the server failed to answer? I have the same problem on different systems, not just one. Bye -- Dr. Ludovic Rousseau
Bug#938958: RM: jpilot -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal jpilot is no more maintained upstream since 2014. Hardware to use with this package (Palm pilot PDA) are no more sold since at least 10 years.
Bug#938957: RM: pilot-link -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal pilot-link is no more maintianed upstream since 2010. It provides a Python2 only package that should be removed. See #937292
Bug#930446: popularity-contest: unable to submit report, impossible to debug
On Wed, 12 Jun 2019 22:52:59 +0200 Bill Allombert wrote: On Wed, Jun 12, 2019 at 09:46:58PM +0200, Stefan Fritsch wrote: > Package: popularity-contest > Version: 1.67 > Severity: normal > > Dear Maintainer, > > on several of my hosts, popularity-contest logs > > unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi. > unable to submit report. > > But it does not log why and there is no way that I could find to trigger > the sending from the command line with debug output enabled. > > http://popcon.debian.org/cgi-bin/pop is reachable from the host via curl. Also, > according to the documentation it should fall back to email, which it does not > do. It does not log why it does not do that. Hello Stefan! This comes from /etc/cron.daily/popularity-contest: # try to post the report through http POST if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then for URL in $SUBMITURLS ; do if setsid /usr/share/popularity-contest/popcon-upload \ -u $URL -f $POPCON 2>/dev/null ; then SUBMITTED=yes else logger -t popularity-contest "unable to submit report to $URL." fi done fi /usr/share/popularity-contest/popcon-upload has an option -d for debugging that you could try. I added the -d to get some more debug. But what I got is not really helpfull. I got an email from cron: From: r...@pihole.xxx.fr (Cron Daemon) To: r...@pihole.xxx.fr Subject: Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) Date: Thu, 29 Aug 2019 06:25:15 +0200 /etc/cron.daily/popularity-contest: Failed to upload, answer '' And in /var/log/messages I have the classic: Aug 29 06:25:15 PiHole popularity-contest: unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi. Aug 29 06:25:15 PiHole popularity-contest: unable to submit report I am using Debian stable (buster) with popularity-contest 1.67 Bye -- Dr. Ludovic Rousseau
Bug#933872: grisbi: rounds JPY to EUR exchange fees value incorrectly when saving gsb file to disk
Le 06/08/2019 à 18:03, Ludovic Rousseau a écrit : Hello I also opened the bug upstream. I may need the help of the upstream author. Feel free to add any more information in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933872 Upstream proposed a fix in http://www.grisbi.org/bugsreports/view.php?id=1961#c5138 I generated a new Debian package with the fix. You can get the amd64 package at http://ludovic.rousseau.free.fr/softwares/grisbi/ Please tell me if the proposed fix works for you or not. Thanks -- Dr. Ludovic Rousseau
Bug#933872: grisbi: rounds JPY to EUR exchange fees value incorrectly when saving gsb file to disk
tags 933872 upstream forwarded 933872 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933872 thanks Hello I also opened the bug upstream. I may need the help of the upstream author. Feel free to add any more information in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933872 Thanks Le 04/08/2019 à 17:33, A.B. a écrit : Package: grisbi Version: 1.2.2-1 Severity: normal File: /usr/bin/grisbi Dear Maintainer, I'm using grisbi for a long time now. Recently I registered a few currency exchange debit transactions. From JPY to EUR and each time I save+close my gsb file, and then reopen it, I get rounded exchange fee (EXF) in my transactions. This behaviour completely messes up my accounting. In order to be better understood, I attached to the present mail one file named exf_bug.gsb. This file contains 4 transactions: 1. [OK] One Initial credit transaction of +100 EUR 2. [OK] One EUR debit transaction of : -15 EUR 3. [KO] One JPY debit transaction of : -1000 JPY (-13,33EUR + 1.67EUR (EXF)) 4. [OK] One last EUR debit transaction of : -10 EUR Before I close my gsb file, everything is OK in grisbi HMI. I.e. There remains 60,00 EUR on the bank account (expected result). If I save+close my gsb file and reopen it, grisbi shows 59,67 EUR as remaining on the bank account (KO). If I give a look at the echange (rate) dialog box of the transaction n°3 (upon 4), the exchange fees have been rounded from 1.67 EUR to 2.0 EUR. And in fact, the gsb file content shows an exf="2.0" for that transaction. Moreover, I registered older currency exchange transactions in the past (e.g. of kind DKK to EUR). Those DKK to EUR transactions works OK. Exchange fees are not rounded unexpectedly. But the one we are talking about are the first one of kind JPY to EUR I'm registering. The only difference between those three currencies is : * EUR : 2 digits max. after floating point * DKK : 2 digits max. after floating point * JPY : *0* digits after floating point Following that analysis, it appears that when floating point formats of both currency source and destination are equal, grisbi behaves great (OK). E.g. DKK to EUR. Nevertheless, it appears that when floating point formats of both currency source and destination are different, grisbi behaves oddly (KO). E.g. JPY to EUR. So, I'm wondering if grisbi is not rounding exchange fees value based on the currency floating point format of the source (instead of the floating point format of the destination -- that applies in my case (as my exchange fees are expressed in EUR and as grisbi exchange (rate) window also seems to express them). As I said, I would have expected that grisbi would have rounded exchange fees value based on the currency floating point format of the destination. Or, in order to be more cautious, I would expect grisbi to round exhcange fees value repecting the biggest of the two max. digits after floating point values. E.g. when exchanging JPY(0) to EUR(2) or EUR(2) to JPY(0), always round to the biggest (0<2) : 2 digits max. after floating point. As I don't know all grisbi usage, I would suggest the last solution not to break the initial behaviour. Thanks a lot in advance for your support. Best regards, -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grisbi depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii grisbi-common 1.2.2-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgoffice-0.10-10 0.10.44-1 ii libgtk-3-0 3.24.5-1 ii libofx7 1:0.9.14-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libssl1.1 1.1.1c-1 ii libxml2 2.9.4+dfsg1-7+b3 ii xdg-utils 1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 grisbi recommends no packages. Versions of packages grisbi suggests: ii firefox-esr [www-browser] 60.8.0esr-1~deb10u1 ii w3m [www-browser] 0.5.3-37 -- no debconf information -- Dr. Ludovic Rousseau
Bug#931462: pcscd: Hangs after a ykman info
Le 05/07/2019 à 16:56, Julien Palard a écrit : Hello Ludovic, It could be interesting to have a pcscd log as documented athttps://pcsclite.apdu.fr/#support Here are the requested infos: $ ykman info Device type: YubiKey 4 [...] Firmware version: 4.3.5 Enabled USB interfaces: OTP+FIDO+CCID Applications OTP Enabled FIDO U2FEnabled OpenPGP Enabled PIV Enabled OATHEnabled FIDO2 Not available $ /usr/sbin/pcscd --version pcsc-lite version 1.8.25. Copyright (C) 1999-2002 by David Corcoran . Copyright (C) 2001-2018 by Ludovic Rousseau . Copyright (C) 2003-2004 by Damien Sauveron . Report bugs to . Enabled features: Linux x86_64-pc-linux-gnu libsystemd serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/etc/reader.conf.d $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster $ lsusb | grep -i yubi Bus 003 Device 030: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID logs attached where I ran the following sequence: mdk@lighthaven$ ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so; ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Card removed: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Enter passphrase for PKCS#11: Card added: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so 0012 [140528082081536] APDU: 00 CB 3F FF 03 5C 01 7E 00 0009 [140528082081536] ifdhandler.c:1303:IFDHTransmitToICC() usb:1050/0407:libudev:2:/dev/bus/usb/003/030 (lun: 0) 0008 [140528082081536] commands.c:1623:CmdXfrBlockAPDU_extended() T=0 (extended): 9 bytes 0017 [140528082081536] -> 00 6F 09 00 00 00 00 31 00 00 00 00 CB 3F FF 03 5C 01 7E 00 0298 [140528082081536] <- 00 81 00 00 00 00 00 31 40 FC 00 0011 [140528082081536] commands.c:1523:CCID_Receive Overrun error 0006 [140528082081536] SW: 0007 [140528082081536] ifdwrapper.c:543:IFDTransmit() Card not transacted: 612 0007 [140528082081536] winscard.c:1620:SCardTransmit() Card not transacted: 0x80100016 The reader reports an error 0xFC Overrun error. According to the CCID specification it is "Overrun error while talking to the ICC". ICC is the smart card. In your case it is the chip inside the token. I have no idea why the token reports such an error. I reader firmware issue? The problem is not with pscsd. I am not sure I can help here. You can try to report the problem on OpenSC-devel mailing list. Maybe someone with YubiKey experience can help. https://github.com/OpenSC/OpenSC/wiki/Mailing-lists Bye -- Dr. Ludovic Rousseau
Bug#931462: pcscd: Hangs after a ykman info
Hello Julien,
Le 05/07/2019 à 15:17, Julien Palard a écrit :
Package: pcscd
Version: 1.8.25-1
Severity: normal
When I use the following sequence of commands:
$ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
$ ssh remote_host hostname
$ ykman info
$ ssh remote_host hostname
the 2nd ssh won't work, I'll get: sign_and_send_pubkey: signing
failed: agent refused operation
If I run ykman info afterwards, it freezes.
I tried stracing pcscd a bit and found it waiting indefinitly in a
nanosleep loop (strace start during a ykman info, before it freezes,
so you have a bit of context):
[pid 14245] accept(3, {sa_family=AF_UNIX}, [110->2]) = 16
[pid 14245] clone(strace: Process 14801 attached
child_stack=0x7f0bd161df30,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID\
, parent_tidptr=0x7f0bd161e9d0, tls=0x7f0bd161e700,
child_tidptr=0x7f0bd161e9d0) = 14801
[pid 14801] set_robust_list(0x7f0bd161e9e0, 24
[pid 14245] alarm(0
[pid 14801] <... set_robust_list resumed> ) = 0
[pid 14245] <... alarm resumed> ) = 0
[pid 14801] read(16, "\f\0\0\0\21\0\0\0", 8) = 8
[pid 14801] read(16, "\4\0\0\0\4\0\0\0\0\0\0\0", 12) = 12
[pid 14801] sendto(16, "\4\0\0\0\4\0\0\0\0\0\0\0", 12, MSG_NOSIGNAL, NULL, 0) =
12
[pid 14801] read(16, "\f\0\0\0\1\0\0\0", 8) = 8
[pid 14801] read(16, "\0\0\0\0\0\0\0\0\0\0\0\0", 12) = 12
[pid 14801] sendto(16, "\0\0\0\0f*Y?\0\0\0\0", 12, MSG_NOSIGNAL, NULL, 0) = 12
[pid 14801] read(16, "\230\0\0\0\4\0\0\0", 8) = 8
[pid 14801] read(16, "f*Y?Yubico YubiKey OTP+FIDO+CCID"..., 152) = 152
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
[pid 14801] nanosleep({tv_sec=0, tv_nsec=1}, NULL) = 0
(at vitam eternam)
Strage thing: there is not a single ioctl during the freez, so I bet
the nanosleep is here to wait for a previous ioctl reply. The process
being waited is the one calling ioctl USBDEVFS_REAPURBNDELAY and it
looks waiting for a poll([{fd=10, events=POLLIN}, {fd=12,
events=POLLIN}, {fd=13, events=POLLOUT}], 3, 6 13
being the fd for the Yubikey.
When this process does a poll it typically get a ([{fd=13,
revents=POLLOUT}]) almost immediatly (I did not straced with timings
though).
Running:
ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
stops the nanosleep loop and everything works again, I do not need to
unplug-replug the key. I tried with two distinct Yubikey 4, one a bit
old and one almost new.
During the ssh failure I see:
[pid 16285] write(1, "03008905 ccid_usb.c:898:ReadUSB() read failed (2/3): -7
LIBUSB_ERROR_TIMEOUT\n", 77) = 77
[pid 16285] write(1, "0123 ifdwrapper.c:543:IFDTransmit() Card not transacted:
612\n", 65) = 65
[pid 16285] write(1, "0092 winscard.c:1626:SCardTransmit() Card not transacted:
0x80100016\n", 73) = 73
Tell me if you're interested in my digging more deeply.
It could be interesting to have a pcscd log as documented at
https://pcsclite.apdu.fr/#support
Thanks
--
Dr. Ludovic Rousseau
Bug#925312: pcscd: Does not work if "used" in wrong order
Hello Joerg, I have no news from you since 3 months now. I documented the problem and solution at https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html With no news from you I will consider that the problem is fixed with my solution and close this Debian bug. Regards, Le 24/03/2019 à 22:15, Ludovic Rousseau a écrit : Le 24/03/2019 à 22:05, Ludovic Rousseau a écrit : Le 24/03/2019 à 21:19, Joerg Jaspert a écrit : On 15351 March 1977, Ludovic Rousseau wrote: I think I found the problem. I think my system disagrees. :) In my case "gpg --card-status" works only if pcscd is NOT running. GnuPG has its own way to access the smart card readers (here a yubikey) Its a yubikey here too. I propose two possible solutions: 1. remove pcscd from your system but that is a drastic change. No PC/SC application will work any more. Not a good thing, it's there for a reason. And I know it worked in stretch. 2. configure scdaemon to NOT use its internal CCID driver but use the PC/SC interface instead To make option 2 just edit/create the scdaemon configuration file as bellow: $ cat ~/.gnupg/scdaemon.conf disable-ccid Done that. Doesn't do anything. Logged out. Killed gpg agent (just in case). Rebooted (damn system, maybe). Nope, nothing. Same behaviour as before. :-( Before you restart pcscd, can you see your YubiKey listed by the pcsc_scan command (from the pcsc-tools package)? Does "gpg --card-status" works as expected? Once you have restarted pcscd, can you see your YubiKey listed by the pcsc_scan command? Does "gpg --card-status" works as expected? What are the USB VendorID & ProductID of your YukiKey token? You can just attach the output of lsusb. Thanks -- Dr. Ludovic Rousseau
Bug#930530: pcscd: Runs with possibly unnecessary privileges
Le 14/06/2019 à 18:02, Kevin Locke a écrit : Package: pcscd Version: 1.8.24-1 Severity: normal Dear Maintainer, Hello Kevin, pcscd currently runs as root. This is a security risk (as pointed out in the SECURITY file shipped with pcscd). It was previously fixed in Bug #606142 and regressed back to root when systemd support was added (setgid was removed in 798d03c). Is there a reason that pcscd needs to run as root, rather than a normal user with access to the necessary device files? If so, could the rationale be documented in the SECURITY file? If not, what would be required to run as a non-root user and would you accept patches that make the necessary changes? You are completely right. It is a known task on my TODO list. See https://salsa.debian.org/rousseau/PCSC/issues/10 I know systemd has many features that could help. Please provide patches upstream (it is not a problem limited to Debian). You can use https://salsa.debian.org/rousseau/PCSC or https://github.com/LudovicRousseau/PCSC to provide pull requests. Maybe you should first discuss ideas and solutions on the pcsclite-muscle mailing list. https://lists.infradead.org/mailman/listinfo/pcsclite-muscle Bye -- Dr. Ludovic Rousseau
