[00:54] <pianogmx> question for developers, I am going to school for programming but how can i find a project team to mentor me?
[00:58] <pianogmx> anyone?
[01:01] <sarnold> pianogmx: best would be to find something that interests you, find a missing feature or a bug that bothers you, and offer a patch to try to fix it..
[01:03] <pianogmx> sarnold, so if I wanted to do like useful utilities like maybe xchat, how would I go about starting then?
[01:05] <sarnold> pianogmx: probably in that case you'd want to find the upstream code source, check it out of whatever version control they use, build it locally, test it out, try to figure out how to add whichever features you want, and perhaps ask on irc or mail lists if you need a hint about where to look in the source code for related code...
[01:05] <pianogmx> okay ima do some research, and idle here for a bit
[01:06] <sarnold> cool :)
[01:33] <syntroPi> is there any tablet around which is supported by ubuntu with normal desktop ui like unity and gnome shell?
[05:13] <pitti> Good morning
[06:09] <dholbach> good morning
[06:11] <dylan-m> Good morning, dholbach! :)
[06:11] <dholbach> hey dylan-m
[06:54] <vipzrx> morning
[08:22] <pitti> infinity: btw, has it ever been discussed to run the soyuz builds under eatmydata or setting that dpkg option for unsafe io? considering that installing the build deps takes like half of the build time for small packages, that might considerably lower the PPA build lag?
[08:51] <xnox> pitti: unsafe io at dependency installation should be ok. running the whole build under eatmydata will make upstart testsuite fail and possibly others as it actually relies on fsync() working.
[08:52] <xnox> (also upstart testsuite fails if the whole build is done in tmpfs as well....)
[08:52] <pitti> so, unsafe-io then :)
[08:52] <pitti> but FTBFS in tmpfs sounds like a bug
[09:01] <Daviey> xnox: Why does eatmydata fail the testsuite?
[09:01] <xnox> pitti: upstart tests gazzion ways one can modify a conffile and makes sure it's reloaded when changes via inotify or not. things have improved with 1.9, but I am still building 1.8 for the distro.... Will revisit that pest once 1.9 lands for the distro.
[09:01] <pitti> xnox: oh, our tmpfs doesn't support inotify?
[09:01] <xnox> pitti: i believe it does.
[09:01] <xnox> that's the funny bit.
[09:03] <xnox> Daviey: eatmydata makes fsync() not actually fsync() and hence data is not written out to disk when one requests for that to happen. Apart from that, I was not spending more time debugging it.
[09:04] <xnox> I'm glad that running test-suite in parallel works fine with 1.9 and up, and does race itself =)
[09:07] <jibel> python testsuite failed for the same reason and this is why I disabled eatmydata in package testing.
[09:09] <pitti> oh, python3.3's autopkgtest succeeds now, great!
[09:37] <Daviey> xnox, jibel: Ugh, that is rubbish.  I was hoping to use eatmydata more.
[09:40] <xnox> Daviey: there is no magic in what eatmydata does, it really trades IO speed for reliability. I run all of my sbuilds on tmpfs & eatmydata, but have a modifier schroots that disable that when I notice a weird build failure from time to time.
[09:46] <Daviey> xnox: I know what it does.. :)
[09:49] <xnox> "perl: warning: Falling back to the standard locale ("C")." why not fallback to C.UTF-8 ?!
[09:49]  * xnox hides
[10:33] <rbasak> I wonder if it's possible to do what eatmydata does but at a different level. Virtualisation perhaps? Or how about a kernel interface to noop syncs?
[10:33] <rbasak> Would that need disabling O_DIRECT in order to remain transparent to userspace?
[10:34] <rbasak> AFAICT it should be possible to make eatmydata-like functionality completely transparent to userspace.
[10:34] <rbasak> (for virtualisation I think libvirt's unsafe caching does something very similar)
[10:40] <cjwatson> mitya57: None of the outstanding Ubuntu patches to llvm-toolchain-3.2 are needed in llvm-toolchain-3.3?
[10:45] <mitya57> cjwatson: only the Ubuntu version patch is not applied upstream, I think it's not worth having a delta because of that
[10:45] <mitya57> (especially while 3.3 is not default)
[10:48] <mitya57> cjwatson: I'll now forward that upstream
[10:54] <mitya57> (done)
[11:09] <cjwatson> mitya57: The Ubuntu version patch is IIRC much more important than it looks, because it causes LLVM to choose a substantially different set of defaults
[11:10] <cjwatson> If we don't have that patch, I'd say this package should not be in Ubuntu
[11:13] <mitya57> cjwatson: I'll ask Sylvestre_ to add it in Debian then (and also fix powerpc build)
[11:53] <xnox> smoser: tested cloud-init with kvm and later with lxc once i figured out how to pass user-data to it. In short, reload-configuration can go back in, but with a version guard checking `initctl version`. In all other cases, instances should always finish initialisation. If one adds upstart jobs via user-data, they might not run, thus a reboot or manually starting them is required.
[11:55] <xnox> smoser: see email for details. But I will preparing raring SRU with changes as it currently is. I don't see how we can improve the situation any better, retrospectively.
[11:58] <smoser> xnox, email where?
[11:59] <xnox> smoser @ u.c
[12:12] <smoser> replied, xnox
[12:12] <rbasak> infinity: please see bug 1187722 when you have a chance. I thought you just sponsored SteveMcIntyre's patch but he says you were more involved? I asked him for feedback in #linaro.
[12:13]  * rbasak finds infinity in #linaro
[12:26] <smb> infinity, Near daily reminder for crash backports review. You are likely pleased to hear I try to load-balance xen over to apw...
[13:03] <ev> mpt: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395
[13:20] <mitya57> cjwatson: http://anonscm.debian.org/viewvc/pkg-llvm?view=revision&revision=690
[13:21] <cjwatson> mitya57: Great, thanks
[13:28] <xnox> smoser: reproduced race, added a check in the post-install for [ "$UPSTART_JOB" = "cloud-config" ] which also simply leaves init.upgraded & reboot-required markers.
[13:30] <xnox> hmm...
[13:33] <xnox> and it works correct now.
[14:24] <pitti> tseliot: bug 1185285
[14:25] <tseliot> pitti: thanks
[14:58] <zyga> barry: hey, is PEP396 (which I just read) going anywhere? Is it dead or is it just not-in-progress
[15:01] <infinity> @pilot in
[15:18]  * dholbach hugs infinity
[16:03] <bdmurray> doko: could you have a look at bug 1088771?
[16:19] <doko> bdmurray, yeah, I know. most likely not this week
[16:22] <bdmurray> doko: okay
[16:27] <jbicha_> ev: did you see bug 1187981?
[16:28] <xnox> jbicha_: that might be me.
[16:30] <jbicha_> GNOME copied our libtimezonemap into their gnome-control-center source and now Ubuntu's datetime panel won't run with g-c-c 3.8
[16:30] <xnox> jbicha_: that sounds so backwards, given that g-c-c was the one wanting to use libtimezonemap1 in the first place. As libtimezonemap upstream i'm not sure what I can do.
[16:30] <Laney> wtf
[16:30] <jbicha_> on the other hand I don't think any other distro packages libtimezonemap and...is it still being maintained?
[16:31] <jbicha_> https://git.gnome.org/browse/gnome-control-center/tree/panels/datetime/cc-timezone-map.c
[16:31] <jbicha_> I'm not sure how many changes GNOME has made to the library to know how easily they could switch to a system lib for 3.10
[16:31] <xnox> jbicha_: yes it's still being maintained. fedora design team approched us, asking to move timezonemap to git.gnome.org and gnome bugzilla and accept their design changes which contradict our previous usability study.
[16:32] <jbicha_> xnox: can the library support both GNOME's design and Ubuntu's?
[16:32] <xnox> jbicha_: but none of their proposals seemed to bring any real benefit to libtimezonemap.
[16:33] <xnox> jbicha_: sure it can, but I only saw mockups from fedora and no code / patches was submitted.
[16:33] <jbicha_> (by the way there's only 2 rdepends, indicator-datetime & ubiquity)
[16:33] <jbicha_> xnox: I think I linked to GNOME's code ;)
[16:34] <xnox> jbicha_: please take it up with g-c-c upstream, that if they decide to fork something maybe it could be submitted as a patch. And also if they do fork a library, they should be renaming the symbols.....
[16:34] <xnox> jbicha_: sure, it's a link to code =) not patches I can readily apply. I'll diff it to see what has changed.
[16:36] <jbicha_> https://launchpad.net/libtimezonemap says Obsolete project, where's the current code?
[16:38] <cjwatson> jibel: Do I understand it correctly that 'adt-britney request' only generates requests for direct reverse-dependencies?
[16:39] <cjwatson> IOW if you change python2.7 it won't generate requests for things that depend only on python
[16:40] <jbicha_> xnox: is their current code for libtimezonemap?
[16:42] <xnox> jbicha_: gtk+3 is here https://launchpad.net/timezonemap
[16:47] <jbicha_> xnox: ok, you can follow up at https://bugzilla.gnome.org/702194
[16:50] <seb128> xnox, jbicha_: are we sure they forked the lib?
[16:51] <jbicha_> yes the copyright header is still there (that's why I pinged ev first)
[16:52] <seb128> xnox, jbicha_: it seems like they didn't really touch that in years, our lib is based on a copy of their code rather, it just started breaking because they are doing static linking of the panels
[16:53] <xnox> seb128: now that sounds closer to being true.
[16:53] <xnox> seb128: i was merely TIL in ubuntu.
[16:54] <xnox> ev / cjwatson  should know the history
[16:54] <seb128> xnox, well, looking at the copyright I guess ev started from the Intel code in g-c-c
[16:54] <seb128> our version evolved
[16:54] <jbicha_> seb128: it looks like maybe GNOME forked it from Ubiquity back in 2010
[16:55] <seb128> oh, right
[16:55] <seb128> the first import has " * Portions from Ubiquity, Copyright (C) 2009 Canonical Ltd."
[16:55] <jbicha_> and it wasn't really a separate library in Ubuntu until 2011?
[16:55] <seb128> well anyway it would be better if g-c-c could use the system lib
[16:56] <Laney> look at README in https://bazaar.launchpad.net/~timezonemap-team/timezonemap/trunk/revision/1 ;-)
[16:56] <Laney> looks like it has quite a twisty history
[16:57] <ev> yeah, we were there first
[16:57] <cjwatson> ubiquity's map originally came from evolution-data-server and I think that was by way of something else, but it wasn't intended as a library when I did that; I think ev was the one to clean it up (by this point it had had very substantial work done on it) and turn it into a library
[16:58] <cjwatson> it was a descendant of the original EDS/whatever-it-was version but wasn't really the same code at all by that point
[16:58] <Laney> sounds like they've converged a bit now anyway
[16:58] <cjwatson> sorry, not EDS, it was from evolution via gnome-system-tools
[16:59] <cjwatson> It was in a src/cut-and-paste/ directory in at least one of those :-)
[17:40] <cjwatson> jibel: Hm.  Also, seems to have an idiosyncratic definition of dependencies.  get_package_info for upstart seems to return systemd-services (upstart Conflicts with that) but not libjson0 (which upstart Depends on).
[22:57] <mwhudson> er
[22:57] <mwhudson> sanity check
[22:57] <mwhudson> it's normal for optimized code for armhf in ubuntu to not be compiled with frame pointers, right?
[23:22] <lifeless> mwhudson: -fomit-frame-pointer; I assume yes.