[01:44] <rbasak> infinity: arch skew? I was offline before. Anything I need to do?
[01:47] <rbasak> Looks like it failed on various archs for various reasons.
[01:48] <rbasak> Skuggen: can you take a look please?
[01:48] <rbasak> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.11-0ubuntu1
[01:48] <rbasak> Missing libnuma-dev on armhf and s390x.
[01:48] <rbasak> Undeclared __NR_epoll_wait in libevent on arm64.
[01:49] <rbasak> "Native atomics support not found!" on powerpc.
[01:49] <rbasak> Pretty spectacular!
[02:01] <infinity> rbasak: I tihnk I have it all fixed except for powerpc.
[02:01] <infinity> rbasak: That one's going to take teaching upstream that it's 2016 and porting from __sync to __atomic functions.
[02:02] <infinity> Which I might do later tonight if bored enough.
[02:02] <infinity> But first I need food and a brain break.
[02:04] <cjwatson> With any luck Debian imports should be fixed after the next time the cron job finishes, typically in around three hours.
[02:04] <cjwatson> (from now I mean)
[02:04] <cjwatson> But we shall see.
[02:42] <tsimonq2> out of curiosity, if one were to want a metapackage in the Ubuntu archives, is it too late in the release cycle? it's just a metapackage...
[02:48] <slangasek> it is not in principle too late.  in practice you may be hard pressed to get AA time to look at the new packgae
[03:01] <tsimonq2> but let's say it only pulls in like 15 packages and is part of a team that can endorse it?
[03:01] <tsimonq2> like a flavor?
[03:02] <tsimonq2> slangasek: ^
[03:19] <slangasek> tsimonq2: only somewhat relevant.  The fact that it's a metapackage /suggests/ it will be an easy review and that increases your odds of an AA picking it up; but AA time is a scarce commodity in the latter part of the cycle
[03:22] <tsimonq2> slangasek: how do I start this process?
[03:33] <slangasek> tsimonq2: getting the package uploaded to the NEW queue
[03:40] <slangasek> cjwatson: oops, devscripts is dep-wait on libuniversal-require-perl!  I have a suggestion on how to clear this dep-wait ;)
[03:47] <cjwatson> slangasek: http://irclogs.ubuntu.com/2016/03/22/%23ubuntu-devel.html#t02:18
[03:48] <cjwatson> slangasek: though I acknowledge your more basic point :)
[03:48] <cjwatson> Hopefully tomorrow I won't have to spend a good chunk of the day on the phone to my ISP
[04:01] <slangasek> hmm so now pixfrogger is built, but p-m also won't let it through because uninstallable on amd64
[04:01] <slangasek> do we have a way to hint around that?
[04:01] <infinity> You can force it and lower the installable count.  Which I'm not super keen on.
[04:02] <infinity> A few releases back, cjwatson and I were intentionally converting things from all to arch-restricted where they had unsatisfiable deps.
[04:05] <slangasek> infinity: we do have FauxPackages in britney1; would that do any good?
[04:06] <infinity> slangasek: We could fill FauxPackages with a bunch of deps for arch:all packages, yes, but that's a bit gross once the list exceeds a handful.
[04:08] <cjwatson> debmirror is working now on iron, but I think it's going to miss the stupid hardcoded five-minute time allocated for it to run before gina starts.
[04:08] <cjwatson> I really must fix that.
[04:12] <cjwatson> It might manage to make it in time to get unstable imported though, just miss experimental.
[04:13] <stgraber> gah, who broke golang on powerpc again?
[04:13] <stgraber> well, gccgo because no golang on it
[04:13] <stgraber> mwhudson: around?
[04:13] <slangasek> stgraber: perhaps related to the ongoing transition to enable versioned golang packages
[04:13] <cjwatson> Ah, no, experimental is small so was processed quickly.
[04:14] <stgraber> slangasek: yeah, I guess so
[04:14] <stgraber> mwhudson: https://launchpadlibrarian.net/249534628/buildlog_ubuntu-xenial-powerpc.lxd_2.0.0~rc5-0ubuntu1_BUILDING.txt.gz
[04:14] <stgraber> mwhudson: "No such file or directory" for the go command is a bit problematic :)
[04:14] <cjwatson> Some things might end up being imported straight into stretch without going through sid from LP's point of view, which would be a bit odd.
[04:14] <cjwatson> Hopefully not many.
[04:15] <stgraber> let me see what we depend on right now, I had to change that stuff back and forth a few times in the past
[04:15] <infinity> stgraber: gccgo stopped providing it as an alternative, so we could move to a go-defaults sort of world.  Looks like the second part isn't entirely sorted yet.
[04:15] <stgraber> infinity: fun, so in the mean time go is busted on arches requiring gccgo?
[04:16] <infinity> stgraber: Pretty sure golang-go is meant to provide the right links now that gccgo doesn't.   I think.
[04:16] <infinity> stgraber: Poke mwhudson even harder, I'm sure he'll sort it when he wakes up.
[04:16] <stgraber> yeah and we depend on golang-go because it's available on all arches and we were told that it would DTRT, apparently it doesn't anymore
[04:16] <infinity> Oh, wait, he shold be "awake" now.  My clock is backwards.
[04:16] <stgraber> isn't it like 5pm for him, he should still be working
[04:16] <stgraber> or at least be awake :)
[04:16] <infinity> stgraber: golang-go is the right thing, it's just mid-transition to a new world order.
[04:17] <infinity> mwhudson: mwhudson mwhudson mwhudson mwhudson mwhudson mwhudson mwhudson
[04:22] <infinity> stgraber: Ahh, yes, here's the problem.
[04:22] <infinity> stgraber: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1555856
[04:22] <infinity> stgraber: It required changes in gccgo, golang, and the new golang-defaults.  But only gccgo was changed.
[04:22] <infinity> stgraber: Resulting in this. :P
[04:23] <mwhudson> infinity: hi
[04:23] <mwhudson> yes, i was expecting some coordination on this
[04:24] <infinity> mwhudson: Hi.  So, the GCC changes for this landed before everything else, and now stgraber's sad.
[04:24] <stgraber> seems like a bit of a fail, surely this was meant to land together :)
[04:24] <mwhudson> but doko apparently didn't think so, or didn't notice
[04:24] <infinity> mwhudson: If golang-go on powerpc just a stub that depends on gccgo right now?
[04:25] <mwhudson> yes
[04:25]  * infinity wonders if we could stuff the symlinks in there to fix the current situation while we work on the grander plan.
[04:25] <mwhudson> it will become an almost stub that depends on gccgo and ships a symlink when golang-defaults gets uploaded
[04:25] <mwhudson> yeah, that would be doable
[04:26] <infinity> I don't know what all needs linking.  You have a mapping somewhere?  I guess you must for golang-defaults.
[04:27] <infinity> Not that I'm against us doing this correctly very soon, but it's been a looooong day, and I'd rather just see lxd build. :P
[04:27] <mwhudson> https://git.launchpad.net/~mwhudson/+git/golang-defaults/tree/debian/golang-go.links.gccgo
[04:29] <mwhudson> infinity: hacking up a change now
[04:29] <mwhudson> is there a bug filed?
[04:29] <infinity> mwhudson: Nope.
[04:29] <infinity> Well, not that I know of.
[04:29] <infinity> Just an angry little Swiss man.
[04:30] <mwhudson> testing http://paste.ubuntu.com/15469992/ now
[04:30] <stgraber> :)
[04:30] <mwhudson> oh ffs quilt
[04:30] <mwhudson> try http://paste.ubuntu.com/15469995/ instead
[04:31] <mwhudson> first hunk for testing only, obv
[04:31] <stgraber> that's much more readable :)
[04:31] <infinity> mwhudson: I assume amd64 is your fake powerpc for local testing? :P
[04:31] <mwhudson> yeah
[04:31] <mwhudson> that didn't work
[04:31] <stgraber> s/deb/debian/ ?
[04:32] <infinity> mkdir -p deb/golang-go/usr/bin/go ? :P
[04:32] <stgraber> well, that's wrong too ;)
[04:32] <infinity> s/deb/debian/ and perhaps go shouldn't be a directory.
[04:32] <stgraber> that's a lot of wrong for such a tiny diff :)
[04:33] <infinity> stgraber: You try typing upside-down.
[04:33] <stgraber> infinity: you managed it for a while :)
[04:33] <infinity> mwhudson: Oh, also, -6, not -5 ...
[04:33] <infinity> That really is a lot of wrong in a small diff.
[04:34] <mwhudson> infinity: life is happening here
[04:35] <infinity> mwhudson: I can only imagine. :)
[04:43] <mwhudson> infinity, stgraber: ok http://paste.ubuntu.com/15470049/ should be non-hilariously broken
[04:43] <infinity> mwhudson: That looks more plausibly correct indeed.
[04:44] <infinity> mwhudson: Fire away.
[04:45]  * stgraber test builds + test installs on powerpc
[04:46] <mwhudson> infinity: one of you will have to do the actual launching
[04:46] <infinity> mwhudson: Oh.  I'm sure we can manage that.
[04:46] <stgraber> yeah, I'll sponsor once the test build is done
[04:46] <infinity> stgraber: When you've confirmed it DTRT, sponsor away, and I'll accept.
[04:46] <infinity> Jinx.
[04:46] <mwhudson> i suspect you've both done one or two uploads
[04:46] <infinity> mwhudson: Ish.
[04:47] <stgraber> root@test:~/test# go version
[04:47] <stgraber> go version go1.6 gccgo (Ubuntu 6-20160319-0ubuntu1) 6.0.0 20160319 (experimental) [trunk revision 234350] linux/ppc
[04:47] <stgraber> root@test:~/test#
[04:47] <stgraber> pretty
[04:48] <mwhudson> \o/
[04:48] <infinity> stgraber: What timezone are you in right now?
[04:49] <stgraber> eastern
[04:49] <stgraber> but mostly working pacific-ish
[04:49] <infinity> stgraber: The latter was what I was asking.  Physical location is meaningless. :P
[04:50] <infinity> stgraber: So, we're probably about lined up.  I guess we can both babysit lxd/lxcfs, and the last man standing can trigger the ubuntu-server build.
[04:50] <stgraber> yep, hopefully the adt runners aren't too busy
[04:50] <infinity> They're empty.
[04:51] <infinity> stgraber: Oh, feel free to unblock both.  Your upload, you can do the paperwork.
[04:52] <infinity> Err, unblock all three, I guess, including golang.
[04:52] <infinity> If golang would be blocked.
[04:52] <infinity> Maybe not.
[04:52] <infinity> I dunno.
[04:52] <stgraber> uploading
[04:53] <stgraber> infinity: apparently none of them are in the big block of doom
[04:53] <infinity> Huh.
[04:53] <stgraber> that's convenient but also maybe a bit worrying
[04:53] <infinity> That's a mistake.
[04:53] <infinity> But okay.
[04:54] <infinity> Oh.  I may have missed server in the block.
[04:55]  * infinity fixes.
[04:55] <stgraber> oh and I need to hint lxc through too, debci failed again, that testsuite is so racy...
[04:55] <mwhudson> the blocks are based on binary package name, right?
[04:56] <infinity> mwhudson: No, source.
[04:56] <mwhudson> hm, then you may want to do something pre-emptive around the golang-1.6 gubbins
[04:56] <infinity> golang's not on any media.
[04:56] <mwhudson> oh right
[04:57] <infinity> Ugh.  Am I really going to upload d-i three times today?  Yes, other Adam, I think you are.
[04:58]  * mwhudson afk for a bit
[04:59] <stgraber> pushed a skiptest for lxc (really need to get pitti to figure out wth is going on with the debci adt) and pushed an unblock for lxc, lxd, lxcfs and golang
[04:59] <stgraber> so if I didn't screw up the version numbers, britney should be happy
[05:22] <infinity> Alright, rebuilding the world except for lubuntu and server.
[05:22] <infinity> And going to go watch some tee vee.
[05:46] <infinity> Hrm.
[05:46] <infinity> ubuntu-archive@snakefruit:~$ /home/ubuntu-archive/ubuntu-dev-tools/seeded-in-ubuntu zygrib
[05:46] <infinity> /usr/lib/python2.7/dist-packages/lazr/__init__.py:19: UserWarning: Module devscripts was already imported from /home/ubuntu-archive/python/devscripts/__init__.pyc, but /usr/lib/python2.7/dist-packages is being added to sys.path
[05:46] <infinity> stgraber: Any idea what that vomit's all about?
[05:47] <infinity> (it's breaking auto-accept)
[05:47] <stgraber> refresh ubuntu-dev-tools maybe? I'm not getting this on my system
[05:48] <stgraber> oh, snakefruit is still 12.04, fun
[05:49]  * stgraber fixes
[05:49] <infinity> Erk.
[05:49] <infinity> Shouldn't have done that pull.  Conflicts.
[05:49] <Skuggen> infinity, rbasak: I'm up! What'd I miss?
[05:51] <infinity> Skuggen: A bunch of build failures.  The only really interesting one is powerpc failing due to upstream using ancient __sync builtins instead of __atomic
[05:51] <stgraber> infinity: are you fixing lpapicache.py now?
[05:52] <Skuggen> infinity: This is still the current state? https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.11-0ubuntu1
[05:53] <stgraber> infinity: dropping that MERGE-SOURCE line should do the trick, but vi is telling me someone is busy editing it already :)
[05:53] <infinity> stgraber: I was fixing. :P
[05:54] <infinity> stgraber: Should be happy now I think.
[05:54] <stgraber> infinity: well, good news, seeded-in-ubuntu is happy now
[05:54] <infinity> Skuggen: No, I've got a WIP here, I'll play with it more tomorrow.
[05:54] <stgraber> doesn't even need my gross workaround (configuring python-warning to hide all warnings)
[05:54] <infinity> \o/
[05:55] <stgraber> ^ was that an auto-accept?
[05:55] <infinity> It was.
[05:55] <stgraber> cool
[05:55] <infinity> And lxd built.
[05:55] <infinity> Things are coming together.
[05:56] <stgraber> oh, apparently you were better at watching golang-go than I was, that thing took forever to publish
[05:56] <Skuggen> infinity: Ah, nice. For the platforms that were/will be fixed, do you think you could make some notes of anything that needs to be fixed upstream?
[05:56] <Skuggen> I know we're working on some of these platforms, but except arm64, which we just got, we don't really have the hardware
[05:58] <infinity> Skuggen: http://paste.ubuntu.com/15470483/ <-- That should fix everything but powerpc.
[05:58] <infinity> Skuggen: powerpc will be more involved, due to your using obsolete atomics.
[05:58] <infinity> Skuggen: The WITH_LIBEVENT=system is (a) a saner packaging default anyway, but (b) necessary on arm64 because your bundled libevent is broken on arm64.
[06:00] <stgraber> oh, guess I should drop edubuntu from the crontab (except for trusty)
[06:01] <Skuggen> infinity: I'll pass it on, thanks
[06:01] <infinity> stgraber: You guys have definitely decided it's dead?
[06:01] <pishuilu> infinity: Hello, can you help me? approve the upload of ubuntukylin-default-settings package.
[06:01] <infinity> pishuilu: I can indeed help.
[06:01] <stgraber> infinity: for 16.04, yeah, then we're giving a chance for whoever to pick it up by 17.10 (so we can have a 18.04), if nothing happens by then, we'll start doing package removals
[06:01] <pishuilu> infinity: Thank you.
[06:02] <infinity> pishuilu: Is that's a ini-style file, your diff is wrong.
[06:05] <infinity> pishuilu: You shouldn't have two stanzas for [com.canonical.Unity.Launcher]
[06:05] <infinity> pishuilu: All the keys for that item should be in the same block.
[06:05] <infinity> stgraber: Sadness.  The end of an era.
[06:06] <pishuilu> infinity:  OK ,thank you. I change it now.
[06:06] <stgraber> infinity: yeah, it's pretty sad though it's been just highvoltage and I for a few years now and we clearly don't have enough time to put in it, so we'd rather spend the little time we have to do the 14.04 maintenance than ship a broken 16.04 that we'd have to deal with for 5 years...
[06:07] <infinity> stgraber: Yeahp, understood.  Would be good if you could find new blood.
[06:07] <infinity> (ideally someone with an actual itch to scratch, like a school admin with a deployment)
[06:08] <stgraber> yep
[06:08] <infinity> It's so very hard maintaining software you don't actually use.
[06:09] <infinity> stgraber: That reminds me that we (the TB) need to poll the rest of the flavours for their LTSness.
[06:09] <stgraber> and yeah, we're both happy to sponsor the uploads of anyone who wants to take the project over, then once they understand how everything works, we'd make them Edubuntu Council member and that'd be the beginning of a new era. Whether that will happen, I have no idea though...
[06:09] <infinity> stgraber: I think trusty worked out okayish with everyone being 3-5yrs, but some people clearly didn't understand how much work they were signing up for. :P
[06:10] <stgraber> I had a couple of folks replying to my e-mail saying they'd be interested but are currently way too busy themselves (which isn't a great sign)
[06:10] <stgraber> infinity: ah yeah, that's a good point. Maybe some folks don't want to maintain their stuff for 5 years anymore :)
[06:17] <infinity> stgraber: Looks like that's all going to migrate, I'll watch an hour of TV and then trigger server before I crash.
[06:21] <stgraber> infinity: yep, everything looks good
[06:21] <pishuilu> infinity: Sorry, need to trouble you again. I upload ubuntukylin-default-settings package again.
[06:45] <pishuilu> infinity: Are you still here?
[06:47] <pishuilu> Hi everyone ,who can help me approving the upload of ubuntukylin-default-settings package? Thanks!
[07:10] <pishuilu> Thanks!
[09:23] <davmor2> cjwatson: I not it's not your realm anymore but you are the only person I can think of that might know. The EFI menu can it display info like the version of the distro so it isn't so black and uninformative
[09:24] <davmor2> currently it just says the gnu grub version
[10:08] <bdrung_work> hi, do i need a FFe for https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1560405 or can i just sync that bugfix release?
[10:50] <cjwatson> davmor2: Maybe cyphermox can help you.
[10:51] <davmor2> cjwatson: no worries he was going to be my next ping later on
[12:28] <cyphermox> davmor2: an interesting question.
[12:40] <davmor2> cyphermox: the reason I ask is if you have a bunch of install that menu give no indication of the version of ubuntu so it is the same from 14.04 through meaning you have to boot it so far to figure out if you have the right image
[12:57] <rbasak> Skuggen: can I leave the powerpc FTBFS to between you and infinity to resolve please? I need to task switch.
[12:57] <rbasak> Skuggen: are you happy for me to push infinity's other changes to Debian VCS?
[13:15] <Skuggen> rbasak: I'm not sure how much I can be online this afternoon, since I'll be on the train for 6-7 hours, but I'll try to follow up on it
[13:15] <Skuggen> The changes look fine for the Debian VCS, yeah
[13:41] <cyphermox> davmor2: ok, so we'd need to come up with a simple graphical theme that replaces that version text with something else (like what's in .disk/info for instance)
[13:42] <cyphermox> then we'd have the release name *and* which daily you're using
[13:44] <flexiondotorg> cyphermox, I've found an RC issue in Ubuntu MATE. Working on it now. I will require a new package upload and iso rebuild
[13:44] <flexiondotorg> Given the above, could you update ubuntu-mate-meta please, which include a trivial change.
[13:45] <flexiondotorg> cyphermox, By RC, I mean Ubuntu MATE is uninstallable.
[13:45] <cyphermox> ok
[13:45] <flexiondotorg> The ubuntu-mate-meta update won't fix this issue. But does need doing at some point and now seem appropriate.
[13:46] <cyphermox> well should it not wait until your fix lands?
[13:46] <flexiondotorg> My fix will be in ubuntu-mate-welcome
[13:47] <flexiondotorg> So please update ubuntu-mate-meta so that when new ubuntu-mate-welcome is uploaded everything is ready for an iso rebuild.
[14:04] <cyphermox> flexiondotorg: what change should I expect?
[14:05] <flexiondotorg> cyphermox, uvcdynctrl is removed.
[14:05] <cyphermox> ok
[14:06]  * flexiondotorg thanks cyphermox while frantically knocking Welcome into shape.
[14:17] <davmor2> cyphermox: nice so it is possible then, shall I write a bug up for it then?
[14:30] <flexiondotorg> cyphermox, infinity Can you unblock mate-tweak, mate-dock-applet and mate-settings-daemon please?
[14:30] <cyphermox> sorry, EACCESS
[14:31] <flexiondotorg> cyphermox, What that comment for me? If so, I don't understand.
[14:31] <cyphermox> I don't have permissions to do that ;)
[14:31] <flexiondotorg> Ah.
[14:34] <flexiondotorg> cyphermox, So if I've prepared a new ubuntu-mate-welcome, you can upload?
[14:44] <flexiondotorg> cyphermox, If you're able - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1560517
[14:46] <flexiondotorg> Laney, please can you unblock mate-tweak, mate-settings-daemon and mate-dock-applet?
[14:47] <flexiondotorg> Laney, I've a release critical issue in ubuntu-mate-welcome, so need to rebuild anyway.
[15:54] <flexiondotorg> Laney, infinity Ubuntu MATE is uninstallable. I've got a fix. Could one of you upload and unblock the update package please?
[15:54] <Laney> flexiondotorg: In a minute
[15:54] <flexiondotorg> Laney, Sure.
[17:31] <Skuggen> infinity: We're working on a patch for the MySQL 5.7 build failure on powerpc
[17:32] <Skuggen> Or rather we have a patch, but are testing it
[17:40] <infinity> Skuggen: Oh, shiny.  Can I see?
[17:41] <Skuggen> Right, sorry :D
[17:41] <Skuggen> http://pastebin.ubuntu.com/15473221/
[17:46] <ryeng> infinity: It still hasn't been reviewed, but testing is in progress. I'm not sure if I can find a powerpc to test on. At the moment I'm just forcing the use of __atomic on other platforms and running test on those.
[17:47] <infinity> Skuggen: Shiny.  Only two comments: 1) __sync is deprecated, and you should be moving to prefer __atomic everywhere (once you've tested for regressions, etc), and 2) you'll need -latomic on some platforms (so need a 'MY_SEARCH_LIBS($symbol atomic LIBATOMIC)' at the top of configure.cmake.
[17:48] <infinity> ryeng: Happy to build and review on a real machine.  And see above.
[17:48] <Skuggen> For 1) I think it's just that since this is a bit of a rush-job with regards to review and testing it's a bit less risky to keep existing behavior when possibly
[17:48] <ryeng> infinity: __atomic is too new to drop __sync. We need it to build on platforms with old GCCs.
[17:48] <ryeng> infinity: But having both is an option.
[17:49] <infinity> ryeng: Right, not suggesting you drop sync, just that you move to prefer atomic, once you've validated it.  Absolutely agree that validation doesn't happen in a day, and sticking with what you know is better for today.
[17:50] <infinity> (That said, on newer GCCs, __sync is implemented using wrappers around __atomic anyway, so...)
[17:50] <infinity> And highly recommended to switch to __atomic, since it gives you more control over memory ordering and such, which the __sync wrappers don't.
[17:51] <ryeng> infinity: In future versions we'll switch to C++11 atomics.
[17:51] <infinity> ryeng: \o/
[17:51] <ryeng> infinity: The patch I've made now is based on a patch that did exactly as you suggested in 1). But the patch didn't make it into 5.7 before freeze ...
[17:52] <ryeng> After that it was just dropped since __sync works and we didn't want to do that kind of fix after release without a good reason.
[17:53] <infinity> ryeng: Right.  All sounds reasonable to me.
[17:53] <jcastro> Hi! Our team needs help sorting out: https://bugs.launchpad.net/ubuntu/+source/charm-tools/+bug/1546776
[17:58] <wxl> any reason why lubuntu only has alternates for beta2?
[18:13] <infinity> wxl: No idea.
[18:13] <infinity> wxl: To be fair, desktop ones would be broken anyway, but lemme look.
[18:13] <wxl> infinity: whatcha mean? ubiquity issues?
[18:14] <infinity> wxl: *nd*
[18:14] <infinity> nod, too.
[18:15] <wxl> okie dokie.
[18:16] <infinity> wxl: Generating a (broken) set anyway, so they don't get lost when it's time for a respin.
[18:17] <wxl> infinity: thanks
[19:04] <willcooke> hi release team.  I've just put a MP up for the slideshow (https://code.launchpad.net/~willcooke/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/289826) with updated screenshots and a slight change of text on one of the slides.
[19:04] <willcooke> I'm emailing the translators mailing list right now
[19:04] <willcooke> Can you tell me if I need a FFe for the updated slideshow?
[19:05] <infinity> willcooke: Nope, slideshow is expected to land late.
[19:06] <willcooke> thanks infinity
[19:06] <willcooke> cyphermox, ^
[19:06] <infinity> willcooke: In fact, we usually fix it ourselves when others fail to land it at all. :P
[19:06] <willcooke> ha!
[19:06] <willcooke> Hopefully this offsets all the other damage I've been doing ;)
[19:06] <infinity> ;)
[19:07] <cyphermox> willcooke: just being extra cautious, I'll merge it and upload now
[19:07] <willcooke> cyphermox, would you double check it for me, just to be sure.  I /think/ I've got it all OK, but I was a bit worried about some of the sym links
[19:07] <willcooke> I dont think I change anything, but ya know...
[19:07] <cyphermox> yeah I was just checking...
[19:08] <infinity> willcooke: There's a handy-dandy test script in the source.
[19:08] <willcooke> also I noticed a lot of blurb was removed from the pot files
[19:08] <willcooke> I used make pot and make test ubuntu :)
[19:08] <willcooke> the test script is ace
[19:09] <cyphermox> yay
[19:11] <willcooke> oh
[19:11] <willcooke> cyphermox, hold on a sec... I've just thought of something
[19:11]  * infinity goes back to arguing with ubiquity.
[19:11] <cyphermox> arguing?
[19:13] <slangasek> I assume one argues with ubiquity by passing it different arguments on the commandline
[19:15] <cyphermox> slangasek: do you prefer automatic or debug meat?

[19:16] <cyphermox> ubiquity can be automatic or debug
[19:16] <slangasek> but "meat"?
[19:16] <cyphermox> like chicken? white or dark meat?
[19:17] <slangasek> you mean ubiquity isn't vegan!?
[19:20] <infinity> I think it's cannibalistic.
[19:21] <cyphermox> ubiquity definitely isn't vegan
[19:28] <Skuggen> infinity: http://pastebin.ubuntu.com/15474163/ for your second comment. We don't have a box to test this on
[19:33] <flexiondotorg> infinity, As rebuilds are going to happen anyway could you please unblock mate-tweak, mate-dock-applet and mate-settings-daemon?
[19:43] <infinity> Skuggen: I can test sometime later.  A bit flat out right now.
[19:44] <infinity> Skuggen: That's indeed what I had in mind.  I suspect that, with your other patch, should DTRT.
[19:45] <infinity> Skuggen: (pointer to your other patch again?  I'm losing context rapidly)
[19:45] <Skuggen> infinity: http://pastebin.ubuntu.com/15473221/
[19:45] <infinity> Skuggen: Ta.
[19:46] <infinity> Skuggen: I'll give them both a spin $later, when I'm not wrestling an installer.
[19:46] <Skuggen> Sure thing, thanks :)
[19:46] <Skuggen> We'll at least get some internal review on it, as well
[19:48] <infinity> Skuggen: As written, it should be a 0-byte change to final binaries for arches with __sync.  Assuming all involved here can read and aren't missing something. :)
[19:51] <Skuggen> I've been burned by that assumption before :D
[19:51] <Skuggen> But yeah, it's not terribly complicated
[21:37] <Logan> could someone please reject the plank syncs per the last comment in Bug 1558592?
[21:41] <slangasek> Logan: it's suggested to hold it back; any reason not to let it sit in the unapproved queue for now?
[21:41] <Logan> hmm, just in case someone approves it by accident, I guess
[21:41] <slangasek> I mean, aside from the obvious risk of someone mis-accepting it, but I guess the risk depends on how long it'll take to fix bamf?
[21:48] <Logan> right, that's true
[21:48] <Logan> not sure what the timeline is for that
[22:18] <infinity> Skuggen: Bah.  All went well on PPC until it got to storage/innobase also wanting __sync
[22:19] <Skuggen> Gah
[22:23] <infinity> Skuggen: The build (with link to log) for your amusement: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/9387908
[22:29] <Skuggen> Guess we'll need a similar patch for innobase
[22:30] <infinity> Skuggen: Looks like.  That's all new code, too.  I'd say something about new code using old prototypes, but I understand you have a company mandate to support people building your software on UNIXes all the way back to 1975. :P
[22:31] <Skuggen> Yeah :)
[22:32] <infinity> Skuggen: if it's any consolation, it looks like my stab-in-the-dark packaging fixes solved things for all the other arches.
[22:33] <infinity> At least, none of them have failed yet. :P
[22:33] <infinity> https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+sourcepub/6224858/+listing-archive-extra
[22:40] <Skuggen> infinity: I'm also seeing it used in the innodb_memcached plugin
[22:45] <Skuggen> infinity: As far as I can see all the errors in that log
[22:45] <Skuggen> Er, sorry. * can be traced to a single use of __sync
[22:45] <infinity> Skuggen: Certainly, but then the build dies.  So hard to say where it goes when that one's fixed. ;)
[22:47] <Skuggen> Yeah, storage/innobase/include/os0atomic.h has a bunch of __sync usage
[22:47] <knome> infinity, i take it we're not going to see the base stuff for b2? :)
[22:48] <infinity> knome: You might but it'll probably be shortly after. :/
[22:48] <knome> infinity, it's ok; as long as we know what to expect. we're likely postponing the "official" base release until .1 so we can have a bit more time to test anyway
[22:49] <infinity> knome: Well, it might Just Work.  Here's hoping.
[22:50] <infinity> knome: But I'm obviously not going to penalise you for my lack of time.  If you want to release it with Final (if it's ready), let's do it.
[22:50] <knome> likely not as it's this far away; we wanted this to be ready earlier because we want to make sure the quality is good, not because "we just want it" :)
[22:51] <infinity> knome: Yup, understood.  Though, in theory, with the two base product just being cut down versions of their fatter brothers, it might not take much iteration.  We'll see.
[22:52] <knome> at least in our case, it's not just "let's remove this and it's done", it's a bit more tweaking
[22:53] <knome> but yeah, i understand what you are saying
[22:53] <knome> you can tell that to our QA team though and see what they have to say ;)
[22:53] <infinity> ;)
[22:53] <infinity> QA people pretty much just shoot you for adding another product period, even if it's the same ISO renamed.
[22:53] <infinity> Because exploding test matrices sucks.
[22:54] <knome> sure, but they also do valuable work and it's sane that they require a certain amount of tests
[22:54] <infinity> I need to go grab some $whatever_meal_this_is_maybe_breakfast_i_dunno while all my beta bugfixes build.
[22:55] <knome> bon appetit!
[22:55] <infinity> knome: I wasn't at all implying they're whining without cause.
[22:55] <knome> :)
[22:56] <Skuggen> infinity: We'll try to work out the innobase issues, hopefully make another patch :)
[22:57] <infinity> Skuggen: My hero.
[22:58] <infinity> Skuggen: The upshot of this is that moving to the new prototypes is the Right Thing to do anyway.  But no one likes being rushed on something like that either. :/
[22:59] <Skuggen> Yeah, we (and by we I mean other people :P) are kind of patching this in the blind since we don't have the hardware to test on
[23:06] <Ukikie> infinity: And right now, the current core images have a broken installer anyway. :P
[23:12] <doko> why does golang-defaults (- to 2:1.6-1ubuntu3) show so many unsatisfiable Depends?
[23:14] <slangasek> doko: main vs. universe
[23:14] <slangasek> ?
[23:14] <slangasek> yes - the existing golang binary is in main
[23:15] <slangasek> this is xnox's recent change to make p-m respect component-mismatches, as announced on ubuntu-release
[23:15] <doko> ohh, didn't hit reload
[23:16] <doko> I'm not subscrubed to ubuntu-release
[23:16] <doko> ok, promoting
[23:17] <doko> hmm, subscribed by both server and foundations ...
[23:17] <knome> doko, you should totally subscrub :P
[23:18] <doko> slangasek, convince -server to subscribed?
[23:18] <slangasek> doko: or I can just subscribe them?
[23:19] <doko> sure, and I assume, we want foundations there too. golang-1.6, golang-defaults, and golang-1.6-race-detector-runtime
[23:22] <slangasek> doko: done, for both teams
[23:23] <doko> ta, promoted