Re: Unable to access to Yubikey after recent GPG changes
Hi, Am Samstag, dem 10.05.2025 um 22:39 +0200 schrieb Yadd: > Hi, > > I can no more use my Yubikey with GPG aftre recent changes. I > followed > https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing > succeeded. > I'm running a Debian testing. > > Did someone find a solution ? Yes I did: sudo apt purge pcscd Turns out you do not need pcscd to use the Yubikey's PGP applet. On the contrary: I now have way less hassle/issues and it works like a charm all the time. Colleagues had to delete their ~/.gnupg/scdaemon.conf though for this to work (I did not have that file on my systems). Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Philipp Huebner ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 671925C5B8CDE74A52253DF9E5CA8C4925E4205F ⠈⠳⣄
Re: Unable to access to Yubikey after recent GPG changes
On 2025-06-23 12:20, Philipp Huebner wrote: Am Samstag, dem 10.05.2025 um 22:39 +0200 schrieb Yadd: Hi, I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing succeeded. I'm running a Debian testing. Did someone find a solution ? Yes I did: sudo apt purge pcscd Turns out you do not need pcscd to use the Yubikey's PGP applet. On the contrary: I now have way less hassle/issues and it works like a charm all the time. Colleagues had to delete their ~/.gnupg/scdaemon.conf though for this to work (I did not have that file on my systems). Generally it's sufficient to temporarily stop pcscd. But also disable-ccid and pcsc-shared in scdaemon.conf should help. (Not that I'm claiming that this is good UX.) Kind regards Philipp Kern
Appstream data generation stalled?
Appstream data does not seem to be generated after Jun 9th https://appstream.debian.org/logs/2025/06/ Just curious, does anyone have any information on this? Regards, Peter
Bug#1108241: ITP: redmine-plugin-simple-captcha -- Redmine plugin adding a simple registration captcha
Package: wnpp Severity: wishlist Owner: Soren Stoutner X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: redmine-plugin-simple-captcha Version : 1.0 Upstream Contact: Soren Stoutner * URL : https://github.com/sorenstoutner/redmine_simple_captcha * License : Expat Programming Lang: Ruby Description : Redmine plugin adding a simple registration captcha This Redmine plugin adds a very simple CAPTCHA question and answer to the account registration page. The question and answer are the same for all people attempting to register on your site, and only allows registration for someone who fills out the CAPTCHA answer field with the same value you set in the plugin settings. . For example, you can set the CAPTCHA question to be a mathamatical equation requesting the user type the answer. Or, you can set it to be a logical puzzle. You can even instruct the user to simply type a specific word in the answer. . Obviously, this will not prevent sophisticated registration attacks. But it gets rid of the low-hanging fruit of automatic registrations, particularly those who just want to flood a target email address with spam. I intend to maintian this package under the Ruby team umbrella.
Re: New contributor experience
On Wednesday, June 18, 2025 3:35:04 AM Mountain Standard Time Marc Haber wrote: > Then you surely can point me to documentation about how I, as the MR > submitter am supposed to improve the MR. I am not sure whether just > pushing my fixed code to the branch that I submitted an MR for will > automatically update the MR Yes, it will. > o whether I am supposed to do some magic > chants to have those changes show up in the MR, No, you don’t need to. > or whether I am > supposed to comment on the thread after pushing an improvement Yes, you should. Usually when I am working with someone on an MR, there are a number of comment threads going at once to address different aspects of the MR that need to be changed. After making a change to the MR, it is helpful to comment on the threads it affects so it is easy for everyone else to see what has been accomplished and what still remains to be done. > and who > is supposed to close the discussion thread in the MR. Whoever feels like it has reached a conclusion, the same as with a bug on the BTS. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1108229: ITP: mozjs140 -- SpiderMonkey JavaScript library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:mozjs140 Owner: jeremy.bi...@canonical.com Package Name: mozjs140 Version: 140.0 Upstream Author: Mozilla etc License: mostly MPL-2.0, other files are licensed under other open source licenses Programming Lang: C++ Description: SpiderMonkey JavaScript library SpiderMonkey is the code-name for Mozilla Firefox's C++ implementation of JavaScript. It is intended to be embedded in other applications that provide host environments for JavaScript. . This library is intended for use in contexts where only trusted JavaScript code will be run, such as GNOME's gjs, Cinnamon's cjs, and polkit's rules parsing. It should not be used to run untrusted JavaScript from web pages: use a security-supported implementation such as Firefox, Chrome or WebKitGTK's JavaScriptCore instead. Other Info -- mozjs is the JavaScript engine from Firefox ESR. Tomorrow, a new Firefox ESR series will be released. It will be supported by Mozilla for about 14 months. mozjs140 is unlikely to be backported for trixie. Forky is likely to use the new series after mozjs140 once it's available in 2026. I expect that either GNOME 49 or 50 (specifically gjs 1.86 or 1.88) will switch from mozjs128 to mozjs140. The other user of mozjs* in Debian is Cinnamon, specifically their cjs fork of gjs. Recently, the cjs developers have changed their update processes to make it easier for distros to fully switch to newer versions of mozjs. cjs's new version numbering system makes this more obvious: trixie's cjs 128 is compatible with mozjs128. mozjs packaging is at https://salsa.debian.org/gnome-team/mozjs References -- https://whattrainisitnow.com/calendar/ https://gitlab.gnome.org/GNOME/gjs/-/issues/690 Thanks, Jeremy Bícha
