=== fginther|away is now known as fginther
[04:12] <Mirv> the qml naming scheme presented by lisandro is sane, he discussed it on IRC before putting to mailing list
=== fabo_ is now known as fabo
[07:07] <zequence> Another last minute fix, bug 1304214
[07:08] <ubot2> Launchpad bug 1304214 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe] New default wp for ubuntustudio-lightdm-theme" [Undecided,New] https://launchpad.net/bugs/1304214
[08:59] <seb128> hey there
[08:59] <seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-control-center
[08:59] <seb128> can somebody make sense of that?
[08:59] <seb128> "unity-control-center/arm64 unsatisfiable Depends: indicator-datetime "
[08:59] <seb128> "Not considered "
[08:59] <seb128> but that situation is not new...
[09:00] <cjwatson> Somebody removed indicator-datetime from arm64?  Why just that arch I wonder?
[09:00] <seb128> it fails to build there
[09:00] <seb128> but that's not new
[09:00] <cjwatson> Oh, me apparently
[09:00] <cjwatson> Well it is somewhat new, saucy had indicator-datetime/arm64
[09:00] <infinity> Why would it be FTBFS on only arm64?
[09:00] <seb128> right, but saucy was not using url-dispatcher
[09:01] <cjwatson> We could probably get that back with a no-change of indicator-datetime though
[09:01] <seb128> infinity, it bubble up to some touch component not being available there
[09:01] <seb128> iir
[09:01] <seb128> iirc
[09:01] <cjwatson> Since the reason it was removed no longer applies
[09:01] <cjwatson> Wonder if I can copy it back
[09:01] <seb128> oh, no
[09:01] <infinity> seb128: No, it's FTBFS in the testsuite, not a missing build-dep.
[09:01] <seb128> build failed on test issue
[09:01] <cjwatson> Oh, yeah, OK
[09:01] <seb128> infinity, sorry, my memory is probably from < qt5.2 times
[09:02] <seb128> should I retry the build?
[09:02] <seb128> in case it's a flacky test
[09:02] <infinity> Can't hurt, but probably won't help either.
[09:02] <infinity> Racey tests don't usually segfault.
[09:02] <cjwatson> seb128: And it *is* new - unity-control-center in -proposed Depends: indicator-datetime, the one in release doesn't.
[09:03] <seb128> cjwatson, oh indeed, sorry
[09:03] <seb128> I confused that version with the one in unapproved
[09:04]  * Laney tries a test build
[09:04] <seb128> cjwatson, infinity: thanks for the help, I guess the easiest way out is to get indicator-datetime to build on arm64
[09:04] <infinity> seb128: Certainly the preferred way out anyway.
[09:11] <cjwatson> Yeah, unity-control-center has enough rdeps that I'd rather not remove its binary.  The next (icky) fallback would probably be to make that dep arch-specific
[09:12] <infinity> Or disable the testsuite on arm64 with a massive XXX FIXME OH GOD LOLZ comment.
[09:12] <infinity> But I'd definitely prefer someone investigating the crash a bit first.
[09:13] <infinity> At least get some backtraces of the segv, it might be something one of us has seen before in other contexts.
[09:17] <seb128> infinity, right, I'm going to talk to charles about it later
[09:17] <Laney> dpkg-deb: building package `indicator-network' in `../indicator-network_0.5.1+14.04.20140318-0ubuntu1_arm64.deb'.
[09:19] <infinity> Laney: If only that was indicator-datetime.
[09:19] <Laney> haha
[09:19] <Laney> I was shitting myself a bit
[09:19] <Laney> I blame... something that's not me not paying attention
[09:24] <Laney> I'd even done apt-get build-dep on the right package /o\
[09:48] <dholbach> could somebody take another look at https://bugs.launchpad.net/ubuntu/+bug/1302619 https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620?
[09:48] <ubot2> Launchpad bug 1302619 in Ubuntu "[FFe] New package qtcreator-plugin-remotelinux " [Undecided,New]
[09:48] <ubot2> Launchpad bug 1302620 in qtcreator (Ubuntu) "[FFe] Remove remotelinux plugin and its dependencies from the QtC package" [Undecided,Incomplete]
[09:49] <dholbach> and bug 1303706 too please :)
[09:49] <ubot2> Launchpad bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New] https://launchpad.net/bugs/1303706
[10:10] <brendand> hey, i have a couple of FFEs that i'm sheperding:
[10:10] <brendand> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1302615
[10:10] <ubot2> Launchpad bug 1302615 in checkbox (Ubuntu) "[FFe] [UIFe] Checkbox GUI needs to be able to send test results to Launchpad" [Undecided,New]
[10:10] <brendand> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1303849
[10:10] <ubot2> Launchpad bug 1303849 in checkbox (Ubuntu) "[FFe] The Checkbox UI needs a way to be customised" [Undecided,New]
[10:10] <brendand> is there a big backlog of FFEs?
[10:21] <dholbach> brendand, https://bugs.launchpad.net/~ubuntu-release/ as 150 bugs - not sure if that's the best indication though
[10:23] <brendand> dholbach, can we em, 'encourage' someone to look at them?
[10:25] <dholbach> brendand, I could imagine that a lot of people on the release team are very busy people :/
[10:26] <infinity> We could encourage people to stop filing FFes seven months after feature freeze and a week and a half before release.
[10:27] <dholbach> infinity, weeks?
[10:27] <brendand> infinity, i know, it's quite late in the day, but we had to do a lot of groundwork to make this feature possible
[10:27] <apw> "if we did this by the book hours would seem like days"
[10:28] <infinity> dholbach: No, months, the hyperbole was intentional. :P
[10:28] <dholbach> ok :)
[10:29] <Laney> brendand: The idea is that if a feature's not ready then it gets in next time
[10:29] <maclin> infinity, the re-building  of ubuntu kylin does not take effect again. Could you help to check it ?
[10:30] <infinity> maclin: Looks like it's in progress right now.
[10:31] <brendand> Laney, well yeah, but this is the LTS release. The feature in question is the ability for the system testing application (checkbox) to submit data to Launchpad's hardware db
=== Adri2000 is now known as Guest44106
[10:31] <brendand> Laney, so if it doesn't make it in, we won't have any of that data for the LTS release
[10:32] <brendand> Laney, unless we could get it through the SRU process
[10:32] <infinity> SRUing features is worse.
[10:32] <infinity> brendand: I understand why everyone wants all their features polished and good to go for LTSes.  I just wish they'd realize they have almost two years to make that happen, and not leave it to the last two weeks to land them.
[10:32] <maclin> infinity, thanks! Is there a way for us to see wether the rebuilding is  right or not?
[10:33] <infinity> maclin: Nope.
[10:33] <maclin> thanks, I get it:)
[10:35] <brendand> infinity, i think that's oversimplifying it a bit. but i can totally understand that it's frustrating as a release team member to see everything build up in the last few weeks/days
[10:41] <infinity> brendand: It's not oversimplifying at all.  We have a very well-known and rigid release schedule.  Yes, some things won't occur to you as being a killer feature until it's too late.  And some of those, we'll let in, but the expectation that we'll let all, or even most, of them in is just wrong.
[10:41] <infinity> brendand: So, we'll look at this.  And we may deem it low risk and useful enough to be necessary, but asking people to develop to a schedule and accept that "late" might mean "next release" is just part of the time-based release bag.
[10:42] <seb128> infinity, imho there would be some value at accepting feature backports to LTS series through SRUs, for things that have been well tested/validated in newer series
[10:43] <infinity> brendand: There are no unique snowflakes here.  If everyone kept uploading new features into the last week or two of release, we'd never be able to stabilise.
[10:43] <infinity> seb128: Sometimes.  And we occasionally do.  But that's a slipperly slope of breaking the promise of what a "stable" release means, too.
[10:44] <infinity> seb128: Stable UI, stable ABIs, stable APIs.  New features usually break one or all of those.
[10:44] <seb128> infinity, right
[10:44] <brendand> infinity, if it gets looked at, we'll be happy. i'm blowing my own trumpet here, but it is very low risk, overall. the absolute worst that could happen is checkbox not working at all, but without it sending results to launchpad, it has little overall value anyway
[10:45] <infinity> (FWIW, I just self-rejected an FFe of my own after some investigation and deciding I was too late to effectively test the change, so I'm practicing what I preach)
[10:46] <infinity> brendand: Point taken on the general uselessness of the package without this feature working, then.  One could probably call that a bugfix. :P
[10:47] <brendand> infinity, then we don't need an FFe! \o/
[10:47] <seb128> could somebody review/accept unity-control-center from the queue?
[10:47] <seb128> it's a one commit to mark string translatable
[10:48] <Laney> Are all of these https://launchpad.net/ubuntu/+source/checkbox versions of checkbox useless then?
[10:48] <seb128> getting it through would let me get a silo back to land the indicator-datetime buildfix
[10:48] <Laney> seb128: looking
[10:48] <seb128> Laney, thanks
[10:49] <brendand> Laney, all of them? no - the ones before trusty had this feature
[10:49] <brendand> Laney, currently in trusty it doesn't
[10:49] <brendand> Laney, the thing is we rebuilt checkbox
[10:49] <brendand> Laney, rewrote it really
[10:50] <infinity> brendand: Can you attach some debdiffs to these FFes?
[10:50] <Laney> seb128: is this kind of translation normal?
[10:51] <brendand> infinity, debdiffs? sure. the lp:ubuntu/checkbox MR is there though
[10:51] <seb128> Laney, "kind of translation"?
[10:51] <Laney> datetime format strings
[10:51] <seb128> Laney, that's a backport of https://git.gnome.org/browse/gnome-control-center/commit/panels/user-accounts/um-history-dialog.c?id=aa3af401147c9550bc19d14b5cdaf5588083f7c1
[10:52] <Laney> I see
[10:52] <seb128> Laney, but yeah, https://developer.gnome.org/glib/stable/glib-I18N.html#C-:CAPS
[10:55] <Laney> yeah I know C_, was just wondering if using it on format strings like that is a done thing
[10:56] <seb128> Laney, well, that just returns a string, you could put a strdup() or something there as well
[10:57] <seb128> Laney, in any case I'm running that version, works fine (and upstream shipped it in a stable release/didn't do followup commits)
[10:58] <brendand> infinity, looks like there are none: http://paste.ubuntu.com/7221079/
[10:58] <brendand> infinity, i can mention that in the ffe's
[10:58] <infinity> brendand: The source, not the debs.
[10:59] <infinity> brendand: Though I'm actually really curious now, since the UIFe seems to imply there should be some conffiles or something new in the packages. :)
[10:59] <infinity> Anyhow, I'm going to back away from the laptop, drug myself, and be back tomorrow.
[11:04] <Laney> seb128: done, doubt anyone will translate that before release but you never know
[11:04] <seb128> Laney, I uploaded an updated template to launchpad last week so translators already did some work ;-)
[11:05] <Laney> manually?
[11:05] <seb128> yes
[11:05] <seb128> run intltool-update in my build tree and uploaded
[11:06] <seb128> don't worry, it's a documented workflow and not the first time I use it ;-)
[11:09] <Laney> heh
[11:09] <Laney> is there a problem with extracting from uploads?
[11:14] <seb128> Laney, no, it's just that if I had waited for the mp to be review/approved/CI trained/unapproved accepted/landed/imported we would have had the new strings available on launchpad this afternoon
[11:14] <seb128> Laney, where my manual update meant translators had an head start on it during the w.e ;-)
[11:17] <Laney> If only launchpad had a way of making translations available from the VCS :-)
[11:18] <seb128> hehe
=== pete-woods is now known as pete-woods-lunch
[11:43] <didrocks> ubuntu-ui-toolkit uploaded: this is a revert to have gallery-app passing again tests. We want to kick an image soon, can anyone from release team consider it? Thanks ^
[11:44] <Laney> seems queuebot hasn't made it back
[11:45] <didrocks> yeah
[11:45] <didrocks> he's gone for long ;)
[11:51] <Laney> didrocks: ok, done
[11:51] <didrocks> Laney: thanks! there is an unity8 coming as well
[11:52] <didrocks> Laney: which was linked to that change
[11:52] <didrocks> (same, revert of one commit)
=== kitterma is now known as ScottK
[11:54] <didrocks> Laney: unity8 7.85+14.04.20140404.is.7.85+14.04.20140403.1-0ubuntu1 coming to a queue near you :)
[11:55] <xnox> Laney: imho it's a bug fix, but also change in the UI, can you peak at bug #1304363 the proposed diff is "s/1/0/" on left,right & bottom border widths.
[11:55] <ubot2> Launchpad bug 1304363 in ubuntu-themes (Ubuntu Trusty) "[UIFe] enable borderless windows under metacity (e.g. for ubiquity)" [High,Confirmed] https://launchpad.net/bugs/1304363
[11:55] <xnox> this would make ubiquity look sexy.
[11:55] <Laney> xnox: Check with docs for screenshots
[11:55] <Laney> (didn't load the bug, maybe you did that)
[11:56] <Laney> (also going to lunch now :P)
[11:57] <Laney> xnox: And get larsu to review that
[11:57]  * Laney biab
[11:57] <xnox> Laney: but the screenshot is soooo pretty =))))
[11:58] <didrocks> actually, unity8 was autoaccepted
[11:58] <didrocks> Laney: but we'll need someone to bump the fauxpackage if possible
[12:02] <xnox> Laney: larsu approved =)
[12:25] <jamespage> Daviey, fyi just updating ceph to 0.79 for testing prior to upload
[12:25] <jamespage> I'll request an ack once I'm happy its OK
[12:45] <sil2100> Dear release team! Sorry to poke once again about things related to this, but could we ask for pushing platform-api forward from the UNAPPROVED queue? Thank you!
[12:46] <cjwatson> looking
[12:47] <cjwatson> lack of queuebot is slowing us down :)
[12:48] <cjwatson> sil2100: done
=== pete-woods-lunch is now known as pete-woods
[12:56] <sil2100> cjwatson: thank you o/
[12:56] <sil2100> :)
[13:25] <Laney> xnox: did you test metacity itself?
[13:25] <Laney> also, please inform docs team
[13:25] <Laney> after that, should be fine
[13:26] <Laney> didrocks: did it get done?
[13:36] <jamespage> could someone from the release team please review bug 1295093
[13:36] <ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Sync docker.io 0.9.0 from Debian testing" [High,New] https://launchpad.net/bugs/1295093
[13:36] <jamespage> its been there for a while with no comment whatsoever
[13:36] <jamespage> 0.9.1 is now in unstable....
[13:38] <jamespage> (I'll look at that now)
[14:12] <didrocks> Laney: not sure if you have done anything, but unity8 is a valid candidate now :)
[14:19] <xnox> Laney: hm, not sure i need to inform docs team, as we don't have ubiquity screenshots in docs, we only have them on ubuntu.com website. And i have a task to pass updated screenshots for the release to the website team already.
[14:19] <xnox> will double check if that has changed.
[14:20] <Laney> Usually it's polite to do so
[14:20] <Laney> I'd just ask them instead of trying to figure it out yourself
[14:20] <Laney> You can ask GunnarHj
[14:23] <stgraber> oh, reminds me I probably should do a last minute ubiquity slideshow upload
[14:23] <stgraber> (the usual last minute translation update)
[14:45] <seb128> Laney, indicator-datetime in the unapproved queue
[14:45] <Laney> someone else better review that one :-)
[14:45] <didrocks> :p
[15:02] <seb128> could somebody review indicator-datetime in the queue?
[15:02] <seb128> it's a one liner (init a variable to null) that fixes the arm64 ftbfs
[15:03] <marrusl> Hi all.  Can someone look into nvidia-graphics-drivers-331 for precise ?   It seems like it's stuck in the "New" queue.
[15:05] <cjwatson> seb128: done
[15:05] <seb128> cjwatson, thanks
[15:11] <jamespage> Daviey, if you have time - https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093
[15:11] <ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
[15:11] <jamespage> or any other release team members :-)
[15:26] <Daviey> jamespage, i dont feel able to look closely at that issue right now.
[15:37] <bdrung_work> hi, may i upload the new source package versiontools to fix the build failure of gevent-socketio?
[16:03] <jamespage> stgraber, would you have time to review https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093 ?
[16:03] <ubot2> Launchpad bug 1295093 in docker.io (Ubuntu Trusty) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
[16:06] <stgraber> jamespage: not at the moment, no
[16:16] <jamespage> ScottK: I need a review of https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093 - its been kicking around for a while
[16:16] <ubot2> Launchpad bug 1295093 in docker.io (Ubuntu Trusty) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
[16:16] <jamespage> would you have time to review?
[16:17] <jamespage> ScottK, I spoke with the Debian maintainer and he's preparing an upload including the required apparmor patch so we can just sync it over
[16:56] <zul> Can someone accept qemu and libvirt it has a regression that affects virtio devices
=== roadmr is now known as roadmr_afk
[17:08] <cjwatson> zul: done
[17:09] <zul> cjwatson:  thanks
[17:09] <tjaalton> could someone ack https://bugs.launchpad.net/ubuntu/+source/libxkbcommon/+bug/1303706 so I can upload it. RAOF tested it as reported on mir-devel@
[17:09] <ubot2> Launchpad bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New]
[17:31] <robru> cjwatson, oops, I goofed up the bamf upload. can you accept the 0408 version over the 0407.1 that just got into proposed?
[17:39] <cjwatson> robru: sure, one sec
[17:40] <robru> cjwatson, thanks
[17:40] <cjwatson> done
[17:43] <robru> cjwatson, sweeet, thanks again
[17:44] <roaksoax> can someome please take care of 'maas' which is in the approved queue? It has 3 important fixes! Thank you!
=== Guest44106 is now known as Adri2000
=== roadmr_afk is now known as roadmr
[18:37] <rsalveti> slangasek: updated qtbase-opensource-src to make sure all the symbols are up-to-date per arch
[18:38] <rsalveti> slangasek: before we actually propose the changes needed for the gl x gles work
[18:38] <rsalveti> doing a bunch of rebuilds now in a ppa to see if what you proposed in that thread is enough (which should be, unless we get some other issues)
[18:42] <marrusl> Hi folks, can someone take a look at nvidia-graphics-drivers-331-updates in the precise New queue?  It's needed for compatibility with the trusty backport kernel.
[18:58] <chrisccoulson> hi, can someone please accept that flash package? ^
[19:06] <jdstrand> chrisccoulson: oh, I asked you to come here, but I forgot this was for partner
[19:06] <jdstrand> I'll do it
[19:06] <jdstrand> chrisccoulson: for some reason I was thinking it was flashplugin-nonfree
[19:06] <chrisccoulson> ah, thanks :)
[19:07] <chrisccoulson> jdstrand, just uploading the others now as well
[19:07] <jdstrand> chrisccoulson: when you update flashpugin-nonfree for trusty, do ask here though
[19:16] <jdstrand> chrisccoulson: ok, I accepted all the partner packages
[19:16] <chrisccoulson> jdstrand, thanks
[20:37] <slangasek> rsalveti: great, glad to hear you're making progress on the glesing.  Can you give me a pointer to the ppa, so I can follow along?
[20:38] <chrisccoulson> could someone please approve that? ^^ :)
[20:38] <rsalveti> slangasek: did a few tests with local builds and I'm now starting to push stuff to https://launchpad.net/~canonical-arm-dev/+archive/ppa/+packages, but will ping you back later today with more results
[20:38] <rsalveti> slangasek: will test initially with a different src package providing just the packages we care (gui, opengles, etc)
[20:39]  * slangasek nods
[20:39] <rsalveti> that can later be integrated in the same src package, but it needs a bit of rework and too close to the release to work on that now
[20:56] <xnox> Laney: got an ack from docs team. So all good to silo that baby up tomorrow \o/
[22:03] <utlemming> stgraber: we need to add a whole bunch more targets for EC2 testing....can we change HVM to "HVM EBS", with one for each region, and then add "HVM Instance" with one for each region?
[22:06] <stgraber> I'm sure we can, lots of manual changes though (and not really worth scripting)...
[22:08] <xnox> slangasek: is it a requirement for newly introduced upstart jobs in trusty to be precise compatible? (those that e.g. replace init.d scripts) the upgrade story is not nice, init.d script is stopped upon upgrade and not started since upstart job is rejected, thus one must reboot.
[22:08] <xnox> i guess the question is, is it support to run precise upstart with trusty userspace =)
[22:08] <xnox> s/support/supported/
[22:08] <xnox> ?
[22:09] <slangasek> xnox: I don't think this question had ever been brought up explicitly; it's certainly a requirement that "upgrades work", but I'm not sure I understand the implications here - are you finding upstart jobs using particular features that aren't precise-compatible?
[22:09] <xnox> slangasek: bug #1272788
[22:09] <ubot2> Launchpad bug 1272788 in php5 (Ubuntu) "php5-fpm upstart job is not compatible with precise upstart" [High,Triaged] https://launchpad.net/bugs/1272788
[22:10] <xnox> slangasek: due to "reload signal USR2", my cunning plan is to ship .override file with "reload signal USR2" -> precise will ignore .override, but trusty will use the .override. Thus compatible with both releases, without compromise on trusty.
[22:11] <slangasek> xnox: also, is a versioned dependency on upstart sufficient here?  Since running services in chroots is not a common use case, we generally speaking only have to worry about the running init when installing packages in the "host" environment, and versioned dep is sufficient to get upstart restarted
[22:11] <slangasek> override> yuck :)
[22:11] <xnox> slangasek: alternatively maintainer scripts should fall back to initd script.
[22:11] <slangasek> also yuck!
[22:11] <slangasek> why not add a versioned dependency?
[22:12] <xnox> slangasek: versioned dep does not help. so the bug is after upgrade and util reboot.
[22:12] <slangasek> xnox: how does it not help?  upstart is upgraded; it re-execs
[22:12] <slangasek> and then the new syntax is supported
[22:13] <apw> heh
[22:13] <apw> erp
[22:13] <xnox> slangasek: i thought precise upstart can't do stateful re-exec and hence it only re-execs on shutdown....
[22:13] <slangasek> oh man
[22:13] <slangasek> you could be right
[22:13] <slangasek> was that only two years ago?
[22:14] <xnox> slangasek: it was during my time, and i've joined after precise got released.
[22:14] <slangasek> yeah, maintainer script in ge 1.9 || 1.8-ubuntu-full-serialization
[22:14] <slangasek> so you're right, versioned dep is no good
[22:14] <xnox> slangasek: at first oakland keybuk was briefing myself and jodh on how to serialise upstart.
[22:14] <slangasek> xnox: yes, I believe you - I'm just old, and so my perception of time is lacking ;)
[22:15] <xnox> slangasek: hence the question of how to support this case, if at all....
[22:16] <xnox> slangasek: i guess we should be falling back to init.d script if the job is unknown to upstart (even though it's present on disk)
[22:18] <slangasek> xnox: that means we would be falling back to init.d in the case of bugs in the upstart job, too; maybe not desirable
[22:19] <slangasek> xnox: you could both 'check if job is known' and 'use init-checkconf on disk to parse the file', and only fall back to the init script if the current upstart on disk likes it but the running upstart doesn't
[22:19] <infinity> Quick, backport stateful re-exec to precise?
[22:20] <infinity> slangasek: That would be a workable (ish) solution for this one package, but that doesn't really scale if other packages are also precise-incompatible.
[22:20] <xnox> slangasek: but init-checkconf in precise, no-worky without X..... (we fixed that in trusty i believe)
[22:20] <slangasek> infinity: eh, you would put it in invoke-rc.d.
[22:20] <infinity> Not that I like the obvious alternative (tell people they must reboot or their services won't be running).
[22:20] <xnox> because dbus =0
[22:21] <slangasek> xnox: but short circuit behavior saves us, no?
[22:21] <xnox> slangasek: what do you mean by "short circuit" ? =)
[22:22] <slangasek> xnox: if $job_is_not_known && init-checkconf $myjob; then sysvinit_fallback=true; fi
[22:22] <slangasek> xnox: so the only case in which you're even trying to invoke init-checkconf is if the job is unknown in the first place
[22:23] <slangasek> *and*, you really care about getting the answer from the *new* init-checkconf anyway, so you'd have a versioned dep on upstart for those packages where it matters
[22:23] <xnox> slangasek: i care about servers only. we are in the state where init-checkconf will not work. init-checkconf might be precise one - in which case it needs dbus-launch/X to work.
[22:24] <xnox> slangasek: init-checkconf from trusty needs trusty pid1 to be able to use user-session to check the job.
[22:24] <slangasek> xnox: oh, then scrap the entire idea.  I assumed init-checkconf worked without talking to pid1
[22:24] <slangasek> if it doesn't, then it doesn't provide any additional info
[22:25] <slangasek> in which case, "if $job_is_not_known" isn't perfect, but probably the closest we can get
[22:25] <xnox> wait, when init-checkconf is trusty one, /sbin/init is also trusty so yeah that will tell you that job is fine, if you'd re-execed.
[22:26] <xnox> and how would this "sysvinit_fallback=true" work? given that init.d scripts per policy would bail on us and so would the $ service command.
[22:27]  * xnox goes to check how many jobs are affected
[22:29] <slangasek> hah, sigh
[22:29] <slangasek> omg, xnox is sending my mail client into a busy loop
[22:30] <xnox> slangasek: so far i see it's just that one php job. I might opt in for e.g. not stopping it on upgrade from precise -> trusty?!
[22:31] <slangasek> xnox: or just dropping the use of 'reload'?
[22:31]  * xnox will run full init-checkconf on all jobs from trusty on a precise box.
[22:31] <xnox> slangasek: or that.
[23:33] <JackYu> hi release team, who could help to take a look at FFe bug #1293299?
[23:33] <ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFE]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
[23:48] <slangasek> JackYu: hi - it's on my list to look at this afternoon
[23:49] <slangasek> JackYu: FYI, FFe bugs should be left in state 'New', not 'Confirmed' so that the release team sees them
[23:51] <JackYu> slangasek, sure, thanks:)
[23:56] <slangasek> rsalveti: how'd the rebuild go?  FWIW I don't seem to have access to https://launchpad.net/~canonical-arm-dev/+archive/ppa/+packages
[23:56] <slangasek> would be nice to have these builds in a public ppa... :)
[23:57] <rsalveti> slangasek: yeah, need to get a public ppa with armhf
[23:57] <rsalveti> slangasek: but anyway, will copy them over once the build is done
[23:57] <slangasek> ok
[23:57] <rsalveti> finishing qtbase, next is qtdeclarative, and building the gles versions in parallel
[23:57] <rsalveti> but it takes time
[23:57] <rsalveti> qtbase takes almost 4 hours to build on armhf