[02:59] <infinity> slangasek: I'm curious about that livecd-rootfs change.
[03:00] <infinity> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on lgw01-amd64-026.buildd
[03:01] <infinity> ^-- From a build log today on the host that you linked your failed build from.
[03:02] <infinity> slangasek: I'm less convinced that the hostname filtering is the issue, and more convinced that that code just plain hasn't been tested in years (it was last used for the panda ubuntu-server preinstalled image).
[03:08] <infinity> slangasek: It's possible that 'if [ -z "$MIRROR" ]; then' isn't tripping, which would cause one to think it was broken the way you saw.
[03:39] <infinity> slangasek: OH!
[03:39] <infinity> slangasek: FFS.
[03:42] <infinity> slangasek: Bug updated.  Also, I feel dumb for not using my own debugging info in the log the first time. :P
[03:43] <infinity> Yay for layers of complexity on top of layers of complexity. :/
[03:44] <sarnold> you sound like you could use a nice new clean abstraction layer on top of everything to simplify things!
[03:44]  * sarnold runs
[03:45] <infinity> sarnold: *glare*
[03:51] <tsimonq2> Sounds to me like problems were *stacking* up, much like the abstraction layers :P
[03:51]  * tsimonq2 runs
[03:52] <slangasek> infinity: ah, heh. thoughts on a reasonable fix? lp-*?
[03:52] <infinity> slangasek: That's what I'm comitting now.
[03:52] <slangasek> ok
[03:52] <infinity> slangasek: While also cleaning out some older entries.
[03:52] <slangasek> :)
[03:52] <infinity> slangasek: And making .buildd a thing again.
[03:52] <slangasek> ok
[04:00] <infinity> slangasek: Of course, fixing this still leaves the open quest of "do we really want to germinate uncondictionally for every single build?" which seems a bit nutty.
[04:01] <infinity> slangasek: Laney cargo-culted my code I was using to build a /pool/, for which germinate was a useful tool, but now it's running for literally every build.
[04:03] <infinity> And by "nutty", I mean "expensive".  germinate isn't quick.
[04:03] <tsimonq2> (amen)
[04:16] <slangasek> infinity: my understanding was that this was meant to do a very small subset of germinate for purposes of getting a list of snaps
[04:16] <slangasek> but I haven't reviewed
=== led_ir23 is now known as led_ir22
[05:04] <nacc> slangasek: would the stuff you've been working on today lead to latency copying packages to the archive? just wondering how long to wait on phpunit being available (so I can trigger the rebuilds that are waiting on it)
[05:04] <slangasek> nacc: no
[05:05] <nacc> slangasek: ok :)
[05:05] <nacc> slangasek: i'll be patient then
[05:05] <nacc> i think i've got it unwedged now, just waiting on the copying
[05:06] <wgrant> I don't see any pending copies of phpunit on LP
[05:06] <nacc> hrm
[05:06] <nacc> https://launchpad.net/ubuntu/+source/phpunit/6.5.5-1ubuntu1
[05:06] <wgrant> That looks already copied?
[05:06] <wgrant> Uploaded, in fact.
[05:06] <nacc> maybe i just hit a small window where it wasn't yet copied
[05:06] <nacc> ok i'll retry the builds now
[05:07] <wgrant> What do you mean by copied?
[05:07] <wgrant> Looks to me like you uploaded that directly.
[05:07] <nacc> sorry, built and then actually available for other packages to use
[05:07] <wgrant> Ah, published.
[05:07] <nacc> yeah, wrong term
[05:08] <nacc> wgrant: thanks as always!
[05:08] <wgrant> That can take up to an hour after the build completes.
[05:11] <nacc> wgrant: ok, good to know
[07:50] <doko> rbasak, nacc, cpaelzer: please comment on https://bugs.launchpad.net/ubuntu/+source/moin/+bug/1735388
[07:50] <ubottu> Launchpad bug 1735388 in moin (Ubuntu) "Server seeded Python2 packages" [Undecided,New]
[08:04] <cpaelzer> doko: nacc: answered with my limited insight to the case on the bug
[08:04] <cpaelzer> good enough to start a discussion if needed, because so far it is a "no, because ..." answer
[08:15] <doko> cpaelzer: no, that's good enough
[08:30] <doko> rbasak, cpaelzer: mariadb-10.1 has autopkg test failures since 70 days ...
[08:34] <cpaelzer> doko: rbasak mentioned yesterday that he knows and wanted to take a look
[08:34] <cpaelzer> it was something more complex, but consider it actively worked on by him
[08:35] <cpaelzer> sil2100: thanks for the ack, and I see you linked it up in the wiki already
[08:35] <doko> just asking because it blockes thinks
[08:35] <cpaelzer> yeah he mentioned that as well
[08:37] <tjaalton> doko: do you have any idea why dfvfs fails to build on bionic, fine on sid? I think it's blocking pyasn1, or at least one of the blockers
[08:37] <tjaalton> a test fails
[08:40] <doko> tjaalton: given back now, but there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888139
[08:40] <ubottu> Debian bug 888139 in src:dfvfs "dfvfs FTBFS: ERROR: testScanFVDE (helpers.source_scanner.SourceScannerTest)" [Serious,Open]
[08:41] <tjaalton> ah
=== Elimin8r is now known as Elimin8er
[08:42] <doko> tjaalton: but the ubuntu one is different, floating point exception
[08:42] <tjaalton> yeah
[08:42] <tjaalton> testFind
[09:24] <doko> rbalint: opengcs ftbfs on 32bit archs
[09:25] <rbasak> doko: if you need mariadb-10.1 through, I think it's appropriate to force-badtest it.
[09:26] <doko> rbasak: can you address this on #ubuntu-release please?
[09:26] <rbasak> doko: I filed Debian bug 888956 yesterday
[09:26] <ubottu> Debian bug 888956 in src:mariadb-10.1 "dep8 tests regressed by removal of mariadb-test" [Important,Open] http://bugs.debian.org/888956
[09:27] <rbasak> doko: you mean change channel? Or something else?
[09:27] <doko> I mean, we entangle now everything with everything, so one more package not migrating probably doesn't matter
[09:27] <doko> rbasak: yes
[09:48] <rbalint> doko: yes, i know, it is an upstream issue but since it works only in windows hyper-v vms only amd64 is interesting
[09:49] <rbalint> doko: i just open LP: #1746697 to track the failure
[09:49] <ubottu> Launchpad bug 1746697 in opengcs (Ubuntu) "Opengcs FTBFS on 32 bit architectures" [Low,New] https://launchpad.net/bugs/1746697
=== est31 is now known as est
=== CadBane_ is now known as CadBane
[12:05] <doko> LocutusOfBorg: you can't build a package in main with dietlibc, it's in universe, and I don't see the point doing that at all
[12:06] <LocutusOfBorg> doko, why gdbm (1.8.3-14 to 1.14.1-2)
[12:06] <LocutusOfBorg>     Maintainer: Dmitry Bogatov
[12:06] <LocutusOfBorg>     0 days old
[12:06] <LocutusOfBorg>     Valid candidate
[12:06] <LocutusOfBorg> britney seems happy with that...
[12:08] <doko> not component mismatches
[12:20] <doko> jbicha: what's going on with dconf/d-conf?
[12:32] <jbicha> doko: someone needs to figure out why a 2-line patch appears to break notify-osd's autopkgtest on armhf
[12:32] <jbicha> https://git.gnome.org/browse/dconf/commit/?id=701d19d1
[12:33] <jbicha> and we're renaming d-conf to dconf
[12:46] <GunnarHj> tjaalton: Hi Timo, do you have time to sponsor bug #1746544?
[12:46] <ubottu> bug 1746544 in xkeyboard-config (Ubuntu) "Upgrade to xkeyboard-config 2.23" [High,In progress] https://launchpad.net/bugs/1746544
[12:48] <tjaalton> GunnarHj: someone just complained about 2.23 breaking something
[12:49] <tjaalton> on #xorg-devel
[12:49] <GunnarHj> tjaalton: Oh.. Will take a look.
[12:49] <tjaalton> 14:19 < arekm> hm, xkeyboard-config 2.22->2.23 and: $ setxkbmap pl
[12:49] <tjaalton> 14:19 < arekm> Error loading new keyboard description
[12:49] <tjaalton> could be user error
[12:51] <GunnarHj> tjaalton: I played with 2.23 successfully yesterday. Is #xorg-devel on freenode?
[12:51] <tjaalton> yes
[12:55] <GunnarHj> bbl
[13:07] <doko> ginggs:  sbuild-build-depends-hwloc-contrib-dummy : Depends: nvidia-cuda-dev but it is not going to be installed
[13:11] <doko> tsimonq2: is kubuntu interested in https://launchpadlibrarian.net/355405407/buildlog_ubuntu-bionic-amd64.choqok_1.6-1.isreally.1.5-4ubuntu2_BUILDING.txt.gz ? if yes, please fix, or else we should remove
[13:13] <tsimonq2> doko: If it's KDE 4 or Qt 4, RM; otherwise we're interested if it's seeded.
[13:13] <tsimonq2> (on mobile, can't check)
[13:14] <doko> libtelepathy-qt4-dev,
[13:15] <doko> debian has a recent version ...
[13:15]  * tsimonq2 looks
[13:16] <doko> tsimonq2: that probably should be merged again
[13:17] <tsimonq2> doko: ack, want to do that or should I?
[13:18] <doko> tsimonq2: please do
[13:18] <doko> I have no idea about the kubuntu specific patch
[13:18] <tsimonq2> doko: Ok, will do later, ta
[13:44] <GunnarHj> tjaalton: I can confirm that there is an issue with the Polish layout, but can't tell why. Uploaded 2.23.1 to the PPA - let's see if that makes a difference.
[13:55] <tjaalton> GunnarHj: alright
[14:24] <rbasak> nacc: could you glance at http://autopkgtest.ubuntu.com/packages/p/php-horde-activesync/bionic/amd64 please? It's holding up mysql-5.7 on some test dependency problem. Is this related to your recent PHP work?
=== juergh_ is now known as juergh
[15:07] <GunnarHj> tjaalton: 2.23.1 didn't help, but I spotted it: https://bugs.freedesktop.org/show_bug.cgi?id=104904
[15:07] <ubottu> Freedesktop bug 104904 in General "Polish symbols file broken by typo" [Critical,New]
[15:07] <GunnarHj> Probably they'll soon release a new version; let's wait a bit.
[15:08] <tjaalton> GunnarHj: ok, I'll push that to debian then
[15:10] <GunnarHj> tjaalton: Well, nothing of this is in Debian yet... https://bugs.debian.org/884822
[15:10] <ubottu> Debian bug 884822 in src:xkeyboard-config "Please upgrade to 2.22" [Wishlist,Open]
[15:10] <tjaalton> GunnarHj: if that simple patch fixes it then that could be added as a distro patch for now..
[15:11] <GunnarHj> tjaalton: Sure, I can do another upload to the PPA with that patch, if you like.
[15:11] <tjaalton> no need
[15:11] <tjaalton> is there a diff to ubuntu?
[15:11] <tjaalton> or is it synced
[15:12] <GunnarHj> tjaalton: There is a permanent Ubuntu delta.
[15:32] <tjaalton> GunnarHj: uploaded to debian, merge with that
[15:35] <doko> juliank, xnox: about the systemd ftbfs on arm64. I think binutils is right. so can you find out why crt0-efi-aarch64.o has such a relocation?
[15:36] <xnox> doko, ooooooouuuugh
[15:36] <xnox> doko, I bet you will be running around brussels yelling at me "fix systemd kthxbye"
[15:37] <GunnarHj> tjaalton: Ok, will do. (Which will be similar in substance to adding that pl patch.)
[15:37] <doko> well, fix it before brussels ;p
[15:37] <juliank> maybe it's a gnu-efi bug :D
[15:38] <juliank> I have a PPA for the new gnu-efi https://launchpad.net/~juliank/+archive/ubuntu/gnu-efi-staging
[15:38] <juliank> but no aarch64 build
[15:38] <juliank> that is, arm64 is not enabled there.
[15:38] <doko> well, you can enable it
[15:38] <juliank> doko: Will it rebuild gnu-efi in there then?
[15:39] <juliank> or rather, build it for that
[15:39] <juliank> I can also copy all stuff in a new PPA
[15:39] <doko> not sure if it automatically creates a new build record. maybe just re-upload after enabling arm64
[15:39] <juliank> I just copy-package gnu-efi and systemd into gnu-efi2 PPA :D
[15:42] <juliank> Ugh, I'm terrible at this
[15:46] <juliank> gnu-efi is building in  https://launchpad.net/~juliank/+archive/ubuntu/gnu-efi-arm64 now
[15:47] <juliank> I probably should just fix refind and roll out that transition via bileto in one go if that fixes systemd.
[15:48] <doko> juliank: is proposed enabled in this ppa?
[15:48] <xnox> juliank, well, if there is something to patch in systemd, it's best to send pull request to systemd upstream; and in packaging we have a handy git-cherry-pick script to cherrypick the patch by commit id.... which debian also needs.....
[15:48] <xnox> and then just merge into ubuntu as usual.....
[15:49] <cjwatson> you could have just copied the package over the top of itself with --include-binaries
[15:49] <cjwatson> that schedules any missing builds
[15:49] <xnox> wow
[15:50] <xnox> neat
[15:59] <juliank> cjwatson: wow
[16:00] <rbasak> Skuggen: ^
[16:00] <rbasak> Skuggen: that might solve your PPA question earlier :)
[16:04] <doko> xnox, juliank: I also tried to disable lto in systemd, but the issue persists. but in general, it's always better to debug issues like these without lto first
[16:17] <nacc> rbasak: yes, it needs the new phpunit and a few other things, which are going through now
[16:18] <rbasak> Ah, thanks.
[16:18] <rbasak> Skuggen: the tool you'd need is copy-package from ubuntu-archive-tools
[16:18] <rbasak> Skuggen: "bzr checkout --lightweight bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-archive-tools/"
[16:25] <nacc> rbasak: i belileve if you use phpunit from proposed it shoudl work, or you can wait till i get the transition done
[16:30] <doko> juliank: your arm64 ppa doesn't have proposed enabled
[16:31] <rbasak> nacc: I'm not sure how to do that for proposed migration. Or can the release team do that with a hint?
[16:31] <juliank> doko: ooh, now I understand.
[16:31] <juliank> ugh
[16:31] <nacc> rbasak: you can do it
[16:31] <nacc> rbasak: take the url & triggers=phpunit/<version> (iirc)
[16:31] <nacc> rbasak: it's documented on the wiki
[16:32] <nacc> rbasak: i can do it later today too
[16:32] <rbasak> Right, but will britney actually pay attention to that specific result?
[16:33] <Laney> Yeah
[16:33] <nacc> yeah
[16:33] <Laney> And you can actually test that if you pass --apt-pocket=proposed=src:pkg1,src:pkg2,... packagetotest locally
[16:33] <nacc> uyeah
[16:34] <nacc> that's what i do locally for the bootstrap
[16:34] <nacc> it just takes a bit to get the archive to that poinnt :)
[16:37] <juliank> doko: Stupid me :(
[17:00] <doko> ginggs: the cuda rdeps now built. pycuda could be be built for ppc64el too
[17:16] <ginggs> doko: thanks, will take a look
[17:24] <ginggs> doko: is there anything still needing gcc-5 now?
[17:25] <doko> ginggs: I didn't look, but it builds =)
[17:31] <ginggs> doko: hmm, didn't build for me - we don't have a libcuda for ppc64el in ubuntu
[17:37] <doko> and there we go, php and ruby transitions in parallel ...
[17:38] <xnox> doko, did you mean golang too?
[17:38]  * xnox is not sure how to read "go, php and ruby" =)
[17:39] <doko> golang is not verb
[17:39] <doko> unless mwhudson goes wild with 1.10 ...
[17:39] <ginggs> anything can be a verb in English
[18:37] <nacc> doko: i should be able to get a lot of php unstuck once the new xdebug migrates from debian
[18:37] <nacc> doko: that's what is preventing phpunit from workign right now
[18:49] <nacc> how often does the auto-syncer run?
[18:52] <cjwatson> 0 5,11,17,23 * * *
[18:53] <nacc> cjwatson: thanks
[18:54] <ginggs> I thought it was 4, 8, 15, 16, 23, 42
[18:55] <cjwatson> I'm not sure what you're thinking of but it must be something else
[18:55] <ginggs> i must be lost
[18:57] <doko> nacc, fyi, I added http://people.canonical.com/~ubuntu-archive/transitions/html/php7.2.html  but there seems to be something wrong. feel free to correct it (just copied from debian)
[18:57] <nacc> doko: ok, thanks
[18:57] <nacc> doko: it's becuase we went ahead of debian
[18:57] <nacc> (to 7.1)
[18:57] <nacc> i'll fix
[18:58] <nacc> doko: actually how do i correct it ?
[18:58] <nacc> doko: it should be phpapi-20160303 for us
[18:58] <nacc> (as bad)
[18:59] <nacc> doko: oh do i just branch the tracker and update?
[19:00] <doko> nacc: yes, but already done
[19:00] <nacc> doko: thankns
[19:00] <doko> you'll see the update in an hour or so
[19:01] <nacc> doko: ok, i'll keep an eye out
[19:04] <nacc> doko: if my grep-dctrl-fu is right, we don't have a ton of packges to rebuild (unit test is a different thing of course)
[19:19] <nacc> slangasek: reading syncpackage, I really shouldn't use --no-lp, right? It would appear that although rmadison sees it, the new xdebug hasn't hit packages.debian and possiby others, and that's what is currently blocking furhter progress for php7.2
[19:20] <nacc> (that is to say, syncpackage does't see the new versionn yet either)
[19:22] <ginggs> nacc: you can syncpackage once it appears here pad.lv/d/xdebug
[19:22] <nacc> ginggs: yep, i can wait for that, i kow
[19:22] <nacc> *know
[19:22] <nacc> ginggs: it's just going to wedge the transition until that shows up :)
[19:23] <slangasek> nacc: you shouldn't use --no-lp because of impatience with the publisher
[19:23] <slangasek> (with the debian importer, rather)
[19:24] <nacc> slangasek: that's what i figured ... will go do something else for a while :)
[20:12] <sleuthkid_> hi everybody. Can anyone point me to the developer(s) of the ubuntu WSL app?
[20:14] <sarnold> sleuthkid_: have you seen this yet? https://github.com/Microsoft/WSL/
=== Guest74281 is now known as karstensrage
=== karstensrage is now known as Guest68163
[20:15] <sleuthkid_> sarnold, I am packaging WSL for Debian and would like to have some exchange about the app code ;)
=== Guest68163 is now known as karstensrage
[20:16] <nacc> sleuthkid_: what ubuntu WSL app?
[20:16] <sarnold> sleuthkid_: oh! :) uhhh. hrm. :)
[20:18] <sleuthkid_> nacc, https://docs.microsoft.com/en-us/windows/wsl/about
[20:19] <nacc> sleuthkid_: right, that's not an ubuntu app
[20:19] <nacc> sleuthkid_: do you mean the WSL instance itself?
[20:20] <nacc> sleuthkid_: or you're not pointing me at the right thing
[20:20] <nacc> sleuthkid_: everything on that page is *for* Windows, afaict
[20:20] <sarnold> nacc: I suspect it's simple preposition confusion, "packaging debian for wsl" rather :)
[20:20] <sleuthkid_> With app I mean the launcher app from the windows store: https://www.microsoft.com/store/p/ubuntu/9nblggh4msv6
[20:21] <nacc> sarnold: ah
[20:21] <nacc> sleuthkid_: you would contact canonical i guess, it's not an ubuntu thing, afaik
[20:33] <sleuthkid_> nacc, thx
[20:35] <doko> nacc: the php tracker looks better now
[20:51] <nacc> doko: yep
[20:51] <nacc> doko: thankns
[21:30] <Tirali> Hello, will there be a backport of smb4k 2.0 for kubuntu 16.04? For 17.10 there is already a version 2.0 of smb4k which works with kernel 4.13
[21:31] <bdmurray> smoser: How is bug 1735225 fixed in bionic and artful?
[21:31] <ubottu> bug 1735225 in resolvconf (Ubuntu Xenial) "root=<url> should automatically enable 'rc-initrd-dns' feature" [Medium,Confirmed] https://launchpad.net/bugs/1735225
[21:35] <nacc> Tirali: why does smb4k depend on the kernel version (not immediatelly obvious)
[21:35] <nacc> Tirali: but i'd file a bug, it's in universe and community maintained
[21:35] <Tirali> kernel 4.13 uses smb v3
[21:35] <Tirali> major change from smb v1 to smb v3 with kernel 4.13
[21:37] <Tirali> i think it does not depend on the kernel, but smb4k needs to support smb v3 and that is only working with smb4k version 2.0, Ubuntu 16.04 has smb4k v1.1.2
[21:37] <nacc> Tirali: right, i'd file a bug
[21:37] <Tirali> in the repo only and there is not backport yet
[21:38] <nacc> Tirali: ubuntu-bug smb4k
[21:38] <Tirali> i have never done this, is there info how to create such a request for an updated smb4k version?
[21:39] <nacc> Tirali: file a bug, describe the issue?
[21:40] <Tirali> is there a bot or a website for doing this?
[21:40] <nacc> Tirali: i just gave you the command?
[21:40] <nacc> Tirali: i'm assuming you are on Ubuntu
[21:40] <Tirali> a ok thx file a bug is the command i think
[21:41] <Tirali> or ubuntu-bug?
[21:41] <nacc> Tirali: `ubuntu-bug smb4k`
[21:41] <Tirali> ah thx
[22:00] <smoser> bdmurray: have to think.
[22:01] <smoser> bdmurray: oh. well, its because resolvconf isnt even involved.
[22:09] <smoser> bdmurray: https://bugs.launchpad.net/maas/+bug/1711760 was the bug that added the fucntionality of hooking up resolvconf to read those files.
[22:09] <ubottu> Launchpad bug 1711760 in resolvconf (Ubuntu Xenial) "[2.3] resolv.conf is not set (during commissioning or testing)" [Critical,Fix released]
[22:12] <smoser> we only put that fix into t, x, z. artful didnt need it. its because resolvconf isnt used there.
[22:13] <smoser> is that enough?
[22:13] <nacc> and phpunit is bootstrapped
[22:13] <nacc> rbasak: --^ fyi for your case, it should be runnable soon (i need to llet phpunit publish, then i can rebuild php-codecoverage and start rerunning tests)
[22:16] <bdmurray> smoser: Yes, I think so.
[22:21] <rbasak> OK. Thanks (and to Laney)
[23:43] <nacc> doko: staring to get some green going onn the transition, so that's good
=== mwsb is now known as chu