[00:38] <cyphermox> xnox: tomorrow morning I'll test removing it to see what breaks, and I tell you then whether it's ok to remove?
[00:38] <cyphermox> my tomorrow morning is in about 12 hours.
[01:35] <FourDollars> cyphermox: Could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1300623 ?
[01:48] <mwhudson> infinity: hey did you stick that libc patch into a ppa?
[01:49] <mwhudson> should have built or failed by now i think...
[01:49] <infinity> mwhudson: Nope.  I'm like a kitten with a laser pointer today.
[01:49] <mwhudson> heh
[01:50] <mwhudson> infinity: anything i can do to make it more likely?
[01:52] <infinity> mwhudson: Uploading nowish.
[01:52] <infinity> In theory.
[01:52] <infinity> When the source builds.
[01:52]  * infinity smacks his laptop.
[01:53] <mwhudson> infinity: which ppa?
[01:53] <infinity> mwhudson: adconrad/ppa
[01:54] <mwhudson> cool
[01:54] <infinity> mwhudson: And building.
[01:55] <mwhudson> infinity: awesome, thanks
[01:56] <mwhudson> takes about 90 mins on arm64, right?
[01:56] <infinity> mwhudson: So, if this works and fixes your issue, we have a few things to do.
[01:56] <infinity> mwhudson: 1: nag Will harder about upstream review (but I won't block on this)
[01:56] <infinity> mwhudson: 2: Fish Will's testcase patch out of libc-alpha and give me that to add with this other patch.
[01:56] <infinity> mwhudson: 3: Figure out WTF our distro kernel chokes on tst-tls5. :/
[01:57] <mwhudson> 1: i cc:ed you on a mail to will earlier i think?
[01:57] <mwhudson> i meant to, anyway
[01:57] <infinity> mwhudson: Yeah, you did. :)
[01:57] <mwhudson> cool
[01:57] <mwhudson> 2: ack
[01:57] <mwhudson> 3: yes :/
[01:57] <mwhudson> do you know offhand what that test is testing?
[01:57] <mwhudson> other than thread local storage
[01:57] <infinity> Haven't looked at it at all.
[01:57] <mwhudson> kay
[01:58] <infinity> But the failure doesn't look like something we should XFAIL either, without understanding why.
[01:58] <mwhudson> indeed
[01:58] <mwhudson> totally a WAG but... how do i tell if i have a 64k page kernel?
[01:58] <infinity> getconf
[01:58] <infinity> (base)adconrad@cthulhu:~$ getconf PAGESIZE
[01:58] <infinity> 4096
[01:59] <mwhudson> ok same
[01:59] <mwhudson> boring
[02:00] <infinity> mwhudson: And about 70 minutes to build on arm64.
[02:00] <infinity> mwhudson: At least, on my snazzy 2.4GHz buildds. :P
[02:00] <mwhudson> heh
[02:01] <mwhudson> what are the porter boxes?  2.0?
[02:01] <infinity> mwhudson: If they're still A2s, then yeah.
[02:02] <mwhudson> hm, 'make check' just succeeded in ~/eglibc-builds/eglibc-2.19/build-tree/arm64-libc
[02:02] <mwhudson> how do you run the tests?
[02:03] <infinity> mwhudson: Well, make check would have had nothing to re-make...
[02:03] <mwhudson> oh ok
[02:03] <infinity> mwhudson: I go hunt through the log for the exact invocation of the test that failed and just run that massive commandline over and over.
[02:03] <infinity> I'm sure there are better ways. :P
[02:05] <infinity> mwhudson: So, I have no idea what am1 is, cause the new cpuinfo is completely uninformative.
[02:05] <infinity> Special.
[02:05] <mwhudson> infinity: hey, it tells you that there are 8 cores
[02:05] <mwhudson> but yes
[02:07] <infinity> mwhudson: The lack of model name and speed seems weird.
[02:09] <mwhudson> infinity: ok
[02:09] <mwhudson> so
[02:09] <mwhudson> the test program prints WRONG ALIGNMENT
[02:09] <mwhudson> (and fails)
[02:09] <mwhudson> _if_ you have ulimit -s unlimited
[02:10] <mwhudson> (which makes memory be allocated in the other direction)
[02:10] <mwhudson> (the fact that i know this bothers me i think)
[02:10] <Niles> Could it be a PAE problem?
[02:10] <mwhudson> 64 bit user space on 64 bit processor?  i hope not
[02:10] <Niles> Oh wait, that's dumb
[02:10] <Niles> Nevermind
[02:11] <Niles> Only case I know where memory gets allocated backwards
[02:11] <mwhudson> i've only read the relevant bits of the kernel for arm64 :)
[02:12] <mwhudson> so um yeah
[02:20] <mwhudson> does anyone happen to know where THREAD_SELF is defined/
[02:20] <mwhudson> ?
[02:21] <mwhudson> (on aarch64)
[02:21] <barry> xnox: that would rock :)
[02:22]  * mwhudson hugs the glibc source layout
[02:23] <sarnold> I've never seen an ironic hug before, but there it is :)
[02:24] <mwhudson> now __builtin_thread_pointer
[02:24] <mwhudson> i guess that's a gcc thing
[02:24] <mwhudson> sarnold: :)
[02:40] <infinity> mwhudson: I'd I'm reading the log-in-process right, tst-tls5 didn't fail in my PPA.
[02:41] <infinity> s/process/progress/
[02:41] <mwhudson> infinity: i think if my patch was causing this failure i'd give up and start looking for lawn mowing jobs
[02:41] <infinity> Lawn mowing is good, honest work.
[02:42] <infinity> You might need to buy some shoes, though.
[02:42] <infinity> sarnold: You don't like the glibc source tree?
[02:43] <infinity> sarnold: Given the complex concepts it needs to encapsulate, I feel it does a pretty good job.
[02:43] <infinity> Doesn't take long to wrap your head around the cascading include paths, etc.
[02:44] <mwhudson> i find the fact that the eg s390 platform specific code is in ./nptl/s390 but the aarch64 specific stuff is in ./ports/sysdeps/unix or somewhere constantly confusing
[02:45] <infinity> mwhudson: Oh, well, ports is gone in 2.20
[02:45] <mwhudson> infinity: \o/
[02:45] <infinity> mwhudson: Or will be, once all the ports are moved.  Most are.
[02:45] <infinity> In fact, all but hppa look to have moved.
[02:45] <infinity> Carlos is a slacker.
[02:48] <mwhudson> oh
[02:51] <mwhudson> um
[02:51] <mwhudson> does libpthread do some crazy magic in its .init section?
[02:52] <mwhudson> because i now have a test program that fails _if_ it's linked against libpthread
[02:52] <mwhudson> and not otherwise
[02:53] <mwhudson> infinity: can you run a small test case on a buildd (or some other vintage kernal machine i guess)
[02:55] <infinity> mwhudson: Sure.
[02:55] <mwhudson> infinity: http://paste.ubuntu.com/7192634/
[02:57] <infinity> mwhudson: http://paste.ubuntu.com/7192638/
[02:58] <mwhudson> ho strange
[02:58] <infinity> mwhudson: Well, seems to be the same as the results you got?
[02:58] <mwhudson> yes
[02:58] <infinity> So, not a regression.
[02:58] <infinity> But quite possibly a bug.
[02:59] <mwhudson> maybe i was just building eglibc in a shell that had ulimit -s unlimited?
[02:59] <infinity> mwhudson: Seems plausible.
[03:00] <mwhudson> it would be a good explanation, but i don't recall changing that :/
[03:05] <mwhudson> ah, i remember why i didn't quilt import this patch: it isn't rooted at the base of the tree
[03:07] <infinity> mwhudson: Well, quilt import doesn't work so well in eglibc probably anyway.
[03:08] <infinity> mwhudson: But just stuffing the git-formatted patch in debian/patches/ubuntu/ works fine. :P
[03:09] <mwhudson> ok i'm now rebuilding in a shell that _definitely_ does not have ulimit -s set
[03:09] <mwhudson> (well rather, not set to unlimited)
[03:09] <mwhudson> and yes, this looks like a bug
[03:10] <mwhudson> glibc tests that pthread_self is always 16 byte aligned, and on aarch64 with unlimited stack it isn't
[03:10] <mwhudson> so is the bug in the test or the ... whatever sets the tls pointer
[03:13] <infinity> mwhudson: Worth an upstream bug report and a nudge to the maintainers.
[03:13] <mwhudson> yeah
[03:14] <mwhudson> glibc bugzilla?
[03:14] <infinity> Yeah.
[03:14] <mwhudson> i'll ping linaro-toolchain about it too
[03:19] <mwhudson> infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16796 (i added you to cc so maybe you got mail already)
[03:39] <cyphermox> FourDollars: gladly. patch looks fine, perhaps it should just also happen in saucy and trusty?
[03:43] <FourDollars> cyphermox: The codebase changed too much in saucy and trusty so this patch may only work in precise.
[03:44] <cyphermox> ok
[03:45] <cyphermox> well then I'd like to give it a shot in trusty tomorrow
[03:45] <cyphermox> and if I can't make it work, then I'll just say so on the bug so there's no questions
[03:46] <cyphermox> FourDollars: want to update the bug for the SRU process?
[03:46] <FourDollars> cyphermox: yes
[03:48] <cyphermox> FourDollars: thanks
[03:49] <cyphermox> FourDollars: I'll sponsor the patch first thing tomorrow morning
[03:49] <FourDollars> cyphermox: Sorry. I just checked saucy and trusty. I think this patch can also apply on them.
[03:49] <FourDollars> cyphermox: Thanks a lot.
[03:57] <cyphermox> FourDollars: alright, np :)
[03:57] <FourDollars> :)
[03:58] <cyphermox> if it turns out it doesn't work for you, I'll look myself in the morning to see if I can make sense of it
[03:58] <FourDollars> OK
[05:27] <sarnold> infinity: well, I can't really argue one way or another about glibc source tree except to say that when I try to figure out how something is implemented in the libc wrappers in linux, it always takes me two or three times longer to find it than I'd expect
[06:17] <pitti> Good morning
[06:17] <ion> that
[06:22] <infinity> mwhudson: Well, that was a quick response to your bug.
[06:39] <infinity> mardy: You around?
[06:41] <infinity> mardy: Your dpkg-maintscript-helper calls in account-plugins should have a version argument on them, so it's not attempted on every single upgrade forever.
[06:41] <infinity> mardy: I'm rejecting based on that.  Please fix.
[06:41] <dholbach> good morning
[06:48] <mardy> infinity: OK
[06:49] <mardy> infinity: I should put the version where the script was last useful, right?
[06:50] <infinity> mardy: It should be the version just before the one being uploaded.  The easiest way to do that is just to tack a ~ on the end of the version you're uploading.
[06:50] <infinity> mardy: ie: if you're uploading 1.2.3-1 that removes the conffile, the version passed to rm_conffile should be 1.2.3-1~
[06:50] <infinity> mardy: The manpage explains why, and how.
[06:51] <mardy> infinity: ok, thanks
[06:51] <infinity> mardy: (Given that you're doing daily builds that tend to have a large gap between uploads, though, you could probably just fudge it as "$date -1" or something if you wanted to)
[06:52] <infinity> mardy: But generally, the goal is to not screw over people who rebuild, do local test builds, derive in other distros, etc, etc.
[07:09] <doko> Sweetshark, could you have a look at https://launchpad.net/ubuntu/+source/accessodf/0.1-4/+build/5866883 ?  looks like the only difference is the lo version
[07:57] <mardy> dbarth: so, infinity suggested a change in the account-plugin-flickr debian scripts
[07:57] <mardy> dbarth: quoting from this morning:
[07:57] <mardy> 09:39 < infinity> mardy: Your dpkg-maintscript-helper calls in account-plugins should have a version argument on them, so it's not attempted on every single upgrade forever.
[07:57] <mardy> 09:39 < infinity> mardy: I'm rejecting based on that.  Please fix.
[08:04] <dbarth> mardy: ah ok
[08:04] <dbarth> mardy: then can you file a bug with infinity's concerns, and i'll land asap
[08:05] <mardy> dbarth: why a second one? account-plugins didn't land, did it?
[08:05] <Noskcaj_> Can someone check if modemmanager is syncable?
[08:05] <Noskcaj_> There's some fairly important upgradeing fixes
[08:05] <dbarth> mardy: it did
[08:05] <dbarth> mardy: was tested and published yesterday
[08:05] <dbarth> mardy: i merged them this morning, since we couldn't take back the packages anyway
[08:06] <mardy> dbarth: oh, you are right
[08:06] <mardy> dbarth: but the bug is still open
[08:07] <mardy> dbarth: and the merge proposal is not in "merged" status yet
[08:07] <mardy> dbarth: even though I see that the changes are now in trunk... weird...
[08:15] <Sweetshark> doko: weird. yeah, Ill take a look.
[08:30] <Noskcaj_> Logan_: http://paste.ubuntu.com/7193182/
[08:32] <seb128> Noskcaj_, hey
[08:49] <Sweetshark> doko: so, have it fixed locally, wonder why it ever build. investigating if we changed the API there upstream ...
[08:51] <Sweetshark> oh, we did. Well actually those cowboys at AOO changed the API and we followed suit ...
[08:54] <brendand> hi, this is a slightly unusual situation, but if we had a feature in a package and then had to drop it for while and now want to bring it back, will we need a feature freeze exception?
[08:56] <pitti> infinity: ah, lintian autopkgtest succeeds now; thanks for pointing out the dep parsing bug
[08:57] <infinity> pitti: Yeahp, I got the spam about it being fixed.  Thanks. :)
[08:59] <didrocks> xnox: are you going to reupload your g+ apps or should I do that?
[09:02] <pitti> infinity: so that was either a bug in lintian or in python-debian; I suspec that the comment in lintian isn't entirely legal, but then again this is probaly underdefined (comments starting at the first column but don't break the continuation line)
[09:03] <infinity> pitti: The comment does start at the first column...
[09:03] <infinity> Oh, I missed the "but" there.
[09:03] <pitti> infinity: right, but it's in the middle of a continuation line
[09:03] <pitti> infinity: so, I don't know whether that's legal or a bug in python-debian, but it just works around that now
[09:03] <pitti> it == adt-run
[09:03] <infinity> pitti: Yeah, it's arguable if it's allowed or not, but I'm not sure I've ever read anything that says it's not, and dpkg parses it correctly.
[09:04] <infinity> pitti: And I'd say that dpkg is the authority on how to parse debian/control.
[09:04] <pitti> *nod*, hence I filed a bug against p-debian
[09:05] <infinity> pitti: I'd have just torn the comments out in our delta, but then it would still be broken for ci.debian, plus it can't be the only package that does that.
[09:05] <infinity> pitti: So, yay, thanks for the bug and the workaround. :)
[09:07] <xnox> didrocks: i can republish it, if the container/ua is fixed now.
[09:08] <xnox> cyphermox: that would be awesome! you're a start =) thanks.
[09:08] <didrocks> xnox: yeah, you need to target the 14.04 dev1 framework though
[09:08] <didrocks> xnox: to get oxide
[09:09] <xnox> didrocks: right, yeah i see ping from davmor2 about that.
[09:22] <davmor2> xnox: see everyone loves the google+
[09:25] <ogra_> wow, G+ in the new browser is just lovely to use
[09:25] <ogra_> working javascript makes such a big difference
[09:26] <davmor2> ogra_: so easily pleased now get off G+ and get some work done ;)
[09:26] <ogra_> haha
[09:27] <davmor2> ogra_: and none of this I'm just "testing oxide" milarky either that's my excuse :P
[09:28] <ogra_> heh
[09:35] <xnox> is there a way to get oxide on the desktop?
[09:35]  * xnox dist-upgrades first
[09:35] <ogra_> xnox, i think that should get it for you (at least for the webapps)
[09:36] <happyaron> seb128: why unity-control-center depends on ibus?
[09:37] <seb128> happyaron, because it writes to its gsettings schemas
[09:37] <seb128> I though of you when that was added
[09:37] <seb128> I guess we could handle the missing schemas and lower to a recommends or something
[09:37] <happyaron> if recommends is doable then that'd be great.
[09:38] <seb128> happyaron, https://code.launchpad.net/~attente/unity-control-center/1288717/+merge/209982
[09:39] <seb128> happyaron, btw https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1288717/comments/3
[09:39] <seb128> happyaron, but you never bothered replying to my comment
[09:39] <seb128> happyaron, if you had you would have seen the change/new depends...
[09:40] <seb128> happyaron, anyway, I don't think making that a recommends is on top of you priority list, but patches are welcome if somebody wants to work on that
[09:41] <happyaron> seb128: well I'm being so busy recently dealing with all kinds of stuff...
[09:42] <seb128> happyaron, we all are...
[09:42] <happyaron> :)
[09:43] <seb128> happyaron, anyway you have the why you asked for now ;-)
[09:49] <tkamppeter> mdeslaur, I have issued cups-filter 1.0.51 upstream now and also packaged and uploaded it for Trusty, so the vulnerability is fixed now. Thanks for the report.
[09:50] <happyaron> seb128: well the good thing is we got this fix: https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1297831/comments/18
[09:51] <happyaron> seb128: so you are right, it's not on the top of my list.
[09:53] <seb128> happyaron, ok, good
[09:53] <brendand> seb128, this is a slightly unusual situation, but if we had a feature in a package and then had to drop it for while and now want to bring it back, will we need a feature freeze exception?
[09:54] <seb128> brendand, I would assume so, but check with #ubuntu-release
[10:04] <Sweetshark> doko, seb128: fix for the build breaker at http://people.canonical.com/~bjoern/trusty/accessodf_0.1-1.3ubuntu2_amd64.changes -- the diff is next to it ...
[10:06] <seb128> Sweetshark, thanks, is that something we can get in Debian and sync?
[10:09] <Sweetshark> seb128: its a clearcut buildbreaker -- I guess debian would want that. Although the fix doesnt recreate the messagebox type (infobox, questionbox etc.), but IMHO thats something for upstream (not debian) to take care of.
[10:10] <pitti> doko: s/langpack-en-us
[10:10] <pitti> doko: ... /language-pack-en-us/ :)
[10:11] <Sweetshark> seb128: Ill hint rene at it (although he is not the maintainer there)
[10:11] <pitti> doko: sorry, I mean language-pack-en; we don't have by-country packs except for -zh
[10:12] <pitti> doko: FYI, infinity wants to move langpack-locales back into eglibc and also build locales-all (hopefully next cycle), so that's going away at some point
[10:12] <seb128> Sweetshark, do you still want sponsoring to trusty? we can sync over from Debian once they fix it
[10:14] <Sweetshark> seb128: lets wait for renes reaction first ..
[10:15] <seb128> Sweetshark, k
[10:21] <apachelogger> pitti: https://launchpad.net/ubuntu/+source/gpgme1.0/1.4.3-0.1ubuntu2 seems to have broken kdepim s/mime support as per bug 1293704
[10:44] <shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1301307
[10:45] <shadeslayer> tseliot: ^^
[10:45] <xnox> ogra_: are there any webapps that work as contained clicks with oxide?
[10:45] <xnox> cause updated g+ fails like shown in bug #1301305
[10:46] <ogra_> xnox, yes, the default shipped ones (gmail, facebook etc) ... and the browser itself is using it now
[10:46] <ogra_> only webapps that havent been re-uploaded with the new framework added use the old way still
[10:46] <tseliot> shadeslayer: I don't think there's a single vendor for that
[10:47] <shadeslayer> tseliot: right, but then the UI just looks terribly broken
[10:47] <shadeslayer> or atleast the KDE one does
[10:47] <tseliot> shadeslayer: any pictures?
[10:47] <shadeslayer> moment
[10:47] <ogra_> xnox, using the gmail app and then clicking the G+ menu option in there works too ... just has the gmail top bar then :)
[10:48] <xnox> ogra_: maybe i need "webview" policy group. Let's see.
[10:49] <shadeslayer> tseliot: http://im9.eu/picture/a19862
[10:50] <shadeslayer> tseliot: something else I noticed
[10:51] <tseliot> shadeslayer: you might want to have a fallback such as "Unspecified vendor" for when that happens
[10:51] <shadeslayer> tseliot: the pci values for Airport extreme is a subset of the one from linux-firmware-nonfree
[10:52] <shadeslayer> /sys/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0 vs /sys/devices/pci0000:00/0000:00:15.0/0000:02:00.0
[10:52] <shadeslayer> so maybe it would make sense to group them together?
[10:53] <tseliot> shadeslayer: does the Airport extreme require linux-firmware-nonfree?
[10:53] <shadeslayer> tseliot: yep
[10:53] <shadeslayer> that or the other b43 driver
[10:53] <shadeslayer> both work
[10:54] <tseliot> shadeslayer: and what do you mean by "grouping them together"?
[10:54] <shadeslayer> tseliot: under the same device :)
[10:55] <shadeslayer> so that ubuntu-drivers devices shows Broadcom Airport Extreme with 2 drivers : b43 and linux-firmware-nonfree
[10:55] <tseliot> oh, I see what you mean now
[10:56] <tseliot> I guess that would make sense
[10:56] <tseliot> pitti: ^
[11:08] <ogra_> oh !
[11:08] <ogra_> oh ! oh !
[11:08] <ogra_> video streaming inside the phone bowser works now !!!
[11:17] <xnox> new g+ is in the store review queue.
[11:18] <mdeslaur> tkamppeter: awesome, thanks!
[11:20] <Riddell> 6/win 15
[11:20] <Riddell> tsk
[11:42] <addiks> hi, does anybody know which exact component is responsible for giving input-events to the applications?
[11:46] <dobey> dpm_: ping
[11:54] <dpm_> hi dobey
[11:54] <dobey> dpm_: hi. do you know what the recommended way to build translations with under cmake would be?
[11:54] <mardy> is there a directory which can be used to store files which are cleared after a user's session ends?
[11:55] <dobey> intltool doesn't integrate with cmake
[11:55] <mardy> I've thought about XDG_RUNTIME_DIR, but that's not cleared on logout
[11:56] <dobey> mardy: delete the file when your process ends?
[11:56] <mardy> mdeslaur: I see you are here, maybe you know? ^
[11:56]  * ogra_ hugs xnox 
[11:56] <mardy> dobey: I want the file to persist across my process invocations, while in the same user session
[11:56] <mdeslaur> mardy: I don't believe there are any
[11:57] <dobey> yeah, there aren't any
[11:57] <mardy> dobey, mdeslaur: that's also good to know :-)
[11:57] <dpm_> dobey, yeah, unfortunately there is no standard way of building translations with cmake, and intltool does not support cmake. We ended up writing a custom rule to build them for core apps, e.g.: http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/trunk/view/head:/po/CMakeLists.txt
[11:57] <mdeslaur> mardy: you can probably store something in XDG_RUNTIME_DIR, and then check the timestamp on it vs. when the user session started
[11:57] <ogra_> xnox, external links dont open in the G+ app ... (not sure thats the app or the container)
[11:57] <mardy> mdeslaur: mmm... interesting! How can I know when the session started?
[11:57] <dobey> dpm_: ok, thanks
[11:58] <xnox> ogra_: i had to enable urlpatterns. At the moment login screens and google plus itself should stay in google plus.
[11:58] <mdeslaur> mardy: I...uh....well....perhaps you can ask logind? /me isn't sure
[11:59] <xnox> mdeslaur: i thought we do cleate a fresh XDG_RUNTIME_DIR on each login... that's the whole point of it.
[11:59] <dpm_> dobey, in addition to that, we also use a bit of a hack to extract translations from the desktop.in file: http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/trunk/view/head:/CMakeLists.txt#L58
[11:59] <ogra_> xnox, well, it doesnt open any external pages ... (though i assume thats a drawback of the new browser)
[12:00] <xnox> ogra_: oh, well... not sure =)
[12:01] <ogra_> xnox, oh, and i can play embedded videos when i open G+ in the browser, i guess your app musses the video apparmor profile
[12:01] <ogra_> *misses
[12:01] <ogra_> (i cant play it in the app)
[12:01] <xnox> ogra_: i have video profile.
[12:02] <ogra_> weird
[12:02] <xnox>     "policy_groups": [
[12:02] <xnox>         "networking",
[12:02] <xnox>         "audio",
[12:02] <xnox>         "video",
[12:02] <xnox>         "location",
[12:02] <xnox>         "webview"
[12:02] <xnox>     ],
[12:02] <dobey> dpm_: ok.
[12:03] <mdeslaur> xnox: doesn't look like it...stuff stays there
[12:03] <ogra_> xnox, well, open G+ in the browser and tap a youtube video, it plays fine ... doesnt in the app
[12:03]  * ogra_ was just trying that with his recent post
[12:04] <ogra_> in the app i see the loading animation ... and then it stops
[12:04] <ogra_> dbarth, ^^^
[12:13] <mdeslaur> xnox: nope, if the directory exists, it's kept as-is
[12:21] <dbarth> hmm, just reading the backlog
[12:22] <dbarth> xnox: do you have apparmor rejects when trying to play that video?
[12:23] <dbarth> xnox: it may also be that the app tries to play video fullscreen and fails
[12:23] <dbarth> the youtube player i mean
[12:23] <ogra_> dbarth, http://paste.ubuntu.com/7194027/
[12:23] <dbarth> previously it was not even trying, cause we were not detected as a "good enough" webview
[12:23] <ogra_> smells like you need some apparmor love from jdstrand
[12:24] <dbarth> ogra_: weird
[12:24] <ogra_> (this is what i get when trying to play an embedded yourtube video in G+ ... the same thing works when using G+ in the browser)
[12:24] <dbarth> do you have policy_version 1.*1* ?
[12:24] <ogra_> hmm, no idea
[12:24] <dbarth> i see you have the webview group already
[12:25] <ogra_> i'm on the latest image
[12:25] <dbarth> you need both, ie add the webview p.g. and bump the policy_version to 1.1
[12:25] <ogra_> where do i check that ?
[12:25] <dbarth> and declare framework 14.04-dev1
[12:25] <dbarth> manifest.json and <app>.json
[12:25] <ogra_> yes, i think thats what xnox did with his last upload
[12:26] <dbarth> then it's a bug
[12:26] <ogra_> http://paste.ubuntu.com/7194044/
[12:26] <dbarth> can you file and affect webbrowser-app, use [webapp-container] as a prefix
[12:26] <ogra_> looks all fine
[12:26] <dbarth> and i'll affect oxide and other if neede
[12:26] <dbarth> d
[12:27] <ogra_> (this was /opt/click.ubuntu.com/net.launchpad.click-webapps.gooogleplus/6/app.json)
[12:29] <jdstrand> dbarth: where have these rejects been happening?
[12:29] <jdstrand> dbarth: the silo or the archive?
[12:30] <ogra_> dbarth, bug 1301351
[12:30] <ogra_> jdstrand, latest image with the latest G+ app
[12:31] <ogra_> (both updated today, using oxide now)
[12:31] <ogra_> jdstrand, see the bug above
[12:32] <jdstrand> well, it should be against apparmor-easyprof-ubuntu
[12:32]  * jdstrand changes
[12:32] <ogra_> jdstrand, well, not sure, it might be two bugs ... (external links ... and video playback)
[12:32] <jdstrand> dbarth: fyi, I was trying to work out the final profile changes when I hit that crasher bug, so was blocked
[12:33] <jdstrand> but I'll get it worked out
[12:35] <ogra_> dbarth, m.youtube.com doesnt play back videos at all ... tapping on play just reloads
[12:35] <ogra_> (funny because the same video embedded in a G+ post plays just fine)
[12:42] <xnox> jdstrand: would i need to reupload the app? i believe i have all the correct intentions declared in the policy groups.
[12:48] <jdstrand> xnox: for that bug ^? no
[12:50] <jdstrand> xnox: I'll fix it and the policy will be regenerated on the first boot of the new image. if you are impatient, you can install apparmor-easyprof-ubuntu directly
[12:50] <xnox> jdstrand: ah cool =) didn't know how/when policies are regenerated =) if all gets fixed with an image update, that's cool! =)
[12:50] <xnox> like, really _cool_ =)))))
[12:51] <smoser> xnox, are you still looking at bug 1160079 ?
[12:54] <xnox> smoser: yes, i can upload a fix with just the cloud bits. Cause my other changes on top need some further work (e.g. on my machine plymouth crashes on shutdown and i haven't debugged it yet)
[12:54] <xnox> smoser: i'll upload the cloud fix later today.
[12:55] <smoser> xnox, thanks, that would be awesome.
[13:56] <hallyn> seb128: would you mind looking at the 1.1.1-0ubuntu8.9 libvirt awaiting acceptance for saucy-proposed?
[13:56] <seb128> hallyn, I'm not part of the SRU team
[13:56] <hallyn> d'oh, i was looking at the wrong comment, sorry
[13:56] <hallyn> bdmurray: ^
[13:57] <seb128> no worry ;-)
[14:05] <jdstrand> ogra_: do you have a couple minutes to help me with the apparmor denials?
[14:05] <ogra_> jdstrand, i can try
[14:06] <jdstrand> ogra_: ok, in /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6
[14:06] <jdstrand> ogra_: you'll see these rules:
[14:06] <jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cx -> oxide_helper,
[14:06] <jdstrand> /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cx -> oxide_helper,
[14:06] <jdstrand> ogra_: can you change them to:
[14:07] <jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cxmr -> oxide_helper,
[14:07] <jdstrand> /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cxmr -> oxide_helper,
[14:07] <jdstrand> ogra_: when done, please do: sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6
[14:07] <jdstrand> ogra_: then relaunch the web app
[14:09] <jdstrand> ogra_: oh, I forgot one. way down you'll see this rule:
[14:09] <jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer rmix,
[14:09] <jdstrand> under it, can you add:
[14:09] <jdstrand> @{PROC}/sys/kernel/yama/ptrace_scope r,
[14:09] <udevbot> Error: "{PROC}/sys/kernel/yama/ptrace_scope" is not a valid command.
[14:10] <jdstrand> ogra_: then do 'sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6' and relaunch the app
[14:13] <ogra_> jdstrand, no change ...
[14:13] <ogra_> let me reboot the phone
[14:13] <jdstrand> ogra_: are there denials?
[14:13] <ogra_> havent seen any when tailing syslog
[14:13] <jdstrand> ok, then it is like you said-- two bugs
[14:13] <ogra_> but the video doesnt play
[14:14] <ogra_> well, the other would be "not opening external links"
[14:14] <jdstrand> heh, well, I mostly mean I can fix my bug
[14:16] <ogra_> jdstrand, i dont really get why it plays flawless when opening G+ in the browser ... might not be apparmor related though
[14:17] <jdstrand> it is probably the webapp-container
[14:18] <jdstrand> I'll direct you to alex-abreau and dbarth
[14:18] <jdstrand> let's go to #webapps
[14:18] <jdstrand> (where they both are)
[14:18] <ogra_> well, dbarth asked me to file the bug, he is aware
[14:19]  * dholbach hugs mvo
[14:19] <ogra_> no need to be pushy, it never worked before ... having it working in the browser now is a massive improvement already :)
[14:20] <Laney> How can I run a/the click user hook/s manually?
[14:20] <Laney> I got an apport report from one of them
[14:23] <Laney> click hook run-user, got it
[14:25] <barry> mvo: ping
[14:25] <mvo> barry: hello! pong
[14:25] <barry> mvo: hi!  thanks for merging and uploading gdebi.  it'll be nice to kill another python2 dependency. :)  however i think there's a problem in sid:
[14:26] <barry> apt-get install gdebi-core
[14:26] <barry> The following packages have unmet dependencies:
[14:26] <barry>  gdebi-core : Depends: python3:any (>= 3.4~)
[14:26] <barry>  
[14:26] <barry> that's in a fresh sid chroot, but on a debian system w/gdebi-core already:
[14:26] <barry>  gdebi : Depends: python3:any (>= 3.4~)
[14:26] <barry>          Depends: gdebi-core (= 0.9.5) but 0.9.4 is to be installed
[14:26] <barry>  
[14:27] <mvo> barry: oh, let me have a look
[14:27] <barry> thanks
[14:28] <barry> mvo: ah, i see xnox committed (probably) a fix in bzr
[14:28] <xnox> barry: and uploaded...
[14:28] <mvo> :) thanks xnox !
[14:29] <xnox> barry: it seems that X-Python3-Verions: >= 3.4 was actually honored and impossible dependencies got generated =)
[14:29] <barry> xnox: thanks!  will you sync once it lands in debian?
[14:29] <xnox> barry: it's not needed on ubuntu.
[14:29] <xnox> barry: as our python3 is 3.4
[14:29] <barry> xnox: right, it didn't break us, but it still might be good to keep in sync
[14:30] <barry> xnox, mvo anyway, thanks!
[14:31] <Riddell> gosh, an mvo
[14:40] <mvo> hey Riddell
[14:48] <pitti> juliank: FYI, our jenkins now exports *-packages, like in https://jenkins.qa.ubuntu.com/job/trusty-adt-unattended-upgrades/45/ARCH=i386,label=adt/
[15:19] <bdmurray> hallyn: should that supercede the existing libvirt (which appears to have ftbfs btw)
[15:19] <hallyn> bdmurray: yes
[15:19] <bdmurray> hallyn: got it
[15:19] <hallyn> i goofed - the pach i was backporting in 8.8 had a hunk applied int he wrong effing fn
[15:19] <hallyn> thanks
[15:37] <jibel> barry, mvo latest pyflakes seems to have broken autopkgtest of unattended-upgrade https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-unattended-upgrades/ARCH=amd64,label=adt/46/artifact/results/dsc0t-run-tests-stdout
[15:38] <barry> jibel: thanks, that ought to be shallow.  let me see if i can craft a fix
[15:42] <juliank> pitti: That's great, but why do you tell me about it? Did I ask about that recently?
[15:43] <juliank> Seriously, I don't know. I forget many things I ask.
[15:44] <mvo> jibel: thanks
[15:44] <mvo> barry: let me know if you want me to have a look instead
[15:45] <barry> mvo: if you have some time to get a fix uploaded, that would be great.  this ought to do it: http://paste.ubuntu.com/7194816/
[15:45] <barry> mvo: or something like it ;)
[15:45] <mvo> barry: aha, the new "shadowing" warning :)
[15:45] <mvo> barry: sure thing, happy to do that
[15:46] <barry> mvo: yep ;)  thanks!
[15:46] <pitti> juliank: hm, I thought you did; sorry if I mixed that up with someone else
[15:46] <pitti> juliank: sorry, I was
[15:47] <pitti> jtaylor: FYI, our jenkins now exports *-packages, like in https://jenkins.qa.ubuntu.com/job/trusty-adt-unattended-upgrades/45/ARCH=i386,label=adt/
[15:47] <juliank> pitti: No problem.
[15:55] <jibel> bdmurray, FYI, I reproduced bug 1286161 with the clone from the OP
[15:58] <mvo> barry: uploaded
[15:59] <barry> mvo: thanks!
[16:04] <bdmurray> jibel: oh, anything interesting?
[16:09] <jibel> bdmurray, apart that it is reproducible with packages from the archive without any PPA, nothing else yet
[16:17] <bdmurray> jibel: oh, you might interested in bug 1290584 regarding apt-clone
[16:46] <pitti> xnox: all these "ValueError: invalid literal for int() with base 10:" in ubiquity, is that real, or just a transient thing?
[16:46] <pitti> xnox: i. e. does it make sense to retry a few times, or is that really broken?
[16:46] <pitti> xnox: sounds like it's trying to interpret a nonexisting debconf key as a number?
[16:47] <pitti> but why would removing the u1 bits affect partman..
[16:49] <xnox> pitti: haven't looked. That error messages comes up for any reason when debconf backend goes away.
[16:49] <xnox> (and ubiquity still tries to interract with it)
[16:56] <pitti> hallyn: is 2.0 still on the table for trusty? it gets kind of tight now
[16:57] <pitti> hallyn: FWIW, I've been using it since your annoucement (and that crash fix), and have basically forgotten about it :) (IOW, all happy)
[16:58] <hallyn> pitti: yeah, my plan is if upstream doesn't tag v2.0 this weekend i will take a git snapshot for .orig.tar.gz and push to trusty archive
[16:59] <pitti> hallyn: ah, you were waiting for the final, not on testing any more?
[16:59] <hallyn> pitti: what do you mean?
[16:59] <pitti> hallyn: yes, then uploading a pre-release snapshot sounds fine
[16:59] <hallyn> pitti: im' still uploading new versions to that ppa every other day or so
[16:59] <pitti> hallyn: the diff from the snapshot to final is presumably much smaller than 1.7 to 2.0 final?
[17:00] <hallyn> oh, yeah, i definately do not want to do a diff on top of 1.7
[17:00] <pitti> oh, need to run out, taxi going back to the hotel; good night everyone
[17:00] <hallyn> pitti: good night
[18:21] <doko> mlankhorst, tjaalton: xorg ping
[18:27] <tjaalton> doko: xorg pong
[18:28] <doko> tjaalton, two things:
[18:28] <doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5735335  the xorg-gtest ftbfs
[18:30] <doko> and the vnc4 ftbfs for arm64 and ppc64el (embedded xorg), https://launchpad.net/ubuntu/+source/vnc4/4.1.1+xorg4.3.0-37ubuntu5  do you have an idea how to fix that?
[18:30] <tjaalton> ugh
[18:33] <tjaalton> i bet xorg-gtest builds fine on sbuild..
[18:33] <tjaalton> lp is picky
[18:34] <tjaalton> no idea about vnc4.. i'd just drop it but someone might whine
[18:35] <bdmurray> stgraber: could you have a look at bug 1300654?
[18:36] <stgraber> bdmurray: I'm aware of it
[18:46] <bdmurray> stgraber: great
[19:50] <mwhudson> infinity: so the glibc build failed *again* for me, and i am very sure that ulimit -s wasn't unlimited
[19:51]  * mwhudson tries to remember the other reasons why the heap might grow up
[19:51] <infinity> mwhudson: Try the patch in the bug you filed?
[19:51] <mwhudson> well yes, that will certainly help
[19:51] <infinity> mwhudson: (assuming it was tst-tls5 that failed again)
[19:51] <mwhudson> or is certainly worth trying at least
[19:51] <mwhudson> yeah, same failure
[19:52] <mwhudson> i wonder if the newer kernel grows the heap up in some other circumstance than 3.8
[19:52] <infinity> mwhudson: I'm really not interested in knowing all the reasons why that test might fail, if the 2-line patch fixes the bug. :P
[19:52] <mwhudson> yeah, focus focus
[19:54] <mwhudson> building
[20:15] <infinity> hallyn: *poke*
[20:17] <infinity> hallyn: In that cgmanager upload, you moved pretty much EVERYTHING to /lib ... Really, only the actual library should move, the .so, .pc, and .a should stay in /usr/lib
[20:18] <infinity> hallyn: Also, you dropped the static build (intentional?), and your changelog claims you added -static when I think you meant -shared.
[20:18] <infinity> stgraber: ^ If you want to address any/all of that for hallyn...
[20:22] <infinity> mvo: Say, why does unattended-upgrades have .pyc files in the source?
[20:46] <juliank> infinity: I believe the pyc files in unattended-upgrades were accidental See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741467 for the fix.
[20:47] <juliank> While I'm not mvo, this might still help.
[20:48] <infinity> juliank: Ahh, kay, good to know that it's been addressed.  I just noticed the binary diffs in the queue and was non-plussed, but it's not like this is a new regression in the packaging or anything. :P
[20:50] <juliank> Maybe mvo wants to merge 0.82.4, assuming it's not too different from 0.82.1ubuntu1. The "fix Bug in rewind_cache() that can cause unwanted removals of packages" in 0.82.2 makes 0.82.1 seem a bit scary
[20:51] <jtaylor> what are the chances of still patching libtool to not strip gccs -fsanitize stuff in trusty?
[20:52] <jtaylor> hm I guess its not super important as you can get the links indirectly in your main application
[20:53] <infinity> jtaylor: I'm not sure that changing the behaviour of libtool two weeks before release would be a bright idea.  Since nothing will be rebuilt with it, but all security updates will be.
[20:54] <jtaylor> yes
[20:54] <jtaylor> just tested it, indirect links seem to work alright anyway
[21:02] <hallyn> infinity: feh, so i should just be moving the actual file by hand in debian/rules?
[21:03] <hallyn> infinity: i dropped the static build bc libcgmanager.so didn't want to be built -shared unless I did so;  if i find a way to have both happen i'll re-add the static lib
[21:04] <infinity> hallyn: Sure, don't care much about the static lib, was just curious.
[21:04] <infinity> hallyn: And yeah, check the bit in expat's debian/rules which moves libexpat.so.* to /lib and then re-targets the symlink in /usr.
[21:05] <infinity> hallyn: Should be able to do that fairly cleanly in a dh_auto_install override.
[21:06] <infinity> (Credit to slangasek for finding the expat rules snippet)
[21:06] <hallyn> ok, thanks.  I'll change that tongiht and re-push.
[22:26] <doko> robert_ancell, pyexiv2 ftbfs on ppc64el
[23:21] <xnox> stgraber: not sure if you are arround, could i get a silo for: https://code.launchpad.net/~xnox/indicator-applet/drop-u1/+merge/213873 and https://code.launchpad.net/~xnox/webapps-applications/remove-u1/+merge/213853 ?
[23:22] <xnox> or does anybody know who is US/west based who can allocate silos... cyphermox ?
[23:27] <stgraber> xnox: I'm not on the landing team myself, so I can add you to the spreadsheet but since those aren't foundations team packages, you may as well go straight to the ci channel
[23:29] <xnox> stgraber: hm, let me check who those two should go via. Maybe i can ping about them tomorrow.
[23:29] <stgraber> cyphermox is my usual suspect but it's past our eastern time EOD so he may be gone for dinner or something
[23:32] <xnox> i've been chatting with dbarth about the webapps one, not sure who is responsible for legacy applets.
[23:33] <xnox> stgraber: excellent. "indicator-applet" has no owner =) but it has been reviewed by ~unitish people. Could you silo up that one?
[23:34] <stgraber> xnox: since they're related, they probably should go in the same silo, let me add you to the spreadsheet at least
[23:34] <xnox> stgraber: all of them are stand alone. webapps is about dropping ubuntuone music webapp, indicator-applet is about dropping recommends to indicator-sync which will stop working.
[23:35] <xnox> stgraber: the two unity7 branches are already inflight in silo5 - which do same as indicator-applet branch + twiddle default settings to drop u1 control panel from default launchers.
[23:36] <xnox> unity7 is bundled with other bug-fixes however, so i wouldn't want to piggy back on top of that.
[23:36] <xnox> bregma: can you release/land indicator-applet?
[23:36] <stgraber> xnox: ok, I added you to the spreadsheet, let's see if there's someone in #ubuntu-ci-eng to give you a silo
[23:37] <xnox> bregma: this is assuming indicator-applet are ~= unitiish =)))
[23:37] <xnox> stgraber: could you ask? i'm not in that channel at all.
[23:37] <stgraber> xnox: yeah, just joined and asked (since we pretty much never land anything through the citrain I don't idle in there)
[23:38] <stgraber> xnox: do you have any testsuite I should link in there?
[23:38] <xnox> stgraber: it's desktop only, btw.
[23:38] <xnox> stgraber: i have manual test cases to test that xubuntu works, and that shortcuts are not in the default unity launcher. I've tested both locally.
[23:38] <xnox> (xubuntu is the prime user of indicator-applet)
[23:39] <stgraber> xnox: ok, I think I've put as much details as I can in the spreadsheet, hopefully someone will flip the switch and give you a silo soon
[23:41] <xnox> stgraber: thanks a lot! i'll watch that spreadsheet.
[23:44] <robert_ancell> doko, what is the easiest way to test on ppc64el?
[23:46] <doko> robert_ancell, ssh porter-ppc64el.canonical.com
[23:48] <robert_ancell> doko, any chance of getting git installed on there?
[23:51] <cjwatson> robert_ancell: schroot -c trusty-ppc64el
[23:51] <doko> robert_ancell, afk now
[23:51] <cjwatson> robert_ancell: git's in the schroot
[23:51] <cjwatson> robert_ancell: (and you can "sudo apt-get install" things)
[23:52] <robert_ancell> ah, thanks
[23:57] <stgraber> xnox: we've got a silo
[23:58] <xnox> \o/
[23:58] <xnox> cjwatson: i'm pretty sure i've installed a whole bunch of things in the chroot, to the point of getting build-conflicts now. sudo apt-get remove does not work.
[23:59] <xnox> cjwatson: was i using our porter boxes somehow wrong? (e.g. a session/snapshot is not created for me that gets auto-cleaned up)