Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h
control: reassign -1 gcc-9 control: forcemerge 953806 -1 On 2020-03-13 23:00, Thorsten Glaser wrote: > Package: libc6-dev > Version: 2.30-2 > Severity: grave > Justification: renders package unusable > > Unsure whether it’s upstream or Debian, but… It's debian specific and not a glibc issue. Reassigning. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed (with 1 error): Re: Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h
Processing control commands:
> reassign -1 gcc-9
Bug #953830 [libc6-dev] /usr/include/limits.h:124:26: error: no include path in
which to search for limits.h
Bug reassigned from package 'libc6-dev' to 'gcc-9'.
No longer marked as found in versions glibc/2.30-2.
Ignoring request to alter fixed versions of bug #953830 to the same values
previously set
> forcemerge 953806 -1
Bug #953806 {Done: Matthias Klose } [cpp-9] cpp-9: no include
path in which to search for limits.h
Bug #953815 {Done: Matthias Klose } [cpp-9] libc6-dev: Cannot
build GNU Emacs - limits.h error in configure
Unable to merge bugs because:
package of #953830 is 'gcc-9' not 'cpp-9'
Failed to forcibly merge 953806: Did not alter merged bugs.
--
953806: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953806
953815: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953815
953830: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953830
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#953830: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h
Package: libc6-dev Version: 2.30-2 Severity: grave Justification: renders package unusable Unsure whether it’s upstream or Debian, but… tglase@tglase-nb:~ $ gcc x.c In file included from x.c:1: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next | ^ 1|tglase@tglase-nb:~ $ cat x.c #include (MWE extracted from a much larger attempt to compile something.) -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc6-dev:amd64 depends on: ii libc-dev-bin2.30-2 ii libc6 2.30-2 ii libcrypt-dev1:4.4.15-1 ii linux-libc-dev 5.4.19-1 libc6-dev:amd64 recommends no packages. Versions of packages libc6-dev:amd64 suggests: pn glibc-doc ii manpages-dev 5.05-1 -- no debconf information
Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure
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 the limits.h include.
>
> Here is a minimal reproduction:
>
> $ cat test.c
> #include
> #include
>
> int main(void) {
> exit(0);
> }
> $ gcc -Wall test.c
> In file included from test.c:2:
> /usr/include/limits.h:124:26: error: no include path in which to search for
> limits.h
> 124 | # include_next
> | ^
> $
Known problem, wait for gcc-9 9.3.0-3 to appear on your mirror.
Welcome to unstable!
Cheers,
Sven
Processed: Re: Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure
Processing control commands:
> reassign -1 cpp-9
Bug #953815 [libc6-dev] libc6-dev: Cannot build GNU Emacs - limits.h error in
configure
Bug reassigned from package 'libc6-dev' to 'cpp-9'.
No longer marked as found in versions glibc/2.30-2.
Ignoring request to alter fixed versions of bug #953815 to the same values
previously set
> forcemerge 953806 -1
Bug #953806 {Done: Sven Joachim } [cpp-9] cpp-9: no include
path in which to search for limits.h
Bug #953815 [cpp-9] libc6-dev: Cannot build GNU Emacs - limits.h error in
configure
Severity set to 'grave' from 'normal'
Marked Bug as done
Marked as fixed in versions gcc-9/9.3.0-3.
Marked as found in versions gcc-9/9.3.0-1.
Merged 953806 953815
--
953806: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953806
953815: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953815
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#953815: libc6-dev: Cannot build GNU Emacs - limits.h error in configure
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 the limits.h include.
Here is a minimal reproduction:
$ cat test.c
#include
#include
int main(void) {
exit(0);
}
$ gcc -Wall test.c
In file included from test.c:2:
/usr/include/limits.h:124:26: error: no include path in which to search for
limits.h
124 | # include_next
| ^
$
On Debian stable the example program compiles without problem.
For completeness, here are the errors from the config.log produced by GNU Emacs'
configure:
configure:6307: checking how to run the C preprocessor
configure:6338: gcc -E conftest.c
In file included from conftest.c:11:
/usr/include/limits.h:124:26: error: no include path in which to search for
limits.h
124 | # include_next
| ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h. */
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|Syntax error
configure:6338: gcc -E conftest.c
In file included from conftest.c:11:
/usr/include/limits.h:124:26: error: no include path in which to search for
limits.h
124 | # include_next
| ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h. */
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|Syntax error
configure:6338: gcc -E -traditional-cpp conftest.c
In file included from /usr/include/features.h:447,
from /usr/include/assert.h:36,
from conftest.c:14:
/usr/include/x86_64-linux-gnu/sys/cdefs.h:30:3: error: #error "You need a ISO C
conforming compiler to use the glibc headers"
30 | # error "You need a ISO C conforming compiler to use the glibc headers"
| ^
configure:6338: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Emacs"
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.0.50"
| #define PACKAGE_STRING "GNU Emacs 28.0.50"
| #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org"
| #define PACKAGE_URL "https://www.gnu.org/software/emacs/;
| #define HAVE_PDUMPER 1
| /* end confdefs.h. */
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|Syntax error
[...]
configure:6427: error: in `/usr/src/emacs':
configure:6429: error: C preprocessor "/lib/cpp" fails sanity check
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc6-dev depends on:
ii libc-dev-bin2.30-2
ii libc6 2.30-2
ii libcrypt-dev1:4.4.15-1
ii linux-libc-dev 5.4.19-1
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc
ii manpages-dev 5.05-1
-- no debconf information
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On 2020-03-13 11:36, Daniel Kahn Gillmor wrote: > On Thu 2020-03-12 23:21:29 +0100, Aurelien Jarno wrote: > > That would clearly work for your use case. Now I am not sure it won't > > break other things. > > I'd like to know what it would break if it would break anything. Anything that take a decision based on the name. So far I don't have any concrete example, and if I can't find any in a few weeks, I might just give a try. But right now we are in the middle of a transition, that's not the moment to break more things. > > I asked on IRC and so far only get the confirmation that the package > > shall not be renamed to libc6-dbgsym. > > Thanks for the reportback. Is there some policy about what kinds of > package may be named *-dbgsym generally that renaming libc6-dbg would > violate? comparing the file lists and (lack of) maintscripts between > libc6-dbg and (as a random example) libglib2.0-0-dbgsym, they don't look > that different (libglib2.0-0-dbgsym ships a file in /usr/lib/debug/.dwz > while libc6-dbg does not, but i don't know that this is an important > difference). The reason is that all *-dbgsym packages need to go the debug archive, not the main archive. We can't rename libc6-dbg into libc6-dbgsym and move it to the debug archive as packages from the main archive currently can't depend or build-depend on packages from the debug archive. This is not something that can be fixed easily by just the glibc team. It would require at least the following changes: - d-i should be updated so that new installations add the debug archive by default. A solution have to be found for the upgrades. - wanna-build and the buildds should be configured to also use that debug archive. - a debug security archive has to be created. Plus I guess changing some policy and/or documentation and policy to explicitly allow a package from the main archive to depend on the debug archive. > Or is the reason that a rename would require updating the dependencies > of other existing packages? For runtime deps, there aren't many: > > 0 dkg@alice:~$ apt rdepends libc6-dbg > libc6-dbg > Reverse Depends: > Suggests: testdisk-dbg > Suggests: libxapian30-dbg > Depends: valgrind > Suggests: testdisk-dbg > Recommends: libntdb1-dbg > |Recommends: libgcj17-dbg > Suggests: ekiga-dbg > Depends: valgrind > Suggests: testdisk-dbg > Depends: valgrind > 0 dkg@alice:~$ > > I'm not sure the quickest way to get a list of build-deps, sorry! It > does seem like a transitional package would be the standard way to solve > this problem, and not a huge pain to do. We've handled much worse > transitions. Again we are talking about different archives. It's not a question of updating the reverse dependencies. > Or is it because it's always been this way, and there's documentation > out there that might get out of date? The documentation would survive > with a transitional package for one release of debian anyway, and at > some point we need to prioritize consistency for new users over > stability of unmaintained documentation. if someone is reading a > 4-year-old unmaintained tutorial on debugging in debian they're probably > not getting the most helpful information anyway. > > Or is there some other reason? No it's not a question of documentation. > I'm sorry to press on this, but "IRC says we shall not do this" sounds a > lot like what people accuse debian of in its worst moments -- reflexive > resistance to change, even when there's a well-motivated reason and a > transition plan available for a concrete improvement, even a minor one > like this. I'm really in the dark here. If there are other reasons, > i'd like to know them. It has not been said about a random person, but by one of the FTP masters. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Thu 2020-03-12 23:21:29 +0100, Aurelien Jarno wrote: > That would clearly work for your use case. Now I am not sure it won't > break other things. I'd like to know what it would break if it would break anything. > I asked on IRC and so far only get the confirmation that the package > shall not be renamed to libc6-dbgsym. Thanks for the reportback. Is there some policy about what kinds of package may be named *-dbgsym generally that renaming libc6-dbg would violate? comparing the file lists and (lack of) maintscripts between libc6-dbg and (as a random example) libglib2.0-0-dbgsym, they don't look that different (libglib2.0-0-dbgsym ships a file in /usr/lib/debug/.dwz while libc6-dbg does not, but i don't know that this is an important difference). Or is the reason that a rename would require updating the dependencies of other existing packages? For runtime deps, there aren't many: 0 dkg@alice:~$ apt rdepends libc6-dbg libc6-dbg Reverse Depends: Suggests: testdisk-dbg Suggests: libxapian30-dbg Depends: valgrind Suggests: testdisk-dbg Recommends: libntdb1-dbg |Recommends: libgcj17-dbg Suggests: ekiga-dbg Depends: valgrind Suggests: testdisk-dbg Depends: valgrind 0 dkg@alice:~$ I'm not sure the quickest way to get a list of build-deps, sorry! It does seem like a transitional package would be the standard way to solve this problem, and not a huge pain to do. We've handled much worse transitions. Or is it because it's always been this way, and there's documentation out there that might get out of date? The documentation would survive with a transitional package for one release of debian anyway, and at some point we need to prioritize consistency for new users over stability of unmaintained documentation. if someone is reading a 4-year-old unmaintained tutorial on debugging in debian they're probably not getting the most helpful information anyway. Or is there some other reason? I'm sorry to press on this, but "IRC says we shall not do this" sounds a lot like what people accuse debian of in its worst moments -- reflexive resistance to change, even when there's a well-motivated reason and a transition plan available for a concrete improvement, even a minor one like this. I'm really in the dark here. If there are other reasons, i'd like to know them. Thanks for all your work in maintaining such a critical part of debian! Regards, --dkg signature.asc Description: PGP signature
Processed: tagging 953788
Processing commands for cont...@bugs.debian.org: > tags 953788 + fixed-upstream Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Added tag(s) fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 953788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953788 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user
Processing control commands: > found -1 2.16-0experimental0 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user The source 'glibc' and version '2.16-0experimental0' do not appear to match any binary packages Marked as found in versions glibc/2.16-0experimental0. > found -1 2.19-18+deb8u10 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Marked as found in versions glibc/2.19-18+deb8u10. > found -1 2.24-11+deb9u1 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Marked as found in versions glibc/2.24-11+deb9u1. > found -1 2.24-11+deb9u4 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Marked as found in versions glibc/2.24-11+deb9u4. > found -1 2.28-10 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Marked as found in versions glibc/2.28-10. > found -1 2.29-10 Bug #953788 [src:glibc] glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user Marked as found in versions glibc/2.29-10. -- 953788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953788 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#953788: glibc: CVE-2020-1752: use-after-free in glob() function when expanding ~user
Source: glibc Version: 2.30-2 Severity: important Tags: security upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=25414 Control: found -1 2.16-0experimental0 Control: found -1 2.19-18+deb8u10 Control: found -1 2.24-11+deb9u1 Control: found -1 2.24-11+deb9u4 Control: found -1 2.28-10 Control: found -1 2.29-10 Hi, The following vulnerability was published for glibc. CVE-2020-1752[0]: use-after-free in glob() function when expanding ~user If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-1752 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1752 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25414 Regards, Salvatore
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 > | ^ > > wondering if other distros patch glibc for that ... Other distributions install limits.h from GCC (in a directory under /usr/lib/gcc), and that header is picked up first, before /usr/include/limits.h.
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 3/4/20 9:48 AM, Florian Weimer wrote: > * 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 anymore. The macro is still referenced in the include-fixed directory. Seen with the 2.31 branch, but I see that this is also backported to 2.30. >>> >>> This is a bug in the gcc package. It must not run fixincludes, to >>> avoid producing mutually incompatible headers because only a subset of >>> them is rewritten. >> >> Is this something which should be done upstream? Or just don't include any >> fixed header in the GCC packages? > > Distributions should never run fixincludes for this reason. This is a > hack for installing compilers as non-root on proprietary systems, > where you can't fix the headers. > > Other distributions routinely backport compiler compatibility fixes > into glibc (even into stable releases), and I think this is the way it > has to be done. > >> Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler. > > If I recall correctly, the header is broken anyway because linux is > rewritten into __linux__, due to a fixincludes bug. > > It should be possible to hide the header by having a file with an > #include directive with an absolute path in a directory used during > the build. 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 | ^ wondering if other distros patch glibc for that ...
