=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== didrocks1 is now known as didrocks
[08:54] <zequence> Hi. Got a package that would need to be uploaded soonish. It's a FFe, and doesn't show in the sponsors queue. It was uploaded to the archives once already, but was rejected due to some lintian warnings, which are gone now Bug: 946591
[08:54] <ubot2> Launchpad bug 946591 in Ubuntu "[FFe] Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
[09:00] <zequence> ^
=== wgrant_ is now known as wgrant
[09:37] <zequence> ..got it to show in the sponsors queue.
=== chuck_ is now known as zul
=== pgraner` is now known as pgraner
=== lool- is now known as lool
[13:26] <dbarth> hi there
[13:27] <dbarth> who has the ability to review this FFE: https://bugs.launchpad.net/webbrowser-app/+bug/1288743 ?
[13:27] <ubot2> Launchpad bug 1288743 in webbrowser-app (Ubuntu) "[FFE] Support for online accounts in webapp-container" [Undecided,New]
[13:27] <dbarth> it is to authorize the landing of a webbrowser-app change on /touch/, knowing that we have limited the binding to not affect the desktop release
[13:28] <dbarth> (the feature is not active on the desktop, via a runtime check); and does not build-depend on universe to fit the desktop/main requirements
[13:39] <dbarth> seb128: ping? can you help? (it's blocking us on the desktop as well)
[13:39] <dbarth> who has the authority to examine the FFE above ^^
[13:40] <seb128> dbarth, I'm not in the release team
[13:40] <seb128> dbarth, https://launchpad.net/~ubuntu-release
[13:41] <dbarth> seb128: i know, but who should i ask for something in between touch and desktop?
[13:42] <seb128> dbarth, FFe are release team material, I just gave you the team on launchpad, it has the list of people
[13:42] <seb128> but you are in the right channel
[13:42] <seb128> they are just busy
[13:42] <seb128> you are not the only one having a FFe request, there is quite some queue
[13:43] <dbarth> i can imagine
[14:24] <sergiusens> dbarth, my FFes have been open for a week; I think it's just a matter of time
=== psivaa_ is now known as psivaa
[14:27] <dbarth> sergiusens: one way or the other,yes, since we're doing time-based releases
[14:28] <sergiusens> dbarth, I mean a matter of time until they get to it :-)
[14:28] <dbarth> i know ;)
[16:04] <Laney> There's quite a few FFes pending
[16:05] <Laney> do any of the rest of you have time to look at some of them?
[16:07] <cjwatson> dbarth: approved
[16:08] <cjwatson> dbarth: hopefully I can get https://code.launchpad.net/~cjwatson/webbrowser-app/multiarch/+merge/211350 rolled in in exchange ;-)
[16:15] <dbarth> cjwatson: \o/ thank you :)
[16:15] <dbarth> let me check that one
[16:57] <Laney> infinity: want to look at https://bugs.launchpad.net/ubuntu/+source/binutils-avr/+bug/1235748 ?
[16:57] <ubot2> Launchpad bug 1235748 in binutils-avr (Ubuntu) "FFe: Sync binutils-avr 2.23.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
[16:58] <infinity>  binutils-avr | 2.23.1-2 | trusty/universe  | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[16:58] <infinity> Laney: Looks already done?
[16:59] <Laney> Oh, I didn't check that
[16:59] <Laney> who didn't wait for the FFe?
[16:59] <Laney> wait
[16:59] <Laney> that one is ancient
=== plars_ is now known as plars
[16:59] <infinity> Yeah, that happened in October, not an FFe thing. :P
[16:59] <Laney> Yeah, we probably ought to clean out the queue at some point. :P
[17:40] <Laney> Daviey: If you're still interested in server (MAAS/Openstack) FFes there are a few in the queue
[17:40] <Laney> I saw you replied to some already, so letting you know.
[17:54] <cjwatson> infinity: libnss-mdns-i386 fauxpkged, though unfortunately it'll need a version bump each time nss-mdns is uploade
[17:54] <cjwatson> d
[17:54] <cjwatson> (I haven't done anything to the seeds, I'll let you figure that out)
[17:56] <infinity> cjwatson: I intend to drop that package in an Ubuntu delta post-trusty anyway.
[17:57] <cjwatson> cool
[17:57]  * cjwatson looks at the build queues.  we can haz powerpc vms on some of the new hosts any time?
[17:57] <infinity> cjwatson: It's only meant for smooth upgrades from lib32nss-mdns to libnss-mdns:i386, so has no use post-LTS.
[17:58] <infinity> cjwatson: Twiddling VMs is on my TODO but, realistically, don't know if I'll have time this week.
[18:00] <Daviey> Laney: ok, thanks - will take a look this evening. Travelling right now.
[18:01] <Laney> Daviey: righto
[18:10] <stgraber> infinity: I'm assuming fisher01 is the ppc64el livefs buildd? if so, something seems wrong with it, there are tasks stuck for a couple of days on nusakan.
[18:12] <infinity> stgraber: Oh.  Derp, I forgot that was the livefs builder when I kept it offline for debugging.  I'll bring it back.
[18:14] <infinity> stgraber: Should be happy now.
[18:15] <stgraber> infinity: ok, I'll kill the remaining ssh processes on nusakan. I'm assuming you cleaned up any remaining livefs cruft on the buildd itself?
[18:15] <infinity> stgraber: There probably isn't any to clean up.  Let me poke.
[18:16] <infinity> I mean, unless it died in the middle of a build, but I doubt it.
[18:16] <infinity> Yeah, I see no lock filed or anything.
[18:16] <stgraber> ok, nusakan has been cleaned up, so things should start building again with the next cronned run
[18:17] <psivaa> infinity: cjwatson: curious about why trusty server iso's are not in cdimage since the 13th if in case anyone pings me.. i see some armhf build failures
[18:17] <psivaa> apologies if the info is in the backlog.. dint go that far back
[18:17] <infinity> Sorry about that.  Just bad luck, I guess, that the 1 in 10 machines that blew up and showed off the IPC race also happened to be the livefs builder. :P
[18:17] <stgraber> psivaa: probably the exact same issue we just fixed since that'd have held up publising of all core and server images.
[18:17] <cjwatson> right
[18:18] <cjwatson> so a whole <10 lines back in scrollback :)
[18:18] <stgraber> psivaa: so they should be appearing nowish
[18:19] <psivaa> stgraber: cjwatson: ack, thanks :)
[19:01] <sergiusens> can someone please look at bug 129094 ?
[19:01] <ubot2> Launchpad bug 129094 in Ubuntu "data CD will not mount and reason given is that I am not root" [Undecided,Invalid] https://launchpad.net/bugs/129094
[19:01] <sergiusens> meh
[19:01] <sergiusens> can someone please look at bug 1290944 ?
[19:01] <ubot2> Launchpad bug 1290944 in phablet-tools (Ubuntu) "[FFe] standing freeze exception in trusty for Ubuntu Touch tools packages" [Undecided,Confirmed] https://launchpad.net/bugs/1290944
[19:01] <sergiusens> latter not former
[19:06] <stgraber> sergiusens: approved
[19:06] <sergiusens> stgraber, thanks
[19:08] <jdstrand> slangasek: hey, fyi, I was asked to alert you to bug #1293681 and bug #1290535
[19:08] <ubot2> Launchpad bug 1293681 in oxide-qt (Ubuntu) "[MIR] oxide" [Undecided,New] https://launchpad.net/bugs/1293681
[19:08] <ubot2> Launchpad bug 1290535 in webbrowser-app (Ubuntu) "[FFE] Webapps support for the new Oxide container" [Undecided,New] https://launchpad.net/bugs/1290535
[19:08] <jdstrand> slangasek: there is nothing for you to do now. basically, we hope to land oxide in the archive this week
[19:09] <jdstrand> slangasek: when that is done, webapps will transition to using oxide
[19:10] <jdstrand> slangasek: I'll handle the MIR bits, so this is just a heads up that the webapps team will need the release team to comment on the FFe, probably next week
[19:10] <jdstrand> dbarth: fyi ^
[19:29] <dbarth> jdstrand: ok
[19:30] <dbarth> thanks
[20:09] <sergiusens> if a package was building fine for arm64 and then finally failed, would that block it in proposed?
[20:11] <cjwatson> sergiusens: that depends on whether the version currently in trusty has an arm64 build
[20:11] <cjwatson> sergiusens: https://wiki.ubuntu.com/ProposedMigration has the rules
[20:11] <sergiusens> cjwatson, it does https://launchpad.net/ubuntu/+source/ubuntu-download-manager
[20:12] <cjwatson> No it doesn't :)
[20:12] <sergiusens> hmm it was depwait for saucy; not sure what the previous results were for trusty; but mandel is saying it used to work
[20:12] <sergiusens> I trust you :-)
[20:12] <cjwatson> depwait vs. failure doesn't matter
[20:12]  * sergiusens checks wiki
[20:12] <cjwatson> the point is it doesn't have binaries in the arhcive
[20:12] <cjwatson> *archive
[20:12] <sergiusens> right; so it was never in (for amr64)
[20:13] <cjwatson> though that build doesn't look desperately far away from working
[20:13] <sergiusens> nope
[20:15] <mandel> sergiusens, cjwatson I don't know much about this, but I do have a ppa where it does build with no problems: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5661763
[20:15] <cjwatson> that's amd64 not arm64
[20:16] <sergiusens> yeah
[20:16] <cjwatson> anyway, this should be fixed but it's no kind of blocker
[20:16] <mandel> ah, sorry
[20:17] <xnox> sergiusens: i mean, if it ever built, AAs have powers to remove binaries from arches and re-introduce them via copies. Which sometimes is done to unblock things (like last friday for qt5.2) so e.g. $ rmadison -S -s trusty ubuntu-download-manager is authoratative way to look up if binaries are or aren't in the achive and for which arches.
[20:17] <mandel> cjwatson, sergiusens ok, so I'm stupid, and I don't think that qmake is placing the libs for arm64 in the correct place, I'll take a closer look
[20:17] <xnox> sergiusens: if ever in doubt =)
[20:18] <sergiusens> xnox, thanks, will add to my cheats
[20:25] <infinity> mandel: Looks like that's the same issue on powerpc too.
[20:25] <mandel> infinity, yes, I'm moving away from qmake due to this kind of things, but will fix both archs
[20:26] <infinity> mandel: Well, surely the answer is for INSTALL_LIBDIR to be seeded by debian/rules with DEB_HOST_MULTIARCH instead of hardcoding it in common-project-config.pri
[20:26] <infinity> Especially since this is wrong too: ARCH = $$system(uname -m)
[20:26] <infinity> (Our i386 buildds are all x86_64, using uname to determine userspace ABI is never right.  Ever)
[20:27] <mandel> infinity, I'm not a qmake expert so I have clearly make an error there, will fix it after dinner
[20:27] <infinity> (The only reason that works for you is because we run our i386 builds under "linux32" to fake uname, but one shouldn't rely on that)
[20:29] <infinity> mandel: Ahh and, indeed, LIBDIR is already preseedable in your .pri
[20:31] <mandel> infinity, yes, I should just be seeding it in the rules and that should sort it out AFAIK
[21:03] <slangasek> jdstrand: yes, dbarth mentioned that on here previously; I'll make sure to make time for FFe request processing between now and then
[21:04] <jdstrand> slangasek: yes, he mentioned that. new info is that oxide should be in the archive soon. awesome, thanks! :)
[21:13] <knome> stgraber, wait, what, where's your "UIF upload" commit for the slideshow?
[21:14] <knome> ah, there it is.
[21:18] <knome> stgraber, we are *missing* content for one slide (plus some minor uploads), about to land it in the next few hours. will you approve that UIFe? ;)
[21:19] <stgraber> knome: sure, file a bug and I'll look at it. Since it'll likely only affect your own documentation and not anything shared with other teams, that shouldn't be a problem.
[21:19] <knome> stgraber, was thinking of the same
[21:20] <knome> stgraber, i only semi-accidentally even noticed the UIFe note, as i was just landing the first, but almost final version of that slide
[21:20] <knome> talk about timing ;)
[21:20] <stgraber> I figured that waiting till Monday after UIF would be good enough to catch all last minute changes, apparently not ;)
[21:21] <stgraber> (Edubuntu was a bit late too, so you're not alone ;))
[21:21] <knome> yeah, we were supposed to have this ready, but real life comes into the way, the person to write the script was in rome...
[23:04] <robru> cjwatson, errrr, can you check on process-cpp? citrain somehow thinks it's in proposed, but I don't see it on any of excuses, launchpad, or even rmadison
[23:05] <robru> cjwatson, oh nm, now I see it in rmadison
=== Ursinha is now known as Ursinha-afk