[00:08] <derEremit> Hi all
[00:08] <derEremit> should ubuntu webapps like http://developer.ubuntu.com/web/overview/
[00:08] <derEremit> still work in trusty
[00:09] <derEremit> i get: Proxy: getUnityObject called with version 1
[00:09] <derEremit> Uncaught Error: not enough arguments
[00:10] <derEremit> in unity-api-page-proxy-builder-gen.js
[00:30] <sarnold> pitti: are the trusty retracers alive and well? this bug report has been waiting for retracing for seven hours: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1288852
[00:32] <derEremit> ok, tested in firefox also, used to work, now i get the message if i would like to add integration but then nothing happens
[00:35] <derEremit> https://bugs.launchpad.net/unity-chromium-extension/+bug/1277126
[00:54] <derEremit> can someone confirm that it's also broken in firefox on trusty
[01:07] <doko> infinity, is the chromium-browser autopkg test really still running, or could you override it?
[01:53] <teward> The MIR checklist points to liblua5.1 as bad...  Am I to assume that includes other non-Lua Lua compilers as well (like luajit), or no?
[02:04] <RAOF> teward: You're talking about the ngnix MIR? If so, it's that liblua5.1 isn't supported (liblua5.2 is). So if there is another Lua runtime in the supported seed that the ngnix lua module works against then that would be acceptable.
[02:04] <teward> RAOF: you've avoided my actual questoin
[02:04] <teward> if you've read the nginx MIR, you'd see sarnold already explained this
[02:04] <teward> and that sarnold and infinity explained this to me in this channel even
[02:05] <teward> you've ignored my actual question, which is, does this also include other Lua interpreters not provided by libljuaX.Y (where X and Y are numbers)
[02:05] <teward> (such as libluajitX.Y)
[02:05] <RAOF> I'm still not sure what your question is, sorry.
[02:05] <teward> then i'll wait for sarnold
[02:06] <teward> or, unless you want me to talk for a bit?
[02:06] <teward> (explain the background of this, really)
[02:06] <RAOF> Sure.
[02:07] <teward> the third-party Lua module is part of the non-main packages (nginx-extras).  It requires Lua 5.1, or an interpreter that speaks Lua 5.1.  The upstream for that module have already looked and said that it will not be able to build ever against 5.2
[02:07] <teward> and that they will not support 5.2 either
[02:07] <teward> they did suggest either static-linking against 5.1, or try something like LuaJIT instead
[02:07] <teward> problem is, I have no idea if LuaJIT is supported or not, nor if that conflicts as it too speaks 5.1
[02:08] <RAOF> Ah.
[02:08] <teward> my question is whether, IF this builds against libluajit-5.1-dev... would that be satisfactory
[02:08] <teward> because the only other alternative is to drop the lua module
[02:08] <teward> (which won't exist in nginx-core, the package that would end up in main, anyways.)
[02:09] <RAOF> libluajit-5.1-dev is also in universe, so ngnix couldn't build-depend on it.
[02:09] <teward> the moment of truth is right now, RAOF, i'm sbuild-ing this.
[02:09] <teward> RAOF: then the MIR is permanently blocked and I may as well just reproduce a separate source package for nginx-core
[02:09] <teward> because we'd *have* to drop Lua and everyone else will be... um...
[02:09] <teward> "extremely dissatisfied"
[02:10]  * teward yawns
[02:10] <teward> i should not be working on code at 9:10PM but meh
[02:10] <RAOF> Heh.
[02:10] <teward> it looks like it builds either way, but meh
[02:11] <RAOF> Why does the lua module not support the ~2 year old Lua 5.2 release? (/me doesn't have any real domain knowledge here)
[02:11] <teward> RAOF: ask the upstream people
[02:11] <teward> https://github.com/chaoslawful/lua-nginx-module/issues/343
[02:12] <teward> RAOF: what I think could be a satisfactory solution is to drop the Lua module from the package, then burn the bridges behind us, as i'll still maintain the PPAs anyways
[02:12] <teward> and I assume liblua5.1 will still exist in trusty even though it's not going to be supported in trusty?
[02:13] <RAOF> Yeah, it's unlikely to be removed.
[02:13] <RAOF> Also, it sounds like Lua is a terrible choice for an embedded language? The language significantly changes between Lua 5.1 and Lua 5.2?!
[02:13] <teward> that's what sarnold and infinity said
[02:14] <RAOF> :)
[02:14] <teward> RAOF: if it's unlikely to be removed from Trusty, then that should still suffice, the people who need Lua can go use the PPA version which I will continue to maintain anyways
[02:14] <teward> while still satisfying the MIR requirements by dropping the lua module
[02:15] <teward> 'course, i'd like sarnold and rbasak to voice their opinions on that solution
[02:15] <RAOF> teward: Sounds reasonable. You could also ask if libluajit is MIR-able.
[02:16] <RAOF> teward: Since it seems like that's actively maintained upstream?
[02:16] <teward> RAOF: that's outside my purview :/
[02:16] <RAOF> Which would be one of the problems with liblua5.1; last release seems to be in 2012.
[02:17] <teward> RAOF: my... preference... would be to just maintain things that DON'T require additional maintenance
[02:17] <teward> but that's Debian's decision to add it
[02:17] <teward> not mine
[02:17] <RAOF> teward: Well, you should mention that it builds (and runs?) against libluajit-5.1-dev, and that libluajit is maintained upstream.
[02:18] <teward> RAOF: all testing in due time
[02:18] <teward> it's still building in sbuild (i386; amd64)
[02:18]  * teward doesn't test-build for other architectures
[02:18] <teward> it *looks* like it builds
[02:18] <teward> but i don't use the lua module so meh
[02:18] <teward> the question is if it starts
[02:18] <teward> if it does without SEGV then meh
[02:19] <teward> hmm, where the heck did my trusty VM go
[02:22] <teward> RAOF: any idea where i can get a trusty image?
[02:22] <teward> :/
[02:22] <teward> my VM exploded itself :/
[02:22] <RAOF> teward: The autopkgtest build scripts pull a cloud VM image...
[05:46] <pitti> Good morning
[05:47] <Unit193> Howdy.
[07:56] <fishor> slangasek, so far i know pipeligt will add symlink in plugins directory and it uses NAPI interface
[07:56] <fishor> i can't say more, since i have no more idea then you. Everything i know, wine will start together with update manager if firefox was not previously started
[09:36] <fishor> slangasek, hm... right now i can reproduce it only with empathy, not with update manager.
[09:52] <doko> jibel, pitti: need to get gcc-4.8 into trusty, chromium-browser autopkg test still running
[09:53] <pitti> doko, jibel: fixing the history files
[09:53] <pitti> doko: FYI, jibel is working on fixing this for good
[09:53] <jibel> pitti, done
[09:54] <doko> pitti: and the other thing I'd like to see migrating is readline6, independent of the python3.4 autopkg test
[09:54] <doko> and then starting the test rebuild
[09:54] <tkamppeter> Anyone with knowledge about Debian package download servers around?
[09:54] <pitti> jibel: I edited trusty-proposed_amd64_chromium-browser.20140306-174838.state and results.history, that right?
[09:55] <jibel> pitti, it is
[09:55] <pitti> doko: right, the python3.4 failure looks like a problem with the new python3.4 itself, not due to libreadline
[09:56] <xnox> tkamppeter: what are you after?
[09:56] <pitti> jibel: can we forge this in the history file? the release team AFAIK can only override the python3.4 test itself, not just that test result for libreadline
[09:57] <pitti> python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1
[09:57] <pitti> python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1 readline6 6.3-1ubuntu1
[09:57] <pitti> jibel: ^ i. e. set it to PASS in the second line, but keep the first?
[09:57] <jibel> pitti, 3661:python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1 readline6 6.3-1ubuntu1
[09:57] <jibel> line 3661
[09:58] <pitti> jibel: I set l 3661 to PASS, keeping the FAIL for python3.4 itself
[09:58] <pitti> doko: ok, should be set; I'll check britney in ~ 30 mins
[09:58] <jibel> pitti, correct
[09:58] <tkamppeter> znox, at Epson they have .deb packages of printer drivers, for auto-download with apt-get. Now the guys are complaining that on their server are too may 404 errors (900000/day) and this is slowing down the server, the problem seems to happen with http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/main/i18n.
[09:58] <doko> thanks!
[09:59] <pitti> err, what, znox? is there an ynox as well, putting Dimitry into all three dimensions?
[09:59] <tkamppeter> xnox, ^^^
[09:59] <pitti> (TGIF!)
[10:01] <xnox> tkamppeter: yeah, that's a known problem, so apt does query translation files of package data thus generating a tonne of 404s queries. I think on launchpad ppas it was suggested to short-circuit queries to i18n paths and return 404 to client on frontend without hiting the disk.
[10:02] <xnox> tkamppeter: or on the repository side, generate empty files there (or some such) such that apt "caches" them and thus does not request/404 them all the time.
[10:02] <xnox> maybe wgrant can give better advice here.
[10:03] <OdyX> tkamppeter: the good solution to that is to release this as redistributable and let good packagers distribute that in the distibutions properly
[10:04] <tkamppeter> wgrant, hi
[10:06] <OdyX> tkamppeter: I'd not even request full source, just redistributability (for non-free)
[10:07] <xnox> tkamppeter: wgrant is end-of-week by now, he is in Australia.
[10:09] <OdyX> tkamppeter: get Epson fix their license please: https://lists.debian.org/debian-legal/2012/12/msg00011.html
[10:10] <OdyX> (if you're talkin to them)
[10:12] <tkamppeter> xnox, would it be enough to create an empty http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/main/i18n/Translation-en file?
[10:13] <xnox> tkamppeter: i think it should be. to test mirror that repository to /var/www/html and try out against local apache at 127.0.0.1 and check the logs =/
[10:17] <tkamppeter> xnox, I am trying with the OpenPrinting web server now, which was also missing this directory, and it seems only adding the empty i18n directory makes "sudo apt-get update" faster.
[10:23] <pitti> doko: both propagated now
[10:55] <wgrant> tkamppeter, xnox: This really needs a fix in apt to not blindly try to download every possible translation.
[10:56] <wgrant> It currently tries to fetch Translation-en.xz, then that 404s so it tries Translation-en.lzma, Translation-en.bz2, Translation-en.gz, Translation-en, then it finally gives up
[10:56] <wgrant> I don't know how to make it stop
[10:56] <wgrant> Translation-* really should only have ever been looked at if they appeared in an index.
[10:58] <tkamppeter> wgrant, so for best server performance I should create empty Translation-en.xz in all i18n directories on the servers?
[10:59] <wgrant> tkamppeter: Plus Translation-$LANG.xz for each possible client language :/
[10:59] <wgrant> It's possible that apt will use TranslationIndex if it's there, but I believe it's deprecated.
[11:00] <wgrant> Possibly it'll now check if there's any Translation-* at all in Release?
[11:00] <wgrant> That would seem like a reasonable thing to do in future, even if that's not the current behaviour.
[11:05] <tkamppeter> wgrant, I hope that this does not cause all deb servers on the world hanging in 404s most of the time.
[11:06] <wgrant> tkamppeter: It causes serious delays on HTTPS apt repos, but for unencrypted HTTP it's not usually too bad.
[11:08] <wgrant> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1171047
[11:16] <mwhudson> are the estimated 14.04.X point release dates listed somewhere?
[11:17] <xnox> mwhudson: not that i see at https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[11:17] <mwhudson> right
[11:18] <xnox> mwhudson: maybe it makes sense to have vUDS session to discuss it.
[11:19] <mwhudson> that might be overkill
[11:19] <mwhudson> also vuds is entirely inhumanely timed for me :)
[11:19] <mwhudson> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule has point releases every six months, starting the august after release
[11:21] <tkamppeter> wgrant, xnox, thank you very much.
[11:23] <xnox> mwhudson: true, but it kind of depends on the .1 timing. Precise .1 was much longer than usual.
[11:24] <xnox> mwhudson: imho lts point releases should be at .7/.1 cadence - half-way between .4/.10 cadence.
[11:25] <Laney> Compared to Hardy it was, but it was broadly the same as Lucid
[11:25] <mwhudson> xnox: ok
[11:26] <xnox> Laney: hardy was a good release, i liked it a lot. =)
[11:27] <Laney> it did have the best t-shirt
[11:31] <jamespage> mwhudson, I quite liked what the Ceph Developer Summit did
[11:32] <jamespage> they had one day that was better timed for APAC
[11:33] <infinity> mwhudson: I need to update the release schedule, but the theory is for point releases to be every 6mo, starting at ~3mo after release.  I don't think we need a UDS session for that.
[11:34] <mwhudson> infinity: coolio
[11:34] <infinity> mwhudson: Exact dates are a bit more flexible than normal releases, but the aim is to make sure they're well out of sync with normal releases, since it's the same people/resources.
[11:34] <mwhudson> that makes sense
[11:34] <mwhudson> so 14.04.2 might have the same kernel as 14.10, say
[11:35] <infinity> mwhudson: .2 will be the 14.10 kernel, .3 will be the 15.04 kernel, etc.  That's set in stone.
[11:35] <xnox> mwhudson: why "might"? it will, cause hwe packs start with .2 releases.
[11:36] <mwhudson> xnox: i don't know if .2 could use a newer kernel or something like that
[11:36] <mwhudson> but apparently i am wrong :)
[11:43] <diwic> pitti, hi, is usb-creator working for you in 14.04? It fails to both erase and create here.
[11:44] <pitti> diwic: I don't know off-hand, it's been some time since I used it
[11:44] <pitti> diwic: yes, erase fails with
[11:44] <pitti> WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util sfdisk doesn't support GPT. Use GNU Parted.
[11:44] <diwic> pitti, ok, do you think I should do anything about it (except filing bug 1289269 )
[11:45] <diwic> pitti, okay, then we have at least three bugs :-/
[11:45] <pitti> oh, it doesn't hang here
[11:45] <pitti> this is an USB stick which I previously dd'ed the current image on
[11:45] <pitti> so supposedly that's how it got a GPT table
[11:52] <GunnarHj> Hi pitti!
[11:52] <pitti> hey GunnarHj
[11:53] <GunnarHj> pitti: I tend to think that the request in bug 1288843 is reasonable, even if there is a lack of official sources that support it. t_fmt_ampm is not normative in the same way as d_t_fmt and t_fmt, so as long as we set t_fmt_ampm without touching the other two it should be ok IMO.
[11:53] <popey> grr. twice today my x220 has locked up completely.
[11:53] <pitti> GunnarHj: yeah, maybe; I still like at least some semi-official references, like in major newspapers; I'm not sure how much proof upstream wants these days
[11:54] <GunnarHj> pitti: Historically they have been pretty picky, as you know much better than me. ;-)
[11:54] <pitti> GunnarHj: yes, but glibc maintainers changed a while ago
[11:55] <GunnarHj> pitti: But from a user perspective the result is not good: The UI offers the option to set 12h clock format, and it fails.
[11:56] <pitti> GunnarHj: yeah, that's certainly a bug in the config UI
[11:56] <pitti> GunnarHj: which should be fixed anyway; but I'm not opposed to adding some AM/PM format if there is some proof that whichever format is proposed is widespread and not just the knee-jerk invention of the reporter
[11:57] <GunnarHj> pitti: Or in the locales, depending on how you choose to look at it...
[11:57] <pitti> GunnarHj: well, e. g. in German there is no official format for AM/PM, so you couldn't "fix" it there
[11:57] <pitti> and inventing some incomprehensible abbreviations which nobody else understands doesn't help either
[11:58] <pitti> so it ought to be a wide-spread and recognizable format
[11:58] <GunnarHj> pitti: In this case there is a history of older bugs with some references. But I'll ask for references on this new bug.
[11:58] <pitti> i. e. if major newspapers/news sites/governmental sites use it, it's ok
[11:58] <pitti> GunnarHj: if we have some in dupes, that's fine of course
[11:58] <GunnarHj> pitti: dupes?
[11:59] <pitti> GunnarHj: or whatever you meant with "older bugs"?
[11:59] <GunnarHj> pitti: Aha.
[11:59] <pitti> GunnarHj: "dupes" == "duplicate bugs"
[11:59] <GunnarHj> pitti: Got it now. ;-)
[12:32] <cjwatson> xnox: Did you ever submit upstart-app-launch merge proposals for the changes you uploaded directly?
[12:33] <xnox> cjwatson: no, i don't think so.
[12:33] <xnox> cjwatson: looks like there were two. Should i make a manual branch with changelog/changes, or can ci-train sync up trunk at all?
[12:33] <cjwatson> xnox: Would you mind?  I have some upstart-app-launch changes I want to land myself, and that'll need to be sorted out
[12:33] <xnox> ok.
[12:33] <cjwatson> xnox: I'm not sure about changelog, you'd need to ask somebody who knows about ci-train
[12:34] <seb128> cjwatson, xnox: bonus point if you include the changelog in the mp, if you don't there is an option to force publication over it though
[12:35] <seb128> the "force publication option" would mean your changelog entry would be dropped of course
[12:37] <xnox> cjwatson: seb128: well, pushed this https://code.launchpad.net/~xnox/upstart-app-launch/sync-archive/+merge/209908
[12:37] <xnox> cjwatson: maybe set that one as pre-requisite and/or rebase on top of it?! (not sure)
[12:39] <cjwatson> xnox: I don't need to set it as a prereq, it'll be fine
[12:40] <cjwatson> xnox: Thanks
[12:45] <bonafide> Hallo, ich versuche meine Wiimote mit meinem PC zu pairen, aber bekomme immer  eine Fehlermeldung. Was kann ich tun?
[12:47] <bonafide> Sorry, I tried to pair my Wiimote but all I get is a error message. Bug is already reported. What can I do?
[12:52] <mdeslaur_> @pilot in
[13:13] <bonafide> Sorry, I tried to pair my Wiimote but all I get is a error message. Bug is already reported. What can I do?
[13:14] <bonafide> Im on Ubuntu 12.04.4. The error message is: "Setting up 'Nintendo RVL-CNT-01' failed"
[14:04] <ScottK> cjwatson: I've run into a conundrum about clamav on ppc64el and I think that removal may be appropriate.  In the last upload, I fixed a bug that had caused the test suite to not run since before the first ppc64el build and discovered it fails on (only) ppcd64el, giving me an impression that the ppc64el binaries don't actually work.  I've no idea how to deal with fixing it (nor hardware to test) and so I think removing the binary so it can
[14:04] <ScottK> migrate might be appropriate since I don't see it as a real regression.  Thoughts?
[14:05] <ScottK> Build log if you're interested: https://launchpadlibrarian.net/168490729/buildlog_ubuntu-trusty-ppc64el.clamav_0.98.1%2Bdfsg-2ubuntu1_FAILEDTOBUILD.txt.gz
[14:11] <cjwatson> ScottK: I'm OK in principle but there are several reverse-deps
[14:12] <cjwatson> clamsmtp, dansguardian, havp, libc-icap-mod-virus-scan, libclamunrar6, proftpd-mod-clamav, python-pyclamav
[14:14] <cjwatson> that seems like rather a lot to rip out
[14:14] <cjwatson> if you have any guesses I could puppet for you on an internal porter box?
[14:24] <ScottK> cjwatson: The only thing comes to mind is if you can go back and look at the diff for the last Hardy uploads, I had to disable (I think) the same functionality that is failing here, so an arch specific build option might be in order.  Other than that, no ideas at ail.
[14:26] <ScottK> I'm looking for it
[14:27] <ScottK> Here it is.
[14:27] <ScottK> ifeq ($(DEB_HOST_ARCH),lpia)
[14:27] <ScottK>   export enable_llvm=no
[14:27] <ScottK> endif
[14:27] <ScottK> cjwatson: ^^^ with lpia/ppc64el, of course.
[14:28] <ScottK> Put that right before config.status: configure
[14:30] <cjwatson> ScottK: ok, give me a minute to make sure I can reproduce the failure
[14:30] <ScottK> OK.  Good luck.
[15:15] <cjwatson> ScottK: Sorry for the delay; I was called away for urgent childcare.  That change fixes the build.
[15:15] <ScottK> No problem.  I know how that goes.
[15:15] <ScottK> cjwatson: Please go ahead and upload then.
[15:19] <cjwatson> ScottK: Done.
[15:19] <ScottK> Thanks.
[15:26] <pitti> xnox: you synced python-apt, right? would you mind terribly if I remove it again? it introduces regressions (like bug 1288171) and thus I can't land a new apport
[15:26] <pitti> remove from -proposed, I mean
[15:26] <ScottK> Since llvm itself FTBFS on ppc64el, I guess it's no surprise the embedded code copy in clamav didn't work either.
[15:27] <xnox> pitti: yeah, remove it. there aren't any pressing changes that we need from 0.9.3 to be honest.
[15:28] <pitti> xnox: ack; i. e. this was mostly a "no remaining Ubuntu changes" sign?
[15:28] <xnox> pitti: yeah.
[15:28] <pitti> xnox: ack, thanks
[15:31] <marcoceppi_> So, I'm attempting to patch 1223229 and I've submitted this patch to the precise package which is the only release of Ubuntu affected by the bug, https://code.launchpad.net/~marcoceppi/ubuntu/precise/charm-tools/lp1223229/+merge/209542
[15:31] <marcoceppi_> is there anything else I need to do for this? like ping someone or request somethign from somewhere
[15:37] <pitti> marcoceppi_: no, it's in the sponsoring queue
[15:38] <pitti> marcoceppi_: well, you need to set up the bug for SRU, i. e. add rationale and testing instructions
[15:38] <pitti> marcoceppi_: and it needs to be a public bug
[15:39] <marcoceppi_> pitti: cool, can do
[15:59] <ScottK> cjwatson: Is there a porters page or something for ppc64el where it might make sense to make a note that if someone fixes llvm on ppc64el, they should look at re-enabling it in clamav too?
[16:00] <mdeslaur_> @pilot out
[16:01] <mdeslaur_> udevbot: wake up
[16:06] <bdmurray> seb128: could you have someone look at bug 1289202?
[16:06] <seb128> bdmurray, tb issues in stable series are security's team
[16:09] <seb128> jdstrand, chrisccoulson: ^
[16:09] <udevbot> Error: "wake" is not a valid command.
[16:11] <jdstrand> seb128: I assigned to chrisccoulson. He'll take a look as part of the next update
[16:11] <seb128> jdstrand, thanks
[16:18] <cjwatson> ScottK: I'm not sure; infinity might know
[16:50] <jamespage> !regression-alert
[16:51] <jamespage> bug 1280941
[16:51] <jamespage> the latest 2013.2.2 release has a problem with the neutronclient we have in saucy
[16:51] <jamespage> not picked up during testing
[16:51] <jamespage> (obviously)
[16:52] <jamespage> upstream fix for neutronclient: https://github.com/openstack/python-neutronclient/commit/02baef46968b816ac544b037297273ff6a4e8e1b
[16:53] <infinity> jamespage: So, erm... What regression is this?
[16:54] <infinity> jamespage: saucy only has one version of python-neutronclient ...
[16:54] <infinity> Oh, it's neutron itself that broken neutronclient.  Check.
[16:54] <jamespage> yes
[16:54] <jamespage> the fix we need is in neutronclient
[16:54] <infinity> jamespage: So, can you get a quick neutronclient SRU up that has nothing but the one cherrypick?
[16:55] <jamespage> infinity, zul is working on it right now
[16:55] <jamespage> ivoks, fyi ^^
[16:55] <infinity> How much working on it can there be?  Looks like a 10 second job. :)
[16:55] <jamespage> infinity, well it takes on TL to run around flapping while zul does the actual work right ?
[16:55] <infinity> jamespage: Heh.
[16:55] <jamespage> :-)
[16:56] <ivoks> jamespage: thanks
[16:56] <jamespage> ivoks, hey - I'm just making noise - zul's doing the work
[16:56] <ivoks> zul: we are waiting :)
[16:56] <ivoks> jamespage: it's not to see noise getting escalated :D
[16:57] <ivoks> s/not/nice/
[16:57] <jamespage> lol
[16:57] <infinity> jamespage: Anyhow, if someone gets something in the queue that looks like it matches that upstream commit, byte-for-byte, I'll review and accept.  I may or may not be around at a convenient time to do an expedited release to -updates after you guys have put it through a bit of testing (flying around the world this weekend), but feel free to find another SRU team member, or even another AA and say "Adam said this is cool as long as we prove we ...
[16:57] <infinity> ... tested it".
[16:57] <ivoks> i've tested it
[16:57] <infinity> ivoks: The package.  You can't have tested the package.  Just saying.
[16:57] <ivoks> yeah, that's true
[16:58] <ivoks> i've tested upstream commit
[16:58] <ScottK> We need the package tested.
[16:58] <ivoks> yup, i know
[16:58] <ivoks> ScottK: and i'll test it as soon as it's available
[16:58] <ivoks> i have broken deployment already prepared for this test
[16:58] <infinity> Perfect.
[16:59] <jamespage> nice having a pre-prepared test bed for this
[17:03] <stgraber> @pilot out
[17:06] <zul> jamespage: just doing a local build before uploading
[17:07] <jamespage> zul, good-oh
[17:07] <jamespage> zul, I raised a task for bug 1280941
[17:10] <zul> jamespage: ok just uploaded
[17:11] <ivoks> zul: jamespage infinity please ping me when it's ready for testing
[17:15] <jamespage> infinity, its in the queue
[17:17] <infinity> Wrong bug ref...
[17:18] <infinity> zul: That should be 1280941, not 1277120
[17:18] <zul> infinity:  please reject and ill reupload
[17:18] <infinity> Go ahead.
[17:20] <ivoks> zul: bug number?
[17:20] <ivoks> zul: same as upstream?
[17:21] <zul> done
[17:23] <infinity> zul: Accepted.
[17:23] <zul> infinity:  cool thanks
[17:24] <infinity> zul: (For future reference, you don't have to upload to $series-proposed anymore, $series works just fine and lands in the right queue)
[17:26] <Nafallo> hey :-)
[17:27] <zul> infinity:  ok cool
[17:27] <Nafallo> I found a patch against net-snmp to add btrfs support to hrFSTable. would it be to late for the next LTS? :-)
[17:30] <infinity> Nafallo: File a bug?
[17:30] <Nafallo> I can do that.
[17:57] <xnox> ogra_: if you are about still, is the ubuntu-touch-meta that landed 20h - actually in fact really old build? cause it's out of date =/
[17:57] <ogra_> which version ?
[17:58] <Laney> yes it is
[17:58] <xnox> ogra_: https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.109 landed 20h into release pocket.
[17:58] <Laney> it was put into the silo ages ago and then released from there
[17:58] <xnox> i see.
[17:58] <ogra_> xnox, it landed 20th in the PPA
[17:58] <xnox> ogra_: Laney: what do I need to do to kick off ubuntu-touch-meta refresh?
[17:59] <Laney> do it normally
[17:59] <ogra_> the seed change is not relevant anymore and needs adjustment as well, but for the sake of a green image it wasnt done yet
[18:00] <xnox> ogra_: what do you mean? is r151 which landed is bad? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty
[18:00] <xnox> ogra_: what needs adjustment?
[18:00] <ogra_> driving the seeds through the CI train is really awkward too ... not sure how we can prevent them from going out of sync
[18:00] <ogra_> xnox, no, not bad, but we want to get rid of gst 0.10 at some point ... sergiusens and rsalveti have that in their hands
[18:01] <ScottK> Not everything that uses it has a 1.0 port though.
[18:01] <rsalveti> yeah, once gallery-app drops support for it
[18:01] <ogra_> well, only the gallery app in our case
[18:01] <rsalveti> right, but at least in touch we don't plan to support anything using 0.10
[18:02] <rsalveti> as that will not use any hw decoder
[18:02] <xnox> ogra_: ScottK: rsalveti: i think we all know that we have both gstreamers still on the desktop, on touch, in main and everywhere.
[18:02] <xnox> ogra_: gst is not the problem, you made it sound as if the seed is somehow broken at the moment.
[18:02] <ogra_> xnox, well, on touch only gallery app kepps it
[18:02] <ogra_> xnox, why do you care ?
[18:03]  * ogra_ didnt mean to make it sound as if anything was broken ... i simply said we will roll parts of the seed change back 
[18:03] <xnox> ogra_: i care about landing ubuntu-touch-meta refresh to drop a load of libraries.
[18:03] <ogra_> hmm
[18:03] <rsalveti> xnox: hey, on a different topic, what is the current state of the i686 android toolchain you were building?
[18:03] <ogra_> xnox, did you coordinate that with didrocks
[18:03] <xnox> ogra_: which depend on gtk and don't do anything.
[18:03] <ogra_> he is anxiously waiting for a 100% image
[18:04] <xnox> ogra_: hm.... libraries that use X server, which is not running, are cruft =)
[18:04] <ogra_> xnox, well, as long as you run the testsuite with them removed
[18:04] <xnox> ogra_: sure!
[18:05] <ogra_> (i wouldnt trust that all deps in our upstream apps are 100% fine)
[18:10] <justCarakas> is there already something in place for an HTML5 app as datepicker or timepicker ?
[18:21] <infinity> jamespage: I'm going to catch some sleep.  If I wake up and discover that SRU has been verified but not released, I'll push it out.
[18:21] <jamespage> infinity, thanks - testing now
[18:21] <jamespage> I was able to reconfirm the regression - now testing the fix
[18:21] <infinity> You shouldn't have a hard time finding someone in a sane NA timezone to release it while I nap, though. :)
[18:39] <jamespage> ivoks, its in proposed (saucy)
[18:39] <jamespage> ivoks, I reproduced and then tested OK
[18:41] <hallyn> oh, i see.  bash completion no longer works with ~ expansion
[18:41] <hallyn> i.e. "ssh-add ~/.ssh/i<tab>" shows nothing
[18:45] <ivoks> jamespage: ok
[18:46] <sergiusens> ogra_, xnox  the gst drop is in a branch bfiller_afk and his team are working on (related to the new thumbnailer) (cc rsalveti)
[18:46] <jamespage> ivoks, I'd like to run the full smoke test run against it before we release - should take about 1 hr
[19:01] <rsalveti> xnox: sergiusens: https://code-review.phablet.ubuntu.com/#/c/206/
[19:01] <rsalveti> xnox: that should hopefully fix the amd64 ftbfs for the i686 androideabi toolchain
[19:02] <xnox> rsalveti: ok, i'll rebuild the toolchain and check it out. if it's good i'll upload it into the archive.
[19:03] <xnox> rsalveti: however, it still doesn't do SSP properly thus the image needs to be compiled with -fno-stack-protector, which is quite bad as well.
[19:03] <xnox> rsalveti: didn't sort out that second problem yet.
[19:03] <rsalveti> xnox: right, no worries
[19:03] <mhall119> what's the process for getting a package *removed* from Universe?
[19:04] <cjwatson> file a bug on it, subscribe ubuntu-archive
[19:04] <cjwatson> give a good reason
[19:04] <mhall119> thanks cjwatson
[19:04] <mhall119> "it's incompatible with it's dependencies" is a good readon
[19:04] <cjwatson> don't give the reason here :)
[19:07] <mhall119> ok, I'll see if I can fix/update it over the weekend, but otherwise I'll file for it to be removed
[19:09] <mhall119> cjwatson: so the package in question is qimo-session, which in 2.x uses a modified Xfce session, but in 3.x will use a modified Unity session, which means there is a drastic change in dependencies for that package, is it okay to just change the Depends or do I need to do something to let the user know that such a big change is happening?
[19:09] <ivoks> jamespage: ok
[19:09] <mhall119> it's probably not relevant, because I don't think qimo-session worked in 12.04 either
[19:17] <jtaylor> someone know the url of the branch the gcc packages are based of?
[19:18] <ivoks> jamespage: zul ScottK infinity verification done
[19:18] <slangasek> hallyn: hey, so I tried to do a test build of your qemu 2.0~pre packages on powerpc, and got this error; is this something you could take a look at? http://paste.ubuntu.com/7051684/
[19:18] <slangasek> hallyn: (we have a powerpc porter box again, so should be easy :)
[19:18] <zul> ivoks:  excelente
[19:18] <jtaylor> oh found it, the vcs browser has more than one page
[19:19] <slangasek> hallyn: in fact, might be as simple as dropping debian/patches/ubuntu/target-ppc-add-stubs-for-kvm-breakpoints, which may be double-applied?
[19:19] <hallyn> slangasek: hm, ok.
[19:21] <hallyn> slangasek: yeah, looks like that was prolly fixed in git, and patch was quietly re-adding it.  it didnt' wanna fuss
[19:21] <hallyn> slangasek: yeah upstream commit c65f9a07a78afa3c98712f6192962ffd6babe339
[19:21] <hallyn> i'll push a new build with that dropped, thx!
[19:21] <slangasek> hallyn: thank you :)
[19:23] <hallyn> thank you!  pushed.
[19:25] <ScottK> ivoks (and infinity) on it.
[19:26] <jamespage> thanks ScottK
[19:28] <ScottK> jamespage, ivoks , zul , infinity: Released.
[19:29] <jamespage> excellent
[19:40] <Noskcaj> Can some more people please add testimonials to https://wiki.ubuntu.com/Noskcaj#MOTU ?
[19:45] <Noskcaj> Laney ^
[19:48] <Noskcaj> mterry, ^
[19:48] <mterry> Noskcaj, hello!
[19:48] <Noskcaj> hey mterry
[19:48] <mterry> Noskcaj, is there a close deadline or can I do it this weekend?
[19:49] <Noskcaj> mterry, Just by the next 19UTC meeting
[19:49] <Noskcaj> That's the only time i can apply till around october
[19:49] <mterry> What day?
[19:49]  * mterry forgets when the membership meetings are
[19:50] <mterry> Noskcaj, ^
[19:50] <Noskcaj> 24th
[19:50] <mterry> Noskcaj, ah, pfft.  OK!  I'll add something this weekend.  :)
[19:50] <Noskcaj> thank you
[19:51] <mterry> Noskcaj, oh man.  Just now realized your  nick is jackson backwards
[19:51]  * mterry is smart
[19:52] <Noskcaj> :)
[19:52] <Noskcaj> I think that's three people have worked that out now
[19:52] <Noskcaj> :)
[19:52]  * mterry goes afk
[19:55] <Laney> That's the only way I can remember how to spell it
[19:55] <Laney> I'll write something soon
[19:56] <Noskcaj> thanks
[20:02] <sarnold> pitti: another trusty bug not yet retraced after eight hours: https://bugs.launchpad.net/bugs/1289289
[20:12] <barry> mlankhorst: oh man, *anything* i can do to help debug LP: #1284134, just let me know.  it's causing me physical pain ;)  i'll drop everything else to help gather information