=== alexabreu is now known as alex-abreu|off
=== FourDollars_ is now known as FourDollars
[07:15] <jibel> Hi, could someone review and approve update-manager and update-notifier in precise-proposed unapproved queue? It's required for HWE EOL notifications
[07:16] <jibel> RAOF, arges ^
[07:17]  * RAOF looks
[07:22] <RAOF> jibel: Hm. Won't be able to accept update-manager until the existing SRU is verified - bug
[07:22] <RAOF> bug #1311396
[07:22] <ubot93> bug 1311396 in update-manager (Ubuntu Trusty) "broken translations results in traceback in new release notification" [Undecided,Confirmed] https://launchpad.net/bugs/1311396
[07:23] <RAOF> Feel free to test that and mark it as verified :)
[07:23] <jibel> RAOF, thanks, I verify it.
[07:23] <jibel> +'ll
[07:32] <RAOF> jibel: Am I right in observing that the update-notifier update should be dependent on the update-manager update? It looks like the update-notifer script unconditionally calls hwe-support-status, which is added in the new update-manager, right?
[07:36] <jibel> RAOF, you're right. let me ask mvo to join this channel.
[07:41] <RAOF> Just upload with an appropriately versioned Depends and it should be fine.
[07:49] <RAOF> Hey mvo!
[07:49] <mvo> RAOF: hi, thanks for your review of update-notifier
[07:51] <mvo> RAOF: I'm happy to add the dependency, but iirc (need to double check) it was done in a way that even without update-manager-core it would still work fine
[07:51] <mvo> i.e. it would just ignore this part
[07:51] <RAOF> It looked to me like it didn't check whether the file existed and just called it; that would generate an error message somewhere, right?
[07:53] <RAOF> mvo: It calls “/usr/bin/hwe-support-status || true”; that's going to error if /usr/bin/hwe-support-status doesn't exist, right?
[07:53] <mvo> RAOF: yeah, there is || true that prevents damage and it won't be part of the user visible output, but I agree that for correctness it makes sense to add the dpenency
[07:54] <RAOF> It'll certainly help in testing :)
[07:54] <RAOF> Since you can't usefully test without the dependency.
[07:55] <mvo> *cough* yes. sorry for that, I will re-upload
[10:05] <ogra_> could some archive admin NEW dbus-property-service ?
[10:23] <seb128> ogra_, done
[10:26] <apw> it looks like libgtop2 2.30.0-0ubuntu1 just migrated but this migrating seems to have ripped a versioned libgtop-2.0.so.7 out from under unity7 which no longer starts; i am wondering why britney didn't stop that
[10:27] <apw> plus could someone else confirm my diagnosis
[10:27] <apw> specificially bamfdaemon seems to be linked to it and no longer starts, which seems to be fatal to unity7
[10:27] <apw> (read, i have a blank desktop)
[10:31] <Laney> apw: looks true from the package list
[10:31] <seb128> shrug
[10:31] <Laney> file list
[10:31] <apw> i suggest upgrading is a bad idea right now
[10:32] <seb128> can you mention it on -devel where the people who did the merge/upload are as well?
[10:33] <seb128> apw, how would have britney stopped that?
[10:34] <seb128> we don't have autopkgtests checking that unity runs
[10:34] <Laney> If there were any tests
[10:34] <Laney> like testing bamf works or something
[10:35] <seb128> right
[10:36] <apw> seb128, hmmm well, i assume something else was done wrong which means it could not detect it, and i think you are suggesting that the binaries are -7 cause they contained abi 7 and should have changed to -10 and did not, if they had, britney would have had a chance
[10:36] <seb128> right, if they had renamed the binary we would have no issue
[10:36] <seb128> the old abi would still be around and britney would have stopped the migration until everything is ported to 10
[10:37] <Laney> Transitions at the archive level are moving dependencies from one package (containing the old SONAME) to another (containing the NEW)
[10:37] <Laney> But if you forget to rename then you just have the new one and the archive seems to be all in order
[10:37] <apw> seb128, yep, i am not blaming britney that is for sure, i was wonderng how we got there, and user error is the answer
[10:38] <Laney> Better test coverage would have helped
[10:38] <apw> yes that is true indeed
[10:39] <seb128> well, what we need is autopilot tests integration in britney/autpkgtests
[10:39] <seb128> we have plenty of those for unity
[10:39] <seb128> they just don't run there
[10:40] <apw> so nearly enough :)  anyhow, sounds like it is getting sorted, thanks for your prompt help
[10:43] <seb128> yw, thanks for pointing it out!
[10:44] <seb128> revert uploaded
[11:12] <apw> it is probabally worth scoring up the lagging arm64 build for this revert given its effects: https://launchpad.net/ubuntu/+source/libgtop2/2.30.0.is.2.28.5-0ubuntu1/+build/6145810
[11:14] <cjwatson> can't make it go faster without cancelling builds
[11:14]  * cjwatson cancels the most recently started build, will retry it in a sec
[11:15] <ogra_> seb128, can i have a binary NEW for dbus-property-service too ?
[11:16] <apw> cjwatson, thanks, it seemed to keep moving out to 10m again every time i looked
[11:16] <cjwatson> Building now
[11:38] <seb128> ogra_, done
[11:38]  * ogra_ hugs seb128 
[11:38] <ogra_> thanks !!
[11:38] <seb128> yw! ;-)
[11:38] <seb128> that was an easy one
[11:42] <mvo> jibel: I wonder if we simply should reject updatemanager in precise-proposed for #1311396 to unblock the SRU for the HWE stack
[11:43] <jibel> mvo, I agree, the SRU should be against the langpacks anyway since there is no other change in update-manager, isn't it?
[11:46] <mvo> jibel: yes
[11:51] <mvo> so could a archive admin please remove update-manager  1:0.156.14.14 from precise-proposed ? so that we can upload a new .15 with a import HWE update?
=== psivaa_ is now known as psivaa-lunch
=== psivaa-lunch is now known as psivaa
=== ogra_` is now known as ogra_
[14:17] <cjwatson> jibel,mvo: removed
[14:24] <mlankhorst> cjwatson: can you accept xorg-lts-transitional ?
[14:24] <cjwatson> where?
[14:24] <mlankhorst> trusty
[14:26] <jibel> cjwatson, thanks. Can you approve update-manager 1:0.156.14.15 in precise ?
[14:26] <cjwatson> mlankhorst: done
[14:26] <mlankhorst> ty
[14:27] <cjwatson> jibel: doesn't it need to be rebased against .13?
[14:27] <mlankhorst> I'll make a backup and try to upgrade tomorrow :p
[14:27] <jibel> mvo, ^
[14:28] <jibel> cjwatson, .14 was a change in the translations which come from LP, but better wait for mvo's answer
[14:29] <cjwatson> sure, but if I removed it that must be because it made things worse, right?
[14:29] <cjwatson> otherwise it was unnecessary to remove it
[14:38] <mvo> cjwatson: its like jibel said, the diff between 13->14 are only po files. I expected that translations.lp would import them from my upstream upload but apparently it didn't :/ it does not make anything worse, I just asked for removal to speed up the process
[14:41] <cjwatson> oh, so there was no need to remove really then
[14:41] <cjwatson> ok, have to go to the bike shop, will have a look later
[14:43] <mvo> thanks
[14:43] <mlankhorst> bdmurray: hm why is https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-raring/+bug/1246384 not a dpkg bug? seems to me that dpkg fails to remove all files for xserver-common-lts-raring before the postrm hook runs..
[14:43] <ubot93> Launchpad bug 1246384 in xorg-server-lts-raring (Ubuntu) "xserver-common-lts-raring does not always get correctly removed." [High,Confirmed]
[14:44] <mvo> and sorry for the confusion about the rmeoval
[15:22] <barry> infinity: question: why is zope.interface in depwait when python3-zope.event is available in utopic?  https://launchpad.net/ubuntu/+source/zope.interface/4.1.1-2/+build/6144343
[15:23] <stgraber> barry: because python3-zope.event isn't in main
[15:24] <barry> stgraber: gah
[15:24] <barry> stgraber: okay, thanks, i missed that.  MIRing
[17:01] <arges> Whats the protocol with sru-releasing packages that I've uploaded or accepted? Do I need to get another person to do the final check?
[17:05] <arges> anyway, I would sru-release pacemaker/corosync for precise; but I'm not sure if I should get another person to do that since I sponsored both
=== jsalisbury_ is now known as jsalisbury
[18:32] <slangasek> arges: sponsor+accept+sru-release, ok.  prepare upload+accept+sru-release, not ok :)
[18:33] <arges> slangasek: so the diffrence is, is it a patch i wrote?
[18:33] <slangasek> arges: the difference is whether you can count yourself as a second set of eyeballs
[18:34] <arges> slangasek: yea that's what i want to avoid. I like having multiple sets of eyes on any change
[18:36] <slangasek> arges: I'm saying the rule of thumb should be that there are at least two sets of eyeballs on the package, the preparer and the SRU team member.  I think it's fine to sru accept a change that you sponsored, provided you're really just sponsoring and not extensively revising
[18:36] <arges> slangasek: gotcha.
=== tgm4883__ is now known as tgm4883
[22:01] <popey> hello! is it possible to get marco, mate-session-manager, mate-desktop-environment synced from debian?
[22:01] <popey> If so, is there some paperwork I need to fill in?
[22:05] <cjwatson> requestsync(1)
[22:06] <cjwatson> But, err, we don't appear to have an Ubuntu delta to any of those?
[22:06] <popey> grr
[22:06] <cjwatson> They're all in utopic at the same versions as in unstable
[22:06] <cjwatson> So nothing to sync
[22:06] <popey> 1.8.0 vs 1.8.1?
[22:07] <popey> 1.8.1-3 vs 1.8.1-4?
[22:07] <cjwatson>  mate-session-manager     | 1.8.1-3               | sid              | source, amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
[22:07] <popey> I'm going by packages.d.o vs packages.u.c
[22:07] <cjwatson> Oh come on those were just uploaded today :)
[22:07] <cjwatson> They'll auto-sync
[22:07] <popey> oh, i wasn't aware of that
[22:07] <popey> i thought it was all manual, sorry.
[22:07] <cjwatson> Very much automated
[22:08] <popey> Yay!
[22:08] <popey> thanks
[22:08] <cjwatson> Before Debian import freeze, anything that doesn't have an Ubuntu delta is auto-synced, basically
[22:08] <cjwatson> (There are a few exceptions)
[22:08] <popey> ah, got it.
[22:09] <cjwatson> lp:ubuntu-archive-tools auto-sync has the full logic should you ever be unfortunate enough to need to investigate