[03:09] <infinity> pitti: adt-britney seems to be "stuck".  All the tests triggered by sphinx, for instance, have been "running" for a Very Long Time despite that being, I believe, complete BS.
[03:09] <infinity> pitti: More bugs to hunt down?
[03:39] <pitti> Good morning
[03:40] <pitti> xnox: upstart> yay, you did it! why sad?
[03:40] <pitti> ogra_: well, it was requested by dbarth and got three acks in the MP: https://code.launchpad.net/~dbarth/ubuntu-seeds/ubuntu-touch.remove-cordova-2.8/+merge/215098
[03:40] <pitti> ogra_: so it seemed ok?
[03:41] <pitti> infinity: probably more likely to be a networking issue; I'll have a quick look (although I'm not intimately familiar how this is plumbed together)
[03:42] <infinity> pitti: Well, I was relying on you to relay to jibel if he's the one at fault. ;)
[03:42] <pitti> infinity: yep :)
[03:43] <pitti> infinity: btw, that adt-britney fix for ignoring results is coming along well
[03:43] <pitti> https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 fixes the issue, just needs some cleanup
[03:43] <pitti> infinity: so this  afternoon or tomorrow morning or so we should land this
[03:43] <infinity> \o/
[03:44] <pitti> if jibel finishes this this morning (which I assume), I'll ask cjwatson to review; I guess he's closest to that part of britney?
[03:44] <infinity> pitti: Do we also have "ignore tests that have never passed" somewhere on the wishlist stack?
[03:44] <pitti> i. e. I did the first round of review, but I can't actually land it
[03:44] <pitti> infinity: nope, that branch fixes those :)
[03:45] <infinity> Erm, it does?
[03:45] <pitti> infinity: it splits the "FAIL" state into ALWAYSFAILED (and britney will accept it) and REGRESSION (it succeeded at least once)
[03:45] <infinity> Ahh, awesome.
[03:45] <pitti> and everything is testcased
[03:45] <infinity> This makes me very happy.
[03:46] <infinity> I can probably scrap a few hints when that lands.
[03:48] <infinity> pitti: This may be too much effort, so feel free to tell me to eff off, but could we also split the i386 and amd64 jobs the way armhf and ppc64el are split?  It seems like a monumental waste of resources every time I restart a failed/broken job and it rebuilds both.
[03:48] <pitti> infinity: I wouldn't bother with jenkins any more TBH
[03:48] <infinity> Though, I guess then they'd lose the "intuitive" linking between the two arches in the UI.
[03:48] <infinity> pitti: Yes, I was hoping your response was "jenkins is going away tomorrow".
[03:49] <pitti> infinity: as soon as I'm through with fixing those autopkgtest bugs, I'll continue working on https://wiki.debian.org/MartinPitt/DistributedDebCI
[03:49] <pitti> infinity: well, I'd love for "tomorrow", just not quite there yet
[03:49] <infinity> pitti: For large values of "tomorrow"? :)
[03:49] <pitti> infinity: if everyone stops sending me fires to put out for a week or so, I can make some progress there :)
[03:50] <pitti> infinity: at least I made some nice progress on the debci rearchitecture
[03:50] <pitti> infinity: and I have a working prototype of the AMQP implementation
[03:50] <pitti> infinity: the worker is literally just 130 lines of code or so
[03:50] <infinity> pitti: I don't know what that means, but I trust it translates to "things will be more awesome".
[03:50] <pitti> infinity: IOW, the entire worker/queue handling code is smaller than a single jenkins XML job config :)
[03:50] <infinity> pitti: That seems like what I'd expect a worker to be, yeah.
[03:51] <pitti> infinity: yes; replace jenkins with a set of AMQP queues (which are very robust, and no SPOF any more) and a distributed file system for the results
[03:51] <infinity> pitti: Please share this awesome with everyone else in the company that uses jenkins as a crutch and purge them all. :P
[03:51] <pitti> jenkins requires way too much maintenance, gets in the way, and becomes too much of a SPOF
[03:51] <infinity> s/company/world/
[03:52] <pitti> infinity: I can assure you the CI team is running full speed away from it :)
[03:52] <pitti> infinity: e. g. the current CI train runs entirely without jenkins AFAIUI
[03:52] <pitti> xnox: ah, my /etc/modules lost rtc! merci beaucoup :)
[03:52] <infinity> pitti for President, with a campaign promise of "Jenkins-free by the next LTS"?
[03:53] <pitti> infinity: next LTS? gosh, I hope "next release"..
[03:53] <pitti> someone break my network for a week, and when I come back it should all be running :)
[03:53] <infinity> Hah.
[03:54] <infinity> We'll send doko over with scissors.
[03:55] <pitti> I suppose my email server would already do
[03:56] <pitti> ooh, "Jenkins Fixed - utopic-adt-libgmpada"
[03:56] <pitti> does that mean the gnat/ada stack became installable now?
[03:56] <infinity> doko merged gnat, I believe.
[03:56] <infinity> So, it should be.
[03:56] <pitti> yes, a while ago, but it made a ton of pacakges uninstasllable and thus britney unhappy
[03:57] <pitti> ah, still does
[03:58] <infinity> Looks like we at least need an easy hint for gnat/gnat-4.6  No idea why britney doesn't appear to be autohinting them.
[03:58] <infinity> But things may well still be broken with that.
[03:58]  * infinity does that now.
[04:01] <pitti> infinity: well, in the recent runs it actually was uninstallable, like https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-libxmlada/6/ARCH=i386,label=adt/console
[04:02] <pitti> e. g. libxmlada4.1-dev depends on gnat-4.6, while this tries to upgrade to gnat-4.9
[04:02] <infinity> Ahh.
[04:02] <pitti> so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems quite right to me
[04:02] <infinity> pitti: I wasn't implying output was wrong, just weird that it didn't autohint the two (which would still break other things)
[04:03] <pitti> in the source I see
[04:03] <pitti> Depends: ${misc:Depends}, ${ada:Depends}
[04:03] <infinity> So, I assume anything with that dep needs a rebuild.
[04:03] <infinity> Can transition in the morning if no one beats me to it.
[04:03] <pitti> however, it build-depends on gnat, gnat-4.6 (why??)
[04:03] <pitti> i. e. it'll need sourceful changes
[04:03] <infinity> Sure, not rocket surgery.
[04:03] <pitti> infinity: no, mostly checking if it still builds with 4.9 I suppose
[04:04] <pitti> at least it's in debian as well, so these can be forwarded
[04:04] <infinity> That particular one has an upload in Debian NEW that should fix it.
[04:04] <infinity> Maybe we should just leave this alone while Debian does the transition.
[04:05] <pitti> ooh, and there it is: https://ftp-master.debian.org/new/libxmlada_4.4.0puregpl-1.html
[04:05] <pitti> right
[04:05]  * infinity puts that transition back on ignore for a bit.
[04:08] <infinity> I think I might try for an early night, so I have more time for hotel bacon in the morning.
[04:09] <StevenK> infinity: Going to bed at 3am, rather than 4, you mean?
[04:10] <infinity> StevenK: Shockingly, 11pm.  Though likely more like midnight when I finally sort out how to shut off my brain enough.
[04:10] <infinity> (ie: when the drugs kick in)
[04:10] <infinity> Toodles.
[04:11] <s1aden> er, morning
[05:56] <pitti> hallyn: I have a followup question on bug 1317179
[06:42] <dholbach> good morning
[07:04] <zyga> good morning everyone
[07:33] <Wellark> hi!
[07:33] <Wellark> is there a way to upgrade from trusty to utopic yet?
[07:33] <Wellark> do-relese-upgrade -d says there are no new releases available
[07:34] <Wellark> I could manually edit my sources.list, but that would throw away all the fail-safes do-release-upgrade provides
[07:36] <RAOF> Wellark: do-release-upgrade provides no fail-safes at this stage ):
[07:36] <RAOF> :)
[07:36] <Wellark> well, it is able to roll back on some errors at least
[07:36] <Wellark> actually I was thinking of running it with -s
[07:38] <RAOF> Well, at the moment you won't get anything particularly different in utopic; it's fairly safe.
[07:38] <RAOF> Although you will lose DNS resolving.
[07:38] <RAOF> That might be an issue for you :)
[07:39] <Wellark> I'm doing networking for touch.. maybe I could manage ;)
[07:39] <Wellark> hmm.. seems we have a daily-live for utopic at least..
[07:40] <mvo> Wellark: if you change your /etc/update-manager/release-upgrades from "prompt=lts" to prompt=normal do-releae-upgrade -d will work
[07:43] <Wellark> mvo: I though -d explicitly overrides the config
[07:43] <Wellark> will try that then
[07:44] <Wellark> mvo: thanks! now it works
[07:45] <mvo> Wellark: it does, but there are two channels (for lack of a better term) for upgrades, lts->lts and lts->normal and right now the upgrade is only available in the normal channel - I guess I should actually fix that and make it available in the lts->lts one as well
[07:45]  * mvo makes a note
[07:58] <xnox> pitti: well... we spawn user session init for some basic tests, and that was going on ahead and launching jobs from /usr/share/upstart/session... that's not good.
[08:00] <pitti> xnox: ah, and that broke the upstart test?
[08:03] <xnox> pitti: yeah, the test was racing the dbus user session job. thus retries on buildds, but an always loose ADT VM.
[08:14] <zyga> hey, using gnome-shell (and gnome-control-center) display settings (particularly monitor arrangement) is lost after logging out and back again
[08:14] <zyga> that works well with unity
[08:14] <zyga> could be a missing upstart session job or something like that?
[08:15] <zyga> note: changes are applied but they are not restored after logging in again
[08:45] <darkxst> what should I do when a package wants to install something in "usr/lib/python3.4/site-packages/gi/overrides"
[08:46] <darkxst> ^that shouldn't be hard-coded in an install file right?
[08:49] <pitti> darkxst: doesn't dh_python3 take care of moving it into the right place? (or am I mixing this up with what dh_python2 used to do?)
[08:50] <pitti> they need to go into /usr/lib/python3/dist-packages/gi/overrides
[08:52] <pitti> infinity: oh wait, could that just be because britney didn't actually run (or finish) for several hours? excuses is from 04:13
[08:53] <pitti> but I have a feeling that the publisher isn't running, so maybe britney just doesn't get triggered (it's not running at least)
[08:54] <pitti> my change-override command hasn't gotten into effect for over an hour already
[08:56] <Laney> pitti: the topic says it's stopped, so that sounds correct
[08:57] <darkxst> pitti, nope dh_python3 doesnt move them
[08:59] <pitti> Laney: ah indeed, missed the topic change
[09:08] <cjwatson> pitti: Yeah, right now is probably not a good time to do proposed-migration maintenance since we won't see the results for some time :-)
[09:08] <pitti> ack
[09:12] <pitti> wgrant: thanks!
[09:21] <mardy> pitti: hi! These autopkg tests fail apparently because some X11 dependency is missing: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/4/ARCH=amd64,label=adt/console
[09:21] <mardy> pitti: am I missing something in debian/control?
[09:22] <pitti> mardy: python-xlib apparently?
[09:22] <pitti> oh wait, why doesn't autopilot-desktop depend on that
[09:22] <pitti> it does
[09:22] <pitti> mardy: ah, seems your test doesn't actually depend on autopilot-desktop :)
[09:23] <pitti> mardy: you should use that instead of just python-autopilot to get the missing deps
[09:29] <mardy> pitti: thanks a lot, I'll try that
[09:30] <mardy> Mirv: should I add a commit to u-s-s-o-a to fix the above ^, or make a separate MP, or what?
[09:38] <sil2100> pitti: hello!
[09:38] <pitti> hello sil2100
[09:40] <sil2100> pitti: I heard you're the best person to ask when there are mysterious autopkgtest failures going on - ubuntu-download-manager seems blocked in -proposed due to an autopkgtest failure, but it looks bogus, seems like more of some infra issue: i.e. https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-system-image/4/ARCH=amd64,label=adt/
[09:40] <sil2100> pitti: do you know by any chance what's wrong and how to fix this? ;)
[09:42] <pitti> sil2100: ah, it's creating the log file in the $ADT_ARTIFACTS/ directory apparently; I'm afraid 9p is really limited and you can't chown there
[09:43] <pitti> sil2100: so if it's ok, I'd propose to create the log file in $ADTTMP instead, and after calling the test copying it to $ADT_ARTIFACTS
[09:43] <pitti> sil2100: the alternative would be that autopkgtest would have to create the artifact dir in a VM-local dir and then always copy the thing to the shared 9p dir which introduces quite some penalty for large files
[09:44] <pitti> sil2100: so in short, "qemu 9p sucks", but it's still the best of all horribly broken ways to communicate with a VM :/
[09:46] <pitti> sil2100: i. e. change debian/tests/prep.py to set artifacts = os.environ['ADTTMP'], and add somethig like "cp $ADTTMP/client.log $ADT_ARTIFACTS/" to debian/tests/smoketest
[09:52] <sil2100> pitti: thanks! Will do that :)
[09:53] <pitti> and half of the kingdom for whoever comes up with a sane and efficient way to exchange files with a VM (which doesn't assume that the entire network stack and ssh are up, and that you have the credentials etc)
[10:07] <ogra_> pitti, thanks for the answer yesterday ... i left a question on the bug already for the cordova stuff
[10:08] <ogra_> (well, s/yesterday/this morning at an unholy time/)
[10:10] <Mirv> mardy: you need a new landing probably
[10:10] <pitti> ogra_: ack; I can also stop doing these seed changes during sponsoring, but it seems nobody else did it or updated that MP for months..
[10:10] <Mirv> so, MP
[10:10] <pitti> ogra_: and it looked ack'ed enough; so, sorry if that messed up something
[10:10] <ogra_> pitti, well, it is probably valid (especially since it comes from dbarth)
[10:11] <ogra_> as long as cordova 3.0 is fully backwards compatible we shoulld be fine ... it is just that framework changes should better be checked twice since we promise a 100% reliable framework for the ones we already released
[10:44] <xnox> cjwatson: re:nvme looks good, thanks a lot.
[10:45] <xnox> ogra_: framework version should be bumped, and old one still provided if new one is still compatible.
[10:45] <xnox> ogra_: such that those that use 3.0 features, not present in 2.8, can set appropriate framework name.
[10:46] <cjwatson> xnox: cool, I basically copied my earlier fusionio patch
[10:46] <ogra_> xnox, right ... that change dropped something the old framework relied on
[10:46] <ogra_> but we still support that framework
[10:46] <cjwatson> xnox: it's building now, according to my laptop fans
[10:46] <xnox> cjwatson: =)))))) excellent indicator.
[10:47] <ogra_> xnox, thats why i was asking about it :) as long as 3.x is fully backwards compatible dropping is fine, i just dont know if anyone checked
[10:48] <cjwatson> Also it vents heat at least in part through the bit where I rest my wrists - I think I shall go and have a belated breakfast rather than cooking my hands
[10:48] <ogra_> winter laptop :)
[10:50] <xnox> =))))) "winter laptop" that's funny. I really need a spring/summer 2014 collection laptop asap!
[11:55] <basd82> What is the goog chanel to ask somting about the archive.ubuntu.com and security.ubuntu.com
[12:03] <cjwatson> basd82: Not sure, would depend what the question was
[12:04] <basd82> is the content security.ubuntu.com also on archive.ubuntu.com
[12:05] <basd82> I made local mirror for our release party, and redirect nl.archive to local miror i prever to do the same with security du to low speed internet connection
[12:05] <cjwatson> Yes.  security.ubuntu.com exists separately so that we can deliver security updates without having to wait for mirroring.
[12:06] <basd82> Great so for the install party i can also redirect security to this local mirror
[12:06] <cjwatson> For a local mirror you can just mirror archive.ubuntu.com; it will typically be ahead of security.ubuntu.com in sources.list and so apt will fetch packages from your mirror
[12:06] <cjwatson> Even if you don't redirect security.ubuntu.com
[12:06] <cjwatson> But for a short-term thing redirecting both should be fine.
[12:53] <Saviq> jodh, hey, any ETA on releasing upstart with the fix for bug #1222705 ?
[13:07] <cousteau> launchpad bug 932177 - could this be workarounded for 12.04 and other affected versions?  (see my comment at the end)
[13:09] <cousteau> the workaround is basically deleting the OnlyShowIn= line in the four gnome-keyring/daemon/gnome-keyring-*.desktop.in.in files
[13:09] <cousteau> ubuntu 14.04 seems to have this application fixed so the annoying warning message isn't displayed, but other versions such as 12.04 are still affected
[13:13] <xnox> Saviq: jodh: upstream release is not happening for a while, but we can cherry-pick that into ubuntu upload.
[13:14] <Saviq> xnox, would be nice, we've been bit by it a few times
[13:15] <xnox> Saviq: ack.
[13:15]  * ogra_ looks around for a filesystem guru 
[13:15] <ogra_> xnox, !
[13:15] <ogra_> xnox, are you subscribed to the ubuntu phone ML ?
[13:15] <ogra_> i'm wondering about some weird behavior of resize2fs
[13:17] <ogra_> xnox, so to my knowledge resize2fs will never ever touch the underlying partition (or in the case we talk about the .img file) ... yet people seems to be able to just use resize2fs with our system.img file on the phone without dd'ing any additional space to it and the img gets resized
[13:18] <ogra_> *seem
[13:19]  * ogra_ wonders if resize2fs grew some secret new behavior, though the manpage still says it wont touch partitions
[13:20] <xnox> Saviq: hm.... ?! that fix was released in upstream 1.12, and thus is in trusty and utopic.
[13:20] <xnox> Saviq: are you sure it's the same bug? what package version did you see that bug with?
[13:21] <Saviq> xnox, hmm interesting, I assumed that's that whenever I saw an init crash, will come back when I have more info
[13:22] <xnox> Saviq: hm, the last line of the crash is from within libnih about to dereference a null pointer....
[13:22] <xnox> Saviq: so it could be any other bug.
[14:00] <pitti> cjwatson: it seems the publisher is running again; could we restart britney?
[14:01] <pitti> hm, or maybe not
[14:01] <pitti> LP thinks it ran (https://launchpad.net/ubuntu/+source/clustalw/+publishinghistory actually got published to universe), but rmadison disagrees
[14:01] <infinity> pitti: britney will run itself.
[14:01] <cjwatson> right, just leave it, it'll sort itself otu
[14:01] <infinity> pitti: But the publisher is mid-run right now.
[14:01] <cjwatson> *out
[14:02] <cjwatson> it didn't run last time because the LP infrastructure doesn't cope well with extremely long publisher runs and the postgres connection timed out, so it never updated dists
[14:02] <pitti> infinity: ah, thanks; wow, must be a hell of a run, for 5 hours already :)
[14:02] <cjwatson> a number of a-f caches were absent
[14:02] <infinity> pitti: We're doing Very Bad Things.
[14:02] <pitti> thanks for the heads-up!
[14:09] <mahmoh> mlankhorst: ping
[14:10] <mlankhorst> pong
[14:42] <mterry> pitti, poke about ofono test scripts.  dialer-app-autopilot seems to make the same calls the scripts do, but dialer-app-autopilot works and the scripts don't.  Do you know if there have been changed environment requirements?
[14:44] <pitti> mterry: ah, I was going to reply to your question, but you weren't online; what was your problem with 199?
[14:44] <pitti> mterry: if you dial that you'll get an ofono exception (that's normal with the simulator); perhaps that was what you were wondering about?
[14:44] <mterry> pitti, naw, I'm used to the exception
[14:44] <mterry> pitti, just nothing happens on the phone
[14:45] <mterry> pitti, is it easy for you to try and sanity check my results?
[14:45] <pitti> mterry: no, the scripts ought to work as well; d-a-ap just changed to doing the d-bus call manually to better handle that exception
[14:45] <mterry> pitti, yeah I looked at its code, it seems to be doing the same thing indeed
[14:45] <mterry> pitti, when I run the dialer-app suite, it works and I see the call (but no ring)
[14:45] <pitti> mterry: what does the script do? after doing a call, do you see it in list-calls?
[14:45] <mterry> pitti, when I run the script, it doesn't do anything
[14:46] <pitti> so that's a recent regression then
[14:46] <pitti> (in the middle of debug session with lots of brain state, so I'd prefer to try later rather than now)
[14:46] <mterry> pitti, I get something from list-calls yeah
[14:46] <mterry> and now it's gone
[14:46] <mterry> so I think the call is happening
[14:47] <mterry> pitti, OK, no worries.  I'll try to track it down.  But when you have an empty brain again, hit me up
[15:05] <zyga__> looking at https://launchpad.net/ubuntu/utopic/+queue?queue_state=3&queue_text=sphinx -- when will sphinx move from proposed to main?
[15:07] <cjwatson> category error: proposed is a pocket, main is a component
[15:07] <zyga__> sorry, that's is correct,
[15:07] <zyga__> so what is the name of the usual pocket?
[15:07] <cjwatson> release
[15:07] <zyga> ah, right
[15:07] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sphinx lists a number of autopkgtest failures
[15:07] <cjwatson> That may not be current as the publisher has been down for much of today
[15:08] <pitti> https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 will help with those and ignore tests which never succeeded (i. e. broken test)
[15:08] <zyga> cjwatson: thanks, I'll keep that link around
[15:08] <cjwatson> Right, those are all never-passed things
[15:08] <pitti> I hope we can land that on Monday (or even tomorrow, although Fridays seem suboptimal for rolling out britney changes)
[15:09] <cjwatson> I'm fine with landing it tomorrow morning; I'll be available if not necessary around at the weekend
[15:09] <pitti> (WIP is right, jibel was working on some improvements after my initial review, but should be done tomorrow)
[15:09] <pitti> apparently today is a French national holiday
[15:14] <zyga> cjwatson: is there a way to force update on sphinx?
[15:14] <zyga> cjwatson: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/sphinx/utopic-proposed/revision/49
[15:15] <zyga> cjwatson: that's the effective delta that is currently blocked by the CI machinery
[15:15] <cjwatson> It is possible, but I worry about leaving us without test cases for the (much more important) update to the machinery
[15:16] <cjwatson> And any new builds in utopic happen against -proposed, so it shouldn't be urgent to push that through
[15:16] <cjwatson> (You should be able to configure your PPA to build against -proposed temporarily, too)
[15:16] <zyga> cjwatson: oh, is there a way to do that in a ppa as well?
[15:16] <zyga> ah
[15:16] <zyga> thanks, that's all I need
[15:16] <cjwatson> "Edit PPA dependencies"
[15:16] <zyga> right
[15:16] <cjwatson> and select Proposed in the top radio group
[15:17] <cjwatson> Increases the risk of transient failures in general, so it's right that it's off by default
[15:17] <zyga> thanks, that should solve it for this single case
[15:53] <Henne91> Hey everybody! I have a question concerning Unity/Debugging. Does anybody have an idea what is the best way to run unity-settings-daemon in debug mode right after boot?
[15:53] <Henne91> The problem is, I am trying to debug an annoying bug but if I run "unity-settings-daemon --replace --debug" this will prevent the bug so I need to start it in debug mode right away.
[15:56] <tarpman> Henne91: move/rename it and replace with a shell script wrapper? exec /usr/bin/unity-settings-daemon.real --debug "$@"
[16:09] <Henne91> tarpman: sounds good, thanks ;-)
[16:36] <stgraber> bdrung: hey, so with that last change you did to ifupdown we can actually start using exec ifup/ifdown again and so probably should. I rejected the upload for now, would be nice if you could re-upload with exec
[16:57] <infinity> dh_install --fix-missing
[16:57] <infinity> Unknown option: fix-missing
[16:57] <infinity> zul: ^-- Did you mean list-missing?
[16:58] <infinity> zul: Or fail-missing?
[16:58] <infinity> zul: (Seen in the keystone build log, but could be in others)
[16:59] <zul> fail-missing
[17:00] <zul> ill fix it our bzr branch
[17:25] <bdrung> stgraber: thanks for pointing it out. i will re-upload the package.
[17:34] <prepangolin> any guys?
[18:12] <bdrung> stgraber: can you reject the old precise and saucy ifupdown uploads?
[18:15] <infinity> bdmurray: What triggers the phased update things?
[18:15] <infinity> bdmurray: Cause you're running into the LP double-override bug and deleting binaries.
[18:16] <stgraber> bdrung: sure
[18:17] <bdmurray> infinity: its just a cronjob run every 6? hours
[18:19] <infinity> bdmurray: Ugh.  Kay, so while we had the publisher offline for ~12h, every arch:all package you overrode twice disappeared from the archive.
[18:19] <stgraber> bdrung: done
[18:19] <infinity> bdmurray: That needs to be triggered to only run once per publisher.
[18:19] <stgraber> smb: drbd8 accepted
[18:19] <bdrung> stgraber: thanks
[18:20] <infinity> bdmurray: I also have no idea how many binaries this affects.  I only noticed it by chance because someone mentioned python-seamicroclient in passing and I did an rmadison on it.
[18:20] <infinity>  python-seamicroclient | 0.2.0-0ubuntu1 | trusty         | source, all
[18:20] <infinity>  python-seamicroclient | 0.2.1-0ubuntu1 | trusty-updates | source
[18:20] <infinity>  python-seamicroclient | 0.2.1-0ubuntu1 | utopic         | source, all
[18:21] <infinity> bdmurray: Do you have logs or any way of knowing which packages you acted on in the last day, so we can hunt for fallout?
[18:21] <bdmurray> infinity: this should help http://people.canonical.com/~ubuntu-archive/phased-updates.html
[18:22] <infinity> So, anything in that list is suspect, I suppose.
[18:22] <infinity> bdmurray: But I guess that doesn't list things that reached 100% in the last day?
[18:22] <bdmurray> infinity: no, I can find that too
[18:23] <infinity> bdmurray: That would be helpful.
[18:23] <bdmurray> infinity: the last day being the last 24 hours or 05-08?
[18:24] <infinity> bdmurray: The last 24h should do.
[18:30] <cjwatson> bdmurray,infinity: It should be possible for the client to check for pending overrides.
[18:30] <cjwatson> (Still racy in theory, but much less so in practice.)
[18:30] <infinity> cjwatson: Triggering it from publisher-parts would probably be saner.
[18:31] <infinity> cjwatson: trigger + timeout semaphore if you don't want it as frequent as the publisher itself.
[18:31] <cjwatson> It's currently every six hours.  I don't think we want to crank it up quite that much.
[18:32] <cjwatson> But I still think it should check for Pending publications, just in case somebody feels the need to run it manually.
[18:32] <infinity> cjwatson: Every 6 hours with a semaphore would work fine, though.
[18:32] <infinity> cjwatson: As in, I trigger you, you check if it's been >>6h since the last run, exit if not, run if so.
[18:33] <infinity> (ie: the same thing we do for external mirror triggers)
[18:33] <infinity> Anyhow, cleaning up the mess now.
[18:33] <infinity> Enjoy the -changes spam.
[18:33] <bdmurray> How do you check for publisher runs?
[18:34] <infinity> bdmurray: We have hackish ways we do it now, but the better way is for the publisher to trigger you.
[18:34] <infinity> Which I'm going to do for the archive reports.
[18:34] <infinity> And could well do for this as well.
[18:34] <infinity> Though, I suppose there's still a minor race with a real human double-overriding.
[18:34] <infinity> We really need to fix that bug.
[18:36] <bdmurray> infinity: so I have a list of packages that became fully phased, how I can check them for you?
[18:36] <infinity> bdmurray: rmadison
[18:37] <infinity> bdmurray: If there are arch:all binaries missing, life sucks.
[18:37] <infinity> bdmurray: Or just give me the list, since I'm already doing it for the others.
[18:40] <infinity> bdmurray: Alright, I'm done with the webpage you gave me.  How many more do you have?
[18:41] <bdmurray> infinity: http://pastebin.ubuntu.com/7417678/
[18:41] <cjwatson> Don't we want all phase changes, not just those to 100%?
[18:42] <cjwatson> They all amount to override changes
[18:42] <bdmurray> cjwatson: that was in the html report
[18:42] <cjwatson> Oh right
[18:42] <infinity> cjwatson: The pre-100% ones were at http://people.canonical.com/~ubuntu-archive/phased-updates.html
[18:42] <cjwatson> Got it
[18:42] <infinity> cjwatson: And -changes spam shows I checked those. ;)
[18:42] <infinity> bdmurray: That would be much less painful by source package...
[18:43]  * infinity sorts that out himself.
[18:43] <infinity> Well, by source, and knowing which series...
[18:44] <bdmurray> its all trusty
[18:44] <infinity> Looks like gettext, clamav, marble, and kubuntu-meta, maybe.
[18:47] <infinity> And kde-dev-scripts
[18:47] <infinity> Alright, those are all copied.
[19:25] <smb> stgraber, Your kernel is ready to be picked up
[19:33] <barry> @pilot in
[20:17] <saiarcot895> Just to check, are we allowed to ask here if anyone is willing to sponsor an SRU?
[20:32] <ari-tczew> saiarcot895: yes, you're allowed. the best is subscribe to ubuntu-sponsors @bug. is your patch already ACK'ed by SRU team?
[20:33] <saiarcot895> ari-tczew: no, I thought ubuntu-sponsors had to approve it first.
[20:35] <saiarcot895> For the record, the SRU/patch to review is https://bugs.launchpad.net/ubuntu/+source/checkstyle/+bug/1308794
[20:46] <ari-tczew> saiarcot895: https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#Procedure
[20:48] <ari-tczew> step #6 says: "The ~ubuntu-sru team will review and approve then the archive admins will accept your upload."
[20:49] <saiarcot895> ari-tczew: But step 5 says "Upload the fixed package to release-proposed with the patch in the bug report", and, if you can't upload, to get a sponsor
[21:28] <robert_ancell> bdmurray, hey, so I'm getting emails from you (automated?) about the the nautilus SRU (bug 1286766) not rolling out further because errors.ubuntu.com is picking up new stack traces. I'm not sure that the traces are due to the patch, how do we continue from here?
[21:31] <bdmurray> robert_ancell: those are from the phased-updater and are automated. if an individual crash isn't new we can override the phased updater check for that spefici crash.
[21:31] <robert_ancell> bdmurray, sorry, be back in 10mins
[21:41] <robert_ancell> bdmurray, sorry about that. The stack traces are new but I think they might be from the same underlying cause
[21:42] <robert_ancell> so that is tricky as there might be a new stack trace every few days :/
[21:43] <robert_ancell> bdmurray, is there a way of finding out if the rate of errors has increased in the users who have the SRU?
[21:43] <bdmurray> robert_ancell: there is a check to see if the rate of errors for all users has increased
[21:44] <bdmurray> robert_ancell: comparing rate of crashes for the previous package version to the new package version
[21:44] <robert_ancell> bdmurray, but we don't know the number of users for the previous / new so we can't do a comparison right?
[21:45] <robert_ancell> or is the upgraded users just a fixed percentage so we can assume?
[21:46] <bdmurray> robert_ancell: if this is a critical issue as the bug seems to indicate we can manually set the phased-update percentage to 100%
[21:49] <robert_ancell> bdmurray, can we get those crash rate numbers for 1:3.10.1-0ubuntu8 and 1:3.10.1-0ubuntu9 and check they have the expected ratio?
[21:51] <Gladiak> hi everyone
[21:51] <Gladiak> i've a little question related to mono and shell command
[21:51] <Gladiak> could you help me ?
[21:53] <bdmurray> robert_ancell: I've an errand to run but will look into the rate when I return
[21:53] <robert_ancell> bdmurray, ok, thanks
[21:54] <dobey> Gladiak: this channel is about development of ubuntu itself (mostly about the foundation), not really about development of arbitrary apps on ubuntu.
[21:54] <Gladiak> ah ok sorry
[21:54] <dobey> Gladiak: also, just ask your question on irc. don't ask to ask. if anyone has an answer, they'll reply with it
[21:54] <Gladiak> first time for me on irc :/
[21:55] <Gladiak> ok sorry again :°)
[21:56] <Gladiak> i've a problem running this command in a gtk# mono app: sudo dpkg --set-selections < /home/$USER/pack_list
[21:56] <Gladiak> i'm trying to build a "backup" program to restore a system after a format
[21:56] <Gladiak> but i can't find a method to run sudo command in a terminal using mono
[21:57] <dobey> you shouldn't run sudo from an app
[21:58] <dobey> you should use the PolicyKit API to run commands that require elevated privileges
[21:58] <Gladiak> mmm i see
[21:59] <Gladiak> i'll try that, maybe it could works
[21:59] <Gladiak> p.s: sorry for my english :/ i don't speak (and write) english so often
[22:49] <barry> @pilot out
[23:13] <robert_ancell> bdmurray, I get http://paste.ubuntu.com/7418700/ as a result of that link - is that correct?
[23:13] <bdmurray> robert_ancell: yes, it is
[23:14] <robert_ancell> bdmurray, ok, and to confirm this is showing that there's different crashes but not an increase in the rate of crashes?
[23:14] <bdmurray> robert_ancell: so the crash rate doesn't take into account the number of users and needs to be fixed
[23:16] <bdmurray> robert_ancell: mostly yeah
[23:16] <bdmurray> robert_ancell: here is the raw data - http://pastebin.ubuntu.com/7418714/
[23:17] <robert_ancell> bdmurray, ok, then I'm confident this SRU is not causing the new crash reports. Let's set the phased release to 100%
[23:18] <robert_ancell> so that says there's 10% of the crashes in the new version and I'm assuming it's rolled out to 10% of the users?
[23:19] <bdmurray> robert_ancell: only update-manager respects the phased-update percentage so if people install view apt-get install or synaptic or some other packager it could be higher
[23:19] <robert_ancell> right
[23:20] <bdmurray> and I mean via and package manager of course
[23:20] <robert_ancell> But 10% seems in the right ballpark. I wouldn't want to see the same number of crashers in the new group and the old group
[23:24] <bdmurray> okay and so you think fully phasing it is a good idea?
[23:48] <robert_ancell> bdmurray, yes
[23:52] <TheMuso> @pilot in
[23:59] <bdmurray> slangasek: can you take care of setting nautilus in trusty to a phased-update-percentage of 100?