[01:53] <veebers> Is there anyone around at this time that can help me with my package stuck in proposed?
[01:54] <veebers> Currently it's been held back by an autopkgtest failure in another project that is unrelated. (autopilot in proposed, autopilot-gtk has failing tests on wily, due to gcc5 changes, which is the unrelated part)
[08:16] <Laney> veebers: wouldn't it be a good idea to fix autopilot-gtk's tests?
[08:36] <veebers> Laney: oh aye, the failures are 'fixed' I'm just in conversation regarding that. Was due to the xpathselect library needing to be rebuilt w/ gcc5
[08:36] <veebers> Laney: we're not ignoring the failures by any means :-)
[08:38] <Laney> veebers: There's these ones too http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/
[08:39] <veebers> Laney: that's the ones I'm talking about
[08:39] <Laney> or is that what you  mean?
[08:39] <Laney> ok
[08:39] <veebers> Laney: I'm not sure why those autopkgtests are failing, but on my wily machine I attempt to build at it fails like that, I rebuild and install xpathselect and the ap-gtk build succeeds
[12:06] <Laney> Huh
[12:07] <Laney> I just looked into that autopilot-gtk failure a bit. Can't confirm that rebuilding xpathselect changes anything, but rebuilding *autopilot-gtk* itself does.
[12:13] <Laney> Ah
[12:14] <Laney> I bet that the xpathselect in wily-proposed is an ABI break
[12:15]  * Laney thanks autopkgtest
[12:17] <Laney> sil2100: ^^^ FYI that xpathselect upload was suspicious (just checked who published the silo)
[12:17] <Laney> Trevinho: ^ fyi too
[12:19] <Trevinho> Laney: looking at the AP failures, I was seeing the very same failures with previous versions as well, did I miss something?
[12:19] <Laney> Trevinho: The index out of range thing is new with the rebuilt xpathselect
[12:20] <Laney> compare https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150819_132411@/log.gz and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150820_151042@/log.gz
[12:20] <Trevinho> Laney: so... want me to change soname or xpathselect or what else? And rebuild AP probably..
[12:21] <Laney> we need to rename xpathselect to add a "v5" to the end of the package name
[12:21] <Laney> I can do this, already did a bunch of them already
[12:21] <Laney> then things which depend on it need rebuilding too
[12:21] <Trevinho> Laney: oh, if want, go for it... What should I do with my silo then?
[12:22] <Laney> what else is in it?
[12:23] <seb128> unity that already migrated
[12:23] <Laney> good job this isn't used for anything critical path ;-)
[12:23] <Laney> Trevinho: will use the same silo I guess
[12:24] <Trevinho> Laney: ok, make it yours
[12:24] <Laney> just stack up on yours
[12:24] <Laney> I would guess that the ap-gtk failure is going to go back to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150819_132411@/log.gz
[12:25] <Trevinho> unity has not a strict dependency on that... and so most of stuff I guess... We dload it it and probably other libs do that
[12:26] <Laney> which one?
[12:26] <Trevinho> mh, I didn't check, but probably gtk module for AP introspection does the same
[12:28] <Laney> ya, that should be fine
[13:00] <Laney> Trevinho: Just wasted/used some time trying to fix that other AP failure, so will do the renaming and stuff after lunch
[13:00] <Laney> hopefully should also unflakify this test
[13:01] <Trevinho> ok
[13:02] <Laney> seems you can't do Eventually(raises(stuff))
[13:02] <Laney> I probably knew that once
[13:02] <Laney> and now I know it again!
[13:02] <Laney> biab
[13:11] <coreycb> hi release team, we have 2 openstack Liberty uploads for the beta 2 release that we need to upload to wily.  can we get approval to upload them?  FFE bug 1488094
[15:20] <flexiondotorg> Laney, infinity I need some quick advice.
[15:21] <flexiondotorg> The MATE 1.10 migration in Debian unstable didn't get completed prior to the feature freeze.
[15:21] <flexiondotorg> Due in part to me being on jury service for 3 weeks and my Debian sponsors being on summer vacation and attending DebConf.
[15:22] <flexiondotorg> Consequently MATE in the 15.10 is a mix on 1.8 and 1.10. Therefore afflicted by segfaults and regressions.
[15:22] <flexiondotorg> Do I need to file for an FFe for each package I want to sync from Debian unstable?
[15:23] <flexiondotorg> My Debian sponsors are back from vacation and have been uploading MATE to unstable for the last 2 days. It is (almost) complete there now.
[15:24]  * ogra_ bets you can get along with a simgle bu for all MATE related FFe packages
[15:24] <ogra_> *bug
[15:25] <flexiondotorg> ogra_, So create a bug listing all unsynced MATE packages then reference that in each sync request?
[15:26] <ogra_> thats what we did in the past for i.e. phone images when needing approval for an FFe
[15:33] <flexiondotorg> ogra_, My question is does I need FFe because technically the sync will be fixing bugs?
[15:33] <ogra_> it brings in new upstream versions ...
[15:33] <ogra_> which makes it fall under FF
[15:33] <Laney> No
[15:33] <ogra_> no ?
[15:33] <Laney> Numbers don't matter
[15:33] <ogra_> thats new then
[15:33] <Laney> the changes do
[15:34]  * ogra_ still thinks just a blanket FFe for all MATE packages should be fine 
[15:35] <ogra_> after all it is you who knows best if syncing them is helpful anyway
[15:37] <didrocks> as Laney said, it just depends what the new release bring. If it's bug-fix only, then no need for FFe
[15:37] <didrocks> if it's new features, that's the F of FFe ;)
[15:38] <ogra_> well ... if you have 3 packages out of 10 that need FFes it is still less paperwork to have a blanket one  for all of MATE ;)+
[15:39] <didrocks> or just open a bug with those 3 packages, and explain what new features it will bring in (and thus, the risks)
[15:40] <ogra_> (and after all we are talking about universe here ... where the rules used to be less strict anyway ... not sure thats still the case)
[15:41] <didrocks> less strict == getting the FFe accepted easily, yeah
[15:41] <didrocks> but not as "no need for FFe"
[15:41] <ogra_> indeed
[15:42] <Laney> unseeded maybe, but these are on a flavour
[15:42] <Laney> The request coming from a flavour developer gives it more weight though.
[15:44] <ogra_> would the conversation not be anyway: flexiondotorg files an FFe bug, you ask him to judge the feature impact since he is most familiar with the code and he tells you to approve/deny  ?
[15:45] <ogra_> sonds a bit like total waste of time and unneded buerocracy if it works like that in the end
[15:45] <apw> best to get a minion to file it ;)
[15:45] <ogra_> well, it if is only for the sake of paperwork i'd even say if a flavour lead asks for it, dont require and FFe
[15:46] <ogra_> and use the miniont time for better stuff ;)
[15:46] <ogra_> *minion
[15:46] <flexiondotorg> OK, so in which case. Some MATE packages in the 15.10 archive are v1.8 and syncing would bump them to 1.10 and they would bring new features in most cases.
[15:47]  * ogra_ just thinks it is pointless to require paperwork if the final decider is also the requesting person in the end ... and i guess most of the time thats the case for flavours
[15:47] <flexiondotorg> So, is the consensus for me to file an FFe for all MATE packages I'd like syncing, then reference that in the sync requests?
[15:48] <flexiondotorg> All the packages are MATE specific and will only impact (positively) Ubuntu MATE.
[15:48] <Laney> I don't really know why ogra is getting himself worked up
[15:48] <ogra_> yeah, by the current rules
[15:48] <ogra_> Laney, i'm not worked up at all
[15:48] <Laney> flexiondotorg: I think just do it this one time
[15:48] <Laney> call that an ack from me :)
[15:48] <ogra_> just analyzing
[15:48] <didrocks> Laney: yeah, seems like the current discussion is taking more time than following the process itself :)
[15:48] <flexiondotorg> Laney, So just start creating sync requests and say you've approved them?
[15:49] <Laney> sure, just paste this in or whatever
[15:49] <ogra_> i'm just wonderign if the process is still helpful at all
[15:49] <Laney> After you get it all in line then follow feature freeze
[15:49] <ogra_> or if we shouldnt loosen it a little
[15:49] <macjack> infinity: Hello infinity, I found "README.diskdefines" in each single 14.04.3 ISO file, it will show "Beta"
[15:49] <flexiondotorg> Laney, OK, thanks.
[15:49] <macjack> infinity: is it typo? Thanks
[15:49] <Laney> ogra_: Getting yourself in the middle of a discussion about a specific request isn't going to bring about the change you want though
[15:49] <Laney> go start a thread on list or something
[16:21] <infinity> macjack: Yeah, the string didn't get changed before release.  Congrats on being the first person other than me that noticed. :P
[16:23] <macjack> infinity: I am the lucky guy :) lol
[16:24] <macjack> infinity: anyway, thanks for replying, just to be sure it is formal release :)
[16:27] <infinity> macjack: It is, yes.  Just an embarrassing error that fixing post-release isn't worth doing.  Perhaps a note in the release notes wouldn't be a bad idea.
[18:07] <flexiondotorg> infinity, Can you do me a favour please? deja-dup-caja has been in the Wily NEW queue for weeks, could you assist it's promotion please?
[18:08] <flexiondotorg> infinity, It is a plugin for Caja (the MATE filemanager) that provides integration with Deja Dup backup.
[18:08] <flexiondotorg> infinity, I requested the plugin and help with it's development. It's inclusion will only affect/benefit Ubuntu MATE.
[18:15] <coreycb> hello, looking for an archive admin's opinion.   we have packages prepped for switching from python-mysqldb to python-pymysql, which is a drop in replacement for python-mysqldb.  do we need an FFE to update d/control for these package updates?
[18:15] <coreycb> for context, MIR bug 1477668
[22:38] <michi> sil2100: Thanks for your help with the train builds!