[00:40] Hi guys, now please don't laugh... but what is the difference between the mini-iso and ubuntu-core? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === mmrazik is now known as mmrazik|lunch === Ursinha is now known as Ursinha-afk === mmrazik|lunch is now known as mmrazik === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [12:13] infinity, FYI, still no cadejo (IS is pinged again though) [12:14] ogra_: Pinging's about the best I can do too, so if you're keeping on them about it, at least you're in the right timezone to do so. :/ [12:16] yeah [12:17] i really wonder why such outages always happen when we actually need the machines for sprints etc ... while they are happy all the rest of the time where they only do daily operation [12:17] must be a builtin panda-murphy or so [12:19] We lose several Pandas a week to random things. It's less about Murphy and more about using glorified cell phones as production servers. [12:19] This horrible misery should all be past us in a year or three, but it's going to feel like a decade. [12:20] * ogra_ is more in the "three" camp [12:20] Well, it depends. We could get armv7 (A9 or A15) server kit this year, and it may even be stable and awesome. It certainly can't be worse than dev boards. [12:21] But the "three" would be around what one might expect for decent armv8 kit. [12:21] Which is, ultimately, where we want to be. Building armhf on arm64 machines (just as we build powerpc on ppc64, i386 on amd64, etc) [12:21] i highly doubt the "this year" part here [12:22] It already exists in the wild. [12:22] It's just scarce. [12:22] i know you will likely have to pre-order a year in advance though [12:22] amnd get a hand soldered machine signed by the engineer or so [12:23] :P [12:58] any SRU team members around? bug 1085255 has been fixed commited for a while now and openstack upstream are about to release a new point release for folsom so it would be great if the packages could be pushed through to -updates [12:58] Launchpad bug 1085255 in quantum (Ubuntu Quantal) "Meta bug for tracking Openstack 2012.2.1 Stable Update" [Undecided,Fix committed] https://launchpad.net/bugs/1085255 [13:05] jamespage: Did no one bother to verify any of the other bugs? [13:06] jamespage: Oh, I see, this is part of some provisional MRE with fancy CI testing strategy. [13:07] infinity, indeed it is :-) [13:07] * jamespage nearly had a heart attack then [13:07] infinity, adam_g has put it through the CI testing; we test a few deployment configurations [13:07] To be clear, I'm still not happy about not having specific bugs verified. Why reference them in the changelog if no one's willing to test? [13:08] (The kernel has an MRE too, but they verify every single bug they fix, or revert the patch) [13:09] Yeah, I'm not happy about it either. If nothing else, if all the bugs in the changelog were verified (one way or another), then you'd find that the update would be pushed to -updates without you having to ask. [13:10] Which should clearly be better from your point of view. === Ursinha-afk is now known as Ursinha [13:12] jamespage: Anyhow. Releasing it this time, but I really do think we need to revisit this. It's lovely you have rigorous QA (hey, so does the kernel), but if you're claiming to fix specific bugs, it shouldn't be too much to ask that someone verifies they're actually fixed. [13:13] infinity, OK - I've kinda picked up on the back of this SRU; once we have this lot through I happy to revisit and figure out what fits best for SRU + Ubuntu Server team [13:15] jamespage: Different people have different workflows, and I'm entirely prepared to acknowledge that, but the bottom line, really, is that if you say you've fixed a bug, you should be prepared to test and back that up. [13:15] jamespage: And hey, if that means adding a new test for every bug to your automated CI machine of doom, verifying the results, and then marking v-done on each bug after looking at the logs, that's cool. Just something other than "well, we tested all the bits together and none of our computers are on fire, so it probably also fixed all these other bugs". [13:18] jamespage: Well, you should be prepared to test, or prepared to revert. The latter being the stance the kernel team took. If bug reporters outside their team refuse to verify bugs, they just revert the patches and say "nyah nyah". [13:19] jamespage: (You'd be amazed at how effective that's been at getting people to test) [13:21] infinity, so I'm busy reading through the TB list around this MRE [13:21] infinity, I expect this has been discussed prior to now (but it did not involve me :-)) [13:26] infinity, cjwatson: is the objection from you guys that the specific bugs are referenced at-all in the changelog? [13:26] jamespage: No. If the uploads fix bugs, referencing them is good and right. [13:26] jamespage: But if you claim it fixes bugs, someone should test that the bugs are fixed. [13:27] infinity, so reading this https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [13:27] "For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessary to manually independently verify them. (Some bugs may deserve specific verification if for example they are hard to reproduce upstream.) " [13:27] jamespage: I'll use the kernel team as a stellar example here again. They do a ton of regression testing (not unlike your CI infrastructure), but if they also fix specific bugs, they verify those. [13:28] jamespage: It's possible I disagree with the wiki on this point. But it does seem you're more or less doing as told in this case. [13:30] jamespage: My objection is the mismatch between listing bugs in the changelog and tagging them [13:30] jamespage: There's also the part where provisional MREs aren't quite MREs. [13:30] cjwatson: To be fair, they're doing exactly what the MRE instructions say to do. [13:30] jamespage: That note in the MRE page is more intended to be about random bugs cited in the upstream changelog, rather than ones that you've gone to the effort of listing explicitly in debian/changelog [13:31] "When the preceding steps have been done, the headline bug (only) should be marked verification-done" [13:31] cjwatson, well gone to effort is actually 'generated the changelog from git' in this case [13:31] A bletcherous practice, but it still counts as effort :) [13:32] The uploader still takes responsibility for the output of automated tools [13:32] Anyway, the point of the MRE thing should - IMO - be that you don't have to manually verify them, not that the bugs don't have to be tagged [13:32] cjwatson, indeed - ftr its also peer reviewed [13:32] I don't know where that thing about only tagging the headline bug came from - it's clearly wildly out of step with the process [13:33] Feel free to bring that up on the TB list for correction [13:34] The whole process would, in any case, work much more smoothly if all bugs mentioned in the changelog were tagged. Whichever way you want to resolve that. [13:35] Hello o/ :) [13:35] cjwatson, OK - I'll give that some sort; we actually raise tasks for Ubuntu during the SRU update process if they are missing; maybe we should stop doing that [13:35] As in, this update would have been released over three weeks ago. [13:35] cjwatson: Can you clarify what tag you want? [13:35] verification-done [13:35] jamespage: Yeah, sounds pretty pointless [13:35] sort/thought [13:35] If there's already one, listing it is useful so that it gets closed [13:35] But creating it just for the sake of independent verification you don't plan to do is pretty pointless [13:35] jamespage: If all parties involved agree that the MRE+CI is enough, then you could easily script or otherwise automate adding the v-done tag to all the bugs. [13:36] jamespage: We did do some semi-automation for handling the verification of each bug task last cycle. [13:36] infinity, indeed - if the SRU team are happy with that then we can do that [13:36] Well, it would get your SRUs released in a timely fashion, as Colin points out. === Ursinha is now known as Ursinha-afk [13:37] The only other option is to track your SRUs separately, as we do for the kernel, but that doesn't scale well if we have too many unique snowflakes. [13:37] jamespage: There is tooling to change tag state, already in the tools branch.. no? [13:37] The SRU team is looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html and in general isn't going to have read all the bug histories; the best way to get something released is to make sure it all looks nice and green there. [13:37] infinity: well the openstack suite is getting larger per cycle.. so yeah [13:37] (I do still tend to eyeball each bug to catch abuse, and so would appreciate it if there weren't a wild excess of automatically-created bugs there) [13:38] if we release early and often avoids the wild excess :) [13:38] Speaking of old SRUs, I need to do something about my initramfs-tools in precise for dot-two. Grr. [13:39] Daviey: Helps, but even so it's a lot quicker to eyeball (say) two bugs than five :) === Ursinha-afk is now known as Ursinha [13:40] cjwatson: I think that was the initial reason for the master tracking bug TBH [13:40] infinity, cjwatson: well we could not auto-generate missing bug tasks and links in the changelog; so we only see 'Ubuntu reported' bugs [13:41] Daviey: Right, the master bug is not the problem here, it's all the other ones that as far as pending-sru.html is concerned appear to be blocking the release [13:41] which would limit the SRU list [13:41] jamespage: Sounds entirely rationale [13:41] *rational [13:41] That seems like a decision to not do work with no value :-) [13:41] cjwatson, I'd be happier automating the verification-done stuff on that basis; as its against actual ubuntu bugs rather than upstream [13:42] jamespage: I don't actually have issues with the tasks being created and then tagged, though Colin's eyeballing point stands too. [13:42] jamespage: Or, you could write the bug references that don't have Ubuntu tasks in such a way that dpkg-genchanges doesn't see them as bug closures [13:42] cjwatson: I did disucss with SpamapS about the potential to NOT tag and comment on each bug, as part of the SRU process. [13:42] e.g. "see LP #nnnnnn" [13:42] cjwatson: It seems quite rude to hijack an 'upstream' bug with verbose ubuntu process. [13:42] That way, they're available as cross-references for humans, but don't jam up the process [13:42] cjwatson, that would still let end-users reference back to LP [13:42] Daviey: Indeed [13:42] cjwatson, which gets a +1 from me [13:42] cjwatson: The only sadness with intentionally avoiding closure syntax is you miss out on auto-linking in web UIs and such. [13:42] "Hi $someone-that-doesn't-care-about Ubuntu, please test our Ubuntu packages" [13:43] infinity: Yeah, but that's fairly minor ... [13:43] (And some UIs will manage to guesstimate it anyway) [13:43] So this sounds like we're all in agreement and we just need to correct the lies in the MRE process [13:43] cjwatson, lol [13:43] erm, the LP UI is still fine.. It was more the sru-accept.py content that i found uncomfortable [13:43] so to summarize [13:43] marking them with LP janitor closing logs is reasonable IMO [13:44] 1) don't generate bug tasks and closes entries for upstream bugs with no ubuntu task [13:44] If they aren't in a form that dpkg-genchanges recognises, the LP janitor won't close them [13:44] Which IMO is fine here [13:44] 2) still reference the bug in the changelog but without the closure [13:44] Hmm, i don't see the problem with a Ubuntu bugtask? [13:44] If you have an Ubuntu bug task, you should close it [13:44] and why not close them? [13:44] Otherwise you'll end up with cruft in the bug database [13:44] 3) automate the verification-done step once all is good [13:45] If you close them, they'll show up on sru-report / sru-accept etc. and you MUST tag them when happy to release [13:45] I don't care which way round you do things, but it needs to match [13:45] Right.. I mean.. Have a bug task, and have the changelogs reference them.. but don't add sru tracking tags to the bugs? [13:45] That ain't happening because the tools can't tell [13:45] Daviey, this is why [13:45] " - [1c99b24] Jenkins jobs fail because of incompatibility between sqlalchemy- [13:45] migrate and the newest sqlalchemy-0.8.0b1 (LP: #1073569)" [13:45] Launchpad bug 1073569 in nova (Ubuntu) "Jenkins jobs fail because of incompatibility between sqlalchemy-migrate and the newest sqlalchemy-0.8.0b1" [Undecided,Fix committed] https://launchpad.net/bugs/1073569 [13:46] raising the task and marking verification-done is farcical [13:46] You have to either (a) both have Ubuntu (appropriate stable release) bug tasks and set appropriate verification tags, or (b) neither [13:46] cjwatson: pending-sru.htmk can't be fixed to ignore bugs without tags? [13:47] Daviey: sru-accept can't be fixed to automatically not create them, and it is very bad to require even more manual work in that process [13:47] Daviey: One of the reasons the SRU queue gets so backed up is that the tools for accepting SRUs require so much tedious manual work [13:47] Daviey: (Which is on somebody's WI list to fix this cycle) [13:47] cjwatson: ./sru-accept $@ --no-tags, wouldn't be reasonable? [13:47] Daviey: No, because it still needs tags for some bugs [13:48] Daviey: And, in any case, the goal is not to require manual invocation of sru-accept at all [13:48] It should be done automatically from a frontend SRU review tool [13:48] I don't think it's necessary for openstack packages to be special snowflakes here [13:48] cjwatson: Okay.. I will be saddened if we lose the ability to have presence for each suitable bugtask [13:49] You have two perfectly good options to choose from for any given bug, both of which will work fine [13:49] So.. If there is a ubuntu task ALREADY.. we tag it.. but don'tcreate superfluous ones? [13:49] infinity, cjwatson: FYI, langpacks built, debdiffed and tested, uploading now (for precise) [13:49] Daviey: Nobody is saying you need to lose that ability [13:49] Daviey: You simply need to tag the bug verification-done if you do it [13:49] Daviey: Otherwise your update sits in a queue for weeks [13:49] Or rather, in -proposed [13:49] pitti: Huzzah. [13:49] Daviey: This is a simple matter of appropriate communication ... [13:50] right [13:51] And if a bug task is unsuitable for having an Ubuntu bug task and the bug log noise that goes along with it, just don't give it one and don't use the LP: #nnnnnn syntax for it in the changelog [13:51] (After all, most upstream commits in most projects never have an associated bug task and it's fine) [13:51] jamespage: the too for git->dch changelogs already polls for LP bug... we should make it check if there is already a task.. and use proper LP #syntax if there is, and inproper LP syntax if it doesn't. Sound reasonable, everyone? [13:51] cjwatson: these should all MOSTLY have LP bug tasks fwiw [13:51] (upstream) [13:51] I mean Ubuntu bug tasks [13:52] ah, yes [13:52] changelog tool> that will be fine so long as all the ones that do have Ubuntu bug tasks then get tagged v-done when the MRE upload is ready to go [13:52] Then the whole thing will light up green in pending-sru and we'll know what to do [13:53] infinity: do we still have a way to mass-accept them from -proposed? [13:53] cjwatson, OK _ I think I have it now [13:53] infinity: from unapproved I mean [13:53] pitti: Yep. [13:53] pitti: I'll get to them shortlyish. [13:53] jamespage / cjwatson: We will also track pending-sru's closer :) [13:53] infinity: ok, thanks; please let me know if you still need anything from me langpack-wise [13:54] pitti: Assuming these are complete and all work, I'm fine with 'em. [13:54] pitti: do you not use the queue tool? [13:54] pitti: Thanks for the silly workaround to appease people's missing hash phobias. [13:54] Daviey: ah right, that; TBH, I've become a bit rusty with archive admin stuff [13:55] Daviey: pitti probably still lives in the past where we used to do everything on ftpmaster. [13:55] infinity: no worries; at some point I'll need to get the built sources to macquarie, but that's not a biggie [13:55] infinity: actually, most of what I did was by-package review and clicking accept on the +queue page :) [13:55] For this purpose queue is basically equivalent to the old ftpmaster queue with additional network latency per accept but lower startup cost [13:55] pitti: the queue tool can match by regex.. but wise to use --dry-run first :) [13:56] Oh, and it no longer does substring match by default [13:56] err, yeah substring.. not regex. [13:56] yeah, I remember now [14:00] pitti: How many of these are there, BTW? [14:00] infinity: stil uploading; 500ish [14:01] Need fewer languages. [14:01] crikey, i had better free up some inodes on my mail server, for the noise on *-changes [14:01] infinity: oh, 824 [14:01] Can't we just roughly divide the world into "English America", "Spanish America", "German Europe", "Russian Europe/Asia", and "Chinese everywhereelse"? [14:02] infinity: well, there are 6 packages per language [14:02] I'm sure that wouldn't annoy anyone at all. [14:04] infinity: and about half of those packages are empty and have not translations at all =) [14:05] infinity: my solution is that when we start publishing packagesets data on the mirrors, we can publish translations packagesets (e.g. such that all gnomy apps that have translations in l18n-gnome-pack-CC declare a packageset l18n-gnome-pack) [14:06] and then we can use magic from ubuntu-drivers-common to query: oooh I have languages AA, BB, CC enabled & I have packages from l18n-gnome-pack set installed, hence my language support is incomplete until I install l18n-gnome-pack-[AA|BB|CC] === Ursinha is now known as Ursinha-afk [14:07] cause currently we have, -base|-updates gnome-base|gnome-updates mozilla chromium and kde language pack packages which a lot of them are empty [14:07] simply because we have no clear way to figure out on the client side which once are needed. [14:07] (well empty - meta-packages) [14:10] but this cunning little plan, relies on either auto-generating packageset headers or manually declaring "Translation-Pack" (in approx. similar fasion to Modaliases:*) [14:10] We'll be autogenerating package set headers as soon as I figure out the necessary pile of SQL [14:10] I need that for other reasons anyway === Ursinha-afk is now known as Ursinha [14:17] pitti: Clearly too late, since I've accepted half of these, but this has always bugged me. Could the automagic changelog for langpacks be switched from "Initial release" to something like "Updated translation export from $date". [14:17] pitti: Cause "Initial release" is so clearly a lie for most languages. :P [14:17] infinity: it actually does that if lp-o-matic updates a langpack [14:17] infinity: but for a fresh base rebuild I just rm -rf ../precise and rebuild them from scratch [14:18] infinity: so indeed, it's a wart [14:18] pitti: language-pack-hpv? [14:19] infinity: please feel free to reject the NEW ones [14:19] infinity: need to run out for some 2 hours or so, bbl [14:19] pitti: Why do we not love the NEW ones? [14:19] infinity: I thought it was a kind of principle to not introduce new packages in SRUs [14:19] infinity: I have no strong opinion either way [14:20] pitti: I have no issues with supporting new languages. [14:20] pitti: ubuntu should be usable by everyone no matter what language they speak ;-) [14:20] xnox: As long as that language is English. [14:21] infinity: as long as you accept -tlh :) [14:21] infinity: да ладно =) [14:21] xnox: I feel like you may have perhaps just cursed at me, but I'm not going to ask Google Translate. [14:22] it's not a curse, but i bet this phrase will loose it's meaning in translation. [14:22] (and the second it's should be its) [14:22] I understand "yes" at least; no idea about ладно [14:23] google translate says "oh well" [14:23] Я говорю по-русски очень плохо [14:24] cjwatson: very good. =) [14:24] pitti: =)))) [14:24] xnox: Yes, his copy and paste skills know no bounds. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === bjf[afk] is now known as bjf === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [18:19] hi huys, raring-core is in iso tracker as a tar.gz and not as an iso. Who's best to ask about that? [18:21] phillw: It's not an ISO. [18:21] phillw: I'm not sure what there is to discuss. :) [18:22] infinity: which does beg the question of it being on the iso tracker, as I can't test it :) [18:22] It's just a minimal root filesystem tarball. [18:22] I think it has a linked testcase, doesn't it? [18:23] Something like "download, untar, cp /etc/resolv.conf chroot/etc/resolv.conf, chroot in, run apt-get update, profit" [18:24] infinity: yeah.. drat... I was hoping to use it instead of mini-iso... So much for that carefully laid plan :P [18:25] phillw: It's not an installer, so that would end poorly. [18:25] What's wrong with the mini.iso? It works well. [18:26] infinity: server is currently over size as an install iso. test-drive doesn't work with mini-iso, I was looking for an alternative. [18:26] It's not a substitute for a mini.iso, and won't be. [18:27] although I am puzzled as to why server would be over size, with no GUI? [18:27] server being oversized has zero effect on testdrive [18:27] (or should do, anyway) [18:27] It's essentially an academic issue [18:28] cjwatson: okies, I'll go with server, it has the advantage of being to use the tasksel window to install a choice of GUI to it. Thanks guys, I'll leave you in peace :) [18:28] It turns out there's loads of other stuff people want to shove in *shrug* [18:28] Think cloud, for instance [18:28] The whole cloud. [18:28] All of it. [18:28] And only 15MB over a CD. [18:28] he he [18:28] Not too shabby. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [19:37] cjwatson: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1040393 verified for you, if you want to push that before I spin a new d-i with only ABI changes. [19:37] Ubuntu bug 1040393 in debian-installer (Ubuntu Precise) "omap netboot partition too small for flash-kernel backup procedure" [Undecided,Fix committed] [19:41] anyone have a clue how often teams are refreshed for our burn down charts? [19:42] for ex, I just punted pgraner from canonical-kernel-distro-team to get a more accurate view of the work assigned to my team, but it has yet to update and I made the change over 2hrs ago [19:43] I have no clue how or when any of that is generated. Was that helpful? [19:44] infinity: slightly [19:46] ogasawara: from personal experience it is ~4h [19:47] xnox: ah thanks, I'll be more patient and check it later then [19:51] ^ done at cyphermox's request [20:18] ogasawara: looks like an update just happened ~5m ago [20:20] vanhoof: hrm, I expected more things to fall off, you sure it's happened? [20:21] vanhoof: I do see timestamps of "Last updated: Tue 29 January 2013, 20:13 UTC" but I don't think the team actually refreshed [20:22] ogasawara: hmm not sure, i know all of this is stored in a db, i wonder if removing someone from a team is enough since the work items were already registered? [20:23] ogasawara: from when i ran my own instance of this, it updated everything each time, but might take a bit longer in this case? [20:23] ogasawara: i was going off of the same timestamps myself [20:24] vanhoof: which reminds me, call today? [20:24] ogasawara: sure [20:25] ogasawara: whenever is good for you, im call free for a few hours :) [20:25] vanhoof: sweet, how bout now [20:25] ogasawara: sure === Ursinha-afk is now known as Ursinha [21:08] we've validated both bug 1080588 and bug 1091068 ... can we get these promoted to -updates for 12.04.2 (believe those are the last two big ones on our radar for the point release) [21:08] Launchpad bug 1080588 in jockey (Ubuntu) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588 [21:08] Launchpad bug 1091068 in linux (Ubuntu Quantal) "No support for Ivybridge Server GPUs in 12.04" [High,Triaged] https://launchpad.net/bugs/1091068 [21:15] vanhoof: Patience. :) [21:15] vanhoof: They'll both get in if they're validated, no worries. [21:16] infinity: ... is a virtue ;) [21:16] Also the name of a Firefly character. [21:16] infinity: ack, wfm ... just dont want any to fall off :) [21:17] infinity: thanks [21:17] That IveBridge bug appears to have 'linux' tasks that are still in Triaged. [21:17] Did the kernel get fixed without a bug reference at some point? [21:17] Or did the kernel not actually need fixing? [21:18] Oh, I see, it got broken out into another bug and fixed. Should twiddle those tasks, then. [21:18] infinity: think thats been sorted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087302 [21:18] Ubuntu bug 1087302 in linux (Ubuntu Quantal) "Add support for Ivy Bridge GT2 Servers" [Medium,Fix released] [21:18] infinity: just task/bug-galore === Ursinha is now known as Ursinha-afk [21:20] infinity: you're too fast I was just about to do that :) [21:20] :P [21:20] I've come to the conclusion that my changelogs are too long. [21:20] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/613662/comments/11 <-- That's, like, half the bug log. [21:20] Ubuntu bug 613662 in eglibc (Ubuntu Quantal) "nscd doesn't cache host entries" [Undecided,Fix committed] [21:21] infinity: nice :) [21:22] vanhoof: Speaking of. I had several people from several teams asking for things in the latest eglibc SRUs. I don't recall if any of those were you. But if so, feel free to peruse the bugs and verify one or two. :P [21:22] https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.4 [21:23] infinity: nothing off-hand I know of but let me look [21:23] Kay. I need to hunt down the people who cared deeply about the malloc deadlock and the ARM futex thing. [21:24] The rest, a monkey on valium could validate. [21:24] infinity: nothing sounds familiar, have any names handy, i can go help chase em down [21:24] I'll remember after I've slept, I'm sure. [21:24] It's been one of those weeks already. [21:24] infinity: :) [21:24] (Is it Friday yet?) [21:25] infinity: almost [21:25] Are you lying to make me feel better? [21:25] infinity: in 35m it will be [21:25] You don't have to do that, we're not dating. [21:25] roflz [21:26] infinity: i like long walks on the beach, drag racing, and hockey [21:26] I also enjoy racing in dresses. [21:26] We have so much in common. [21:27] :D [21:27] * xnox goes back to knitting scarf [21:27] xnox: orange please === Noskcaj is now known as Noskcaj_afk [21:28] vanhoof: sure, next one will be orange. [21:29] vanhoof: Flyers orange or Ubuntu orange? [21:29] vanhoof: Answer carefully. [21:30] infinity: ubuntu ;) [21:30] I dont like that traitor of a coach the Flyers have ;) [21:31] xnox: http://ubuntuone.com/45rb67F6TBowKJJm3Fb283 ... -ENEEDSCARF [21:31] vanhoof: is that actually your dog? [21:31] I refuse to believe a dog can use onboard. [21:32] Most humans can't. [21:32] yeah she's blessing me with her presence as we speak :) [21:32] me can do a small one for her ;-) [21:32] balloons: Hey dude. You filed a bug a bazillion years ago and never followed up for SRU verification. [21:33] balloons: y u no love us? [21:33] balloons: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1018504 [21:33] Ubuntu bug 1018504 in empathy (Fedora) "Empathy doesn't display buddy list" [Undecided,New] [21:33] xnox: :D [21:33] xnox: she's 50lb so not too small :) [21:33] infinity, ooo [21:33] that got fixed [21:33] I check it out [21:34] what's up with it? [21:34] balloons: It got fixed 125 days ago, apparently, but you never verified on precise. Sadness. [21:34] wha? I thought it got verified :-( [21:34] it worked for me [21:34] balloons: I'd love to release that SRU instead of pulling it, if you can verify. [21:34] I'm not on precise anymore [21:34] infinity: /me is doing libnih verification. It's ~approx. from that timeframe. [21:35] ahh.. looks like it never made it to precise perhaps [21:35] ? [21:35] balloons: Your only comment was about it being fixed in Q, which was less than helpful. :/ [21:35] balloons: It's been in precise-proposed for 125 days due to lack of verification. [21:35] well, I can reload precise and do a verify [21:36] i thought it was released :-( [21:36] hmm [21:36] xnox: Someone should SRU libnih to whack that glibc private symbol usage too, to help apt's tiny brain cope better with upgrades. [21:38] xnox: Though, would require an apport SRU for completeness too. [21:38] xnox: https://bugs.launchpad.net/libnih/+bug/997359 [21:38] Ubuntu bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [Undecided,Confirmed] [21:52] infinity: yeah, somehow coverity source code analyser says that __abort_msg is never reached in the code (or something like always evaluating to a const value). I'd like to check that first. [21:53] xnox: Why check that when it should be removed? :P [21:53] as in the other _nih__abort_msg symbol that got introduced to replace the glibc one is not reached, that is. [21:53] =D [22:25] infinity, fyi, while cadejo is reachable via http, it doesnt seem to do anything when triggering a build [22:25] buildlive just silently hangs forever === yofel_ is now known as yofel [22:33] ogra_: Oh, that probably means you have a few dozen BuildLiveCDs all sitting there waiting on locks. [22:34] nothing in nusakans processlist [22:34] i had started a manual build right after it came up again, but killed it now since nothing happened [22:35] nusakan has nothing to do with it. [22:35] killing the ssh session doesn't kill the remote. [22:35] Anyhow, looking into it. [22:35] i know [22:35] i dont think there was a remote session [22:35] or if there was one it was just sitting there [22:35] none of the logs moved [22:36] You missed the part where I said "waiting on locks", right? [22:36] Probably had a stale lock when it came up. [22:37] i didnt, thats what i was agreeing to :) [22:37] "sitting there" [22:37] hmpf, so why does my upstart job not work ... [22:37] i can run it manually but it never runs automatically [22:38] ogra_: never starts or fails once started? [22:38] Does it specify when it should start? [22:38] ogra_: (do you have /var/log/upstart/.log?) [22:38] Does it double-fork itself into oblivion and upstart loses it? [22:38] http://paste.ubuntu.com/1587278/ [22:38] pretty trivial [22:39] vanhoof: yeah, the routine for 12.04.2 is going to be that we manually check everything that *doesn't* seem to be going in [22:39] oh, i didnt know about that log stuff !!! [22:40] gah [22:40] maybe it objects to your pointless use of /bin/echo? :) [22:40] cannot create /sys/devices/system/cpu/cpufreq/interactive/boost_factor: Directory nonexistent [22:40] cjwatson: cool, feel free to yell^Wping if you see anything on our end but outside of a few that are already verified, we look to be good [22:40] ogra_: hehe, and upstart runs with -e, so any error is critical and the script stops there [22:40] i guess i need to bind that to a udev rule and wait for the governor to be initialized [22:40] vanhoof: wouldn't hurt to have a list of things to pay attention to, but it's not vital [22:40] ogra_: well, we have a udev bridge you know ;) [22:41] right [22:41] cjwatson: noted, i'll have a pass at the queue this evening to be sure [22:41] ogra_: Or just do it from ondemand, where the governor gets set. [22:41] ogra_: so you can do a "start on -added" assuming you know what device type you're looking at [22:41] infinity, ondemand is off on the nexus [22:41] though in this case, it'd be "cpu" which you should have before anything runs :) [22:41] ogra_: Eh? [22:41] and yeah, I'm checking pending-sru for verified stuff more than once a day; I expect I'm not the only one [22:41] we use interactive like android [22:42] ogra_: I meant the script. [22:42] ogra_: I know we use interactive, I'm the one who patched it. :P [22:42] ondemand has proven to be pretty wasteful [22:42] oh [22:42] that one [22:42] * ogra_ tries to stay away from sysvinit for new stuff usually ... i didnt even think about it [22:44] though that wont help much if the governor is slow to initalize [22:45] i tested the upstart job with "start on started lightdm" i desparation ... seems the dir wasnt even there by then [22:45] s/i/in/ [22:45] ogra_: That's inentional. Read /etc/init.d/ondemand [22:46] ogra_: The script sleeps so the machine can tear through boot in performance, before dropping you to a friendlier scheduler. [22:46] heh [22:46] infinity: I think he means the kernel side is slow to appear, not referring to the delay in the init script? [22:46] lol [22:46] yeah [22:47] slangasek, right, i did [22:47] slangasek: The delay in the init script is why the kernel side isn't there, I imagine. [22:47]