Bug#1014849: Newer jimtcl (>= 0.81) requires fix to scripts

Package: openocd Version: 0.11.0-1+b1 Severity: serious Hello, After I upgraded to libjim0.81, OpenOCD started to emit errors like: == Error executing event examine-end on target stm32f0x.cpu: /usr/bin/../share/openocd/scripts/mem_helper.tcl:37: Error: wrong # args: should be

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

On Mon, 11 Apr 2022 11:00:55 -0700 Vagrant Cascadian wrote: > Same problem with Gnuk, presumably multiple or all smartcards are > affected? I found an issue of scdaemon. At upstream development, it is tracked by: https://dev.gnupg.org/T5935 When the data is not so large (smaller than

Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

On Sun, 02 May 2021 19:47:15 +0200 "Xavier G." wrote: > Package: libgcrypt20 > Version: 1.8.7-4 > Severity: important > > Dear Maintainer, > > After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails: > > gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant] >

Bug#954506: ttyrec: diff for NMU version 1.0.8-5.1

Sudip Mukherjee wrote: > I've prepared an NMU for ttyrec (versioned as 1.0.8-5.1) and > uploaded it to mentors for sponsoring. Please feel free to tell me if I > should remove it. Thank you for your work. It is OK for Debian. Ideally, it should not be Debian-only patch, so that upstream will

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Hello, I managed to identify the bug and upload the fix. Thanks. --

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Here is some information. It is garbage collection + threads bug (possibly + dynamic loading). When I reproduce the failure (by make check) on my machine, it keeps running at gauche-c-wrapper/testsuite/cwrappertest.scm. gauche-c-wrapper/testsuite/test.log having:

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

Hello, Santiago Vila wrote: > but the failure rate is extremely high (around 70% here). Thanks for the number. When I built, I didn't get failure in such a rate. I built it in my machine (a few times), and upload it to Debian, where it automatically built on several machines, you know. So

Bug#789927: Anthy library breakage

Osamu Aoki wrote: > If what NOKUBI Takatsugu's comment is correct, I wonder why anthy is > upgraded without coordinating with key users: > ibus > uim > fcitx > > (Please note these have many dependence packages so the testing > migration is slow if package version dependency

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Antoine Beaupré writes: > This reminds me - it sure looks like pcscd was crashing back > there. Should I revert back to using pcscd to try and reproduce the > problem and file a pcscd bug about this? Yes. I think that this is a different problem, and it's pcscd issue. --

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Thanks a lot for your confirmation. Antoine Beaupré writes: >> If this works, the udev line should be included into scdaemon package in >> future, so that each user doesn't need to configure. > > I confirm the udev hack works. No, this is not a hack. This is a configuration

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

Hello, Thank you for reporting in detail. Antoine Beaupre wrote: > In Bug#854005, I have described a distinct issue I have experience > with my Yubikey since the upgrade of the GnuPG suite from 2.1.17 to > 2.1.18, and in the case of pcscd, from 1.8.19-1 to 1.8.20-1. [...] >

Bug#759891: golly: FTBFS: configure: error: could not determine Perl shared library name

On 08/31/2014 07:46 AM, Niko Tyni wrote: The problem, of course, is that libperl.so moved from /usr/lib/libperl.so to /usr/lib/triplet/libperl.so, so it looks like debian/rules needs to be updated accordingly. Patch attached, this makes it build for me. Thank you for your patch. I changed

Bug#724161: ginspector: FTBFS: configure.ac:5: error: required file 'misc/compile' not found

On 2013-10-21 at 23:17 +0900, Hideki Yamane wrote: Attached patch would fix this FTBFS, could you consider to apply it, please? Thank you. However, I don't have any plan to do anything for this package. It has been orphaned with valid reasons. That is to say, it's a sort of historical

Bug#717238: sigscheme-runtime: fails to upgrade from 'testing' - trying to overwrite /usr/share/sigscheme/lib/srfi-95.scm

On 2013-07-18 at 11:57 +0200, Andreas Beckmann wrote: It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at

Bug#662941: scute: diff for NMU version 1.4.0-1.1

On 2012-03-28 at 01:41 +0200, Mònica Ramírez Arceda wrote: I've prepared an NMU for scute (versioned as 1.4.0-1.1). The diff is attached to this message. I've not uploaded this NMU as I'm not a DD but I hope it is useful for you. Thanks a lot. I incorporated your changes and uploaded it. --

Bug#595839: verilog-mode: diff for NMU version 558-1.1

gregor herrmann wrote: I guess now - I should cancel the NMU and - you will file a removal request Ok? Yes, I will do file the removal request next week. -- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#595839: verilog-mode: diff for NMU version 558-1.1

gregor herrmann wrote: tags 595839 + patch tags 595839 + pending thanks Dear maintainer, I've prepared an NMU for verilog-mode (versioned as 558-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks. However, I think that verilog-mode

Bug#561203: threads and fork on machine with VIPT-WB cache

Modestas Vainius wrote: Note that Debian's buildds run a UP kernel, so as soon as those fixes go upstream we can pull them in. Thanks for all your work here! Well, as long as this is unfixed or at least common, I don't see how hppa can be considered to be a release arch. Is that UP patch

Bug#561203: threads and fork on machine with VIPT-WB cache

John David Anglin wrote: It is interesting that in the case of the Debian bug that a thread of the parent process causes the COW break and thereby corrupts its own memory. As far as I can tell, the fork'd child never writes to the memory that causes the fault. Thanks for writing and testing

Bug#561203: threads and fork on machine with VIPT-WB cache

Thanks a lot for the discussion. James Bottomley wrote: So your theory is that the data the kernel sees doing the page copy can be stale because of dirty cache lines in userspace (which is certainly possible in the ordinary way)? Yes. By design that shouldn't happen: the idea behind COW

Bug#561203: threads and fork on machine with VIPT-WB cache

retitle 561203 threads and fork on machine with VIPT-WB cache reassign 561203 linux-2.6 thanks As I am sure that this bug lives in kernel, I do reassign and retitle. -- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#561203: threads and fork on machine with VIPT-WB cache

NIIBE Yutaka wrote: To have same semantics as other archs, I think that VIPT-WB cache machine should have cache flush at ptep_set_wrprotect, so that memory of the page has up-to-date data. Yes, it will be huge performance impact for fork. But I don't find any good solution other than this yet

Bug#561203: threads and fork on machine with VIPT-WB cache

Hi there, I think that I am catching a bug for threads and fork. I found it when debugging FTBFS of Gauche, a Scheme interpreter. As I think that the Debian bug #561203 has same cause, I am CC:-ing to the BTS too. Please send Cc: to me, I am not on linux-parisc list. Here, I am talking

Bug#561203: threads and fork on machine with VIPT-WB cache

Thanks for your quick reply. James Bottomley wrote: In COW breaking, the page table entry is copied, so A and B no longer have page table entries at the same physical location. If the COW is intact, A and B have the same physical page, but it's also accessed by the same virtual address,

Bug#489844: FTBFS not fixed

reopen 489844 thanks No, sigscheme_0.8.3-3 doesn't fix FTBFS(es). -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#437859: The cause of this bug -- BSD pty

I think that the cause of this bug is the use of BSD pty. Currently in debian/rules, ttyrec is compiled for BSD standard (deprecated, I think). I think following patch should apply for Debian build. -- --- rules.orig 2007-08-25 16:16:16.0 +0900 +++ rules

Bug#405921: NMU uploaded

Andreas Barth wrote: I uploaded an NMU of your package. Please see this as help to get the package into a releaseable condition for etch. Please find the used diff below. Thank you for your help. But... For the record, let me explain the situation. There are two different code bases:

Bug#400556: gauche: ..*** ERROR: unbound variable: slib:features

. * debian/control (Build-Conflicts): slib removed. (Build-Depends): slib. * debian/rules: Don't make install, but make install-pkg, install-doc, and slibcat-in-place. * debian/gauche.prerm, debian/gauche.postinst: Don't touch slibcat. -- NIIBE Yutaka [EMAIL PROTECTED] Tue, 5 Dec

Bug#335564: Rebuilding fam in GCC 4.0 environment

To rebuild fam-2.7.0, I need a patch (attached) for realloc and free. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1 Versions

Bug#295877: gauche-gtk: FTBFS: /bin/sh: m: command not found

On Mon, 07 Mar 2005 04:49:33 +0200 Lars Wirzenius [EMAIL PROTECTED] wrote: With regard to bug #295877: gauche-gtk is missing versioned build dependencies on gauche-dev (= 0.8.3-1) and possibly on gauche (= 0.8.3-1). gauche has been split into several packages and is waiting for NEW package

Bug#295877: gauche-gtk: FTBFS: /bin/sh: m: command not found

Your package is failing to build on all arches. Here is an extract from the build log: cd src; /usr/bin/make install make[2]: Entering directory `/build/buildd/gauche-gtk-0.4.1/src' m 444 -T /build/buildd/gauche-gtk-0.4.1/debian/gauche-gtk`/usr/bin/gauche- config --sysincdir` /bin/sh: m: