=== _salem is now known as salem_
=== salem_ is now known as _salem
infinityLogan:  http://launchpadlibrarian.net/275043606/funny-manpages_1.3-5.1ubuntu1_1.3-5.1ubuntu2.diff.gz <-- What's wrong with this diff? ;)04:00
infinitypitti: amd64 autopkgtest queues seem stuck.04:47
infinitypitti: Oh, lcy01 is completely dead.  If amd64 autopkgtest uses that region exclusively, that would explain the stall.05:19
infinitypitti: 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:21
pittiinfinity: yes, Qt 5.6 + dead lcy01 == tests take forever..05:51
pittiinfinity: oh, I thought I accepted all trusty langpacks05:51
pittiinfinity: sorry, will process the rest05:51
pittiinfinity: meh, the cleanup/restart script stumbled over "nova list" failing; fixed that now, so the other clouds keep running05:59
infinitypitti: Seemed curious to me that the i386 queue emptied before the amd64 one.  I would have expected them to drain in parallel.06:41
infinitypitti: 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
pittiinfinity: britney issues the requests in architecture order, so i386 is always a bit ahead indeed06:42
pittimaybe this could use some more shuffling06:42
pittithe main source of imbalance is the retry-autopkgtest-regressinos script though06:42
infinitypitti: 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
pittithat generates stuff sorted by architecture first06:43
infinitypitti: So, for shared pool arches, they'd together.06:43
* infinity shrugs.06:43
pittibritney is per-excuse first, then per architecture, then all the triggered tests for that excuse06:43
infinitypitti: Minor frustration to be waiting on one arch column for all packages instead of two arch columns for half the packages.06:43
pittiyes, indeed; but it's not nearly as bad06:44
infinitypitti: Oh, not sure if I told you, but mvo and I sat down and fixed snapd autopkgtests.07:21
infinitypitti: 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
ubottuLaunchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] https://launchpad.net/bugs/159979907:21
mwhudsoninfinity: what was the problem?07:29
infinitymwhudson: Exactly what they error message no one read said the problem was.07:29
infinity(They created new units and didn't run daemon-reload)07:29
mwhudsoni did _ask_ about that07:30
mwhudsonbut i didn't check07:30
infinityI 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
infinityBut whatever.07:30
infinityThe number of times we reload that daemon to clear the cobwebs from its internal state is insane.07:30
pittithis wasn't the error I saw in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799/comments/1207:30
ubottuLaunchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged]07:30
pittibasic-binaries.block[12533]: unable to bind /snap/ubuntu-core/current//bin to /bin. errmsg: Permission denied07:30
pittithat wasn't a missing daemon-reload07:31
mwhudsoni think that one was a snap-confine bug07:31
infinityYeah, different bug than the one originally reported.07:31
infinityBut both seem fixed.07:31
* pitti stares at the autopkgtest queue and o_O's07:32
pittiooh, new perl07:32
infinityI shouldn't have retried the arm64 build. ;)07:33
infinityNow I have no chance of getting my own retries in.07:33
infinityOh well.07:33
pittiinfinity: if it's blocking, I can remove all the perl tests and we re-trigger them later07:33
infinitypitti: Shouldn't be.  I'm just waiting for the snapd/amd64 result, which is currently in limbo.07:33
infinitypitti: If it comes back successful, I'm happy.07:34
pittiweird, it hasn't run yet and it's not in the queue07:34
infinityIt disappeared from the queue about 10m ago.07:34
infinityI assumed that meant it would, I dunno, run.07:34
pittinothing from today yet07:34
pittiI suppose an lcy01 worker tried to catch it and is now caught in its "retry three times until I give up" loop or so07:35
infinityWhat happend after that?  End of the queue, or punted to another builder, or dropped on the floor?07:35
pittiah no, it's working07:35
pittierr, running07:35
pittiit just doesn't show on running.shtml for some reason07:36
infinityBecause running.shtml is 10m old?07:36
pitti18 mins07:36
infinitypitti: I'm curious why the debci pages are static generated instead of cgi.  Just trying to be load-friendly?07:38
pittiinfinity: I suppose so; it's quite expensive to generate them, as it shows the entire history of a package07:39
infinitypitti: 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:39
infinitypitti: 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
pittiwell, I don't know :)07:40
infinitypitti: 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
pittiinfinity: I can't say I like the current design either; it creates literally millions of little files which keeps hitting the "max inodes" ceiling07:42
pittiand it's expensive to generate indeed07:42
infinityxfs to the rescue?07:42
pittibut yeah, it was that or "write it yourself" :)07:42
infinityI'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:43
pittiinfinity: 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
infinitypitti: Heh, I'm not suggesting you fix it, just making idle banter.07:45
infinitypitti: Besides, every page does point me at the git repository, if it really pisses me off enough.07:45
infinitypitti: 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
pittiinfinity: it actually would be -- this would be changing the thing from the ground up07:46
infinity(Though, as it scales up, replacing the backend with a proper DB seems sane)07:46
pittiinfinity: so, I don't think there's any way around downloading the entire metadata from swift as that takes an awful amount of time07:47
pittibut generating html and the indexes dynamically would be great indeed07:47
pittiright, sqlite or so would certainly beat individual files :)07:47
mwhudsoni'm sure there's some shiny nosql db we could use07:47
infinityI need to read up on nosql stuff to understand why I'm supposed to like it.07:48
infinityTHere's enough psql deployed in Debian and Canonical that that would have been my first choice.07:48
pittiinfinity: no prob to add psql to the charm for sure07:48
infinitypitti: 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:51
infinity"Oh look, a psql result" -> regen psql page.07:52
infinityAs it is, it does ALL the pages.07:52
infinityWhich is daft.07:52
pittiinfinity: so if we can talk slangasek into allocating three days for that, we should invite terceiro and fix this up properly07:54
pittiinfinity: I know terceiro has also hit the inode limit, and I'm sure the load on ci.debian.net is similarly high07:54
infinitypitti: Hahaha.  That reminds me.07:56
pittiinfinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160727_073957@/log.gz07:56
infinitypitti: ci.ubuntu.com still has a link in the top bar ([Proposed]) to the old jenkins-driven autopkgtest infra.07:56
infinitypitti: Who owns that?07:56
infinitypitti: It should point to autopkgtest.ubuntu.com, probably.07:56
pittiuh, oh, look behind! a three-headed monkey!07:57
pittijibel: do you know who owns http://ci.ubuntu.com/ ?07:57
infinitypitti: And yay on the pass!07:57
pittithis looks so out of date, I doubt it's still useful at all07:57
infinitypitti: Hrm, indeed.  http://ci.ubuntu.com/smokeng/ seems to stop at wily.07:59
infinitypitti: How did the user session sprint go?08:10
infinitypitti: Will we reduce 'reverse-depends upstart' to zero by release?08:10
infinityWell, zero except for the things with 'upstart' in the name. :P08:10
pittiinfinity: 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 fix08:10
pittiinfinity: we converted most things and they are currently being landed08:11
infinitypitti: Awesome.08:11
pittithere's a big CI train silo, and landing gnome-session/xubuntu-default-settings etc. is blocked on landing upstart in -proposed and systemd 231-108:11
infinityupsart seems to just be waiting on autopkgtests.08:12
pittiwhich 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
pittiso, just a few days unti the dust settles08:12
infinityThough, I'm suspicious that the upstart autopkgtests may have disappeared.08:12
infinitySince I don't buy that the ppc64el tests have been "in progress" since yesterday.08:13
pittiinfinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/upstart/20160513_104747@/log.gz08:13
pittiapt segfault and corrupted cache, I retried it this morning08:13
pittibefore the perl flood I think08:13
pittianyway, I have an eye on it08:13
jibelpitti, no idea, it used to be ev's team08:21
Oni_ShadowG'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
Oni_Shadow(it there the right place?)09:56
naccOni_Shadow: what is "ubuntu-devel"?09:57
Oni_Shadowmy 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 broken09:57
naccOni_Shadow: do you mean 16.10?09:57
Oni_Shadowwell devel is a codenam for developement i suppose that points on the lastest nightly builds, currently yaketty.09:57
naccOni_Shadow: you want #ubuntu+109:58
Oni_ShadowI just want to get qt stuff (like unity8 and konversation) installable again09:58
Oni_Shadowon my ubuntu-devel machine09:58
naccOni_Shadow: right, ask in #ubuntu+109:58
naccOni_Shadow: this channel is for development of Ubuntu itself (see /topic)09:59
Oni_Shadowok cheers !09:59
Oni_Shadowsorry about that then09:59
juliankpitti: 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:15
* juliank is supposed to hand in some master thesis plan soon, otherwise he would have more time to look at things10:16
juliankGPG error: http://ddebs.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C8CAB6595FDFF62210:16
juliankthat's the apport failure10:16
juliankIt does say freeze now, I suppose that's for the alpha 2s tomorrow?10:17
juliankclick 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 there10:18
juliankAnd ubuntu-make has some jquery coverage issues10:19
juliank"Couldn't find static file 'jquery.ba-throttle-debounce.min.js'"10:19
pittijuliank: 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
juliankpitti: 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 know10:36
juliankThen again, signature ver. issues should have been errors before too10:37
pittijuliank: indeed, like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/a/apport/20160727_081401@/log.gz10:38
pittiit's a  warning there10:38
juliankthat's the add repository, install keyring, update again scenario10:39
juliankThat now requires --allow-insecure or --allow-unauthenticated10:39
* juliank is never sure which is whicht10:39
juliank(or [allow-insecure=true] in the sources.list)10:40
pittijuliank: do you know about the python-apt failure?10:41
juliankthis 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 them10:41
pittiI'll put the apport thing on my TODO list10:42
juliankpitti: 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 own10:42
juliankThat is, they also fail for other test suite triggers10:43
pittiso, fine for me to ignore these two10:43
pittijuliank: for now I'll requeue a retry of proposed python-apt against proposed apt, that should clear up that part10:44
pittijuliank: will take a bit though, look at the queues on http://autopkgtest.ubuntu.com/running.shtml :/10:45
pittijuliank: p-apt hinted, p-apt for apt retried10:47
xnoxpitti, 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
pittioh, so a cloud instance won't do for that10:48
pittinested qemu perhaps10:49
pitti(on a cloud instance)10:49
infinityxnox: You can emulate, yes.10:51
infinityxnox: It's not fast, mind you.10:52
infinityxnox: qemu-system-ppc64 -M pseries10:52
infinityxnox: Or ask slangasek how to get at real hardware, where you can add --enable-kvm to that and not hate yourself. ;)10:52
xnoxin virtmanager i do get architecture ppc64le and pseries option. let me see if i can boot that at all.10:53
xnoxasks for an iso image10:53
* xnox goes to get coffee whilst download is in progress. 90s left.10:54
xnoxfonts look odd but it seems to be working10:58
infinityxnox: Emulating video too?  Brave.10:58
infinityxnox: I'd have opted for qemu-system-ppc64 -M pseries -m 2G -vga none -nographics -hda foo.img -cdrom ubuntu.iso10:59
xnoxusing defaults in libvirt10:59
infinityxnox: And just enjoy the text.10:59
infinitylibvirt and I don't get along.10:59
xnoxi think video crashes.11:00
xnoxserial looks better.11:01
davmor2wrong window ah that's better now it pings me in pm11:01
xnoxi get kernel panic trying to boot of yakkety-server.iso and it goes into reboot loop =(11:02
* xnox tries xenial11:02
* infinity gets 12MB/s from cdimage, and wonders if this is a sign of the apocalypse.11:05
xnoxqemu-system-ppc64le -M pseries -cdrom yakkety-server-ppc64el.iso -m 2048 -nographic11:07
xnoxdoesn't get me d-i :-(11:07
infinityemu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -hda disk.img.server -cdrom ubuntu-16.04.1-server-ppc64el.iso11:10
infinityxnox: -cpu needs to be POWER8, we don't support lower.  Also, -vga none is a good idea if you're -nographic.11:10
infinity(The above worked for me here)11:10
xnoxthat got me grub11:11
infinityyakkety boots with that commandline too.11:11
infinityBut yeah.  It ain't quick.11:11
xnoxi see d-i \o/11:11
infinityBe prepared for some very slow menu transitions.11:12
* infinity goes to bed.11:12
=== dpm is now known as dpm-lunch
smoserrbasak, thanks for your help yesterday.11:46
smoserxnox, 'xkvm' from curtin makes the qemu cmdline easier.11:47
smoserand should pretty easily dtrt for power11:47
smoserrbasak, so Fixes LP: #bug1, bug211:47
smoseror Fixes LP: #bug1, #bug211:47
=== hikiko is now known as hikiko|ln
rbasaksmoser: any need for "Fixes"?11:51
smoserthere is not.11:52
smosermaybe Fixes-bug:11:52
smoserit isnt necessary, but it seems reasonable to put sanely formated data.11:52
smosermaybe i should just accept arbitrary string searching11:53
smoser zgrep -E LP: /usr/share/doc/*/changelog.Debian.gz | grep -e "#[0-9]\+[ ]*[ ,]\+[#*][0-9]\+"11:53
smoserit seems like LP: #NN, #NN11:53
smoseris pretty common in changelogs11:53
smoserso for multiple bugs i'll do11:53
smoserLP: #BUG, #BUG11:53
cjwatsonBoth '#' characters are necessary, yes.11:53
rbasakThe problem is that you're making something up that is likely to be non-standard.11:53
rbasakYou say Fixes, someone else says Closes, etc. So I don't think you get any benefit there unless someone defines something.11:54
rbasakI'd just put "LP: #NNN" on a line on its own.11:54
cjwatsonIt'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:54
rbasak(or "LP: #XXX, #YYY" of course)11:55
rbasakThe nice thing about that is that it also matches the pseudo-header syntax that others tend to use.11:56
smoserwell, because i'm in the position where i can actually make consistency for this, it seems better to do it.11:56
rbasakYou can't make consistency for this.11:56
rbasakYou'll end up with a history that does one thing, and a future that potentially does something else.11:57
smoseri surely can for my repo.11:57
rbasakOr, 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
rbasakI'm just saying that you shouldn't arbitrarily invent anything here.11:57
smoserthe 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
naccthe latter is not correct syntax11:59
rbasakdebian/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
naccit should be LP #XXXX in that case11:59
naccLP: is "special"11:59
cjwatsonThe traditional approach in changelogs is as nacc says.11:59
cjwatsonIt's maybe not ideal, but it's pretty established.12:00
rbasak"Fixes LP" also breaks the RFC822-style headers the git community tends to use.12:00
xnoxoh wow.12:00
smoserFixes: LP: # does not.12:00
rbasakIt might be worth looking into whether git-dch can parse that.12:01
rbasakI know it parses "LP: #XXX" on a line on its own fine.12:02
smoseralright. i'll go with just LP: # as new line.12:02
rbasakThanks. I feel that this has the most potential to become a future de facto standard.12:03
=== _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_
semiosisOdd_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
ubottubug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/156598513:25
=== sakrecoer is now known as sakrecoer_
=== JanC is now known as Guest24709
=== JanC_ is now known as JanC
smoserrbasak, so.. i tried that mono bzr fast-export rewriter... had issues.14:33
smoseri could not get it to work for me14:33
smoserhowever, this does work:14:33
smoser http://paste.ubuntu.com/21144779/14:33
smoserand seems much better sutied for the task. ie, i just modified fastexport in bzr to update the messages.14:33
rbasaksmoser: seems reasonable14:35
rbasaksmoser: it might be sensible to send that upstream, too. Though your code is a little hacky IMHO.14:35
LocutusOfBorgcan anybody please try to clean ppc64el builders space?14:56
LocutusOfBorgobjcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN[.rodata]: No space left on device14:56
LocutusOfBorgobjcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN: No space left on device14:56
LocutusOfBorgor should I do something else14:56
smoserrbasak, agreed on both counts. hacky and would be nice to have that as an option.15:03
smoseryou'd have to provide some option for how to translate some template or something.15:03
rbasaksmoser: IMHO, for the sake of consistency there shouldn't be a configurable template option. Just do the one thing one way.15:05
Odd_Blokesemiosis: The next yakkety build should have them.15:09
Odd_Blokesemiosis: (Thanks for the ping though, I'd forgotten to push a button)15:09
smoserrbasak, but there are different bug sources15:12
smosernot everyone uses launchpad15:12
smoseri know, its hard to believe :)15:12
rbasaksmoser: 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
smoserwell, sort of15:13
smoserbzr knows the bug url15:13
smoserso it could quite easily do:15:13
smoserfixes-bug: bugurl15:14
smoserfixes-bug: bugurl215:14
smoserbut extracting the bug number out of any bug systems url is more complex.15:14
smoserand that assumes good data in those urls15:14
smoserconsistent url formats across every committer15:14
dobeywell, it's easy enough for launchpad to handle launchpad bug urls15:18
dobeybeyond that, you just have a url which is generally good enough15:18
dobeysee url, click url, get bug15:19
dobey*** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: 0x01f5c390 ***15:22
dobeywell, that sucks15:22
bregmahave 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:34
jbichabregma: universe b-depends are ok now: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html15:36
bregmaI ask because I'm looking at having to MIR 114 packages to get Unity 8 into main *without* the build-deps15:36
bregmajbicha, what about packages needed only for running autopkgtests?15:37
jbichathat's a good email list to subscribe to if you don't already15:37
pittibregma: test dependencies can come from any component15:37
bregmaI'm subscribed, so I was peripherally aware of the change but the wiki documentation is not up to date15:38
dobeybuild-deps are ok being in universe, if they don't create binary deps on things in universe15:40
semiosisOdd_Bloke: glad to hear it.  thank you!15:48
mterry@pilot in16:30
=== 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
mterryjamespage, 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?17:56

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