Re: Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)
Dear powerpc porters, it would be great if you could look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852811 From a cursory glance it seems that seccomp support is broken on ppc64. Your input would be appreciated. Am 27.01.2017 um 16:21 schrieb Michael Biebl: > Am 27.01.2017 um 15:54 schrieb Christian Marillat: >> #MemoryDenyWriteExecute=yes >> #RestrictRealtime=yes >> #RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 >> >> But I see others problems after a reboot : > > There are quite a few services which use seccomp features to restrict > the service. systemd-udevd is just one of them. So if seccomp is broken, > the output you get is expected. > > Christian, I think it's best if you approach the ppc64 porters about > this. We need their input regarding seccomp support on that architecture. > -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#853755: installation-reports: ppc64el fails to boot after installation
Am 02.02.2017 um 14:22 schrieb Cyril Brulebois: > Hi Erwan, > > Erwan Prioul (2017-02-02): >> AFAIK 4.9.6-x is not yet provided in the daily image for ppc64el. >> It's still the 4.9.2-2. Anyway, I ran a couple of tests with >> 4.9.6-3 and 4.8.15-2, and I got the same error. > > The switch from 4.9.2 to 4.9.6 was first seen with d-i daily builds > with this one: > https://d-i.debian.org/daily-images/ppc64el/20170130-00:02/ > >> I did another install but this time I took the previous version of >> systemd, 232-8 instead of 232-14 (current version), and it worked. > > Ah, right, that's one of the big differences between a boot to d-i and > a boot to the installed system… Good catch! > >> I'll reassign this to systemd. > > An easy suspect would be: > | commit 7b17f7c824429e95826528d4c6e9d40662ae45ca > | Author: Michael Biebl > | Date: Wed Jan 18 19:43:28 2017 +0100 > | > | Enable seccomp support on ppc64 ppc64 != ppc64el, or am I missing something? seccomp support has been enabled on ppc64el since almost a year: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=7a1805b4e89f3545cd110d6e6ed2125fe946e685 Do we have any ppc/powerpc porters which can help us in that regard and let us know if seccomp is working on that architecture: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853755 (ppc64el) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853940 (powerpc) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852811 (ppc64) Could it be that older versions were already broken but it simply went unnoticed because none of the sandboxing features were used in the .service files? Erwan, could you try 232-1 from snapshots.debian.org and see if the problem is reproducible there? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#853755: installation-reports: ppc64el fails to boot after installation
Am 02.02.2017 um 15:56 schrieb Erwan Prioul: > On 02/02/2017 02:46 PM, Michael Biebl wrote: >> >> Erwan, could you try 232-1 from snapshots.debian.org and see if the >> problem is reproducible there? > > I ran few tests. > 232-1 is OK, same result for 232-8 and 232-10. > The issue appeared in 232-11. Let me quote what I wrote in #853940 > The sandboxing features (based on seccomp) are available in systemd > since a while, but were not actively used in .service units. > > In 232-1 for a couple of systemd services, like logind, udevd or > journald those were turned on. > > This caused problems on i386, so we temporarily removed them from the > .service files. seccomp support was reworked upstream and we backported > those patches in 232-11 and reenabled the sandboxing features. > > I guess it would be worthwile testing 232-1 from snapshot.d.o [1] > > This would show if seccomp support has been broken in previous releases > as well, or if the backported patches [2] from 232-11 caused a > regression on powerpc. > > Michael > > [1] http://snapshot.debian.org/ > [2] > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=c31b5ee9b9c79c9d2ac491920b23a8084a4ccc46 The relevant upstream bug report is https://github.com/systemd/systemd/issues/4575 That seccomp code is admittedly over my head. I guess it would be best if you take this issue upstream and talk directly to them, letting them know that the changes from #4575 apparently caused a regression on powerpc. As for the stretch release, I'm currently undecided what the best course of action is. Disabling the sandboxing features/Seccomp on ppc* seems like an option. Adrian said he wanted to look into this over the weekend. So maybe we know more then. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: mozjs52: tests fail on ppc64el: timeout
On Thu, 12 Oct 2017 20:51:59 +0100 Simon McVittie wrote: > Source: mozjs52 > Version: 52.3.1-4 > Severity: normal > X-Debbugs-Cc: debian-powerpc@lists.debian.org > > Build-time test suite failures for mozjs52 have been made non-fatal on > ppc64el because the tests time out. This is clearly a bug, but it isn't > clear what the severity of that bug is: it could be anything from minor > (if trivial functionality is broken) to RC (if mozjs52 is basically > unusable on this architecture). > The tests that currently fail are > ## js1_5/extensions/regress-341956-01.js: rc = 0, run time = 233.1152 > BUGNUMBER: 341956 > STATUS: GC Hazards in jsarray.c - unshift > FAILED! [reported from test()] GC Hazards in jsarray.c - unshift : Expected > value 'true', Actual value 'false' > Done > TEST-UNEXPECTED-FAIL | js1_5/extensions/regress-341956-01.js | (args: "") > ## js1_5/extensions/regress-313763.js: rc = 0, run time = 375.610908 > BUGNUMBER: 313763 > STATUS: Root jsarray.c creatures > STATUS: This bug requires TOO_MUCH_GC > STATUS: false > FAILED! [reported from top level script] Root jsarray.c creatures : Type > mismatch, expected type string, actual type undefined Expected value '1', > Actual value 'undefined' > TEST-UNEXPECTED-FAIL | js1_5/extensions/regress-313763.js | (args: "") -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Control: tags -1 + unreproducible Hello Lucas Am 09.12.20 um 09:42 schrieb Lucas Nussbaum: Source: systemd-bootchart Version: 233-2 Severity: serious Justification: FTBFS on ppc64el Tags: bullseye sid ftbfs Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el Hi, During a rebuild of all packages in sid, your package failed to build on ppc64el. At the same time, it did not fail on amd64. I'm marking this bug as severity:serious since your package currently has ppc64el binary packages in unstable (so this is a regression). Relevant part (hopefully): make[1]: Entering directory '/<>' Making check in . make --no-print-directory check-TESTS FAIL: tests/run = systemd-bootchart 233: ./test-suite.log = # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: tests/run === 1..3 Segmentation fault not ok 1 - ./systemd-bootchart -o /tmp/tmp.cNy0lVrga8 -n 2 -r Segmentation fault not ok 2 - ./systemd-bootchart -o /tmp/tmp.cNy0lVrga8 -n 10 -r Segmentation fault not ok 3 - ./systemd-bootchart -o /tmp/tmp.cNy0lVrga8 -n 10 -r -p # Failed 3 out of 3 tests FAIL tests/run (exit status: 1) Testsuite summary for systemd-bootchart 233 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to http://github.com/systemd/systemd-bootchart/issues make[4]: *** [Makefile:1515: test-suite.log] Error 1 make[3]: *** [Makefile:1623: check-TESTS] Error 2 make[2]: *** [Makefile:1859: check-am] Error 2 make[1]: *** [Makefile:1400: check-recursive] Error 1 make[1]: Leaving directory '/<>' dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2 Unfortunately, I can't reproduce the issue on a porter box (plummer). So I'm not sure if I can do something about it. CCing the powerpc porters mailing list. Maybe they can have a look. Regards, Michael
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Am 10.12.20 um 20:18 schrieb John Paul Adrian Glaubitz: Hi Michael! On 12/10/20 7:53 PM, Michael Biebl wrote: Unfortunately, I can't reproduce the issue on a porter box (plummer). So I'm not sure if I can do something about it. It might be an issue with parallel jobs as Lucas built the package with make -j160 and some packages can't cope with that many parallel jobs. export DEB_BUILD_OPTIONS="parallel=160" ... dh_auto_test make -j160 check VERBOSE=1 make[1]: Entering directory '/home/biebl/sd/systemd-bootchart-233' Making check in . make --no-print-directory check-TESTS PASS: tests/run Testsuite summary for systemd-bootchart 233 # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 make[1]: Leaving directory '/home/biebl/sd/systemd-bootchart-233' create-stamp debian/debhelper-build-stamp dh_prep debian/rules override_dh_auto_install make[1]: Entering directory '/home/biebl/sd/systemd-bootchart-233'
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz: Hi Michael! On 12/10/20 8:42 PM, Michael Biebl wrote: Testsuite summary for systemd-bootchart 233 # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Did the test machine you used actually have that many cores? No idea
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Am 10.12.20 um 22:12 schrieb Michael Biebl: Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz: Hi Michael! On 12/10/20 8:42 PM, Michael Biebl wrote: Testsuite summary for systemd-bootchart 233 # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Did the test machine you used actually have that many cores? No idea But given that there is only a single test, I wonder if that is really relevant anyway.
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Am 11.12.20 um 09:09 schrieb Lucas Nussbaum: 0x00014d04 in svg_ps_bars (interval=, graph_start=2775.3698308829998, ps_first=0x1000505d0, n_cpus=1, n_samples=10, head=0x100050770, of=0x1000503f0) at src/svg.c:1187 looking at n_cpus=1, what's the output of /proc/schedstat?
Re: Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Am 11.12.20 um 09:26 schrieb Lucas Nussbaum: I tried to reproduce this on another system (ARM64, 256 visible cores because 2 x ThunderX2, 32 cores/cpu, 4 threads/core) and it also segfaults. I tried to reproduce on yet another system (x86_64, 128 visible cores because 4x Intel Xeon Gold 6130, 16 cores/cpu, 2 threads/core), and it also segfaults. My guess would be that the test suite depends on the system it is running on (it just generates the output for the local system), and there's something it doesn't like about large numbers of cores, but there's nothing specific to ppc64el here. There is also $ grep MAXCPUS -R src/bootchart.h:#define MAXCPUS16 src/bootchart.h:double runtime[MAXCPUS]; src/bootchart.h:double waittime[MAXCPUS]; src/store.c:if (r < 0 || c > MAXCPUS -1) src/store.c:/* Oops, we only have room for MAXCPUS data */
Re: Bug#1086795: rsyslog: Segmentation fault
Control: tags -1 + moreinfo Control: retitle -1 rsyslog: segmentation fault on ppc64 Am 06.11.24 um 00:18 schrieb Stuart MacIntosh: Package: rsyslog Version: 8.2406.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, The rsyslog package on ppc64 in sid currently segfaults on Apple Xserve G5 hardware. Please provide a backtrace of the crash: https://wiki.debian.org/HowToGetABacktrace I also usertagged the issue so it shows up at [1] so the ppc porters might have a look and can keep track of it. Michael [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-powerpc@lists.debian.org&tag=ppc64 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1086795: rsyslog: Segmentation fault
Control: tags -1 + help Hi Stuart Am 08.11.24 um 00:29 schrieb Stuart MacIntosh: On 7/11/2024, at 1:25 AM, Michael Biebl wrote: Control: tags -1 + moreinfo Control: retitle -1 rsyslog: segmentation fault on ppc64 Am 06.11.24 um 00:18 schrieb Stuart MacIntosh: Package: rsyslog Version: 8.2406.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, The rsyslog package on ppc64 in sid currently segfaults on Apple Xserve G5 hardware. Please provide a backtrace of the crash: https://wiki.debian.org/HowToGetABacktrace I also usertagged the issue so it shows up at [1] so the ppc porters might have a look and can keep track of it. Michael [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-powerpc@lists.debian.org&tag=ppc64 Please find the backtrace bt.txt attached. Thank you for your help. Thanks for the backtrace This looks like a crash in glibc when trying to load the rsyslog modules from /usr/lib/rsyslog which in turn hints at a platform specific (toolchain) issue. Not sure, if there is anything in rsyslog itself that can be done about it (probably not). That said, I'm not familiar with the intricacies of the ppc platform, so this issue needs help from the ppc porters. I will not further pursue this issue (as I lack the means to reproduce the issue) and I will also not forward this issue to upstream. You are free to try that though. In this case please report this at https://github.com/rsyslog/rsyslog/issues Regards Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1089243: FTBFS on powerpc
Source: ppc64-diag
Version: 2.7.9-1.1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Hi,
as can be seen at [0], the package fails to build (most likely due to
the t64 related changes in sid/trixie):
rtas_errd/v6ela.c: In function ‘report_menugoal’:
gcc -DHAVE_CONFIG_H -I. -I./config -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I ./common/ -I ./ela/ -I
./diags -I ./lpd/ -I /usr/include/ncurses/ -Wall -g -DDEBUG -DDEST_DIR='"/usr"'
-DVERSION='"2.7.9"' -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-all -fwrapv
-fPIE -Wstack-protector --param=ssp-buffer-size=1 -c -o diags/7031_D24_T24.o
diags/7031_D24_T24.c
rtas_errd/v6ela.c:366:65: error: passing argument 1 of ‘time’ from incompatible
pointer type [-Wincompatible-pointer-types]
366 | time_loc = time((long
*)0);
|
^
| |
| long
int *
In file included from /usr/include/features.h:510,
from
/usr/include/powerpc-linux-gnu/bits/libc-header-start.h:33,
from /usr/include/stdio.h:28,
from rtas_errd/v6ela.c:21:
/usr/include/time.h:85:15: note: expected ‘time_t *’ {aka ‘long long int *’}
but argument is of type ‘long int *’
85 | extern time_t __REDIRECT_NTH (time, (time_t *__timer), __time64);
| ^~
rtas_errd/v6ela.c:367:66: error: passing argument 1 of ‘localtime’ from
incompatible pointer type [-Wincompatible-pointer-types]
367 | date =
localtime(&time_loc);
|
^
| |
| long
int *
/usr/include/time.h:141:19: note: expected ‘const time_t *’ {aka ‘const long
long int *’} but argument is of type ‘long int *’
141 | extern struct tm *__REDIRECT_NTH (localtime, (const time_t *__timer),
| ^~
gcc -DHAVE_CONFIG_H -I. -I./config -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I ./common/ -I ./ela/ -I
./diags -I ./lpd/ -I /usr/include/ncurses/ -Wall -g -DDEBUG -DDEST_DIR='"/usr"'
-DVERSION='"2.7.9"' -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-all -fwrapv
-fPIE -Wstack-protector --param=ssp-buffer-size=1 -c -o diags/bluehawk.o
diags/bluehawk.c
make[1]: *** [Makefile:2170: rtas_errd/v6ela.o] Error 1
make[1]: *** Waiting for unfinished jobs
In file included from /usr/include/string.h:548,
[0]
https://buildd.debian.org/status/fetch.php?pkg=ppc64-diag&arch=powerpc&ver=2.7.9-1.1&stamp=1733512224&raw=0
Re: libvpd-2.2-3 file loss during upgrade from bookworm to trixie due to /usr-move (DEP17)
Hi Adrian Am 21.02.25 um 14:38 schrieb John Paul Adrian Glaubitz: Hi Michael, On Fri, 2025-02-14 at 23:13 +0100, Michael Biebl wrote: it appears that Frédéric Bonnard is not really active anymore. I've CCed you as PPC porter. Maybe you can have a look at this bug report and do an NMU / take over the package. Yes, I'm going to have a look at it over the weekend. I assume this fell through the cracks? OpenPGP_signature.asc Description: OpenPGP digital signature
Re: libvpd-2.2-3 file loss during upgrade from bookworm to trixie due to /usr-move (DEP17)
Hi Adrian! On Fri, 04 Apr 2025 10:44:41 +0200 John Paul Adrian Glaubitz wrote: Hi, On Wed, 2025-03-26 at 13:59 +0100, John Paul Adrian Glaubitz wrote: > It didn't. There were just a few other things that kept me busy last > week, including a smartphone that nearly got lost when I sent it to > repair. > > I'll look at it either today or tomorrow. Apologies, I have to move that to the weekend. With the freeze in effect, it has probably become a bit harder to get ppc64-diag and libvpd back into trixie. https://tracker.debian.org/pkg/ppc64-diag https://tracker.debian.org/pkg/libvpd That said, I have no idea how important those packages are for ppc(64) or not (and if removal of those packages is a valid option as well). As it stands today, those packages will not be part of trixie. I've added debian-powerpc to CC to gather further feedback Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: HELP NEEDED: debuging a ppc64el autopkgtest failure involving polkitd?
Am 12.06.25 um 23:27 schrieb Theodore Ts'o: Creating group 'polkitd' with GID 989. < We created the polkitd group here Creating user 'polkitd' (User for polkitd) with UID 989 and GID 989. chown: invalid group: ‘root:polkitd’ <-- Huh?!?!? .. So this is a really big mystery. I've cc'ed folks who are involved with polkitd and debianutils, as well as sending this query to the ppc64el developers, hoping that someone can give me a hint as to what might be going on.What am I missing? It's certainly not an e2fsprogs issue. debian-edu-config has already been failing in the past quite often with the same error message as above. The oldest failing log is from 2025-04-18 22:11:45 UTC https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/debian-edu-config/60154832/log.gz Unfortunately older logs have already been garbage collected. polkitd has an autopkgtest which installs the package, include the above creation of the polkitd user and the test runs reliably on ppc64el: https://ci.debian.net/packages/p/policykit-1/unstable/ppc64el/ So maybe some weird interaction is going on by the way the debian-edu-config test bed is setup. Haven't seen this failure myself before, so sorry if I can't be of more help. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
