| === pieq_ is now known as pieq | ||
| slyon | Hey, can somebody tell me if autopkgtests using the "needs-reboot" restriction in debian/tests/control (called via the "/tmp/autopkgtest-reboot" command) are supported on Ubuntu's infrastructure? They are working fine in my local qemu environment, but there seem to be problems on our infra: https://paste.ubuntu.com/p/48q73GXpxz (line 1317 ff.) | 06:55 |
|---|---|---|
| RAOF | slyon: I'm pretty sure the systemd tests require reboots, and they work. | 07:07 |
| RAOF | (At least, when they're not regressed by something 🔥) | 07:07 |
| cpaelzer | yes slyon I think I've seen some working | 07:07 |
| cpaelzer | let me check which of the things I touched have one | 07:07 |
| slyon | RAOF, cpaelzer: hum.. okay, thanks for that information. So maybe it was just a temp failure? ... But it failed for amd64 and arm64, (ppc64el still running). Skipped on s390x/armhf. | 07:09 |
| slyon | Would it be worth re-trying this? https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=netplan.io&trigger=netplan.io/0.100-0ubuntu2 I cannot see any obvious problem in the log, except that nova cannot establish the SSH connection after the autopkgtest-reboot | 07:11 |
| cpaelzer | slyon: nice trap :-) | 07:51 |
| cpaelzer | I wanted to click on the link what I'd retyr, but it already was the retry link :-) | 07:51 |
| slyon | heh :-P | 07:52 |
| cpaelzer | anyway I guess that is ok, if the error reoccurs let us dig deeper on the actual case | 07:52 |
| slyon | the "core-dev trap" | 07:52 |
| * cpaelzer hides his cookies | 07:52 | |
| slyon | cpaelzer: sounds like a plan! Thanks | 07:52 |
| seb128 | rbalint, hey, the new glibc seems to make things no happy on i386, e.g https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages ? | 08:13 |
| seb128 | is that a known issue? | 08:13 |
| === StevenK is now known as Guest1882 | ||
| xnox | LocutusOfBorg: fyi - the builds with like -O0 / gcc-min stuff didn't improve things on armhf at all. Still 3days+, i'm cancelling those in bileto. | 10:23 |
| xnox | hm do i have interent | 10:23 |
| xnox | ok, looks like client sent those messages, but didn't show them to me. | 10:23 |
| xnox | ohw ell | 10:23 |
| LocutusOfBorg | xnox, I'm doing two tests | 10:32 |
| LocutusOfBorg | 1) groovy, gcc-9, ghc 8.8.4 | 10:32 |
| LocutusOfBorg | 2) focal, no change rebuild of ghc 8.6.5 | 10:33 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages | 10:33 |
| LocutusOfBorg | I see things have become worse and worse when you added the s390x byte order fixes, maybe something in the toolchain changed in the meanwhile | 10:33 |
| xnox | LocutusOfBorg: i am wondering if ubuntu's ghc got poisoned. Cause it does use previous ghc to bootstrap stage1 ghc. | 10:55 |
| xnox | LocutusOfBorg: i'm thinking to cross-build ghc from amd64->armhf; then build armhf off that; and then build against off that to see if the last build will be fast / just as fast as debian. | 10:55 |
| xnox | LocutusOfBorg: ubuntu & debian toolchains are mostly even around the relevant builds, and yet ubuntu build took 8days vs ~12h in debian | 10:56 |
| Laney | use Debian's to bootstrap it | 10:59 |
| LocutusOfBorg | Laney, xnox no change rebuilding the focal version in focal archive should answer that question, right? | 11:04 |
| LocutusOfBorg | I noticed a slow-down between the last 8.6 build and the first 8.8 build | 11:05 |
| Laney | probably the backport you already have going will be good data | 11:06 |
| LocutusOfBorg | backport? | 11:07 |
| LocutusOfBorg | no backport... | 11:07 |
| LocutusOfBorg | I'm no change rebuilding 8.6.5 with 8.6.5 | 11:07 |
| LocutusOfBorg | and I'm rebuilding 8.8.4 with 8.8.3 and gcc-9 | 11:07 |
| Laney | k | 11:09 |
| Laney | whatever, the focal build | 11:09 |
| LocutusOfBorg | yes, if 8.6.5 built with 8.6.5 is fast, it means regression in ghc somewhere | 11:14 |
| LocutusOfBorg | if it is slow, means regression in infrastructure somewhere | 11:14 |
| LocutusOfBorg | if 8.6.5 with 8.6.5 is fast, I can try 8.8.4 on top of it, the backport you mentioned | 11:14 |
| LocutusOfBorg | and then copy the binaries from focal to groovy :p | 11:14 |
| === StevenK is now known as Guest88139 | ||
| === StevenK_ is now known as StevenK | ||
| rbalint | seb128, yes, the cross toolchain needs to be updated | 12:03 |
| seb128 | rbalint, is anyone working on that? | 12:04 |
| rafaeldtinoco | bom dia! | 12:07 |
| rbalint | seb128, i'm working on everything around glibc including this one, but help is appreciated | 12:07 |
| seb128 | rbalint, ack, I'm busy enough atm so I will let you deal with it but I try to give an hand next week if there are still things to sort out | 12:08 |
| rbalint | doko, have you by any chance started updating cross-toolchain-base? | 12:08 |
| doko | rbalint: yes, I'll do that tomorrow | 12:56 |
| rbalint | doko, if it is just https://pastebin.ubuntu.com/p/HDxcKS8sYW/ and regenerating control i can land it today | 12:57 |
| rafaeldtinoco | ddstreet: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1880193 | 14:14 |
| ubottu | Launchpad bug 1880193 in systemd (Ubuntu Focal) "autofs: Assertion 'set_remove(iterator->links, link) == link' failed at src/shared/userdb.c:314, function userdb_on_query_reply(). Aborting." [Undecided,Triaged] | 14:14 |
| rafaeldtinoco | for you to kepe track ^ | 14:14 |
| === popey8 is now known as popey | ||
| seb128 | RikMills, could you do the kde rebuilds needed for the new poppler? | 15:56 |
| RikMills | seb128: ok, will do shortly | 15:57 |
| seb128 | RikMills, thanks! Debian did that transition already and most things didn't need changes so hopefully those are easy uploads | 15:58 |
| RikMills | great | 15:58 |
| rafaeldtinoco | xnox: out of curiosity only.. is it on purpose we're not packaging userdbctl in systemd ? | 16:53 |
| rafaeldtinoco | u happen to know ? or anyone else | 16:53 |
| === paride is now known as paride|off | ||
| xnox | rafaeldtinoco: it has licensing issues at the moment. And no demand to use it. Even if it is packaged, it would be in universe. | 18:12 |
| rafaeldtinoco | xnox: gotcha. | 18:13 |
| xnox | rafaeldtinoco: and possibly incorrectly scoped upstreamed. I think it comes with homed, and not otherwise compiled. | 18:13 |
| xnox | rafaeldtinoco: if you want/need it, open a bug against systemd package and we can look into making it available. But so far, it's just syntatic sugar, no? | 18:14 |
| rafaeldtinoco | https://bugs.launchpad.net/bugs/1880193 | 18:14 |
| ubottu | Launchpad bug 1880193 in systemd (Ubuntu Focal) "autofs: Assertion 'set_remove(iterator->links, link) == link' failed at src/shared/userdb.c:314, function userdb_on_query_reply(). Aborting." [Undecided,Triaged] | 18:14 |
| rafaeldtinoco | i ask you because of this ^ | 18:14 |
| rafaeldtinoco | its not directly related but ... | 18:14 |
| rafaeldtinoco | I think they're populating an internal user caching database (or something similar) through varlink, coming from pam-systemd to logind | 18:15 |
| xnox | rafaeldtinoco: can you explain how the two are related? | 18:15 |
| rafaeldtinoco | xnox: reading code for couple of hours only.. looks like varlink protocol gets information and populates the userdb feature | 18:16 |
| rafaeldtinoco | the only thing that would consume that now would be userdbctl (and some other internal stuff.. not sure which) | 18:16 |
| rafaeldtinoco | so.. its a varlink server getting stuff from something (pam-systemd), populating userdb and crashing because of an assert() going wrong (possibly a varlink protocol error) | 18:17 |
| rafaeldtinoco | but without a dump its hard to tell, and I was trying to avoid setting up all stuff related :\ | 18:18 |
| xnox | rafaeldtinoco: right, but how come autofs (which is standalone project, that doesn't call into systemd at all) causes such a crash? | 18:18 |
| xnox | rafaeldtinoco: from the bug report, the user is not using systemd.automount units. | 18:18 |
| rafaeldtinoco | xnox: through NSS | 18:18 |
| rafaeldtinoco | autofs -> sssd -> NSS -> pam -> systemd | 18:18 |
| xnox | interesting | 18:18 |
| rafaeldtinoco | not sure why systemd is acquiring info from NSS | 18:19 |
| xnox | i don't think one can safely use sssd with pam_systemd | 18:19 |
| rafaeldtinoco | xnox: yep, I thought the same | 18:19 |
| rafaeldtinoco | about asking end user to disable pam_systemd | 18:19 |
| rafaeldtinoco | and checking if the forwarding stuff to logind | 18:19 |
| rafaeldtinoco | would stop the crash (and the userdb to be populated) | 18:19 |
| xnox | rafaeldtinoco: well, that's not a solution, it breaks DynamicUsers= in all the service units then. | 18:19 |
| rafaeldtinoco | :\ | 18:19 |
| xnox | rafaeldtinoco: i am interested in a minimal reproducer what/how NSS is poked that is causing the assertion. | 18:20 |
| rafaeldtinoco | yep | 18:20 |
| rafaeldtinoco | lets see if user replies, if not | 18:20 |
| xnox | rafaeldtinoco: have you managed to reproduce the issue? cause it sounds like a bug in systemd's nss module then. | 18:20 |
| rafaeldtinoco | i may try to reproduce locally | 18:20 |
| rafaeldtinoco | i was interested why userdb was into play | 18:21 |
| xnox | i only skimmed through the bug, so didn't see exact steps on how to trigger it. | 18:21 |
| rafaeldtinoco | couldnt find any consumer | 18:21 |
| xnox | there might be bugs in pam_systemd when it is built _without_ userdb, or specifically when systemd-homed.service is not available to it. | 18:21 |
| xnox | tripping up a runtime assert. | 18:21 |
| rafaeldtinoco | yep, that might be one case | 18:22 |
| rafaeldtinoco | alright, will put this on hold until reporter gets something back | 18:22 |
| rafaeldtinoco | OR will try to reproduce in a free time moment | 18:22 |
| xnox | mwhudson: https://bileto.ubuntu.com/#/ticket/4259 uploaded plausible looking golang-defaults there, triggered autopkgtests. | 19:40 |
| xnox | mwhudson: also want to like rebuild all the things against that bileto to see if there is large fallout or not. | 19:40 |
| mwhudson | xnox: um ok, i don't really see the need to run ahead of debian but ok | 22:58 |
| xnox | mwhudson: it looks okish https://bileto.ubuntu.com/excuses/4259/groovy.html not sure about mdns thing, but ubuntu-report will need a fix i think. | 23:12 |
| xnox | mwhudson: why is debian not switching? | 23:12 |
| mwhudson | xnox: don't know | 23:12 |
| xnox | mwhudson: you are uploader ;-) | 23:13 |
| mwhudson | client_test.go:501: exchange took longer 29.967138ms than specified Timeout 11ms | 23:13 |
| mwhudson | yay wall clock tests | 23:13 |
| mwhudson | xnox: true! | 23:13 |
| Unit193 | Curious, if a package doesn't build on riscv and is in universe, can one force it to publish anyway? :> | 23:14 |
| xnox | Unit193: explain a little more, we only block regressions => if a package never built on riscv64, it will not block publication/migration. | 23:15 |
| xnox | Unit193: is it a regression? in that case manual intervention needed (either fixing it, or to remove the riscv64 dep from release pocket) | 23:15 |
| Unit193 | xnox: Yeah it used to pass, but now fails on mips and riscv, but it's a desktop Qt application so it's unlikely to be used there. | 23:16 |
| Unit193 | PPAs don't have riscv, so it's not as easy to test fixes. | 23:16 |
| xnox | Unit193: what is the src package name? | 23:25 |
| xnox | Unit193: =) | 23:25 |
| Unit193 | barrier. | 23:25 |
| xnox | mwhudson: can't reproduce ubuntu-report failure | 23:28 |
| xnox | dunno what's happening there. | 23:28 |
| xnox | Unit193: hit retry, it looks like it should be affecting all arches | 23:28 |
| Unit193 | Built in tests and for Debian on other arches.. | 23:30 |
| mwhudson | xnox: hmm | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!