=== pieq_ is now known as pieq
[06:55] <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.)
[07:07] <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:09] <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:11] <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:51] <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:52] <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
[08:13] <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?
=== StevenK is now known as Guest1882
[10:23] <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:32] <LocutusOfBorg> xnox, I'm doing two tests
[10:32] <LocutusOfBorg> 1) groovy, gcc-9, ghc 8.8.4
[10:33] <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:55] <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:56] <xnox> LocutusOfBorg:  ubuntu & debian toolchains are mostly even around the relevant builds, and yet ubuntu build took 8days vs ~12h in debian
[10:59] <Laney> use Debian's to bootstrap it
[11:04] <LocutusOfBorg> Laney, xnox no change rebuilding the focal version in focal archive should answer that question, right?
[11:05] <LocutusOfBorg> I noticed a slow-down between the last 8.6 build and the first 8.8 build
[11:06] <Laney> probably the backport you already have going will be good data
[11:07] <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:09] <Laney> k
[11:09] <Laney> whatever, the focal build
[11:14] <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
=== StevenK is now known as Guest88139
=== StevenK_ is now known as StevenK
[12:03] <rbalint> seb128, yes, the cross toolchain needs to be updated
[12:04] <seb128> rbalint, is anyone working on that?
[12:07] <rafaeldtinoco> bom dia!
[12:07] <rbalint> seb128, i'm working on everything around glibc including this one, but help is appreciated
[12:08] <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:56] <doko> rbalint: yes, I'll do that tomorrow
[12:57] <rbalint> doko, if it is just https://pastebin.ubuntu.com/p/HDxcKS8sYW/ and regenerating control i can land it today
[14:14] <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 ^
=== popey8 is now known as popey
[15:56] <seb128> RikMills, could you do the kde rebuilds needed for the new poppler?
[15:57] <RikMills> seb128: ok, will do shortly
[15:58] <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
[16:53] <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
=== paride is now known as paride|off
[18:12] <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:13] <rafaeldtinoco> xnox: gotcha.
[18:13] <xnox> rafaeldtinoco:  and possibly incorrectly scoped upstreamed. I think it comes with homed, and not otherwise compiled.
[18:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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
[19:40] <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.
[22:58] <mwhudson> xnox: um ok, i don't really see the need to run ahead of debian but ok
[23:12] <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:13] <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:14] <Unit193> Curious, if a package doesn't build on riscv and is in universe, can one force it to publish anyway? :>
[23:15] <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:16] <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:25] <xnox> Unit193: what is the src package name?
[23:25] <xnox> Unit193:  =)
[23:25] <Unit193> barrier.
[23:28] <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:30] <Unit193> Built in tests and for Debian on other arches..
[23:30] <mwhudson> xnox: hmm