Re: Installation fails with current release image 2022-03-28 and server set
Hello Adrian, thank you for your reply. Health comes first, please take your time to get well. I encountered the usr-merge problem i guess when i first tried to set up a separate /usr partition. This will abort the installation with an error saying one needs an initramfs. After repartitioning without the use of a /usr partition, this error came not up anymore. After that i encountered the error of my post above which seems to be caused by 2.34-7 https://packages.debian.org/de/sid/libc-bin and 2.34-7 https://packages.debian.org/de/sid/locales-all not matching to 2.35-1 https://packages.debian.org/de/sid/locales During installation i chrooted into /target, installed 2.34-7 locales-all and locales manually and had to set them to hold with apt-mark. I was then able to proceed and complete the installation for now. (to be further tested, but the installer showed no further error). Regards, Connor On Sun, Sep 25, 2022 at 5:26 PM John Paul Adrian Glaubitz wrote: > > Hello! > > On 9/25/22 15:56, Connor McLaughlan wrote: > > This worked earlier this year but currently fails with the updated > > files from debian servers during tasksel as follows: > > This might be related to the ongoing usr-merge but I'm not sure. I'm > planning to publish new installation images next week. Cannot do it > earlier as I am currently lying in bed with a cold. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: Installation fails with current release image 2022-03-28 and server set
Hello! On 9/25/22 15:56, Connor McLaughlan wrote: This worked earlier this year but currently fails with the updated files from debian servers during tasksel as follows: This might be related to the ongoing usr-merge but I'm not sure. I'm planning to publish new installation images next week. Cannot do it earlier as I am currently lying in bed with a cold. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1020319: openldap: FTBFS on sparc64 due to unaligned access in testsuite
Hi Gregor! On 9/25/22 17:07, Gregor Riepl wrote: openldap FTBFS on sparc64 due to an unaligned access in the testsuite: Adding __attribute__((packed)) to the MDB_page struct creates some memory alignment warnings, but it will make the test cases succeed: ./../../../libraries/liblmdb/mdb.c: In function ‘mdb_cursor_put’: ./../../../libraries/liblmdb/mdb.c:971:31: warning: taking address of packed member of ‘struct MDB_page’ may result in an unaligned pointer value [-Waddress-of-packed-member] 971 | s = (unsigned short *)&(src); \ | ^~ ./../../../libraries/liblmdb/mdb.c:6799:41: note: in expansion of macro ‘COPY_PGNO’ 6799 | COPY_PGNO(fp->mp_pgno, mp->mp_pgno); | ^ I get some errors later on, unfortunately: > 00:03:39 Starting test018-syncreplication-persist for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... ldapsearch failed at provider (254)! ./scripts/test018-syncreplication-persist: 128: kill: No such process This could be a different issue, though, or maybe caused by my experimentation. Looks like the extremely conservative memory usage of liblmdb leads to all sorts of problems when the target architecture doesn't like unaligned memory access. :( Interestingly, there seem to be provisions for aligning memory access in liblmdb, as evidenced by the macro MISALIGNED_OK (which is unset on sparc64). Still, it's not enough to produce working code. The Bus Error also does not occur when compiling with -O0. Thanks for the additional investigation. Could you add that information to the upstream bug [1]? Adrian [1] https://bugs.openldap.org/show_bug.cgi?id=9916 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1018076: mini-transition: gjs built against mozjs102
On Sun, 25 Sep 2022 at 15:41:04 +0200, John Paul Adrian Glaubitz wrote: > Could you blacklist the test > > “ large-arraybuffers/basic.js” > > on all affected big-endian targets (powerpc, ppc64, sparc64)? > > The test is blacklist on s390x and fails on powerpc and ppc64 as well. I'm not intending to touch it until the current version has either migrated or failed to migrate, but after that, sure. Please open a mozjs102 bug as a reminder. (Obviously I'd prefer a fix for whatever endianness assumption is causing this test to fail, if a porter for big-endian architectures can find the root cause and suggest a patch.) smcv
Re: Bug#1020319: openldap: FTBFS on sparc64 due to unaligned access in testsuite
openldap FTBFS on sparc64 due to an unaligned access in the testsuite: Adding __attribute__((packed)) to the MDB_page struct creates some memory alignment warnings, but it will make the test cases succeed: ./../../../libraries/liblmdb/mdb.c: In function ‘mdb_cursor_put’: ./../../../libraries/liblmdb/mdb.c:971:31: warning: taking address of packed member of ‘struct MDB_page’ may result in an unaligned pointer value [-Waddress-of-packed-member] 971 | s = (unsigned short *)&(src); \ | ^~ ./../../../libraries/liblmdb/mdb.c:6799:41: note: in expansion of macro ‘COPY_PGNO’ 6799 | COPY_PGNO(fp->mp_pgno, mp->mp_pgno); | ^ I get some errors later on, unfortunately: > 00:03:39 Starting test018-syncreplication-persist for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... ldapsearch failed at provider (254)! ./scripts/test018-syncreplication-persist: 128: kill: No such process This could be a different issue, though, or maybe caused by my experimentation. Looks like the extremely conservative memory usage of liblmdb leads to all sorts of problems when the target architecture doesn't like unaligned memory access. :( Interestingly, there seem to be provisions for aligning memory access in liblmdb, as evidenced by the macro MISALIGNED_OK (which is unset on sparc64). Still, it's not enough to produce working code. The Bus Error also does not occur when compiling with -O0.
Installation fails with current release image 2022-03-28 and server set
Hello All, i am using the sparc64 netinstall image of 2022-03-28. This worked earlier this year but currently fails with the updated files from debian servers during tasksel as follows: ep 25 13:42:18 pkgsel: starting tasksel Sep 25 13:42:21 in-target: Reading package lists... Sep 25 13:42:23 in-target: Sep 25 13:42:23 in-target: Building dependency tree... Sep 25 13:42:25 in-target: Sep 25 13:42:25 in-target: Reading state information... Sep 25 13:42:25 in-target: Sep 25 13:42:29 in-target: tasksel is already the newest version (3.70). Sep 25 13:42:29 in-target: The following package was automatically installed and is no longer required: Sep 25 13:42:29 in-target: libicu67 Sep 25 13:42:29 in-target: Use 'apt autoremove' to remove it. Sep 25 13:42:29 in-target: The following additional packages will be installed: Sep 25 13:42:29 in-target: gcc-12-base libatomic1 libc-bin libc6 libgcc-s1 libssl3 libstdc++6 Sep 25 13:42:29 in-target: libsystemd-shared libsystemd0 systemd Sep 25 13:42:29 in-target: Suggested packages: Sep 25 13:42:29 in-target: glibc-doc locales libnss-nis libnss-nisplus systemd-container systemd-homed Sep 25 13:42:29 in-target: systemd-userdbd systemd-boot systemd-resolved libfido2-1 Sep 25 13:42:29 in-target: libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0 policykit-1 Sep 25 13:42:29 in-target: Recommended packages: Sep 25 13:42:29 in-target: manpages default-dbus-system-bus | dbus-system-bus systemd-timesyncd Sep 25 13:42:29 in-target: | time-daemon Sep 25 13:42:30 in-target: The following packages will be REMOVED: Sep 25 13:42:30 in-target: locales Sep 25 13:42:30 in-target: The following NEW packages will be installed: Sep 25 13:42:30 in-target: libatomic1 libssl3 libsystemd-shared Sep 25 13:42:30 in-target: The following packages will be upgraded: Sep 25 13:42:30 in-target: gcc-12-base libc-bin libc6 libgcc-s1 libstdc++6 libsystemd0 systemd Sep 25 13:42:30 in-target: 7 upgraded, 3 newly installed, 1 to remove and 36 not upgraded. Sep 25 13:42:30 in-target: E Sep 25 13:42:30 in-target: : Sep 25 13:42:30 in-target: Packages need to be removed but remove is disabled. Sep 25 13:42:30 in-target: Sep 25 13:42:30 main-menu[236]: (process:5798): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Sep 25 13:42:30 main-menu[236]: (process:5798): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename Sep 25 13:42:30 main-menu[236]: WARNING **: Configuring 'pkgsel' failed with error code 100 Sep 25 13:42:30 main-menu[236]: WARNING **: Menu item 'pkgsel' failed. Sep 25 13:42:39 main-menu[236]: INFO: Modifying debconf priority limit from 'high' to 'medium' Sep 25 13:42:39 debconf: Setting debconf/priority to medium Sep 25 13:42:45 main-menu[236]: INFO: Falling back to the package description for brltty-udeb What can i do to work around it? Regards, Connor
Re: Bug#1018076: mini-transition: gjs built against mozjs102
Hello! > On Sep 25, 2022, at 3:08 PM, Simon McVittie wrote: > > Control: retitle -1 mini-transition: gjs built against mozjs102 > Control: unblock -1 by 1018819 > Control: tags -1 = pending > >> On Thu, 25 Aug 2022 at 11:19:30 +0100, Simon McVittie wrote: >> I think we need to be looking at the possibility of doing >> architecture-specific removals of gjs and dependent packages from armel. > > We were able to get mozjs102_102.3.0-1 compiling and passing most of > its test suite on armel and all other release architectures (thanks > to Adrian Bunk and Mike Hommey for providing the necessary patches), > and gjs_1.74.0-2 has built successfully against it on all release > architectures and is also passing tests, so I'm now hoping we can keep > the full GNOME 43 family of packages on armel for Debian 12. Could you blacklist the test “ large-arraybuffers/basic.js” on all affected big-endian targets (powerpc, ppc64, sparc64)? The test is blacklist on s390x and fails on powerpc and ppc64 as well. Thanks, Adrian
