[ Putting the glibc maintainers and the mips porters into the loop.
Summary: emacs23-nox aborts with malloc assertion failure on mipsel. ]
On 2010-01-26 02:17 +0100, Deng Xiyue wrote:
Package: emacs23-nox
Version: 23.1+1-5
Severity: grave
When installing emacs23-nox, aptitude stops with
found 585737 2.11.2-1
thanks
Alas, the Breaks: locales ( 2.11) does not really help much, as I
discovered when upgrading a sid chroot today. While the new locales
package got unpacked early, it was only configured together with the
bulk of optional packages, and lots of the annoying perl
On 2010-06-18 11:08 +0200, Aurelien Jarno wrote:
tag 585737 + wontfix
thanks
Sven Joachim a écrit :
found 585737 2.11.2-1
thanks
Alas, the Breaks: locales ( 2.11) does not really help much, as I
discovered when upgrading a sid chroot today. While the new locales
package got unpacked
Hi folks,
Déjà vu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566947
just reared its ugly head again. :-(
On 2010-09-28 03:27 +0200, Christoph Egger wrote:
Package: emacs23-nox
Version: 23.2+1-4
Severity: serious
The following partially installed packages will be configured:
Hi,
today I hit this bug: after installing an extension, namely
xul-ext-adblock-plus, and restarting icedove it failed:
$ icedove
/usr/lib/icedove/icedove-bin: symbol lookup error:
/usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
This is in accord with Jonathan's
Package: libc6
Version: 2.13-7
Severity: important
User: vor...@debian.org
Usertags: multiarch
On multiarch-enabled i386 systems, installing libc6:amd64 together with
lib64foo:i386 has some interesting effects. To reproduce, set up an
i386 chroot with a dpkg from the pu/multiarch/full branch of
On 2011-06-30 18:36 +0200, Jonathan Nieder wrote:
Sven Joachim wrote:
On multiarch-enabled i386 systems, installing libc6:amd64 together with
lib64foo:i386 has some interesting effects.
[...]
# apt-get install libc6:amd64
# apt-get install lib64ncurses5
# bash
You get an error message
reassign 632405 libc6
forcemerge 632190 632405
thanks
On 2011-07-02 05:09 +0200, Michael Biebl wrote:
Package: debootstrap
Version: 1.0.32
Severity: grave
Hi,
trying to create a chroot like
debootstrap sid /tmp/chroot/
fails
...
I: Installing core packages...
W: Failure trying to
On 2011-07-01 10:31 +0200, Aurelien Jarno wrote:
Currently libc-bin is virtually essential: a lot of essential packages
depend on libc6 which in turn depends on libc-bin. This package has been
created during the first steps of the multiarch transition two years
ago, and all the binaries have
On 2008-09-09 10:27 +0200, Neil Williams wrote:
The package supports a method of adding unsupported locales but that
this method does not appear to have been used.
Unless the submitter can demonstrate that the existing support is
broken, I think this bug should be downgraded to normal.
It
On 2008-09-09 11:09 +0200, Neil Williams wrote:
On Tue, 2008-09-09 at 11:03 +0200, Sven Joachim wrote:
For the record, the path is /usr/local/share/i18n/SUPPORTED (not
/usr/locale/...), and that seems perfectly reasonable, since you don't
want to edit files under /usr locally.
In that case
reassign 508764 perl
forcemerge 221790 508764
thanks
On 2008-12-15 04:15 +0100, Michael Biebl wrote:
Package: libc6
Version: 2.7-16
Severity: important
Hi,
I did a test upgrade from etch - lenny. As soon as the new libc6 has
been unpacked, I get lots of those warnings:
perl: warning:
reassign 143870 libc6 2.2.3-5
thanks
Hi,
I'm trying to clean up old Emacs bugs in Debian. This one seems to
belong elsewhere, see [1].
On 2001-06-16 12:01 +0200, Tollef Fog Heen wrote:
Package: emacs
It seems like emacs doesn't like when the resolver settings change:
From tcpdump (when
found 502311 2.9-1
thanks
Now glibc apparently built fine on ia64, but it does not on i386.
Here is the result from my local build with debuild:
,
| #
| # Testsuite failures, someone should be working towards
| # fixing these! They are listed here for the purpose of
| # regression testing
On 2009-02-18 16:45 +0100, Aurelien Jarno wrote:
Sven Joachim a écrit :
You are probably using an old kernel which has some problems. The buildd
is using a 2.6.26 kernel from lenny.
While my kernel may have some problems (not that I noticed any, but it's
of course possible
On 2009-02-18 18:00 +0100, Aurelien Jarno wrote:
Then maybe some regressions have been added in the latest versions.
Could you retry with a 2.6.26 kernel from lenny/unstable? This version
is working on the buildd and on my machine, so that will infirm/confirm
it is due to the kernel.
Would
On 2009-02-18 15:42 +0100, Sven Joachim wrote:
found 502311 2.9-1
thanks
Now glibc apparently built fine on ia64, but it does not on i386.
Here is the result from my local build with debuild:
,
| #
| # Testsuite failures, someone should be working towards
| # fixing
On 2009-02-23 08:01 +0100, Aurelien Jarno wrote:
On Sun, Feb 22, 2009 at 11:48:55AM +0100, Sven Joachim wrote:
All but one of these errors are fixed or ignored in 2.9-2, but the last
problem still occurs -- apparently only if a 64-bit kernel is running
and detectable. From my debuild log
Package: eglibc
Version: 2.9-11
I've experienced a testsuite failure again:
,
| # Testsuite failures, someone should be working towards
| # fixing these! They are listed here for the purpose of
| # regression testing during builds.
| # Format: Failed test, Error Make error code [(ignored)]
|
On 2009-05-09 21:07 +0200, Aurelien Jarno wrote:
On Fri, May 08, 2009 at 09:40:49AM +0200, Sven Joachim wrote:
Package: eglibc
Version: 2.9-11
I've experienced a testsuite failure again:
,
| # Testsuite failures, someone should be working towards
| # fixing these! They are listed
On 2009-05-09 23:16 +0200, Aurelien Jarno wrote:
Are you able to reproduce the problem with previous versions? 2.9-10 is
still on the mirrors for example.
Initially I had the problem with 2.9-9, but did not bother to report it
as 2.9-10 built successfully. Retrying today, 2.9-10 also fails
On 2009-05-10 10:25 +0200, Aurelien Jarno wrote:
On Sun, May 10, 2009 at 09:18:56AM +0200, Sven Joachim wrote:
2.6.28.10 does not show the problem (repeated the test a few dozen
times), but all 2.6.29 kernels I've tested have it, including Debian's
official 2.6.29-2-amd64 package. Under
On 2009-06-20 21:24 +0200, Clint Adams wrote:
On Sat, Jun 20, 2009 at 02:10:25PM +0200, Goswin Brederlow wrote:
you actually managed to completly screw the pooch with the /usr/lib32
transition from link to directory and now on existing installations it
remains a link. Now
Package: glibc-doc-reference
Version: 2.9-1
Severity: normal
Your package puts an entry for every libc function and macro into the
main info directory, using up more than 1700 lines. This has been
triggered by the transition to GNU's install-info; apparently the dpkg
implementation ignored
tags 536506 + patch
thanks
On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:
tag 536506 + help
thanks
On Fri, Jul 10, 2009 at 05:56:01PM +0200, Sven Joachim wrote:
Package: glibc-doc-reference
Version: 2.9-1
Severity: normal
Your package puts an entry for every libc function and macro
On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:
I have recently uploaded to experimental eglibc 2.9-23+multiarch, from
our multiarch branch. It doesn't use the multiarch paths yet, but it is
a first step toward multiarch.
The only difference with the unstable version is that libc-bin and
On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:
On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
In short it looks like a Pre-Depends is overkill, and that a Depends is
enough. I'll upload a new version soon to experimental to fix that.
eglibc version 2.9-23+multiarch.1 is
reassign 249122 libc-bin
forwarded 249122 http://sourceware.org/bugzilla/show_bug.cgi?id=1484
thanks
This bug had been originally reported as #224450 against
libncurses5-dev, and is marked as forwarded there. It probably makes
more sense to mark #249122 as forwarded, since that bug is about the
Package: glibc-doc-reference
Version: 2.3.6-1
Severity: wishlist
Hello,
could you please upload a new debian version matching glibc 2.5 to
unstable? It's already in experimental.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Package: nscd
Version: 2.5-4
Severity: grave
Your package depends on libssp0 which is no longer present in the
latest gcc-4.1 upload (4.1.2-4). Following Matthias Klose's advice
in http://bugs.debian.org/421162, I report this as a bug against your
package. Please examine whether a binNMU
reassign 635685 libc6-dev
severity 635685 serious
thanks
On 2011-07-28 10:58 +0200, Tim Northover wrote:
Package: general
Severity: normal
It looks like gcc -m32 has been partially broken by the recent
hiving off of various headers to /usr/include/x86_64-linux-gnu.
In particular a program
On 2011-07-28 23:53 +0200, Steve Langasek wrote:
On Thu, Jul 28, 2011 at 11:39:50AM +0200, Sven Joachim wrote:
On 2011-07-28 10:58 +0200, Tim Northover wrote:
Package: general
Severity: normal
It looks like gcc -m32 has been partially broken by the recent
hiving off of various
On 2011-07-29 09:58 +0200, Sven Joachim wrote:
On 2011-07-29 09:58 +0200, Sven Joachim wrote:
On 2011-07-28 23:53 +0200, Steve Langasek wrote:
On Thu, Jul 28, 2011 at 11:39:50AM +0200, Sven Joachim wrote:
,
| $ LANG=C debian/rules build-64
| [...]
| make[2]: Entering directory
`/usr
On 2011-07-29 12:27 +0200, Steve Langasek wrote:
Do you happen to have any of the following packages installed in this
chroot?
libacl1-dev
libapparmor-dev
libasound2-dev
libcap-dev
libsbuf-dev
systemtap-sdt-dev
No, but libc6-dev-i386 had been installed before, shipping a
On 2011-07-29 17:50 +0200, Steve Langasek wrote:
On Fri, Jul 29, 2011 at 01:44:06PM +0200, Sven Joachim wrote:
I see, much to my surprise, that libc6-dev is not the only package shipping
files in this directory; so if you have one of these packages installed,
the
/usr/include/sys
Package: libc6-dev-amd64
Version: 2.13-13
Severity: grave
There was a problem installing your package:
,
| Preparing to replace libc6-dev-amd64 2.13-11 (using
.../libc6-dev-amd64_2.13-13_i386.deb) ...
| Unpacking replacement libc6-dev-amd64 ...
| dpkg: error processing
On 2011-07-25 14:50 +0200, Santiago Vila wrote:
reassign 632682 libc6
retitle 632682 we should probably remove /lib64 - lib symlink (with care)
thanks
Hi. After discussing about this today, it seems what we really need
for multiarch to work is to remove those symlinks, hence this reassign.
On 2011-08-10 19:48 +0200, Aurelien Jarno wrote:
On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote:
On 2011-07-25 14:50 +0200, Santiago Vila wrote:
reassign 632682 libc6
retitle 632682 we should probably remove /lib64 - lib symlink (with care)
thanks
Hi. After discussing
On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:
Sven Joachim wrote:
1) remove /lib64
2) create /lib64 directory
3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
/lib64/ld-linux-x86-64.so.2
2) and 3) are a bit difficult after the path to the ELF interpreter has
just disappeared
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
I'll have a look at it in the next few days if nobody beats me to it.
Just to confirm that my ideas were the same as yours, AFAICS the
following needs to be done in the preinst
On 2011-08-10 22:44 +0200, Aurelien Jarno wrote:
On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
This is basically what we have in mind, though it has not been tested.
For step 2 and 3, you can call the ELF interpreter
On 2011-08-13 13:58 +0200, Aurelien Jarno wrote:
* Add patches/localedata/cvs-rupee.diff fro upstream to add support for
Rupee symbol (U20B9).
This patch does not apply cleanly here, I got a reject in the following
hunk:
+diff --git a/localedata/ChangeLog b/localedata/ChangeLog
+index
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
I'll have a look at it in the next few days if nobody beats me to it.
Just to confirm that my ideas were the same as yours, AFAICS the
following needs to be done in the preinst
Thanks for the review, Jonathan.
On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
Sven Joachim wrote:
- link_name=debian/tmp-$(curpass)/lib/$$rtld_so ; \
+ link_name=debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so ; \
target=$(call xx,slibdir)/$$(readlink
On 2011-08-13 23:17 +0200, Sven Joachim wrote:
On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
Sven Joachim wrote:
- link_name=debian/tmp-$(curpass)/lib/$$rtld_so ; \
+ link_name=debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so ; \
target=$(call xx,slibdir
On 2011-08-18 01:05 +0200, Steve Langasek wrote:
The biggest change compared to the previous one is the new patch 6 which
tries to check that there is at least one free inode. Namely, if there
aren't any, the sequence
rm -f /lib64
$interpreter /bin/mkdir /lib64
$interpreter
On 2011-08-18 18:20 +0200, Steve Langasek wrote:
On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
The right way to handle it is to create the directory under a separate
name, populate the symlink, and only *then* rm /lib64 and invoke mv
/lib64.real /lib64 via $interpreter
On 2011-08-19 09:46 +0200, Petr Salinger wrote:
I looked at just commited r4891, and it seems that it breaks
kfreebsd-amd64 seriously.
On kfreebsd-amd64, the ELF interpreter is
/lib/ld-kfreebsd-x86-64.so.1, i.e. it is really in /lib, not in
/lib64.
The lib64 - lib symlinks in previous
On 2011-08-13 21:25 +0200, Sven Joachim wrote:
- The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to
/lib/ld-linux-x86-64.so.2 that get broken. Nothing dramatic and
solvable in a few ways.
Since it has been decided that /lib/ld-linux-x86-64.so.2 goes away, the
lsb-core
On 2011-09-08 08:35 +0200, Austin Clements wrote:
I probably don't understand all of the nuances of that code, but one
potential fix is simply to pass a benign argument to mv. Something like
if ! $ldfile /bin/mv --version /dev/null 2/dev/null; then
...
Alternatively, it may be
found 669172 2.13-29
thanks
On 2012-04-18 00:38 +0200, Adam Conrad wrote:
The reason this fails in -27 as well as -28 is because it has
nothing to do with -28, it just got triggered for people by a
new eglibc upload, period.
The real bug here is that dpkg has decided that referring to
On 2012-06-02 21:56 +0200, Aurelien Jarno wrote:
On Sat, Jun 02, 2012 at 09:33:19PM +0200, Thibaut Girka wrote:
On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote:
Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev
m-a: same. You should also check for files
On 2012-06-03 10:39 +0200, Aurelien Jarno wrote:
On Sun, Jun 03, 2012 at 10:10:41AM +0200, Sven Joachim wrote:
On 2012-06-02 21:56 +0200, Aurelien Jarno wrote:
Either we have to make them conflict one with another (that is
libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc
reassign 678511 src:zlib 1:1.2.7.dfsg-3
thanks
On 2012-06-22 14:02 +0200, Mark Brown wrote:
reassign 678511 libc6-dev
kthxbye
On Fri, Jun 22, 2012 at 12:12:25PM +0100, Jonathan McCrohan wrote:
Your package FTBFS on s390x. s390x is now a release architecture [1], hence
the
RC status.
On 2013-05-08 03:32 +0200, Ben Hutchings wrote:
Package: src:eglibc
Version: 2.17-1
Severity: important
This upgrade failed:
[snip]
Preparing to replace libc6-dev-amd64 2.13-38 (using
.../libc6-dev-amd64_2.17-1_i386.deb) ...
Unpacking replacement libc6-dev-amd64 ...
Preparing to
Control: severity -1 serious
On 2013-05-08 09:37 +0200, Sven Joachim wrote:
On 2013-05-08 03:32 +0200, Ben Hutchings wrote:
OK, where is /lib64/ld-linux-x86-64.so.2 pointing? To ld-2.13.so,
which does not exist.
It ought to point at /lib/x86_64-linux-gnu/ld-2.13.so,
It does so
On 2013-05-08 10:06 +0200, Sven Joachim wrote:
Control: severity -1 serious
On 2013-05-08 09:37 +0200, Sven Joachim wrote:
On 2013-05-08 03:32 +0200, Ben Hutchings wrote:
The new version of libc6-amd64 has already been unpacked, but
/lib64/ld-linux-x86-64.so.2 belongs to libc6:amd64 which
Package: libc-bin
Version: 2.17-1
Severity: minor
The echo ldconfig deferred processing now taking place message in the
libc-bin postinst is rather useless and should not be printed by
default, since dpkg already gives that information itself
(Processing triggers for libc-bin ...).
Please remove
On 2013-05-18 01:03 +0200, Clint Adams wrote:
Author: clint
Date: 2013-05-17 23:03:21 + (Fri, 17 May 2013)
New Revision: 5604
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/control
Log:
Add rpcinfo to libc-bin description.
Uhm, why that?? The
On 2009-07-11 08:02 +0200, Sven Joachim wrote:
tags 536506 + patch
thanks
On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:
tag 536506 + help
thanks
On Fri, Jul 10, 2009 at 05:56:01PM +0200, Sven Joachim wrote:
Package: glibc-doc-reference
Version: 2.9-1
Severity: normal
Your
As the transliteration of the german quotes in non-UTF-8 german locales
has been fixed in version 2.3.5-12 of the glibc package, it seems this
bug should be considered closed, too.
What is your opinion, Helge?
Regards,
Sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: locales
Version: 2.3.6-5
Severity: normal
When upgrading to version 2.3.6-5, the locale settings were moved from
/etc/environment to /etc/default/locale. Since I had LANG=de_DE in
/etc/environment, but not set it in my ~/.bash{_profile,rc} scripts, I
found that my window manager and
On 2014-07-12 23:30 +0200, Stephen Powell wrote:
The problem occurs when libc6 must be upgraded during apt-get upgrade
or apt-get dist-upgrade. I see a screen which looks like this:
-
lu Configuring libc6:s390x tk
x Running services and
Source: glibc
Version: 2.19-10
Severity: normal
From the Debian changelog:
,
| * debian/control.in/main: build-depends on dpkg-dev (= 1.17.1) and
| gcc-4.8 (= 4.8.3-8) to make sure to get the new i586 GNU triplet on
| i386, hurd-i386 and kfreebsd-i386.
`
However, the cputable
Package: base-files,libc-bin
Both base-files and libc-bin install the /etc/nsswitch.conf file.
Although it has been agreed in #673271 that libc-bin should take over
responsibility for it, base-files still installs and updates it.
Moreover, in response for #699090 base-files has updated its copy,
Source: glibc
Version: 2.22-8
Severity: normal
Bug #759495 redux: the cputable file is shipped by dpkg, not by
dpkg-dev, so build-depending on dpkg-dev (>= 1.18.7) does not achieve
anything.
While the build dependency on a recent g++-5 ensures that the right
compiler is used (i586-linux-gnu is a
Package: libc6-dev
Version: 2.24-1
Severity: important
The fix for bug #834706 has the side effect that libc6-dev now depends
on linux-libc-dev:$arch :
,
| $ apt-cache show libc6-dev | grep ^Depends
| Depends: libc6 (= 2.24-1), libc-dev-bin (= 2.24-1), linux-libc-dev:i386 (>=
4.6.4-1)
`
On 2013-07-10 21:32 +0200, Sven Joachim wrote:
> On 2009-07-11 08:02 +0200, Sven Joachim wrote:
>
>> tags 536506 + patch
>> thanks
>>
>> On 2009-07-11 02:06 +0200, Aurelien Jarno wrote:
>>
>>> tag 536506 + help
>>> thanks
>>>
&
On 2018-01-24 21:05 +0100, Javier Serrano Polo wrote:
> El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure:
>> The dynamic linker path is part of the
>> x86-64 ABI and is present in all ELF executables.
>
> I am aware that the original specification has that quirk, but it was
>
Package: libc6-amd64
Version: 2.27-4
Severity: important
On i386, libc6-amd64 and libc6-x32 install more than one gigabyte each:
,
| $ apt-cache show libc6-amd64 libc6-x32 | grep Installed-Size
| Installed-Size: 1143839
| Installed-Size: 1143407
`
Looking at /lib64, all the .so files
Control: reassign -1 binutils 2.30.90.20180627-1
Control: retitle -1 binutils: produces large 64-bit libraries on i386
Control: affects -1 libc6-amd64 libc6-x32
On 2018-07-09 11:19 +0200, Sven Joachim wrote:
> Package: libc6-amd64
> Version: 2.27-4
> Severity: important
>
> On i3
Am 14.10.2018 um 13:38 schrieb Florian Weimer:
> * Sven Joachim:
>
>> This result is rather surprising. After all, "putchar('x')" is supposed
>> to do the same as "putc('x', stdout)", but here it does not.
>
> Can you reproduce this w
Control: retitle -1 libc6: putchar does not follow stdio
On 2014-09-12 09:10 -0700, Thomas D. Dean wrote:
> Package: libc6
> Version: 2.13-38+rpi2+deb7u3
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Redirecting stdout in C code does not work for
Source: glibc
Version: 2.29-1
Severity: normal
According to the INSTALL file, Python is now required to build glibc:
,
|* Python 3.4 or later
|
| Python is required to build the GNU C Library. As of release time,
| Python 3.7.1 is the newest verified to work for building and
|
me!
Cheers,
Sven
From 8d3ef80d688b71503dc369b68bf0323349e9fbda Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Mon, 9 Sep 2019 13:46:28 +0200
Subject: [PATCH 1/1] Do not restart services of different architecture than
libc
Only check services in packages which are of the same architecture, or
&q
Control: reassign -1 rpcbind
This bug has been reported against rpcinfo which is no longer shipped in
libc-bin, but rather in rpcbind. I could not tell off-hand if it still
relevant.
Cheers,
Sven
Am 25.06.2010 um 21:46 schrieb Alexander Kretschmer:
> Package: libc-bin
> Version:
Control:; reassign -1 rpcbind
This bug has been assigned to libc6 which no longer ships the rpcinfo
program.
On 2006-03-26 15:04 +0200, Steinar H. Gunderson wrote:
> tags 353867 - patch
> thanks
>
> On Tue, Feb 21, 2006 at 03:55:17PM +0100, Stephan Krempel wrote:
>> -
Control: reassign -1 cpp-9
Control: forcemerge 953806 -1
On 2020-03-14 10:11 +0100, Berillions wrote:
> Package: libc6-dev
> Version: 2.30-2
>
> Hello,
>
> I try to build plain wine-5.4 on my debian sid 64bits (directly on my
> system or in a chroot with pbuilder) and i have an error about
Control: reassign -1 cpp-9
Control: forcemerge 953806 -1
On 2020-03-13 20:03 +0100, Adam Sjøgren wrote:
> Package: libc6-dev
> Version: 2.30-2
> Severity: normal
>
> Dear Maintainer,
>
> I cannot build GNU Emacs on Debian unstable after the latest update -
> configure
> fails with an error with
On 2020-11-13 18:23 +0100, Niels Thykier wrote:
> Control: reassign -1 perl-base
> Control: affects -1 upgrade-reports
> Control: severity -1 grave
>
> Hi Perl team,
>
> I have reassigned this bug to perl because perl-base being essential
> must remain functional during an upgrade and AFAICT
On 2020-11-19 19:47 +0100, Marco d'Itri wrote:
> On Nov 16, Niko Tyni wrote:
>
>> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
>> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
>> is fully installed.
> I think that Niko is right, so I would
Package: locales
Version: 2.31-11
Severity: normal
Tags: l10n
Running "dpkg-reconfigure locales" in a German locale displays broken
non-ASCII characters, see the attached screenshot.
It seems this is because of a mismatch between content and declared
encoding in debian/po/de.po. I will send a
Control; tags -1 patch
On 2021-04-06 11:42 +0200, Sven Joachim wrote:
> Package: locales
> Version: 2.31-11
> Severity: normal
> Tags: l10n
>
> Running "dpkg-reconfigure locales" in a German locale displays broken
> non-ASCII characters, see the attached screensho
On 2021-03-05 14:41 +0100, Aurelien Jarno wrote:
> control: notfound -1 libc6/2.28-10
> control: found -1 libc6/2.31-9
> control: severity -1 grave
>
> On 2021-03-04 19:26, Thomas Hahn wrote:
>> Package: libc6
>> Version: 2.28-10
>> Severity: normal
>> X-Debbugs-Cc: thah...@t-online.de
>>
>> Dear
On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:
> Package: libc6
> Version: 2.36-7
> Severity: serious
>
> The new libc6 appears to have some change related to Unicode that
> yields display issues in screen 4.9.0-3, such as horizontal and/or
> vertical text shifting. A consequence of this text
On 2023-01-02 19:08 +0100, Vincent Lefevre wrote:
> On 2023-01-02 18:07:52 +0100, Sven Joachim wrote:
>> On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:
>> > There is no such issue under bullseye (Debian 11.6), which also has
>> > GNU Screen 4.09.00, so the breakage
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30701
On 2023-07-30 13:25 +0200, Sven Joachim wrote:
> Package: libc6
> Version: 2.37-6
> Tags: upstream
>
> The utmp(5) interface has broken its compatibility in 32-bit programs
> built with -D_TIME_BITS=64
Package: libc6
Version: 2.37-6
Tags: upstream
The utmp(5) interface has broken its compatibility in 32-bit programs
built with -D_TIME_BITS=64. In bits/utmpx.h we see this:
,
| /* The fields ut_session and ut_tv must be the same size when compiled
|32- and 64-bit. This allows files and
Am 21.01.2024 um 15:25 schrieb Helmut Grohne:
> Source: glibc
> Version: 2.37-13
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
>
> Hi Aurelien,
>
> thanks for your answers on IRC to my design question. As promised here
> comes a patch that moves most files in binary packages built
On 2024-04-03 22:47 +0200, Alejandro Colomar wrote:
> On Wed, Apr 03, 2024 at 06:01:50PM +0200, Sven Joachim wrote:
>> Control: severity -1 normal
>>
>> On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:
>>
>> > I now see that `apt-file show glibc-doc` shows
Control: severity -1 normal
On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:
> Hi,
>
> On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote:
>> Thanks, that sounds great that we can finally get rid out of those in
>> the debian package.
>>
>> >$ git diff --stat
On 2024-04-01 19:02 +0200, Alejandro Colomar wrote:
> Hi Sven,
>
> On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
>> Makes perfect sense, but at the moment it can only be uploaded to
>> experimental.
>>
>> > We're not in a freeze, so I
On 2024-04-01 16:23 +0200, Alejandro Colomar wrote:
> Package: glibc-doc
> Version: 2.38-6
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: a...@kernel.org, mar...@debian.org
>
> Dear Maintainer,
>
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages
On 2024-04-01 18:00 +0200, Alejandro Colomar wrote:
> Hi Sven,
>
> On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
>> Obviously the manpages-dev package should not have shipped these files
>> as long as there are in glibc-doc; this is tracked in #1068166.
>
94 matches
Mail list logo
