[07:08] <acheronuk> doko: why did you do 'Explicitly build using clang 7' for clazy? was that to do with kdevelop using 7?
[10:53] <doko> acheronuk: build issues? I can't remember. Did you you for build failures?
[10:53] <doko> in the publishing history
[10:55] <acheronuk> doko: yeah, 1st thing I looked at. no fails that I could see.
[10:57] <acheronuk> perhaps just as clang/llvm 8 was not officially released at that time?
[10:57]  * acheronuk shrugs
[11:04] <LocutusOfBorg> tjaalton, vulkan-loader sync?
[11:04]  * LocutusOfBorg wants to see if vkQuake can run with it
[11:15] <lag> cyphermox: waveform: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1819443
[11:15] <ubottu> Launchpad bug 1819443 in debian-installer (Ubuntu) "Cannot boot installer on platforms requiring Device Tree" [Undecided,New]
[11:15] <lag> dannf: xnox: -^
[11:20] <xnox> lag, commented
[11:23] <doko> LocutusOfBorg: virtualbox ping for openjdk-11
[11:28] <tjaalton> LocutusOfBorg: i'd rather get them all first to the se version
[11:28] <tjaalton> *same
[11:29] <tjaalton> though i don't think it'd matter much if -validationlayers is synced later
[11:31] <cascardo> LocutusOfBorg: can you take a look at https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1819352 ? patch attached
[11:31] <ubottu> Launchpad bug 1819352 in virtualbox (Ubuntu) "virtualbox 6.0.4-dfsg-5 ADT test failure with linux 5.0.0-7.8" [Undecided,Fix released]
[11:55] <lag> xnox: LP won't let me reply to you: "Timeout error, please try again in a few minutes."
[11:57] <xnox> lag, i know, we must be running postgres triggers again, which stalls commenting for "a while"
[11:57] <xnox> lag, i am sitting on two tabs with bug comments myself.
[11:58] <lag> xnox: Nightmare
[11:59] <xnox> wgrant, what version of postgres does launchpad run? I am told, newish postgres can do parallel/out-of-bound rebuilds of indexes and stuff, atomically, without blocking writes to tables.... And same helpful people do sell consultancy to upgrade people to newer postgresis.
[12:00] <xnox> lag, ok managed to post two bug updates just now!
[12:00] <wgrant> xnox: We're on 9.3, but the upgrade to 10 is pretty much prepped.
[12:00] <xnox> wgrant, shiny!
[12:02] <lag> xnox: Sweet, thanks!  \o/
[12:30] <LocutusOfBorg> doko, I finished the work yestterday
[12:30] <LocutusOfBorg> cascardo, ???
=== alan_g_ is now known as alan_g
[12:36] <LocutusOfBorg> cascardo, please check release archive :)
[12:36] <LocutusOfBorg> tjaalton, thanks!
=== ricab is now known as ricab|lunch
[13:24] <Laney> xnox: yo, so I was just looking at systemd/arm64
[13:24] <Laney> the boot-and-services seems flaky wrt gdm3 and test_no_options
[13:24] <Laney> test_no_options looks for the kernel commandline in the journal but I think that's hidden by "Missed 50 kernel messages"
[13:25] <Laney> which is "journal can't keep up with messages", not normal journald rate limiting afaics
[13:31] <Laney> not sure about gdm3; guess: much slower to start up than the other things being tested, and the test is run "too early"?
[13:46] <cascardo> LocutusOfBorg: awesome! thanks!
[13:55] <xnox> Laney, i can test the "too early" condition.
[13:55] <xnox> Laney, re: missed kernel messages -> i have no idea how to fix it, or why it happens. I wonder if kmsg kernel round robin buffer is too small?
[13:56] <xnox> Laney, at one point I had both of those tests blacklisted. But possibly in Ubuntu packaging only, not in Debian/upstream.
[13:57] <Laney> if we can't rely on actually seeing the kernel messages, maybe stop testing for them?
[13:58] <Laney> I was looking in disco, so I guess the blacklisting got lost at some point :>
[13:59]  * Laney goes to eat a sandwich and fail at the cryptic crossword
[14:12] <xnox> Laney, well. it's bad that we loose boot time dmesg on arm64 and nowhere else.
=== ricab|lunch is now known as ricab
[14:30] <kstenerud> Does anyone know how debian/control is generated from debian/control.in? When I run debian/rules in php7.2, it generates a php7.2-intl package entry in the generated debian/control, but there's no such thing in control.in
[14:32] <kstenerud> so where is php7.2-intl coming from?
[14:34] <cjwatson> There isn't a general answer; generation of debian/control from debian/control.in is package-specific and you'll find it somewhere under debian/
[14:34] <cjwatson> (It's also largely a deprecated procedure because there are so many pitfalls)
[14:37] <cjwatson> I suspect that debian/rules.d/ext-intl.mk has something to do with it
[14:39] <cjwatson> Looks as though each extension that gets added to ext_PACKAGES is substituted into debian/php-module.control.in and concatenated
[14:41] <kstenerud> hmm ok
[14:41] <kstenerud> I'm feeling a bit lost actually
[14:41] <kstenerud> php7.2-intl is supposed to depend on libicu, but it doesn't, and that causes problems for php packages that use internationalization
[14:41] <kstenerud> but when I look at php7.3, there's also no mention of libicu, and it just works
[14:43] <kstenerud> so maybe it's just coincidence that libicu just happened to be somewhere in the dependency tree and it worked by chance?
[14:50] <cjwatson> In general terms, that sort of thing should normally be handled by build-depending on libicu-dev, having the upstream build system detect its presence and link to it, and then the runtime dependency should automatically be substituted into ${shlibs:Depends}
[14:50] <cjwatson> Hardcoding the runtime dependency would normally be a mistake
[14:52] <juliank> Oh well, the new gbome-shell seems to be a fail
[14:52] <juliank> ooh my Cursor is moving
[14:52] <juliank> Ah it just took half a second to start
[14:52] <kstenerud> hmm... it does depend on libicu-dev, and yet packages that depend on php-intl fail with an unknown symbol that is in libicu...
[14:55] <juliank> [   51.971819] Freezing of tasks failed after 20.008 seconds (5 tasks refusing to freeze, wq_busy=0):
[14:55] <juliank> this is odd
[14:56] <juliank> It was trying to freeze user space processes at 51:29, 51:49, 52:11, and 52:32
[14:56] <tsimonq2> !dmb-ping
[14:56] <ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
[14:58]  * juliank upgrades and tries a reboot again
[15:09] <Laney> xnox: maybe, but as long as this dropped messages thing can happen it seems like there's no guarantee there
[15:09] <xnox> Laney, true.
[15:38] <juliank> OK, so it was topicons plus (installed from gnome.org) that was delaying the start
[15:38] <juliank> Now I'm on a "GNOME" wayland session and can't get back to X
[15:40] <seb128> juliank, what's the issue with the X session?
[15:40] <juliank> seb128: oh I don't have a GNOME X session, only (I guess) an Ubuntu one
[15:40] <juliank> oh, I think GNOME classic uses X, but it's stuck in classic mode obviously
[15:41] <seb128> hum, I though we had both for GNOME, wayland/X
[15:43] <juliank> seb128: Today's disco offers "GNOME", "GNOME Classic", "Ubuntu", and "Ubuntu on Wayland"
[15:46] <juliank> seb128: Deleted /usr/share/wayland-sessions/gnome.desktop, and now I got GNOME on Xorg
[15:46] <juliank> odd
[15:46] <seb128> hum, I don't remember the details on why/how we did that
[15:46] <seb128> didrocks maybe does
[15:47] <seb128> but it sounds buggy to me, unless we did change that for a reason
[15:49] <didrocks> I think default should only show Ubuntu/Ubuntu on Wayland
[15:49] <didrocks> gnome-session which provides GNOME/GNOME Classic isn't installed by default AFAIK
[15:49] <didrocks> (should be checked in the manifest though if something isn't pulling it by error)
[15:49] <juliank> didrocks: I do have that installed
[15:50] <juliank> didrocks: manually
[15:50] <didrocks> juliank: so, you asked for it, you got it :)
[15:50] <Laney> he's saying "gnome on xorg" is missing
[15:50] <juliank> didrocks: The problem is not that I'm in a GNOME session, but that there is no "GNOME on Xorg" appearing
[15:51] <juliank> Unless I deleted gnome.desktop in wayland-sessions, then it popped up
[15:51] <juliank> s/Unless/Until/
[15:51] <didrocks> yeah, I guess the decision for GNOME vanilla was to use wayland by default
[15:51] <didrocks> and let the fallback to Xorg
[15:51] <didrocks> as upstream desired vanilla experience
[15:51] <didrocks> that was discussed a long time ago, with Jeremy or in meeting
[15:52] <juliank> so, if gnome failed, it would fallback to gnome-xorg?
[15:52] <didrocks> yeah
[15:52] <juliank> Oh well
[15:52] <juliank> Gotta fix gnome-terminal on Wayland
[15:52] <didrocks> (to be more precise, this is done when GDM is loaded, so if GDM can't load gnome-shell on wayland, it will fallback)
[15:52] <didrocks> I'm sure seb128 will be happy if you fix it on Wayland :)
[15:53] <juliank> I have a custom gnome-terminal window with --class and --name, and it just shows up as "gnome-terminal-server" in wayland in the dock
[15:53] <juliank> Which is not particularly helpful :)
[15:53] <didrocks> we already did a lot of maintainance/fix for that on Xorg
[15:54] <didrocks> I'm sure it's equally broken for different reasons on Wayland
[15:54] <juliank> Last login, normal gnome-terminal also showed up as gnome-terminal-server with "?" icon
[15:54] <juliank> until I closed all terminal windows and started terminal again :D
[15:54] <seb128> didrocks, thx, I didn't remember if not showing "GNOME on xorg" was a decision or a bug
[15:54] <seb128> sounds like decision
[15:55] <seb128> good :)
[15:55] <juliank> Aside from gnome-terminal application mapping, wayland has been fairly stable when I used it
[15:56] <seb128> good to know :)
[15:59] <juliank> and now it has fractional scaling I suppose
[16:13] <bdmurray> has anybody looked at this failing test? http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/i386
[16:16] <ahasenack> bdmurray: that rings a bell
[16:17] <ahasenack>   * d/t/build-procenv: only install the built package if the chroot it was
[16:17] <ahasenack>     built in matches the release of the host system (LP: #1806388)
[16:17] <ubottu> Launchpad bug 1806388 in sbuild (Ubuntu) "DEP8 test builds uninstallable package most of the time" [Undecided,Fix released] https://launchpad.net/bugs/1806388
[16:19] <bdmurray> ahasenack: okay, I'll hint it for now then
[16:19] <bdmurray> ahasenack: Do you have any plans to SRU it?
[16:21] <ahasenack> wasn't going to, but I could
[16:21] <ahasenack> on its own, or is there some other sbuild sru that's imminent?
[16:21] <ahasenack> if we hit this frequently enough, might be worth on its own
[16:27] <bdmurray> How could we sort out what packages have autopkgtest relations with sbuild?
[16:27] <LocutusOfBorg> klebers, can you please test https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1818049 ?
[16:27] <ubottu> Launchpad bug 1818049 in virtualbox-hwe (Ubuntu Xenial) "virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function ‘get_user_pages’]" [High,Fix committed]
[16:29] <klebers> LocutusOfBorg, I triggered autopkgtests with the kernels in proposed, I'll report the results back on the bug
[16:41] <ahasenack> bdmurray: don't know, I'm not sure how it's decided which dependent autopkgtests are run, if it comes straight out of reverse depends or not
[16:42] <Laney> and Testsuite-Triggers
[16:49] <paride> xnox, vorlon, just a ping on https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1819438 tl;dr disco d-i fails on ppc64, the system is uninstallable
[16:49] <ubottu> Launchpad bug 1819438 in debian-installer (Ubuntu) "Install fails on ppc64: partman: *** stack smashing detected ***" [High,New]
[16:49] <ahasenack> even exim4 triggered an sbuild run
[16:56] <LocutusOfBorg> klebers, see release channel
[17:04] <vorlon> paride: thanks. do you know about the rls-dd-incoming tag to flag bugs to us for evaluation as RC?
[17:04] <paride> vorlon, I don't.
[17:05] <vorlon> now you do ;)
[17:05] <paride> vorlon, so I just tag it rls-dd-incoming if I believe it to be RC?
[17:06] <vorlon> yes
[17:06] <paride> vorlon, done :)
[17:06] <vorlon> paride: glibc published to the release pocket on March 5.  Perhaps this is fixed by the rebuild of d-i that just made it to the release pocket https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu566 do you want me to respin images so you can retest?
[17:08] <paride> vorlon, that would be great, yes
[17:09] <vorlon> paride: partman-base was *also* updated on March 5 so that's the next stop if the d-i rebuild didn't fix it
[17:11] <vorlon> paride: running now at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server/+build/158934
[17:18] <vorlon> (also: lame that nothing in the build log lists the version of d-i used)
[17:19] <vorlon> oh, I guess that'd have to be in the debian-cd log and not the livefs log
[18:05] <paride> vorlon, seems to be working now :)
[18:05] <vorlon> paride: excellent
[18:05] <paride> vorlon, I'll let the test run finish and then close the bug
=== imcleod_ is now known as imcleod
[22:32] <mwhudson> does anyone have a grab bag of reasons a package might fail to build on launchpad bug succeed locally
[22:32] <mwhudson> network access is the obvious one i guess but i don't think it's that
[22:34] <doko> fresh or tainted local chroot?
[22:36] <rbasak> In main but universe dependencies required
[22:36] <rbasak> --resolve-alternatives or simliar needed but not used
[23:09] <Unit193> ddstreet: Howdy, looks like you put some effort into ubuntu-dev-tools (https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537), any chance you're going to merge that in to upstream and release to the archive?
[23:09] <ubottu> Launchpad bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,In progress]
[23:11] <CarlFK> mwhudson: on lp there is a log that should tell you
[23:12] <CarlFK> mwhudson: er, for ppa anyway.  which is all I'm familiar with.
[23:12] <mwhudson> doko: i make a fresh chroot for the test
[23:12] <mwhudson> CarlFK: yeah, i'm well up with reading logs :)
[23:12] <mwhudson> rbasak: yeah --resolve-alternatives is a good one but i don't think it applies here (and usually causes problems the other way around)
[23:14] <Unit193> CarlFK: FWIW, yes official builds also have logs.