[01:38] <bluesabre> ScottK: would you mind ack'ing the extra released components in https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887 ? at the least, the updated garcon and libxfce4util provide updated libraries with the xfce-4.12 release
[09:39] <jamespage> morning - I have a couple of FFe's that I'd like to get reviewed if there is a release team member around - bug 1423601 and bug 1426761
[09:39] <jamespage> pretty please
[09:39] <jamespage> :=)
[11:25] <sil2100> Hello release team! We would like to get opinion on whether or not we will need to fill in a FFe for the new UITK release that's being prepared
[11:27] <sil2100> It's a big release and the developers mentioned that there might be features changed, but only to fix long-standing bugs
[11:27] <sil2100> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/uitk12_final_vivid_landing/+merge/251578
[11:27] <sil2100> Will we have to pressure for an FFe in this case
[11:29] <tumbleweed> it sounds like it'd require an FFe. New features require FFes. Bug fixes only don't.
[11:32] <doko> tumbleweed, no, there are exceptions for stuff like firefox, openjdk, etc ...
[11:33] <tumbleweed> and uitk isn't in that list
[11:44] <bzoltan_> tumbleweed:  no application is using the UITK on desktop other than the SDK IDE what we maintain.
[11:45] <tumbleweed> then the FFe should be easy to grant
[11:45] <Laney> webbrowser-app
[11:46] <bzoltan_> tumbleweed:  tbh the FFe in our case would be a pure administrative overhead ... the UITK is pretty much on rolling release to the RTM
[11:46] <tumbleweed> then it presumably shouldn't be getting new features after FF
[11:49] <bzoltan_> tumbleweed: it does not
[11:51] <tumbleweed> then it doesn't need an FFe. The rules are pretty simple. Bugfixes that don't break other things, and don't introduce new features don't require an FFe
[11:54] <bzoltan_> tumbleweed:  I am the lander, I do not want to do FFe, because I think it is a pointless administrative overhead. So my opinion os not exactly objective :) So I am looking for somebody who's opinion counts in this case. I can answer questions about this landing.
[11:56] <tumbleweed> bzoltan_: I don't understand what you want. If your upload fits within the FF rules, there isn't a problem. You seem to say that it does, but you also seem to want someone else to approve it, sight unseen.
[11:58] <bzoltan_> tumbleweed:  I am only looking for second opinion :)
[11:58] <tumbleweed> and that's less work than an FFe?
[12:18] <ScottK> Not at the rate we're going.
[12:21] <ScottK> bzoltan_: Needs FFe.
[12:21] <ScottK> (I did look at the diff)
[12:22] <tumbleweed> generally rule of thumb: "Don't know if this needs an ffe" => it does
[12:30] <ScottK> I was pretty sure by line 8 of a 20K line diff.
[12:46] <bzoltan_> ScottK: tumbleweed: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1427662
[12:52] <ScottK> bzoltan_: Approved.
[12:58] <bzoltan_> ScottK: Thank you
[15:54] <zul> can i get an ack for python-eventlet 0.7.0 FFE please (#1424639)
[19:50] <cyphermox> could someone please take a look at console-setup-freebsd, removing it so that console-setup can complete its transition to -release?
[19:57] <infinity> cyphermox: Yeahp.
[19:59] <cyphermox> infinity: thanks. good morning :)
[20:00] <infinity> cyphermox: FWIW, changing the Depends lines seems like unnecessary delta.
[20:00] <infinity> cyphermox: "Depends: foo | bar" when only foo is in Ubuntu is fine, after all.
[20:01] <infinity> cyphermox: Also, you didn't drop the freebsd udebs...
[20:01] <cyphermox> infinity: I'd like to make all of it unnecessary, will propose debian to make console-setup-freebsd Arch: kfreebsd-any.
[20:01] <cyphermox> infinity: the freebsd udebs are fine, really
[20:01] <infinity> cyphermox: Why the deb, but not the udebs?
[20:01] <cyphermox> deb is uninstallable due to vidcontrol, kbdcontrol being uninstallable.
[20:02] <cyphermox> the udebs people could use if they really wanted to, I guess
[20:02] <cyphermox> I mean, really, really wanted to
[20:02] <infinity> Fair enough.
[20:03] <infinity> Should sort itself on the next britnification.
[20:03] <cyphermox> thanks
[22:47] <ari-tczew> could someone take a loon on package osm-gps-map/1.0.2-2 what's wrong with that in -proposed? It contains RC bug fix.
[22:49] <infinity> Trying easy from autohinter: osm-gps-map/1.0.2-2 gnuais/0.3.2-1
[22:49] <infinity> leading: osm-gps-map,gnuais
[22:49] <infinity> start: 158+0: a-48:a-22:a-23:i-22:p-21:p-22
[22:49] <infinity> orig: 158+0: a-48:a-22:a-23:i-22:p-21:p-22
[22:49] <infinity> easy: 159+0: a-49:a-22:a-23:i-22:p-21:p-22
[22:49] <infinity>     * amd64: gpxviewer
[22:49] <infinity> FAILED
[22:49] <infinity> ari-tczew: You could read update_output.txt as well as I can to sort out what that means, I suspect.
[22:50] <infinity> ari-tczew: (That's saying that updating those packages breaks gpxviewer)
[22:52] <ari-tczew> infinity: right, I forgot about proposed-migration