Your message dated Fri, 2 May 2025 09:34:51 +0200 with message-id <[email protected]> and subject line Re: Bug#863914: closing 863914 has caused the Debian Bug report #863914, regarding linux-libc-dev: Install separate from /usr/include to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 863914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863914 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: linux-libc-dev Version: 4.11-1~exp2 Severity: wishlist Certain low-level programs and libraries, notably glibc, would like to be able to make sure that they do *not* use any system headers during their build, other than the kernel's headers and the ones provided by the compiler (stddef.h, stdarg.h etc) It would be much easier to arrange this if the kernel's headers were installed in a location separate from /usr/include and then symlinked into /usr/include. (It would be fine to symlink just the directories.) -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
--- End Message ---
--- Begin Message ---On Fri, Apr 25, 2025 at 10:14:44PM +0200, Salvatore Bonaccorso wrote: > In this case you might want to contribute a solution in form of a > proposed merge request to the packaging? That would be welcome so that > for instance Ben might review what you are proposing. Actually I woukld expect such a request come from an active maintainer of affected toolhain packages. What is asked here would implement a long time API we have to fulfill in addition to the current one. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
--- End Message ---
