phillwHi guys, now please don't laugh... but what is the difference between the mini-iso and ubuntu-core?00:40
=== 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
ogra_infinity, FYI, still no cadejo (IS is pinged again though)12:13
infinityogra_: 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:14
ogra_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 operation12:17
ogra_must be a builtin panda-murphy or so12:17
infinityWe 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
infinityThis horrible misery should all be past us in a year or three, but it's going to feel like a decade.12:19
* ogra_ is more in the "three" camp12:20
infinityWell, 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:20
infinityBut the "three" would be around what one might expect for decent armv8 kit.12:21
infinityWhich 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
ogra_i highly doubt the "this year" part here12:21
infinityIt already exists in the wild.12:22
infinityIt's just scarce.12:22
ogra_i know you will likely have to pre-order a year in advance though12:22
ogra_amnd get a hand soldered machine signed by the engineer or so12:22
jamespageany 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 -updates12:58
ubot2Launchpad bug 1085255 in quantum (Ubuntu Quantal) "Meta bug for tracking Openstack 2012.2.1 Stable Update" [Undecided,Fix committed] https://launchpad.net/bugs/108525512:58
infinityjamespage: Did no one bother to verify any of the other bugs?13:05
infinityjamespage: Oh, I see, this is part of some provisional MRE with fancy CI testing strategy.13:06
jamespageinfinity, indeed it is :-)13:07
* jamespage nearly had a heart attack then13:07
jamespageinfinity, adam_g has put it through the CI testing; we test a few deployment configurations13:07
infinityTo 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:07
infinity(The kernel has an MRE too, but they verify every single bug they fix, or revert the patch)13:08
cjwatsonYeah, 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:09
cjwatsonWhich should clearly be better from your point of view.13:10
=== Ursinha-afk is now known as Ursinha
infinityjamespage: 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:12
jamespageinfinity, 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 team13:13
infinityjamespage: 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
infinityjamespage: 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:15
infinityjamespage: 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:18
infinityjamespage: (You'd be amazed at how effective that's been at getting people to test)13:19
jamespageinfinity, so I'm busy reading through the TB list around this MRE13:21
jamespageinfinity, I expect this has been discussed prior to now (but it did not involve me :-))13:21
jamespageinfinity, cjwatson: is the objection from you guys that the specific bugs are referenced at-all in the changelog?13:26
infinityjamespage: No.  If the uploads fix bugs, referencing them is good and right.13:26
infinityjamespage: But if you claim it fixes bugs, someone should test that the bugs are fixed.13:26
jamespageinfinity, so reading this https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions13:27
jamespage"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
infinityjamespage: 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:27
infinityjamespage: 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:28
cjwatsonjamespage: My objection is the mismatch between listing bugs in the changelog and tagging them13:30
infinityjamespage: There's also the part where provisional MREs aren't quite MREs.13:30
infinitycjwatson: To be fair, they're doing exactly what the MRE instructions say to do.13:30
cjwatsonjamespage: 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/changelog13:30
infinity"When the preceding steps have been done, the headline bug (only) should be marked verification-done"13:31
jamespagecjwatson, well gone to effort is actually 'generated the changelog from git' in this case13:31
cjwatsonA bletcherous practice, but it still counts as effort :)13:31
cjwatsonThe uploader still takes responsibility for the output of automated tools13:32
cjwatsonAnyway, 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 tagged13:32
jamespagecjwatson, indeed - ftr its also peer reviewed13:32
cjwatsonI don't know where that thing about only tagging the headline bug came from - it's clearly wildly out of step with the process13:32
cjwatsonFeel free to bring that up on the TB list for correction13:33
cjwatsonThe 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:34
DavieyHello o/ :)13:35
jamespagecjwatson, 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 that13:35
cjwatsonAs in, this update would have been released over three weeks ago.13:35
Davieycjwatson: Can you clarify what tag you want?13:35
cjwatsonjamespage: Yeah, sounds pretty pointless13:35
cjwatsonIf there's already one, listing it is useful so that it gets closed13:35
cjwatsonBut creating it just for the sake of independent verification you don't plan to do is pretty pointless13:35
infinityjamespage: 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:35
Davieyjamespage: We did do some semi-automation for handling the verification of each bug task last cycle.13:36
jamespageinfinity, indeed - if the SRU team are happy with that then we can do that13:36
infinityWell, it would get your SRUs released in a timely fashion, as Colin points out.13:36
=== Ursinha is now known as Ursinha-afk
infinityThe 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
Davieyjamespage: There is tooling to change tag state, already in the tools branch.. no?13:37
cjwatsonThe 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
Davieyinfinity: well the openstack suite is getting larger per cycle.. so yeah13:37
cjwatson(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:37
Davieyif we release early and often avoids the wild excess :)13:38
infinitySpeaking of old SRUs, I need to do something about my initramfs-tools in precise for dot-two.  Grr.13:38
cjwatsonDaviey: Helps, but even so it's a lot quicker to eyeball (say) two bugs than five :)13:39
=== Ursinha-afk is now known as Ursinha
Davieycjwatson: I think that was the initial reason for the master tracking bug TBH13:40
jamespageinfinity, cjwatson: well we could not auto-generate missing bug tasks and links in the changelog; so we only see 'Ubuntu reported' bugs13:40
cjwatsonDaviey: 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 release13:41
jamespagewhich would limit the SRU list13:41
cjwatsonjamespage: Sounds entirely rationale13:41
cjwatsonThat seems like a decision to not do work with no value :-)13:41
jamespagecjwatson, I'd be happier automating the verification-done stuff on that basis; as its against actual ubuntu bugs rather than upstream13:41
infinityjamespage: I don't actually have issues with the tasks being created and then tagged, though Colin's eyeballing point stands too.13:42
cjwatsonjamespage: 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 closures13:42
Davieycjwatson: I did disucss with SpamapS about the potential to NOT tag and comment on each bug, as part of the SRU process.13:42
cjwatsone.g. "see LP #nnnnnn"13:42
Davieycjwatson: It seems quite rude to hijack an 'upstream' bug with verbose ubuntu process.13:42
cjwatsonThat way, they're available as cross-references for humans, but don't jam up the process13:42
jamespagecjwatson, that would still let end-users reference back to LP13:42
cjwatsonDaviey: Indeed13:42
jamespagecjwatson, which gets a +1 from me13:42
infinitycjwatson: The only sadness with intentionally avoiding closure syntax is you miss out on auto-linking in web UIs and such.13:42
Daviey"Hi $someone-that-doesn't-care-about Ubuntu, please test our Ubuntu packages"13:42
cjwatsoninfinity: Yeah, but that's fairly minor ...13:43
cjwatson(And some UIs will manage to guesstimate it anyway)13:43
cjwatsonSo this sounds like we're all in agreement and we just need to correct the lies in the MRE process13:43
jamespagecjwatson, lol13:43
Davieyerm, the LP UI is still fine.. It was more the sru-accept.py content that i found uncomfortable13:43
jamespageso to summarize13:43
Davieymarking them with LP janitor closing logs is reasonable IMO13:43
jamespage1) don't generate bug tasks and closes entries for upstream bugs with no ubuntu task13:44
cjwatsonIf they aren't in a form that dpkg-genchanges recognises, the LP janitor won't close them13:44
cjwatsonWhich IMO is fine here13:44
jamespage2) still reference the bug in the changelog but without the closure13:44
DavieyHmm, i don't see the problem with a Ubuntu bugtask?13:44
cjwatsonIf you have an Ubuntu bug task, you should close it13:44
Davieyand why not close them?13:44
cjwatsonOtherwise you'll end up with cruft in the bug database13:44
jamespage3) automate the verification-done step once all is good13:44
cjwatsonIf you close them, they'll show up on sru-report / sru-accept etc. and you MUST tag them when happy to release13:45
cjwatsonI don't care which way round you do things, but it needs to match13:45
DavieyRight.. I mean.. Have a bug task, and have the changelogs reference them.. but don't add sru tracking tags to the bugs?13:45
cjwatsonThat ain't happening because the tools can't tell13:45
jamespageDaviey, this is why13:45
jamespage"     - [1c99b24] Jenkins jobs fail because of incompatibility between sqlalchemy-13:45
jamespage       migrate and the newest sqlalchemy-0.8.0b1 (LP: #1073569)"13:45
ubot2Launchpad 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/107356913:45
jamespageraising the task and marking verification-done is farcical13:46
cjwatsonYou have to either (a) both have Ubuntu (appropriate stable release) bug tasks and set appropriate verification tags, or (b) neither13:46
Davieycjwatson: pending-sru.htmk can't be fixed to ignore bugs without tags?13:46
cjwatsonDaviey: sru-accept can't be fixed to automatically not create them, and it is very bad to require even more manual work in that process13:47
cjwatsonDaviey: One of the reasons the SRU queue gets so backed up is that the tools for accepting SRUs require so much tedious manual work13:47
cjwatsonDaviey: (Which is on somebody's WI list to fix this cycle)13:47
Davieycjwatson: ./sru-accept $@ --no-tags, wouldn't be reasonable?13:47
cjwatsonDaviey: No, because it still needs tags for some bugs13:47
cjwatsonDaviey: And, in any case, the goal is not to require manual invocation of sru-accept at all13:48
cjwatsonIt should be done automatically from a frontend SRU review tool13:48
cjwatsonI don't think it's necessary for openstack packages to be special snowflakes here13:48
Davieycjwatson: Okay.. I will be saddened if we lose the ability to have presence for each suitable bugtask13:48
cjwatsonYou have two perfectly good options to choose from for any given bug, both of which will work fine13:49
DavieySo.. If there is a ubuntu task ALREADY.. we tag it.. but don'tcreate superfluous ones?13:49
pittiinfinity, cjwatson: FYI, langpacks built, debdiffed and tested, uploading now (for precise)13:49
cjwatsonDaviey: Nobody is saying you need to lose that ability13:49
cjwatsonDaviey: You simply need to tag the bug verification-done if you do it13:49
cjwatsonDaviey: Otherwise your update sits in a queue for weeks13:49
cjwatsonOr rather, in -proposed13:49
infinitypitti: Huzzah.13:49
cjwatsonDaviey: This is a simple matter of appropriate communication ...13:49
cjwatsonAnd 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 changelog13:51
cjwatson(After all, most upstream commits in most projects never have an associated bug task and it's fine)13:51
Davieyjamespage: 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
Davieycjwatson: these should all MOSTLY have LP bug tasks fwiw13:51
cjwatsonI mean Ubuntu bug tasks13:51
Davieyah, yes13:52
cjwatsonchangelog 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 go13:52
cjwatsonThen the whole thing will light up green in pending-sru and we'll know what to do13:52
pittiinfinity: do we still have a way to mass-accept them from -proposed?13:53
jamespagecjwatson, OK _ I think I have it now13:53
pittiinfinity: from unapproved I mean13:53
infinitypitti: Yep.13:53
infinitypitti: I'll get to them shortlyish.13:53
Davieyjamespage / cjwatson: We will also track pending-sru's closer :)13:53
pittiinfinity: ok, thanks; please let me know if you still need anything from me langpack-wise13:53
infinitypitti: Assuming these are complete and all work, I'm fine with 'em.13:54
Davieypitti: do you not use the queue tool?13:54
infinitypitti: Thanks for the silly workaround to appease people's missing hash phobias.13:54
pittiDaviey: ah right, that; TBH, I've become a bit rusty with archive admin stuff13:54
infinityDaviey: pitti probably still lives in the past where we used to do everything on ftpmaster.13:55
pittiinfinity: no worries; at some point I'll need to get the built sources to macquarie, but that's not a biggie13:55
pittiinfinity: actually, most of what I did was by-package review and clicking accept on the +queue page :)13:55
cjwatsonFor this purpose queue is basically equivalent to the old ftpmaster queue with additional network latency per accept but lower startup cost13:55
Davieypitti: the queue tool can match by regex.. but wise to use --dry-run first :)13:55
cjwatsonOh, and it no longer does substring match by default13:56
Davieyerr, yeah substring.. not regex.13:56
pittiyeah, I remember now13:56
infinitypitti: How many of these are there, BTW?14:00
pittiinfinity: stil uploading; 500ish14:00
infinityNeed fewer languages.14:01
Davieycrikey, i had better free up some inodes on my mail server, for the noise on *-changes14:01
pittiinfinity: oh, 82414:01
infinityCan't we just roughly divide the world into "English America", "Spanish America", "German Europe", "Russian Europe/Asia", and "Chinese everywhereelse"?14:01
pittiinfinity: well, there are 6 packages per language14:02
infinityI'm sure that wouldn't annoy anyone at all.14:02
xnoxinfinity: and about half of those packages are empty and have not translations at all =)14:04
xnoxinfinity: 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:05
xnoxand 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]14:06
=== Ursinha is now known as Ursinha-afk
xnoxcause currently we have, -base|-updates gnome-base|gnome-updates mozilla chromium and kde language pack packages which a lot of them are empty14:07
xnoxsimply because we have no clear way to figure out on the client side which once are needed.14:07
xnox(well empty - meta-packages)14:07
xnoxbut this cunning little plan, relies on either auto-generating packageset headers or manually declaring "Translation-Pack" (in approx. similar fasion to Modaliases:*)14:10
cjwatsonWe'll be autogenerating package set headers as soon as I figure out the necessary pile of SQL14:10
cjwatsonI need that for other reasons anyway14:10
=== Ursinha-afk is now known as Ursinha
infinitypitti: 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
infinitypitti: Cause "Initial release" is so clearly a lie for most languages. :P14:17
pittiinfinity: it actually does that if lp-o-matic updates a langpack14:17
pittiinfinity: but for a fresh base rebuild I just rm -rf ../precise and rebuild them from scratch14:17
pittiinfinity: so indeed, it's a wart14:18
infinitypitti: language-pack-hpv?14:18
pittiinfinity: please feel free to reject the NEW ones14:19
pittiinfinity: need to run out for some 2 hours or so, bbl14:19
infinitypitti: Why do we not love the NEW ones?14:19
pittiinfinity: I thought it was a kind of principle to not introduce new packages in SRUs14:19
pittiinfinity: I have no strong opinion either way14:19
infinitypitti: I have no issues with supporting new languages.14:20
xnoxpitti: ubuntu should be usable by everyone no matter what language they speak ;-)14:20
infinityxnox: As long as that language is English.14:20
pittiinfinity: as long as you accept -tlh :)14:21
xnoxinfinity: да ладно =)14:21
infinityxnox: I feel like you may have perhaps just cursed at me, but I'm not going to ask Google Translate.14:21
xnoxit's not a curse, but i bet this phrase will loose it's meaning in translation.14:22
xnox(and the second it's should be its)14:22
pittiI understand "yes" at least; no idea about ладно14:22
cjwatsongoogle translate says "oh well"14:23
pittiЯ говорю по-русски очень плохо14:23
xnoxcjwatson: very good. =)14:24
xnoxpitti: =))))14:24
infinityxnox: Yes, his copy and paste skills know no bounds.14:24
=== 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
phillwhi huys, raring-core is in iso tracker as a tar.gz and not as an iso. Who's best to ask about that?18:19
infinityphillw: It's not an ISO.18:21
infinityphillw: I'm not sure what there is to discuss. :)18:21
phillwinfinity: which does beg the question of it being on the iso tracker, as I can't test it :)18:22
infinityIt's just a minimal root filesystem tarball.18:22
infinityI think it has a linked testcase, doesn't it?18:22
infinitySomething like "download, untar, cp /etc/resolv.conf chroot/etc/resolv.conf, chroot in, run apt-get update, profit"18:23
phillwinfinity: yeah.. drat... I was hoping to use it instead of mini-iso... So much for that carefully laid plan :P18:24
infinityphillw: It's not an installer, so that would end poorly.18:25
infinityWhat's wrong with the mini.iso?  It works well.18:25
phillwinfinity: 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
cjwatsonIt's not a substitute for a mini.iso, and won't be.18:26
phillwalthough I am puzzled as to why server would be over size, with no GUI?18:27
cjwatsonserver being oversized has zero effect on testdrive18:27
cjwatson(or should do, anyway)18:27
cjwatsonIt's essentially an academic issue18:27
phillwcjwatson: 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
cjwatsonIt turns out there's loads of other stuff people want to shove in *shrug*18:28
cjwatsonThink cloud, for instance18:28
infinityThe whole cloud.18:28
infinityAll of it.18:28
infinityAnd only 15MB over a CD.18:28
phillwhe he18:28
infinityNot too shabby.18:28
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
infinitycjwatson: 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
ubot2Ubuntu bug 1040393 in debian-installer (Ubuntu Precise) "omap netboot partition too small for flash-kernel backup procedure" [Undecided,Fix committed]19:37
ogasawaraanyone have a clue how often teams are refreshed for our burn down charts?19:41
ogasawarafor 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 ago19:42
infinityI have no clue how or when any of that is generated.  Was that helpful?19:43
ogasawarainfinity: slightly19:44
xnoxogasawara: from personal experience it is ~4h19:46
ogasawaraxnox: ah thanks, I'll be more patient and check it later then19:47
stgraber^ done at cyphermox's request19:51
vanhoofogasawara: looks like an update just happened ~5m ago20:18
ogasawaravanhoof: hrm, I expected more things to fall off, you sure it's happened?20:20
ogasawaravanhoof: I do see timestamps of "Last updated: Tue 29 January 2013, 20:13 UTC" but I don't think the team actually refreshed20:21
vanhoofogasawara: 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:22
vanhoofogasawara: 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
vanhoofogasawara: i was going off of the same timestamps myself20:23
ogasawaravanhoof: which reminds me, call today?20:24
vanhoofogasawara: sure20:24
vanhoofogasawara: whenever is good for you, im call free for a few hours :)20:25
ogasawaravanhoof: sweet, how bout now20:25
vanhoofogasawara: sure20:25
=== Ursinha-afk is now known as Ursinha
vanhoofwe'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
ubot2Launchpad bug 1080588 in jockey (Ubuntu) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/108058821:08
ubot2Launchpad bug 1091068 in linux (Ubuntu Quantal) "No support for Ivybridge Server GPUs in 12.04" [High,Triaged] https://launchpad.net/bugs/109106821:08
infinityvanhoof: Patience. :)21:15
infinityvanhoof: They'll both get in if they're validated, no worries.21:15
vanhoofinfinity: ... is a virtue ;)21:16
infinityAlso the name of a Firefly character.21:16
vanhoofinfinity: ack, wfm ... just dont want any to fall off :)21:16
vanhoofinfinity: thanks21:17
infinityThat IveBridge bug appears to have 'linux' tasks that are still in Triaged.21:17
infinityDid the kernel get fixed without a bug reference at some point?21:17
infinityOr did the kernel not actually need fixing?21:17
infinityOh, I see, it got broken out into another bug and fixed.  Should twiddle those tasks, then.21:18
vanhoofinfinity: think thats been sorted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/108730221:18
ubot2Ubuntu bug 1087302 in linux (Ubuntu Quantal) "Add support for Ivy Bridge GT2 Servers" [Medium,Fix released]21:18
vanhoofinfinity: just task/bug-galore21:18
=== Ursinha is now known as Ursinha-afk
vanhoofinfinity: you're too fast I was just about to do that :)21:20
infinityI've come to the conclusion that my changelogs are too long.21:20
infinityhttps://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/613662/comments/11 <-- That's, like, half the bug log.21:20
ubot2Ubuntu bug 613662 in eglibc (Ubuntu Quantal) "nscd doesn't cache host entries" [Undecided,Fix committed]21:20
vanhoofinfinity: nice :)21:21
infinityvanhoof: 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. :P21:22
vanhoofinfinity: nothing off-hand I know of but let me look21:23
infinityKay.  I need to hunt down the people who cared deeply about the malloc deadlock and the ARM futex thing.21:23
infinityThe rest, a monkey on valium could validate.21:24
vanhoofinfinity: nothing sounds familiar, have any names handy, i can go help chase em down21:24
infinityI'll remember after I've slept, I'm sure.21:24
infinityIt's been one of those weeks already.21:24
vanhoofinfinity: :)21:24
infinity(Is it Friday yet?)21:24
stgraberinfinity: almost21:25
infinityAre you lying to make me feel better?21:25
vanhoofinfinity: in 35m it will be21:25
infinityYou don't have to do that, we're not dating.21:25
vanhoofinfinity: i like long walks on the beach, drag racing, and hockey21:26
infinityI also enjoy racing in dresses.21:26
infinityWe have so much in common.21:26
* xnox goes back to knitting scarf21:27
vanhoofxnox: orange please21:27
=== Noskcaj is now known as Noskcaj_afk
xnoxvanhoof: sure, next one will be orange.21:28
infinityvanhoof: Flyers orange or Ubuntu orange?21:29
infinityvanhoof: Answer carefully.21:29
vanhoofinfinity: ubuntu ;)21:30
vanhoofI dont like that traitor of a coach the Flyers have ;)21:30
vanhoofxnox: http://ubuntuone.com/45rb67F6TBowKJJm3Fb283 ... -ENEEDSCARF21:31
xnoxvanhoof: is that actually your dog?21:31
infinityI refuse to believe a dog can use onboard.21:31
infinityMost humans can't.21:32
vanhoofyeah she's blessing me with her presence as we speak :)21:32
xnoxme can do a small one for her ;-)21:32
infinityballoons: Hey dude.  You filed a bug a bazillion years ago and never followed up for SRU verification.21:32
infinityballoons: y u no love us?21:33
infinityballoons: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/101850421:33
ubot2Ubuntu bug 1018504 in empathy (Fedora) "Empathy doesn't display buddy list" [Undecided,New]21:33
vanhoofxnox: :D21:33
vanhoofxnox: she's 50lb so not too small :)21:33
balloonsinfinity, ooo21:33
balloonsthat got fixed21:33
balloonsI check it out21:33
balloonswhat's up with it?21:34
infinityballoons: It got fixed 125 days ago, apparently, but you never verified on precise.  Sadness.21:34
balloonswha? I thought it got verified :-(21:34
balloonsit worked for me21:34
infinityballoons: I'd love to release that SRU instead of pulling it, if you can verify.21:34
balloonsI'm not on precise anymore21:34
xnoxinfinity: /me is doing libnih verification. It's ~approx. from that timeframe.21:34
balloonsahh.. looks like it never made it to precise perhaps21:35
infinityballoons: Your only comment was about it being fixed in Q, which was less than helpful. :/21:35
infinityballoons: It's been in precise-proposed for 125 days due to lack of verification.21:35
balloonswell, I can reload precise and do a verify21:35
balloonsi thought it was released :-(21:36
infinityxnox: Someone should SRU libnih to whack that glibc private symbol usage too, to help apt's tiny brain cope better with upgrades.21:36
infinityxnox: Though, would require an apport SRU for completeness too.21:38
infinityxnox: https://bugs.launchpad.net/libnih/+bug/99735921:38
ubot2Ubuntu bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [Undecided,Confirmed]21:38
xnoxinfinity: 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:52
infinityxnox: Why check that when it should be removed? :P21:53
xnoxas in the other _nih__abort_msg symbol that got introduced to replace the glibc one is not reached, that is.21:53
ogra_infinity, fyi, while cadejo is reachable via http, it doesnt seem to do anything when triggering a build22:25
ogra_buildlive just silently hangs forever22:25
=== yofel_ is now known as yofel
infinityogra_: Oh, that probably means you have a few dozen BuildLiveCDs all sitting there waiting on locks.22:33
ogra_nothing in nusakans processlist22:34
ogra_i had started a manual build right after it came up again, but killed it now since nothing happened22:34
infinitynusakan has nothing to do with it.22:35
infinitykilling the ssh session doesn't kill the remote.22:35
infinityAnyhow, looking into it.22:35
ogra_i know22:35
ogra_i dont think there was a remote session22:35
ogra_or if there was one it was just sitting there22:35
ogra_none of the logs moved22:35
infinityYou missed the part where I said "waiting on locks", right?22:36
infinityProbably had a stale lock when it came up.22:36
ogra_i didnt, thats what i was agreeing to :)22:37
ogra_"sitting there"22:37
ogra_hmpf, so why does my upstart job not work ...22:37
ogra_i can run it manually but it never runs automatically22:37
stgraberogra_: never starts or fails once started?22:38
infinityDoes it specify when it should start?22:38
stgraberogra_: (do you have /var/log/upstart/<job>.log?)22:38
infinityDoes it double-fork itself into oblivion and upstart loses it?22:38
ogra_pretty trivial22:38
cjwatsonvanhoof: yeah, the routine for 12.04.2 is going to be that we manually check everything that *doesn't* seem to be going in22:39
ogra_oh, i didnt know about that log stuff !!!22:39
cjwatsonmaybe it objects to your pointless use of /bin/echo? :)22:40
ogra_cannot create /sys/devices/system/cpu/cpufreq/interactive/boost_factor: Directory nonexistent22:40
vanhoofcjwatson: 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 good22:40
stgraberogra_: hehe, and upstart runs with -e, so any error is critical and the script stops there22:40
ogra_i guess i need to bind that to a udev rule and wait for the governor to be initialized22:40
cjwatsonvanhoof: wouldn't hurt to have a list of things to pay attention to, but it's not vital22:40
stgraberogra_: well, we have a udev bridge you know ;)22:40
vanhoofcjwatson: noted, i'll have a pass at the queue this evening to be sure22:41
infinityogra_: Or just do it from ondemand, where the governor gets set.22:41
stgraberogra_: so you can do a "start on <device-type>-added" assuming you know what device type you're looking at22:41
ogra_infinity, ondemand is off on the nexus22:41
stgraberthough in this case, it'd be "cpu" which you should have before anything runs :)22:41
infinityogra_: Eh?22:41
cjwatsonand yeah, I'm checking pending-sru for verified stuff more than once a day; I expect I'm not the only one22:41
ogra_we use interactive like android22:41
infinityogra_: I meant the script.22:42
infinityogra_: I know we use interactive, I'm the one who patched it. :P22:42
ogra_ondemand has proven to be pretty  wasteful22:42
ogra_that one22:42
* ogra_ tries to stay away from sysvinit for new stuff usually ... i didnt even think about it22:42
ogra_though that wont help much if the governor is slow to initalize22:44
ogra_i tested the upstart job with "start on started lightdm" i desparation ... seems the dir wasnt even there by then22:45
infinityogra_: That's inentional.  Read /etc/init.d/ondemand22:45
infinityogra_: The script sleeps so the machine can tear through boot in performance, before dropping you to a friendlier scheduler.22:46
slangasekinfinity: I think he means the kernel side is slow to appear, not referring to the delay in the init script?22:46
ogra_slangasek, right, i did22:47
infinityslangasek: The delay in the init script is why the kernel side isn't there, I imagine.22:47
slangasekogra_: why not do it as a udev rule?22:47
ogra_but the sleep will help i guess22:47
infinityAs in, without enabling the governor, you can't twiddle it.22:47
ogra_slangasek, that was what i said above before infinity came up with the ondemand script22:47
slangasekinfinity: the init script only pokes at /sys, which I think is what ogra is doing too22:47
infinityslangasek: Yes, but the init script and Oli are doing two different things.22:48
infinityslangasek: And one might find that he can't do his thing without first doing what the script does.22:48
slangasekright, sure22:48
infinityogra_: cadejo might give you love now.22:49
slangasekdoes the 'interactive' governor also adversely impact startup speed?22:49
infinityNot sure by how much, but it would do so, yes.22:50
slangasekbut yeah, I see now; the init script is already where we handle 'interactive', so further tuning should probably go there as well22:50
infinityPossibly less than ondemand.22:50
slangasekno real sense in splitting the logic between an init script and an upstart job/udev rule that depends on that init script22:50
ogra_well, all that stuff should move to upstart/udev eventually22:51
slangasekyes, but that's a long "eventually" and we shouldn't leave bits of the logic scattered in multiple different places in the meantime22:52
=== Ursinha-afk is now known as Ursinha
Noskcajthe iso tracker has frozen for 12.04, kubuntu alternate23:29

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