On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
we almost certainly will not be using the path which has been enabled
in glibc up to now, namely /lib/i486-linux-gnu.
I'd heard that, and was somewhat concerned about whether that'd block
multiarch for yet another release cycle; I'm
Package: glibc-source
Version: 2.28-1
Severity: important
autopkgtest fails while trying to test whether glibc in unstable could
migrate to testing:
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1438735/log.gz
> tar -x -f /usr/src/glibc/glibc-2.28.tar.xz
> cp -a
On Thu, 07 Feb 2019 at 14:05:33 +0100, Adam Borowski wrote:
> a locale for a silly country with weird customs
Please don't take this tone. Insulting people who disagree with you[1]
is rarely an effective way to persuade them that you're right and
they're wrong.
> • promoting C.UTF-8 in our user
On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
> Remaining usecases of i386 will be old binaries, some old Linux binaries
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.
Based on background from my
On Sun, 09 Feb 2020 at 19:19:24 +, Simon McVittie wrote:
> On Sun, 09 Feb 2020 at 16:45:05 +0100, Mattia Rizzolo wrote:
> > I see glib2.0 is also failing in the r-b infra:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib2.0.html
>
> We could
Package: libc6
Version: 2.29-10
Severity: normal
Summarizing the glibc bits of #948834, which I'm about to close because
newer versions of glib2.0 bypass it:
Steps to reproduce
==
- Be in an environment with only loopback addresses. Using bubblewrap and
`bwrap --unshare-net
On Wed, 25 Mar 2020 at 13:15:03 +, Aurelien Jarno wrote:
> debian/debhelper.in/libc.preinst, debian/rules.d/debhelper.mk: there is no
> easy way to check if a file belongs to a package with usrmerge. Just drop all
> safety checks... Closes: #954915.
The /usr merge merges /foo with /usr/foo
Control: retitle -1 libgegl-sc-0.4.so: undefined symbol: __exp_finite
Control: reassign -1 libgegl-0.4-0 0.4.12-2
Control: affects -1 + gimp
Control: tags -1 + bullseye sid
Control: clone -1 -2
Control: severity -2 minor
Control: retitle -2 libc6: please consider adding Breaks on libgegl-0.4-0 (<<
Package: libc6
Version: 2.31-1
Severity: normal
I've encountered an odd bug in openarena (#966150) which I'm concerned
might be a glibc regression affecting other packages.
Some background: openarena is a game running on the ioquake3 engine
(main executable: /usr/lib/ioquake3/ioquake3). During
On Fri, 24 Jul 2020 at 14:36:54 +0200, Bastian Blank wrote:
> On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> > The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> > older (2020-02-18) toolchain fails to load on an up-to-
On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> On 25-04-2021 01:55, Aurelien Jarno wrote:
> > It appears that all the failures are related to containers. I have been
> > able to reproduce the issue with a bullseye kernel, which defaults to
> > kernel.unprivileged_userns_clone=1. It
On Sun, 25 Apr 2021 at 10:14:51 +0100, Simon McVittie wrote:
> On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> > On 25-04-2021 01:55, Aurelien Jarno wrote:
> > > It appears that all the failures are related to containers. I have been
> > > able to reproduc
Control: found -1 1.4.2-3
Sorry, this is still failing, dependent on unpack order:
> Preparing to unpack .../rpcsvc-proto_1.4.2-3_amd64.deb ...
> Unpacking rpcsvc-proto (1.4.2-3) ...
> dpkg: error processing archive
> /var/cache/apt/archives/rpcsvc-proto_1.4.2-3_amd64.deb (--unpack):
> trying
same issue.
Please consider the attached patch.
smcv
>From bffb450291513a1486dae6e04b1d126994ba22fe Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Tue, 14 Sep 2021 09:25:36 +0100
Subject: [PATCH] Restore versioned symbol tracking for mips, mipsel,
libc6-i386:x32
Commit d3f9fade "debian/libc6.symbols.
On Mon, 13 Sep 2021 at 22:59:32 +0200, Aurelien Jarno wrote:
> - running the operation on a non-existing user, but as loginctl does a
> check that the user exists, it has to be done directly with the dbus
> API, for instance "gdbus call --system --dest org.freedesktop.login1
> --object-path
Package: libc6
Version: 2.32-2
Severity: normal
libc6 (>= 2.32) appears to have triggered a regression in
python3-iptables, fixed in python3-iptables (= 1.0.0-2). Please consider
adding a versioned Breaks to prevent broken partial upgrades.
smcv
On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> Having ld.so as a real command makes the name architecture-agnostic.
> This discourages from hard-coding non-portable paths such as
> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
>
On Sun, 09 Jan 2022 at 13:48:06 +0100, Aurelien Jarno wrote:
> On 2022-01-06 11:21, Simon McVittie wrote:
> > * install locales-all (this costs > 200M but ensures that all locales are
> > available)
> >
> > For "reasonably large" desktop and serve
Package: locales-all
Version: 2.33-1
Severity: wishlist
As discussed recently on -devel and previously in #701585, at the moment
Debian users have a choice between two non-ideal locale setups:
* install locales and generate a subset of locale files with locale-gen
(this is optimal for small
20 matches
Mail list logo
