[02:39] <psusi> is there a way to get polkit to retain the user home dir?
[04:57] <pitti> Good morning
[07:12] <dholbach> good morning
[07:56] <didrocks> doko__: hey, seb128 and I looked at google-mock for respecitively 30 min and 1h without finding out how to fix the google-mock FTBFS (pthread failures). Tried to add various -pthread (already included) before/after the linkage, tried to look if upstream has anything as well, tried to compare with debian, but the FTBFS is there as well, various google search… do you think you can give us an hand?
[07:59] <didrocks> tvoss: FYI ^
[08:00] <tvoss> didrocks, thanks
[08:11] <czajkowski> aloha
[08:11] <czajkowski> If I buy a brand newlaptop to wipe and install Ubuntu on it, will I run into any issues with secure boot?
[08:12] <czajkowski> looking at buying a X1 Carbon and just want to check to see if there is anything I should avoid
[08:12] <hyperair> ugh x1 carbon
[08:12] <hyperair> no ethernet.
[08:17] <czajkowski> oh now never even thought about that or need for one
[08:17] <czajkowski> altough it can be nice to have as a back up
[08:18] <czajkowski> bugger
[08:19] <hyperair> yeah you'll have to go out and get a USB-3 dock, or ethernet dongle
[08:19] <czajkowski> aye you can get one via  a USB adaptor
[08:19] <hyperair> it's still going to be capped at 100BaseT though
[08:20] <hyperair> USB-3 ethernet dongles are incredibly hard to find
[08:20] <hyperair> (at least here in singapore)
[08:21] <czajkowski> nods gotcha
[08:21] <czajkowski> am more concerned over the secure boot issues I may run into
[08:21] <soren> If ethernet is an emergency backup (ie wifi is the normal connection type), being capped at 100 Mbps doesn't sound like a big issue.
[08:24] <czajkowski> soren: more of a plan B back up
[08:35] <xnox> czajkowski: if you use iso or dd the iso onto usb stick, it should all just work. You must be able to disable secure boot using bios/firmware screens.
[08:43] <greyback> czajkowski: quoting the wiki page, SecureBoot might probably work. https://help.ubuntu.com/community/UEFI#SecureBoot
[08:43] <greyback> czajkowski: and this person looks to have had success: https://x1carbon.wordpress.com/2012/10/16/install-linux-on-lenovo-x1-carbon/ - tho it may have been an earlier model
[08:45] <greyback> http://vasilezaremba.com/installing-ubuntu-12-10-on-lenevo-x1-carbon/ too
[08:50] <czajkowski> xnox: greyback cheers
[08:50] <greyback> happy buying!
[09:00] <infinity> czajkowski: Several of us have Carbons, and they seem to work just fine.
[09:00] <infinity> czajkowski: (Not I, but many others)
[09:40] <seb128> zul, infinity, mdeslaur: hey, does one of you plan to merge apache2 on Debian? there is a bunch of packages in the archive depwaiting on dh-apache2 which is a new helper shipped in the current Debian version
[09:45] <cjwatson> If you do, then be aware that the Apache 2.4 transition is a large and complex one
[09:45] <cjwatson> I think we probably ought to take it, but somebody needs to actually manage that transition
[09:46] <cjwatson> cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958
[09:47] <seb128> cjwatson, thanks, I was not planning to ... which is why I pinged the people who touched apache2 last ;-)
[09:47] <seb128> but good to be aware that it needs planning
[09:47] <cjwatson> Sure, which is why I didn't specifically address my comment to you :-)
[09:50] <seb128> ;-)
[09:52] <seb128> jamespage, doko, whoever looks after java: jarjar in saucy depwait on libasm4-java which is in universe, want to file a MIR for this one? ;-)
[09:54] <pitti> @pilot in
[09:54] <infinity> seb128: I was thinking of merging and starting the transition after Alpha1, but it depends on how far Debian's gotten (or how many patches there are in the BTS), since I don't particularly want to do the whole thing myself.
[09:56] <seb128> infinity, ok, no hurry, as said I just noticed that a few packages are depwaiting on it in saucy ... but we can as well wait for Debian to do a bit more of the heavy lifting ;-)
[09:57] <infinity> seb128: *nod*... We should definitely do it this cycle, I'll keep an eye on it and start it when it seems sane.
[10:06] <pitti> cjwatson: oh, you are handling the casper sponsoring? I was just about to do it, but saw your approval
[10:07] <pitti> cjwatson: ah no, that was -cdimage, not the casper branch, nevermind
[10:46] <pitti> mvo: hey Michael, how are you?
[10:47] <pitti> mvo: there's a bunch of updates in lp:software-properties, is that good for uploading, or do you know of blockers?
[10:50] <pitti> mvo: it works fine here after some basic testing, at least
[11:04] <mvo> pitti: I think its fine, go ahead and upload (I can do that too later if you want)
[11:37] <tvoss_> pitti, ping
[11:50] <pitti> mvo: done
[11:50] <pitti> tvoss_: hey
[11:51] <tvoss_> pitti, hey there :) I'm looking into a VT_SETMODE ioctl resulting in an Input/Output error
[11:52] <tvoss_> pitti, the behavior people are describing hints towards a race, but I'm not a 100% convinced
[11:53] <tvoss_> is there any way to get a little more information about the cause of the error
[11:53] <tvoss_> ?
[11:53] <cjwatson> The notes in the comments at the top of /lib/udev/console-setup-tty may be helpful
[11:53] <cjwatson> (or may not)
[11:54] <pitti> tvoss_: first time I hear about VT_SETMODE, I'm afraid; what's the context there?
[11:56] <tvoss_> pitti, Mir has to adjust the vt mode to process-controlled (as opposed to kernel controlled), and specify some callbacks to manage its state on vt switches
[12:02] <cjwatson> I wonder if you're accidentally trying to perform that ioctl on a hung-up tty
[12:05] <cjwatson> TBH for undocumented console ioctl failures you generally have to either attempt to divine the problem from kernel source or else rebuild the kernel with extra printk debugging
[12:16] <apw> cjwatson, it is possible i have another report of linux-image-generic not being installed after install, do you know of any cases of this still occuring, and if it is would that likely be ubiquity ?
[12:17] <cjwatson> apw: I don't know of one, but I'm not sure I would :)
[12:17] <cjwatson> apw: Find out first whether it was a serverish or a desktopish install
[12:18] <apw> cjwatson, they are saying "live USB key" and it is a laptop they are installing, so i belive it is a desktop job
[12:18] <apw> bug #1172852
[12:18]  * apw tries to raise the reporter on irc as well
[12:20] <smb> Since it says life usb key. I would assume not-server
[12:21] <cjwatson> I'd suggest getting /var/log/installer/syslog and perhaps also /var/lib/dpkg/status then
[12:21] <doko> didrocks, Daviey, Laney: did one of you ping me about the ipxe ftbfs? looks like an issue in ipxe, so the proposed fix seems to be ok
[12:21] <Laney> I don't have any memory of that
[12:21] <Laney> doesn't mean that I didn't ...
[12:22] <didrocks> doko: neither did I, I pinged you about google-mock vs pthread
[12:22] <doko> didrocks, can't remember that one either ;)
[12:23] <didrocks> doko: here it is: http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-devel.html#t07:56 :)
[12:23] <Laney> btw, I'm trying gtk3 with 4.7 to see if that really is it
[12:26] <doko> didrocks, you need to build libgtest with -pthread, not just the executables for the unittests
[12:26] <seb128> Laney, ?
[12:26] <Laney> yes?
[12:26] <seb128> Laney, gtk3 works fine with gcc 4.8 before those linaro changes got merged in
[12:26] <Laney> you narrowed it down more?
[12:26] <seb128> well, to one revision
[12:27] <seb128> not sure how gcc 4.7 is going to be useful
[12:27] <doko> well, to one gcc upload
[12:27] <Laney> it's useful because you can upload using that on armhf in the interim
[12:27] <seb128> right, sorry "revision" -> "upload"
[12:27] <seb128> Laney, -O0 workaround it
[12:27] <seb128> so we can use that was well
[12:27] <doko> did you narrow it down even more?
[12:27] <seb128> doko, ^ just that -O0 works
[12:27] <seb128> -O1 or -O2 breaks
[12:27] <seb128> not sure how to narrow it further down
[12:28] <doko> is there a single test case which you can run?
[12:28] <doko> well, it's the game about combining O0 and O2 object files until you find the offending one
[12:28] <seb128> not really, it's basically "build libgtk.so, run one of the tests, it fails with new gcc"
[12:28] <seb128> I don't know how to do that
[12:29] <seb128> and libgtk has a full stack of object files
[12:29] <seb128> I tried to "touch .c" on random sources
[12:29] <seb128> but that feels like random poking going nowhere
[12:29] <doko> I know, it's a time consuming task ...
[12:30] <doko> did you open an issue for that?
[12:30] <seb128> no, I will do it in a bit, I was waiting to get a bit more details
[12:30] <seb128> e.g trying to optimization
[12:30] <seb128> I poked enough around to open a bug with some content at this point
[12:31] <cjwatson> Bisecting -f options can help too, although it's not always the case that you get a clean bisection there
[12:31] <seb128> I'm not sure I will be able to spend more time on that anyway, I almost spend a day on it already
[12:31] <seb128> cjwatson, you mean?
[12:32] <cjwatson> I mean that much of the difference between -O0 and -O1 can be controlled in more fine-grained ways using a variety of -ffoo options
[12:32] <seb128> oh
[12:32] <seb128> is the list of options described somewhere?
[12:33] <cjwatson> http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#Optimize-Options
[12:33] <seb128> thanks
[12:33] <mlankhorst> brrr, rebuilding mesa 4 times again locally because the sru was preempted by a security update :/
[12:33] <cjwatson> Like I say, it isn't always perfect - I don't think everything's independently controllable, and some of the optimisation options interact
[12:33] <cjwatson> But it can sometimes help
[12:33] <apw> cjwatson, confirmed it is a live cd install on a normal system, i've asked them to attach the said files
[12:34] <cjwatson> ok
[12:34] <pitti> didrocks: hm, the bunch of unity-ish uploads in https://launchpad.net/ubuntu/raring/+queue?queue_state=1 look like an error in the autolanding? or was that actually supposed to be a massive SRU?
[12:34] <doko> right, bisecting options options helps too, but it won't help much finding the location
[12:35] <seb128> cjwatson, doko, Laney: I will try to poke around a bit more, but that seems like a time sink work and I've already spend more time on than that I should (or rather delayed touch work that I should be doing) ... I might just end up filing the bug and build gtk with -O0 on armhf as a workaround
[12:36] <seb128> pitti, that stack seems about right
[12:37] <seb128> pitti, they are all components from a stable series with SRU bugs manually pushed (I think sil2100 worked on that landing)
[12:37] <doko> pitti, infinity: I was wondering if we can build locales again from the eglibc sources, or what would be needed for that
[12:37] <pitti> seb128: ok, thanks for confirming (just saying, the SRU team won't be happy about that)
[12:37] <seb128> pitti, why wouldn't them?
[12:38] <pitti> doko: I think we can actually; this was originally split back in the ancient days for adding locale editing support to LP, but this won't happen, and it's not very important
[12:38] <pitti> doko: we have a couple of patches to locales which would need to go to eglibc then, plus our modificaitons to locale-gen, but not much else really
[12:38] <seb128> pitti, it's only 10 sources, we do land more than that manually when we do e.g a GNOME minor releases round or when KDE does a point release update
[12:38] <pitti> seb128: there's no debdiff nor changelog in the queue, so a bit hard to review
[12:39] <pitti> anyway, it just caught my eye during my sponsoring shift
[12:39] <seb128> pitti, yeah, that's a known issue, but the staging ppa which is used for copy should have the diff
[12:39] <doko> pitti, cool, can you coordinate with infinity so that he may get these included upstream in 2.18 maybe?
[12:40] <pitti> doko: ah, maybe the eglibc maintainers are more open to that; I sent all our locale changes to glibc, and some were even accepted, but you know Ulrich.. :)
[12:40] <pitti> doko: does eglibc have a separate bug tracker? I can re-send them there
[12:41] <doko> pitti, no, but carlos o donell is now doing glibc release management
[12:41] <pitti> most of our patches are just taken from Debian's eglibc package, but we have some 5 extra
[12:41] <apw> cjwatson, i assume if we see the below, this is not good:
[12:41] <apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-generic ...
[12:41] <apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-headers-generic ...
[12:42] <cjwatson> apw: Probably not but I have a policy of not looking at partial log fragments :-)
[12:43] <apw> cjwatson, it is attached in full to the bug
[12:43] <apw> :)
[12:44] <cjwatson> apw: Ah, that's bug 1070427 then
[12:44] <cjwatson> Not fixable without a 12.10 point release ...
[12:44] <apw> cjwatson, ahh ok, nasty
[12:45] <doko> didrocks, are you looking at google-mock?
[12:47] <pitti> @pilot out
[12:51]  * dholbach hugs pitti
[13:05]  * pitti hugs dholback
[13:23] <didrocks> dholbach: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
[13:23] <didrocks> pitti: no, it's a SRU that has been reuploaded 3 times because the package went invalid after a while (the syncs)
[13:23] <didrocks> pitti: it's indicators + unity srus
[13:24] <dholbach> didrocks, are you sure you wanted to ping me about it? :)
[13:24] <didrocks> dholbach: no, too many "d" on this channel!
[13:24] <didrocks> "oh wait" :)
[13:24] <didrocks> doko: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
[13:25] <dholbach> yeah, thought so - the other German whose nick starts with a'd' :)
[13:25] <dholbach> or "the other guy in Berlin..." :)
[13:25] <didrocks> dholbach: I was close you will notice!" :)
[13:25] <dholbach> didrocks, if it's early enough, I'll meet doko on Friday - I can let him know there ;-)
[13:26] <didrocks> dholbach: ahah, let's plan on that then! :)
[13:26] <dholbach> brilliant
[13:26]  * didrocks hugs dholbach
[13:26]  * dholbach hugs didrocks back
[13:33] <seb128> doko, Laney: ok, I opened https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1194123
[13:44] <mlankhorst> can some core dev sponsor xxv-intel-lts-raring and mesa-lts-raring from http://people.canonical.com/~mlankhorst/lts-raring.tar ? Keep in mind that you need to use dpkg-buildpackage with -v to get all the changes from the previous lts-raring entry, else the sru will get rejected again :/
[14:04] <tseliot> mlankhorst: if you build the sources with "-v" for me, I'll gladly get your sources, sign them and upload for you
[14:06] <mlankhorst> tseliot: the .changes in there should be correct
[14:07] <tseliot> mlankhorst: ok, let me have a look
[14:10] <pitti> fginther: so I was mostly wondering whether the ap-gtk tests should run at package build time or not
[14:11] <pitti> fginther: doing so requires xvfb; it currently works, but it's rather slow and requires disabling one check
[14:11] <fginther> pitti, I wouldn't go done that path of running xvfb during package build...
[14:11] <pitti> fginther: if not, I'd like them to run at least for merge proposals (CI); but I don't know how to integrate them there
[14:12] <pitti> fginther: but do you agree to the part of integrating it into "make test"/"ctest"? that makes local development a whole lot simpler
[14:12] <fginther> pitti, for lp:autopilot, the tests were split into 'unit' and 'functional' tests. The unit tests run during package build and don't require any X interfaces.
[14:12] <pitti> fginther: ok, I don't have that for ap-gtk, as by its nature all tests are integration tests
[14:13] <fginther> pitti, I do agree an making it easier for devs to run.
[14:13] <fginther> hmm
[14:13] <pitti> fginther: or rather, as long as we can do blackbox testing through the AP interface, I'm not that keen on encoding particular implementation details in unit tests
[14:14] <pitti> fginther: I can just change the dh_auto_test rule to not run the tests, so we can keep ctest without having to run it during package build
[14:14] <doko> didrocks, could you point me to your fix attempt?
[14:14] <pitti> fginther: so if we don't run them during package build, how can I ensure that they run for MPs?
[14:15] <fginther> pitti, we should be able to add them to the daily-release integration testing
[14:15] <didrocks> doko: I have a source in /tmp/, want me to upload it? I tried several autoreconf and modification of Makefile.am, but not sure that will give you anything
[14:15] <didrocks> doko: basically, adding -pthread at multiple place and trying to executed the failing g++ line manually, switching the args
[14:15] <fginther> pitti, we also have ways to run them during MP, but it's a bit clunky right now, so we only do it for a handful of packages
[14:16] <pitti> fginther: hm, isn't that the main point of doing CI?
[14:16] <pitti> fginther: in this case, perhaps we should keep the tests during package build for the time being? that'll run them in MPs too (I got a reject the first time, then added the missing build deps, and it succeeds now)
[14:16] <fginther> pitti, the ci infrastructure is geared toward unit tests. running UI tests requires a lot of infrastucutre
[14:17] <pitti> fginther: ah, I thought we'd use the same infrastructure for upstream CI as for the distro autolanding
[14:17] <pitti> (as they are essentially the same test suites)
[14:17] <fginther> pitti, we're not there yet :-)
[14:17] <pitti> fginther: understood :) (sorry, I'm still not quite familiar with all the details behind that)
[14:18] <fginther> pitti, I'll take a look at the MP and do some testing through jenkins. If there are no issues, there is no reason not to run the tests during package building
[14:18] <pitti> fginther: so it sounds like we should keep the "xvfb-run ctest during package build" for now? It succeeds for the full test suite (https://code.launchpad.net/~pitti/autopilot-gtk/add-tests/+merge/171036)
[14:18] <fginther> pitti, yes. I'll make sure it runs, then comment in the MP
[14:19] <pitti> fginther: thanks (both MPs have links to jenkins build, FTR)
[14:19] <pitti> fginther: locally I test in sbuild, that should be reasonably similar
[14:20] <fginther> pitti, thanks. I'll get back to you
[14:20] <pitti> fginther: ack, thanks to you
[14:20] <tseliot> mlankhorst: uploaded
[14:21] <mlankhorst> thanks
[15:01] <seb128> Laney, sorry, not sure how much that spammed
[15:01] <seb128> stupid website/firefox
[15:01] <Laney> a lot
[15:01] <Laney> :P
[15:01] <seb128> I selected one line to copy but it seemed to have taken the whole file
[15:02] <seb128> and IRC isn't clever enough to limit the paste
[15:02] <cjwatson> It didn't spam everyone; I only saw you quitting
[15:02] <seb128> cjwatson, it was on #ubuntu-desktop
[15:02] <cjwatson> Ah
[15:02] <cjwatson> Your IRC client might not be clever enough.  irssi is :-)
[15:02] <seb128> I'm writting here because I'm not sure if spamming is still ongoing :p
[15:26] <smoser> how often does the auto sync occur ?
[15:28] <mlankhorst> bdmurray: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1100586 .. irony
[15:29] <cjwatson> smoser: Every six hours; currently disabled, see https://lists.ubuntu.com/archives/ubuntu-release/2013-June/002422.html
[15:29] <xnox> smoser: if it's already available at pad.lv/d/package, and is needed, then you can use syncpackage command ;-)
[15:32] <smoser> xnox, yeah, i was aware i could do it. just didn't know why it didn't just happen.
[15:32] <smoser> i think i'm ook waiting until tuesday morning.
[15:33] <smoser> thanks cjwatson xnox
[15:35] <bdmurray> mlankhorst: it'd be ironic if I were running Quantal, but the description says I was using 13.04.
[15:36] <mlankhorst> ah :p
[15:36] <mlankhorst> just accept I guess
[16:06] <didrocks> cjwatson: hey, small and probably a dummy question. There are tracers tools (they are libs) using lttng to bind mirserver/mirclient to some kernel tracing calls. I put them in a mir-test-tools
[16:07] <didrocks> cjwatson: I, of course, then get those lintian warnings: http://paste.ubuntu.com/5795887/
[16:07] <didrocks> the 3 first are "wanted" (they are not real consumer libs anyway), but the last one shows that dh_makeshlibs is ignoring this package it seems
[16:07] <didrocks> even forcing the call with -pmir-test-tools shows that it doesn't produce the postinst, postrm
[16:08] <didrocks> so apart from making the ldconfig call manually in postinst, postrm, I'm out of ideas, would you know more?
[16:08] <didrocks> (does dh_makeshlibs filters on package name, I tried looking if there was some algorightm like starting with "lib", but didn't get any luck?)
[16:13] <cjwatson> didrocks: Can't you put them in a private directory instead, if they're not meant to be on the system runtime linker path?
[16:14] <didrocks> cjwatson: I think lttng needs them to be on a system runtime path
[16:14] <cjwatson> didrocks: e.g. /usr/lib/man-db/libman.so doesn't cause a problem
[16:14] <didrocks> tvoss: would know more ^
[16:50] <hyperair> ScottK: regarding bug #1193667, would it be too invasive if i could the BPM detection module in an SRU here?
[17:01] <jdstrand> jjohansen: hey, did you figure out a way to install a kernel on the touch image without regenerating it? if so, I can help you test aa3 kernels on mako and grouper
[17:02] <jjohansen> jdstrand: heh I haven't gotten that far yet
[17:02] <jdstrand> jjohansen: if that would be helpful that is.
[17:02] <jdstrand> jjohansen: ack, let me know if I can be of assistance
[17:02] <jjohansen> jdstrand: so no I haven't yes that would be helpful
[17:03] <jdstrand> k
[18:28] <MDesigner> hey guys, who can I contact w/ regards to all things Ubuntu audio? (sound effects, etc)
[18:37] <seb128> MDesigner, hi, try TheMuso or diwic
[18:38] <diwic> MDesigner, hi
[18:38] <fhf> hello all I have a problem with packaging: I need to copy icon to particular dir and I add "cp" to "rules" file http://paste.ubuntu.com/5796280/ but it gives me error "no such file or dir" and it cannot copy icon http://paste.ubuntu.com/5796283/ any1 can help?
[18:44] <tvoss> ScottK, ping
[19:00] <fhf> hm any genius at packing can help?
[19:30] <MDesigner> argh. was in a conversation w/ diwic but he split before I got off the phone. he said I should talk to the design team. so… now who do I contact? :)
[20:09] <hallyn> pitti: hey, do you remember the udev bug which caused debootstrap to leave a udevd running from the install?
[20:10] <cjwatson> Bug 1182540
[20:11] <cjwatson> It wasn't a udev bug in the end
[20:11] <hallyn> oh right.  thanks!
[21:22] <stgraber> cjwatson: meetings minutes are in the moderation queue
[21:22] <stgraber> *meeting
[21:23] <cjwatson> poked
[21:23] <stgraber> thanks