[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?
=== Nisstyre-laptop is now known as Nisstyre
[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
=== tkamppeter_ is now known as tkamppeter
[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?
=== doko_ is now known as doko
[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?
=== mmrazik is now known as mmrazik|lunch
[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
=== MacSlow is now known as MacSlow|lunch
[11:13] <mitya57> cjwatson: I'll ask Sylvestre_ to add it in Debian then (and also fix powerpc build)
=== mmrazik|lunch is now known as mmrazik
[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
=== pete-woods is now known as pete-woods-lunch
[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:12] <ubottu> bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722
[12:13]  * rbasak finds infinity in #linaro
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
[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:03] <ubottu> Launchpad bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New]
=== jbicha is now known as Guest30774
[13:20] <mitya57> cjwatson: http://anonscm.debian.org/viewvc/pkg-llvm?view=revision&revision=690
=== Guest30774 is now known as jbich_
=== jbich_ is now known as jbicha_
[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.
=== wedgwood_away is now known as wedgwood
=== kentb-out is now known as kentb
=== ckpringle_ is now known as ckpringle
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:24] <pitti> tseliot: bug 1185285
[14:24] <ubottu> bug 1185285 in fglrx-installer (Ubuntu Saucy) "[saucy] fglrx fails to build against linux 3.9.0 (missing version.h)" [High,Triaged] https://launchpad.net/bugs/1185285
[14:25] <tseliot> pitti: thanks
=== alesage|afk is now known as alesage
[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
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
[15:18]  * dholbach hugs infinity
=== mako_ is now known as mako
=== mmrazik is now known as mmrazik|afk
[16:03] <bdmurray> doko: could you have a look at bug 1088771?
[16:03] <ubottu> bug 1088771 in python-defaults (Ubuntu Precise) "dangling symlink /usr/lib/pkgconfig/python2.pc" [Low,Triaged] https://launchpad.net/bugs/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:27] <ubottu> bug 1187981 in ubiquity (Ubuntu) "symbol conflicts in libtimezonemap1" [Undecided,New] https://launchpad.net/bugs/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?
=== bfiller is now known as bfiller_afk
[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:47] <ubottu> Gnome bug 702194 in Date and Time "forked libtimezonemap breaks Ubuntu's indicator-datetime" [Major,Unconfirmed]
[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).
=== echevemaster is now known as _echevemaster
=== salem_ is now known as _salem
=== kentb is now known as kentb-oout
=== jbicha is now known as Guest26134
[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.
=== wedgwood is now known as wedgwood_away
=== Rcart is now known as Rcart_afk