Bug#373779: libc6: assertion failure in gconv_db.c with smbclient

2006-06-15 Thread Helmut Grohne
Package: libc6 Version: 2.3.999.2-4 Severity: normal # smbclient smbclient: gconv_db.c:232: __gconv_release_step: Assertion `step-__end_fct == ((void *)0)' failed. Aborted # This does not happen with 2.3.6-9. The bug seems to occur while loading shared libraries as different options to

Bug#352139: getopt optional arg does not work as documented

2007-02-27 Thread Helmut Grohne
tag 352139 wontfix thanks However, this does not seem to be the case. Actually it works quite similar. When run: [EMAIL PROTECTED]:/tmp$ a.out -a a arg is: (null) Correct behaviour. $ ./a.out -afoo a arg is: foo [EMAIL PROTECTED]:/tmp$ a.out -a hello a arg is: (null) Now.

Bug#160683: date: long timezone offset sighlently changed

2007-02-27 Thread Helmut Grohne
tag 160683 moreinfo thanks On Thu, Sep 12, 2002 at 12:10:48PM -0700, Blars Blarson wrote: Gnu date apperently siglently limits the timezone offset to 23, so the above command will SOMETIMES show todays date instead with no error message. (The SOMETIMES makes this even harder to debug.) This

Bug#286825: fixed in experimental

2007-03-06 Thread Helmut Grohne
tags 286825 = fixed-in-experimental thanks This bug seems to be fixed in experimental. Helmut Grohne signature.asc Description: Digital signature

Bug#310445: More information needed

2007-03-06 Thread Helmut Grohne
tag 310445 moreinfo severity 310445 normal thanks There are new versions of glibc available. Could you perhaps recheck whether this bug is reproducible? Furthermore the source for that binary would be helpful if available. Helmut Grohne signature.asc Description: Digital signature

Bug#336843: adduser: removes user from group if /etc/group file ends with :

2007-03-06 Thread Helmut Grohne
does here is within the specs. The function could also segfault at that point. This could maybe reported to the upstream but they'll probably think the same way. Helmut Grohne signature.asc Description: Digital signature

Bug#331405: Accidential activation of nscd is too simple

2007-03-06 Thread Helmut Grohne
their behaviour since there are only 5 packages in apt-cache rdepends nscd of which at least one is a conflict. So maybe libpam-ldap could suggest nscd instead of recommending it. Otherwise this bug should be tagged wontfix. Helmut Grohne signature.asc Description: Digital signature

Bug#352139: getopt optional arg does not work as documented

2007-03-06 Thread Helmut Grohne
be adapted. Thanks to Aurelien Jarno for pointing this out. Helmut Grohne signature.asc Description: Digital signature

Bug#667023: src:eglibc: please provide a binary package for the x32 sub architecture on amd64

2012-04-03 Thread Helmut Grohne
Package: src:eglibc Version: 2.13-27 Severity: normal Tags: upstream Blocks: 667005 gcc-4.7 and binutils (2.22) already provide support for the x32 abi. The missing piece to producing x32 binaries is a c library. Patches are available at git://github.com/hjl-tools/glibc.git. An aspect that makes

Bug#667023: 2.15 brings x32 support

2012-05-27 Thread Helmut Grohne
block 667023 by 672934 thanks x32 support has been merged into the 2.15 version of glibc. Since carrying x32 patches ourselves seems like a useless waste of time, I mark the x32 bug as being blocked by the new upstream version. Helmut -- To UNSUBSCRIBE, email to

Bug#708504: src:eglibc: drop always satisfied build-dependency sed

2013-05-15 Thread Helmut Grohne
Package: src:eglibc Version: 2.17-2 Severity: wishlist Could you drop sed from Build-Depends? Rationale: * Currently it is sed (= 4.0.5-4). The version required is satisfied in old old stable and the package itself is essential. * sed lacks Multi-Arch foreign (#693872), so this makes cross

Bug#708504: src:eglibc: drop always satisfied build-dependency sed

2013-05-16 Thread Helmut Grohne
Control: retitle -1 drop always satisfied build-dependencies sed and make Sorry for the noise. On Thu, May 16, 2013 at 07:45:59AM +0200, Helmut Grohne wrote: Could you drop sed from Build-Depends? Rationale: * Currently it is sed (= 4.0.5-4). The version required is satisfied in old old

Bug#742640: src:eglibc: build stage2 without selinux

2014-03-25 Thread Helmut Grohne
Package: src:eglibc Version: 2.18-4 Severity: wishlist Tags: patch The eglibc package currently lacks a stage2 build profile entirely. A stage2 is needed though, because libselinux cannot be built without an actual libc among other things and eglibc explicitly enabled selinux via a configure

Bug#743676: FTCBFS: i386 stage1 tries to install xen stuff which is not built

2014-04-05 Thread Helmut Grohne
they are +not built. Closes: #-1. + + -- Helmut Grohne hel...@dedup1.subdivi.de Sat, 05 Apr 2014 08:07:22 +0200 + eglibc (2.18-4) unstable; urgency=high [ Aurelien Jarno ] diff -Nru eglibc-2.18/debian/sysdeps/i386.mk eglibc-2.18/debian/sysdeps/i386.mk --- eglibc-2.18/debian/sysdeps/i386.mk 2014-03-02 16:01

Bug#745380: src:eglibc: support non-multilib builds

2014-04-21 Thread Helmut Grohne
+ + * Non-maintainer upload. + * Add a nobiarch stage that inhibits all multilib packages from being +built. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Mon, 21 Apr 2014 07:44:15 +0200 + eglibc (2.18-4) unstable; urgency=high [ Aurelien Jarno ] diff -Nru eglibc-2.18/debian/rules

Bug#752480: src:eglibc: use the build profile spec

2014-06-23 Thread Helmut Grohne
=stage1 to conform with +https://wiki.debian.org/BuildProfileSpec. Closes: #-1 + + -- Helmut Grohne hel...@subdivi.de Wed, 18 Jun 2014 17:05:21 +0200 + eglibc (2.19-3) unstable; urgency=medium [ Aurelien Jarno ] diff -Nru eglibc-2.19/debian/control.in/amd64 eglibc-2.19/debian/control.in/amd64

Bug#742640: src:eglibc: build stage2 without selinux

2014-07-10 Thread Helmut Grohne
Version: 2.19-5 On Tue, Mar 25, 2014 at 09:51:33PM +0100, Helmut Grohne wrote: The eglibc package currently lacks a stage2 build profile entirely. A stage2 is needed though, because libselinux cannot be built without an actual libc among other things and eglibc explicitly enabled selinux via

Bug#754350: src:glibc: fix dh_strip call in stage1

2014-07-10 Thread Helmut Grohne
Package: src:glibc Version: 2.19-5 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap I introduced a regression in my patch for #752480. All non-dev packages were (correctly) marked with Build-Profiles: !stage1. For debhelper this means, that those packages no longer

Bug#742640: src:eglibc: build stage2 without selinux

2014-07-15 Thread Helmut Grohne
On Thu, Jul 10, 2014 at 09:46:05PM +0200, Aurelien Jarno wrote: Hmm, the above has actually been removed in favor of a test on $(DEB_BUILD_PROFILES). Instead of duplicating the code, please test for both stage1 and stage2 in the same test. Updating patch addressing both concerns.

Bug#745380: src:eglibc: support non-multilib builds

2014-07-20 Thread Helmut Grohne
On Mon, Apr 21, 2014 at 07:58:51AM +0200, Helmut Grohne wrote: Please consider the attached patch to achieve this goal. Please find an updated patch attached. Changes since last version: * Add Build-Profiles headers to binary packages. * Don't treat optimized packages (e.g. i686) as multilib

Bug#755580: src:glibc: drop libgcc dependency from stage2 builds

2014-07-22 Thread Helmut Grohne
dependencies on libgcc when building stage2. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Sun, 20 Jul 2014 22:06:57 +0200 + glibc (2.19-7) unstable; urgency=high * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply diff -Nru glibc-2.19/debian/control.in/libc glibc

Bug#756095: src:glibc: application of debian/patches/ia64/local-rtld-compile-options.diff fails

2014-07-26 Thread Helmut Grohne
. +(Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Sat, 26 Jul 2014 07:41:10 +0200 + glibc (2.19-7) unstable; urgency=high * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply diff -Nru glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff glibc-2.19/debian/patches

Bug#756473: src:glibc: install multilib stubs-$abi.h when bootstrapping

2014-07-30 Thread Helmut Grohne
@@ -1,3 +1,11 @@ +glibc (2.19-7.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * debian/patches/any/local-bootstrap-headers.diff: Update to handle +stubs-$abi.h which is required for multilib bootstraps. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Wed, 30 Jul 2014 09:28:26

Bug#773300: Improve glibc bootstrap

2014-12-16 Thread Helmut Grohne
On Tue, Dec 16, 2014 at 11:39:40PM +0800, YunQiang Su wrote: Hi, the attached patch can improve bootstrapping of glibc. Partially, this seems to be a duplicate of #766877. Maybe these should be merged? It produces the similiar stage1 glibc (libc6/libc6-dev and multilib version of them), at

Bug#766877: Fix multilib enabled stage1 cross builds

2014-12-16 Thread Helmut Grohne
Control: user helm...@debian.org Control: usertags -1 + rebootstrap On Sun, Oct 26, 2014 at 02:23:07PM +0100, Matthias Klose wrote: The patch fixes building multilib enabled stage1 cross, by doing the call xx dance for stage1 as well, as well as generating the debhelper files for multilib

Bug#759530: CPU info?

2015-01-10 Thread Helmut Grohne
On Thu, Jan 01, 2015 at 10:09:58PM +0100, Yves-Alexis Perez wrote: I'm not experiencing that bug, but maybe it'd help if the submitters would provide their /proc/cpuinfo and maybe try to get a clue about where the segfault happens (maybe with coredumps)? /proc/cpuinfo from Bernd Zeimetz (he

Bug#780431: 2.19-16 breaks stage2 build

2015-03-13 Thread Helmut Grohne
Package: src:glibc Version: 2.19-16 Tags: patch User: helm...@debian.org Usertags: rebootstrap The glibc 2.19-16 upload regresses the stage2 build. The regression is introudced in svn revision 6371 in debian/rules.d/debhelper.mk where tmp.substvars is no longer generated for stage2. The build

Bug#780431: 2.19-16 breaks stage2 build

2015-03-13 Thread Helmut Grohne
On Fri, Mar 13, 2015 at 09:36:01PM +0100, Helmut Grohne wrote: I verified that the attached patch solves the issue. As Adam pointed out, my patch was missing. Sorry. But it really is equivalent to what is already in SVN. So this mostly is a confirmation. Helmut diff -Nru glibc-2.19/debian

Bug#766877: Fix multilib enabled stage1 cross builds

2015-04-30 Thread Helmut Grohne
On Tue, Dec 16, 2014 at 08:51:44PM +0100, Helmut Grohne wrote: Matthias patch does not work for architectures with optimized libcs (called otherarch in glibc packaging, i.e. i386, mipsel, alpha). Matthias asked to clarify my stance on this patch. The above says that the patch does not work

Bug#784015: undeclared file conflict between libc6-i386 and libc6-mipsn32

2015-05-02 Thread Helmut Grohne
Package: libc6-i386,libc6-mipsn32 Version: 2.19-18 User: helm...@debian.org Usertags: rebootstrap | dpkg: error processing archive /tmp/repo/pool/main/g/glibc/libc6-mipsn32_2.19-18_mips.deb (--unpack): | trying to overwrite '/usr/lib32/gconv/ANSI_X3.110.so', which is also in package libc6-i386

Re: Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or d

2015-05-30 Thread Helmut Grohne
Control: severity -1 wishlist Control: reassign -1 libc6 Control: retitle -1 ld-linux.so loads libraries from . when /proc is not mounted Control: affects -1 + ghc Control: summary -1 0 When /proc is not mounted, a relative RPATH causes ld-linux.so to fall back to using the working directory as

Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path

2015-09-05 Thread Helmut Grohne
Hi Steven, On Sat, Sep 05, 2015 at 01:50:02AM +0100, Steven Chamberlain wrote: > We're hoping to move kfreebsd-kernel-headers' files to multiarch > path /usr/include/$(DEB_TARGET_MULTIARCH), so that headers of other > kernels are co-installable on a build machine (for cross-building and >

Bug#797831: glibc: further problems with stage1

2015-09-08 Thread Helmut Grohne
Hi Aurelien, On Tue, Sep 08, 2015 at 07:58:13PM +0200, Aurelien Jarno wrote: > Thanks for the patch and the detailed explanation. The changes make sense, > so I have applied the patch. Thank you. > That said looking as this part of the code as a whole, it ends up being a > bit complicated.

Bug#797831: glibc: further problems with stage1

2015-09-02 Thread Helmut Grohne
Source: glibc Version: 2.21-0experimental1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, thank you very much for applying #766877 and uploading to experimental. This has moved us a big step closer to a working stage1. We are not quite there yet. At this point I estimate

Bug#773300: Improve glibc bootstrap

2015-09-09 Thread Helmut Grohne
In the mean time, the other patch #766877 was merged into experimental. Time to review this bug. Unfortunately, the original submission lacks details on what problems are being solved, so assessing the solutions is difficult and I do not understand all the aspects. | diff -urN debian/rules

Bug#806912: Don't build optimized variants in stage1 or stage2 builds

2015-12-03 Thread Helmut Grohne
On Wed, Dec 02, 2015 at 09:20:58PM +0100, Matthias Klose wrote: > Package: src:glibc > Version: 2.21-1 > Tags: patch > > Don't build optimized variants in stage1 or stage2 builds; saves a pass on > alpha and i386. I think that the functionality requested here is useful, but I have a few remarks

Bug#817944: nios2 support

2016-03-11 Thread Helmut Grohne
Source: glibc Version: 2.22-2 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Dear glibc maintainers, >From a Debian pov, nios2 is a pretty new architecture. It has been added to dpkg in version 1.18.4. Marek Vasut has been working on actually bootstrapping the port

Bug#840260: glibc: please support the tilegx architecture

2016-10-09 Thread Helmut Grohne
-2.24/debian/changelog --- glibc-2.24/debian/changelog 2016-09-17 20:00:44.0 +0200 +++ glibc-2.24/debian/changelog 2016-10-10 06:36:11.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.24-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support tilegx. (Closes: #-1) + + -- Helmut

Bug#840260: glibc: please support the tilegx architecture

2016-10-15 Thread Helmut Grohne
Hi Aurelien, On Sat, Oct 15, 2016 at 09:15:36PM +0200, Aurelien Jarno wrote: > Unfortunately this is not enough. Recent dak versions check that the > architecture is known by dpkg, and ftp-master.debian.org is using > jessie. If we add tilegx to the Architecture: list, the source package > will

Bug#869717: glibc FTBFS: Error: `loc1@GLIBC_2.2.5' can't be versioned to common symbol 'loc1'

2017-07-25 Thread Helmut Grohne
Source: glibc Version: 2.24-12 Severity: serious Tags: patch upstream fixed-upstream Forwarded: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=388b4f1a02f3a801965028bbfcd48d905638b797 User: helm...@debian.org Usertags: rebootstrap glibc fails to build from source in unstable

Bug#883186: e2fsprogs FTBFS on mips64el: undefined reference to `posix_fadvise64'

2017-11-30 Thread Helmut Grohne
Source: e2fsprogs Version: 1.43.7-1 Severity: serious Justification: FTBFS User: helm...@debian.org Usertags: rebootstrap I was investigating a bootstrap failure for mips64el (https://jenkins.debian.net/job/rebootstrap_mips64el_gcc7_nobiarch/51) and wondered whether this was a native issue.

Bug#882263: libc6-dev-mips64el-cross breaks linking executables

2017-11-20 Thread Helmut Grohne
Package: libc6-dev-mips64el-cross Version: 20 Severity: serious User: helm...@debian.org Usertags: rebootstrap I was trying to use gcc-mips64el-linux-gnuabi64 to link a trivial executable: $ echo 'int main(){return 0;}' | mips64el-linux-gnuabi64-gcc -x c - -o /dev/null With libc6-dev:mips64el

Bug#898743: breaks when #included after

2018-05-15 Thread Helmut Grohne
Package: linux-libc-dev,libc6-dev Severity: serious Justification: makes systemd ftbfs User: helm...@debian.org Usertags: rebootstrap Control: affects -1 + src:systemd libmount-dev systemd FTBFS here, because compiling load-fragment.c fails. I spent a while minimizing that file and it boils down

Bug#902800: glibc FTBFS: dh_installdocs: Cannot find (any matches for) "BUGS" (tried in .)

2018-07-01 Thread Helmut Grohne
Source: glibc Version: 2.27-3 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap glibc fails to cross build from source. An arch-only build log (using DEB_BUILD_OPTIONS=nocheck to speed things

Bug#886301: glibc: logme removal accidentally breaks stage1

2018-01-03 Thread Helmut Grohne
Source: glibc Version: 2.26-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, pkg-glibc commit 74784d0d9e06adb57047548685e79ea0223a05ac ("debian/rules, debian/rules.d/build.mk: stop logging build/check messages to files, both sbuild and debuild are able to do that.")

Bug#886315: libc6-dev-$arch-cross incompatible with libc6-dev:$arch: glibc major version skew

2018-01-04 Thread Helmut Grohne
Package: libc6-dev-arm64-cross,libc6-dev-armel-cross,libc6-dev-armhf-cross,libc6-dev-mips-cross,libc6-dev-mips64el-cross,libc6-dev-mipsel-cross,libc6-dev-ppc64el-cross,libc6-dev-s390x-cross Version: 2.25-3cross1 Severity: important User: helm...@debian.org Usertags: rebootstrap Control: block -1

Bug#892126: glibc: stage1 build failure due to missing multilib lib-names-*.h

2018-03-05 Thread Helmut Grohne
Source: glibc Version: 2.27-1 User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, I need a bug number for tracking this issue, so I am filing this bug summarizing the problem and recording my knowledge. Building glibc with DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=stage1 presently

Re: Propose requiring Python 3.4 or later for building glibc.

2018-10-22 Thread Helmut Grohne
; default Python 3 version in unstable (which is relevant for future > versions of glibc) is already 3.6. > > We also need to consider the process of bootstrapping Debian. In that > case I believe it should also be fine as Python 3 from the host system > can be used. I

Re: Propose requiring Python 3.4 or later for building glibc.

2018-10-22 Thread Helmut Grohne
On Mon, Oct 22, 2018 at 11:38:15AM -0400, Carlos O'Donell wrote: > It is possible that the build *and* host require python 3.4. > > The reason being that when cross-testing glibc with the test-wrapper-env > script the build system may execute a command on the host system to > run python (which

Bug#798955: How to deal with gcc's with multiarch glibc headers?

2018-10-01 Thread Helmut Grohne
Hi, I was offered some CPU cycles to research the impact of #798955 (moving glibc's headers to /usr/include/). I'll post another mail with a summary, but there is already one quite obvious issue affecting multiple packages. The implications are not quite clear to me, so maybe someone else can

Bug#916588: libc6: uses non-essential runlevel in preinst and postinst

2018-12-16 Thread Helmut Grohne
Package: libc6 Version: 2.28-2 Severity: minor While upgrading libc6 from 2.27-8 to 2.28-2, I saw this: | Checking for services that may need to be restarted... | Checking init scripts... | /var/lib/dpkg/tmp.ci/preinst: 320: /var/lib/dpkg/tmp.ci/preinst: runlevel: not found That's libc6's

Bug#946396: glibc+libxcrypt breaks cross-toolchain-base

2019-12-08 Thread Helmut Grohne
Source: glibc Version: 2.29-5 Severity: serious Justification: installation failure Control: affects -1 + src:cross-toolchain-base Since glibc added dependencies on libxcrypt, building cross-toolchain-base produces packages that are not installable: | $ dpkg-deb -I

Bug#956855: consider reducing toolchain bootstrap stages

2020-04-15 Thread Helmut Grohne
-maintainer upload. + * Bootstrap with fewer stages. (Closes: #-1) + + -- Helmut Grohne Wed, 15 Apr 2020 11:35:18 +0200 + cross-toolchain-base (45) unstable; urgency=medium * Build using glibc 2.30-2. diff --minimal -Nru cross-toolchain-base-45/debian/rules cross-toolchain-base-45+nmu1/debian

Bug#910685: glibc: please support DPKG_ROOT

2020-04-19 Thread Helmut Grohne
Hi Aurelien, On Tue, Apr 14, 2020 at 05:49:38PM +0200, Helmut Grohne wrote: > Yes, please. Is there anything blocking this? Without support in glibc, > moving forward is a little difficult. Can you include it soonish? I pinged Aurelien on IRC about this. Let me summarize your answe

Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers

2020-04-19 Thread Helmut Grohne
The and headers need their counter parts and from the libc respectively, but libstdc++ wraps these headers. Now and include these headers using $ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null In file included from :1: /usr/include/c++/9/cstdlib:75:15: fatal error:

Bug#958674: glibc: refactor generation of multilib include symlinks

2020-04-24 Thread Helmut Grohne
. + * Refactor generation of multilib include symlinks. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/rules.d/build.mk glibc-2.30/debian/rules.d/build.mk --- glibc-2.30/debian

Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers

2020-04-22 Thread Helmut Grohne
Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > > Now you are probably going to say that "-isystem /usr/include" is a bad > > idea and that you shouldn't do that. > > Right. > > > I'm inclined to agree. This isn't a > > problem just yet. Debian wants to move

Bug#91815: Patch to add memusage and memusagestat

2020-05-03 Thread Helmut Grohne
Hi Aurelien and Stephen, On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote: > It's something we can fix. I found strange nobody notice so far. Does it > mean the bootstrap is done ignoring the build-dependencies? Yes, I still ignore build-depends entirely. glibc depends on a

Bug#958674: glibc: refactor generation of multilib include symlinks

2020-05-03 Thread Helmut Grohne
+0200 @@ -1,3 +1,10 @@ +glibc (2.30-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Refactor generation of multilib include symlinks. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --mi

Bug#91815: Patch to add memusage and memusagestat

2020-04-22 Thread Helmut Grohne
Hi Aurelien and Stephen, On Wed, Apr 22, 2020 at 12:04:32AM +0200, Aurelien Jarno wrote: > > The attached patch adds memusage and memusagestat to the libc-bin package. > > This does mean that the latter becomes dependent on libgd3, so it might be > > better to add a new memusage package; I can

Bug#910685: glibc: please support DPKG_ROOT

2020-04-14 Thread Helmut Grohne
NRELEASED; urgency=medium + + * Non-maintainer upload. + * Initial, minimal support for DPKG_ROOT. (Closes: #910685) + + -- Helmut Grohne Tue, 14 Apr 2020 17:39:34 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst

Bug#954393: please Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION})

2020-03-21 Thread Helmut Grohne
Package: libc6-dev Version: 2.30-2 Severity: wishlist Every time a new glibc upstream release gets uploaded, cross-toolchain-base breaks in difficult to diagnose ways. This seems to happen, because gcc uses the libc6-dev:somearch headers together with libc6-dev-somearch-cross libraries. Would

Bug#954392: libc6-dev-armhf-cross is incompatible with current libc6-dev:armhf

2020-03-21 Thread Helmut Grohne
Package: libc6-dev-armhf-cross Version: 2.29-9cross1 Severity: serious The current libc6-dev-armhf-cross is incompatible with libc6-dev:armhf versioned >= 2.30. Typical symptoms include (mips64el this time, but also reproducible for armhf):

Bug#91815: Patch to add memusage and memusagestat

2020-05-09 Thread Helmut Grohne
Hi Stephen, Thank you for not dropping the ball after my initial "it's not that easy" reply. On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote: > There’s another part of the transition which bothers me: if we add memusage > to a package which is depended upon (albeit temporarily) by

Bug#91815: Patch to add memusage and memusagestat

2020-07-08 Thread Helmut Grohne
Hi Stephen, On Wed, Jul 08, 2020 at 05:38:46PM +0200, Stephen Kitt wrote: > I don’t mind, it’s not as if this is an urgent bug ;-). Thank you for your patience and work on this. > I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin, > on purpose; it’s not only useful