Bug#1007454: libio-dirent-perl: please consider upgrading to 3.0 source format
Thanks for the patch, I'll add it soon. Regards, -- Ludo https://drolez.com/blog/ - Music and Tech Blog https://chezsandro.com - A cool place in Cape Verde :) https://palmopensource.com - Raspberry, retro and solar tinkering
Bug#1077676: pcscd: unprivileged users not authorized to access OpenPGP smart cards
Hello Gian,
Le 31/07/2024 à 22:14, Gian Piero Carrubba a écrit :
Package: pcscd
Version: 2.2.3-1
Severity: normal
Today I've rebooted my unattended-upgrades-enabled sid laptop after a
long time (almost 70 days) and discovered I could not access my smart
cards anymore.
from syslog:
pcscd: ../src/auth.c:145:IsClientAuthorized() Process 31413 (user: 1000) is NOT
authorized for action: access_pcsc
pcscd: ../src/winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC
client
I had to add a polkit rule in order to allow my unprivileged self to use
the cards:
sudo cat /etc/polkit-1/rules.d/40-allow-pcscd.rules
polkit.addRule(function(action, subject) {
if (
subject.isInGroup("plugdev")
&& (
action.id === "org.debian.pcsc-lite.access_pcsc"
|| action.id === "org.debian.pcsc-lite.access_card"
)
) {
return polkit.Result.YES;
}
return polkit.Result.NOT_HANDLED;
});
Given the long time since the previous reboot, I don't know when the
problem has started or where it has originated.
polkit is enabled by default since pcsc-lite 2.0.1 from Nov 2023.
See https://blog.apdu.fr/posts/2023/11/new-version-of-pcsc-lite-201/
So I am surprised you have the issue only now.
Maybe pcscd has started being linked against polkit only recently? If
this is the case, I suggest shipping with the package a polkit rule
similar to the one above and adding a NEWS entry to warn the users. This
would particularly benefit users that depend on the smart card for
logging in.
Local users should have access to pcsc-lite by default
See https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/
Your problem occurs on the login screen?
Or after you are logged in?
Bye
--
Dr. Ludovic Rousseau
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
Le 23/07/2024 à 13:04, Petter Reinholdtsen a écrit : [Ludovic Rousseau] Is there a way to debug my .metainfo.xml *without* uploading a new package in the archive? I tend to use this approach: appstreamcli validate-tree debian/pcscd --explain The issue should be fixed with the upstream commit https://salsa.debian.org/rousseau/PCSC/-/commit/409b1ea65c12f8cbbbd2ca9618cbe6c8855d7acd I will close this bug on the next upstream pcscd package upload. Thanks -- Dr. Ludovic Rousseau
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
Le 23/07/2024 à 11:24, Petter Reinholdtsen a écrit : [Ludovic Rousseau] So it should find pcscd. No? I had the impression that the Appstream data was only fetched from the Debian archive, and have no experience with feeding information via the local disk. The only way I have updated the Appstream data so far is via uploads to the Debian archive. :) Of course. The data should be available when the package is NOT installed. Is there a way to debug my .metainfo.xml *without* uploading a new package in the archive? I just created the file /usr/share/metainfo/fr.apdu.pcsclite.metainfo.xml by hand. Maybe I should use a tool to register it? I am using Debian testing. I have no idea, I suspect I will need help with this one. CC to Matthias, who know a lot more about appstream than me. Thanks -- Dr. Ludovic Rousseau
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
Le 22/07/2024 à 19:28, Petter Reinholdtsen a écrit : Can you try the appstream2modaliases script in the source and see what show up for pscsd there? It uses the same python code as isenkram-lookup to fetch appstream modalias values. $ ./appstream2modaliases | grep pcscd $ It returns nothing. $ strings /var/cache/swcatalog/cache/fr-FR-local-metainfo.xb | grep -C 2 pcscd velopp continu pcscd Middleware to access a smart card using PC/SC The purpose of PC/SC Lite is to provide a Windows(R) SCard $ strings /var/cache/swcatalog/cache/fr-FR-os-catalog.xb | grep -C 2 pcscd $ I used strace and I see that appstream2modaliases reads the file /var/cache/swcatalog/cache/fr-FR-local-metainfo.xb So it should find pcscd. No? I can remove the cache files /var/cache/swcatalog/cache/* and recreate them using "sudo appstreamcli refresh" but it does not solve the problem. How did you add the appstream entry? Which version of Debian is this? We might have to ask the appstream maintainer. I just created the file /usr/share/metainfo/fr.apdu.pcsclite.metainfo.xml by hand. Maybe I should use a tool to register it? I am using Debian testing. Thanks -- Dr. Ludovic Rousseau
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
On Wed, 17 Jul 2024 19:03:03 +0200 Petter Reinholdtsen wrote: > You can for example test isenkram using 'apt install isenkram-cli && apt > update && isenkram-lookup'. I have a problem with isenkram-cli. I was not able to find where to report bugs. There is no issue tracker on https://salsa.debian.org/debian/isenkram I am using this metainfo file in /usr/share/metainfo/fr.apdu.pcsclite.metainfo.xml fr.apdu.pcsclite MIT pcscd Middleware to access a smart card using PC/SC The purpose of PC/SC Lite is to provide a Windows(R) SCard interface in a very small form factor for communicating to smart cards and smart cards readers. The PC/SC daemon is used to dynamically allocate/deallocate reader drivers at runtime and manage connections to the readers. PCSC-lite project https://pcsclite.apdu.fr/ usb:*ic0Bisc00ip* usb:v058Fp9540d0120dc00dsc00dp00ic0Bisc00ip00in00 It looks like it works fine with appstreamcli: $ appstreamcli what-provides --details modalias "usb:v058Fp9540d0120dc00dsc00dp00ic0Bisc00ip00in00" Identificateur: fr.apdu.pcsclite [generic] Identifiant interne: system/package/os/fr.apdu.pcsclite/* Nom: pcscd Résumé: Middleware to access a smart card using PC/SC Page d’accueil: https://pcsclite.apdu.fr/ Développeur: PCSC-lite project Description: The purpose of PC/SC Lite is to provide a Windows(R) SCard interface in a very small form factor for communicating to smart cards and smart cards readers. The PC/SC daemon is used to dynamically allocate/deallocate reader drivers at runtime and manage connections to the readers. Éléments fournis: ↓ Modalias: - usb:*ic0Bisc00ip* - usb:v058Fp9540d0120dc00dsc00dp00ic0Bisc00ip00in00 But then isenkram-lookup does not find pcscd: $ isenkram-lookup usb:v058Fp9540d0120dc00dsc00dp00ic0Bisc00ip00in00 scdaemon I guess it is a cache file that is not updated or something like that. But I have no idea how to debug that. Can you help?
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
Le 16/07/2024 à 19:47, Petter Reinholdtsen a écrit : [Ludovic Rousseau] *ic0Bisc00ip* (I have no idea how to parse that) The commit message for this from 2013 was "Propose pcscd for any smart card reader." I assume it map to any smart card reader. I do not remember any more how I came up with this idea. It was a commit message for which software? isenkram? Do you have an URL of the commit? Why add only these 2 devices? To be honest, I have no idea. I am working my way through the list of hardware->package mappings in the isenkram modaliases file, to try to get them all into appstream. My best guess is that those are the USB ids of smartcard readers I had access to before 2013, which was when those two were added to git. I never used isenkram. I will have a look. Bye -- Dr. Ludovic Rousseau
Bug#1076439: pcscd: Add Appstream metainfo announcing HW support
Hello Petter, Le 16/07/2024 à 13:43, Petter Reinholdtsen a écrit : Package: pcscd Version: 1.9.9-2 Tags: patch User: p...@hungry.com Usertags: appstream-modalias Here is a patch to add Appstream metainfo XML announcing the hardware handled by this package. Including this information in the package will ensure programs mapping hardware to packages using Appstream information, like the isenkram package, will know that this package is useful on machines where the USB IDs are discovered. I guess the USB IDs you want to add are: vendor 0x20A0 product 0x4107 vendor 0x0B97 product 0x7772 *ic0Bisc00ip* (I have no idea how to parse that) It looks like vendor 0x20A0 is Flirc and 0x0B97 is O2Micro, Inc. Why add only these 2 devices? pcscd itself does NOT support any reader. You need to install one (or more) driver(s). The "default" driver is libccid and has support for 679 readers https://ccid.apdu.fr/select_readers/?section%E2%89%A0disabled§ion%E2%89%A0unsupported Maybe the Appstream metainfo for pcscd should contain only the USB class 11 (CCID devices). https://www.usb.org/document-library/smart-card-ccid-version-11 All recent USB readers are CCID now. What should I do? Bye -- Dr. Ludovic Rousseau
Bug#1051065: weex: d/copyright: Incorrect upstream source
On Tue, Jul 09, 2024 at 10:11:37PM +0200, Bastian Germann wrote: > I am uploading a NMU to DELAYED/10 in order to fix this. > Please find the debdiff attached. Hi! This package is really a native one, I'm the last maintainer. I think I simply forgot to upload the source to sourceforge... Regards, Ludo
Bug#1074245: pam_pkcs11 manpage has no useful information and referes to non-existing pam_pkcs11.conf
Le 25/06/2024 à 07:21, Michael Tokarev a écrit : Package: libpam-pkcs11 Version: 0.6.12-1 Severity: normal the pam_pkcs11 manpage contains no information whatsoever about how to use the module. Also, it refers to pam_pkcs11.conf manpage which is not shipped with the package. The result of all this is that the module is basically unusable. It isn't even clear where pam_pkcs11.conf file should be. Okay, examples/READMEs shipped in /usr/share/doc/libpam-pkcs11/ helps a bit, also strings and strace tools, but it's not where one looks for the info usually. Hello, You can find more documentation on the project web page: https://github.com/OpenSC/pam_pkcs11/blob/master/README.md PAM-PKCS11 User Manual is available at https://opensc.github.io/pam_pkcs11/doc/pam_pkcs11.html I am not sure the manpages should contain everything. As indicated in pam_pkcs11(8) the pam_pkcs11.conf file should be at /etc/pam_pkcs11/pam_pkcs11.conf I agree the reference to pam_pkcs11.conf(5) is incorrect and should be fixed. I reported the issue upstream at https://github.com/OpenSC/pam_pkcs11/issues/76 Bye -- Dr. Ludovic Rousseau
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#1066228: xjdic: FTBFS: implicit declaration of functions
On Wed, Mar 27, 2024 at 11:12:09AM +0100, Bastian Germann wrote: > Please find a patch included. Thanks ! Will upload this soon. Ludo -- https://drolez.com/blog/ - Music and Tech Blog https://palmopensource.com - Raspberry, retro and solar tinkering
Bug#1064726: Should I upload 0ad involved in wxwidgets3.2 migration?
Hello Debian Release team, 0ad has a FTBFS bug #1064726. I have a new version with the fix ready for upload. But when trying to upload I get: - $ dupload --to debian-ssh *_source.changes --no dupload note: no announcement will be sent. Checking OpenPGP signatures before upload..signatures are ok Checking Debian transitions... Warning: Source package 0ad is part of ongoing transitions: <https://release.debian.org/transitions/html/auto-curl> <https://release.debian.org/transitions/html/auto-libpng1.6> <https://release.debian.org/transitions/html/auto-wxwidgets3.2> If the upload does not solve issues caused by these transitions, then it might disrupt them by adding delays or entangling them. For more information, please read: <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook> Note: If you are aware of this and do not want to be warned, you can disable this hook from the configuration file, skip it with --skip-hooks or set the one-off environment variable DUPLOAD_SKIP_HOOKS, or alternatively you can reply to the following prompt. Continue anyway? (yes/NO) - I see 0ad listed in https://release.debian.org/transitions/html/auto-wxwidgets3.2.html Of course the rebuild failed because the FTBFS fix is not yet in unstable. Should I upload a new version of 0ad to help the wxwidgets3.2 migration? Should I wait for 0ad to be removed from testing (planned in 5 days)? Please Cc: me on reply. Thanks -- Dr. Ludovic Rousseau
Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2
Le 03/03/2024 à 17:13, Adrian Bunk a écrit : Source: ausweisapp2 Version: 2.0.3-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Ludovic Rousseau https://buildd.debian.org/status/logs.php?pkg=ausweisapp2&ver=2.1.0-1 ... /<>/src/card/pcsc/PcscUtils.h:112:46: error: ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean ‘SCARD_E_UNKNOWN_RES_MSG’? 112 | Scard_E_Unknown_Res_Mng = returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error code was returned from a layered component. */ | ^~~ ... This is not a regression in the new ausweisapp2 upload, but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed): https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237 "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG" Exact. I now discover that Windows does define BOTH values: SCARD_E_UNKNOWN_RES_MSG 0x8010002B in https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpesc/9861f8da-76fe-41e6-847e-40c9aa35df8d SCARD_E_UNKNOWN_RES_MNG 0x8010002B in https://learn.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values I guess pcsc-lite will also have to define both values. I will release a new pcsc-lite version soon. Sorry. -- Dr. Ludovic Rousseau
Bug#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#1029448: alire in Debian; dependencies of the package
Stephane Carrez writes: > Alire does not directly use XML/Ada nor GNATPRJ. > These shared libraries are linked/used by libgnatcoll.so.21 and > libgnatprj.so.10. Ah, ok, in that case the dependencies are already handled i.e. the package libgnatcoll21 depends on libxmlada-* and libgnatprj10. So you don't need to do anything more. I'll try to upload. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
> Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgnat-12 (>= 12.2.0), > libgnatcoll21 (>= 23.0.0), libxmlezout7 (>= 1.06.2) is at odds with > ciceron@theia:~/debian$ ldd /usr/bin/alr > linux-vdso.so.1 (0x7ffc36dca000) > libgnatcoll.so.21 => /lib/x86_64-linux-gnu/libgnatcoll.so.21 > (0x7f1508e0) > libxmlezout.so.7 => /lib/x86_64-linux-gnu/libxmlezout.so.7 > (0x7f150a71b000) > libgnarl-12.so => /lib/x86_64-linux-gnu/libgnarl-12.so > (0x7f150a6cf000) > libgnat-12.so => /lib/x86_64-linux-gnu/libgnat-12.so > (0x7f150880) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f150a6af000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f150861f000) > libgnatprj.so.10 => /lib/x86_64-linux-gnu/libgnatprj.so.10 > (0x7f1507c0) > libxmlada_schema.so.7 => /lib/x86_64-linux-gnu/libxmlada_schema.so.7 > (0x7f150a5d7000) > libxmlada_dom.so.8 => /lib/x86_64-linux-gnu/libxmlada_dom.so.8 > (0x7f15095de000) > libxmlada_sax.so.7 => /lib/x86_64-linux-gnu/libxmlada_sax.so.7 > (0x7f150958c000) > libxmlada_input.so.7 => /lib/x86_64-linux-gnu/libxmlada_input.so.7 > (0x7f150957d000) > libxmlada_unicode.so.7 => > /lib/x86_64-linux-gnu/libxmlada_unicode.so.7 (0x7f150780) > /lib64/ld-linux-x86-64.so.2 (0x7f150a741000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f150949e000) You need to add libgnatprj10, libxmlada-schema7 etc. to the dependencies; preferably in an automated way. You're almost there, keep up the good work. Also, I've checked that no existing package provides a file named /usr/bin/alr, so you're good in that respect. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
Stephane Carrez writes: > By not depending on the GNAT compiler installed, you can use Alire with > several newer > or older compiler as you wish. This may be fine on operating systems that lack a package manager but this contradicts the Debian Ada Policy, which requires all Ada packages to depend on the same gnat compiler. Therefore, please package alire in such a way that the binary package depends on, and uses, the existing Debian packages i.e. gnat-12, libgnatcoll21 and libxmlezout7 at run-time, and build-depends and uses the corresponding -dev packages at compile time. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
Here is what I get with dpkg --info alire_1.2.1-2_amd64.deb after building it: new Debian package, version 2.0. size 3434464 bytes: control archive=1560 bytes. 476 bytes,13 lines control 2386 bytes,35 lines md5sums Package: alire Version: 1.2.1-2 Architecture: amd64 Maintainer: Stephane Carrez Installed-Size: 17740 Depends: libc6 (>= 2.35) Section: devel Priority: optional Homepage: https://github.com/alire-project Description: Ada package manager. A catalog of ready-to-use Ada libraries plus a command-line tool (`alr`) to obtain, build, and incorporate them into your own projects. It aims to fulfill a similar role to Rust's `cargo` or OCaml's `opam`. As you can see, it does not depend on libgnat-12 and does not even recommend gnat. This seems suspicious to me. Could you please check that the dependencies are generated correctly? -- Ludovic Brenta.
Bug#1029448: Debian package for Alire 1.2.1
OK, after a little struggling I managed to build the package (notably, g...@github.com:alire-project/alire.git requires permissions which I don't have, used https://github.com/alire-project/alire.git). During the build I noticed that alire pulls and recompiles several libraries it depends on. This violates Debian policy; a Debian package must never duplicate another. I notice gnatcoll and xmlezout among the dependencies that are already packaged for Debian. There may be others I didn't see. Therefore, please update the packaging of alire to build-depend on these existing packages and not to recompile them from source. I have filed bug #1029448 to track the introduction of alire into Debian. A Debian bug is also a dedicated, public mailing list: in this case, 1029...@bugs.debian.org. -- Ludovic Brenta.
Bug#1029448: ITP: alire -- Package manager for Ada sources
Package: wnpp Owner: Ludovic Brenta Severity: wishlist * Package name: alire Version : 1.2.1 Upstream Author : Alejandro R. Mosteo and others * URL or Web page : https://github.com/alire-project * License : GPLv3 Description : Package manager for Ada sources ALIRE: Ada LIbrary REpository. A catalog of ready-to-use Ada libraries plus a command-line tool (alr) to obtain, build, and incorporate them into your own projects. It aims to fulfill a similar role to Rust's cargo or OCaml's opam. This is a source package manager, in contrast to apt which is a binary package manager. -- Ludovic Brenta.
Bug#1029405: flightgear: crashes on receiving some real-time weather reports
Package: flightgear Version: 1:2020.3.16+dfsg-1+b2 Severity: important Forwarded: https://sourceforge.net/p/flightgear/codetickets/2765/ Tags: upstream fixed-upstream When real-time weather is enabled, some METAR strings received from the weather servers can cause fgfs to crash. A workaround is to disable real-time weather, an important feature of flightgear. This upstream commit fixes; it would be nice if it were backported before the freeze of bookworm. https://sourceforge.net/p/flightgear/flightgear/ci/86f82994bec00ecbe791b61530b229b22c7d51c8 Thank you! -- Ludovic Brenta.
Bug#1028045: php-8.1-solr and php-solr and missing in testing (hard package freeze in 2 months)
Package: php-8.1-solr Version: 2.5.1+2.4.0-15 Hi, it seems that php-8.1-solr (and php-solr) aren't in testing at all at current time of write, and last changelog entry is from 08 Mar 2022 : -- Ondřej Surý Tue, 08 Mar 2022 15:09:07 +0100 If by any chance I can help somehow, let me know (I'm not enrolled as d-d). Thanks for all the fish, -- Ludovic Pouzenc Ingénieur Informatique de Gestion Direction du Numérique - Service des Systèmes Applicatifs 04 79 75 83 54
Bug#1027065: Clarification
On bookworm (testing) I get:
$ gm2 --version
gm2 (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gm2 hello.mod
hello.mod:1:2: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’
1 | FROM StrIO IMPORT WriteString, WriteLn;
| ^~~~
hello.mod:1:2: error: compilation failed
Adding a first line, "MODULE hello;" makes the program legal but then I
get the same symptoms as in the original bug report.
Adding -fpim2 or -fpim3 to the compiler command line has no effect.
Adding -fiso silences the compiler even though StrIO is not an ISO
module. Therefore a complete workaround is:
$ cat hello.mod
MODULE hello;
FROM StrIO IMPORT WriteString, WriteLn;
BEGIN
WriteString('hello world');
WriteLn
END hello.
$ gm2 -fiso hello.mod -o hello
$ ./hello
hello world
It seems that libm2pim.so lacks some necessary functions which
libm2iso.so has.
--
Ludovic Brenta.
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#1025765: Upstream resolved the issue
Upstream updated recently to 0.3.6: https://github.com/micahflee/torbrowser-launcher/releases/tag/v0.3.6 Reason for the update: Tor Browser 12.0 no longer uses locales, so the download URL and local path have changed All prior versions of torbrowser-launcher are probably broken and unusable. -- Cheers, Ludovic
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#990047: timeshift: Not possible to browse content of snapshot via the gui
Le 04/08/2022 à 23:28, Steve M a écrit : Ludovic, Timeshift first uses xdg-open to call the default tool of your desktop environment as it in turn calls gvfs-open, kde-open, exo-open, gnome- open, etc. as appropriate. On my Debian desktop with KDE running xdg- open and kde-open launche Dolphin, but on my Pop_OS laptop xdg_open is not installed and there is no gvfs-open for some reason. In the event that xdg_open fails, Timeshift tries in order to launch nemo, nautilus, thunar, io.elementary.files, pantheon-files, marlin, and dolphin lastly. In your case it seems that maybe xdg-open is resulting in "code" being called due to your Gnome settings. The command `xdg-mime query default inode/directory` should report out what the default file browser is set to. You can also look in ~/.config/mimeapps.list to see what it is set to. I think you can just edit this file or run a command similar to `xdg-mime default org.gnome.Nautilus.desktop inode/directory` to make a change. Please let me know how this works out as it may be worth asking upstream for a more robust means of opening the default file manager. Thanks -Steve Steeve, Okay. I see the catch! The command `xdg-mime query default inode/directory` returns org.gnome.Nautilus.desktop (as expected) when I run it as my user. But, as Timeshift runs as root, if I run the same xdg-mime command as root I get `code.desktop` :( root doesn't have any `~/.config/mimeapps.list file`. And it sure won't use the settings I have in my account. After purging the VSCode package, the xdg-mime returns org.gnome.Nautilus.desktop as one would expect. As root, `xdg-mime default org.gnome.Nautilus.desktop inode/directory` creates the cat ~/.config/mimeapps.list enforcing nautilus as the default application. Fixing the behaviour when VSCode is installed. A diff of my /etc folder after VSCode install show this change brought by the package. Adding VSCode for inode/directory if I understand it properly : ``` diff --git a/mailcap b/mailcap index 7167022..2d64e78 100644 --- a/mailcap +++ b/mailcap @@ -84,6 +84,10 @@ application/xhtml_xml; /usr/bin/chromium %s; test=test -n "$DISPLAY" application/x-mimearchive; /usr/bin/chromium %s; test=test -n "$DISPLAY" x-scheme-handler/http; /usr/bin/chromium %s; test=test -n "$DISPLAY" x-scheme-handler/https; /usr/bin/chromium %s; test=test -n "$DISPLAY" +x-scheme-handler/vscode; /usr/share/code/code --open-url %s; test=test -n "$DISPLAY" +text/plain; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" +inode/directory; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" +application/x-code-workspace; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" application/vnd.iccprofile; /usr/bin/gcm-import %s; test=test -n "$DISPLAY" application/pkcs12; /usr/bin/gcr-viewer %s; test=test -n "$DISPLAY" application/pkcs12+pem; /usr/bin/gcr-viewer %s; test=test -n "$DISPLAY" ``` So, I guess that Timeshift does it right. And it's VSCode causing trouble to the party. -- Ludovic Poujol
Bug#1013929: src:goffice: FTBFS on mips64el
Le 02/08/2022 à 11:27, Dmitry Smirnov a écrit : Hi Ludovic, On Sunday, 31 July 2022 12:36:04 AM AEST Ludovic Rousseau wrote: I am the Debian maintainer of the package grisbi that depends on libgoffice-0.10-10 I see no update on this bug since 3 weeks. It looks like the fix is proposed upstream at https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045 Sorry, I'm being very slow lately... I've applied the upstream patch but unfortunately it did not fix the problem... I think we now have a *different* issue. The initial build failure https://buildd.debian.org/status/fetch.php?pkg=goffice&arch=mips64el&ver=0.10.52-2&stamp=1656999642&raw=0 was during execution of dh_auto_build command: /usr/bin/ld: .libs/goffice-0.10-scan.o: in function `get_object_types': ./docs/reference/goffice-0.10-scan.c:207: undefined reference to `go_complexl_get_type' /usr/bin/ld: ./docs/reference/goffice-0.10-scan.c:207: undefined reference to `go_complexl_get_type' collect2: error: ld returned 1 exit status 2022-07-05 05:40:30,271:scangobj.py:execute_command:1289:WARNING:Linking scanner failed: 1, command: /bin/bash ../../libtool --tag=CC --mode=link mips64el-linux-gnuabi64-gcc -lgobject-2.0 -lglib-2.0 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -Wall -Werror=init-self -Werror=missing-include-dirs -Wsign-compare -Werror=pointer-arith -Wchar-subscripts -Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn -Werror=missing-prototypes -Werror=implicit-function-declaration -Wmissing-declarations -Wno-pointer-sign -Werror=format-security -Wstrict-prototypes -Wno-error=format-nonliteral -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib goffice-0.10-scan.lo ../../goffice/libgoffice-0.10.la -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgsf-1 -lrsvg-2 -lm -lxslt -lxml2 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib -o goffice-0.10-scan make[3]: *** [Makefile:695: scan-build.stamp] Error 1 make[3]: Leaving directory '/<>/docs/reference' make[2]: *** [Makefile:438: all-recursive] Error 1 make[2]: Leaving directory '/<>/docs' make[1]: *** [Makefile:552: all-recursive] Error 1 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j4 returned exit code 2 make: *** [debian/rules:70: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 With the new upstream patch the build failure is during ecxecution of dpkg-gensymbols command: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libgoffice-0.10-10/DEBIAN/symbols doesn't match completely debian/libgoffice-0.10-10.symbols --- debian/libgoffice-0.10-10.symbols (libgoffice-0.10-10_0.10.52-3_mips64el) +++ dpkg-gensymbolsz0mJDF 2022-08-02 08:51:19.169391884 + @@ -60,22 +60,22 @@ go__VOID__INT_BOOLEAN_BOOLEAN_BOOLEAN@Base 0.9.0 go_accumulator_add@Base 0.9.0 go_accumulator_add_quad@Base 0.9.1 - go_accumulator_add_quadl@Base 0.9.1 - go_accumulator_addl@Base 0.9.0 +#MISSING: 0.10.52-3# go_accumulator_add_quadl@Base 0.9.1 +#MISSING: 0.10.52-3# go_accumulator_addl@Base 0.9.0 go_accumulator_clear@Base 0.9.0 - go_accumulator_clearl@Base 0.9.0 +#MISSING: 0.10.52-3# go_accumulator_clearl@Base 0.9.0 [...] Some symbols, ending with "l", were previously defined but are no more present. From the header file https://gitlab.gnome.org/GNOME/goffice/-/blob/master/goffice/math/go-accumulator.h#L29 we see that the symbol go_accumulator_addl() is defined only if GOFFICE_WITH_LONG_DOUBLE is defined. But in debian/rules we still have "--without-long-double" option for mips64el. I think that is the source of the new problem. Have you tried to *revert* https://salsa.debian.org/debian/goffice/-/commit/3cd973d85f5b6d337100270e068f09fd30d8cea5 and keep only the new upstream patch? Hope this helps. -- Dr. Ludovic Rousseau
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
Steeve, Good question. And, you're right, thanks ! I thought it was some kind of "internal browser" provided with timeshift. But after looking more closely, it was actually trying to start VSCode ! :s And it's the one that do not like to be run as root. Not sure why or how it decided to use it instead of the Gnome file browser. But apt remove of it "fixed" the issue. I don't see any settings for that in the timeshift GUI. I'm not sure how I can force it to use the default gnome file browser :( Thanks -- Ludovic Poujol
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#1015974: Should gnat-gps be removed?
severity 1015974 normal retitle 1015974 gnat-gps: new version available using python 3 thanks Upstream has finally migrated gnat-gps to python 3 but too late for Debian 11. We will package the new upstream version as part of the next Ada transition (to gnat-12 or gnat-13). In the mean time, this package will remain in unstable. -- Ludovic Brenta.
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#1012046: References / previous reports
Hi, Friends pointed me out to older bugs reports of the quite same problem with libvte. Situation has changed since but it seems kept in the wrong choices to me... Problems are there since 09/2009 (vte-0.21.6). https://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html It is pointing out that the suggestion I made in previous comment was also made in 2015 and has drawbacks : [...] it is inherited by all child processed launched inside the terminal which is probably not what they want. https://bugzilla.gnome.org/show_bug.cgi?id=631685#c50 Someone pointed out inhttps://bugzilla.xfce.org/show_bug.cgi?id=8183: While setting TMPDIR to a shm or tmpfs based location is a nice workaround for those who definitely want their scrollback in memory, it is cumbersome: it is inherited by all child processed launched inside the terminal which is probably not what they want. Moreover, it's not feasible to set this in some global environment definition file. For these people it would be convenient to support VTETMPDIR - if defined, it would take precedence over the standard tmp dir locations. Regards,
Bug#1012046: Configuration solution
Hi, I just found a "solution" to get rid of the problem without recompiling anything : TMPFILE env var is taken into account. I have added a systemd override file for my user. It may be useful to have it globally by default in the distro. $ systemctl --user cat gnome-terminal-server.service | tail # /home/lpouzenc/.config/systemd/user/gnome-terminal-server.service.d/override.conf [Service] RuntimeDirectory=gnome-terminal-server Environment=TMPDIR=%t/gnome-terminal-server After closing and opening my gnome session again : $ tr '' 'n' < /proc/$(pidof gnome-terminal-server)/environ | grep TMP TMPDIR=/run/user/1000/gnome-terminal-server $ lsof -np $(pidof gnome-terminal-server) | tail -n5 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc Output information may be incomplete. gnome-ter 15142 lpouzenc 12u unix 0xf567608e 0t0 252993 type=STREAM (CONNECTED) gnome-ter 15142 lpouzenc 13u CHR 5,2 0t0 85 /dev/ptmx gnome-ter 15142 lpouzenc 14u CHR 5,2 0t0 85 /dev/ptmx gnome-ter 15142 lpouzenc 15u REG 0,52 458752 674 /run/user/1000/gnome-terminal-server/#674 (deleted) gnome-ter 15142 lpouzenc 16u REG 0,52 65536 675 /run/user/1000/gnome-terminal-server/#675 (deleted) Hope it could help others, Cheers, Ludovic
Bug#1012046: /usr/libexec/gnome-terminal-server: gnome-terminal-server writes on disk data when a program output data on term
Package: gnome-terminal
Version: 3.44.0-1
Severity: normal
File: /usr/libexec/gnome-terminal-server
X-Debbugs-Cc: bugrepo...@pouzenc.fr
Dear Maintainer,
I see on debian 10, 11 and testing a potential security problem with
gnome-terminal-server. It makes IO on disk when some program output on terminal.
It uses deleted files in /tmp instead of no files or files in RAM in /run.
My use case is sysadmin a lot of machines, with sometimes confidential
data displayed on terminal. For me everything should be in RAM as
xterm does.
The simplest way to spot code path that seems to be bad for me is :
* install debian 10, 11 or testing on a physical amd64 computer
* open a gnome session with a normal user
* open a gnome-terminal
* wait until there is not significant activity on IO physical LED
* start the following command : yes
* terminal starts to scroll fast
* IO LED should go to "solid on" now, because many IO
* sudo apt install iotop strace
* sudo iotop should display something like :
Total DISK READ: 0.00 B/s | Total DISK WRITE: 2.21 M/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 191.00 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO>COMMAND
2260 be/4 lpouzenc0.00 B/s 176.86 K/s ?unavailable?
gnome-terminal-server
1 be/4 root0.00 B/s0.00 B/s ?unavailable? init
2 be/4 root0.00 B/s0.00 B/s ?unavailable? [kthreadd]
* sudo strace -p2260 -fc # for 10 seconds or so
strace: Process 2260 attached with 4 threads
^Cstrace: Process 2260 detached
strace: Process 2315 detached
strace: Process 2316 detached
strace: Process 2327 detached
% time seconds usecs/call callserrors syscall
-- --- --- - -
66,590,9991151546 646 poll
32,060,480939 4100426 4 read
0,310,004600 2 2156 pread64
0,260,003925 4 915 593 recvmsg
0,190,002921 1 2334 pwrite64
0,160,002460 1 1898 ftruncate
0,130,001926 6 312 write
0,080,001240 10 116 fallocate
0,070,001086 7 13631 futex
0,050,000774 774 1 restart_syscall
0,040,000645 1157 sendmsg
0,040,000550 775 writev
0,010,000109 13 8 ioctl
0,000,45 220 clock_nanosleep
-- --- --- - -
100,001,500335 13109100 628 total
* sudo strace -p2260 -fo /dev/shm/gts
* less /dev/shm/gts
[...]
2260 write(14, "\r", 1)= 1
2260 recvmsg(3, {msg_namelen=0}, 0)= -1 EAGAIN (Ressource temporairement
non disponible)
2260 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
events=POLLIN}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI},
{fd=19, events=POLLIN|POLLPRI}], 6, 600) = 1 ([{fd=14, revents=POLLIN}])
2260 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
2260 read(14, "\0\r\n\33[?2004l\r", 8136) = 12
2260 read(14, 0x562c26142083, 8125)= -1 EAGAIN (Ressource temporairement
non disponible)
2260 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
2260 recvmsg(3, {msg_namelen=0}, 0)= -1 EAGAIN (Ressource temporairement
non disponible)
2260 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
events=POLLIN}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI},
{fd=19, events=POLLIN|POLLPRI}], 6, 10) = 1 ([{fd=4, revents=POLLIN}])
2260 read(4, "\2\0\0\0\0\0\0\0", 16) = 8
2260 recvmsg(3, {msg_namelen=0}, 0)= -1 EAGAIN (Ressource temporairement
non disponible)
2260 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
events=POLLIN}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI},
{fd=19, events=POLLIN|POLLPRI}], 6, 10) = 1 ([{fd=14, revents=POLLIN}])
2260 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
2260 read(14, "\0y\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny"...,
8125) = 1361
2260 read(14, "\0\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r"...,
6765) = 289
2260 read(14, "\0\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r"...,
6477) = 295
2260 read(14, "\0\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r"...,
6183) = 292
2260 read(14, "\0\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r"...,
5892) = 292
2260 read(14, "\0\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r"...,
5601) = 288
2260 read(14, "\0y\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny\r\ny"...,
5314) = 262
[...]
* sudo lsof -np 2260 | grep -v mem
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000
Bug#1009906: haproxy: HTTPS proxyfied requests randomly delayed by 50 seconds (default timeout server)
Package: haproxy
Version: 2.2.9-2+deb11u3
Severity: important
X-Debbugs-Cc: bugrepo...@pouzenc.fr
Dear Maintainer,
We have a (Wordpress) PHP web-site hosted on 3 LAMP nodes. We use haproxy to
load-balance the incomming web trafic.
We've got 240k lines of apache2 access log yesterday.
The problem can be reproduced with a test infra without any concurrent user
and a basic test.php thats readfile("jquery.min.js")
and a basic index.html referencing multiple (24) times the test.php
to have Firefox starting multiple HTTP requests in parallel.
The problem is hard or impossible to trigger with Firefox with http2 enabled.
The problem is easy to reproduce with firefox forced in http/1.1 mode.
The problem doesn't show with a echo "Hello World" in test.php,
it seems that the response size is important. 30kio is enough to trigger it
for sure.
Out of 25 requests (including GET /), Firefox will get results about 20 of
them, and about 4 will be delayed by a huge amount of 50 seconds.
(50 seconds if haproxy have : default timeout server 5).
I tried nbproc 1 and nbthreads 1 with no improvements.
I tried haproxy 2.4.15-1~bpo11+1 and it DOES fix the situation without changing
anything else.
# apt install -t bullseye-backports haproxy
I didn't find any bugreports mentionning major troubles in "basic" usage of
haproxy.
I post it here to get someone else luck with Googling about the troubles I hit.
I can't find exactly what line in haproxy changelog could correspond to this.
I think I can try, if useful, to find the smallest configuration that breaks.
PHP seems unrelated. Direct access to the apache don't show up any trouble.
It may be broken in Ubuntu 21.04 (hirsute) and Ubuntu 21.10 (impish) also.
Thanks for all the fish,
Ludovic
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread)
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 haproxy depends on:
ii adduser 3.118
ii dpkg 1.20.9
ii init-system-helpers 1.60
ii libc62.31-13+deb11u3
ii libcrypt11:4.4.18-4
ii libgcc-s110.2.1-6
ii liblua5.3-0 5.3.3-1.1+b1
ii libpcre2-8-0 10.36-2
ii libssl1.11.1.1n-0+deb11u1
ii libsystemd0 247.3-7
ii lsb-base 11.1.0
ii zlib1g 1:1.2.11.dfsg-2+deb11u1
haproxy recommends no packages.
Versions of packages haproxy suggests:
pn haproxy-doc
pn vim-haproxy
-- Configuration Files:
/etc/haproxy/haproxy.cfg changed:
global
log /dev/loglocal0
log /dev/loglocal1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd
listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# See:
https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
ssl-default-bind-ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
defaults
log global
modehttp
option httplog
option dontlognull
timeout connect 5000
timeout client 5
timeout server 5
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http
bind *:80
mode http
# redirects to https
redirect scheme https if !{ ssl_fc }
default_backend http
frontend https
bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
mode http
# [some acl with our IPs stripped here]
default_backend http
backend http
balance roundrobin
# ensures the forwarded request includes the actual client IP address
option forwardfor
#defines the check HAProxy uses to test if a web server is still valid for
forwarding requests
option httpchk
http-check send meth GET uri /
# use cookies for
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#1008682: Security: updates & upgrades too delayed
Package: unattended-upgrades Version: 2.8 Severity: normal X-Debbugs-Cc: bugrepo...@pouzenc.fr Dear Maintainer, Unattended-upgrade installs security upgrades with too much (random) delay, more than 24h after DSA and mirror availability. On a pool of about twenty debian 11 VM, the majority ends with 2 day of lagg on published DSA. I expect things like in pre-systemd debian : all upgrades applied before the start of the current working day. I believe it's mostly an apt problem with /usr/lib/apt/apt.systemd.daily. I've reported this as #1008679 on src:apt. I create a BR against unattended-upgrades because it set in /etc/apt/apt.conf.d/20auto-upgrades : APT::Periodic::Update-Package-Lists "1"; Witch is mostly bad with the default (apt) /lib/systemd/system/apt-daily.timer : OnCalendar=*-*-* 6,18:00 (twice a day) "1" random skip apt update for 36h in worst cases I believe. Extra delay is added with apt-daily-upgrade.timer. APT::Periodic::Update-Package-Lists "always"; may be an other value to consider (or not). Code using APT::Periodic::Update-Package-Lists is currently very complicated. (in debian 11 at least). /etc/apt/apt.conf.d/20auto-upgrades does not provide comments for helping admins about tuning that. Be cautious: the comment in /usr/lib/apt/apt.systemd.daily about Update-Package-Lists seems wrong and misleading for me. I have detailed everything I can in #1008679. Cheers, Ludovic Pouzenc -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-12-amd64 (SMP w/2 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 unattended-upgrades depends on: ii debconf [debconf-2.0] 1.5.77 ii lsb-base 11.1.0 ii lsb-release11.1.0 ii python33.9.2-3 ii python3-apt2.2.1 ii python3-dbus 1.2.16-5 ii python3-distro-info1.0 ii ucf3.0043 ii xz-utils 5.2.5-2 Versions of packages unattended-upgrades recommends: ii anacron 2.3-30 ii cron [cron-daemon] 3.0pl1-137 ii systemd-sysv247.3-6 Versions of packages unattended-upgrades suggests: pn bsd-mailx pn default-mta | mail-transport-agent pn needrestart pn powermgmt-base ii python3-gi 3.38.0-2 -- debconf information: unattended-upgrades/enable_auto_updates: true
Bug#1008679: Security: updates & upgrades too delayed by /usr/lib/apt/apt.systemd.daily
ible for mirrors nowadays. I think that : - setting APT::Periodic::Update-Package-Lists "always" or removing the "06," in apt-daily.timer - removing the "After=" dependency of the timer slightly improve the situation without patching code for the admins that wants to change their config quickly and not make troubles to mirror maintainers. I think that the current code is too error-prone of every one. I think that the tone of my bug report is going bad as I am ending writing it. Sorry about that, everything is almost very great. I wish to add that I'm very happy the celebrate this year my 15 years of nearly full-time sysadmin on Debian based systems for various purposes ! Cheers, Ludovic Pouzenc -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::LastInstalledKernel "5.10.0-12-amd64"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "lz4"; APT::Compressor::lz4::Cost "50"; APT::Compressor::lz4::CompressArg ""; APT::Compressor::lz4::CompressArg:: "-1"; APT::Compressor::lz4::UncompressArg ""; APT::Compressor::lz4::UncompressArg:: "-d"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg &qu
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#998485: gjiten: FTBFS: configure.in:8: error: AM_INIT_AUTOMAKE expanded multiple times
On Mon, Jan 03, 2022 at 12:50:58AM +0200, Adrian Bunk wrote: > Hi Ludovic, > > are you still maintaining this package, or should it be moved to QA > maintainance? > Hi Adrian, Yes, an update is on the way! Thanks, -- Ludovic Drolez. https://isabelleantoine.be - Coaching and NLP
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#999279: swish-e: diff for NMU version 2.4.7-6.1
On Thu, Dec 16, 2021 at 07:56:50AM +, Damyan Ivanov wrote: > Control: tags 999279 + patch > Control: tags 999279 + pending > > Dear maintainer, > > I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. > Hi! That's perfect, thanks for your help! -- Ludovic https://isabelleantoine.be - Coaching Gestion du Stress
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#929050: weex: use dh autoreconf to update configure, so that support new architectures
Hi! I've tried to use dh_autoreconf, but now the build fails. Did you try a recent build with it? Best regards, Ludovic On Thu, May 16, 2019 at 11:37:25AM +0800, YunQiang Su wrote: > + * Run dh_autoreconf to update configure. -- Ludovic Drolez. https://drolez.com/blog/music/ - Music and Tech Blog
Bug#1001242: weex FTBFS: dh_testroot: error: You must run this as root (or use fakeroot).
Hi! Sorry I thought that was required for all builds? Ludovic > dh_testroot > dh_testroot: error: You must run this as root (or use fakeroot). -- Ludovic Drolez. https://drolez.com/blog/ - Music and Tech Blog
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#986462: automysqlbackup: LATEST=yes broken code: cp .gz /var/lib/automysqlbackup/latest/ (No such file or directory)
Hi, First try on an already installed debian 11 test server : it seems to work properly. (see term1.html) I've tried this version on debian 10 before a full upgrade to debian 11, no post-inst problems seen, backup successful. Then I've tried to upgrade to debian 11 this VM, no problems found. (see term2.html) I think everything is now working in my usecases and I didnt find any bad side effects. Cheers, Ludovic Le 30/08/2021 à 17:29, Thomas Goirand a écrit : On 8/30/21 5:02 PM, Ludovic Pouzenc wrote: Thank you very much. I can test right now but I can't find now a mirror that reflects your upload. Could you point me the right thing to do ? Wait until the next Dak run, as I've just uploaded it it takes time for the package to reach the mirrors. It should be available later this evening. Cheers, Thomas Goirand (zigo) -- Ludovic Pouzenc Ingénieur Informatique de Gestion Direction du Numérique, DN : Applications 04 79 75 83 54 (test)root@app-d11-test:~# date; lsb_release -a; apt policy automysqlbackup mar. 31 août 2021 11:10:06 CEST No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 11 (bullseye) Release:11 Codename: bullseye automysqlbackup: Installé : 2.6+debian.4-4 Candidat : 2.6+debian.4-4 Table de version : *** 2.6+debian.4-4 100 100 /var/lib/dpkg/status 2.6+debian.4-3 500 500 http://ftp.fr.debian.org/debian bullseye/main amd64 Packages (test)root@app-d11-test:~# automysqlbackup ; echo $? 0 (test)root@app-d11-test:~# date mar. 31 août 2021 11:10:19 CEST (test)root@app-d11-test:~# ls -lh /var/lib/automysqlbackup/latest/ total 12K -rw--- 1 root root 8,2K 31 août 11:10 wp_test_2021-08-31_11h10m.mardi.sql.gz (test)root@app-d11-test:~# ls -lh /var/lib/automysqlbackup/daily/ total 4,0K drwxr-xr-x 2 root root 4,0K 31 août 11:10 wp_test (test)root@app-d11-test:~# ls -lh /var/lib/automysqlbackup/daily/wp_test/ total 36K -rw--- 1 root root 8,2K 29 août 06:25 wp_test_2021-08-29_06h25m.dimanche.sql.gz -rw--- 1 root root 8,2K 30 août 06:25 wp_test_2021-08-30_06h25m.lundi.sql.gz -rw--- 1 root root 8,2K 31 août 11:10 wp_test_2021-08-31_11h10m.mardi.sql.gz (test)root@app-d11-test:~# (vbox)root@vmdev1-pouzencl:~# date; lsb_release -a mardi 31 août 2021, 11:45:45 (UTC+0200) No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster (vbox)root@vmdev1-pouzencl:~# wget http://ftp.fr.debian.org/debian/pool/main/a/automysqlbackup/automysqlbackup_2.6+debian.4-4_all.deb --2021-08-31 11:41:39-- http://ftp.fr.debian.org/debian/pool/main/a/automysqlbackup/automysqlbackup_2.6+debian.4-4_all.deb Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 212.27.32.66, 2a01:e0c:1:1598::2 Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|212.27.32.66|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 14576 (14K) [application/octet-stream] Sauvegarde en : « automysqlbackup_2.6+debian.4-4_all.deb » automysqlbackup_2.6 100%[===>] 14,23K --.-KB/sds 0,04s 2021-08-31 11:41:39 (378 KB/s) — « automysqlbackup_2.6+debian.4-4_all.deb » sauvegardé [14576/14576] (vbox)root@vmdev1-pouzencl:~# dpkg -i automysqlbackup_2.6+debian.4-4_all.deb (Lecture de la base de données... 65569 fichiers et répertoires déjà installés.) Préparation du dépaquetage de automysqlbackup_2.6+debian.4-4_all.deb ... Dépaquetage de automysqlbackup (2.6+debian.4-4) sur (2.6+debian.4-2) ... Paramétrage de automysqlbackup (2.6+debian.4-4) ... Fichier de configuration « /etc/default/automysqlbackup » ==> Modifié (par vous ou par un script) depuis l'installation. ==> Le distributeur du paquet a fourni une version mise à jour. Que voulez-vous faire ? Vos options sont les suivantes : Y ou I : installer la version du responsable du paquet N ou O : garder votre version actuellement installée D : afficher les différences entre les versions Z : suspendre ce processus pour examiner la situation L'action par défaut garde votre version actuelle. *** automysqlbackup (Y/I/N/O/D/Z) [défaut=N] ? d --- /etc/default/automysqlbackup2021-05-25 19:50:08.903741914 +0200 +++ /etc/default/automysqlbackup.dpkg-new 2021-08-30 16:50:19.0 +0 @@ -56,7 +56,7 @@ DBEXCLUDE="" # Include CREATE DATABASE in backup? -CREATE_DATABASE=no +CREATE_DATABASE=yes # Separate backup directory and file for each DB? (yes or no) SEPDIR=yes @@ -64,15 +64,22 @@ # Which day do you want weekly backups? (1 to 7 where 1 is Monday) DOWEEKLY=6 +# Which day of the month to execute the monthly backup (00 = no monthly backup) +# Two digit required +DOMONTHLY=01 + # Choose Compression type. (gzip or bzip2) COMP=gzip +# Compress backups on the fly with gzip or bzip2 (yes or no) +COMPDIRECT=no + # Compress communications between backup server and MySQL serv
Bug#986462: automysqlbackup: LATEST=yes broken code: cp .gz /var/lib/automysqlbackup/latest/ (No such file or directory)
Thank you very much. I can test right now but I can't find now a mirror that reflects your upload. Could you point me the right thing to do ? Le 30/08/2021 à 16:54, Thomas Goirand a écrit : On 4/6/21 3:29 PM, Ludovic Pouzenc wrote: - cp $1$SUFFIX "$BACKUPDIR/latest/" + cp $2$SUFFIX "$BACKUPDIR/latest/" Hi Ludovic and Gabriel, I've commited and uploaded the above patch. Can you please check the version in Debian unstable, and confirm it fixes the problem? If it's ok, then I'll try to get the package fixed in Stable as well. Cheers, Thomas Goirand (zigo) -- Ludovic Pouzenc Ingénieur Informatique de Gestion Direction du Numérique, DN : Applications 04 79 75 83 54
Bug#986462: (no subject)
Dear maintainer, This bug has landed in debian stable and I think there is people that are starting to migrate real things on it. At least me and theorically all users using LATEST=yes in their config. This is a 1 byte patch. (or a 2 bits patch). Regards, -- Ludovic Pouzenc Ingénieur Informatique de Gestion Direction du Numérique, DN : Applications 04 79 75 83 54
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#986462: (no subject)
Hi, I confirm that I didn't see any troubles since then with the proposed patch. I ran this only on single a amd64 VM but it's shell script func call with numbered args... so should be fine for any arch. Regards, -- Ludovic Pouzenc Ingénieur Informatique de Gestion Direction du Numérique, DN : Applications 04 79 75 83 54
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
