Hello,
Aurelien Jarno wrote:
> Currently it's not an issue for Sid (unstable), but glibc 2.41 should
> migrate to Trixie (testing) in the next days.
Thank you. Now, I understand the situation.
I uploaded the fix for #1099232.
--
Hello,
Aurelien Jarno wrote:
> This change appears to have been caused by glibc 2.41. It changes the
> contents of that file, and the mentioned line (and a few others) got
> changed from
> extern double ceil (double __x) __attribute__ ((__nothrow__ , __leaf__))
> __attribute__ ((__const__)); e
Andreas Tille wrote:
> Thus I would suggest to remove this package from unstable.
Agreed. It was useful when I packaged, but no users (even the author)
these days.
--
signature.asc
Description: PGP signature
Andreas Metzler wrote:
> Package: gnupg2
> Version: 2.4.5-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>From GnuPG, I factored out spawn functions into libgpg-error (mainly for
support of Windows 64-bit). Since libgpg-error
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 "ex
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 t
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]
>
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
ev
Hello,
I managed to identify the bug and upload the fix. Thanks.
--
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:
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 far
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 is correctly record
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.
--
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 needed.
It seems fo
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.
[...]
> anything i can do to
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//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 debian/r
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 pac
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
> http://www.debian.org/doc/debian-policy/ch-relationsh
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.
--
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 listmas
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-mo
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 ava
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 testi
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 listma
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
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 thi
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, h
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 uniproce
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]
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 2
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
h: New file.
* 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 P
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 o
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
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: comman
35 matches
Mail list logo
