=== pieq_ is now known as pieq
slyonHey, 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
RAOFslyon: 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
cpaelzeryes slyon I think I've seen some working07:07
cpaelzerlet me check which of the things I touched have one07:07
slyonRAOF, 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
slyonWould 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-reboot07:11
cpaelzerslyon: nice trap :-)07:51
cpaelzerI wanted to click on the link what I'd retyr, but it already was the retry link :-)07:51
slyonheh :-P07:52
cpaelzeranyway I guess that is ok, if the error reoccurs let us dig deeper on the actual case07:52
slyonthe "core-dev trap"07:52
* cpaelzer hides his cookies07:52
slyoncpaelzer: sounds like a plan! Thanks07:52
seb128rbalint, 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
seb128is that a known issue?08:13
=== StevenK is now known as Guest1882
xnoxLocutusOfBorg:  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
xnoxhm do i have interent10:23
xnoxok, looks like client sent those messages, but didn't show them to me.10:23
xnoxohw ell10:23
LocutusOfBorgxnox, I'm doing two tests10:32
LocutusOfBorg1) groovy, gcc-9, ghc 8.8.410:32
LocutusOfBorg2) focal, no change rebuild of ghc 8.6.510:33
LocutusOfBorgI see things have become worse and worse when you added the s390x byte order fixes, maybe something in the toolchain changed in the meanwhile10:33
xnoxLocutusOfBorg:  i am wondering if ubuntu's ghc got poisoned. Cause it does use previous ghc to bootstrap stage1 ghc.10:55
xnoxLocutusOfBorg:  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
xnoxLocutusOfBorg:  ubuntu & debian toolchains are mostly even around the relevant builds, and yet ubuntu build took 8days vs ~12h in debian10:56
Laneyuse Debian's to bootstrap it10:59
LocutusOfBorgLaney, xnox no change rebuilding the focal version in focal archive should answer that question, right?11:04
LocutusOfBorgI noticed a slow-down between the last 8.6 build and the first 8.8 build11:05
Laneyprobably the backport you already have going will be good data11:06
LocutusOfBorgno backport...11:07
LocutusOfBorgI'm no change rebuilding 8.6.5 with 8.6.511:07
LocutusOfBorgand I'm rebuilding 8.8.4 with 8.8.3 and gcc-911:07
Laneywhatever, the focal build11:09
LocutusOfBorgyes, if 8.6.5 built with 8.6.5 is fast, it means regression in ghc somewhere11:14
LocutusOfBorgif it is slow, means regression in infrastructure somewhere11:14
LocutusOfBorgif 8.6.5 with 8.6.5 is fast, I can try 8.8.4 on top of it, the backport you mentioned11:14
LocutusOfBorgand then copy the binaries from focal to groovy :p11:14
=== StevenK is now known as Guest88139
=== StevenK_ is now known as StevenK
rbalintseb128, yes, the cross toolchain needs to be updated12:03
seb128rbalint, is anyone working on that?12:04
rafaeldtinocobom dia!12:07
rbalintseb128, i'm working on everything around glibc including this one, but help is appreciated12:07
seb128rbalint, 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 out12:08
rbalintdoko, have you by any chance started updating cross-toolchain-base?12:08
dokorbalint: yes, I'll do that tomorrow12:56
rbalintdoko, if it is just https://pastebin.ubuntu.com/p/HDxcKS8sYW/ and regenerating control i can land it today12:57
rafaeldtinocoddstreet: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/188019314:14
ubottuLaunchpad 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
rafaeldtinocofor you to kepe track ^14:14
=== popey8 is now known as popey
seb128RikMills, could you do the kde rebuilds needed for the new poppler?15:56
RikMillsseb128: ok, will do shortly15:57
seb128RikMills, thanks! Debian did that transition already and most things didn't need changes so hopefully those are easy uploads15:58
rafaeldtinocoxnox: out of curiosity only.. is it on purpose we're not packaging userdbctl in systemd ?16:53
rafaeldtinocou happen to know ? or anyone else16:53
=== paride is now known as paride|off
xnoxrafaeldtinoco:  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
rafaeldtinocoxnox: gotcha.18:13
xnoxrafaeldtinoco:  and possibly incorrectly scoped upstreamed. I think it comes with homed, and not otherwise compiled.18:13
xnoxrafaeldtinoco:  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
ubottuLaunchpad 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
rafaeldtinocoi ask you because of this ^18:14
rafaeldtinocoits not directly related but ...18:14
rafaeldtinocoI think they're populating an internal user caching database (or something similar) through varlink, coming from pam-systemd to logind18:15
xnoxrafaeldtinoco:  can you explain how the two are related?18:15
rafaeldtinocoxnox: reading code for couple of hours only.. looks like varlink protocol gets information and populates the userdb feature18:16
rafaeldtinocothe only thing that would consume that now would be userdbctl (and some other internal stuff.. not sure which)18:16
rafaeldtinocoso.. 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
rafaeldtinocobut without a dump its hard to tell, and I was trying to avoid setting up all stuff related :\18:18
xnoxrafaeldtinoco:  right, but how come autofs (which is standalone project, that doesn't call into systemd at all) causes such a crash?18:18
xnoxrafaeldtinoco:  from the bug report, the user is not using systemd.automount units.18:18
rafaeldtinocoxnox: through NSS18:18
rafaeldtinocoautofs -> sssd -> NSS -> pam -> systemd18:18
rafaeldtinoconot sure why systemd is acquiring info from NSS18:19
xnoxi don't think one can safely use sssd with pam_systemd18:19
rafaeldtinocoxnox: yep, I thought the same18:19
rafaeldtinocoabout asking end user to disable pam_systemd18:19
rafaeldtinocoand checking if the forwarding stuff to logind18:19
rafaeldtinocowould stop the crash (and the userdb to be populated)18:19
xnoxrafaeldtinoco: well, that's not a solution, it breaks DynamicUsers= in all the service units then.18:19
xnoxrafaeldtinoco:  i am interested in a minimal reproducer what/how NSS is poked that is causing the assertion.18:20
rafaeldtinocolets see if user replies, if not18:20
xnoxrafaeldtinoco:  have you managed to reproduce the issue? cause it sounds like a bug in systemd's nss module then.18:20
rafaeldtinocoi may try to reproduce locally18:20
rafaeldtinocoi was interested why userdb was into play18:21
xnoxi only skimmed through the bug, so didn't see exact steps on how to trigger it.18:21
rafaeldtinococouldnt find any consumer18:21
xnoxthere 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
xnoxtripping up a runtime assert.18:21
rafaeldtinocoyep, that might be one case18:22
rafaeldtinocoalright, will put this on hold until reporter gets something back18:22
rafaeldtinocoOR will try to reproduce in a free time moment18:22
xnoxmwhudson:  https://bileto.ubuntu.com/#/ticket/4259 uploaded plausible looking golang-defaults there, triggered autopkgtests.19:40
xnoxmwhudson:  also want to like rebuild all the things against that bileto to see if there is large fallout or not.19:40
mwhudsonxnox: um ok, i don't really see the need to run ahead of debian but ok22:58
xnoxmwhudson:  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
xnoxmwhudson:  why is debian not switching?23:12
mwhudsonxnox: don't know23:12
xnoxmwhudson:  you are uploader ;-)23:13
mwhudson    client_test.go:501: exchange took longer 29.967138ms than specified Timeout 11ms23:13
mwhudsonyay wall clock tests23:13
mwhudsonxnox: true!23:13
Unit193Curious, if a package doesn't build on riscv and is in universe, can one force it to publish anyway? :>23:14
xnoxUnit193:  explain a little more, we only block regressions => if a package never built on riscv64, it will not block publication/migration.23:15
xnoxUnit193: is it a regression? in that case manual intervention needed (either fixing it, or to remove the riscv64 dep from release pocket)23:15
Unit193xnox: 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
Unit193PPAs don't have riscv, so it's not as easy to test fixes.23:16
xnoxUnit193: what is the src package name?23:25
xnoxUnit193:  =)23:25
xnoxmwhudson:  can't reproduce ubuntu-report failure23:28
xnoxdunno what's happening there.23:28
xnoxUnit193:  hit retry, it looks like it should be affecting all arches23:28
Unit193Built in tests and for Debian on other arches..23:30
mwhudsonxnox: hmm23:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!