[01:53] Is there anyone around at this time that can help me with my package stuck in proposed? [01:54] 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) === jzheng_ is now known as jzheng [08:16] veebers: wouldn't it be a good idea to fix autopilot-gtk's tests? === Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: feature freeze | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis [08:36] 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] Laney: we're not ignoring the failures by any means :-) [08:38] veebers: There's these ones too http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/ [08:39] Laney: that's the ones I'm talking about [08:39] or is that what you mean? [08:39] ok [08:39] 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 === jzheng is now known as jzheng_afk === Laney is now known as Guest65212 === Guest65212 is now known as Laney === thierry-ibm is now known as thf [12:06] Huh [12:07] 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] Ah [12:14] I bet that the xpathselect in wily-proposed is an ABI break [12:15] * Laney thanks autopkgtest [12:17] sil2100: ^^^ FYI that xpathselect upload was suspicious (just checked who published the silo) [12:17] Trevinho: ^ fyi too [12:19] Laney: looking at the AP failures, I was seeing the very same failures with previous versions as well, did I miss something? [12:19] Trevinho: The index out of range thing is new with the rebuilt xpathselect [12:20] 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] Laney: so... want me to change soname or xpathselect or what else? And rebuild AP probably.. [12:21] we need to rename xpathselect to add a "v5" to the end of the package name [12:21] I can do this, already did a bunch of them already [12:21] then things which depend on it need rebuilding too [12:21] Laney: oh, if want, go for it... What should I do with my silo then? [12:22] what else is in it? [12:23] unity that already migrated [12:23] good job this isn't used for anything critical path ;-) [12:23] Trevinho: will use the same silo I guess [12:24] Laney: ok, make it yours [12:24] just stack up on yours [12:24] 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] 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] which one? [12:26] mh, I didn't check, but probably gtk module for AP introspection does the same [12:28] ya, that should be fine [13:00] Trevinho: Just wasted/used some time trying to fix that other AP failure, so will do the renaming and stuff after lunch [13:00] hopefully should also unflakify this test [13:01] ok [13:02] seems you can't do Eventually(raises(stuff)) [13:02] I probably knew that once [13:02] and now I know it again! [13:02] biab [13:11] 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 [13:11] bug 1488094 in neutron-vpnaas (Ubuntu) "[FFE] glance, neutron-vpnaas liberty-2 release" [Undecided,New] https://launchpad.net/bugs/1488094 [15:20] Laney, infinity I need some quick advice. [15:21] The MATE 1.10 migration in Debian unstable didn't get completed prior to the feature freeze. [15:21] 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] Consequently MATE in the 15.10 is a mix on 1.8 and 1.10. Therefore afflicted by segfaults and regressions. [15:22] Do I need to file for an FFe for each package I want to sync from Debian unstable? [15:23] 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] *bug [15:25] ogra_, So create a bug listing all unsynced MATE packages then reference that in each sync request? [15:26] thats what we did in the past for i.e. phone images when needing approval for an FFe [15:33] ogra_, My question is does I need FFe because technically the sync will be fixing bugs? [15:33] it brings in new upstream versions ... [15:33] which makes it fall under FF [15:33] No [15:33] no ? [15:33] Numbers don't matter [15:33] thats new then [15:33] the changes do [15:34] * ogra_ still thinks just a blanket FFe for all MATE packages should be fine [15:35] after all it is you who knows best if syncing them is helpful anyway [15:37] as Laney said, it just depends what the new release bring. If it's bug-fix only, then no need for FFe [15:37] if it's new features, that's the F of FFe ;) [15:38] 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] or just open a bug with those 3 packages, and explain what new features it will bring in (and thus, the risks) [15:40] (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] less strict == getting the FFe accepted easily, yeah [15:41] but not as "no need for FFe" [15:41] indeed [15:42] unseeded maybe, but these are on a flavour [15:42] The request coming from a flavour developer gives it more weight though. [15:44] 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] sonds a bit like total waste of time and unneded buerocracy if it works like that in the end [15:45] best to get a minion to file it ;) [15:45] 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] and use the miniont time for better stuff ;) [15:46] *minion [15:46] 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] 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] All the packages are MATE specific and will only impact (positively) Ubuntu MATE. [15:48] I don't really know why ogra is getting himself worked up [15:48] yeah, by the current rules [15:48] Laney, i'm not worked up at all [15:48] flexiondotorg: I think just do it this one time [15:48] call that an ack from me :) [15:48] just analyzing [15:48] Laney: yeah, seems like the current discussion is taking more time than following the process itself :) [15:48] Laney, So just start creating sync requests and say you've approved them? [15:49] sure, just paste this in or whatever [15:49] i'm just wonderign if the process is still helpful at all [15:49] After you get it all in line then follow feature freeze [15:49] or if we shouldnt loosen it a little [15:49] infinity: Hello infinity, I found "README.diskdefines" in each single 14.04.3 ISO file, it will show "Beta" [15:49] Laney, OK, thanks. [15:49] infinity: is it typo? Thanks [15:49] 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] go start a thread on list or something [16:21] macjack: Yeah, the string didn't get changed before release. Congrats on being the first person other than me that noticed. :P [16:23] infinity: I am the lucky guy :) lol [16:24] infinity: anyway, thanks for replying, just to be sure it is formal release :) [16:27] 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] 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] infinity, It is a plugin for Caja (the MATE filemanager) that provides integration with Deja Dup backup. [18:08] infinity, I requested the plugin and help with it's development. It's inclusion will only affect/benefit Ubuntu MATE. [18:15] 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] for context, MIR bug 1477668 [18:15] bug 1477668 in python-pymysql (Ubuntu) "[MIR] python-pymysql" [High,Incomplete] https://launchpad.net/bugs/1477668 [22:38] sil2100: Thanks for your help with the train builds!