Bug#1061266: [PATCH] sgmls: Fix type of signal handlers for C89 compatibility

Package: linuxdoc-tools Version: 0.9.82-1 Tags: upstream patch This is another fallout from GCC 14 porting of Fedora. Without this change, the outcome of two tests are altered due to compiler errors: -#define HAVE_EXTENDED_PRINTF 1 +/* #define HAVE_EXTENDED_PRINTF 1 */ -/* #define

Bug#1060065: ssmtp: GCC 14 compatibility fixes

Package: ssmtp While preparing Fedora for GCC 14, I encountered ssmtp as a package that fails to build. We record Debian as ssmtp's upstream, which is why I'm reporting this here. The first patch removes some bogus (char)NULL expressions. If you do not run autoconf during the build, you also

Bug#115503: texi2dvi: source file directory included in search path

* Hilmar Preuße: >> texi2dvi includes the source file directory in the TeX search path. >> This is quite unusual for programs processing -I options (such as C >> compilers), and even makeinfo doesn't do that. Furthermore, it's not >> possible to remove that directory from the search path. >> >

Bug#1050371: glibc 2.38 regression impacting djbdns

It looks like Adam Jackson found the root cause and is fixing it: [PATCH] libio: Fix oversized __io_vtables We're going to backport this fix to the upstream glibc 2.38 release branch. Thanks, Florian

Bug#1034362: [PATCH] sgmls: Avoid implicit ints/function declarations in configure

Package: linuxdoc-tools Version: 0.9.82-1 Tags: upstream patch These C features are no longer part of C99, and future compilers will no longer support them by default, causing the build to fail. The changes assume that the usual system headers (, ) are present, but that should not be a problem

Bug#1033397: Gnus cannot store some incoming mail into nnml

discussed in this subthread: From: Florian Weimer Subject: Re: master ef14acf: Make nnml handle invalid non-ASCII headers more consistently To: emacs-de...@gnu.org Cc: Lars Ingebrigtsen , d...@gnus.org Date: Fri, 16 Dec 2022 23:42:21 +0100 (13 weeks, 6 days, 11 hours ago) Message-ID: <874jtvq

Bug#1026235: tar: ftbfs with recent glibc

* John David Anglin: > On 2022-12-16 4:24 p.m., Florian Weimer wrote: >> * John David Anglin: >> >>> I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 >>> This would avoid the overflow converting tv_sec from 64 to 32 bits. >> It's

Bug#1026235: tar: ftbfs with recent glibc

* John David Anglin: > I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 > This would avoid the overflow converting tv_sec from 64 to 32 bits. It's an ABI break. You probably can enable it in the tar build safely because it's not a library. But doing it by default across

Bug#1026045: Pointer truncation issue in DLOPEN_LOCAL_SCAN patch

Package: exim4 Version: 4.96-9 We are trying to port Fedora to a more modern variant of C. This tripped up our Exim builds, and I see the same warning in the Exim builds for

Bug#1025973: C99 compatibility fixes for pmount

Package: pmount Version: 0.9.23-6 Tags: patch Future compilers (such as Clang 16 and GCC 14) are likely to disable support for implicit function declarations by default. This patch ensures that pmount doesn't stop building for this reason. diff --git a/src/luks.c b/src/luks.c index

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

* Alejandro Colomar: > Hi Florian! > > On 7/25/22 12:38, Florian Weimer wrote: >> * Alejandro Colomar via Libc-alpha: >> >>> Is there an easy way to regenerate that header to get the tatest >>> syscalls? Maybe a command could be supplied so that users (or

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

* Alejandro Colomar via Libc-alpha: > Is there an easy way to regenerate that header to get the tatest > syscalls? Maybe a command could be supplied so that users (or at > least distributors) have it easy to regenerate them? Maybe it already > exists but it's not widely known? I have recently

Bug#1006677: Java JIT Compiler fails to compile JavaFX method

* Frank Ulbricht: > [4. hs_err_pid1182.log --- application/octet-stream; hs_err_pid1182.log]... Frank, would you be able to send the compiler replay log as well (replay_pid*.log)? Thanks.

Bug#1006677: Java JIT Compiler fails to compile JavaFX method

* Frank Ulbricht: > --- T H R E A D --- > > Current thread (0x7f74e8101ef0): JavaThread "C2 CompilerThread0" daemon > [_thread_in_native, id=1195, stack(0x7f74cc211000,0x7f74cc312000)] > > > Current CompileTask: > C2:17931770 16689 4 >

Bug#1004433: Patches for CVE-2022-23959

* Salvatore Bonaccorso: > Thanks a lot for your testing, this is very much appreciated! > > Florian, should we go ahead with the DSA release? We should, I'll look into it this evening. Thanks for all the testing!

Bug#1004433: Patches for CVE-2022-23959

* Andreas Unterkircher: > Hello Salvatore! > >> Unofficial and amd64 only builds (including the source in case you >> want to built it on your own) are at: >> >> https://people.debian.org/~carnil/tmp/varnish/ > > I've installed v6.1.1 packages on several of our Buster servers. > Apparently all

Bug#1004577: ldconfig -p coredumps

* Christoph Berg: > Package: libc-bin > Version: 2.33-3 > Severity: important > > In > https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916 > there is a diff generated between the two builds because a core file > from `ldconfig -p` appears as

Bug#998156: contains non-DFSG-free files

* Henry Cejtin: > (I assume you meant ml-nlffigen.) ml-nlffigen is part of SML/NJ, not > part of MLton. /usr/bin/mlnlffigen is part of mlton-tools. I believe the code generation requirements are different for MLton and SML/NJ.

Bug#998156: contains non-DFSG-free files

* Henry Cejtin: > As far as I know, the ckit stuff is just included because it needed > some tweaks to work under MLton. > I don't think that any of "our" stuff depends on it. I think mlnffigen needs ckit.

Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL

* Aurelien Jarno: > I have been looking at the corresponding instruction, this is: > > 2ed0 <__cpu_indicator_init@GCC_4.8.0>: > 2ed0: f3 0f 1e fb endbr32 > > This is an Intel CET instruction, and it seems your CPU doesn't support > executing it. Anyway this shows that

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Aurelien Jarno: >> > Is it possible to commit those patches to the upstream 2.28 branch? If >> > so, I guess we can simply pull the branch in the Debian package, fixing >> > many other security bugs at the same time. >> >> I'm concerned about the GLIBC_PRIVATE internal ABI change, it causes >>

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Aurelien Jarno: > On 2021-06-04 20:34, Florian Weimer wrote: >> * Moritz Mühlenhoff: >> >> > Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno: >> >> control: forcemerge 967938 969926 >> >> >> >> Hi, >> >>

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Moritz Mühlenhoff: > Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno: >> control: forcemerge 967938 969926 >> >> Hi, >> >> On 2020-09-09 02:58, Bernd Zeimetz wrote: >> > Source: glibc >> > Version: 2.28-10 >> > Severity: serious >> > Tags: security upstream patch >> >

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

* Elana Hashman: > You and the original report mention "tooling issues". Can you please > provide some examples of tools that do not currently support working > with compressed symbols and the resulting effects on developer workflow? dwz still can't process compressed debuginfo sections, I

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

* Morel Bérenger: >> * Bérenger: > ... >> Why do you think this is a bug? > > POSIX 10031-2017 standard says: POSIX requires that if you manipulate the underlying file descriptor of a stream, you first need to call fseek when using the stream again. Your example code does not do that, so

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

* Bérenger: > When running following code: > > ```C > #include > #include > #include > > int main() > { > close( STDIN_FILENO ); > close( STDOUT_FILENO ); > int fd = dup( STDERR_FILENO ); > close( STDERR_FILENO ); > if( -1 == fprintf( stdout, "%d\n", fd ) ) >

Bug#979730: Errors when installing in a chroot, due to potentially outdated /proc test?

* Daniel Dunn: > Thank you for the fast reply! Does the installer actually use java for > anything? I think it used to create the CDS archive, but the .jsa files are now packaged, and the dump failure was ignored anyway. > This link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803717

Bug#979730: Errors when installing in a chroot, due to potentially outdated /proc test?

* Daniel Dunn: > In this file: > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/JB-jre-headless.postinst.in?h=openjdk-14 > > > This code seems to still exist. It complicates installation in a chroot, > > such as for CustomPiOS. Do we still need it? It says

Bug#976865: Fwd: Bug#974900: dash removes trailing slash from script arguments

* Herbert Xu: > On Thu, Dec 10, 2020 at 08:58:37AM +0100, Aurelien Jarno wrote: >> >> That's the dash symptoms. glob(3) takes a pattern and just returns the >> paths matching the pattern, as they are named on the filesystem. That >> said, the option GLOB_MARK can return a trailing slash for all

Bug#731082: Processed: severity of 731082 is normal

forwarded 731082 https://sourceware.org/bugzilla/show_bug.cgi?id=27008 tags 731082 + upstream thanks I happen to have a patch for this: A bit by accident, it ended up as part of the glibc-hwcaps work.

Bug#975219: [Debichem-devel] Bug#975219: elkcode: FTBFS: internal compiler error: in lookup_field_for_decl, at tree-nested.c:288

* Lucas Nussbaum: > Hi Michael, > > On 22/11/20 at 15:32 +0100, Michael Banck wrote: >> Hi Lucas, >> >> That looks like an ICE, shouldn't that be filed with gfortran? > > Usually my logic is: if there's only one similar failure, I file a bug > against the affected package, rather than against

Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

* Matthias Klose: > As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, > 15 > with 14, 16 with 15. Only having 11 in bullseye would make backports more > "interesting". All recent OpenJDK releases can be built by themselves, right? That's good enough for backports, I

Bug#975026: Use 公元 not 西元

* 積丹尼 Dan Jacobson: > I think this, > $ LC_TIME=zh_TW.UTF-8 date > 西元2020年11月18日 (週三) 12時39分44秒 CST > should say 公元 not 西元. Why do you think so? These Taiwanese newspapers appear to use 西元 for Gregorian years:

Bug#971515: Request for security team input on kubernetes TC bug

* Moritz Mühlenhoff: > On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote: >> * Moritz Mühlenhoff: >> >> > * Follow a scheme similar to Firefox ESR where in case of a security >> > the update either happens to the latest minor release of >>

Bug#971515: Request for security team input on kubernetes TC bug

* Moritz Mühlenhoff: > * Follow a scheme similar to Firefox ESR where in case of a security > the update either happens to the latest minor release of > the current branch or if that has stopped, happens to the next > major release. To map this to specific k8s releases: Let's assume

Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs

* Aurelien Jarno: > brk/sbrk is definitely something deprecated. But it is still part of the > API (especially for old architectures) and still used by software like > jemalloc, gcl or libgc. This is therefore important to keep this feature > in a good shape. > > It's also used by many less

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

* Julian Gilbey: > On Fri, Sep 25, 2020 at 06:22:33PM +0200, Florian Weimer wrote: >> * tony mancill: >> >> > I had already prepared the NMU for openjdk-15 - building first without >> > the patch and then with it so I could test with both - so I will go >>

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

* tony mancill: > I had already prepared the NMU for openjdk-15 - building first without > the patch and then with it so I could test with both - so I will go > ahead and upload that package today. There's also an upstream change to honor SOURCE_DATE_EPOCH: commit

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

* Aurelien DESBRIERES: > This is emacs and jedi-mode and much more elisp stuff to works with > emacs as python3 ide. > > Please update this glibc it seems to be outdated! That's simply not going to happen for the buster release. You will have to change the way you set up your pip environment.

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

* aurelien desbrieres: > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >try to use jedi-mode on emacs >* What exactly did you do (or not do) that was effective (or > ineffective)? >M-x jedi:install-server >

Bug#969618: getopt: optarg is NULL outside of loop

* John Scott: > #define _POSIX_C_SOURCE 200809L > #include > #include > #include > #include > int main(int argc, char *argv[]) { > int opt; > while((opt = getopt(argc, argv, "a:")) != -1) {} > assert(optarg != NULL); > } > > If this is invoked as './a.out -afoo', the inner

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

* Aurelien Jarno: > On 2020-08-06 06:08, Jinpu Wang wrote: >> Hi Florian, >> >> On Wed, Aug 5, 2020 at 6:44 PM Florian Weimer wrote: >> > >> > * Jinpu Wang: >> > >> > > Dear Maintainer: >> > > >> > > Sorry, a

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

* Jinpu Wang: > Dear Maintainer: > > Sorry, add some missing information below: > > After update to Buster, the systemd-sysusers are segfaulting every time. > After search around, I found following bugreport in glibc > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html > > I

Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

* Nicholas D. Steeves: > Hi, > > Adrian Bunk writes: > >> On Fri, Jul 10, 2020 at 07:48:31PM -0400, Nicholas D Steeves wrote: >> >>> it would still not be DFSG-free, because it >>> fails the "desert island test" for snail mail. Were OmniTI Computer >>> Consulting would accept email, it would

Bug#963699: PostgreSQL: WolfSSL support

* Felix Lechner: > On Tue, Jun 30, 2020 at 11:38 AM Florian Weimer wrote: >> >> The other issue (WolfSSL GPL violation due to linking against >> GPL-incompatible applications via libpq) unfortunately remains. > > Could that be remedied with a special grant from wolfSS

Bug#963699: PostgreSQL: WolfSSL support

* Felix Lechner: > Hi Florian > > On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer wrote: >> >> <https://github.com/wolfSSL/wolfssl/blob/master/LICENSING> says this: > > Kaleb from wolfSSL followed up today: > >> After going over with our management we s

Bug#963699: PostgreSQL: WolfSSL support

* Christoph Berg: > Re: Florian Weimer >> WolfSSL is licensed under the GPL, version 2 only. This means that >> applications which use libpq and whose license is incompatible with >> the GPL now violate the license of WolfSSL. Furthermore, the original >> GPL co

Bug#963699: PostgreSQL: WolfSSL support

* Felix Lechner: > Hi, > >> For postgresql-12, it fails at the configure stage > > Attached please find a WIP patch for wolfSSL support in postgresql-12. > The build log was too large, even with compression, to include here. WolfSSL is licensed under the GPL, version 2 only. This means that

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

* Aurelien Jarno: >> This doesn't seem correct to me. Is there any documentation giving a >> rationale for this ? Is there a way to change this locally ? > > I do not know enough about apparmor and its threat model to know if it > should be considered or not. From the glibc point of view,

Bug#962388: ITP: re2j -- linear-time regular expression matching in Java

* Vincent Prat: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-j...@lists.debian.org > > * Package name    : re2j >   Version    : 1.3 >   Upstream Author : The Go Authors > * URL : https://github.com/google/re2j > * License : BSD-3 >   Programming Lang: Java

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

* YunQiang Su: > Adrian Bunk 于2020年5月21日周四 上午4:44写道： >> >> On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote: >> > >> > FTR, after giving back golang-1.14 mipsel several times, it's finally >> > built, by a longson builder. >> > So I guess it only occurs on octeon. Since the

Bug#959231: security-tracker: Proxy Error on CVE-2020-11565 tracker page

* Salvatore Bonaccorso: > Hi Florian, > > On Fri, May 01, 2020 at 02:33:21PM +0200, Florian Weimer wrote: >> * Salvatore Bonaccorso: >> >> > Hi Florian, >> > >> > On Fri, May 01, 2020 at 02:11:50PM +0200, Florian Weimer wrote: >>

Bug#959231: security-tracker: Proxy Error on CVE-2020-11565 tracker page

* Salvatore Bonaccorso: > Hi Florian, > > On Fri, May 01, 2020 at 02:11:50PM +0200, Florian Weimer wrote: >> * Florian Weimer: >> >> > * Francesco Poli: >> > >> >> Please note that the CVE is mentioned in [DSA-4667-1]. >> >> >&

Bug#959231: security-tracker: Proxy Error on CVE-2020-11565 tracker page

* Florian Weimer: > * Francesco Poli: > >> Please note that the CVE is mentioned in [DSA-4667-1]. >> >> [DSA-4667-1]: >> <https://lists.debian.org/debian-security-announce/2020/msg00071.html> >> >> What's wrong with that tracker page? > &g

Bug#959231: security-tracker: Proxy Error on CVE-2020-11565 tracker page

* Francesco Poli: > Please note that the CVE is mentioned in [DSA-4667-1]. > > [DSA-4667-1]: > > > What's wrong with that tracker page? It's something in the NVD data that breaks the HTML escaping.

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Florian Weimer: > I raised the matter of compiler defaults on the GCC list: > > <https://gcc.gnu.org/pipermail/gcc/2020-April/232261.html> The link is now: <https://gcc.gnu.org/pipermail/gcc/2020-April/000491.html>

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

I raised the matter of compiler defaults on the GCC list: Thanks, Florian

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: >> > Significant performance impact has also been observed in less contrived >> > cases (MariaDB and Postgres), but I don't have a repro to share. >> >> But indeed what counts is number on real workloads. It

Bug#958045: Support trust-ad option from glibc 2.31

Package: resolvconf Version: 1.79 glibc 2.31 has support for recognizing that the name servers listed in /etc/resolv.conf are reached over a trusted network path and implement DNSSEC correctly (but do not necessarily perform validation): * The DNS stub resolver will optionally send the AD

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: >> > At least if I'm reading the code right (which I may very well not be >> > doing, being generally unfamiliar with gcc internals), -mtune=generic >> > enables the equivalent of

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: >> > Gcc provides two ways to enable support for these instructions at build >> > time. The simplest, and least disruptive, is to enable -moutline-atomics >> > globally in the arm64

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > Gcc provides two ways to enable support for these instructions at build > time. The simplest, and least disruptive, is to enable -moutline-atomics > globally in the arm64 glibc build. Shouldn't GCC do this by default, at least for -mtune=generic?

Bug#954715: glibc: FTBFS: tests failed: signal/tst-minsigstksz-1 signal/tst-minsigstksz-2

* Lucas Nussbaum: > Source: glibc > Version: 2.30-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200322 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. >> FAIL:

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

* Matthias Klose: > ok, now removing that leads to: > > $ cat foo.c > #include > > $ gcc -c foo.c > In file included from foo.c:1: > /usr/include/limits.h:124:26: error: no include path in which to search for > limits.h > 124 | # include_next > | ^ > >

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

* Matthias Klose: > On 3/4/20 9:33 AM, Florian Weimer wrote: >> * Matthias Klose: >> >>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >>&g

Bug#953054: "DeprecationWarning: PY_SSIZE_T_CLEAN will be required" after python3.7 -> 3.8

* Anders Breindahl: > As unattended-upgrades was doing its thing, my regularly-running > debsecan-exploitive monitoring suite started throwing these errors on > regular debsecan invocations: > > $ debsecan > /dev/null > /usr/bin/debsecan:95: DeprecationWarning: PY_SSIZE_T_CLEAN will be >

Bug#952668: openjdk-11-jre-headless fails to install in buster, Fatal Error in Frame v ~StubRoutines::call_stub

The crash happens here: 0: c5 f8 ae 5d a0 vstmxcsr -0x60(%rbp) 5: 8b 45 a0mov-0x60(%rbp),%eax 8: 81 e0 c0 ff 00 00 and$0xffc0,%eax e: 3b 05 06 6c f2 1d cmp0x1df26c06(%rip),%eax# 0x1df26c1a 14: 0f 84 08 00 00 00

Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

* Aurelien Jarno: >> I've been running into this myself a lot lately and wonder if >> anything has happened regarding this since 2014, after all it's >> been six years. >> I'm surprised so few people seem to be taking interest in this >> considering the amount of tools that rely on frame

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

Unfortunately, this change tickles an XFS bug:

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

consists of these patches: commit 173ec37bb2af6e30892a141d74d42db5957ddd36 Author: Florian Weimer Date: Sun Feb 9 11:50:44 2020 +0100 support: Add the xlstat function commit f6233ab412c3bebebacf65745e775e01506dd58d Author: Florian Weimer Date: Sun Feb 9 11:51:08 2020 +0100 Linux

Bug#948396: New glibc broke existing app due to historic stack alignment

* Petr Vandrovec: > Florian Weimer wrote on 1/7/2020 9:31 PM: >> * Petr Vandrovec: >> >>> As far as I can tell, while x86-64 ABI requires stack to be aligned >>> on entry to the functions, x86 ABI does not have any such >>> requirement, and so g

Bug#948396: New glibc broke existing app due to historic stack alignment

* Petr Vandrovec: > As far as I can tell, while x86-64 ABI requires stack to be aligned > on entry to the functions, x86 ABI does not have any such > requirement, and so glibc should align stack itself if it wants to > use XMM instructions that require aligned values. The i386 ABI was changed

Bug#944493: Please disable parallel install

Package: src:ghc Version: 8.8.1+dfsg1+is+8.6.5+dfsg1-2 Something like this seems to be needed because the install target does not ensure that directories are created before files that are installed into them: diff -Nru ghc-8.8.1+dfsg1+is+8.6.5+dfsg1/debian/rules

Bug#941277: dispatch function missing in header file generated for RPC service

* Simon Richter: > while implementing an RPC service (in 2019, no less!) I found out that the > dispatch function generated by rpcgen is not listed in the generated header > file, so if the service is generated without a main function or inetd > interface, the code using it needs to create its

Bug#874160: Fedora has C.UTF-8

* Adam Borowski: > Looks like Fedora has C.UTF-8 now, and even backported this change to their > stable releases: > > https://bugzilla.redhat.com/show_bug.cgi?id=902094 > > They're not upstream, but a good part of distros that are not downstream > from Debian are downstream from Fedora. This

Bug#939841: Acknowledgement (vorbisgain needs to be ported to C99)

Sorry, the patch was incomplete. configure needs to be changed as well (it's difficult to regenerate it; autoconf itself was not C99-compatible at the time, and later versions might produce a non-equivalent script.) Thanks, Florian diff -ur vorbisgain-0.36.orig/configure

Bug#939841: vorbisgain needs to be ported to C99

Package: src:vorbisgain Tags: patch vorbisgain fails to build with a strict C99 compiler which does not support implicit function declarations (for the isatty function). (NB: Upstream may use DOS encoding for the files.) diff -ur vorbisgain-0.36.orig/misc.c vorbisgain-0.36/misc.c ---

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > Sorry for late answer. > > On 17. 08. 19 22:18, Florian Weimer wrote: >> * Pavel Matěja: >> >>> The strange means they appear only on 2 servers out of 6. >>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon >

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Francesco Poli: > Hello everyone, > I am sorry to ask, but... I cannot understand what's the status of > [this bug report]. > > [this bug report]: > > A serious bug for libc6-dev without any apparent activity since last > March? Sure there must have been some

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > The strange means they appear only on 2 servers out of 6. > Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon > E3-1220 v6 produced crashes. > It did not matter if the host Debian was Stretch or Buster. Do you see crashes on stretch as well? What does the

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: >> Is there a way to reproduce your results easily? Upstream, we're >> looking for workloads which are difficult to handle for glibc's malloc >> and its default settings, so that we hopefully can improve things >> eventually. > > This way of the ready builds of the

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have > got the memory effectivity some better even than in Debian 7! Is there a way to reproduce your results easily? Upstream, we're looking for workloads which are difficult to handle for glibc's malloc and

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Initial condition of the problem representing is a program in the > single source code, built on-and for Debian 7, 8, 9, 10 with a result > in the Live disks. I think glibc 2.13 as shipped by Debian was not built with --enable-experimental-malloc, so it doesn't use arenas.

Bug#914941: http-parser: CVE-2018-12121

* Jérémy Lal: > Le dim. 21 juil. 2019 à 22:08, Florian Weimer a écrit : > >> * Jérémy Lal: >> >> > I believe this commit should partly be applied to http-parser: >> > https://github.com/nodejs/node/commit/a8532d4d2 >> > >> > Specifica

Bug#914941: http-parser: CVE-2018-12121

* Jérémy Lal: > I believe this commit should partly be applied to http-parser: > https://github.com/nodejs/node/commit/a8532d4d2 > > Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable > default (8192 instead of 81920 bytes) should be good for all other > software depending on

Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

* Nicholas D. Steeves: > Package name: fuidshift > Version : 3.0 > Upstream Author : Name > URL : https://github.com/lxc/lxd/tree/master/fuidshift > License : Apache 2.0 > Programming Lang: Go > Description : remap a filesystem tree to shift one set of UID/GID >

Bug#931771: subversion: E170013 (unable to connect to a repository) and E120171 (Error occured during SSL communication)

* Martin: > svn version 1.9.5-1+deb9u3 from stretch works fine, but after upgrading to the > fresh Debian buster stable release I cannot svn checkout using subversion > v1.10.4-1 Is the affected repository publicly accessible?

Bug#931535: debsecan: Add support to choose bullseye

* Salvatore Bonaccorso: > diff --git a/debian/debsecan.config b/debian/debsecan.config > index c6943a21e51f..85eff64c1389 100644 > --- a/debian/debsecan.config > +++ b/debian/debsecan.config > @@ -10,7 +10,7 @@ CRONFILE=/etc/cron.d/debsecan > > normalize_suite () { > case "$SUITE" in > -

Bug#273207: packaging metatype1, sources of lmodern

* Hilmar Preuße: > On 09.12.08 01:23, Norbert Preining wrote: > > Hi Florian, > >> might I remind you what you once said on 27. Sep 2004: >> >> / see bug report for full quote >> | (a) I, Florian Weimer, hereby declare my intention to package

Bug#928143: unblock: glibc/2.28-9

* Aurelien Jarno: > - Fix for memusagestat's Makefile related code, which has no impact on > the generated code. Sorry, I screwed that one up and had to revert it upstream for the 2.28 branch. I don't think the bug introduced by this commit matters for Debian at present, but it will cause

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after signal in amd64 32-bit compat mode thanks * Lucas Nussbaum: > On 27/03/19 at 08:48 +0100, Florian Weimer wrote: >> > If that's useful, I can easily provide access to an AWS VM to debug this >>

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

* Lucas Nussbaum: > On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote: >> On 2019-03-22 17:30, Florian Weimer wrote: >> > > About the archive rebuild: The rebuild was done on EC2 VM instances from >> > > Amazon Web Services, using a clean, minimal and up-to-date

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

> About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. I believe the actual test failure is tst-pkey. Presumably, this rebuild was

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Le 19/03/19 à 19:43, Florian Weimer a écrit : >> * Laurent Bigonville: >> >>> Package: libc6-dev >>> Version: 2.28-8 >>> Severity: serious >>> >>> Hi, >>> >>> The crypt.3 manp

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Package: libc6-dev > Version: 2.28-8 > Severity: serious > > Hi, > > The crypt.3 manpage, state that _XOPEN_SOURCE should be define for > crypt() to be available. > > But it looks that it's currently the opposite, if _XOPEN_SOURCE is > defined, the function cannot be

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

* Sven Joachim: > It does not, since Emacs is already configured that way. In Emacs 26.2, > the issue will be fixed by the patch at[1] which should probably be > cherry-picked for the Debian package. > > Cheers, >Sven > > > 1. >

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

* Joël Krähemann: > This happens as you call pthread_cond_destroy() twice on the very same > cond variable. Surely that's an application bug. Why do you think this is a glibc issue? Thanks, Florian

Bug#904808: libcap-ng0: libcap-ng's use of pthread_atfork causes segfaults

The problem here is the weak declaration: $ eu-readelf --symbols=.dynsym /lib64/libcap-ng.so.0.0.0 | grep pthread_atfork 28: 0 NOTYPE WEAK DEFAULTUNDEF pthread_atfork In the Fedora 29 build, the constructor looks like this: Dump of assembler code for function

Bug#693587: bind9: stop resolving

* Marco d'Itri: > ; Bad cache > ; > ; intercom.it/DS [ttl 590265] That TTL is extremely suspicious and is way longer than anything warranted by IT zone contents. Looks like the clock went back almost seven days since the entry was added to the cache. I suspect what happens is this: System

Bug#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

* Salvatore Bonaccorso: > CVE-2016-10739[0]: > | In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo > | function would successfully parse a string that contained an IPv4 > | address followed by whitespace and arbitrary characters, which could > | lead applications to

  1   2   3   4   5   6   7   8   9   10   >