=== agateau_ is now known as agateau
=== nudtrobert1 is now known as nudtrobert
=== Chipaca` is now known as Chipaca
=== Chipaca is now known as Chipakeitor
=== Chipakeitor is now known as __chip__
=== __chip__ is now known as Chipaca
[10:46] <flocculant> morning - are people aware that wily dailies are not working too well since the end of last week? bug 1495017
[10:46] <ubot93> bug 1495017 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions" [Medium,Confirmed] https://launchpad.net/bugs/1495017
[10:48]  * darkxst fires my QA team, no one told me about that flocculant , even though I seem comments from some of them on the bug!
[10:49] <flocculant> darkxst: I didn't check your image as I saw comments - so I assume it's an issue for you too
[10:49] <flocculant> I do try and doublecheck a few images when I see things like this on Xubuntu
[10:59] <darkxst> pitti, how can this even happen on a dbus call interface="(unset)" see ^ bug
[11:00] <pitti> darkxst: err, context?
[11:00] <pitti> darkxst: but no idea about an unset interface -- could you try and ask smcv?
[11:00] <darkxst> ubiquity is crashing apparently, see bug 1495017
[11:00] <ubot93> bug 1495017 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions" [Medium,Confirmed] https://launchpad.net/bugs/1495017
[11:01] <flocculant> it's not apparent - it really is :)
[11:01] <darkxst> flocculant, it may not be ubiquity's fault though
[11:01] <flocculant> you can get it to run - once you've got to the desktop
[11:01] <darkxst> that sounds racy
[11:01] <flocculant> darkxst: ack
[11:01] <pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 7 matched rules; type="method_call", sender=":1.18" (uid=999 pid=1733 comm="/usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --") interface="(unset)" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.6" (uid=0 pid=1437 comm="/usr/sbin/NetworkManager --no-daemon ")
[11:01] <pitti> darkxst: ^ that looks quite straightforward?
[11:02] <pitti> darkxst: i. e. I suppose the new NM changed its policy somehow?
[11:02] <darkxst> what, NM got updated? that slipped past me!
[11:04] <darkxst> pitti, all makes sense now
[11:04] <pitti> I updated the bug
[11:04] <pitti> darkxst: yeah, it was stuck in -proposed for several weeks
[11:04] <darkxst> I had the flu for several weeks
[11:33] <darkxst> pitti, looks like it was ported to gdbus
[11:34] <darkxst> NM that is
[11:40] <darkxst> but that would be after 1.0.4 release ;(
[14:24] <jamespage> doko, all new binaries for gf-complete are now built ^^
[14:34] <davmor2> jamespage: that sounds so Weird Science if you manage to build a complete gf
[14:43] <ogra_> now i feel old
[14:54] <davmor2> ogra_: why because you got that or you realised the film was in the 80's so is 30 years old?
[14:56] <ogra_> yeah ... *sniff*
=== slangase` is now known as slangasek
[18:04] <flexiondotorg> infinity, Please could you update ubuntu-mate-meta for me?
[18:08] <infinity> flexiondotorg: I think I can manage that.
[18:08] <flexiondotorg> infinity, Many thanks.
[18:09]  * infinity wonders idly why pull-lp-source is exploding.
[18:10] <infinity> Oh.  Because python really doesn't like cwd not existing.
[19:46] <cyphermox> I'm trying to sponsor mate-netspeed, but I'm getting a reject: mate-netspeed 1.10.2+dfsg1-1 in stretch (same version already has published binaries in the destination archive)
[19:46] <cyphermox> any idea what might be the issue? I'm specifying to pick it from unstable and send it to wily-proposed
[19:46] <cyphermox> (this is a sync)
[20:07] <infinity> That's a reject from soyuz?
[20:08] <infinity> Huh.  So it is.
[20:11] <infinity> cjwatson, wgrant: ^-- WTF, mate.
[20:12] <infinity> cyphermox: Oh.
[20:12] <infinity> cyphermox: https://launchpad.net/ubuntu/+source/mate-netspeed/+publishinghistory
[20:12] <infinity> cjwatson, wgrant: Nevermind.  britney broke it.
[20:12] <cyphermox> ah
[20:12] <infinity> cyphermox: It was synced weeks ago, and broke on migration.
[20:12] <infinity> cyphermox: I'll copy it back into proposed.
[20:12] <cyphermox> yes, that would certainly explain it
[20:13] <infinity> cyphermox: And let britney migrate it again.
[20:13] <cyphermox> thanks
[20:13] <cyphermox> and let it explo
[20:13] <cyphermox> de again.
[20:13] <cyphermox> :)
[20:15] <infinity> Hahaha.  No, it's totally broken.  That's why britney broke it.
[20:15] <infinity> cjwatson, wgrant: Reping.  https://launchpad.net/ubuntu/+source/mate-netspeed/1.10.2+dfsg1-1 is a mess ... What happened there?
[20:16] <infinity> cyphermox: Path of least resistance will be to upload a build1.
[20:17] <cyphermox> ok
[20:17]  * infinity really wants to know how soyuz created those duplicate build records...
=== med_ is now known as Guest47766
=== Guest47766 is now known as medberry
[22:20] <bdmurray> infinity, slangasek: I forget did we have ubuntu-release-upgrader skip an EoL release? Maybe that was to allow Raring to Trusty upgrades?
[22:21] <slangasek> bdmurray: I think we did have to deal with this previously, yes, though I wouldn't remember the details of how
[22:22] <bdmurray> Does it seem like people upgrading from Trusty should not be upgrading to Utopic and then Vivid?
[22:22] <slangasek> yes
[22:24] <bdmurray> I guess I've just added to my own TODO list.
[22:24] <slangasek> ;)
[22:33] <wgrant> infinity: https://bugs.launchpad.net/launchpad/+bug/682692
[22:33] <ubot93> Launchpad bug 682692 in Launchpad itself "Some PPAs have duplicated builds" [High,Triaged]
[22:33] <wgrant> infinity: But in this case it was probably just two simultaneous copies.
[22:41] <infinity> bdmurray: I think we discussed that, in light of the 9mo release schedule (and to better prepare us for lts->lts), the release upgrader should be capable of upgrading to the "latest" release, skipping in between.  I don't know that we made that happen, though.
[22:42] <infinity> The latest within a supported set of upgrade paths, that is.  Not that quantal should be able to upgrade to wily or any such madness.
[22:43] <bdmurray> Okay, that's what I was sort of remembering too.
[22:45] <infinity> bdmurray: My take is, that, given we have to support 14.04->16.04, we're actually making our lives easier by making sure 14.04->15.10 (for instance) works.  Since we'll know we have the right bits in place for 16.04.
[22:45] <infinity> Or most of the right bits.