=== cjwatson_ is now known as cjwatson === alesage is now known as alesage|afk [00:38] 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] my tomorrow morning is in about 12 hours. === seelaman` is now known as seelaman [01:35] cyphermox: Could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1300623 ? [01:35] Launchpad bug 1300623 in bluez (Ubuntu) "bluetoothd crashs after resuming from Suspend to RAM. " [Undecided,New] [01:48] infinity: hey did you stick that libc patch into a ppa? [01:49] should have built or failed by now i think... [01:49] mwhudson: Nope. I'm like a kitten with a laser pointer today. [01:49] heh [01:50] infinity: anything i can do to make it more likely? [01:52] mwhudson: Uploading nowish. [01:52] In theory. [01:52] When the source builds. [01:52] * infinity smacks his laptop. [01:53] infinity: which ppa? [01:53] mwhudson: adconrad/ppa [01:54] cool [01:54] mwhudson: And building. [01:55] infinity: awesome, thanks [01:56] takes about 90 mins on arm64, right? [01:56] mwhudson: So, if this works and fixes your issue, we have a few things to do. [01:56] mwhudson: 1: nag Will harder about upstream review (but I won't block on this) [01:56] mwhudson: 2: Fish Will's testcase patch out of libc-alpha and give me that to add with this other patch. [01:56] mwhudson: 3: Figure out WTF our distro kernel chokes on tst-tls5. :/ [01:57] 1: i cc:ed you on a mail to will earlier i think? [01:57] i meant to, anyway [01:57] mwhudson: Yeah, you did. :) [01:57] cool [01:57] 2: ack [01:57] 3: yes :/ [01:57] do you know offhand what that test is testing? [01:57] other than thread local storage [01:57] Haven't looked at it at all. [01:57] kay [01:58] But the failure doesn't look like something we should XFAIL either, without understanding why. [01:58] indeed [01:58] totally a WAG but... how do i tell if i have a 64k page kernel? [01:58] getconf [01:58] (base)adconrad@cthulhu:~$ getconf PAGESIZE [01:58] 4096 [01:59] ok same [01:59] boring [02:00] mwhudson: And about 70 minutes to build on arm64. [02:00] mwhudson: At least, on my snazzy 2.4GHz buildds. :P [02:00] heh [02:01] what are the porter boxes? 2.0? [02:01] mwhudson: If they're still A2s, then yeah. [02:02] hm, 'make check' just succeeded in ~/eglibc-builds/eglibc-2.19/build-tree/arm64-libc [02:02] how do you run the tests? [02:03] mwhudson: Well, make check would have had nothing to re-make... [02:03] oh ok [02:03] 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] I'm sure there are better ways. :P [02:05] mwhudson: So, I have no idea what am1 is, cause the new cpuinfo is completely uninformative. [02:05] Special. [02:05] infinity: hey, it tells you that there are 8 cores [02:05] but yes [02:07] mwhudson: The lack of model name and speed seems weird. [02:09] infinity: ok [02:09] so [02:09] the test program prints WRONG ALIGNMENT [02:09] (and fails) [02:09] _if_ you have ulimit -s unlimited [02:10] (which makes memory be allocated in the other direction) [02:10] (the fact that i know this bothers me i think) [02:10] Could it be a PAE problem? [02:10] 64 bit user space on 64 bit processor? i hope not [02:10] Oh wait, that's dumb [02:10] Nevermind [02:11] Only case I know where memory gets allocated backwards [02:11] i've only read the relevant bits of the kernel for arm64 :) [02:12] so um yeah [02:20] does anyone happen to know where THREAD_SELF is defined/ [02:20] ? [02:21] (on aarch64) [02:21] xnox: that would rock :) [02:22] * mwhudson hugs the glibc source layout [02:23] I've never seen an ironic hug before, but there it is :) [02:24] now __builtin_thread_pointer [02:24] i guess that's a gcc thing [02:24] sarnold: :) [02:40] mwhudson: I'd I'm reading the log-in-process right, tst-tls5 didn't fail in my PPA. [02:41] s/process/progress/ [02:41] infinity: i think if my patch was causing this failure i'd give up and start looking for lawn mowing jobs [02:41] Lawn mowing is good, honest work. [02:42] You might need to buy some shoes, though. [02:42] sarnold: You don't like the glibc source tree? [02:43] sarnold: Given the complex concepts it needs to encapsulate, I feel it does a pretty good job. [02:43] Doesn't take long to wrap your head around the cascading include paths, etc. [02:44] 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] mwhudson: Oh, well, ports is gone in 2.20 [02:45] infinity: \o/ [02:45] mwhudson: Or will be, once all the ports are moved. Most are. [02:45] In fact, all but hppa look to have moved. [02:45] Carlos is a slacker. [02:48] oh [02:51] um [02:51] does libpthread do some crazy magic in its .init section? [02:52] because i now have a test program that fails _if_ it's linked against libpthread [02:52] and not otherwise [02:53] infinity: can you run a small test case on a buildd (or some other vintage kernal machine i guess) [02:55] mwhudson: Sure. [02:55] infinity: http://paste.ubuntu.com/7192634/ [02:57] mwhudson: http://paste.ubuntu.com/7192638/ [02:58] ho strange [02:58] mwhudson: Well, seems to be the same as the results you got? [02:58] yes [02:58] So, not a regression. [02:58] But quite possibly a bug. [02:59] maybe i was just building eglibc in a shell that had ulimit -s unlimited? [02:59] mwhudson: Seems plausible. [03:00] it would be a good explanation, but i don't recall changing that :/ [03:05] ah, i remember why i didn't quilt import this patch: it isn't rooted at the base of the tree [03:07] mwhudson: Well, quilt import doesn't work so well in eglibc probably anyway. [03:08] mwhudson: But just stuffing the git-formatted patch in debian/patches/ubuntu/ works fine. :P [03:09] ok i'm now rebuilding in a shell that _definitely_ does not have ulimit -s set [03:09] (well rather, not set to unlimited) [03:09] and yes, this looks like a bug [03:10] glibc tests that pthread_self is always 16 byte aligned, and on aarch64 with unlimited stack it isn't [03:10] so is the bug in the test or the ... whatever sets the tls pointer [03:13] mwhudson: Worth an upstream bug report and a nudge to the maintainers. [03:13] yeah [03:14] glibc bugzilla? [03:14] Yeah. [03:14] i'll ping linaro-toolchain about it too [03:19] infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16796 (i added you to cc so maybe you got mail already) [03:19] sourceware.org bug 16796 in nptl "[aarch64] pthread_self not aligned to 16 bytes when heap grows up" [Normal,New] [03:39] FourDollars: gladly. patch looks fine, perhaps it should just also happen in saucy and trusty? [03:43] cyphermox: The codebase changed too much in saucy and trusty so this patch may only work in precise. [03:44] ok [03:45] well then I'd like to give it a shot in trusty tomorrow [03:45] and if I can't make it work, then I'll just say so on the bug so there's no questions [03:46] FourDollars: want to update the bug for the SRU process? [03:46] cyphermox: yes === cr3_ is now known as cr3 [03:48] FourDollars: thanks === cr3 is now known as Guest29639 [03:49] FourDollars: I'll sponsor the patch first thing tomorrow morning [03:49] cyphermox: Sorry. I just checked saucy and trusty. I think this patch can also apply on them. [03:49] cyphermox: Thanks a lot. [03:57] FourDollars: alright, np :) [03:57] :) [03:58] 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] OK [05:27] 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] Good morning [06:17] that [06:22] mwhudson: Well, that was a quick response to your bug. === jackson is now known as Guest51547 [06:39] mardy: You around? [06:41] 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] mardy: I'm rejecting based on that. Please fix. [06:41] good morning [06:48] infinity: OK [06:49] infinity: I should put the version where the script was last useful, right? [06:50] 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] 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] mardy: The manpage explains why, and how. [06:51] infinity: ok, thanks [06:51] 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] mardy: But generally, the goal is to not screw over people who rebuild, do local test builds, derive in other distros, etc, etc. === doko_ is now known as doko [07:09] 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 === psivaa is now known as psivaa-afk [07:57] dbarth: so, infinity suggested a change in the account-plugin-flickr debian scripts [07:57] dbarth: quoting from this morning: [07:57] 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] 09:39 < infinity> mardy: I'm rejecting based on that. Please fix. [08:04] mardy: ah ok [08:04] mardy: then can you file a bug with infinity's concerns, and i'll land asap [08:05] dbarth: why a second one? account-plugins didn't land, did it? [08:05] Can someone check if modemmanager is syncable? [08:05] There's some fairly important upgradeing fixes [08:05] mardy: it did [08:05] mardy: was tested and published yesterday [08:05] mardy: i merged them this morning, since we couldn't take back the packages anyway [08:06] dbarth: oh, you are right [08:06] dbarth: but the bug is still open [08:07] dbarth: and the merge proposal is not in "merged" status yet [08:07] dbarth: even though I see that the changes are now in trunk... weird... [08:15] doko: weird. yeah, Ill take a look. [08:30] Logan_: http://paste.ubuntu.com/7193182/ [08:32] Noskcaj_, hey === psivaa-afk is now known as psivaa [08:49] doko: so, have it fixed locally, wonder why it ever build. investigating if we changed the API there upstream ... [08:51] oh, we did. Well actually those cowboys at AOO changed the API and we followed suit ... [08:54] 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] infinity: ah, lintian autopkgtest succeeds now; thanks for pointing out the dep parsing bug [08:57] pitti: Yeahp, I got the spam about it being fixed. Thanks. :) [08:59] xnox: are you going to reupload your g+ apps or should I do that? [09:02] 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] pitti: The comment does start at the first column... [09:03] Oh, I missed the "but" there. [09:03] infinity: right, but it's in the middle of a continuation line [09:03] 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] it == adt-run [09:03] 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] pitti: And I'd say that dpkg is the authority on how to parse debian/control. [09:04] *nod*, hence I filed a bug against p-debian [09:05] 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] pitti: So, yay, thanks for the bug and the workaround. :) [09:07] didrocks: i can republish it, if the container/ua is fixed now. [09:08] cyphermox: that would be awesome! you're a start =) thanks. [09:08] xnox: yeah, you need to target the 14.04 dev1 framework though [09:08] xnox: to get oxide [09:09] didrocks: right, yeah i see ping from davmor2 about that. [09:22] xnox: see everyone loves the google+ [09:25] wow, G+ in the new browser is just lovely to use [09:25] working javascript makes such a big difference [09:26] ogra_: so easily pleased now get off G+ and get some work done ;) [09:26] haha [09:27] ogra_: and none of this I'm just "testing oxide" milarky either that's my excuse :P [09:28] heh [09:35] is there a way to get oxide on the desktop? [09:35] * xnox dist-upgrades first [09:35] xnox, i think that should get it for you (at least for the webapps) [09:36] seb128: why unity-control-center depends on ibus? [09:37] happyaron, because it writes to its gsettings schemas [09:37] I though of you when that was added [09:37] I guess we could handle the missing schemas and lower to a recommends or something [09:37] if recommends is doable then that'd be great. [09:38] happyaron, https://code.launchpad.net/~attente/unity-control-center/1288717/+merge/209982 [09:39] happyaron, btw https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1288717/comments/3 [09:39] Launchpad bug 1288717 in unity-control-center (Ubuntu) "/usr/bin/unity-control-center:6:g_assertion_message:g_assertion_message_expr:ibus_config_get_value:orientation_combo_changed:_g_closure_invoke_va" [High,Fix released] [09:39] happyaron, but you never bothered replying to my comment [09:39] happyaron, if you had you would have seen the change/new depends... [09:40] 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] seb128: well I'm being so busy recently dealing with all kinds of stuff... [09:42] happyaron, we all are... [09:42] :) [09:43] happyaron, anyway you have the why you asked for now ;-) === tkamppeter_ is now known as tkamppeter [09:49] 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] seb128: well the good thing is we got this fix: https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1297831/comments/18 [09:50] Launchpad bug 1297831 in Ubuntu Kylin "Input method set to ibus in Ubuntu Kylin, while fcitx is the desired default" [Critical,Fix committed] [09:51] seb128: so you are right, it's not on the top of my list. [09:53] happyaron, ok, good [09:53] 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] brendand, I would assume so, but check with #ubuntu-release [10:04] 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] Sweetshark, thanks, is that something we can get in Debian and sync? [10:09] 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] doko: s/langpack-en-us [10:10] doko: ... /language-pack-en-us/ :) [10:11] seb128: Ill hint rene at it (although he is not the maintainer there) [10:11] doko: sorry, I mean language-pack-en; we don't have by-country packs except for -zh [10:12] 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] Sweetshark, do you still want sponsoring to trusty? we can sync over from Debian once they fix it [10:14] seb128: lets wait for renes reaction first .. [10:15] Sweetshark, k [10:21] 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:21] bug 1293704 in kdepim (Ubuntu) "Kleopatra don't support s/mime" [High,Confirmed] https://launchpad.net/bugs/1293704 === vrruiz_ is now known as rvr [10:44] pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1301307 [10:44] Launchpad bug 1301307 in ubuntu-drivers-common (Ubuntu) "Empty vendor string for driver" [Undecided,New] [10:45] tseliot: ^^ [10:45] ogra_: are there any webapps that work as contained clicks with oxide? [10:45] cause updated g+ fails like shown in bug #1301305 [10:45] bug 1301305 in webbrowser-app (Ubuntu) "oxide fails to launch contained webapp" [Undecided,New] https://launchpad.net/bugs/1301305 [10:46] xnox, yes, the default shipped ones (gmail, facebook etc) ... and the browser itself is using it now [10:46] only webapps that havent been re-uploaded with the new framework added use the old way still [10:46] shadeslayer: I don't think there's a single vendor for that [10:47] tseliot: right, but then the UI just looks terribly broken [10:47] or atleast the KDE one does [10:47] shadeslayer: any pictures? [10:47] moment [10:47] 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] ogra_: maybe i need "webview" policy group. Let's see. [10:49] tseliot: http://im9.eu/picture/a19862 [10:50] tseliot: something else I noticed [10:51] shadeslayer: you might want to have a fallback such as "Unspecified vendor" for when that happens [10:51] tseliot: the pci values for Airport extreme is a subset of the one from linux-firmware-nonfree [10:52] /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] so maybe it would make sense to group them together? [10:53] shadeslayer: does the Airport extreme require linux-firmware-nonfree? [10:53] tseliot: yep [10:53] that or the other b43 driver [10:53] both work [10:54] shadeslayer: and what do you mean by "grouping them together"? [10:54] tseliot: under the same device :) [10:55] so that ubuntu-drivers devices shows Broadcom Airport Extreme with 2 drivers : b43 and linux-firmware-nonfree [10:55] oh, I see what you mean now [10:56] I guess that would make sense [10:56] pitti: ^ [11:08] oh ! [11:08] oh ! oh ! [11:08] video streaming inside the phone bowser works now !!! [11:17] new g+ is in the store review queue. [11:18] tkamppeter: awesome, thanks! [11:20] 6/win 15 [11:20] tsk === MacSlow is now known as MacSlow|lunch [11:42] hi, does anybody know which exact component is responsible for giving input-events to the applications? [11:46] dpm_: ping [11:54] hi dobey [11:54] dpm_: hi. do you know what the recommended way to build translations with under cmake would be? [11:54] is there a directory which can be used to store files which are cleared after a user's session ends? [11:55] intltool doesn't integrate with cmake [11:55] I've thought about XDG_RUNTIME_DIR, but that's not cleared on logout [11:56] mardy: delete the file when your process ends? [11:56] mdeslaur: I see you are here, maybe you know? ^ [11:56] * ogra_ hugs xnox [11:56] dobey: I want the file to persist across my process invocations, while in the same user session [11:56] mardy: I don't believe there are any [11:57] yeah, there aren't any [11:57] dobey, mdeslaur: that's also good to know :-) [11:57] 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] 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] xnox, external links dont open in the G+ app ... (not sure thats the app or the container) [11:57] mdeslaur: mmm... interesting! How can I know when the session started? [11:57] dpm_: ok, thanks [11:58] ogra_: i had to enable urlpatterns. At the moment login screens and google plus itself should stay in google plus. [11:58] mardy: I...uh....well....perhaps you can ask logind? /me isn't sure [11:59] mdeslaur: i thought we do cleate a fresh XDG_RUNTIME_DIR on each login... that's the whole point of it. [11:59] 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] xnox, well, it doesnt open any external pages ... (though i assume thats a drawback of the new browser) [12:00] ogra_: oh, well... not sure =) [12:01] 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] *misses [12:01] (i cant play it in the app) [12:01] ogra_: i have video profile. [12:02] weird [12:02] "policy_groups": [ [12:02] "networking", [12:02] "audio", [12:02] "video", [12:02] "location", [12:02] "webview" [12:02] ], [12:02] dpm_: ok. [12:03] xnox: doesn't look like it...stuff stays there [12:03] 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] in the app i see the loading animation ... and then it stops [12:04] dbarth, ^^^ [12:13] xnox: nope, if the directory exists, it's kept as-is [12:21] hmm, just reading the backlog [12:22] xnox: do you have apparmor rejects when trying to play that video? [12:23] xnox: it may also be that the app tries to play video fullscreen and fails [12:23] the youtube player i mean [12:23] dbarth, http://paste.ubuntu.com/7194027/ [12:23] previously it was not even trying, cause we were not detected as a "good enough" webview [12:23] smells like you need some apparmor love from jdstrand [12:24] ogra_: weird [12:24] (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] do you have policy_version 1.*1* ? [12:24] hmm, no idea [12:24] i see you have the webview group already [12:25] i'm on the latest image [12:25] you need both, ie add the webview p.g. and bump the policy_version to 1.1 [12:25] where do i check that ? [12:25] and declare framework 14.04-dev1 [12:25] manifest.json and .json [12:25] yes, i think thats what xnox did with his last upload [12:26] then it's a bug [12:26] http://paste.ubuntu.com/7194044/ [12:26] can you file and affect webbrowser-app, use [webapp-container] as a prefix [12:26] looks all fine [12:26] and i'll affect oxide and other if neede [12:26] d [12:27] (this was /opt/click.ubuntu.com/net.launchpad.click-webapps.gooogleplus/6/app.json) [12:29] dbarth: where have these rejects been happening? [12:29] dbarth: the silo or the archive? [12:30] dbarth, bug 1301351 [12:30] bug 1301351 in webbrowser-app (Ubuntu) "[webapp-container] embedded videos do not play in G+ app while they play fine in the browser" [Undecided,New] https://launchpad.net/bugs/1301351 [12:30] jdstrand, latest image with the latest G+ app [12:31] (both updated today, using oxide now) [12:31] jdstrand, see the bug above [12:32] well, it should be against apparmor-easyprof-ubuntu [12:32] * jdstrand changes [12:32] jdstrand, well, not sure, it might be two bugs ... (external links ... and video playback) [12:32] dbarth: fyi, I was trying to work out the final profile changes when I hit that crasher bug, so was blocked [12:33] but I'll get it worked out === _salem is now known as salem_ [12:35] dbarth, m.youtube.com doesnt play back videos at all ... tapping on play just reloads [12:35] (funny because the same video embedded in a G+ post plays just fine) [12:42] jdstrand: would i need to reupload the app? i believe i have all the correct intentions declared in the policy groups. === MacSlow|lunch is now known as MacSlow [12:48] xnox: for that bug ^? no [12:50] 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] jdstrand: ah cool =) didn't know how/when policies are regenerated =) if all gets fixed with an image update, that's cool! =) [12:50] like, really _cool_ =))))) [12:51] xnox, are you still looking at bug 1160079 ? [12:51] bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079 [12:54] 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] smoser: i'll upload the cloud fix later today. [12:55] xnox, thanks, that would be awesome. [13:56] seb128: would you mind looking at the 1.1.1-0ubuntu8.9 libvirt awaiting acceptance for saucy-proposed? [13:56] hallyn, I'm not part of the SRU team [13:56] d'oh, i was looking at the wrong comment, sorry [13:56] bdmurray: ^ [13:57] no worry ;-) [14:05] ogra_: do you have a couple minutes to help me with the apparmor denials? [14:05] jdstrand, i can try [14:06] ogra_: ok, in /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6 [14:06] ogra_: you'll see these rules: [14:06] /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cx -> oxide_helper, [14:06] /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cx -> oxide_helper, [14:06] ogra_: can you change them to: [14:07] /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cxmr -> oxide_helper, [14:07] /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cxmr -> oxide_helper, [14:07] ogra_: when done, please do: sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6 [14:07] ogra_: then relaunch the web app [14:09] ogra_: oh, I forgot one. way down you'll see this rule: [14:09] /usr/lib/@{multiarch}/oxide-qt/oxide-renderer rmix, [14:09] under it, can you add: [14:09] @{PROC}/sys/kernel/yama/ptrace_scope r, [14:09] Error: "{PROC}/sys/kernel/yama/ptrace_scope" is not a valid command. [14:10] ogra_: then do 'sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6' and relaunch the app [14:13] jdstrand, no change ... [14:13] let me reboot the phone [14:13] ogra_: are there denials? [14:13] havent seen any when tailing syslog [14:13] ok, then it is like you said-- two bugs [14:13] but the video doesnt play [14:14] well, the other would be "not opening external links" [14:14] heh, well, I mostly mean I can fix my bug [14:16] jdstrand, i dont really get why it plays flawless when opening G+ in the browser ... might not be apparmor related though [14:17] it is probably the webapp-container [14:18] I'll direct you to alex-abreau and dbarth [14:18] let's go to #webapps [14:18] (where they both are) [14:18] well, dbarth asked me to file the bug, he is aware [14:19] * dholbach hugs mvo [14:19] no need to be pushy, it never worked before ... having it working in the browser now is a massive improvement already :) [14:20] How can I run a/the click user hook/s manually? [14:20] I got an apport report from one of them [14:23] click hook run-user, got it [14:25] mvo: ping [14:25] barry: hello! pong [14:25] 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] apt-get install gdebi-core [14:26] The following packages have unmet dependencies: [14:26] gdebi-core : Depends: python3:any (>= 3.4~) [14:26] [14:26] that's in a fresh sid chroot, but on a debian system w/gdebi-core already: [14:26] gdebi : Depends: python3:any (>= 3.4~) [14:26] Depends: gdebi-core (= 0.9.5) but 0.9.4 is to be installed [14:26] [14:27] barry: oh, let me have a look [14:27] thanks [14:28] mvo: ah, i see xnox committed (probably) a fix in bzr [14:28] barry: and uploaded... [14:28] :) thanks xnox ! [14:29] barry: it seems that X-Python3-Verions: >= 3.4 was actually honored and impossible dependencies got generated =) [14:29] xnox: thanks! will you sync once it lands in debian? [14:29] barry: it's not needed on ubuntu. [14:29] barry: as our python3 is 3.4 [14:29] xnox: right, it didn't break us, but it still might be good to keep in sync [14:30] xnox, mvo anyway, thanks! [14:31] gosh, an mvo [14:40] hey Riddell === salem_ is now known as _salem [14:48] 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] hallyn: should that supercede the existing libvirt (which appears to have ftbfs btw) [15:19] bdmurray: yes [15:19] hallyn: got it [15:19] i goofed - the pach i was backporting in 8.8 had a hunk applied int he wrong effing fn [15:19] thanks [15:37] 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] jibel: thanks, that ought to be shallow. let me see if i can craft a fix [15:42] pitti: That's great, but why do you tell me about it? Did I ask about that recently? [15:43] Seriously, I don't know. I forget many things I ask. [15:44] jibel: thanks [15:44] barry: let me know if you want me to have a look instead [15:45] 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] mvo: or something like it ;) [15:45] barry: aha, the new "shadowing" warning :) [15:45] barry: sure thing, happy to do that [15:46] mvo: yep ;) thanks! [15:46] juliank: hm, I thought you did; sorry if I mixed that up with someone else [15:46] juliank: sorry, I was [15:47] 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] pitti: No problem. [15:55] bdmurray, FYI, I reproduced bug 1286161 with the clone from the OP [15:55] bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,Confirmed] https://launchpad.net/bugs/1286161 [15:58] barry: uploaded [15:59] mvo: thanks! [16:04] jibel: oh, anything interesting? [16:09] bdmurray, apart that it is reproducible with packages from the archive without any PPA, nothing else yet [16:17] jibel: oh, you might interested in bug 1290584 regarding apt-clone [16:17] bug 1290584 in apt-clone (Ubuntu) "apt-clone restore should have a use my mirror option" [Undecided,In progress] https://launchpad.net/bugs/1290584 === _salem is now known as salem_ [16:46] xnox: all these "ValueError: invalid literal for int() with base 10:" in ubiquity, is that real, or just a transient thing? [16:46] xnox: i. e. does it make sense to retry a few times, or is that really broken? [16:46] xnox: sounds like it's trying to interpret a nonexisting debconf key as a number? [16:47] but why would removing the u1 bits affect partman.. [16:49] pitti: haven't looked. That error messages comes up for any reason when debconf backend goes away. [16:49] (and ubiquity still tries to interract with it) [16:56] hallyn: is 2.0 still on the table for trusty? it gets kind of tight now [16:57] 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] 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] hallyn: ah, you were waiting for the final, not on testing any more? [16:59] pitti: what do you mean? [16:59] hallyn: yes, then uploading a pre-release snapshot sounds fine [16:59] pitti: im' still uploading new versions to that ppa every other day or so [16:59] hallyn: the diff from the snapshot to final is presumably much smaller than 1.7 to 2.0 final? [17:00] oh, yeah, i definately do not want to do a diff on top of 1.7 [17:00] oh, need to run out, taxi going back to the hotel; good night everyone [17:00] pitti: good night === bfiller is now known as bfiller_afk === Logan__ is now known as Logan_ === bfiller_afk is now known as bfiller === roadmr is now known as roadmr_afk === mhall119_ is now known as mhall119 [18:21] mlankhorst, tjaalton: xorg ping [18:27] doko: xorg pong [18:28] tjaalton, two things: [18:28] https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5735335 the xorg-gtest ftbfs [18:30] 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] ugh [18:33] i bet xorg-gtest builds fine on sbuild.. [18:33] lp is picky [18:34] no idea about vnc4.. i'd just drop it but someone might whine [18:35] stgraber: could you have a look at bug 1300654? [18:35] bug 1300654 in isc-dhcp (Ubuntu) "Prompt to update unmodified configuration file during upgrade from Precise to Trusty" [High,New] https://launchpad.net/bugs/1300654 [18:36] bdmurray: I'm aware of it === roadmr_afk is now known as roadmr [18:46] stgraber: great === buxy_bak is now known as buxy === jackson is now known as Guest78494 === Guest78494 is now known as Noskcaj_ [19:50] 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] mwhudson: Try the patch in the bug you filed? [19:51] well yes, that will certainly help [19:51] mwhudson: (assuming it was tst-tls5 that failed again) [19:51] or is certainly worth trying at least [19:51] yeah, same failure [19:52] i wonder if the newer kernel grows the heap up in some other circumstance than 3.8 [19:52] 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] yeah, focus focus [19:54] building [20:15] hallyn: *poke* [20:17] 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] hallyn: Also, you dropped the static build (intentional?), and your changelog claims you added -static when I think you meant -shared. [20:18] stgraber: ^ If you want to address any/all of that for hallyn... === alesage|afk is now known as alesage [20:22] mvo: Say, why does unattended-upgrades have .pyc files in the source? [20:46] 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:46] Debian bug 741467 in src:unattended-upgrades "unattended-upgrades: source package contains generated files (*.pyc)" [Minor,Fixed] [20:47] While I'm not mvo, this might still help. [20:48] 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] 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] what are the chances of still patching libtool to not strip gccs -fsanitize stuff in trusty? [20:52] hm I guess its not super important as you can get the links indirectly in your main application [20:53] 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] yes [20:54] just tested it, indirect links seem to work alright anyway [21:02] infinity: feh, so i should just be moving the actual file by hand in debian/rules? [21:03] 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] hallyn: Sure, don't care much about the static lib, was just curious. [21:04] 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] hallyn: Should be able to do that fairly cleanly in a dh_auto_install override. [21:06] (Credit to slangasek for finding the expat rules snippet) [21:06] ok, thanks. I'll change that tongiht and re-push. [22:26] robert_ancell, pyexiv2 ftbfs on ppc64el [23:21] 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] or does anybody know who is US/west based who can allocate silos... cyphermox ? [23:27] 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] stgraber: hm, let me check who those two should go via. Maybe i can ping about them tomorrow. [23:29] cyphermox is my usual suspect but it's past our eastern time EOD so he may be gone for dinner or something [23:32] i've been chatting with dbarth about the webapps one, not sure who is responsible for legacy applets. [23:33] stgraber: excellent. "indicator-applet" has no owner =) but it has been reviewed by ~unitish people. Could you silo up that one? [23:34] xnox: since they're related, they probably should go in the same silo, let me add you to the spreadsheet at least [23:34] 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] 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] unity7 is bundled with other bug-fixes however, so i wouldn't want to piggy back on top of that. [23:36] bregma: can you release/land indicator-applet? [23:36] 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] bregma: this is assuming indicator-applet are ~= unitiish =))) [23:37] stgraber: could you ask? i'm not in that channel at all. [23:37] xnox: yeah, just joined and asked (since we pretty much never land anything through the citrain I don't idle in there) [23:38] xnox: do you have any testsuite I should link in there? [23:38] stgraber: it's desktop only, btw. [23:38] 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] (xubuntu is the prime user of indicator-applet) [23:39] 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] stgraber: thanks a lot! i'll watch that spreadsheet. [23:44] doko, what is the easiest way to test on ppc64el? [23:46] robert_ancell, ssh porter-ppc64el.canonical.com [23:48] doko, any chance of getting git installed on there? [23:51] robert_ancell: schroot -c trusty-ppc64el [23:51] robert_ancell, afk now [23:51] robert_ancell: git's in the schroot [23:51] robert_ancell: (and you can "sudo apt-get install" things) [23:52] ah, thanks [23:57] xnox: we've got a silo [23:58] \o/ [23:58] 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] cjwatson: was i using our porter boxes somehow wrong? (e.g. a session/snapshot is not created for me that gets auto-cleaned up)