=== _salem is now known as salem_ === salem_ is now known as _salem [04:00] Logan: http://launchpadlibrarian.net/275043606/funny-manpages_1.3-5.1ubuntu1_1.3-5.1ubuntu2.diff.gz <-- What's wrong with this diff? ;) [04:47] pitti: amd64 autopkgtest queues seem stuck. [05:19] pitti: Oh, lcy01 is completely dead. If amd64 autopkgtest uses that region exclusively, that would explain the stall. [05:21] pitti: And while I'm pinging you, there seem to be a mess of trusty langpacks sitting in the queue. I kinda assumed you'd be dealing with those. :) [05:51] infinity: yes, Qt 5.6 + dead lcy01 == tests take forever.. [05:51] infinity: oh, I thought I accepted all trusty langpacks [05:51] infinity: sorry, will process the rest [05:59] infinity: meh, the cleanup/restart script stumbled over "nova list" failing; fixed that now, so the other clouds keep running [06:41] pitti: Seemed curious to me that the i386 queue emptied before the amd64 one. I would have expected them to drain in parallel. [06:42] pitti: We were very careful about this with shared queues in lp-buildd land, FWIW, to make sure that, all things being vaguely equal, upload 1 would get all its builds out before upload 2, etc. [06:42] infinity: britney issues the requests in architecture order, so i386 is always a bit ahead indeed [06:42] maybe this could use some more shuffling [06:42] the main source of imbalance is the retry-autopkgtest-regressinos script though [06:43] pitti: Ahh, see, I'd expect "testing foo triggered by bar" would queue foo/trigger on all arches, then move to quux/trigger all arches, etc. [06:43] that generates stuff sorted by architecture first [06:43] pitti: So, for shared pool arches, they'd together. [06:43] Ish. [06:43] * infinity shrugs. [06:43] britney is per-excuse first, then per architecture, then all the triggered tests for that excuse [06:43] pitti: Minor frustration to be waiting on one arch column for all packages instead of two arch columns for half the packages. [06:44] yes, indeed; but it's not nearly as bad [07:21] pitti: Oh, not sure if I told you, but mvo and I sat down and fixed snapd autopkgtests. [07:21] pitti: I'm waiting to see the results on amd64 before I close LP: #1599799 but the successes on i386 and ppc64el look promising. [07:21] Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] https://launchpad.net/bugs/1599799 [07:28] ooh [07:29] infinity: what was the problem? [07:29] nice! [07:29] mwhudson: Exactly what they error message no one read said the problem was. [07:29] (They created new units and didn't run daemon-reload) [07:29] heh [07:30] i did _ask_ about that [07:30] but i didn't check [07:30] I consider it a pretty glaring misfeature in systemd that they wrote a *Linux-specific* init system and didn't think to, I dunno, leverage inotify correctly. [07:30] But whatever. [07:30] The number of times we reload that daemon to clear the cobwebs from its internal state is insane. [07:30] this wasn't the error I saw in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799/comments/12 [07:30] Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] [07:30] basic-binaries.block[12533]: unable to bind /snap/ubuntu-core/current//bin to /bin. errmsg: Permission denied [07:31] that wasn't a missing daemon-reload [07:31] i think that one was a snap-confine bug [07:31] Yeah, different bug than the one originally reported. [07:31] But both seem fixed. [07:32] * pitti stares at the autopkgtest queue and o_O's [07:32] ooh, new perl [07:32] Yeah. [07:33] I shouldn't have retried the arm64 build. ;) [07:33] Now I have no chance of getting my own retries in. [07:33] Oh well. [07:33] infinity: if it's blocking, I can remove all the perl tests and we re-trigger them later [07:33] pitti: Shouldn't be. I'm just waiting for the snapd/amd64 result, which is currently in limbo. [07:34] pitti: If it comes back successful, I'm happy. [07:34] weird, it hasn't run yet and it's not in the queue [07:34] It disappeared from the queue about 10m ago. [07:34] I assumed that meant it would, I dunno, run. [07:34] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/amd64/s/snapd [07:34] nothing from today yet [07:35] I suppose an lcy01 worker tried to catch it and is now caught in its "retry three times until I give up" loop or so [07:35] What happend after that? End of the queue, or punted to another builder, or dropped on the floor? [07:35] ah no, it's working [07:35] err, running [07:35] s/happend/happens/ [07:36] it just doesn't show on running.shtml for some reason [07:36] Because running.shtml is 10m old? [07:36] Err. [07:36] Older. [07:36] 18m. [07:36] 18 mins [07:38] pitti: I'm curious why the debci pages are static generated instead of cgi. Just trying to be load-friendly? [07:39] infinity: I suppose so; it's quite expensive to generate them, as it shows the entire history of a package [07:39] pitti: Hrm. But, it seems to generate them even when it doesn't have to, so I'm not sure I buy the load argument now. ;) [07:40] pitti: Picking, say, http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5/ at random, no tests run for two days, but page generated 15m ago. [07:40] well, I don't know :) [07:41] pitti: Given the relative infrequency of tests, it would seem smarter to do a shallow "when was the last test run?" compare to a timestamp of a cached earlier-generated page, serve from cache if not stale, generate on the fly if stale. [07:41] Ish. [07:42] infinity: I can't say I like the current design either; it creates literally millions of little files which keeps hitting the "max inodes" ceiling [07:42] and it's expensive to generate indeed [07:42] xfs to the rescue? [07:42] but yeah, it was that or "write it yourself" :) [07:43] I'd have been inclined to write it as a perl/python/php/cgi/whatever and dynamically generate the mess from a DB. But that probably says more about my background than my taste. [07:45] infinity: I think excuses.html is the main thing devs should look at (and it's completely independent of debci); other than that, I could cobble together a simple CLI thing to query past results, but I'm afraid I'm too loaded with other stuff to rewrite a web UI :/ [07:45] pitti: Heh, I'm not suggesting you fix it, just making idle banter. [07:45] pitti: Besides, every page does point me at the git repository, if it really pisses me off enough. [07:46] pitti: Not that I'd go replacing the backend, ain't no one got time for that, but fixing the caching mechanism to not be constantly uselessly stale wouldn't be too hard. [07:46] infinity: it actually would be -- this would be changing the thing from the ground up [07:46] (Though, as it scales up, replacing the backend with a proper DB seems sane) [07:47] infinity: so, I don't think there's any way around downloading the entire metadata from swift as that takes an awful amount of time [07:47] but generating html and the indexes dynamically would be great indeed [07:47] right, sqlite or so would certainly beat individual files :) [07:47] i'm sure there's some shiny nosql db we could use [07:48] I need to read up on nosql stuff to understand why I'm supposed to like it. [07:48] THere's enough psql deployed in Debian and Canonical that that would have been my first choice. [07:48] infinity: no prob to add psql to the charm for sure [07:51] pitti: But, in the current architecture, the obvious fix would be to trigger page generation on incoming scraped results, rather than batch regenerating the world on a timer. [07:52] "Oh look, a psql result" -> regen psql page. [07:52] As it is, it does ALL the pages. [07:52] Which is daft. [07:54] infinity: so if we can talk slangasek into allocating three days for that, we should invite terceiro and fix this up properly [07:54] infinity: I know terceiro has also hit the inode limit, and I'm sure the load on ci.debian.net is similarly high [07:56] pitti: Hahaha. That reminds me. [07:56] infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160727_073957@/log.gz [07:56] PASS [07:56] pitti: ci.ubuntu.com still has a link in the top bar ([Proposed]) to the old jenkins-driven autopkgtest infra. [07:56] pitti: Who owns that? [07:56] pitti: It should point to autopkgtest.ubuntu.com, probably. [07:57] uh, oh, look behind! a three-headed monkey! [07:57] jibel: do you know who owns http://ci.ubuntu.com/ ? [07:57] pitti: And yay on the pass! [07:57] this looks so out of date, I doubt it's still useful at all [07:59] pitti: Hrm, indeed. http://ci.ubuntu.com/smokeng/ seems to stop at wily. [08:10] pitti: How did the user session sprint go? [08:10] pitti: Will we reduce 'reverse-depends upstart' to zero by release? [08:10] Well, zero except for the things with 'upstart' in the name. :P [08:10] infinity: yes, we should; with the PPA the only thing that still needs it is the lightdm unity greeter session, which isn't too hard to fix [08:11] infinity: we converted most things and they are currently being landed [08:11] pitti: Awesome. [08:11] there's a big CI train silo, and landing gnome-session/xubuntu-default-settings etc. is blocked on landing upstart in -proposed and systemd 231-1 [08:12] upsart seems to just be waiting on autopkgtests. [08:12] which is in turn blocked by apparmor in -proposed and the new mdadm xnox is working on (although if that doesn't happen soon enough it's simple enough to upload a workaround in systemd itself until that happens) [08:12] so, just a few days unti the dust settles [08:12] Though, I'm suspicious that the upstart autopkgtests may have disappeared. [08:13] Since I don't buy that the ppc64el tests have been "in progress" since yesterday. [08:13] infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/upstart/20160513_104747@/log.gz [08:13] apt segfault and corrupted cache, I retried it this morning [08:13] before the perl flood I think [08:13] anyway, I have an eye on it [08:21] pitti, no idea, it used to be ev's team [09:56] G'day, I am runnig ubuntu-devel since it's availibilyty and have a quite nasty package dependency I do not know how to solve... [09:56] (it there the right place?) [09:57] Oni_Shadow: what is "ubuntu-devel"? [09:57] my unity8 session was uninstalled by last upgrade and I did not pay attention and now, everything qt related cannot be installer because of unmet dependency whilst my package system is not broken [09:57] Oni_Shadow: do you mean 16.10? [09:57] well devel is a codenam for developement i suppose that points on the lastest nightly builds, currently yaketty. [09:58] Oni_Shadow: you want #ubuntu+1 [09:58] I just want to get qt stuff (like unity8 and konversation) installable again [09:58] on my ubuntu-devel machine [09:58] Oni_Shadow: right, ask in #ubuntu+1 [09:59] Oni_Shadow: this channel is for development of Ubuntu itself (see /topic) [09:59] ok cheers ! [09:59] sorry about that then [10:15] pitti: Did you have time to look at the apport autopkgtest failure yet? I don't really have much time at the moment, but I definitely need to get the apt 1.3 stuff in; and apport fails (and click and ubuntu-make fail for the fixed python-apt - which is likely not my fault, as I only made python-apt work with the new apt) [10:16] * juliank is supposed to hand in some master thesis plan soon, otherwise he would have more time to look at things [10:16] GPG error: http://ddebs.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C8CAB6595FDFF622 [10:16] that's the apport failure [10:17] It does say freeze now, I suppose that's for the alpha 2s tomorrow? [10:18] click just says: "Cannot install /tmp/tmpv7h7mjfk/org.example.debsig-valid-sig_1.0_all.click: Signature verification error: debsig: No applicable policy found." - Not sure what the problem is there [10:19] And ubuntu-make has some jquery coverage issues [10:19] "Couldn't find static file 'jquery.ba-throttle-debounce.min.js'" [10:36] juliank: no, I didn't, sorry; not sure why the new apt doesn't accept the signature, does ddebs.u.c. need to chagne its archive layout somehow? [10:36] pitti: I'm not sure what's going on on ddebs, I thought you might know more. DonKult flipped the switch to treat the warnings as errors in the new release, that's all I know [10:37] Then again, signature ver. issues should have been errors before too [10:38] juliank: indeed, like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/a/apport/20160727_081401@/log.gz [10:38] it's a warning there [10:39] right. [10:39] that's the add repository, install keyring, update again scenario [10:39] That now requires --allow-insecure or --allow-unauthenticated [10:39] * juliank is never sure which is whicht [10:40] (or [allow-insecure=true] in the sources.list) [10:41] juliank: do you know about the python-apt failure? [10:41] this one is easy to fix then. the click and ubuntu-make regressions are far more annoying, as they are completely unrelated to the python-apt upload that triggered them [10:42] I'll put the apport thing on my TODO list [10:42] pitti: the python-apt failure is fixed (should be at least, maybe there's some stderr output I need to get rid of), but the new python-apt is prevented from migrating by click and ubuntu-make which went rogue on their own [10:43] That is, they also fail for other test suite triggers [10:43] right [10:43] so, fine for me to ignore these two [10:44] juliank: for now I'll requeue a retry of proposed python-apt against proposed apt, that should clear up that part [10:45] juliank: will take a bit though, look at the queues on http://autopkgtest.ubuntu.com/running.shtml :/ [10:45] OK [10:47] juliank: p-apt hinted, p-apt for apt retried [10:48] pitti, infinity - can one emulate ppc64el on non-ppc64el hardware? or how do i get my hands onto such a system? need to debug claims that installing with btrfs as root, does not work on ppc64el. [10:48] oh, so a cloud instance won't do for that [10:49] nested qemu perhaps [10:49] (on a cloud instance) [10:51] xnox: You can emulate, yes. [10:52] xnox: It's not fast, mind you. [10:52] xnox: qemu-system-ppc64 -M pseries [10:52] xnox: Or ask slangasek how to get at real hardware, where you can add --enable-kvm to that and not hate yourself. ;) [10:53] in virtmanager i do get architecture ppc64le and pseries option. let me see if i can boot that at all. [10:53] asks for an iso image [10:54] * xnox goes to get coffee whilst download is in progress. 90s left. [10:58] fonts look odd but it seems to be working [10:58] xnox: Emulating video too? Brave. [10:59] xnox: I'd have opted for qemu-system-ppc64 -M pseries -m 2G -vga none -nographics -hda foo.img -cdrom ubuntu.iso [10:59] using defaults in libvirt [10:59] xnox: And just enjoy the text. [10:59] libvirt and I don't get along. [11:00] i think video crashes. [11:00] testing123 [11:01] s/nographics/nographic/ [11:01] serial looks better. [11:01] wrong window ah that's better now it pings me in pm [11:02] i get kernel panic trying to boot of yakkety-server.iso and it goes into reboot loop =( [11:02] * xnox tries xenial [11:05] * infinity gets 12MB/s from cdimage, and wonders if this is a sign of the apocalypse. [11:07] qemu-system-ppc64le -M pseries -cdrom yakkety-server-ppc64el.iso -m 2048 -nographic [11:07] doesn't get me d-i :-( [11:10] emu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -hda disk.img.server -cdrom ubuntu-16.04.1-server-ppc64el.iso [11:10] xnox: -cpu needs to be POWER8, we don't support lower. Also, -vga none is a good idea if you're -nographic. [11:10] (The above worked for me here) [11:11] that got me grub [11:11] yakkety boots with that commandline too. [11:11] But yeah. It ain't quick. [11:11] i see d-i \o/ [11:12] Be prepared for some very slow menu transitions. [11:12] * infinity goes to bed. === dpm is now known as dpm-lunch [11:46] rbasak, thanks for your help yesterday. [11:47] xnox, 'xkvm' from curtin makes the qemu cmdline easier. [11:47] and should pretty easily dtrt for power [11:47] rbasak, so Fixes LP: #bug1, bug2 [11:47] or Fixes LP: #bug1, #bug2 === hikiko is now known as hikiko|ln [11:51] smoser: any need for "Fixes"? [11:52] there is not. [11:52] maybe Fixes-bug: [11:52] it isnt necessary, but it seems reasonable to put sanely formated data. [11:53] maybe i should just accept arbitrary string searching [11:53] from [11:53] zgrep -E LP: /usr/share/doc/*/changelog.Debian.gz | grep -e "#[0-9]\+[ ]*[ ,]\+[#*][0-9]\+" [11:53] it seems like LP: #NN, #NN [11:53] is pretty common in changelogs [11:53] so for multiple bugs i'll do [11:53] LP: #BUG, #BUG [11:53] Both '#' characters are necessary, yes. [11:53] The problem is that you're making something up that is likely to be non-standard. [11:54] You say Fixes, someone else says Closes, etc. So I don't think you get any benefit there unless someone defines something. [11:54] I'd just put "LP: #NNN" on a line on its own. [11:54] It's still not absolutely settled what Launchpad will recognise, but if it's anything like the changelog syntax then it will likely be exactly the same as the changelog syntax, not a slight variant of it. [11:55] (or "LP: #XXX, #YYY" of course) [11:56] The nice thing about that is that it also matches the pseudo-header syntax that others tend to use. [11:56] well, because i'm in the position where i can actually make consistency for this, it seems better to do it. [11:56] You can't make consistency for this. [11:57] You'll end up with a history that does one thing, and a future that potentially does something else. [11:57] i surely can for my repo. [11:57] Or, if you stick to the same thing, you'll have cloud-init doing a special thing that no other repo does, which will be confusing for contributors. [11:57] I'm just saying that you shouldn't arbitrarily invent anything here. [11:59] the thing i'm bothered by is that 'LP: #XXX' does not differenciate from Fixes LP: #XXX and 'this is fallout of a fix for LP: #XXXX' [11:59] the latter is not correct syntax [11:59] aiui [11:59] debian/changelog has the same issue. You can't fix it by adding "Fixes LP". The regexp that Colin proposed will still match it. [11:59] it should be LP #XXXX in that case [11:59] LP: is "special" [11:59] The traditional approach in changelogs is as nacc says. [12:00] It's maybe not ideal, but it's pretty established. [12:00] "Fixes LP" also breaks the RFC822-style headers the git community tends to use. [12:00] oh wow. [12:00] Fixes: LP: # does not. [12:01] It might be worth looking into whether git-dch can parse that. [12:02] I know it parses "LP: #XXX" on a line on its own fine. [12:02] alright. i'll go with just LP: # as new line. [12:03] Thanks. I feel that this has the most potential to become a future de facto standard. === _salem is now known as salem_ === dpm-lunch is now known as dpm === salem_ is now known as _salem === _salem is now known as salem_ [13:25] Odd_Bloke: i see bug 1565985 is filed in this week's milestone for cloud-images. does that mean that the yakkety images will start to be built with the fixes soon? [13:25] bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985 === sakrecoer is now known as sakrecoer_ === JanC is now known as Guest24709 === JanC_ is now known as JanC [14:33] rbasak, so.. i tried that mono bzr fast-export rewriter... had issues. [14:33] i could not get it to work for me [14:33] however, this does work: [14:33] http://paste.ubuntu.com/21144779/ [14:33] and seems much better sutied for the task. ie, i just modified fastexport in bzr to update the messages. [14:35] smoser: seems reasonable [14:35] smoser: it might be sensible to send that upstream, too. Though your code is a little hacky IMHO. [14:56] can anybody please try to clean ppc64el builders space? [14:56] objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN[.rodata]: No space left on device [14:56] objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN: No space left on device [14:56] or should I do something else [14:57] https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-1ubuntu1/+build/10520384 [15:03] rbasak, agreed on both counts. hacky and would be nice to have that as an option. [15:03] you'd have to provide some option for how to translate some template or something. [15:05] smoser: IMHO, for the sake of consistency there shouldn't be a configurable template option. Just do the one thing one way. [15:09] semiosis: The next yakkety build should have them. [15:09] semiosis: (Thanks for the ping though, I'd forgotten to push a button) [15:12] rbasak, but there are different bug sources [15:12] not everyone uses launchpad [15:12] i know, its hard to believe :) [15:13] smoser: sure, but the bzr metadata knows the bug source, right? So it wouldn't need to be configurable, just individual support in the code. [15:13] well, sort of [15:13] bzr knows the bug url [15:13] so it could quite easily do: [15:14] fixes-bug: bugurl [15:14] fixes-bug: bugurl2 [15:14] but extracting the bug number out of any bug systems url is more complex. [15:14] and that assumes good data in those urls [15:14] consistent url formats across every committer [15:18] well, it's easy enough for launchpad to handle launchpad bug urls [15:18] beyond that, you just have a url which is generally good enough [15:19] see url, click url, get bug [15:22] *** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: 0x01f5c390 *** [15:22] well, that sucks [15:23] oops [15:34] have the main inclusion requirements as documented in https://wiki.ubuntu.com/UbuntuMainInclusionRequirements changed? In particular, are build-deps still required to be in main, or was that not recently relaxed? [15:36] bregma: universe b-depends are ok now: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html [15:36] I ask because I'm looking at having to MIR 114 packages to get Unity 8 into main *without* the build-deps [15:37] jbicha, what about packages needed only for running autopkgtests? [15:37] that's a good email list to subscribe to if you don't already [15:37] bregma: test dependencies can come from any component [15:38] I'm subscribed, so I was peripherally aware of the change but the wiki documentation is not up to date [15:40] build-deps are ok being in universe, if they don't create binary deps on things in universe [15:48] Odd_Bloke: glad to hear it. thank you! [16:30] @pilot in === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry === sidi_ is now known as sidi [17:56] jamespage, in pacemaker 1.1.14~rc4-2ubuntu1 for 16.04, you wrote "d/control: Promote crmsh | pcs to Recommends for upgraders from 14.04." -- what did you mean about upgraders from 14.04? Do we still need that change post-16.04?