Bug#1068198: debian-installer-netboot-images: accesses the internet during build
Source: debian-installer-netboot-images Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer-netboot-images attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Bug#1068197: debian-installer: accesses the internet during build
Source: debian-installer Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Re: Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi Cyril, On 2024-02-25 13:45, Jonathan Wiltshire wrote: > Control: tag -1 d-i > > Hi, > > On Sat, Feb 24, 2024 at 04:59:10PM +0100, Aurelien Jarno wrote: > > [ Reason ] > > The upstream stable branch got a few fixes in the last months, and this > > update pulls them into the debian package. > > > > [ Impact ] > > In case the update isn't approved, systems will be left with a few > > issues, and the differences with upstream will increase, which might > > make next fixes more difficult to review. > > I'm happy with it from SRM point of view, but as you say d-i ack needed. The date of the next point release is slowly approaching, could you please have a look at this? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi Cyril, On 2024-02-25 13:45, Jonathan Wiltshire wrote: > Control: tag -1 d-i > > Hi, > > On Sat, Feb 24, 2024 at 04:59:10PM +0100, Aurelien Jarno wrote: > > [ Reason ] > > The upstream stable branch got a few fixes in the last months, and this > > update pulls them into the debian package. > > > > [ Impact ] > > In case the update isn't approved, systems will be left with a few > > issues, and the differences with upstream will increase, which might > > make next fixes more difficult to review. > > I'm happy with it from SRM point of view, but as you say d-i ack needed. The date of the next point release is slowly approaching, could you please have a look at this? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: gl...@packages.debian.org, debian-boot@lists.debian.org Control: affects -1 + src:glibc [ Reason ] The upstream stable branch got a few fixes in the last months, and this update pulls them into the debian package. [ Impact ] In case the update isn't approved, systems will be left with a few issues, and the differences with upstream will increase, which might make next fixes more difficult to review. [ Tests ] The upstream fixes come with additional tests, which represent a significant part of the diff. [ Risks ] The changes to do not affect critical part of the library, and come with additional tests. The upstream changes have been in testing/sid for about 3 weeks. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Please find below the changelog with additional explanations: * debian/patches/git-updates.diff: update from upstream stable branch: - any/local-CVE-2023-4911.patch: upstreamed. - any/local-CVE-2023-6246.patch: upstreamed. - any/local-CVE-2023-6779.patch: upstreamed. - any/local-CVE-2023-6780.patch: upstreamed. => Those patches went upstream, with some additional tests. - Revert fix to always call destructors in reverse constructor order due to unforeseen application compatibility issues. => This fix introduced some regression, even if none have been reported to Debian, so they have been reverted to come back to the previous situation. - Fix a DTV corruption due to a reuse of a TLS module ID following dlclose with unused TLS. => This issue affect the Mesa crocus driver that is shipped in bookworm, even if we haven't got any report on the Debian side. The fix is a very simple one liner. More details can be found on the upstream BTS: https://sourceware.org/bugzilla/show_bug.cgi?id=29039 - Fix the DTV field load on x32. => The testcase added for the above issue, uncovered an issue on x32. For stable architectures, this only affects the libc6-x32 package. More details can be found on the upstream BTS: https://sourceware.org/bugzilla/show_bug.cgi?id=31184 - Fix the TCB field load on x32. => Debugging the above x32 issue, uncovered a similar bug. For stable architectures, this only affects the libc6-x32 package. More details can be found on the upstream BTS: https://sourceware.org/bugzilla/show_bug.cgi?id=31185 [ Other info ] debian-boot is in Cc: as glibc has one udeb. diff --git a/debian/changelog b/debian/changelog index 8e1ee881..b708d99d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,19 @@ +glibc (2.36-9+deb12u5) bookworm; urgency=medium + + * debian/patches/git-updates.diff: update from upstream stable branch: +- any/local-CVE-2023-4911.patch: upstreamed. +- any/local-CVE-2023-6246.patch: upstreamed. +- any/local-CVE-2023-6779.patch: upstreamed. +- any/local-CVE-2023-6780.patch: upstreamed. +- Revert fix to always call destructors in reverse constructor order due + to unforeseen application compatibility issues. +- Fix a DTV corruption due to a reuse of a TLS module ID following dlclose + with unused TLS. +- Fix the DTV field load on x32. +- Fix the TCB field load on x32. + + -- Aurelien Jarno Sat, 24 Feb 2024 16:49:22 +0100 + glibc (2.36-9+deb12u4) bookworm-security; urgency=medium * debian/patches/any/local-CVE-2023-6246.patch: Fix a heap buffer overflow diff --git a/debian/patches/any/local-CVE-2023-4911.patch b/debian/patches/any/local-CVE-2023-4911.patch deleted file mode 100644 index 4c4c2094.. --- a/debian/patches/any/local-CVE-2023-4911.patch +++ /dev/null @@ -1,60 +0,0 @@ -From d2b77337f734fcacdfc8e0ddec14cf31a746c7be Mon Sep 17 00:00:00 2001 -From: Siddhesh Poyarekar -Date: Mon, 11 Sep 2023 18:53:15 -0400 -Subject: [PATCH v2] tunables: Terminate immediately if end of input is reached - -The string parsing routine may end up writing beyond bounds of tunestr -if the input tunable string is malformed, of the form name=name=val. -This gets processed twice, first as name=name=val and next as name=val, -resulting in tunestr being name=name=val:name=val, thus overflowing -tunestr. - -Terminate the parsing loop at the first instance itself so that tunestr -does not overflow. -Changes from v1: - -- Also null-terminate tunestr before exiting. - - elf/dl-tunables.c | 17 ++--- - 1 file changed, 10 insertions(+), 7 deletions(-) - -diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c -index 8e7ee9df10..76cf8b9da3 100644 a/elf/dl-tunables.c -+++ b/elf/dl-tunables.c -@@ -187,11 +187,7 @@ parse_tunables (char *tunestr, char *valstring) - /* If we reach the end of the string before getting a valid name-valu
Re: Bug#1053130: bookworm-pu: package glibc/2.36-9+deb12u2
On 2023-09-28 20:58, Adam D. Barratt wrote: > Control: tags -1 confirmed > > On Wed, 2023-09-27 at 23:47 +0200, Aurelien Jarno wrote: > > The upstream glibc stable branch got a few fixes since the latest > > point > > released, including two security fixes. > > > > Please go ahead. > Thanks for the fast review, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1053130: bookworm-pu: package glibc/2.36-9+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: gl...@packages.debian.org, debian-gl...@lists.debian.org, debian-boot@lists.debian.org Control: affects -1 + src:glibc [ Reason ] The upstream glibc stable branch got a few fixes since the latest point released, including two security fixes. [ Impact ] Installations will be left vulnerable to security issues. [ Tests ] The upstream fixes come with additional tests, which represent a significant part of the diff. [ Risks ] The risk can be considered low, as all the changes except the one for CVE-2023-5156 have been tested in testing/sid for a few days. The one for CVE-2023-5156 has just been uploaded to sid, but comes with a test. In addition those fixes have been committed on a few upstream branches and have been used by other distributions to provide security updates. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] All the changes come from the upstream stable branch, and are summarized in the debian changelog. Let me comment it: - Fix the value of F_GETLK/F_SETLK/F_SETLKW with __USE_FILE_OFFSET64 on ppc64el. Closes: #1050592. This fixes a regression introduced in the previous point release and testing/sid. On ppc64el, the values of F_GETLK/F_SETLK/F_SETLKW changed when __USE_FILE_OFFSET64 is in use. While this is handled transparently at the glibc level, it breaks some packages which use the values internally like perl. - Fix a stack read overflow in getaddrinfo in no- mode (CVE-2023-4527). Closes: #1051958. This fixes a security issue in a new feature introduced in glibc 2.36, which has not been considered serious enough by the security team to issue a DSA. - Fix use after free in getcanonname (CVE-2023-4806, CVE-2023-5156). This fixes a security issue that might happen with some NSS modules which implement some hooks but not some others, however there are no known modules implemented that way. Unfortunately the initial fix introduced a memory leak which got assigned CVE-2023-5156. - Update the x86 cacheinfo code to look at the per-thread L3 cache to determine the non-temporal threshold. This improves memory and string functions on modern CPUs. This changes the way the cache sizes are interpreted, properly taking into account the L3 cache on modern CPUs. The memory and string functions are unchanged, only some threshold are changed. - Fix _dl_find_object to return correct values even during early startup. It has been found that _dl_find_object is can wrongly return 1 during early startup. Currently no impact has been found, but as this functions is used by some external unwiders (for instance GCC), it's better to fix it to be future proof. - Always call destructors in reverse constructor order. This fixes a regression introduced in glibc 2.36, which causes destructors to be called in a different order than the constructors when there are cyclic dependencies. This causes issues with some applications. [ Other info ] debian-boot is in Cc: as glibc has one udeb. diff --git a/debian/changelog b/debian/changelog index aafd6e3a..146c85d3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,19 @@ +glibc (2.36-9+deb12u2) UNRELEASED; urgency=medium + + * debian/patches/git-updates.diff: update from upstream stable branch: +- Fix the value of F_GETLK/F_SETLK/F_SETLKW with __USE_FILE_OFFSET64 on + ppc64el. Closes: #1050592. +- Fix a stack read overflow in getaddrinfo in no- mode + (CVE-2023-4527). Closes: #1051958. +- Fix use after free in getcanonname (CVE-2023-4806, CVE-2023-5156). +- Update the x86 cacheinfo code to look at the per-thread L3 cache to + determine the non-temporal threshold. This improves memory and string + functions on modern CPUs. +- Fix _dl_find_object to return correct values even during early startup. +- Always call destructors in reverse constructor order. + + -- Aurelien Jarno Sat, 23 Sep 2023 15:08:08 +0200 + glibc (2.36-9+deb12u1) bookworm; urgency=medium [ Aurelien Jarno ] diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff index 9203223b..cdb02b1d 100644 --- a/debian/patches/git-updates.diff +++ b/debian/patches/git-updates.diff @@ -68,10 +68,10 @@ index d1e139d03c..09c0cf8357 100644 else # -s verbose := diff --git a/NEWS b/NEWS -index f61e521fc8..9f6b48b63d 100644 +index f61e521fc8..ae55ffb53a 100644 --- a/NEWS +++ b/NEWS -@@ -5,6 +5,65 @@ See the end for copying conditions. +@@ -5,6 +5,85 @@ See the end for copying conditions. Please send GNU C library bug reports via <https://sourceware.org/bugzilla/> using `glibc' in the "product" field. @@ -91,6
Re: Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1
Hi Adam, On 2023-07-13 17:01, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote: > > The upstream stable branch got a few fixes during the bookworm freeze > > period, and this update pulls them into the debian package. In short: > > - Fix a buffer overflow and memory corruption in the gmon > >functionality. > > - Fix a deadlock in getaddrinfo() and system() functions > > - Fix y2038 support in strftime on 32-bit architectures. > > - Fix possible segmentation fault in applications using sgetsgent() > >when /etc/gshadow contains very long lines > > - Fix support for old C90 compilers. > > > > In addition this include a Slovak translation update fixing typos, > > that > > > > Please go ahead, bearing in mind that the window for 12.1 closes over > the coming weekend. Thanks for the review, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1
ncern bookworm release architectures, and there is no stable for debian-ports architectures. However it doesn't make sense to exclude the corresponding changes, and backport fixes one by one instead of using the upstream branch. - No change in the generated code: - Fix asm constraints in amd64 version of feraiseexcept (bug not visible with GCC 12). => This is a two lines fix patch to fix an issue with GCC 13, but it doesn't affect glibc build with GCC 12. * debian/po/sk.po: Fix typos in the Slovak translation. => The above change fixes some typos introduced in the Slovak translation. It's not a full rewrite of the translation nor a new translation. [ Other info ] debian-boot is in Cc: as glibc has one udeb. diff --git a/debian/changelog b/debian/changelog index d67a3e5d..d40a0111 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,35 @@ +glibc (2.36-9+deb12u1) bookworm; urgency=medium + + [ Aurelien Jarno ] + * debian/patches/git-updates.diff: update from upstream stable branch: +- Affecting bookworm release architectures: + - Improve mcount overflow handling in gmon. + - Fix a buffer overflow in gmon (CVE-2023-0687). + - Fix a memory corruption when incorrectly calling gmon functions +repeatedly on in wrong order. + - Fix a deadlock in getaddrinfo (__check_pf) with deferred cancellation. + - Fix y2038 support in strftime on 32-bit architectures. + - Fix corner case parsing of /etc/gshadow which can return bad pointers +causing segfaults in applications. + - Fix a deadlock in system() when called concurrently from multiple +threads. + - cdefs: limit definition of fortification macros to __FORTIFY_LEVEL > 0 +to support old C90 compilers. +- Not affecting bookworm release architectures: + - Fix LFS POSIX lock constants for powerpc64. + - Fix GL(dl_phdr) and GL(dl_phnum) for static builds. Closes: #1028200. +- Not affecting debian architectures: + - Fix LFS POSIX lock constants on 32 bit arch with 64 bit default +time_t. +- No change in the generated code: + - Fix asm constraints in amd64 version of feraiseexcept (bug not visible +with GCC 12). + + [ Andrej Shadura ] + * debian/po/sk.po: Fix typos in the Slovak translation. + + -- Aurelien Jarno Thu, 22 Jun 2023 19:33:59 +0200 + glibc (2.36-9) unstable; urgency=medium [ Aurelien Jarno ] diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff index 0d3d0800..9203223b 100644 --- a/debian/patches/git-updates.diff +++ b/debian/patches/git-updates.diff @@ -68,10 +68,10 @@ index d1e139d03c..09c0cf8357 100644 else # -s verbose := diff --git a/NEWS b/NEWS -index f61e521fc8..8c79e83b77 100644 +index f61e521fc8..9f6b48b63d 100644 --- a/NEWS +++ b/NEWS -@@ -5,6 +5,54 @@ See the end for copying conditions. +@@ -5,6 +5,65 @@ See the end for copying conditions. Please send GNU C library bug reports via <https://sourceware.org/bugzilla/> using `glibc' in the "product" field. @@ -94,8 +94,13 @@ index f61e521fc8..8c79e83b77 100644 +The following bugs are resolved with this release: + + [12154] Do not fail DNS resolution for CNAMEs which are not host names ++ [20975] Deferred cancellation triggers in __check_pf and looses lock leading to deadlock + [24816] Fix tst-nss-files-hosts-long on single-stack hosts ++ [27576] gmon: improve mcount overflow handling + [28846] CMSG_NXTHDR may trigger -Wstrict-overflow warning ++ [29444] gmon: Fix allocated buffer overflow (bug 29444) ++ [29864] libc: __libc_start_main() should obtain program headers ++address (_dl_phdr) from the auxv, not the ELF header. + [29305] Conserve NSS buffer space during DNS packet parsing + [29402] nscd: nscd: No such file or directory + [29415] nscd: Fix netlink cache invalidation if epoll is used @@ -122,6 +127,12 @@ index f61e521fc8..8c79e83b77 100644 + [29771] Restore IPC_64 support in sysvipc *ctl functions + [29776] elf/tst-tlsopt-powerpc fails when compiled with -mcpu=power10 + [29951] time: Set daylight to 1 for matching DST/offset change ++ [30053] time: strftime %s returns -1 after 2038 on 32 bits systems ++ [30101] gmon: fix memory corruption issues ++ [30151] gshadow: Matching sgetsgent, sgetsgent_r ERANGE handling ++ [30163] posix: Fix system blocks SIGCHLD erroneously ++ [30305] x86_64: Fix asm constraints in feraiseexcept ++ [30477] libc: [RISCV]: time64 does not work on riscv32 + Version 2.36 @@ -189,6 +200,75 @@ index 2b99dea33b..aac8c49b00 100644 return __cmsg; } #endif/* Use `extern inline'. */ +diff --git a/csu/libc-start.c b/csu/libc-start.c +index 543560f36c..bfeee6d851 100644 +--- a/csu/libc-start.c b/csu/libc-start.c +@@ -262,28 +262,7 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), + } + # endif + _dl_aux_init
Re: Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6
On 2023-04-19 21:16, Adam D. Barratt wrote: > Control: tags -1 + confirmed d-i > > On Tue, 2023-04-18 at 00:06 +0200, Aurelien Jarno wrote: > > There are multiple fixes in this upload, all coming from the upstream > > stable branch: > > - Multiple crashes or memory leak in printf-family functions > > - Overflow fix in the AVX2 implementation of wcsnlen > > > > Please go ahead. Thanks, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gl...@packages.debian.org, debian-boot@lists.debian.org,
debian-gl...@lists.debian.org
Control: affects -1 + src:glibc
[ Reason ]
There are multiple fixes in this upload, all coming from the upstream
stable branch:
- Multiple crashes or memory leak in printf-family functions
- Overflow fix in the AVX2 implementation of wcsnlen
[ Impact ]
In case the update isn't approved, systems will be left with issues
which combined with other vulnerabilities might lead to denial of
service.
[ Tests ]
The upstream fixes come with additional tests, which represent a
significant part of the diff.
[ Risks ]
The most risky parts are probably the printf-family functions changes,
however those changes are in testing/sid for ~1.5 years (since glibc
2.32), but have only been identified as problematic recently. The
wcsnlen fix is in testing/sid for ~4 months. All of those changes come
with additional tests.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Let me comment the changelog:
- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
(obsolete).
The upstream stable branch for glibc 2.31 now includes the fix
introduced in glibc 2.31-13+deb11u5 to fix some crash on some CPU.
Therefore this patch is not needed anymore.
- Fix memory leak in printf-family functions with long multibyte strings.
This fixes a memory leak that might lead to OOM when calling with
long multibyte strings. The simplest reproducer is:
printf("%.1371337ls", L"A\n");
- Fix a crash in printf-family due to width/precision-dependent
allocations.
This fixes a crash due to a missing overflow check in the requested
precision. The simplest reproducer is:
fprintf (fp, "%2$.*1$a", 0x7fff, 1e200);
- Fix a segfault in printf handling thousands separator.
This segmentation fault has been fixed as a side effect of the
previous fix, but comes with a specific test. The simplest reproducer
is:
setlocale(LC_ALL, "en_US.UTF-8");
printf("%'1000d\n", 1000);
- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
pages.
The overflow happens when wcsnlen is called with a huge maxlen
argument (e.g. (1UL << 63)), triggering an assertion in the wcsnlen
code.
diff --git a/debian/changelog b/debian/changelog
index 50f6135b..3d95edf8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+glibc (2.31-13+deb11u6) UNRELEASED; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debian/patches/git-updates.diff: update from upstream stable branch:
+- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+ (obsolete).
+- Fix memory leak in printf-family functions with long multibyte strings.
+- Fix a crash in printf-family due to width/precision-dependent
+ allocations.
+- Fix a segfault in printf handling thousands separator.
+- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
+ pages.
+
+ -- Aurelien Jarno Sun, 16 Apr 2023 18:58:33 +0200
+
glibc (2.31-13+deb11u5) bullseye; urgency=medium
* debian/patches/local-require-bmi-in-avx2-ifunc.diff: new patch extracted
diff --git a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
deleted file mode 100644
index 936f89ae..
--- a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-This patch is extracted from upstream commit 83c5b368226c ("x86-64: Require
-BMI2 for strchr-avx2.S"). It changes the common ifunc AVX2 selector to require
-the BMI2 instructions, and the backported fixes for memchr and strlen rely on
-that change.
-
a/sysdeps/x86_64/multiarch/ifunc-avx2.h
-+++ b/sysdeps/x86_64/multiarch/ifunc-avx2.h
-@@ -21,28 +21,28 @@ IFUNC_SELECTOR (void)
-
- extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
-
- static inline void *
- IFUNC_SELECTOR (void)
- {
- const struct cpu_features* cpu_features = __get_cpu_features ();
-
- if (CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
-+ && CPU_FEATURES_CPU_P (cpu_features, BMI2)
- && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
- {
- if (CPU_FEATURES_ARCH_P (cpu_features, AVX512VL_Usable)
--&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable)
--&& CPU_FEATURES_CPU_P (cpu_features, BMI2
Re: Bug#1020969: buildd.debian.org: Dell XPS 15 9520 - Boot hangs
control: reassign -1 installation-reports Hi, On 2022-09-29 20:58, Waido wrote: > Package: buildd.debian.org > Severity: important > X-Debbugs-Cc: waidoshor...@protonmail.com > > Dear Maintainer, > > I'm trying to install Debian 11.5 (Bullseye) on a notebook Dell XPS 15 9520. > The installation finished successfully but from the first boot of the > notebook on the screen appears the message > > dell_smm_hwmon: unable to get SMM Dell signature > > and the notebook hangs. I can't get to the shell prompt. > From a live distro, inside installed distro, I created the file > /etc/modprobe.d/blacklist.conf with the content > > blacklist dell-smm-hwmon > > Now the notebook boots ... and hangs without showing the previous message, > without showing any error or interesting message. The buildd.debian.org pseudo package is for bugs concerning the build daemons infrastructure, which is responsible for building packages from source for all architectures. It has nothing to do with the installer. I am therefore reassigning this to the installation-reports package, for you to get more chances to find people helping you. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3
On 2022-03-17 17:49, Adam D. Barratt wrote: > On Tue, 2022-03-15 at 20:33 +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed d-i > > > > On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote: > > > There are multiple fixes in this upload: > > > - 4 security bugs > > > - a fix to avoid preinst script failure when running on kernel > > > x.y.z > > > with z > 255. > > > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on > > > upgrade > > > > > > [ Impact ] > > > Installation will be left vulnerable to security issues and upgrade > > > from buster will fail when running recent upstream stable kernels. > > > > > > > This looks OK to me, thanks. > > > > As glibc produces a udeb, this will want a KiBi-ack; CCing and > > tagging > > accordingly. > > As we're getting very close to the window for 11.3 closing, please feel > free to upload. Thanks, I have just uploaded it. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1
On 2022-03-17 17:51, Adam D. Barratt wrote: > Control: tags -1 + confirmed d-i > > On Wed, 2022-03-16 at 00:50 +0100, Aurelien Jarno wrote: > > A big part of the changes have been in the buster git branch for many > > months, but I failed to submit the package for a point release up to > > now. What triggered me to look at it again is breakage in the preinst > > script when running on kernel x.y.z with z > 255. > > > > In other changes are just an (old) pull from the stable branch, > > fixing > > a few important bugs. > > Please go ahead, thanks. > > As glibc produces a udeb, I'm tagging the bug and CCing accordingly. > Thanks for the review despite the close deadline. I have just uploaded it. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 2021-09-30 22:16, Adam D. Barratt wrote: > On Mon, 2021-09-27 at 12:38 +0100, Adam D. Barratt wrote: > > Control: tags -1 + confirmed d-i > > > > To confirm some IRC conversations - given the closeness of the freeze > for 11.1, please feel free to upload and kibi can review the package > from stable-new. > Unfortunately Cyril has found an issue while testing, the query to debconf doesn't work when the libc6.preinst script is re-executed by the debconf frontend: | ... | Preparing to unpack .../libc6_2.31-13+deb11u1_amd64.deb ... | debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable | Unpacking libc6:amd64 (2.31-13+deb11u1) over (2.31-13+deb11u1) . | ... This message is harmless in most cases, but can cause a switch to text mode while debconf is able to fallback to another frontend. It is also very worrying for users. As discussed on IRC, I have uploaded glibc 2.31-13+deb11u2 that fixes that issue by not trying to detect if debconf is available when the debconf frontend has already been loaded. You will find the corresponding debdiff attached. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net diff --git a/debian/changelog b/debian/changelog index dd5370af..7c23c790 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +glibc (2.31-13+deb11u2) bullseye; urgency=medium + + [ Aurelien Jarno ] + * debian/debhelper.in/libc.preinst: do not try to detect if debconf is +available when the debconf frontend has already been loaded. + + -- Aurelien Jarno Sat, 02 Oct 2021 14:47:40 +0200 + glibc (2.31-13+deb11u1) bullseye; urgency=medium [ Aurelien Jarno ] diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst index f0285832..ff59ad9a 100644 --- a/debian/debhelper.in/libc.preinst +++ b/debian/debhelper.in/libc.preinst @@ -23,7 +23,11 @@ if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ] then # Check if the debconf module is available and usable USE_DEBCONF= -if [ -f /usr/share/debconf/confmodule ]; then +if [ "$DEBIAN_HAS_FRONTEND" ]; then +# Debconf is already loaded, so we already checked if the frontend +# is usable or not +USE_DEBCONF=1 +elif [ -f /usr/share/debconf/confmodule ]; then # cdebconf has a working fallback mechanism in case dialog # is not usable, so do not try to do anything smart here if [ "$DEBCONF_USE_CDEBCONF" ] ; then signature.asc Description: PGP signature
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 2021-09-27 12:38, Adam D. Barratt wrote: > Control: tags -1 + confirmed d-i > Control: fixed 994042 2.32-3 > > Hi, > > On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote: > > Hi, > > > > On 2021-09-26 20:46, Adam D. Barratt wrote: > > > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote: > > > [...] > > > > In the meantime another issue that would need to be fixed in sid > > > > > > came > > > > as > > > > bug#994042. > > > > > > > > This time the issue is in the preinst. To summarize, in the case > > > > debconf is not usable to prompt the user about the upgrade, the > > > > preinst switches to text prompt. However as the debconf module > > > > has > > > > been loaded got control of the tty, which prevent any input from > > > > the > > > > user. For skilled users it still possible to kill the upgrade > > > > from > > > > another, but other users will probably try other actions that > > > > might > > > > have damaging effects (like rebooting the system). > > > > > > > > The fix is to get the debconf configuration without using the > > > > debconf > > > > module, as suggested by Colin Watson. > > > > > > > > > > Thanks. That looks OK to me, particularly with Colin's review. > > > > Thanks for the review. I guess that now it just needs a kibi-ack. > > Yep; re-tagging accordingly. I have just uploaded this package to bullseye. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 2021-09-26 20:46, Adam D. Barratt wrote: > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote: > [...] > > In the meantime another issue that would need to be fixed in sid > > > > came > > as > > bug#994042. > > > > This time the issue is in the preinst. To summarize, in the case > > debconf is not usable to prompt the user about the upgrade, the > > preinst switches to text prompt. However as the debconf module has > > been loaded got control of the tty, which prevent any input from the > > user. For skilled users it still possible to kill the upgrade from > > another, but other users will probably try other actions that might > > have damaging effects (like rebooting the system). > > > > The fix is to get the debconf configuration without using the debconf > > module, as suggested by Colin Watson. > > > > Thanks. That looks OK to me, particularly with Colin's review. Thanks for the review. I guess that now it just needs a kibi-ack. > Is there an ETA for getting the fix into unstable? Upgrades from buster to bookworm are not supported, so it means upgrade to bookworm starts from bullseye, which has a fixed debconf (the issue has been fixed in version 1.5.76). Therefore the fix in unstable has been done in glibc 2.32-3 by just dropping all the workaround: https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789 Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
control: tag -1 - confirmed
On 2021-09-04 15:08, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Sun, 2021-08-22 at 14:58 +0200, Aurelien Jarno wrote:
> > During the upgrade from Buster to Bullseye, the SSH server is not
> > restarted following the libc6 upgrade, causing new SSH connections to
> > get rejected until the SSH server is restarted later in the upgrade.
> >
> > It could be considered as a regression as it didn't happen during the
> > upgrade from Stretch to Buster.
> >
> > [ Impact ]
> > Upgrade might fail or get stuck for remote upgrade using SSH if for
> > some reason the SSH connection breaks. Using screen or tmux doesn't
> > help here as it is not possible to connect again using SSH.
> [...]
> > The change consist in updating the regex getting the list of services
> > in the "installed" state, to also consider openssh-server in
> > 'unpacked' state.
>
> +glibc (2.31-13+deb11u1) unstable; urgency=medium
>
> The distribution there should be "bullseye".
Indeed good catch. dch just reuse the one from the previous entry.
> I realise that the changes don't affect the udeb, but for completeness
> this wants a kibi-ack; CCed and tagging appropriately. Please feel free
> to go ahead on that basis.
In the meantime another issue that would need to be fixed in sid came as
bug#994042.
This time the issue is in the preinst. To summarize, in the case debconf
is not usable to prompt the user about the upgrade, the preinst switches
to text prompt. However as the debconf module has been loaded got
control of the tty, which prevent any input from the user. For skilled
users it still possible to kill the upgrade from another, but other
users will probably try other actions that might have damaging effects
(like rebooting the system).
The fix is to get the debconf configuration without using the debconf
module, as suggested by Colin Watson.
You will find the new debdiff including this fix attached to the mail.
It has been tested by using the reproducer providing by Colin with an
additional repository containing the fixed glibc packages. Two cases
have been tested:
- upgrade + dist-upgrade to reproduce the original issue where the
preinst switches to text prompt and verify that the user input is now
accepted
- dist-upgrade to get a debconf prompt and verify it still works.
Could you please consider this new debdiff for bullseye?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff --git a/debian/changelog b/debian/changelog
index 138f350a..d19a1d75 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+glibc (2.31-13+deb11u1) bullseye; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debian/script.in/nsscheck.sh: restart openssh-server even if it has been
+deconfigured during the upgrade. Closes: #990069.
+ * debian/debhelper.in/libc.preinst: fix text fallback when debconf is
+unusable, the current debconf configuration should be queried without
+first sourcing the confmodule to avoid losing control of the tty. Big
+ thanks to Colin Watson for the help diagnosing the issue and for providing
+an easy reproducer. Closes: #994042.
+
+ -- Aurelien Jarno Sun, 22 Aug 2021 14:38:58 +0200
+
glibc (2.31-13) unstable; urgency=medium
[ Colin Watson ]
diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index d679db4f..f0285832 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -21,23 +21,23 @@ kfreebsd_compare_versions () {
if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
then
-# Load debconf module if available and usable
+# Check if the debconf module is available and usable
+USE_DEBCONF=
if [ -f /usr/share/debconf/confmodule ]; then
# cdebconf has a working fallback mechanism in case dialog
# is not usable, so do not try to do anything smart here
if [ "$DEBCONF_USE_CDEBCONF" ] ; then
-. /usr/share/debconf/confmodule
USE_DEBCONF=1
# debconf requires perl
elif perl -e "" 2>/dev/null ; then
-. /usr/share/debconf/confmodule
# Check that the selected frontend will work
if [ -n "$DEBIAN_FRONTEND" ] ; then
frontend="$DEBIAN_FRONTEND"
else
-db_version 2.0
-db_get debconf/frontend || RET="Dialog"
-frontend="$RET"
+# Query the frontend without first sourcing the confmodule to
avoid
+# losing control of the tty. This snippet must not be copied
blindly.
+frontend="$(echo 'GET debconf/frontend' | debconf-communicate
|
Bug#991372: unblock: glibc/2.31-13
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-boot@lists.debian.org
Please unblock package glibc
[ Reason ]
This new version fixes one serious bug (#990069) in the maintainer
scripts preventing the sshd daemon following a glibc upgrade on systems
where the ssh meta-package is not installed.
It also fixes a security issue in the wordexp() function
(CVE-2021-35942, #990542) by pulling the upstream stable branch.
[ Impact ]
On systems where the ssh meta-package is not installed, following the
upgrade from buster to bullseye, incoming SSH connections are not
accepted until the sshd daemon is restarted manually or the system is
rebooted. This can be an issue for systems upgraded remotely.
[ Tests ]
The change to the maintainer scripts are not covered by automatic tests
(except maybe by piuparts). They have however been manually tested by
multiple persons.
The change to the wordexp() function is covered by the upstream
testsuite. A new test has actually been added to catch the security
issue.
[ Risks ]
The change to the maintainer scripts is relatively simple and just
follow what is already done for other daemons where the package name is
not the same than the daemon name. The package has been in sid for 2
weeks, and no regression have been reported. The risk is therefore very
low.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
d-i team is Cc:ed.
unblock glibc/2.31-13
diff --git a/debian/changelog b/debian/changelog
index 7197d373..138f350a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+glibc (2.31-13) unstable; urgency=medium
+
+ [ Colin Watson ]
+ * debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: Look for
+openssh-server package rather than ssh. Closes: #990069
+
+ [ Aurelien Jarno ]
+ * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix an arbitrary read in wordexp() (CVE-2021-35942). Closes:
+ #990542.
+
+ -- Aurelien Jarno Tue, 06 Jul 2021 21:16:59 +0200
+
glibc (2.31-12) unstable; urgency=medium
* debian/po/de.po: fix encoding declaration. Closes: #986450.
diff --git a/debian/debhelper.in/libc.postinst
b/debian/debhelper.in/libc.postinst
index 0b312dfa..f52a1430 100644
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -33,9 +33,10 @@ then
check="$check boa cucipop courier-authdaemon cron cups exim"
check="$check exim4-base dovecot-common cucipop incron lprng lpr"
check="$check lpr-ppd mysql-server nis openbsd-inetd"
- check="$check openldapd postgresql-common proftpd postfix
postfix-tls"
- check="$check rsync samba sasl2-bin slapd smail sendmail snmpd ssh"
- check="$check spamassassin vsftpd wu-ftpd wu-ftpd-academ wwwoffle"
+ check="$check openldapd openssh-server postgresql-common proftpd"
+ check="$check postfix postfix-tls rsync samba sasl2-bin slapd"
+ check="$check smail sendmail snmpd spamassassin vsftpd"
+ check="$check wu-ftpd wu-ftpd-academ wwwoffle"
check="$check webmin dropbear gdm"
# NSS services check:
__NSS_CHECK__
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index 0e5aefae..e1cac4a1 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -3647,6 +3647,31 @@ index cba9cd1819..4580cefb9f 100644
dirlen = home_len + rest_len;
dirname_modified = 1;
}
+diff --git a/posix/wordexp-test.c b/posix/wordexp-test.c
+index ed1b22308e..cb3f989cba 100644
+--- a/posix/wordexp-test.c
b/posix/wordexp-test.c
+@@ -183,6 +183,7 @@ struct test_case_struct
+ { 0, NULL, "$var", 0, 0, { NULL, }, IFS },
+ { 0, NULL, "\"\\n\"", 0, 1, { "\\n", }, IFS },
+ { 0, NULL, "", 0, 0, { NULL, }, IFS },
++{ 0, NULL, "${1234567890123456789012}", 0, 0, { NULL, }, IFS },
+
+ /* Flags not already covered (testit() has special handling for these) */
+ { 0, NULL, "one two", WRDE_DOOFFS, 2, { "one", "two", }, IFS },
+diff --git a/posix/wordexp.c b/posix/wordexp.c
+index e082d94895..56289503a1 100644
+--- a/posix/wordexp.c
b/posix/wordexp.c
+@@ -1399,7 +1399,7 @@ envsubst:
+ /* Is it a numeric parameter? */
+ else if (isdigit (env[0]))
+ {
+- int n = atoi (env);
++ unsigned long n = strtoul (env, NULL, 10);
+
+ if (n >= __libc_argc)
+ /* Substitute NULL. */
diff --git a/stdlib/Makefile b/stdlib/Makefile
index 45214b59e4..4615f6dfe7 100644
--- a/st
Bug#988740: unblock: glibc/2.31-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-gl...@lists.debian.org, debian-boot@lists.debian.org Please unblock package glibc [ Reason ] This new version fixes testsuite failures when run on a kernel which has kernel.unprivileged_userns_clone set to 1. This is the case of the Bullseye kernel. This problem manifests itself as an FTBFS when building the package or a failed autopkgtests. In addition this version also fixes the display of non-ascii characters in German debconf template. It also includes fixes from the upstream stable branch fixing: - a wrong assumption of available instructions on s390x in the memmove code which might be triggered by a kernel parameter or some older versions of zVM - a fix in the way of AT_SECURE binaries are handled, which might be used to facilitate the exploitation of security issues in those binaries [ Impact ] If the unblock is not granted, users won't be able to build the package from sources on a Bullseye system without using the nocheck build option or disabling kernel.unprivileged_userns_clone. In addition users with a German locale will have to understand the displayed text without the non-ASCII letters. [ Tests ] The changes related to the testsuite actually improves the testsuite coverage. This allowed to find an issue in the debian/rules makefile causing the value of the --build= parameter to be wrongly empty. The debconf changes have been tested manually on a system set to German locale. The upstream changes related to the AT_SECURE binaries come with additional tests. Note that those tests actually represent the bigger part of the debdiff. [ Risks ] The fixes related to the testsuite involves many changes to our build system, by letting the upstream makefiles to install the ld.so symlink instead of doing it in the Debian makefiles, in an architecture specific way for bi/tri-arch packages. While the changes might look risky at a first glance, they do not change the code in the binaries, but only the ld.so symlinks and the libc.so linker scripts. Those have been verified manually on the packages built by glibc and cross-toolchain-base. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] The decision to install the ld.so symlink using the Debian specific makefiles instead of the upstream ones seems to have been taken many years ago to avoid changing dpkg-cross. dpkg-cross has been fixed recently in version 2.6.18+nmu1 (already in Bullseye), so this is not an issue anymore. No conflicts or breaks against dpkg-cross have been added as dpkg-cross is basically a .deb mangler which takes any .deb file from the command line. unblock glibc/2.31-12 diff -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog --- glibc-2.31/debian/changelog 2021-03-31 22:09:32.0 +0200 +++ glibc-2.31/debian/changelog 2021-05-01 22:56:06.0 +0200 @@ -1,3 +1,29 @@ +glibc (2.31-12) unstable; urgency=medium + + * debian/po/de.po: fix encoding declaration. Closes: #986450. + * debian/patches/git-updates.diff: update from upstream stable branch: +- On s390x, check for vector support in memmove ifunc-selector in + addition to Miscellaneous-Instruction-Extensions. + * debian/patches/any/local-rtlddir-cross.diff: drop patch, letting upstream +makefiles to install the dynamic linker symlink directly in the right +location. This fixes the temporary installation done by upstream makefiles +to run some tests in a container. Closes: #973278, #985617. + * debian/rules.d/build.mk: do not create the dynamic linker manually. + * debian/sysdeps/*.mk: do not create the dynamic linker manually for +bi/tri-arch packages. + * debian/rules.d/build.mk: create the soname symlink for ld-2.xx.so, to +avoid its creation later by ldconfig. + * debian/debhelper.in/libc.install, debhelper.in/libc-alt.install, +debhelper.in/libc-udeb.install, debhelper.in/libc-udeb.install.hurd-i386: +adjust given that the dynamic linker symlink is now already at the correct +location. + * debian/patches/git-updates.diff: update from upstream stable branch: +- Fix GLIBC_TUNABLES parsing for AT_SECURE binaries. + * debian/rules.d/build.mk: escape EOL so that $configure_build is correctly +passed to the configure script. + + -- Aurelien Jarno Sat, 01 May 2021 22:56:06 +0200 + glibc (2.31-11) unstable; urgency=medium * debian/debhelper.in/libc.preinst: handle the case where debconf diff -Nru glibc-2.31/debian/debhelper.in/libc-alt.install glibc-2.31/debian/debhelper.in/libc-alt.install --- glibc-2.31/debian/debhelper.in/libc-alt.install 2019-07-29 11:56:57.0 +0200 +++ glibc-2.31/debian/debhelper.in/libc-alt.install 2021-04-25 18:11:42.0 +0200 @@ -1,4 +1,5 @@ # This file is used for biarch libraries
Bug#973455: keymap dz(la) not supported?
Hi, On 2020-11-02 00:23, Holger Wansing wrote: > Aurelien Jarno wrote: > > > The locale settings for the Kabyle language are supposed to be > > > language: Kabyle - kab > > > country: Algeria - DZ > > > -> kab_DZ > > > > > > I have added Kabyle to the localechooser package, and it correctly shows > > > up as > > > a language in the "Choose language" dialog. > > > > I confirm that the kab_DZ is available in glibc, it has been added in > > version 2.27. You can also check that the date is properly displayed on > > a running Debian system. > > > > $ LC_ALL=kab_DZ date > > Sed 31 Tub 2020 17:36:48 CET > > > > > But I have a problem now in the text-based installer: > > > (in graphical installer everything is ok!) > > > While displaying the installer dialogs in Kabyle is fine, it fails to > > > switch > > > the keyboard to the desired "Berber (Latin)" layout. > > > > Keyboard layout is not something handled by the glibc locales. > > > > > I also noticed that the installer states to use "kab_DZ" as locale, while > > > in the other languages there is an UTF-8 locale (like "de_DE.UTF-8" for > > > German). > > > Maybe that's the reason for the installer failing to switch keyboard > > > correctly ... ? > > > > This is correct, because the kab_DZ locale is only available as UTF-8. > > de_DE.UTF-8 exists because the default de_DE locale is ISO-8859-1 > > encoded. The same way there is also a de_DE@euro locale defaulting to > > ISO-8859-15. > > > > > When diagnosing the list of supported locales, I see that in locales > > > package > > > the situation is the same: > > > > > > ned@t520:~$ grep kab /usr/share/i18n/SUPPORTED > > > kab_DZ UTF-8 > > > ned@t520:~$ > > > > > > Only "kab_DZ" shows up in /usr/share/i18n/SUPPORTED, instead of > > > "kab_DZ.UTF-8/UTF-8" like for many other languages. > > > > This is perfectly normal. There are many other locales without UTF-8 in > > their name, see for example fy_DE or en_NG. > > > > > Please accept my appologies, if I got something wrong here, but for me it > > > seems there is something wrong/missing... ? > > > Shouldn't UTF-8 be the default for years already? > > > (Hmm, not for all languages/locales maybe ... ?) > > > > Yes, that's exactly because UTF-8 is the default for years already that the > > Kabylian locale is only available as kab_DZ. > > Ok, thanks for taking the time to confirm, that this seems no issue related > to locales/glibc ! > With the above explanation it makes sense so far :-) > So, sorry for the noise. I have just seen you patch to localechooser: https://salsa.debian.org/installer-team/localechooser/-/commit/e7c432b8e7579511ff24ca554940b23cd0a9d482#97d66a6f96fa0a78b8cc86e86b52a0144da74883_54_53 I think the locale entry is wrong, as discussed above, it should be kab_DZ instead of kab_DZ.UTF-8. Just like then entries around are ks_IN or km_KH. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: busybox FTBFS with glibc 2.31 (references to obsolete 'stime')
Hi, On 2020-03-30 09:17, Steve Langasek wrote: > Package: busybox > Version: 1:1.30.1-4 > Severity: important > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, the busybox package has begun to FTBFS because Ubuntu has moved > to glibc 2.31, which has obsoleted the stime() function and busybox still > calls this function. > > The attached patch has been uploaded to Ubuntu, replacing the calls to > stime() with clock_settime(), per the glibc upstream documentation. > > This is not a serious bug today in Debian because glibc 2.31 is only in > experimental, but at some point it will become a serious FTBFS. It would be nice if this bug could be fixed as it is currently blocking the glibc 2.31 transition. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#953952: kmod: libkmod2-udeb contains binary instead of libraries
Package: kmod Version: 26+20191223-1 Severity: serious Tags: d-i Justification: Policy 8.6.4 The libkmod2 shlibs file contains the following entry: | libkmod 2 libkmod2 (>= 26+20191223) | udeb: libkmod 2 libkmod2-udeb (>= 26+20191223) It means that libkmod.so.2 is supposed to be provided by libkmod2-udeb. In practice it only contains the kmod binaries: | $ dpkg -c libkmod2-udeb_27-2_amd64.udeb | drwxr-xr-x root/root 0 2020-03-13 22:53 ./ | drwxr-xr-x root/root 0 2020-03-13 22:53 ./bin/ | -rwxr-xr-x root/root121656 2020-03-13 22:53 ./bin/kmod | drwxr-xr-x root/root 0 2020-03-13 22:53 ./etc/ | drwxr-xr-x root/root 0 2020-03-13 22:53 ./etc/modprobe.d/ | -rw-r--r-- root/root 246 2020-03-13 22:53 ./etc/modprobe.d/aliases.conf | drwxr-xr-x root/root 0 2020-03-13 22:53 ./sbin/ | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./bin/lsmod -> kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/depmod -> /bin/kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/insmod -> /bin/kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/lsmod -> /bin/kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/modinfo -> /bin/kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/modprobe -> /bin/kmod | lrwxrwxrwx root/root 0 2020-03-13 22:53 ./sbin/rmmod -> /bin/kmod udev-udeb depends on libkmod2-udeb as /lib/systemd/systemd-udevd requires libkmod.so.2. The binaries should probably be moved to a different package like kmod-udeb, as they conflict with busybox-udeb. Right now the kmod ones are used, but it depends on the unpack order. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Bug#953878: libudev1-udeb: library wrongly shipped in the multiarch path
On 2020-03-14 14:55, Michael Biebl wrote: > Am 14.03.20 um 13:23 schrieb Aurelien Jarno: > > Package: systemd > > Version: 245-2 > > Severity: normal > > Tags: patch > > > > libudev1-udeb ships the libudev.so.1 in the multiarch path: > > > > | $ dpkg -c libudev1-udeb_245-2_amd64.udeb > > | drwxr-xr-x root/root 0 2020-03-12 12:55 ./ > > | drwxr-xr-x root/root 0 2020-03-12 12:55 ./lib/ > > | drwxr-xr-x root/root 0 2020-03-12 12:55 ./lib/x86_64-linux-gnu/ > > | -rw-r--r-- root/root174144 2020-03-12 12:55 > > ./lib/x86_64-linux-gnu/libudev.so.1.6.17 > > | lrwxrwxrwx root/root 0 2020-03-12 12:55 > > ./lib/x86_64-linux-gnu/libudev.so.1 -> libudev.so.1.6.17 > > > > udeb packages should ship the library in the non-multiarch path, i.e. > > /lib or /usr/lib. Otherwise this causes mklibs to fetch the library from > > the system instead of the udeb and increases the size of d-i image > > Installing in M-A paths is deliberate to not have any pointless > differences between the udeb and non-udeb build. This is not something supported by the d-i build system. > TBH, I don't understand the problems you list above. Why would shipping > a file in a different path increase the size of the d-i image? > This causes the d-i build system to not find the library, it therefore fallback in to copying the system library, and thus it is present twice in the initrd: $ find . -name libudev.so.1 ./lib/libudev.so.1 ./lib/x86_64-linux-gnu/libudev.so.1 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#953879: libnl-genl-3-200-udeb: library wrongly shipped in the multiarch path
Source: libnl3
Version: 3.4.0-2
Severity: normal
Tags: patch
libnl-genl-3-200-udeb ships the libnl-genl-3.so.200 library in the
multiarch path:
| $ dpkg -c libnl-genl-3-200-udeb_3.4.0-1+b1_amd64.udeb
| drwxr-xr-x root/root 0 2019-08-18 13:08 ./
| drwxr-xr-x root/root 0 2019-08-18 13:08 ./lib/
| drwxr-xr-x root/root 0 2019-08-18 13:08 ./lib/x86_64-linux-gnu/
| -rw-r--r-- root/root 28072 2019-08-18 13:08
./lib/x86_64-linux-gnu/libnl-genl-3.so.200.26.0
| lrwxrwxrwx root/root 0 2019-08-18 13:08
./lib/x86_64-linux-gnu/libnl-genl-3.so.200 -> libnl-genl-3.so.200.26.0
udeb packages should ship the library in the non-multiarch path, i.e.
/lib or /usr/lib. Otherwise this causes mklibs to fetch the library from
the system instead of the udeb and increases the size of d-i image
(although compression helps a bit there). This also prevent the removal
of mklibs from d-i, which we will eventually want to do.
The patch below fixes the issue. Would it be possible to include it in
the next upload?
Thanks,
Aurelien
--- libnl3-3.4.0/debian/libnl-genl-3-200-udeb.install
+++ libnl3-3.4.0/debian/libnl-genl-3-200-udeb.install
@@ -1,2 +1,2 @@
#!/usr/bin/dh-exec
-usr/lib/${DEB_HOST_MULTIARCH}/libnl-genl-3.so.* lib/${DEB_HOST_MULTIARCH}/
+usr/lib/${DEB_HOST_MULTIARCH}/libnl-genl-3.so.* lib/
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#953878: libudev1-udeb: library wrongly shipped in the multiarch path
Package: systemd Version: 245-2 Severity: normal Tags: patch libudev1-udeb ships the libudev.so.1 in the multiarch path: | $ dpkg -c libudev1-udeb_245-2_amd64.udeb | drwxr-xr-x root/root 0 2020-03-12 12:55 ./ | drwxr-xr-x root/root 0 2020-03-12 12:55 ./lib/ | drwxr-xr-x root/root 0 2020-03-12 12:55 ./lib/x86_64-linux-gnu/ | -rw-r--r-- root/root174144 2020-03-12 12:55 ./lib/x86_64-linux-gnu/libudev.so.1.6.17 | lrwxrwxrwx root/root 0 2020-03-12 12:55 ./lib/x86_64-linux-gnu/libudev.so.1 -> libudev.so.1.6.17 udeb packages should ship the library in the non-multiarch path, i.e. /lib or /usr/lib. Otherwise this causes mklibs to fetch the library from the system instead of the udeb and increases the size of d-i image (although compression helps a bit there). This also prevent the removal of mklibs from d-i, which will eventually want to do. The patch below fixes the issue. Would it be possible to include it in the next upload? Thanks, Aurelien --- systemd-245/debian/libudev1-udeb.install +++ systemd-245/debian/libudev1-udeb.install @@ -1 +1 @@ -lib/*/libudev.so.* +lib/*/libudev.so.* lib/ -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Bug#951749: System installation hangs on decompressing tzdata
control: reassign -1 debootstrap On 2020-02-21 02:39, Rahul Martim Juliato wrote: > Package: tzdata > > > System install hangs on trying to uncompress tzdata. > > > I tried with the mini image, DVD and DVD without network (hoping it would > force not to download anything and using what is on DVD) > > > But in all tries the installation hangs (both on graphical and text) > just after tzdata is being uncompressed. > > > After a red screen said it tried 5 times and cannot continue, I went to > sheel and was able to read something like this on the log: > > > debootstrap: dpkg: error while cleaning up > debootstrap: unable to trstore backup version of > '/usr/share/zoneinfo/right/Australi...' and many other lines similary to > this. Can you please provide the exact log output? A photo is also fine. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#941853: crypt(3) should be provided by libxcrypt
On 2019-12-06 22:46, Cyril Brulebois wrote: > Hi, > > Marco d'Itri (2019-10-07): > > Dear debian-boot: for the benefit of the ftpmasters, please confirm that > > you have no objections to src:libxcrypt generating a libcrypt1-udeb > > package (initially in experimental) which will provide crypt(3) > > currently in the libc udeb. > > > > > I guess we should keep building libcrypt1 for the bi/tri-arch packages. > > What do I need to do about this? > > > > > > (Also, do not forget about the man pages in the -dev packages.) > > > The man page was not provided by the -dev package but by manpages-dev. > > Actually I see that it automatically stopped shipping crypt(3) and > > crypt_r(3) in 5.01-1, so I will add Breaks+Replaces. > > > > > We must build the libcrypt1 udeb, and add a depends from libc6-deb to > > > libcrypt1-udeb, otherwise we might break d-i. At some point we might > > OK, I will start again building the udeb with the next upload. > > Aurelien, Marco, do we need to anticipate any changes on the d-i side? > > Or will that udeb addition just result in a new dependency from crypt-using > udebs to libcrypt1-udeb? There should be no changes needed on the d-i side. libc6-udeb has a new dependency on libcrypt1-udeb. When packages get rebuilt against libxcrypt, they'll have a direct dependency on libcrypt1-udeb. There is a small impact on size (~100kB) as libxcrypt provides a bit more functionality. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#943572: d-i.debian.org: d-i scripts on dillon.d.o use /srv/mirrors
Package: d-i.debian.org Severity: normal DSA would like to move dillon to another ganeti cluster with no local mirror. It seems that the d-i scripts use /srv/mirrors, at least the following crontab entry: 55 */4 * * * cd $DI; mr -q up ; cd $DI/scripts/testing-summary; ./gen-summary /srv/mirrors/debian > $WWW/testing-summary.html ; ~/bin/push-www Can you please confirm that /srv/mirrors is still used? Does it need a full mirror or a partial mirror without pool/? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
control: retitle 926699 libc6 foreign/biarch: installing, removing,
reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
control: affects 926699 libc6
Hi,
I have been asked privately to work constructively on a solution,
otherwise my bad behaviour will likely lead to a decision that I will
regret if this discussion leads towards an appeal to the TC.
So let me explain in details my position on the subject.
The issue
-
First of all let's describe the problem.
usrmerge works by moving all data from /lib into /usr/lib and then
creating a symlink /lib -> /usr/lib. The same is done for the biarch
or triarch directories, namely /lib32, /lib64, /libx32 and /libo32
depending on the architecture. Note that this part is done by usrmerge,
but doesn't appear in its description, nor in the debconf question
asked to the user. It is important to note that it is done directly on
the filesystem and that this change is not known to dpkg.
When a user install for example libc6-i386 on an amd64 system, dpkg will
follow the symlink and will install everything that should go on /lib32
into /usr/lib32 as expected. This works as expected. However when the
package is removed, /lib32 will be removed. In turn when it is installed
again, the symlink /lib32 -> /usr/lib32 has disappeared.
This is the consequence of:
1) the dpkg policy to remove the last used directory or symlink on
package removal.
2) libc6-i386 being the last package using /lib32.
There is nothing special done with that regard in the glibc maintainer
scripts.
Similarly, that issue also affects the libc6 package when used as a
foreign architecture. For example installing libc6:amd64 on an i386
system and then deinstalling and reinstalling it will cause the /lib64
-> /usr/lib64 to disappear. I guess there might also be some more
issues when installing biarch packages as foreign packages.
The solution envisaged by the usrmerge team
---
The usrmerge people considers that it has to be fixed in the glibc
maintainer scripts. As explained above, it would mean that the preinst
script is responsible, if usrmerge is activated, to create the
/lib{32,64,o32,x32} -> /usr/lib{32,64,o32,x32} symlink if it doesn't
exist. The directory might not be empty as a result of a partial
conversion to usrmerge (yes those system will exists). In turn this
directory might be the one of the dynamic linker used for executing
the maintainer scripts (dash/bash, coreutils). So this means the
maintainer scripts have to handle the case of moving the dynamic
linker without breaking the system.
In short it means *the most tricky part of usrmerge has to be
implemented and maintained in the glibc preinst scripts*. This is even
more difficult as the preinst script will be executed all the time and
not when the user ask for that. It won't ask the user for its permission
before. It doesn't have the option to abort if something looks wrong as
this will lead to a system difficultly recoverable for many users if
they are dist-upgrading their system to a new release (usually apt-get
install -f is not enough).
On the glibc side experience we have very bad experience of moving the
dynamic linker from one directory to another in the maintainer scripts,
and this has resulted in many broken systems. There are still even a few
bugs opened about that for which we haven't really understood the
problem. Looking at the usrmerge's archived bugs, it seems it wasn't an
easy road on the usrmerge side either.
Alternative solutions
-
I do not understand why I should be the one responsible of finding a
solution to this issue. Anyway let me provide a few alternatives
solutions.
In my opinion, the root of the problem is that the symlink is created
without dpkg being aware of that. Therefore it removes it once there are
no users for it. This is exactly why for example base-files ships
/usr/src and we do not require all packages that ship a file in /usr/src
to have postrm script to make sure the directory still exists after the
package removal.
Therefore I really believe the best solution for this issue is to
make dpkg aware of the symlink, which means creating a package
containing this symlinks. This could be for example:
- in base-files, for example by depending on base-files-usrmerge |
base-files-nousrmerge
- in usrmerge after reconsidering that the package can be uninstalled
after the conversion.
- directly in the libc6 and libc6-xxx packages if the TC reconsiders the
"weak" situation for at least the /lib{32,64,o32,x32} directories.
Another alternative solution is simply to only consider /lib and
/usr/lib for usrmerge (like it is alreayd done in the user visible
interface) and ignore the /lib{32,64,o32,x32} directories, at least
until the state stays as "weak".
I would be happy if you could also work on your side to provide
alternative solutions.
Regards,
Aurelien
--
Aurelien Ja
Re: Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
On 2019-08-17 23:00, Marco d'Itri wrote: > On Aug 17, Aurelien Jarno wrote: > > > One package should be responsible for providing those links so that > > glibc is not the last package using them. The same way that base-files > > ensure that some directories are present. > usrmerge is only needed to be installed during the conversion of a > non-merged system, so it cannot do this. > > Putting the links inside some package would not solve the problem of > e.g. /lib32/ and /libx32/ being always created even on systems which do > not need them. > And worse, deleting them would become impossible because they would be > created again every time the package is upgraded. > > Doing this in base-files would require having both a "base-files" and > a "base-files-not-merged" package as long as we will keep supporting > non-merged systems, and I think that the complexity of managing this > (in deboostrap and possibly somewhere else) makes this a non-starter. > > If this were implemented in a different package then it would need to be > Essential (and still require special-casing in debootstrap as long as we > will want to support non-merged systems), so I am not sure if this plan > would be accepted by all the stakeholders. Fine it's your opinion. Then I leave you imagine other ideas. I am still believing cluttering the maintainer scripts of the glibc is not the right way to go, even if it's the easy way for you. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
On 2019-08-17 22:20, Marco d'Itri wrote:
> On Aug 17, Aurelien Jarno wrote:
>
> > > > The preinst scripts could check whether the package is being installed
> > > > in a --merged-usr environment and create (dangling) symlinks if
> > > > /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> > > > they went missing.
> Yes: this is how I hoped that this could be implemented, to stop having
> useles e.g. /libx32/ on all amd64 systems which will never see x32
> packages.
>
> > As explained it's not a bug of the glibc package, but a design flaw of
> > usrmerge. I am therefore reassigning the bug to debootstrap + usrmerge.
> Do you have any suggestions about how you would like this to be fixed?
One package should be responsible for providing those links so that
glibc is not the last package using them. The same way that base-files
ensure that some directories are present.
To take an analogy, base-files provides /usr/src to ensure it is always
there. It is not created by deboostrap and we do not ask all packages
writing to /usr/src to have a postrm file recreating the directory.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Re: Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
reassign -1 debootstrap,usrmerge
thanks
On 2019-04-09 16:53, Aurelien Jarno wrote:
> On 2019-04-09 12:27, Andreas Beckmann wrote:
> > Package: libc6-x32,libc6-i386
> > Version: 2.28-8
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > Hi,
> >
> > during a test with piuparts in a --merged-usr environment I noticed that
> > installing, removing, and installing again a package shipping /lib32,
> > /libx32 will actually unmerge that directory.
> > The package will take ownership of the preexisting symlinks
> > /lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
> > remove them and create plain /usr/lib{32,x32} directories in the next
> > installation.
> > (/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
> > perhaps on !x86 architectures)
/lib64 is an issue for at least libc6:amd64 on an i386 system. And there
are many more cases if you also consider other official architectures
and ports architectures.
> Hmm the only fault of the libc6-i386 and libc6-x32 packages (plus I
> guess all the other bi/tri-arch ones on other architectures) is to be
> the last user of those directory when being removed. They do not do
> anything tricky in their directories.
>
> > The preinst scripts could check whether the package is being installed
> > in a --merged-usr environment and create (dangling) symlinks if
> > /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> > they went missing.
The glibc maintainer scripts are already cluttered with many ugly and
fragile workarounds to handle the co-installability of foreign and biarch
glibc. I do not want to adds more workarounds that might will make the
whole things a nightmare.
> This looks like an ugly workaround to me, and might not work if a
> package start adding files there without depending on libc6. This looks
> to me like a flaw in the usrmerge design. The base-files package is
> designed to prevent directories or symlinks to be removed, so I wonder
> if we need a usrmerge version of it.
As explained it's not a bug of the glibc package, but a design flaw of
usrmerge. I am therefore reassigning the bug to debootstrap + usrmerge.
I am not opposed to a workaround in the glibc package, kept for one
release cycle only, *once a real solution* is implemented for this bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Please drop usbutils from block-udeb in freeze hints
Hi, The freeze hints contains the following entry: block-udeb usbutils usbutils dropped it's udeb package during the buster release cycle, and thus the usbutils-udeb package was present in stretch, but is not present in buster. Could you please therefore drop the corresponding entry from the freeze hints? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#928404: unblock: glibc/2.28-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, The glibc package in version 2.28-10 currently in sid mostly updates the git-updates.diff patch to the latest upstream stable branch: - Fix security issue CVE-2019-9169. - Support for the new Reiwa era to the ja_JP which seems to be something quite important for Japanese people. provide shared libraries (not) tuned for the corresponding platforms. - Fix for an infinite loop in the pldd binary, which makes it unusable (regression from stretch). - Support for vector instructions related hwcap on s390x to allow one to - Fix for a riscv specific issue in a file which is not used on other architectures, so with no risk for them. In addition to that it includes a fix for a bug in dlopen introduced by an arm patch, but affecting all architectures. I believe that all the above changes are suitable for buster. If you agree, could you please unblock package glibc: unblock glibc/2.28-10 Thanks, Aurelien -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#928143: unblock: glibc/2.28-9
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
The glibc package in version 2.28-9 currently in sid mostly updates the
git-updates.diff patch to the latest upstream stable branch:
- Fix security issue CVE-2019-9169.
- Support for the new Reiwa era to the ja_JP which seems to be something
quite important for Japanese people.
- Support for vector instructions related hwcap on s390x to allow one to
provide shared libraries (not) tuned for the corresponding platforms.
- Fix for a riscv specific issue in a file which is not used on other
architectures, so with no risk for them.
- Fix for memusagestat's Makefile related code, which has no impact on
the generated code.
In addition to that it includes a fix for a bug in dlopen introduced by
an arm patch, but affecting all architectures.
I believe that all the above changes are suitable for buster. If you
agree, could you please unblock package glibc:
unblock glibc/2.28-9
Thanks,
Aurelien
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 24a46054..711bb67a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+glibc (2.28-9) unstable; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix heap-based buffer over-read in regular-expression matching
+ (CVE-2019-9169). Closes: #924612.
+- Add entry for the new Japanese era to the ja_JP locale. Closes:
+ #927914.
+
+ [ Adam Conrad ]
+ * debian/patches/arm/unsubmitted-ldso-abi-check.diff: Fix rtld segv in
+dl_open() introduced via merge with upstream at 2.28 (LP: #1821677)
+
+ -- Aurelien Jarno Thu, 25 Apr 2019 21:12:03 +0200
+
glibc (2.28-8) unstable; urgency=medium
[ Aurelien Jarno ]
diff --git a/debian/patches/arm/unsubmitted-ldso-abi-check.diff
b/debian/patches/arm/unsubmitted-ldso-abi-check.diff
index 6c78c674..8a7cab12 100644
--- a/debian/patches/arm/unsubmitted-ldso-abi-check.diff
+++ b/debian/patches/arm/unsubmitted-ldso-abi-check.diff
@@ -222,10 +222,10 @@
if (ph->p_type == PT_NOTE && ph->p_filesz >= 32 && ph->p_align >= 4)
{
ElfW(Addr) size = ph->p_filesz;
-@@ -1751,6 +1955,21 @@
+@@ -1751,6 +1955,20 @@
+
+ break;
}
- free (abi_note_malloced);
- }
+ if (-1 != fd)
+ {
+int error = arch_specific_checks(fd, name, ehdr);
@@ -239,8 +239,7 @@
+goto call_lose;
+ }
+ }
-+
-+}
++ }
+ free (abi_note_malloced);
+ }
- return fd;
- }
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index 50d4962c..a6722cc9 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -1,10 +1,44 @@
GIT update of https://sourceware.org/git/glibc.git/release/2.28/master from
glibc-2.28
diff --git a/ChangeLog b/ChangeLog
-index 08b42bd2f5..42fe0aeb1e 100644
+index 08b42bd2f5..609d5c1b19 100644
--- a/ChangeLog
+++ b/ChangeLog
-@@ -1,3 +1,784 @@
+@@ -1,3 +1,818 @@
++2019-04-24 Mike Frysinger
++
++ [BZ #18465]
++ * malloc/Makefile (others): Add memusagestat.
++ ($(objpfx)memusagestat): Delete rule.
++ (LDLIBS-memusagestat): New variable.
++
++2019-04-03 TAMUKI Shoichi
++
++ [BZ #22964]
++ * localedata/locales/ja_JP (LC_TIME): Add entry for the new Japanese
++ era.
++
++2019-03-21 Stefan Liebler
++
++ * sysdeps/s390/dl-procinfo.h (HWCAP_IMPORTANT):
++ Add HWCAP_S390_VX and HWCAP_S390_VXE.
++
++2019-01-31 Paul Eggert
++
++ CVE-2019-9169
++ regex: fix read overrun [BZ #24114]
++ Problem found by AddressSanitizer, reported by Hongxu Chen in:
++ https://debbugs.gnu.org/34140
++ * posix/regexec.c (proceed_next_node):
++ Do not read past end of input buffer.
++
++2018-11-07 Andreas Schwab
++
++ [BZ #23864]
++ * sysdeps/unix/sysv/linux/riscv/kernel-features.h
++ (__ASSUME_SET_ROBUST_LIST) [__LINUX_KERNEL_VERSION < 0x041400]:
++ Undef.
++
+2018-09-21 Adhemerval Zanella
+
+ * NEWS: Add note about new TLE support on powerpc64le.
@@ -807,15 +841,19 @@ index 608ffe648c..f5e81bdf5d 100644
# We might want to compile with some stack-protection flag.
ifneq ($(stack-protector),)
diff --git a/NEWS b/NEWS
-index 154ab22d7c..60b15116d6 100644
+index 154ab22d7c..e8030d499a 100644
--- a/NEWS
+++ b/NEWS
-@@ -5,6 +5,77
Bug#690210: debootstrap : debian-ports support
control: retitle -1 debootstrap: please support multiple suites On 2018-04-30 09:45, Raphael Hertzog wrote: > Hi, > > On Sat, 28 Apr 2018, jhcha54008 wrote: > > I am afraid debootstrap already depends on perl (it > > doesn't show up in the control file as perl-base > > is Essential) : it ships a perl function 'pkg_details' > > inline (see file /usr/share/debootstrap/functions line 1323 > > in debootstrap version 1.0.97) > > Ok, I missed this. Still I'm pretty sure that it's not a good > trend to continue. > > > Should the perl code depends on libdpkg-perl or is it bearable > > to inline the needed functions ? The former avoids code duplication > > with benefits in size and maintainability, the latter keeps the > > dependencies to a minimum (wget, perl-base). > > > > As far as I know, there are three main use cases of debootstrap : > > 1. create a debian chroot on a host running debian (or similar) > > 2. in debian-installer (base-installer step) > > 3. "to install Debian GNU/Linux from a Unix/Linux system" > > (https://www.debian.org/releases/stable/amd64/apds03.html.en) > > > > Depending on libdpkg-perl is beneficial to the first use case, > > and inlining the functions to the third. > > A dependency on libdpkg-perl is not a good idea either. This is why I'm > really questioning the need to for this code to be inside debootstrap > at all. From what I get this new dependency on libdpkg-perl or on perl code is to be able to sort packages by version, as a package can be in both suite in different versions. However that leads me to 2 questions: - At least for sid, it's already possible to have a package twice in two different versions in a single suite. How does it work currently? Does it takes the first one, the second one, or is it a random selection? I am not sure that the order in dak is stable though. - If the order used by debootstrap is not random, we can probably just "concatenate" the two Packages file in the right order to give more priority to unreleased (or to -security, see below). > > > IMO the special casing for ports.debian.org architectures should be > > > handled in a dedicated wrapper. And maybe debootstrap needs new features > > > to make this wrapper possible. > > > > May I ask what for new features you have in mind ? > > Possibly passing a pre-built "Packages" file directly. It would be the > result of the merge that you are doing between UNRELEASED and the normal > suite. > > > Is the hope of a debian-ports support in debootstrap still > > (not too un)reasonable ? > > Why aren't you creating a proper suite merging the required bits on the > server side in ports.debian.org? > > Maybe the tools you are using do not make it easy to implement but it's really > something that is not hard with most of the tools (e.g. reprepro). I am not really sure why we want to do that on the server side, especially that we are talking about moving debian-ports to dak at some point, so it means the work will have to be redone also for dak. In addition to that, in the light of the recent apt issue, there is another use case than debian-ports for supporting multiple suites. Supporting debootstrap from both oldstable and oldstable-security would allow to debootstrap jessie easily. Currently you need to deboostrap jessie and then upgrade to the latest apt with the redirection disabled. Of course you need to do that from a mirror which doesn't use redirection (i.e. not deb.debian.org as apt from jessie doesn't support the SRV record). As a bonus this feature could be used in the d-i netboot images, making the installation even faster, by not downloading and installing the packages in -security twice. In that regard, I have retitled the bug report. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#871033: newt: please add a libnewt0.52-udeb package
On 2017-08-06 20:55, Aurelien Jarno wrote: > Source: newt > Version: 0.52.20-1 > Severity: wishlist > Tags: patch > > Dear Maintainer, > > debian-installer used to re-link all the libraries going into the initrd > in order to strip unneeded symbols, using mklibs. That is the reason why > libnewt0.52-pic was needed. Unfortunately it was subject to regular > breakage, so d-i switched to mklibs-copy which just copies the regular > library. > > It would now make sense to get rid of mklibs-copy and switch to a > regular udeb. Therefore would it be possible to add a libnewt0.52-udeb > package to newt? That's the purpose of the attached patch. > > Once the transition has been done, it will be possible to get rid of the > libnewt0.52-pic package. Any news about that? Does it sounds acceptable to you? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic
On 2018-01-21 00:47, Ben Hutchings wrote: > On Wed, 17 Jan 2018 12:31:06 +0100 Aurelien Jarno <aure...@debian.org> wrote: > [...] > > busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has > > the same effect of reducing the default stack alignment from 16 bytes to > > 2 bytes. This comes from arch/i386/Makefile: > > The argument is the log2 of the alignment, so this sets alignment to 4 > bytes - which is compliant with the System V psABI for i386. This is correct, but it is not compliant with the i386 GCC ABI which assumes the stack is 16-byte aligned (not just 4-byte aligned) when the call instruction in the caller was executed. > Any assumption of 16-byte stack alignment in glibc on i386 will break > not only busybox but most binaries built with old versions of gcc > (before 4.2, if the comment in busybox is correct). So this really > ought to be fixed there. The 16-byte stack alignment in glibc on i386 comes from a GCC 7 regression, reported as bug #887327. It has been fixed in the upstream gcc-7 branch in the mean time. > I think that any libraries that need to maintain backward binary > compatibility will need to be compiled with the option > -mincoming-stack-boundary=2. gcc will then fix up the stack alignment > in functions that need greater alignment for local variables. If we allow any binary to be built with -mpreferred-stack-boundary=2, we need to build *all* libraries with -mincoming-stack-boundary=2, not only the ones that need to maintain backward binary compatibility. In that case we should make it the default in GCC. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic
control: reassign -1 busybox control: retitle -1 busybox: wrongly compiled with -mpreferred-stack-boundary=2 on i386 On 2018-01-17 12:08, Raphael Hertzog wrote: > Control: reassign -1 src:glibc 2.26-1 > Control: retitle -1 busybox sh broken on i386 with glibc 2.26, leads to > kernel panic > Control: severity -1 serious > Control: affects -1 + busybox src:linux > > Hello, > > on i386 with glibc 2.26-4, busybox sh is broken: > > $ busybox sh > [...] > BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > Segmentation fault > > In the kernel messages, you see this: > [1097712.640730] traps: busybox[3288] general protection ip:f7e9a51d > sp:ff8da68c error:0 in libc-2.26.so[f7d48000+1cd000] > > There's a work-around (the same as the one described in > #887169): > > $ GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2 busybox sh > [...] > BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > ~ $ > > Given that busybox's sh is used in the initrd and that the init > command is a shell script, this will lead to the kernel panic > shown earlier in this bug report. > > Possible work-arounds in the mean time: > - disable busybox in the initrd by setting BUSYBOX=n in > /etc/initramfs-tools/initramfs.conf (but this is not > possible if you use cryptsetup) > - you can add the "GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2" to the kernel > command line so that it's set in the environment of the init script > (this will at least let you boot once to fix it permanently) > - install busybox-static instead of busybox (since it was built with > an earlier version of glibc) and rebuild your initrd. > > Aurélien Jaron commented on IRC that this was strange that busybox > was affected by this bug since the analysis made in #887169 lead to > believe that only binaries compiled with -mstack-align=4 would be > affected. busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has the same effect of reducing the default stack alignment from 16 bytes to 2 bytes. This comes from arch/i386/Makefile: | # -mpreferred-stack-boundary=2 is essential in preventing gcc 4.2.x | # from aligning stack to 16 bytes. (Which is gcc's way of supporting SSE). | CFLAGS += $(call cc-option,-march=i386 -mpreferred-stack-boundary=2,) I don't really get why it is essential to prevent gcc from aligning stack to 16 bytes, anyway this is a bad idea. Removing this option just fixes the issue. I am therefore reassigning the bug to busybox. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
debian-installer & usbutils
Hi, Recent versions of usbutils (like the one in experimental) have stopped using usb.ids, but rather access the udev hardware database through libudev. While both udev and libudev have a udeb package, they don't provide the hardware database, and I am not sure we want to add it. Looking at debian-installer code, it seems that usbutils is not used anymore and that a shell script called usb-list is used instead in installation-report. So in short, could we just drop the udeb from usbutils? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: New arm64 porterbox, old one will be decommissioned soon
On 2017-09-09 17:57, Cyril Brulebois wrote: > Cyril Brulebois <k...@debian.org> (2017-09-09): > > Aurelien Jarno <aure...@debian.org> (2017-09-08): > > > Dear all, > > > > > > The arm64 porterbox called asachi.d.o is kindly hosted by Linaro. We > > > have just been notified that this hosting will come to and end soon. > > > We have therefore created a new arm64 porterbox at Conova called > > > amdahl.d.o. asachi.d.o will be decommissioned soon. > > > > > > Please use this new porterbox instead of the old one. If you have any > > > important work in progress on asachi.d.o, it's time to fetch your data. > > > Remember that the porterboxes are NOT backuped, so we won't be able to > > > get your data once it has been decommissioned. > > > > Thanks for the heads-up, I'm currently preparing both amdahl and dillon > > for d-i daily builds. > > I think we're all done: > - dillon: asachi replaced with amdahl in daily-build-setup.git, and >authorized_keys refreshed. > - asachi: daily builds decronned. > - amdahl: ssh keys generated, di-autobuild.git cloned, daily builds cronned, > and one build performed for each arch to make sure both build and >sync work fine. Thanks! -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
New arm64 porterbox, old one will be decommissioned soon
Dear all, The arm64 porterbox called asachi.d.o is kindly hosted by Linaro. We have just been notified that this hosting will come to and end soon. We have therefore created a new arm64 porterbox at Conova called amdahl.d.o. asachi.d.o will be decommissioned soon. Please use this new porterbox instead of the old one. If you have any important work in progress on asachi.d.o, it's time to fetch your data. Remember that the porterboxes are NOT backuped, so we won't be able to get your data once it has been decommissioned. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Please unblock glibc/2.24-14
On 2017-08-20 00:56, Cyril Brulebois wrote: > Hello, > > Aurelien Jarno <aurel...@aurel32.net> (2017-08-19): > > glibc/2.24-14 has been blocked for long in unstable due to the linux > > package not migrating. Unfortunately it failed to migrate at the same > > time due to bug#871275, which has nothing to glibc besides the fact that > > "libc-bin" appears in the log. > > > > In short, after waiting for more than 2 weeks, it missed the freeze only > > by a few hours. It would be nice to have it in testing asap, as the > > current version in testing is not buildable with binutils 2.19 which is > > now in testing. Besides that nothing to worry about for d-i. > > glibc | 2.24-14 | testing| source > glibc | 2.24-14 | unstable | source > > Happened during the 1000Z run. Thanks! -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Please unblock glibc/2.24-14
Hi, glibc/2.24-14 has been blocked for long in unstable due to the linux package not migrating. Unfortunately it failed to migrate at the same time due to bug#871275, which has nothing to glibc besides the fact that "libc-bin" appears in the log. In short, after waiting for more than 2 weeks, it missed the freeze only by a few hours. It would be nice to have it in testing asap, as the current version in testing is not buildable with binutils 2.19 which is now in testing. Besides that nothing to worry about for d-i. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#871045: src:debian-installer: should d-i use the busybox provided kmod binaries?
Package: src:debian-installer Severity: important Dear Maintainer, I just realized that busybox also provides the kmod related binaries (lsmod, depmod, insmod, modinfo, modprobe, rmmod). I wonder if we should use that instead of the binaries from kmod. I don't really have any opinion pro or con besides that it would save around 120kB in the initrd. Aurelien -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Use better compression for udebs?
On 2017-07-31 05:29, Niels Thykier wrote: > On Mon, 31 Jul 2017 00:44:30 +0300 Adrian Bunk <b...@debian.org> wrote: > > Package: debhelper > > Version: 10.2.5 > > Severity: normal > > > > Following up on an observation I made in #868674: > > > > udebs are currently compressed with "xz -1 -extreme", > > while normal packages are compressed with "xz -6". > > > > "xz -1" requires 2 MiB memory for decompression and > > "xz -6" requires 9 MiB memory for decompression. > > > > Is there any situation left where these 7 MiB difference still matter? > > > > Is there is no situation left where 9 MiB memory usage for > > decompression are a problem, then "xz -6 -extreme" would > > be a better choice. > > > > > > I think this is a question better asked in debian-boot. :) Noawadays, system installed with d-i won't work with less than about 160MB of memory. So I guess this should not be an issue to just build udeb packages the same ways than deb packages. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#871033: newt: please add a libnewt0.52-udeb package
Source: newt
Version: 0.52.20-1
Severity: wishlist
Tags: patch
Dear Maintainer,
debian-installer used to re-link all the libraries going into the initrd
in order to strip unneeded symbols, using mklibs. That is the reason why
libnewt0.52-pic was needed. Unfortunately it was subject to regular
breakage, so d-i switched to mklibs-copy which just copies the regular
library.
It would now make sense to get rid of mklibs-copy and switch to a
regular udeb. Therefore would it be possible to add a libnewt0.52-udeb
package to newt? That's the purpose of the attached patch.
Once the transition has been done, it will be possible to get rid of the
libnewt0.52-pic package.
Thanks,
Aurelien
diff -Nru newt-0.52.20/debian/control newt-0.52.20/debian/control
--- newt-0.52.20/debian/control 2017-05-03 10:53:05.0 +
+++ newt-0.52.20/debian/control 2017-08-06 16:11:51.0 +
@@ -82,6 +82,19 @@
to provide extra functionality. This package contains the shared library
for programs that have been built with newt.
+Package: libnewt0.52-udeb
+Architecture: any
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Not Erik's Windowing Toolkit for Debian Installer
+ This is a udeb, or a microdeb, of the Not Erik's Windowing Toolkit. As such
+ it is the installer counterpart of libnewt0.52.
+ You only need this package to support applications needing Newt during
+ the Debian installation process time and probably don't need to select it.
+Package-Type: udeb
+
+
Package: whiptail
Architecture: any
Section: utils
diff -Nru newt-0.52.20/debian/libnewt0.52-udeb.install
newt-0.52.20/debian/libnewt0.52-udeb.install
--- newt-0.52.20/debian/libnewt0.52-udeb.install1970-01-01
00:00:00.0 +
+++ newt-0.52.20/debian/libnewt0.52-udeb.install2017-08-06
16:11:51.0 +
@@ -0,0 +1,2 @@
+usr/lib/*/libnewt.so.0.52.20 usr/lib
+usr/lib/*/libnewt.so.0.52 usr/lib
diff -Nru newt-0.52.20/debian/rules newt-0.52.20/debian/rules
--- newt-0.52.20/debian/rules 2017-05-03 10:53:05.0 +
+++ newt-0.52.20/debian/rules 2017-08-06 16:11:51.0 +
@@ -84,3 +84,6 @@
mkdir -p debian/libnewt-pic/$(LIBDIR)
cp newt*.ver debian/libnewt-pic/$(LIBDIR)/libnewt_pic.map
+override_dh_makeshlibs:
+ dh_makeshlibs -a -V --add-udeb="libnewt0.52-udeb"
+
Bug#865425: debian-installer-9-netboot-mips64el: mips64el Malta netboot installer finds no installable kernel
On 2017-06-24 19:07, Aurelien Jarno wrote: > On 2017-06-24 02:12, Cyril Brulebois wrote: > > Control: reassign -1 libdebian-installer 0.110 > > Control: affects -1 debian-installer-9-netboot-mips64el > > > > Bruno Bierbaumer <l...@bierbaumer.net> (2017-06-21):² > > > Package: debian-installer-9-netboot-mips64el > > > Severity: normal > > > Tags: d-i > > > > > > Dear Maintainer, > > > > > > I wanted to install Debian Stretch mips64el in QEMU. > > > It seems that the netboot installer can't find any installable kernel for > > > this architecture. > > > There is definitely linux-images for 5kc-malta in the repo and the same > > > install procedure worked for both mips and mipsel. > > > > > > Steps to reproduce: > > > > > > qemu-system-mips64el -M malta -m 256 -cpu MIPS64R2-generic \ > > > -drive file=hda.qcow2,if=virtio,format=qcow2,index=0 \ > > > -kernel vmlinux-4.9.0-3-5kc-malta \ > > > -initrd initrd.gz \ > > > -net user,hostfwd=tcp::2-:22 \ > > > -net nic \ > > > -nographic \ > > > -append "nokaslr" > > > > > > The installer will show the error: No installable kernel was found in the > > > defined APT sources > > > > Some info about this: > > ~ # archdetect > > mips64el/unknown > > > > and “unknown” is why base-installer isn't able to pick the right kernel. > > > > Looking at the hwmap structure in src/system/subarch-mips-linux.c (from > > the libdebian-installer package), where architecture detection happens, > > I initially thought we were missing some MIPS64 pattern there, but that > > doesn't seem the case, as /proc/cpuinfo reports this: > > | system type : MIPS Malta > > … > > | cpu model : MIPS GENERIC QEMU V0.0 FPU V0.0 > > > > (Full contents below for reference.) > > > > and those are the ones which are searched through the hwmap… > > > > I'm not sure how to fix libdebian-installer here, adding debian-mips@ > > and qemu maintainers in copy. > > > > It might make sense to update the bug report title as well at some > > point, since this is likely an issue on QEMU only? > > The current version of subarch-mips-linux.c tries to detect if the CPU > is 32 or 64-bit using the CPU type. It's therefore not prepared for the > "GENERIC QEMU" type returned in /proc/cpuinfo. The code should probably > be modified to use the "isa" field as a fallback if the "cpu model" > field can't be used to determine the flavour. I have implemented that change in libdebian-installer 0.111. This is already available in the daily installer images [1]. Once it reaches testing, we can consider backporting it to stretch. Aurelien [1] https://d-i.debian.org/daily-images/mips64el/daily/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#865425: debian-installer-9-netboot-mips64el: mips64el Malta netboot installer finds no installable kernel
On 2017-06-24 02:12, Cyril Brulebois wrote: > Control: reassign -1 libdebian-installer 0.110 > Control: affects -1 debian-installer-9-netboot-mips64el > > Bruno Bierbaumer <l...@bierbaumer.net> (2017-06-21):² > > Package: debian-installer-9-netboot-mips64el > > Severity: normal > > Tags: d-i > > > > Dear Maintainer, > > > > I wanted to install Debian Stretch mips64el in QEMU. > > It seems that the netboot installer can't find any installable kernel for > > this architecture. > > There is definitely linux-images for 5kc-malta in the repo and the same > > install procedure worked for both mips and mipsel. > > > > Steps to reproduce: > > > > qemu-system-mips64el -M malta -m 256 -cpu MIPS64R2-generic \ > > -drive file=hda.qcow2,if=virtio,format=qcow2,index=0 \ > > -kernel vmlinux-4.9.0-3-5kc-malta \ > > -initrd initrd.gz \ > > -net user,hostfwd=tcp::2-:22 \ > > -net nic \ > > -nographic \ > > -append "nokaslr" > > > > The installer will show the error: No installable kernel was found in the > > defined APT sources > > Some info about this: > ~ # archdetect > mips64el/unknown > > and “unknown” is why base-installer isn't able to pick the right kernel. > > Looking at the hwmap structure in src/system/subarch-mips-linux.c (from > the libdebian-installer package), where architecture detection happens, > I initially thought we were missing some MIPS64 pattern there, but that > doesn't seem the case, as /proc/cpuinfo reports this: > | system type : MIPS Malta > … > | cpu model : MIPS GENERIC QEMU V0.0 FPU V0.0 > > (Full contents below for reference.) > > and those are the ones which are searched through the hwmap… > > I'm not sure how to fix libdebian-installer here, adding debian-mips@ > and qemu maintainers in copy. > > It might make sense to update the bug report title as well at some > point, since this is likely an issue on QEMU only? The current version of subarch-mips-linux.c tries to detect if the CPU is 32 or 64-bit using the CPU type. It's therefore not prepared for the "GENERIC QEMU" type returned in /proc/cpuinfo. The code should probably be modified to use the "isa" field as a fallback if the "cpu model" field can't be used to determine the flavour. That said, the quick workaround is to emulate a real CPU in QEMU. For example you can select the 5KEf CPU which is a MIPS64R2 CPU with FPU. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#865381: unblock: glibc/2.24-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock glibc version 2.24-12 includes an important security fix (CVE-2017-1000366) that should probably fixed asap in buster. It contains other changes which should have no impact on debian-installer. Here is the full changelog: | glibc (2.24-12) unstable; urgency=high | | [ Aurelien Jarno ] | * debian/patches/git-updates.diff: update from upstream stable branch: | - Drop patches/any/cvs-remove-pid-tid-cache-clone.diff (merged upstream). | - Remove wrong assertion on parent PID in fork. | - Fix 64-bit atomics on m68k. Closes: #855692. | * debian/debhelper.in/libc.templates: update the kernel 3.2 warning to | mention that the support limitation comes from Debian and not from | upstream. Closes: #864720. | * debian/rules, debian/rules.d/build.mk: do not capture the build path | when generating glibc-source tarball. Closes: #861183. | * debian/control.in/main: build-depends on gperf. Closes: #847478. | * debian/patches/hppa/submitted-longjmp.diff: new patch from Helge Deller | to fix longjmp on hppa. Closes: #858738. | * debian/sysdeps/mipsel.mk, debian/sysdeps/mips64el.mk: leave the default | GCC ISA level, currently MIPS32R2/MIPS64R2. | * debian/patches/any/local-CVE-2017-1000366-rtld-LD_AUDIT.diff, | debian/patches/any/local-CVE-2017-1000366-rtld-LD_LIBRARY_PATH.diff, | debian/patches/any/local-CVE-2017-1000366-rtld-LD_PRELOAD.diff: add | patches to protect the dynamic linker against stack clashes | (CVE-2017-1000366). | * debian/patches/any/cvs-vectorized-strcspn-guards.diff: patch backported | from upstream to allow usage of strcspn in ld.so. | * debian/patches/any/cvs-hwcap-AT_SECURE.diff: patch backported from | upstream to disable HWCAP for AT_SECURE programs. | | [ John Paul Adrian Glaubitz ] | * debian/sysdeps/sh3.mk: copy from sh4.mk. Closes: #851867. | | -- Aurelien Jarno <aure...@debian.org> Sun, 18 Jun 2017 20:04:53 +0200 Could you therefore please unblock this package: unblock glibc/2.24-12 Thanks, Aurelien -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Installation guide is not updated in some languages
On 2017-06-04 12:05, Samuel Thibault wrote: > Hello DSA, > > Samuel Thibault, on dim. 04 juin 2017 11:54:04 +0200, wrote: > > Some build dependencies are missing on www-master: > > > > fonts-wqy-microhei fonts-vlgothic > > I have attached a debian.org.git patch. > Thanks, I merged the patch and installed the packages on wolkenstein. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#860276: jessie-pu: package glibc/2.19-18+deb8u8
On 2017-04-27 22:58, Aurelien Jarno wrote: > On 2017-04-23 21:18, Adam D. Barratt wrote: > > On Thu, 2017-04-13 at 23:19 +0200, Aurelien Jarno wrote: > > > I would like to upload a new glibc package for the next jessie release. > > > Here is the changelog with some additional comment: > > > > > > * Update from upstream stable branch: > > > - Fix PowerPC sqrt inaccuracy. Closes: #855606. > > > > > > This fixes a regression introduced in glibc 2.19-18+deb8u7, which > > > slightly lower the precision of the sqrt function on PowerPC. This > > > notably causes failures in the postgresql testsuite. This code is > > > already present in stretch/sid. > > > > > > * patches/any/cvs-resolv-internal-qtype.diff: patch from upstream to > > > fix a > > > NULL pointer dereference in libresolv when receiving a T_UNSPEC > > > internal > > > QTYPE (CVE-2015-5180). Closes: #796106. > > > > > > This is a long standing security issue that has been fixed recently. > > > It basically change the value of a constant so that it can't only be > > > generated internally. The patch is already present in stretch/sid. > > > > While I doubt that either of the above should have any noticeable effect > > on the installer, I'd appreciate a d-i ack in any case; CCing. > > As said on IRC, I have been pointed that the second patch actually > breaks the breaks libnss/libnss-dns ABI. This means that the resolver > might not work correctly if all the binaries using libnss are restarted. > The same way there might be an issue on the d-i side if the libc in d-i > and libnss-dns-udeb are out of sync. > > Therefore I'll do a new upload without the patch fixing CVE-2015-5180, > leaving only the PowerPC fix. That should be either today or tomorrow. > > Sorry about this complication. I have just uploaded glibc_2.19-18+deb8u9. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#860276: jessie-pu: package glibc/2.19-18+deb8u8
On 2017-04-23 21:18, Adam D. Barratt wrote: > On Thu, 2017-04-13 at 23:19 +0200, Aurelien Jarno wrote: > > I would like to upload a new glibc package for the next jessie release. > > Here is the changelog with some additional comment: > > > > * Update from upstream stable branch: > > - Fix PowerPC sqrt inaccuracy. Closes: #855606. > > > > This fixes a regression introduced in glibc 2.19-18+deb8u7, which > > slightly lower the precision of the sqrt function on PowerPC. This > > notably causes failures in the postgresql testsuite. This code is > > already present in stretch/sid. > > > > * patches/any/cvs-resolv-internal-qtype.diff: patch from upstream to fix a > > NULL pointer dereference in libresolv when receiving a T_UNSPEC internal > > QTYPE (CVE-2015-5180). Closes: #796106. > > > > This is a long standing security issue that has been fixed recently. > > It basically change the value of a constant so that it can't only be > > generated internally. The patch is already present in stretch/sid. > > While I doubt that either of the above should have any noticeable effect > on the installer, I'd appreciate a d-i ack in any case; CCing. As said on IRC, I have been pointed that the second patch actually breaks the breaks libnss/libnss-dns ABI. This means that the resolver might not work correctly if all the binaries using libnss are restarted. The same way there might be an issue on the d-i side if the libc in d-i and libnss-dns-udeb are out of sync. Therefore I'll do a new upload without the patch fixing CVE-2015-5180, leaving only the PowerPC fix. That should be either today or tomorrow. Sorry about this complication. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#860276: jessie-pu: package glibc/2.19-18+deb8u8
On 2017-04-23 21:58, Adam D. Barratt wrote: > Control: tags -1 + confirmd > > On Sun, 2017-04-23 at 22:52 +0200, Cyril Brulebois wrote: > > Adam D. Barratt <a...@adam-barratt.org.uk> (2017-04-23): > > > While I doubt that either of the above should have any noticeable effect > > > on the installer, I'd appreciate a d-i ack in any case; CCing. > > > > No objections, thanks. > > Thanks for the quick response. > > Aurelien, please feel free to upload. I have just upload it. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#854553: debian-installer: please add fb-modules to loongson-3 installer
On 2017-02-10 09:12, Cyril Brulebois wrote:
> Control: tag -1 patch
>
> Hi,
>
> YunQiang Su <wzss...@gmail.com> (2017-02-08):
> > Package: src:debian-installer
> > Version: 20170127
> >
> > Please add
> > pkg-lists/netboot/mips{64,}el/loongson-3.cfg
> > to debian-installer.
> > The content of them should be:
> > fb-modules-${kernel:Version}
> >
> > As most of Loongson machines uses radeon video card,
> > without them, the installer cannot show anything on screen.
>
> It seems the attached patch indeed results in fb-modules being added
> to the loongson-3 netboot image, according to a grep in
> ./build/tmp/loongson-3_netboot/udeb.list after a build in a sid
> chroot on eller.
>
> Aurelien, do you confirm it's the right way to do it? (I think
> that's the first time I add some flavour configuration, as opposed
> to updating an existing one.)
Yes, this is one way to do it. The other way that is used on some other
architectures is to mark the module as optional (using '?'). Given so
far we only have one flavour having fb-modules, I think both options are
equivalent.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued
On 2017-02-06 00:50, Cyril Brulebois wrote: > Hi, > > Aurelien Jarno <aurel...@aurel32.net> (2017-02-06): > > Well this kind of patch is not mergeable upstream, so we will have to > > keep it forever. > > Or just for stretch given the following points? No, I don't think the freeze is an excuse for fixing bugs the wrong way. > > What would be wrong in using a supported value for the debian-installer > > locale? It should only be a dozen of lines to change. > > A couple of things: > 1. I don't know anything about locales. Understandable. > 2. Nobody moved a finger on this RC bug for months, so I'm not sure we > have anyone else able/willing to fix this. Or maybe people able/willing to fix this were not aware of the bug? > 3. The freeze is here and I'm not too thrilled about changing code/data > I don't have a clue about. These strings only changes LC_IDENTIFICATION, so there is no risk to replace them by "i18n:2012". We have done that for a few additional locales we have in the glibc, including for the C.UTF-8 locale [1]. If you don't want to fix that yourself, I can just do the upload. Aurelien [1] https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=12fabca5b6fccdf47b3f147a40d00f9149ef345a -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued
On 2017-02-04 23:45, Cyril Brulebois wrote: > Hi, > > Lucas Nussbaum <lu...@debian.org> (2016-09-07): > > Source: installation-locale > > Version: 1.6 > > Severity: serious > > Tags: stretch sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20160906 qa-ftbfs > > Justification: FTBFS on amd64 > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build on > > amd64. > > > > Relevant part (hopefully): > > > make[1]: Entering directory '/<>' > > > localedef -i C.UTF-8.in -f "UTF-8" ./C.UTF-8 > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_CTYPE' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_NUMERIC' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_TIME' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_COLLATE' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_MONETARY' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_MESSAGES' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_PAPER' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NAME' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_ADDRESS' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_TELEPHONE' > > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category > > > `LC_IDENTIFICATION' > > > no output file produced because warnings were issued > > > Makefile:4: recipe for target 'C.UTF-8' failed > > > make[1]: *** [C.UTF-8] Error 4 > > I think this is due to the following commit, first released with 2.24: > | commit 900f59f084bfe35cb389bbe0dc464413a1a38e90 > | Author: Mike Frysinger <vap...@gentoo.org> > | Date: Wed Apr 13 18:38:56 2016 -0400 > | > | localedef: check LC_IDENTIFICATION.category values > | > | Currently localedef accepts any value for the category keyword. This > has > | allowed bad values to propagate to the vast majority of locales (~90%). > | Add some logic to only accept a few standards. > > I suppose it makes sense to add a Debian-specific patch to the glibc > package to accept “our extra standard”. I've successfully tested the > attached patch on top of glibc master, even if I had to disable the > testsuite because of this: > | FAIL: rt/tst-shm > | original exit status 1 > | -- > | +-+ > | | Encountered regressions that don't match expected failures. | > | +-+ > | FAIL: rt/tst-shm > | debian/rules.d/build.mk:115: recipe for target > '/home/kibi/hack/glibc/glibc-debian.git/stamp-dir/check_libc' failed > > With upgraded libc packages, installation-locale builds fine again. > > glibc maintainer: if you agree with this proposed path and patch, please > steal this bug report awawy from src:installation-locale. Well this kind of patch is not mergeable upstream, so we will have to keep it forever. What would be wrong in using a supported value for the debian-installer locale? It should only be a dozen of lines to change. Alternatively would it make sense to install the C.UTF-8 locale from libc-bin in libc6-udeb? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#851790: installation-reports: DNS not working
On 2017-01-23 17:30, Wookey wrote: > On 2017-01-19 11:04 +0100, Cyril Brulebois wrote: > > Steve McIntyre <st...@einval.com> (2017-01-19): > > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote: > > > > > > > >The workaround are to make sure the chroots are up-to-date (which should > > > >be the case now on the build daemons). An other alternative would be to > > > >avoid copying a library in mklibs if it is already present in the image. > > > >That might break if some very strict dependencies are used, though > > > >I guess the way the udebs are downloaded, they should always have the > > > >same or a newer version than in the chroot. > > > > > > Thanks for the explanation - it's appreciated! > > > > Yeah, thanks for the confirmation. > > OK. I tested today's image (2017-01-23 04:56) and the install went > through OK, so we are back in sync and this issue is gone for now. It should > probably be retitled to something about library sync/using host libs > and left open until it's fixed propoerly. I have pushed a patch a few days ago that should fix the issue. Well I don't know if it should be considered as a fix or a hack, but at least it looks less a hack than the existing code... The longterm solution is clearly to fully get rid of mklibs. That should wait for after stretch though, as it requires new udebs from some packages and thus some coordination. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#851790: installation-reports: DNS not working
On 2017-01-19 01:53, Cyril Brulebois wrote: > Cyril Brulebois <k...@debian.org> (2017-01-19): > > Summing up things from IRC: > > - in an uptodate sid chroot (both development version and minimal one > >with daily-build script): no DNS issues with the generated mini.iso > >(amd64, tested within stable's kvm on amd64). My image was also > >tested successfully by Steve, so not a setup issue. > > > > - I can reproduce the issue with dailies from 2017-01-18, and from > >2017-01-19 (I picked it in advance during its build on barriere). > > > > - I can reproduce the issue in the above mentioned sid chroot if > >I downgrade these packages to testing's version (-9 → -8): > > sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 > > libc-dev-bin=2.24-8 > > > > - The older set of libc* packages is installed in barriere's current > >amd64 sid chroot, too. > > > > - Steve could only produce broken images when building locally, until > >he upgraded his libc* packages as well. > > And since Steve was wondering how we could release something for Stretch > RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb > (reversioned as -9+hack so that its being dropped under localudebs makes > it take precedence over sid's .udeb) leads to an image that's working > fine. And AFAICT that's the combination we had at the time. > > I suspect the implementation change through the following patch in -9: > glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff Indeed, I haven't done any test, but looking at the code, it shows that the changes assume that libresolv.so.2 and libnss_dns.so.2 stay in sync. > plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is > what is triggering the issue? (Explaining why host's libc .deb have an > impact on the built images.) Indeed this has been done to avoid crashes when libc6-udeb is re-installed at the beginning if the installer process, often causing crashes in case of version mismatch (because the libnss* libraries were in a different package). Now libc6-udeb is unpacked while building the image, but given we still have half a dozen of libraries without the corresponding udeb, mklibs copy them on the image, as well as the dependencies, which presumably includes libresolv.so.2. > It's been a while since I last looked at/understood mklibs stuff though, > feel free to fix my suspicions/conclusions. The long term solution is to package all the libraries into udeb packages. That way we can simply get rid of the mklibs pass. The workaround are to make sure the chroots are up-to-date (which should be the case now on the build daemons). An other alternative would be to avoid copying a library in mklibs if it is already present in the image. That might break if some very strict dependencies are used, though I guess the way the udebs are downloaded, they should always have the same or a newer version than in the chroot. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#836525: Bug#836446: libc6-dev: depends on linux-libc-dev:$arch, breaking debootstrap
On 2016-09-03 20:54, Cyril Brulebois wrote: > Aurelien Jarno <aurel...@aurel32.net> (2016-09-03): > > clone 836446 -1 > > reassign -1 debootstrap > > retitle -1 debootstrap: doesn't support arch-qualified dependencies > > affects -1 libc6-dev > > thanks > > Thanks for this. > > > On 2016-09-03 11:28, Sven Joachim wrote: > > > Package: libc6-dev > > > Version: 2.24-1 > > > Severity: important > > > > > > The fix for bug #834706 has the side effect that libc6-dev now depends > > > on linux-libc-dev:$arch : > > > > > > , > > > | $ apt-cache show libc6-dev | grep ^Depends > > > | Depends: libc6 (= 2.24-1), libc-dev-bin (= 2.24-1), linux-libc-dev:i386 > > > (>= 4.6.4-1) > > > ` > > > > > > While dpkg and apt obviously don't have a problem with that, debootstrap > > > cannot cope with it, and "debootstrap --variant=buildd" fails to even > > > download linux-libc-dev. See the attached log. > > > > That's definitely a bug in debootstrap. In the future it's more and more > > likely that we'll have arch-qualified dependencies in the bases packages, > > so this has to be fixed. I am therefore cloning and reassigning the bug. > > Do you plan to implement a workaround in glibc for now, or should this bug > report (on the debootstrap side) be raised to RC and fixed before we can > think of a new d-i release? (I have no such plan right now, but it might > be nice not to wait too much once linux has migrated). I have just committed a workaround in glibc, I'll upload it in the next days. It would be nice to have this bug fixed for Stretch though, so that we can use arch-qualified dependencies in Buster. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#836446: libc6-dev: depends on linux-libc-dev:$arch, breaking debootstrap
clone 836446 -1 reassign -1 debootstrap retitle -1 debootstrap: doesn't support arch-qualified dependencies affects -1 libc6-dev thanks On 2016-09-03 11:28, Sven Joachim wrote: > Package: libc6-dev > Version: 2.24-1 > Severity: important > > The fix for bug #834706 has the side effect that libc6-dev now depends > on linux-libc-dev:$arch : > > , > | $ apt-cache show libc6-dev | grep ^Depends > | Depends: libc6 (= 2.24-1), libc-dev-bin (= 2.24-1), linux-libc-dev:i386 (>= > 4.6.4-1) > ` > > While dpkg and apt obviously don't have a problem with that, debootstrap > cannot cope with it, and "debootstrap --variant=buildd" fails to even > download linux-libc-dev. See the attached log. That's definitely a bug in debootstrap. In the future it's more and more likely that we'll have arch-qualified dependencies in the bases packages, so this has to be fixed. I am therefore cloning and reassigning the bug. > Please clone/reassign to debootstrap as you see fit, but in any case it > would be nice to remove the extraneous arch qualification in the > dependency. Note that arch qualification is automatically added by dpkg-query, so we'll have to mangle the output. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#826173: Debian Testing/Unstable MIPS Installer Kernel Panic
On 2016-06-03 19:03, Ben Hutchings wrote: > Control: reassign -1 debian-installer 20160516+b1 > > On Fri, 2016-06-03 at 08:48 +, Mattia Rizzolo wrote: > > control: reassign -1 src:linux 4.5.4-1 > > > > On Thu, Jun 02, 2016 at 07:13:04PM -0400, Mike wrote: > > > Package: kernel > > > > this is not a valid package name. > > > > > Version: Testing > > > > and this is not a valid version > > > > > > > > I am working on installing Debian under a QEMU MIPS emulator. I was able > > > to > > > get the Debian Stable branch to install and run properly using this: > > > > > > http://ftp.de.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/ > > > > > > However, when I attempt to use unstable or testing, I receive a kernel > > > panic immediately on boot for install. I cannot really give a package name > > > because it appears there's a problem in the kernel or init somewhere. > > > > > > http://ftp.de.debian.org/debian/dists/unstable/main/installer-mips/current/images/malta/netboot/ > > > > > > The error I get it as follows: > > > [2.463767] Kernel panic - not syncing: Attempted to kill init! > > > exitcode=0x0004 > > > [2.463767] > > > [2.464725] ---[ end Kernel panic - not syncing: Attempted to kill > > > init! > > > exitcode=0x0004 > > That usually means something is wrong with the initrd. So reassigning > to the installer. It would be interested to know which QEMU command you used to start this image. Since the switch to GCC 5, the mips architecture requires a R2 CPU. QEMU defaults emulating a R2 CPU in 32-bit mode, but a R1 CPU in 64-bit mode. In the later case try to pass "-cpu 5KEf" to QEMU. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#824880: RM: partitioner -- ROM; obsolete
Package: ftp.debian.org Severity: normal All the (sub)-architectures which required the partitioner package in debian-installer are not supported anymore. Therefore this package is not used anymore during the installation process, though it get downloaded anyway.
Re: Merging libnss-dns-udeb and libnss-files-udeb back into libc6-udeb
On 2016-03-13 02:26, Aurelien Jarno wrote: > Hi, > > For historical reason, disk space on boot floppies, the libnss_dns.so.2 > and libnss_files.so.2 libraries are in separate udeb packages, namely > libnss-dns-udeb and libnss-files-udeb. This is not the case of the deb > package, where everything is in the libc6 package. > > In practice these libraries are really small by nowadays standards (22kB > and 47kB uncompressed), and moreover libnss-dns-udeb is already included > in all images. In addition these libraries are tightly coupled to the > libresolv library which is in libc6-udeb. The recent CVE-2015-7547 has > shown that, and Ubuntu hit a bug by having the two out of sync in their > installer [1]. We would have got the same if debian-installer was pulling > its udeb from debian-security. Thinking a bit more about that we'll have the same problem. Our 8.3 debian-installer images will likely break when 8.4 is released. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Merging libnss-dns-udeb and libnss-files-udeb back into libc6-udeb
Hi, For historical reason, disk space on boot floppies, the libnss_dns.so.2 and libnss_files.so.2 libraries are in separate udeb packages, namely libnss-dns-udeb and libnss-files-udeb. This is not the case of the deb package, where everything is in the libc6 package. In practice these libraries are really small by nowadays standards (22kB and 47kB uncompressed), and moreover libnss-dns-udeb is already included in all images. In addition these libraries are tightly coupled to the libresolv library which is in libc6-udeb. The recent CVE-2015-7547 has shown that, and Ubuntu hit a bug by having the two out of sync in their installer [1]. We would have got the same if debian-installer was pulling its udeb from debian-security. That's why I would like to propose to merge back libnss-dns-udeb and libnss-files-udeb back into libc6-udeb. The idea is to make libc6-udeb to provide them, it seems udpkg supports that. The only packages having a dependency on libnss-files-udeb are espeakup-udeb, rdnssd-udeb, open-iscsi and openssh-client-udeb, and none of them has a versioned dependency. None of the udeb have a dependency on libnss-files-udeb. Any opinion on that? Thanks, Aurelien [1] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1546459 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
On 2016-02-02 17:51, Wookey wrote: > > > what do you mean by that? Source packages like cross-gcc-4.9-armhf > > *do* have cross-arch build-deps. Were you talking about missing > > support in britney to properly transition source packages with > > cross-arch build-deps? Is there a bug about this open somewhere? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770925 > > Stalled since debconf. Although that's actually the wanna-build code, > rather than britney. We've been waiting for w-b to be implemented > before we could sensibly worry about britney. > > But time is getting short if we are to have this working this release. > > Aurelien - can we help move this along? Sorry about that. I'll try to work again on it. 3 out of 5 patches have already been merged, the two others has issues and need to be reworked. It might help if you or someone else can provide updated patches addressing the issues. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#810408: discover: please switch to libusb 1.0
Package: discover Version: 2.1.2-7 Severity: wishlist Dear Maintainer, discover has a build-depends on libusb-dev. A few years ago upstream has released a new major version libusb 1.0 with a different API which aims to fix design deficiencies with USB 2.0 and 3.0 in mind. The old libusb 0.1 package is not supported upstream anymore and should be considered deprecated. If discover supports the new libusb 1.0 library, please consider switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not please inform upstream that porting the software to the new API is recommended. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Dropping CDs entirely?! (was: Stretch Alpha 3 images)
On 2015-09-06 14:25, Thomas Schmitt wrote: > Hi, > > Aurelien Jarno wrote: > > I have no idea if they support booting over a > > CD-ROM or USB image. Does someone known if we can do so on a Loongson 3 > > or Octeon machine? > > Maybe one should ask grub-de...@gnu.org mailing list or > Vladimir Serbinenko directly. GRUB only works on the Loongson 2 machines, not the Loongson 3 ones. Given we are going to drop the Loongson 2 support soon, there is no point trying to get it working for CD-ROM booting. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Dropping CDs entirely?! (was: Stretch Alpha 3 images)
On 2015-09-03 23:03, Steve McIntyre wrote: > On Thu, Sep 03, 2015 at 05:21:17PM +0200, Cyril Brulebois wrote: > >Steve McIntyre <st...@einval.com> (2015-09-03): > >> All looked OK, *except* mips failures: > >> > >> install: cannot stat > >> '/org/cdbuilder.debian.org/src/ftp/debian/dists/stretch/main/installer-mips/current/images/r4k-ip22/cdrom-boot.img': > >> No such file or directory > >> > >> Looks like we need some fixes there... > > > >I suppose mipsel also fails? > > > > http://anonscm.debian.org/cgit/d-i/debian-installer.git/diff/?id=1b92647295e > 33ff66a46a5665e7f293d04fd2e19 > > You might think so, but no - the builds all worked for mipsel. > > >Changelog says: > >| [ Aurelien Jarno ] > >| * Drop r4k-ip22, r5k-ip32 and sb1-bcm91250a images on mips. > >| * Drop sb1-bcm91250a images on mipsel. > > > >But the diff has an extra miniiso removal: > > - The following subarchs got removed on mips: > > r4k-ip22 r5k-ip32 sb1-bcm91250a miniiso The miniiso was only containing boot support for r4k-ip22 which has been dropped. > Right. That means that we'll end up with no bootable options on mips > images. CCing debian-mips for guidance there. > Most of the flavours requires to pass the d-i kernel/initrd to uboot or similar bootloader to run d-i. The flavours we dropped were the only one with CD-ROM support. I guess however it still makes sense to continue producing the CD-ROM images, but without making them bootable. In the long term, we might want to add bootable support for the remaining flavours, but I have no idea if they support booting over a CD-ROM or USB image. Does someone known if we can do so on a Loongson 3 or Octeon machine? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#746967: buildd.debian.org: d-i daily builds happen with unsigned code from alioth
On 2015-07-24 19:49, Cyril Brulebois wrote: Hi Aurélien, Aurelien Jarno aurel...@aurel32.net (2015-03-18): With the help of Hector Oron, we have been able to setup this on the porterbox of 4 architectures: arm64, armel, armhf and mips. This has been done by allowing the d-i role account on the porterboxes. As a nice side effect, this mean that d-i people can now do/fix the setup themselves without having to go through the buildd team. The code used is available in the porterbox branch of the di-autobuild git. Note that the chroots on the porterbox are created in a very similar way than on the newer buildds (it's even done by the same script IIRC), so the problems should be similar. For example both were affected by bug#775136. Is there any doc on how to create the needed bits on a porterbox to add d-i autobuilding? I suspect anyone in the d-i group should be able to do so (plus the ssh key dance on dillon afterwards)? I've pinged Hector but apparently he didn't have the procedure in mind. :) It'd be nice to have that (1) for later uses of course, and (2) so that I can set up d-i autobuilding on abel again since it got reinstalled recently. I don't know if you can consider that as a documentation, but there is a procedure in the README file in the git [1]. Be sure to select the proper branch though (currently 'master' for the code for the buildds and 'porterbox' for the code for the porterboxes). Aurelien [1] https://buildd.debian.org/git/di-autobuild.git -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: debian-installer: dropping library reduction pass?
Hi, Thanks all for the feedback. On 2015-05-10 23:37, Cyril Brulebois wrote: Aurelien Jarno aurel...@aurel32.net (2015-05-10): Any comment or opinion? I'm pretty sure you know exotic archs better than I do, so if arm*, mips* etc. are not going to take a direct hit with this change, and if mitigating it through better compression is OK, let's implement your proposed changes. After this positive answer, I have done more checks and found the following possible issues: - After this change the DNS-323 (and thus CH3SNAS) will only have 500kB left for a future initrd size increase. If we go over the limit we can switch to xz compression. - The sparc TFTP netboot image seems to be limited to 10MB (according to a comment in the sources) and is already using xz compression to stay below this limit. That said the built image is bigger than this size for 1.5 years (12MB currently) and it seems nobody realised or complained. I am therefore going to replace mklibs by mklibs-copy in git. It's a small change that can be easily reverted if needed. In a few weeks if nothing is reported as broken, I'll start removing mklibs completely. It might take some time to remove it fully as it seems some hacks are well hidden. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
debian-installer: dropping library reduction pass?
Hi, debian-installer uses a library reduction pass (mklibs) in order to reduce initrd's size. This is needed to: - fit the initrd on the boot media (originally 1.44MB floppy disk) - reduce the memory consumption as the uncompressed initrd has to fit in memory during the installation process This has some drawbacks: - packages used in d-i have to ship a -pic package, in the best case adding some code to debian/rules, in the worst case needing to patch upstream code and/or do another build pass. - a d-i image built with a version of the libc crashes if the udebs on the mirror have a newer version - some additional code and workarounds in d-i Computers have evolved since it was designed, they now accept bigger boot media and have more memory. I think we reached a point were we can just drop this pass. In any case if the size on the boot media is something critical we should probably use another compression method like xz, which is now supported by the kernel. I have done some tests with the amd64 flavour, here are the results. Note that the tests are a few months old (I didn't want to start such a discussion in the middle of the freeze), so the various size might be slightly different, but it should not change the conclusions. flavour | mklibs|mklibs-copy | | initrd| initrd.gz | initrd.xz | initrd| initrd.gz | initrd.xz | -+---+---+---+---+---+---+ netboot | 45172 | 14720 | 10672 | 47660 | 15868 | 11264 | netboot/gtk | 94532 | 33536 | 23484 | 97072 | 34616 | 23940 | hd-media | 25548 | 8284 | 6128 | 27944 | 9392 | 6732 | hd-media/gtk | 74656 | 27024 | 18924 | 77092 | 28052 | 19380 | cdrom| 18708 | 6212 | 4624 | 21104 | 7320 | 5228 | cdrom/gtk| 67676 | 24896 | 17380 | 70108 | 25924 | 17836 | The maximum gain is for the cdrom flavour, with 11.4% on the memory consumption and 15.1% on the initrd size. The minimum gain is for the netboot/gtk flavour, with 2.6% on the memory consumption and 3.1% on the initrd size. If we really need to get the smallest possible initrd on some architectures, I would suggest to switch it to xz compression, as the gain is between 25 and 30% depending on the flavour. Any comment or opinion? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Help with the arm64 and ppc64el installation-guides needed
On 2015-04-12 20:22, Samuel Thibault wrote: Hello, Mmm, the following looks like a useless addition: Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit : Index: en/boot-installer/powerpc.xml === --- en/boot-installer/powerpc.xml (Revision 69729) +++ en/boot-installer/powerpc.xml (Arbeitskopie) @@ -283,3 +283,41 @@ /para /sect2 + + sect2 arch=ppc64el titleBooting a ppc64el machine/title +para + +How to boot a ppc64el machine: + +/para + + sect3 titlePetitboot/title +para + +Petitboot is a platform independent bootloader based on the Linux kexec. +Petitboot supports loading kernel, initrd and device tree files from +any Linux mountable filesystem, plus can load files from the network +using the FTP, SFTP, TFTP, NFS, HTTP and HTTPS protocols. Petitboot can +boot any operating system that includes kexec boot support. + +/parapara + +Petitboot looks for bootloader configuration files on mountable devices +in the system, and can also be configured to use boot information from a +DHCP server. + +/para + /sect3 + +!-- comment this out for now, since there is no content + sect3 titleBoot parameters/title +para +Boot parameters for ppc64el + +FIXME: add some useful content here + +/para + /sect3 +-- + + /sect2 Since petitboot runs inside a running linux kernel, that only shifts the problem of booting that linux kernel :) Petitboot is the default bootloader on this machine when configured to run Linux. It's the interface the user see when powering up the machine. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150412200844.go4...@aurel32.net
Re: Bug#781075: sbuild: Breaks d-i build by assuming it is a deb
control: tag -1 + pending On 2015-03-24 07:18, Cyril Brulebois wrote: Hi, Niels Thykier ni...@thykier.net (2015-03-24): Source: sbuild Version: 0.65.1-1 Severity: grave Tags: d-i User: release.debian@packages.debian.org Usertags: jessie-is-blocker Hi, The debian-installer currently FTBFS on various architectures, but the build itself is followed by I: Built successfully. Then there is a message later saying (something to the extend of): dpkg-deb: error: `/«CHROOT»/«BUILDDIR»/debian-installer-images_20150324_arm64.tar.gz' Which is entirely correct as the debian-installer is a tar.gz file. This happens on both the Wheezy sbuild and the Jessie sbuild. But only the Jessie version seems to be flagging the build as failed! We believe it is related the commit [684c57b]. (Thanks for opening the bug report and letting -boot@ know through x-d-cc as requested on IRC.) Since debian-installer-images is an arch-indep “package name”, I guess an easy way out would be to special-case it and not perform dpkg calls on it in lib/Sbuild/Build.pm's build sub? (Even fancier, letting tar xf do the work with that particular beast but that's another story, and I'm afraid I'm not patching + testing sbuild right now.) I have just committed a patch to fix that on the master branch [1]. There have been other changes committed to this branch, so we should decide if they are jessie material or not. I have added Ansgar in Cc for that. Aurelien [1] https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=7ec60100ee315e130e8771d4268debc3eaeff9af -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Bug#746967: buildd.debian.org: d-i daily builds happen with unsigned code from alioth
On 2014-12-28 13:34, Philipp Kern wrote: On Thu, Sep 11, 2014 at 10:49:06PM +0200, Aurelien Jarno wrote: If we choose this solution, here is a quick and dirty patch against di-autobuild to do that. It's basically changing the hardcoded paths and call to schroot. There is probably more fixes/cleanup to do, but it's just a proof of concept to show this solution works without additional privilege on the porterboxes. Note that I haven't tried the upload part, but I guess it's just a matter of having the right packages installed (if not already the case). We probably want to have a dedicated d-i account for that on the porterbox. Also we have only one amd64/i386 porterbox, and the current script doesn't support that, but that should be easy to test. If this solution is chosen, I'll be happy to continue working on this script as time permits. I'm ok with this approach for the time being. Obviously building on real infrastructure the way other stuff is built would be even better. (For With the help of Hector Oron, we have been able to setup this on the porterbox of 4 architectures: arm64, armel, armhf and mips. This has been done by allowing the d-i role account on the porterboxes. As a nice side effect, this mean that d-i people can now do/fix the setup themselves without having to go through the buildd team. The code used is available in the porterbox branch of the di-autobuild git. Note that the chroots on the porterbox are created in a very similar way than on the newer buildds (it's even done by the same script IIRC), so the problems should be similar. For example both were affected by bug#775136. instance binNMUing the unstable d-i into experimental every day, or similar.) BinNMUing the unstable d-i into experimental actually doesn't really work as it doesn't take into account the changes done on the debian-installer package itself. It is not uploaded that often, so it's important to have daily-builds to test it. Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: live-installer_47_s390x.changes ACCEPTED into unstable
On 2015-03-09 09:18, Cyril Brulebois wrote: Debian FTP Masters ftpmas...@ftp-master.debian.org (2015-03-08): Mapping sid to unstable. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 08 Mar 2015 11:27:38 +0100 Source: live-installer Binary: live-installer Architecture: s390x Version: 47 Distribution: sid Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Christian Perrier bubu...@debian.org Description: live-installer - Install the system (udeb) Changes: live-installer (47) unstable; urgency=low . [ Updated translations ] * Danish (da.po) by Joe Hansen Checksums-Sha1: 80ce92a0bf45fc2a279d58bdeab58baaa60fea04 36678 live-installer_47_s390x.udeb Checksums-Sha256: 9a741d63f904e6e38c5fd6a74906953e81b67ce91000fc4d3a24e68ca93a7c73 36678 live-installer_47_s390x.udeb Files: f2a55df27cf9a8f8e335c0992bc3be32 36678 debian-installer optional live-installer_47_s390x.udeb -BEGIN PGP SIGNATURE- Hi, this looks like a misconfigured buildd? Yes, looks like I did a mistake when updating the configuration following the upgrade of the buildd to jessie. That should be fixed now, sorry about that. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: ppc64el d-i directory empty
On 2015-02-24 10:31, Fernando Seiti Furusato wrote: Hello, The d-i daily images directory for ppc64el seems to be empty: http://d-i.debian.org/daily-images/ppc64el/ Do you know if there is any problem? The ppc64el build daemons are now running jessie and unfortunately the script which produces the debian-installer daily builds doesn't work for it. It's not specific to ppc64el, arm64 is also affected. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150225205725.gd4...@aurel32.net
Re: ppc64el d-i directory empty
On 2015-02-25 22:56, Holger Levsen wrote: Hi, On Mittwoch, 25. Februar 2015, Aurelien Jarno wrote: The ppc64el build daemons are now running jessie and unfortunately the script which produces the debian-installer daily builds doesn't work for it. run the script in a schroot? This is not something possible on a buildd were we have limited control on what can be done. Same for a porterbox where it is more or less planned to move the daily d-i build process. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Bug#775136: sources.list.udeb generator doesn't consider Dir::Etc::SourceList
Package: debian-installer Version: 20150107 Severity: important build daemons traditionally use the Dir::Etc::SourceList apt configuration option in order to specify a different sources.list file. debian-installer sources.list.udeb generator doesn't consider this option, which causes a FTBFS on some build daemons without /etc/apt/sources.list or with an outdated one. This is reproducible on an installation using only the standard /etc/apt/sources.list: # echo 'Dir::Etc::SourceList sources.list2;' /etc/apt/apt.conf.d/sources.conf # mv /etc/apt/sources.list /etc/apt/sources.list2 # apt-get -q -q update ; echo $? 0 So it means apt is able to work correctly in this situation. Unfortunately the debian-installer sources.list.udeb generator doesn't consider Dir::Etc::SourceList, leading to the following source file: | make[2]: Entering directory '/home/aurel32/debian-installer-20150107/build' | Using generated sources.list.udeb: |deb [trusted=yes] copy:/home/aurel32/debian-installer-20150107/build/ localudebs/ | make[9]: 'sources.list.udeb' is up to date. | Ign copy: localudebs/ InRelease | Ign copy: localudebs/ Release.gpg | Ign copy: localudebs/ Release | Get:1 copy: localudebs/ Packages [20 B] | Ign copy: localudebs/ Translation-en | Fetched 20 B in 0s (1052 B/s) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150111211445.30137.52963.report...@weber.rr44.fr
Re: d-i ftbfs on ppc64el-unicamp-01
On 2015-01-07 09:48, Aurelien Jarno wrote: On 2015-01-07 05:19, Cyril Brulebois wrote: Hi, d-i/ppc64el FTBFS on ppc64el-unicamp-01, probably due to a failure to get network access during the build: https://buildd.debian.org/status/fetch.php?pkg=debian-installerarch=ppc64elver=20150107stamp=1420603066 Please advise. It looks like the problem is that the sources.list is not generated correctly by the d-i script. This buildd uses weekly generated chroots by a DSA script, and I guess something is missing there. If it is urgent, we can build it on the non-DSAed non-autosigned buildd, otherwise I think i'll have time to have a deeper look tonight. The buildd chroots use a different configuration file for the sources.list, namely /etc/apt/sources.buildd.list. This file is therefore specified in /etc/apt.conf with the following line: Dir::Etc::SourceList sources.buildd.list; It seems that d-i sources.list generator doesn't take the configuration files into account. It works by chance on other buildds (but might use the wrong mirror if it has been modified since the chroot has been created), and doesn't work on automatically generated chroots as this file simply doesn't exist. I therefore guess this issue has to be fixed on the d-i side. However we can build this version on the non autosigned buildd, so that you don't have to do another upload just for that. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: d-i ftbfs on ppc64el-unicamp-01
On 2015-01-07 05:19, Cyril Brulebois wrote: Hi, d-i/ppc64el FTBFS on ppc64el-unicamp-01, probably due to a failure to get network access during the build: https://buildd.debian.org/status/fetch.php?pkg=debian-installerarch=ppc64elver=20150107stamp=1420603066 Please advise. It looks like the problem is that the sources.list is not generated correctly by the d-i script. This buildd uses weekly generated chroots by a DSA script, and I guess something is missing there. If it is urgent, we can build it on the non-DSAed non-autosigned buildd, otherwise I think i'll have time to have a deeper look tonight. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: What's up with d-i daily builds?
On Mon, Dec 22, 2014 at 01:32:12PM +0100, Cyril Brulebois wrote: Hi, the last d-i daily build on ppc64el seems to have happened on Dec 12. Can you please have a look and check whether something needs fixing there? The old build daemon has been replaced by a DSAed machine running Jessie. This new setup doesn't allow setting-up d-i builds there. It might be a good idea to really make progress on bug#746967 so that we can setup something. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141222130939.gn32...@hall.aurel32.net
Re: What's up with d-i daily builds?
On Mon, Dec 22, 2014 at 02:29:00PM +0100, Holger Levsen wrote: On Montag, 22. Dezember 2014, Aurelien Jarno wrote: The old build daemon has been replaced by a DSAed machine running Jessie. This new setup doesn't allow setting-up d-i builds there. uhm, why? is DSA aware of this? Yes. It's not possible to do a git checkout due to the SSL certificates not being available. Peter Palfrader told me he already sent a mail to debian-devel about that. ppc64el must have d-i builds, else it will either delay jessie or not be released with jessie. This will be the case of all buildds once upgraded to Jessie and hence all architectures, unless the bug is solved. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141222133801.go32...@hall.aurel32.net
Re: What's up with d-i daily builds?
On Mon, Dec 22, 2014 at 02:38:01PM +0100, Aurelien Jarno wrote: On Mon, Dec 22, 2014 at 02:29:00PM +0100, Holger Levsen wrote: On Montag, 22. Dezember 2014, Aurelien Jarno wrote: The old build daemon has been replaced by a DSAed machine running Jessie. This new setup doesn't allow setting-up d-i builds there. uhm, why? is DSA aware of this? Yes. It's not possible to do a git checkout due to the SSL certificates not being available. Peter Palfrader told me he already sent a mail to debian-devel about that. More details about the issue there: https://lists.debian.org/debian-devel/2014/11/msg01354.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141222135535.gp32...@hall.aurel32.net
Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
On Wed, Nov 12, 2014 at 10:53:51AM +0300, Michael Tokarev wrote: 12.11.2014 04:27, Diederik de Haas wrote: Package: busybox-static Version: 1:1.22.0-11 Severity: important This is basically the same error as with bug #757941, but it was reassigned to glibc and fixed there. As Aurelien Jarno correctly stated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757941#120 it was indeed fixed with version 1.22.0-9+b1, which I have verified. However, I just received version 1.22.0-11 of busybox-static and now it fails again: Now this is funny. Should I add a versioned build-dependency against libc6-dev perhaps? Because, according to the build log of amd64 (that's your arch), the package has been built against glibc (= 2.19-11) -- grep for Built-Using in the build log: https://buildd.debian.org/status/fetch.php?pkg=busyboxarch=amd64ver=1%3A1.22.0-11stamp=1415729242 now I wonder how the -9+b1 version has been built against fixed glibc-2.19-12 while at least one of amd64 buildds have -11 ? I scheduled the previous binNMUs using --extra-depends, thus forcing the libc version. A quick analysis shows that hurd-i386, kfreebsd-amd64, kfreebsd-i386, mips and ppc64el built busybox against a fixed glibc version, and that amd64, arm64, armel, armhf, i386, mipsel, powerpc, s390x and sparc built it against a broken version. At least the built-using field is great to find which packages are broken. And there's nothing I can do about this on busybox side -- except, again, adding a versioned build-dep. I'll schedule binNMUs for now, but it might be a good idea to add a versioned build-dep so that it doesn't happen again. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112170528.gg...@hall.aurel32.net
Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote: 12.11.2014 21:05, Aurelien Jarno wrote: [] And there's nothing I can do about this on busybox side -- except, again, adding a versioned build-dep. I'll schedule binNMUs for now, but it might be a good idea to add a versioned build-dep so that it doesn't happen again. Please don't. I want to fix it for real today, one way or another. Oops, that's already done, I did it just after sending the previous email. And this brings an interesting question: how to add this build-dep? I tried adding build-depends: libc-bin (2.19-12~) | libc-bin (2.19) but this one just pulls the libc-bin package not libc6 and libc6-dev. Yes, libc-bin does not have a strict dependency on the other libc packages, it only depends on the major version. Ofcourse I thouht about using libc6[-dev] in this context, but immediately come across the fact that on different arches, libc is named differently (libc6.1, libc0.3 etc). Should I list them all in the build-deps? If yes, what's the complete list? It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | libc0.1-dev ( 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any] (I tried to keep it buildable on older glibc too; but it's ofcourse possible to add a build-conflicts: libc6 (2.19-12), libc6.1 (2.19-12) etc -- this is easier than listing two versions for each) Another thought is to add a build-time test that the thing actually work (eg, busybox-static ping localhost or something, or a small separate program to be run before real build) -- with this in mind, it might not be even required to add a build-dep, -- build will just fail with a friendly message telling to fix glibc... Yes that might also be a good idea, and also getting that test upstream given that the libc bug is not yet fixed upstream. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112194553.gv24...@hall.aurel32.net
Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
On Thu, Nov 13, 2014 at 12:03:39AM +0300, Michael Tokarev wrote:
12.11.2014 22:45, Aurelien Jarno wrote:
On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote:
Should I list them all in the build-deps? If yes, what's the complete
list?
It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] |
libc0.1-dev ( 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any]
Please double-check:
Build-Depends:
# glibc static-nss #754813, 2.19..2.19-11, -12 is ok
libc6-dev ( 2.19-12~) [linux-any !alpha !ia64] |
libc6-dev ( 2.19) [linux-any !alpha !ia64] |
libc6.1-dev ( 2.19-12~) [alpha ia64] |
libc6.1-dev ( 2.19) [alpha ia64] |
libc0.1-dev ( 2.19-12~) [kfreebsd-any] |
libc0.1-dev ( 2.19) [kfreebsd-any] |
libc0.3-dev ( 2.19-12~) [hurd-any] |
libc0.3-dev ( 2.19) [hurd-any],
That looks lok.
Since this is all alternatives, is it really necessary to list the [arch]
names? I mean, just list of pkgs with versions should be enough I think,
each arch will pick the right name, no?
sbuild only considers the first alternative, so it won't work.
Alternatively I think I have found a better solution.
libc{0.1,0.3,6,6.1}-dev strictly depends on libc-dev-bin, so if you
build-depends on libc-dev-bin ( 2.19-12~) | libc-dev-bin ( 2.19),
the libcX-dev package will also get the same version.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112220123.gw24...@hall.aurel32.net
Bug#768876: busybox-static is statically linked against libc6, but doesn't have a Built-Using: field
Package: busybox Version: 1:1.22.0-9 Severity: serious Justification: Policy 7.8 busybox-static is statically linked against libc6. According to Debian Policy §7.8 such a package MUST list the glibc source package in the Built-Using: field. Note: While this is a serious policy violation and given Jessie is already frozen, it has been agreed with the release team that the bug does not need to be fixed for Jessie. That's why the jessie-ignore tag is added, this makes this bug non RC. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109205014.9038.83032.report...@weber.rr44.fr
Re: Time for Jessie Beta 2?
On Mon, Sep 29, 2014 at 01:00:01AM +0200, Cyril Brulebois wrote: Since the kernel is now a candidate for migration, I'll probably start urgenting more packages into testing during the weekend (all l10n-only updates, for a start), try to figure out which packages to additionally migrate, and freeze udeb-producing packages. Besides partman-efi (uploaded today to drop armhf), brltty (stuck because of llvm/clang issues), and the CJK issue (#762057), I don't think I'm going to merge more things, so I've just frozen udebs. It might be interesting to also unblock netcfg 1.122 if we want to have a working d-i beta2 on s390x (and maybe on other architectures). The recent uploads have been built with gcc-4.9 instead of gcc-4.8, which triggers a bug that have been hidden for years. I have fixed this bug in 1.122. Also not fully necessary, but it might be a good idea to let util-linux to migrate to testing so that we can do testing installations on ppc64el. There is no code change, just one less file shipped on this architecture so the diff is quite small. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: decrufting hw-detect?
On Mon, Sep 29, 2014 at 10:20:52PM +0200, Cyril Brulebois wrote: Aurelien Jarno aurel...@aurel32.net (2014-09-29): Hi all, hw-detect is a package missing in testing for arm64 and ppc64el. It is needed if we want to at least imagine running debian-installer with testing udebs on these architectures. It missed twice the migration to testing due to a new upload, and it seems it won't migrate automatically as it needs a manual decruft from the ftpmasters. The automated cruft script seems to be confused by the old new archdetect-udeb, with some additional provides: | * source package hw-detect version 1.104 no longer builds | binary package(s): archdetect-udeb | on amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc | - suggested command: | dak rm -m [auto-cruft] NBS (no longer built by hw-detect) -s unstable -a amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc -p -R -b archdetect-udeb | - broken Depends: | base-installer: bootstrap-base | hw-detect: hw-detect | live-installer: live-installer | partman-base: partman-base | prep-installer: prep-installer [powerpc] | quik-installer: quik-installer [powerpc] | silo-installer: silo-installer [sparc] | yaboot-installer: yaboot-installer [powerpc] Should we ask the ftpmasters for archdetect-udeb to be removed? I think I did that after having uploaded the revert, but I might be misremembering. Either way, I felt uncomfortable with the amount of changes/the diff while reviewing udebs this weekend, so I decided to skip it. Feel free to ask for a decruft, I can then get it into testing so that new archs get into a better shape, even if that introduces some risks for other archs. I have asked for decruft, and the decruft has been done. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140930192956.gl3...@hall.aurel32.net
decrufting hw-detect?
Hi all, hw-detect is a package missing in testing for arm64 and ppc64el. It is needed if we want to at least imagine running debian-installer with testing udebs on these architectures. It missed twice the migration to testing due to a new upload, and it seems it won't migrate automatically as it needs a manual decruft from the ftpmasters. The automated cruft script seems to be confused by the old new archdetect-udeb, with some additional provides: | * source package hw-detect version 1.104 no longer builds | binary package(s): archdetect-udeb | on amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc | - suggested command: | dak rm -m [auto-cruft] NBS (no longer built by hw-detect) -s unstable -a amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc -p -R -b archdetect-udeb | - broken Depends: | base-installer: bootstrap-base | hw-detect: hw-detect | live-installer: live-installer | partman-base: partman-base | prep-installer: prep-installer [powerpc] | quik-installer: quik-installer [powerpc] | silo-installer: silo-installer [sparc] | yaboot-installer: yaboot-installer [powerpc] Should we ask the ftpmasters for archdetect-udeb to be removed? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929201210.ge3...@hall.aurel32.net
Bug#754093: debian-installer: ppc64el support
Hi, On Mon, Jul 07, 2014 at 03:53:47PM +0200, Frederic Bonnard wrote: Package: debian-installer Severity: normal Tags: d-i patch User: debian-powe...@lists.debian.org Usertags: ppc64el Dear Maintainer, hi, here is a patch from Ubuntu to add support of ppc64el. I just changed grub-cdrom.cfg to remove any d-i option on the kernel command line. I added virtio-modules to support VMs with virtio which is good to have for development. I have merge the part of the patch which doesn't use grub, as it is not yet available. This will allow debian-installer to be built for the daily images [1] that I'll setup for ppc64el in the next days. I'll merge the other parts when grub is available. I also have done some small changes to the packages list, and set the DEBIAN_RELEASE variable to install unstable instead of testing, as the latter is not yet available for ppc64el. [1] http://d-i.debian.org/daily-images/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140830162859.gb1...@ohm.rr44.fr
Bug#754095: base-installer: ppc64el support
On Mon, Jul 07, 2014 at 04:18:13PM +0200, Frederic Bonnard wrote:
Package: base-installer
Version: 1.140
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Dear Maintainer,
here is a patch from Ubuntu to add support to ppc64el.
I've added a test when the CPU is used in POWERNV.
Thank you,
[snip]
--- base-installer-1.140/kernel/ppc64el.sh1970-01-01 00:00:00.0
+
+++ base-installer-1.140/kernel/ppc64el.sh2014-05-14 11:55:07.0
+
@@ -0,0 +1,13 @@
+arch_get_kernel_flavour () {
+ echo powerpc64le
+ return 0
+}
+
+arch_check_usable_kernel () {
+ return 0
+}
+
+arch_get_kernel () {
+ echo linux-powerpc64le
+ echo linux-image-powerpc64le
+}
I think only the second line is needed, the first line doesn't
correspond to any real package. Could you please confirm? I'll then
merge the patch.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140828083944.gs15...@hall.aurel32.net
Bug#754093: debian-installer: ppc64el: ping / vmlinuz
Hi, On Wed, Aug 27, 2014 at 01:32:32AM +0200, Cyril Brulebois wrote: Hi, and thanks for both the bug report and the patch. Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com (2014-08-26): Would you have any news/comments about the patch attached in this bug? I'll rather let Aurelien comment on ppc64el patches. (Also, some bits could probably be shared between powerpc and ppc64el?) I have this patch in mind for ppc64el d-i (as well as the other one on partman-partioning-auto), I will look in details at it soon, but I would like to test build it using the Debian archive first. We would like to switch the kernel on ppc64el to vmlinuz starting with 3.16 (introduction of zImage support for 64el). 3.16 is soon going to be the default anyway, as soon as it's uploaded to unstable and built on all architectures. I'll look at this one soon. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826234737.gn15...@hall.aurel32.net
Bug#740068: debian-installer: segfaults when built against testing
Hi, On Tue, Feb 25, 2014 at 02:39:23PM +0300, Cyril Brulebois wrote: Cyril Brulebois k...@debian.org (2014-02-25): Cyril Brulebois k...@debian.org (2014-02-25): It doesn't seem to happen when building against unstable, but it would be nice to make sure we spot the reason/bugfix and possibly speed up its propagation to testing. I forgot to mention it's netboot/gtk/mini.iso on amd64, in case it matters. So here are the results of some cross tests, using this: git clean -xdf make rebuild_netboot-gtk USE_UDEBS_FROM=... chroot \ USE_UDEBS_FROM | jessie | sid - jessie |OK| segfault - sid | segfault |OK (FTR my chroots are up-to-date and sid's has 2.18-3.) This might be due to some libc mismatch (2.17 vs. 2.18) I guess? Yes, we get this bug happening regularly because the binaries on the image went through the library reduction process with a given libc (here 2.18), and later a different version of the libc is unpacked over it (here 2.17). Therefore some symbols are missings, causing the segfault. In addition I think there are also some version mismatches between libnss-* and libc6 when the old one is getting unpacked. This rings some bells: | eglibc (2.18-2) unstable; urgency=medium | | [ Aurelien Jarno ] | * any/local-ldconfig-ignore-ld.so.diff: new patch to ignore the dynamic | linker in ldconfig. Closes: #699206, #707185, #727786, #736097, | #739734, #739758. No it's not related to that. This bug is when you have multiple libc of the same architecture on a system (e.g. libc6:amd64 and libc6-amd64:i386, or libc6:i386 and libc-i386:amd64) eglibc maintainers, can you please suggest further directions for me to look into? Initial d-i bug report with busybox sh segfaults: http://bugs.debian.org/740068 You just have to ensure that the libc used for building the image is the same as the one used later in d-i. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225192412.gg5...@hall.aurel32.net
Bug#733502: busybox: FTBFS when built with bash as the default shell
Package: busybox
Version: 1:1.21.0-6exp
Severity: important
Tags: upstream
Busybox fails to build when the default shell is bash and busybox is
*not* installed on the system. In this condition the
which-uses-default-path test fails as in this build log [1]:
| FAIL: which-uses-default-path
| ++ command -pv busybox
| + BUSYBOX=
Looking at the test, it does:
| BUSYBOX=$(command -pv busybox)
| SAVED_PATH=$PATH
| unset PATH
| $BUSYBOX which ls
It is launched with PATH set to ${busybox-build-dir}:$PATH
On a POSIX compliant shell like bash, the '-p' passed to 'command' means
ignore the PATH environment variable and use the default one [1]. If
busybox is not in the standard path (which is supposed to be the case on
a clean chroot on a buildd), this command will return nothing, and a
exit value different of 0, and the test will fail, as seen on the build
log.
When dash is used, it ignores the '-p' argument passed to 'command'
contrary to what POSIX mandates. The just built busybox is therefore
correctly found the in the PATH, and the test succeed. I have reported
the dash issue as bug #733501.
On the busybox side, it looks like what is really wanted here is
'command -v busybox' instead of 'command -pv busybox. That way the
testsuite passes.
[1]
https://buildd.debian.org/status/fetch.php?pkg=busyboxarch=mipsver=1%3A1.21.0-6expstamp=1387284512
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages busybox depends on:
ii libc6 2.18-0experimental0
busybox recommends no packages.
busybox suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131229135028.3049.20558.report...@volta.rr44.fr
[PATCH RFC] Remove KERNELMAJOR feature
Historically the KERNELMAJOR feature allows to build the same images for
two different kernels, for example 2.4 and 2.6 kernel. This is not used
anymore, but KERNELMAJOR still has to be defined, otherwise the
arguments to pkg-list are shift by one, causing the build to fail. Thus
depending on the architecture, KERNELMAJOR is defined to random values
like 2.4, 2.6 or 3.11.
Note also that kfreebsd is building the images for both kernel 9 and 10,
but for that uses different configuration files.
It is therefore probably a good idea to remove KERNELMAJOR support,
which is what the current patches does.
---
build/Makefile | 2 +-
build/README| 7 +--
build/config/alpha.cfg | 1 -
build/config/amd64.cfg | 1 -
build/config/armel.cfg | 1 -
build/config/armhf.cfg | 1 -
build/config/hppa.cfg | 1 -
build/config/hurd-i386.cfg | 3 +--
build/config/i386.cfg | 1 -
build/config/ia64.cfg | 1 -
build/config/kfreebsd-amd64.cfg | 1 -
build/config/kfreebsd-i386.cfg | 1 -
build/config/m68k.cfg | 1 -
build/config/mips.cfg | 1 -
build/config/mipsel.cfg | 1 -
build/config/powerpc.cfg| 28 ++--
build/config/powerpc/apus.cfg | 1 -
build/config/s390.cfg | 1 -
build/config/s390x.cfg | 1 -
build/config/sh4.cfg| 1 -
build/config/sparc.cfg | 1 -
build/config/sparc64.cfg| 1 -
build/util/pkg-list | 10 ++
23 files changed, 15 insertions(+), 53 deletions(-)
diff --git a/build/Makefile b/build/Makefile
index deb00a4..8359097 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -607,7 +607,7 @@ endif
# Get the list of udebs to install.
# HACK Alert: pkg-lists/ is still sorted by TYPE instead of a dir hierarchy.
-UDEBS = $(shell set -e; get-packages udeb update 2; pkg-list $(TYPE)
$(DRIVER_FOR) $(KERNEL_FLAVOUR) $(KERNELMAJOR) $(SUBARCH)
$(KERNELIMAGEVERSION)) $(EXTRAS)
+UDEBS = $(shell set -e; get-packages udeb update 2; pkg-list $(TYPE)
$(DRIVER_FOR) $(KERNEL_FLAVOUR) $(SUBARCH) $(KERNELIMAGEVERSION)) $(EXTRAS)
# Get all required udebs and put them in UDEBDIR.
$(STAMPS)get_udebs-$(targetstring)-stamp: sources.list.udeb
diff --git a/build/README b/build/README
index 33f6f5b..d2753c9 100644
--- a/build/README
+++ b/build/README
@@ -147,8 +147,7 @@ like this:
SUBARCH_SUPPORTED = r4k-ip22 r5k-ip22 sb1-bcm91250a miniiso
-KERNELMAJOR = 2.4
-KERNELMINOR = 25
+KERNELVERSION = 3.12-1
KERNEL_FLAVOUR = di
KERNELIMAGEVERSION = $(KERNELVERSION)
KERNELNAME = $(foreach ver,$(KERNELVERSION),vmlinux-$(ver))
@@ -191,10 +190,6 @@ FLAVOUR_SUPPORTED
MEDIUM and FLAVOUR for every snippet they invoke that way.
At least one of them must be defined.
-KERNELMAJOR
- The high part of the kernel version, like 2.6. Unluckily, this is
- what the kernel people call MAJOR.MINOR.
-
KERNELVERSION
The version of the kernel .udeb package, like 2.4.26-r4k-ip22
diff --git a/build/config/alpha.cfg b/build/config/alpha.cfg
index 523759e..26eeeb8 100644
--- a/build/config/alpha.cfg
+++ b/build/config/alpha.cfg
@@ -2,7 +2,6 @@ MEDIUM_SUPPORTED = cdrom netboot miniiso
# The version of the kernel to use.
KERNELVERSION = 2.6.30-2-alpha-generic
-KERNELMAJOR = 2.6
KERNEL_FLAVOUR = di
KERNELNAME = vmlinuz
KERNELIMAGEVERSION = $(KERNELVERSION)
diff --git a/build/config/amd64.cfg b/build/config/amd64.cfg
index 05d7bf9..ae0063f 100644
--- a/build/config/amd64.cfg
+++ b/build/config/amd64.cfg
@@ -3,7 +3,6 @@ MEDIUM_SUPPORTED_EXTRA = monolithic
# The version of the kernel to use.
KERNELVERSION = 3.12-1-amd64
-KERNELMAJOR = 2.6
KERNEL_FLAVOUR = di
KERNELNAME = vmlinuz
KERNELIMAGEVERSION = $(KERNELVERSION)
diff --git a/build/config/armel.cfg b/build/config/armel.cfg
index 9b505c7..032d361 100644
--- a/build/config/armel.cfg
+++ b/build/config/armel.cfg
@@ -1,6 +1,5 @@
SUBARCH_SUPPORTED = iop32x kirkwood orion5x versatile
-KERNELMAJOR = 2.6
KERNELVERSION = 3.12-1
KERNEL_FLAVOUR = di
KERNELIMAGEVERSION = $(KERNELVERSION)
diff --git a/build/config/armhf.cfg b/build/config/armhf.cfg
index d44d191..a2bf409 100644
--- a/build/config/armhf.cfg
+++ b/build/config/armhf.cfg
@@ -2,7 +2,6 @@ SUBARCH_SUPPORTED = armmp
MKLIBS = mklibs --ldlib=/lib/ld-linux-armhf.so.3
-KERNELMAJOR = 2.6
KERNELVERSION = 3.12-1
KERNEL_FLAVOUR = di
KERNELIMAGEVERSION = $(KERNELVERSION)
diff --git a/build/config/hppa.cfg b/build/config/hppa.cfg
index c3c8e57..bae2359 100644
--- a/build/config/hppa.cfg
+++ b/build/config/hppa.cfg
@@ -3,7 +3,6 @@ MEDIUM_SUPPORTED = cdrom netboot miniiso
KERNEL_FLAVOUR = di
BASEVERSION = 2.6.37-2
-KERNELMAJOR = 2.6
KERNELIMAGEVERSION = $(BASEVERSION)-parisc $(BASEVERSION)-parisc64
KERNELVERSION = $(foreach ver,${KERNELIMAGEVERSION},$(ver))
KERNELNAME = $(foreach ver,${KERNELVERSION},vmlinux-$(ver))
diff --git a/build/config/hurd-i386.cfg
Re: Bug#704672: virtio-modules for sparc64
On Fri, May 03, 2013 at 12:28:03PM +0200, Cyril Brulebois wrote: Artyom Tarasenko atar4q...@gmail.com (03/05/2013): Will be in rc3. Negative. The drivers are still missing: $ gunzip -c debian-wheezy-DI-rc3-sparc-netinst/initrd.gz | cpio -t | grep virtio 28223 blocks Well, they are in the netboot image (mini.iso), which is what Aurélien advertised in his changelog entry. Looks like the fact you were asking about the netinstall images was overlooked. The virtio-net module (as every NIC modules) should only be needed for the netboot image. The netinst image has the virtio-net module (and other NIC modules) on the CD-ROM in: pool/main/l/linux/virtio-modules-3.2.0-4-sparc64-di_3.2.41-2_sparc.udeb Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130503111617.gh26...@hall.aurel32.net
Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di
On Mon, Apr 15, 2013 at 01:47:28AM +0100, Ben Hutchings wrote:
On Sun, 2013-04-14 at 23:41 +0200, Aurelien Jarno wrote:
[...]
Sorry to answer late, I only have been able to test it now.
Unfortunately the vexpress image is now broken, due to this change:
| * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
|images (Closes: #705118)
nic-modules is still needed on vexpress as it provides the module for
the on-board NIC.
Since any system with external USB ports should be able to work with
arbitrary USB Ethernet controllers, I added nic-{usb,wireless}-modules
packages and removed the USB modules you originally specified in
nic-modules. In the case of mx5 this left nic-modules empty, and I
removed it, but for vexpress there was that one module left, smsc911x.
Unfortunately I then removed nic-modules from the installer for *both*
flavours instead of just mx5.
I just tried adding smsc91xx back into the current daily netboot initrd
and it seems to work in QEMU (up to the point where the installer finds
I didn't attach a disk).
Yes, I have committed such a change, and I have been able to do a full
installation that way. The daily image that will be generated in a few
hours should have the fix, I will test it when available.
By the way, given that the majority of users for the vexpress flavour
will be running it in QEMU rather than a real Motherboard Express
(they're expensive!), is it possible to support an alternate model like
virtio_net that may be emulated more efficiently?
Unfortunately the vexpress board doesn't have PCI/PCIE support so the
standard virtio doesn't work there. People are working on virtio-mmio,
but it seems to be something difficult to get working correctly.
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130415083403.gb32...@ohm.aurel32.net
