| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| infinity | Logan: http://launchpadlibrarian.net/275043606/funny-manpages_1.3-5.1ubuntu1_1.3-5.1ubuntu2.diff.gz <-- What's wrong with this diff? ;) | 04:00 |
|---|---|---|
| infinity | pitti: amd64 autopkgtest queues seem stuck. | 04:47 |
| infinity | pitti: Oh, lcy01 is completely dead. If amd64 autopkgtest uses that region exclusively, that would explain the stall. | 05:19 |
| infinity | 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:21 |
| pitti | infinity: yes, Qt 5.6 + dead lcy01 == tests take forever.. | 05:51 |
| pitti | infinity: oh, I thought I accepted all trusty langpacks | 05:51 |
| pitti | infinity: sorry, will process the rest | 05:51 |
| pitti | infinity: meh, the cleanup/restart script stumbled over "nova list" failing; fixed that now, so the other clouds keep running | 05:59 |
| infinity | pitti: Seemed curious to me that the i386 queue emptied before the amd64 one. I would have expected them to drain in parallel. | 06:41 |
| infinity | 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 |
| pitti | infinity: britney issues the requests in architecture order, so i386 is always a bit ahead indeed | 06:42 |
| pitti | maybe this could use some more shuffling | 06:42 |
| pitti | the main source of imbalance is the retry-autopkgtest-regressinos script though | 06:42 |
| infinity | 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 |
| pitti | that generates stuff sorted by architecture first | 06:43 |
| infinity | pitti: So, for shared pool arches, they'd together. | 06:43 |
| infinity | Ish. | 06:43 |
| * infinity shrugs. | 06:43 | |
| pitti | britney is per-excuse first, then per architecture, then all the triggered tests for that excuse | 06:43 |
| infinity | pitti: Minor frustration to be waiting on one arch column for all packages instead of two arch columns for half the packages. | 06:43 |
| pitti | yes, indeed; but it's not nearly as bad | 06:44 |
| infinity | pitti: Oh, not sure if I told you, but mvo and I sat down and fixed snapd autopkgtests. | 07:21 |
| infinity | 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 |
| ubottu | Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] https://launchpad.net/bugs/1599799 | 07:21 |
| mwhudson | ooh | 07:28 |
| mwhudson | infinity: what was the problem? | 07:29 |
| pitti | nice! | 07:29 |
| infinity | mwhudson: 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 |
| mwhudson | heh | 07:29 |
| mwhudson | i did _ask_ about that | 07:30 |
| mwhudson | but i didn't check | 07:30 |
| infinity | 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 |
| infinity | But whatever. | 07:30 |
| infinity | The number of times we reload that daemon to clear the cobwebs from its internal state is insane. | 07:30 |
| pitti | this wasn't the error I saw in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799/comments/12 | 07:30 |
| ubottu | Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged] | 07:30 |
| pitti | basic-binaries.block[12533]: unable to bind /snap/ubuntu-core/current//bin to /bin. errmsg: Permission denied | 07:30 |
| pitti | that wasn't a missing daemon-reload | 07:31 |
| mwhudson | i think that one was a snap-confine bug | 07:31 |
| infinity | Yeah, different bug than the one originally reported. | 07:31 |
| infinity | But both seem fixed. | 07:31 |
| * pitti stares at the autopkgtest queue and o_O's | 07:32 | |
| pitti | ooh, new perl | 07:32 |
| infinity | Yeah. | 07:32 |
| infinity | I shouldn't have retried the arm64 build. ;) | 07:33 |
| infinity | Now I have no chance of getting my own retries in. | 07:33 |
| infinity | Oh well. | 07:33 |
| pitti | infinity: if it's blocking, I can remove all the perl tests and we re-trigger them later | 07:33 |
| infinity | pitti: Shouldn't be. I'm just waiting for the snapd/amd64 result, which is currently in limbo. | 07:33 |
| infinity | pitti: If it comes back successful, I'm happy. | 07:34 |
| pitti | weird, it hasn't run yet and it's not in the queue | 07:34 |
| infinity | It disappeared from the queue about 10m ago. | 07:34 |
| infinity | I assumed that meant it would, I dunno, run. | 07:34 |
| pitti | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/amd64/s/snapd | 07:34 |
| pitti | nothing from today yet | 07:34 |
| pitti | 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 |
| infinity | What happend after that? End of the queue, or punted to another builder, or dropped on the floor? | 07:35 |
| pitti | ah no, it's working | 07:35 |
| pitti | err, running | 07:35 |
| infinity | s/happend/happens/ | 07:35 |
| pitti | it just doesn't show on running.shtml for some reason | 07:36 |
| infinity | Because running.shtml is 10m old? | 07:36 |
| infinity | Err. | 07:36 |
| infinity | Older. | 07:36 |
| infinity | 18m. | 07:36 |
| pitti | 18 mins | 07:36 |
| infinity | pitti: I'm curious why the debci pages are static generated instead of cgi. Just trying to be load-friendly? | 07:38 |
| pitti | infinity: I suppose so; it's quite expensive to generate them, as it shows the entire history of a package | 07:39 |
| infinity | 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:39 |
| infinity | 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 |
| pitti | well, I don't know :) | 07:40 |
| infinity | 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 |
| infinity | Ish. | 07:41 |
| pitti | 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 |
| pitti | and it's expensive to generate indeed | 07:42 |
| infinity | xfs to the rescue? | 07:42 |
| pitti | but yeah, it was that or "write it yourself" :) | 07:42 |
| infinity | 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:43 |
| pitti | 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 |
| infinity | pitti: Heh, I'm not suggesting you fix it, just making idle banter. | 07:45 |
| infinity | pitti: Besides, every page does point me at the git repository, if it really pisses me off enough. | 07:45 |
| infinity | 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 |
| pitti | infinity: it actually would be -- this would be changing the thing from the ground up | 07:46 |
| infinity | (Though, as it scales up, replacing the backend with a proper DB seems sane) | 07:46 |
| pitti | 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 |
| pitti | but generating html and the indexes dynamically would be great indeed | 07:47 |
| pitti | right, sqlite or so would certainly beat individual files :) | 07:47 |
| mwhudson | i'm sure there's some shiny nosql db we could use | 07:47 |
| infinity | I need to read up on nosql stuff to understand why I'm supposed to like it. | 07:48 |
| infinity | THere's enough psql deployed in Debian and Canonical that that would have been my first choice. | 07:48 |
| pitti | infinity: no prob to add psql to the charm for sure | 07:48 |
| infinity | 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:51 |
| infinity | "Oh look, a psql result" -> regen psql page. | 07:52 |
| infinity | As it is, it does ALL the pages. | 07:52 |
| infinity | Which is daft. | 07:52 |
| pitti | infinity: so if we can talk slangasek into allocating three days for that, we should invite terceiro and fix this up properly | 07:54 |
| pitti | infinity: I know terceiro has also hit the inode limit, and I'm sure the load on ci.debian.net is similarly high | 07:54 |
| infinity | pitti: Hahaha. That reminds me. | 07:56 |
| pitti | infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160727_073957@/log.gz | 07:56 |
| pitti | PASS | 07:56 |
| infinity | pitti: ci.ubuntu.com still has a link in the top bar ([Proposed]) to the old jenkins-driven autopkgtest infra. | 07:56 |
| infinity | pitti: Who owns that? | 07:56 |
| infinity | pitti: It should point to autopkgtest.ubuntu.com, probably. | 07:56 |
| pitti | uh, oh, look behind! a three-headed monkey! | 07:57 |
| pitti | jibel: do you know who owns http://ci.ubuntu.com/ ? | 07:57 |
| infinity | pitti: And yay on the pass! | 07:57 |
| pitti | this looks so out of date, I doubt it's still useful at all | 07:57 |
| infinity | pitti: Hrm, indeed. http://ci.ubuntu.com/smokeng/ seems to stop at wily. | 07:59 |
| infinity | pitti: How did the user session sprint go? | 08:10 |
| infinity | pitti: Will we reduce 'reverse-depends upstart' to zero by release? | 08:10 |
| infinity | Well, zero except for the things with 'upstart' in the name. :P | 08:10 |
| pitti | 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:10 |
| pitti | infinity: we converted most things and they are currently being landed | 08:11 |
| infinity | pitti: Awesome. | 08:11 |
| pitti | 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:11 |
| infinity | upsart seems to just be waiting on autopkgtests. | 08:12 |
| pitti | 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 |
| pitti | so, just a few days unti the dust settles | 08:12 |
| infinity | Though, I'm suspicious that the upstart autopkgtests may have disappeared. | 08:12 |
| infinity | Since I don't buy that the ppc64el tests have been "in progress" since yesterday. | 08:13 |
| pitti | infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/upstart/20160513_104747@/log.gz | 08:13 |
| pitti | apt segfault and corrupted cache, I retried it this morning | 08:13 |
| pitti | before the perl flood I think | 08:13 |
| pitti | anyway, I have an eye on it | 08:13 |
| jibel | pitti, no idea, it used to be ev's team | 08:21 |
| Oni_Shadow | 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 |
| Oni_Shadow | (it there the right place?) | 09:56 |
| nacc | Oni_Shadow: what is "ubuntu-devel"? | 09:57 |
| Oni_Shadow | 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 |
| nacc | Oni_Shadow: do you mean 16.10? | 09:57 |
| Oni_Shadow | well devel is a codenam for developement i suppose that points on the lastest nightly builds, currently yaketty. | 09:57 |
| nacc | Oni_Shadow: you want #ubuntu+1 | 09:58 |
| Oni_Shadow | I just want to get qt stuff (like unity8 and konversation) installable again | 09:58 |
| Oni_Shadow | on my ubuntu-devel machine | 09:58 |
| nacc | Oni_Shadow: right, ask in #ubuntu+1 | 09:58 |
| nacc | Oni_Shadow: this channel is for development of Ubuntu itself (see /topic) | 09:59 |
| Oni_Shadow | ok cheers ! | 09:59 |
| Oni_Shadow | sorry about that then | 09:59 |
| juliank | 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:15 |
| * juliank is supposed to hand in some master thesis plan soon, otherwise he would have more time to look at things | 10:16 | |
| juliank | 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 |
| juliank | that's the apport failure | 10:16 |
| juliank | It does say freeze now, I suppose that's for the alpha 2s tomorrow? | 10:17 |
| juliank | 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:18 |
| juliank | And ubuntu-make has some jquery coverage issues | 10:19 |
| juliank | "Couldn't find static file 'jquery.ba-throttle-debounce.min.js'" | 10:19 |
| pitti | 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 |
| juliank | 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:36 |
| juliank | Then again, signature ver. issues should have been errors before too | 10:37 |
| pitti | 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 |
| pitti | it's a warning there | 10:38 |
| juliank | right. | 10:39 |
| juliank | that's the add repository, install keyring, update again scenario | 10:39 |
| juliank | That now requires --allow-insecure or --allow-unauthenticated | 10:39 |
| * juliank is never sure which is whicht | 10:39 | |
| juliank | (or [allow-insecure=true] in the sources.list) | 10:40 |
| pitti | juliank: do you know about the python-apt failure? | 10:41 |
| juliank | 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:41 |
| pitti | I'll put the apport thing on my TODO list | 10:42 |
| juliank | 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:42 |
| juliank | That is, they also fail for other test suite triggers | 10:43 |
| pitti | right | 10:43 |
| pitti | so, fine for me to ignore these two | 10:43 |
| pitti | juliank: for now I'll requeue a retry of proposed python-apt against proposed apt, that should clear up that part | 10:44 |
| pitti | juliank: will take a bit though, look at the queues on http://autopkgtest.ubuntu.com/running.shtml :/ | 10:45 |
| juliank | OK | 10:45 |
| pitti | juliank: p-apt hinted, p-apt for apt retried | 10:47 |
| xnox | 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 |
| pitti | oh, so a cloud instance won't do for that | 10:48 |
| pitti | nested qemu perhaps | 10:49 |
| pitti | (on a cloud instance) | 10:49 |
| infinity | xnox: You can emulate, yes. | 10:51 |
| infinity | xnox: It's not fast, mind you. | 10:52 |
| infinity | xnox: qemu-system-ppc64 -M pseries | 10:52 |
| infinity | xnox: Or ask slangasek how to get at real hardware, where you can add --enable-kvm to that and not hate yourself. ;) | 10:52 |
| xnox | in virtmanager i do get architecture ppc64le and pseries option. let me see if i can boot that at all. | 10:53 |
| xnox | asks for an iso image | 10:53 |
| * xnox goes to get coffee whilst download is in progress. 90s left. | 10:54 | |
| xnox | fonts look odd but it seems to be working | 10:58 |
| infinity | xnox: Emulating video too? Brave. | 10:58 |
| infinity | xnox: I'd have opted for qemu-system-ppc64 -M pseries -m 2G -vga none -nographics -hda foo.img -cdrom ubuntu.iso | 10:59 |
| xnox | using defaults in libvirt | 10:59 |
| infinity | xnox: And just enjoy the text. | 10:59 |
| infinity | libvirt and I don't get along. | 10:59 |
| xnox | i think video crashes. | 11:00 |
| davmor2 | testing123 | 11:00 |
| infinity | s/nographics/nographic/ | 11:01 |
| xnox | serial looks better. | 11:01 |
| davmor2 | wrong window ah that's better now it pings me in pm | 11:01 |
| xnox | i get kernel panic trying to boot of yakkety-server.iso and it goes into reboot loop =( | 11:02 |
| * xnox tries xenial | 11:02 | |
| * infinity gets 12MB/s from cdimage, and wonders if this is a sign of the apocalypse. | 11:05 | |
| xnox | qemu-system-ppc64le -M pseries -cdrom yakkety-server-ppc64el.iso -m 2048 -nographic | 11:07 |
| xnox | doesn't get me d-i :-( | 11:07 |
| infinity | 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 |
| infinity | xnox: -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 |
| xnox | that got me grub | 11:11 |
| infinity | yakkety boots with that commandline too. | 11:11 |
| infinity | But yeah. It ain't quick. | 11:11 |
| xnox | i see d-i \o/ | 11:11 |
| infinity | Be prepared for some very slow menu transitions. | 11:12 |
| * infinity goes to bed. | 11:12 | |
| === dpm is now known as dpm-lunch | ||
| smoser | rbasak, thanks for your help yesterday. | 11:46 |
| smoser | xnox, 'xkvm' from curtin makes the qemu cmdline easier. | 11:47 |
| smoser | and should pretty easily dtrt for power | 11:47 |
| smoser | rbasak, so Fixes LP: #bug1, bug2 | 11:47 |
| smoser | or Fixes LP: #bug1, #bug2 | 11:47 |
| === hikiko is now known as hikiko|ln | ||
| rbasak | smoser: any need for "Fixes"? | 11:51 |
| smoser | there is not. | 11:52 |
| smoser | maybe Fixes-bug: | 11:52 |
| smoser | it isnt necessary, but it seems reasonable to put sanely formated data. | 11:52 |
| smoser | maybe i should just accept arbitrary string searching | 11:53 |
| smoser | from | 11:53 |
| smoser | zgrep -E LP: /usr/share/doc/*/changelog.Debian.gz | grep -e "#[0-9]\+[ ]*[ ,]\+[#*][0-9]\+" | 11:53 |
| smoser | it seems like LP: #NN, #NN | 11:53 |
| smoser | is pretty common in changelogs | 11:53 |
| smoser | so for multiple bugs i'll do | 11:53 |
| smoser | LP: #BUG, #BUG | 11:53 |
| cjwatson | Both '#' characters are necessary, yes. | 11:53 |
| rbasak | The problem is that you're making something up that is likely to be non-standard. | 11:53 |
| rbasak | You say Fixes, someone else says Closes, etc. So I don't think you get any benefit there unless someone defines something. | 11:54 |
| rbasak | I'd just put "LP: #NNN" on a line on its own. | 11:54 |
| cjwatson | 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:54 |
| rbasak | (or "LP: #XXX, #YYY" of course) | 11:55 |
| rbasak | The nice thing about that is that it also matches the pseudo-header syntax that others tend to use. | 11:56 |
| smoser | well, because i'm in the position where i can actually make consistency for this, it seems better to do it. | 11:56 |
| rbasak | You can't make consistency for this. | 11:56 |
| rbasak | You'll end up with a history that does one thing, and a future that potentially does something else. | 11:57 |
| smoser | i surely can for my repo. | 11:57 |
| rbasak | 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 |
| rbasak | I'm just saying that you shouldn't arbitrarily invent anything here. | 11:57 |
| smoser | 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 |
| nacc | the latter is not correct syntax | 11:59 |
| nacc | aiui | 11:59 |
| rbasak | 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 |
| nacc | it should be LP #XXXX in that case | 11:59 |
| nacc | LP: is "special" | 11:59 |
| cjwatson | The traditional approach in changelogs is as nacc says. | 11:59 |
| cjwatson | It'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 |
| xnox | oh wow. | 12:00 |
| smoser | Fixes: LP: # does not. | 12:00 |
| rbasak | It might be worth looking into whether git-dch can parse that. | 12:01 |
| rbasak | I know it parses "LP: #XXX" on a line on its own fine. | 12:02 |
| smoser | alright. i'll go with just LP: # as new line. | 12:02 |
| rbasak | Thanks. 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_ | ||
| semiosis | 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 |
| ubottu | bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985 | 13:25 |
| === sakrecoer is now known as sakrecoer_ | ||
| === JanC is now known as Guest24709 | ||
| === JanC_ is now known as JanC | ||
| smoser | rbasak, so.. i tried that mono bzr fast-export rewriter... had issues. | 14:33 |
| smoser | i could not get it to work for me | 14:33 |
| smoser | however, this does work: | 14:33 |
| smoser | http://paste.ubuntu.com/21144779/ | 14:33 |
| smoser | and seems much better sutied for the task. ie, i just modified fastexport in bzr to update the messages. | 14:33 |
| rbasak | smoser: seems reasonable | 14:35 |
| rbasak | smoser: it might be sensible to send that upstream, too. Though your code is a little hacky IMHO. | 14:35 |
| LocutusOfBorg | can anybody please try to clean ppc64el builders space? | 14:56 |
| LocutusOfBorg | objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN[.rodata]: No space left on device | 14:56 |
| LocutusOfBorg | objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN: No space left on device | 14:56 |
| LocutusOfBorg | or should I do something else | 14:56 |
| LocutusOfBorg | https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-1ubuntu1/+build/10520384 | 14:57 |
| smoser | rbasak, agreed on both counts. hacky and would be nice to have that as an option. | 15:03 |
| smoser | you'd have to provide some option for how to translate some template or something. | 15:03 |
| rbasak | smoser: IMHO, for the sake of consistency there shouldn't be a configurable template option. Just do the one thing one way. | 15:05 |
| Odd_Bloke | semiosis: The next yakkety build should have them. | 15:09 |
| Odd_Bloke | semiosis: (Thanks for the ping though, I'd forgotten to push a button) | 15:09 |
| smoser | rbasak, but there are different bug sources | 15:12 |
| smoser | not everyone uses launchpad | 15:12 |
| smoser | i know, its hard to believe :) | 15:12 |
| rbasak | 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 |
| smoser | well, sort of | 15:13 |
| smoser | bzr knows the bug url | 15:13 |
| smoser | so it could quite easily do: | 15:13 |
| smoser | fixes-bug: bugurl | 15:14 |
| smoser | fixes-bug: bugurl2 | 15:14 |
| smoser | but extracting the bug number out of any bug systems url is more complex. | 15:14 |
| smoser | and that assumes good data in those urls | 15:14 |
| smoser | consistent url formats across every committer | 15:14 |
| dobey | well, it's easy enough for launchpad to handle launchpad bug urls | 15:18 |
| dobey | beyond that, you just have a url which is generally good enough | 15:18 |
| dobey | see url, click url, get bug | 15:19 |
| dobey | *** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: 0x01f5c390 *** | 15:22 |
| dobey | well, that sucks | 15:22 |
| dobey | oops | 15:23 |
| bregma | 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:34 |
| jbicha | bregma: universe b-depends are ok now: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html | 15:36 |
| bregma | I ask because I'm looking at having to MIR 114 packages to get Unity 8 into main *without* the build-deps | 15:36 |
| bregma | jbicha, what about packages needed only for running autopkgtests? | 15:37 |
| jbicha | that's a good email list to subscribe to if you don't already | 15:37 |
| pitti | bregma: test dependencies can come from any component | 15:37 |
| bregma | I'm subscribed, so I was peripherally aware of the change but the wiki documentation is not up to date | 15:38 |
| dobey | build-deps are ok being in universe, if they don't create binary deps on things in universe | 15:40 |
| semiosis | Odd_Bloke: glad to hear it. thank you! | 15:48 |
| mterry | @pilot in | 16: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 | ||
| mterry | 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? | 17:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!