=== jocarter is now known as highvoltage
[02:10] <jdstrand> mterry: that's cool-- it was just not obvious from the build log that it was the case
[02:10] <mterry> jdstrand, yeah.  :-/  And trunk has a fix for the full path needing to be specified in the /etc file
[02:11] <mterry> jdstrand, these pieces are coming together a bit fast
[02:11]  * jdstrand nods
[05:04] <darkxst> jbicha, any other show-stopper bugs for the iso?
[05:06] <pitti> Good morning
[05:13] <darkxst> anything I can do to resolve this? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1043077
[05:13] <ubottu> Launchpad bug 1043077 in upstart (Ubuntu) "upstart restarts DM to quickly" [Undecided,New]
[05:21] <pitti> DAMN YOU, Launchpad! you timeouted my carefully typed bug report
[05:39] <siretart> stgraber: I see. are you aware of any other 'official' ubuntu project that depends on live-boot's nfsroot capabilities?
[07:19] <dholbach> good morning
[07:20] <geser> good morning
[07:23] <nigelb> Hey dholbach and geser :)
[07:26] <geser> I'm preparing a vim merge to make vim installable again. Could someone sponsor it later?
[07:27] <dholbach> hey nigelb, hey geser
[07:44] <geser> bug 1043035 is waiting on sponsoring if someone wants to upgrade vim in quantal
[07:44] <ubottu> Launchpad bug 1043035 in vim (Ubuntu) "vim no longer installable dependancy problems" [Undecided,Triaged] https://launchpad.net/bugs/1043035
[07:50] <xnox> posted to devel from the wrong email.
=== chrisccoulson_ is now known as chrisccoulson
=== tkamppeter_ is now known as tkamppeter
=== mcclurmc_away is now known as mcclurmc
[08:56] <PaoloRotolo> Hi all!
=== Quintasan_ is now known as Quintasan
[10:44] <xclaesse> why is gdesktopappinfo.h installed in /usr/include/gio-unix-2.0/gio/ ?
[10:44] <xclaesse> it should be /usr/include/glib-2.0/gio/ no ?
[10:46] <xclaesse> hm, that's what upstream does in make install it seems ... :/
[10:49] <seb128> xclaesse, I don't think me move any include around...
[10:49] <xclaesse> yeah, that's normal actually, my bad
=== MacSlow is now known as MacSlow|lunch
[10:53] <xclaesse> seb128, I've seen that because building gtk from source fails: gtk-launch.c:31:33: fatal error: gio/gdesktopappinfo.h: Aucun fichier ou dossier de ce type
[10:53] <xclaesse> seems gtk-launch should be built extra unix flags
[10:53] <xclaesse> I'm wondering how ubuntu package work around that
[10:56] <seb128> xclaesse, not sure, we don't do anything I know about
=== Quintasan_ is now known as Quintasan
[11:05] <seb128> xclaesse, yeah, from the build log there is a bunch of -I parameters but I don't know where they are coming from looking at the Makefile.am...
[11:09] <xnox> seb128: /usr/lib/x86_64-linux-gnu/pkgconfig/gio-unix-2.0.pc
[11:11] <seb128> xnox, no
[11:11] <seb128> xnox, I mean Makefile.am has
[11:11] <seb128> gtk_launch_LDADD = $(LDADDS)
[11:11] <seb128> gtk_launch_SOURCES = gtk-launch.c
[11:11] <seb128> no CFLAGS
[11:12] <seb128> xnox, I though that would only add the "pkg-config --libs gio-unix-2.0" bits
[11:14] <xclaesse> ok ok, understood why it works for ubuntu package and not my build
[11:14] <seb128> xclaesse, oh? why?
[11:14] <xclaesse> I'm building with broadway backend, and in that case the configure.ac does not define have_gio_unix
[11:15] <seb128> oh, ok
[11:18] <xclaesse> still, that's an upstream bug, if it's not unix it should not try building gtk-launch
[11:18]  * xclaesse will report that
[11:19] <xclaesse> and that was already reported... awesome : https://bugzilla.gnome.org/show_bug.cgi?id=682824
[11:19] <ubottu> Gnome bug 682824 in win32 "Don't build gtk-launch on Win32 environments" [Normal,Unconfirmed]
=== helderc_ is now known as helderc
=== cpg is now known as cpg|away
=== _salem is now known as salem_
=== dendrobates is now known as dendro-afk
=== MacSlow|lunch is now known as MacSlow
[13:19] <smoser> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin, smoser
=== sagaci_ is now known as sagaci
[14:04] <sconklin> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
[14:07] <dholbach> mterry, coolbhavi, tumbleweed, m_3: ready? :)
[14:07] <coolbhavi> dholbach, yup :)
[14:07]  * dholbach hugs sconklin
[14:07] <tumbleweed> haven't started preparing anything, but I've doen this one before, so sure :P
[14:09] <dholbach> sweet
[14:10] <mterry> dholbach, I'm mostly ready, but I've not done this talk for a more Ubuntu-focused audience (usually for app dev week), so not sure how long it will be.  I suppose there's no harm in ending before an hour
[14:10] <coolbhavi> dholbach, have already shared my notes with you
[14:10] <coolbhavi> reg dat :)
[14:15] <dholbach> mterry, cool
[14:15] <dholbach> coolbhavi, allright
[14:38] <m_3> dholbach: yup
[14:40] <dholbach> cool
[14:44] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in ~15 minutes in #ubuntu-classroom
=== yofel_ is now known as yofel
=== mcclurmc is now known as mcclurmc_away
=== doko_ is now known as doko
=== deryck is now known as deryck[lunch]
[16:32] <ev> mpt, bdmurray: https://bugs.launchpad.net/errors/+bug/1043426
[16:32] <ubottu> Launchpad bug 1043426 in Errors "When we start pulling in more problem types, continue to track *just* crash problems in addition to the whole set" [Undecided,New]
[16:36] <ev> and https://bugs.launchpad.net/errors/+bug/1043428
[16:36] <ubottu> Launchpad bug 1043428 in Errors "Selecting a package or a package and version should change the average errors per day graph" [Undecided,New]
[16:40] <ev> https://bugs.launchpad.net/errors/+bug/1043430
[16:40] <ubottu> Launchpad bug 1043430 in Errors "Selecting a date range in the average errors per day graph should change the most common problems table to the matching date range" [Undecided,New]
=== deryck[lunch] is now known as deryck
=== bryceh is now known as bryce
=== henrix_ is now known as henrix
[18:57] <smoser> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[19:14] <roaksoax> cjwatson: ping
=== cpg|away is now known as cpg
[19:22] <dobey> slangasek: hey. do you know if gobject-introspection (libgirepository) has proper multiarch support? or am i totally breaking things by trying to convert my package to multiarch that provides a gir api?
[19:23] <slangasek> dobey: TTBOMK there's no multiarch support for gir itself currently; so typelibs should continue to be shipped in /usr/lib/girepository-1.0, not in an arch-qualified directory
[19:24] <slangasek> dobey: but as long as the gir bits are in a separate binary package, the shared lib could still be made M-A: same
[19:24] <dobey> slangasek: and the gir package needs to be foreign?
[19:24] <slangasek> dobey: no
[19:24] <slangasek> it needs to not be marked Multi-Arch at all
[19:25] <dobey> ah
[19:25] <slangasek> because it's architecture-dependent and not co-installable
[19:25] <slangasek> (the typelib files encode information about things like integer sizes, so are not arch-neutral)
[19:25] <dobey> slangasek: and does dh_girepository move stuff back to non-ma dirs? or one has to do that manually?
[19:25] <slangasek> I suspect you need to do that part manually
[19:26] <dobey> ick, ok
[19:42] <seb128> in the hate webkit serie
[19:42] <seb128> doko, slangasek, others: can we get http://sourceware.org/bugzilla/show_bug.cgi?id=14302 in quantal?
[19:43] <ubottu> sourceware.org bug 14302 in binutils "ar mishandles 4GB files" [Normal,Resolved: fixed]
[19:43] <seb128> "ar: .libs/libWebCore.a: File truncated" is how webkit fails to build on amd64, seems to be due to that bug
[19:43] <seb128> did I say that I hate webkit?
[19:44] <dobey> seb128: libWebCore.a is > 4GB?! :(
[19:44] <seb128> dobey, guess so
[19:44] <seb128> the build dir is like 25G and ld takes over 3G of ram so I'm not surprised
[19:45] <dobey> ffs it has really ballooned out in its age, hasn't it
[19:46] <seb128> yeah, that's just insane
=== cpg is now known as cpg|away
[20:00] <seb128> doko, slangasek: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1043507
[20:00] <ubottu> Launchpad bug 1043507 in binutils (Ubuntu) "webkit build fails on binutils limitation" [Undecided,New]
=== henrix is now known as henrix_
[20:06] <sdh> im just catching up on the day's "developer week" logs
[20:07] <sdh> is it correct that anybody can register to attend UDS?
=== henrix_ is now known as henrix
[20:17] <xnox> sdh: yes. It is an open for all event, if you can/prepared to pay your own accomodation, food and travel.
[20:18] <xnox> sdh: you can apply for sponsorship to attend, but there is a very limited amount of those available.
[20:31] <ajmitch> iirc sponsorship for the next uds has closed
[20:34] <dobey> sdh, xnox, ajmitch: also, even if you can't attend in person, you can attend remotely via irc and the audio/video streams
[20:37] <sdh> xnox: i would look to fund that myself
[20:48] <sdh> xnox: does UDS tend to "sell" out?
[20:49] <xnox> sdh: there is no "sell" out. There are many locals showing up on the day. So attendance does vary.
[20:51] <xnox> sdh: for the plenary sessions it can be packed (e.g. when HP/Google/etc are presenting), other sessions can be quite empty (I did attend a session where there were only 3 people, we quickly made some decisions and went to visit other tracks)
[20:51] <sdh> cool, so no rush to register?
[20:51] <sdh> is there an agenda/plan anywhere?
[20:51] <xnox> sdh: register if you think you might attend.
[20:51] <xnox> sdh: uds.ubuntu.com In due course... everyone is busy with quantal right now =)
[20:52] <sdh> sure, thanks xnox ;)
[20:52] <xnox> sdh: it's a developer event, not a consumer / user event. Mostly we talk about blueprints.
[20:52] <sdh> that's good
[20:52] <xnox> sdh: see status.ubuntu.com for things that are lickely to be discussed.
[20:52] <sdh> xnox: cool, will do. just checking then, it's ok to register and possibly back out in future
[20:53] <xnox> sdh: and developing ubuntu =) not like any random "lets learn to code in python, but better!" =)
[20:54] <sdh> i think i understand :)
[20:55] <sdh> wow danish hotels are expensive !
[20:57] <xnox> sdh: hint, all hotels in capitals & easy air-travel from USA and Europe are expensive
[20:58] <sdh> thanks xnox i haven't travelled anywhere before
[20:59] <sdh> :p
[21:05] <slangasek> seb128: the upstream bug claims it only impacts 32-bit platforms, you report that it affects amd64?
[21:06] <seb128> slangasek, hum, maybe a different issue then :-(
[21:06] <slangasek> seb128: the "only impacts 32-bit" is what I would have expected, since size_t and friends are 64-bit already on amd64
[21:06] <seb128> I didn't read the details, I just had a quick look since I had to run
[21:07] <slangasek> seb128: and it looks like this .a is an intermediate file used for linking the final result, right?  So it's not enough to just disable static library builds?
[21:11] <seb128> slangasek, I guess I can try that, I'm still unsure what is the best practice about static libs
[21:11] <slangasek> seb128: if WebCore.a is an interim file that's linked into the final .so, disabling static libs doesn't help
[21:11] <jtaylor> is someone already working on update vim? required since the last python update
[21:12] <slangasek> seb128: but certainly, I don't think we should let anyone link statically to webkit ;)
[21:12] <micahg> +1 :)
[21:15] <tumbleweed> jtaylor: aah, you found geser's bug
[21:16] <seb128> slangasek, in fact from the build log static build is already disabled "checking whether to build static libraries... no"
[21:17] <slangasek> seb128: right, so I think this is just linking a convenience library
[21:18] <slangasek> seb128: so unless you want to change -g options, there doesn't seem any way around it
[21:18] <seb128> :-(
[21:19] <seb128> webkit is a nightmare
[21:19] <sdh> how so?
[21:21] <seb128> sdh, takes 6 hours do build, ld takes over the 32 bit memory space allocation limit, requires patched make because it goes over the number of arguments limitations of the current version, hit some binutils bug on amd64 apparently, etc
[21:21] <sdh> seb128: crikey, good reasons to complain ;)
[21:23] <seb128> did I mention that they broke api without noticing several times this cycle?
[21:23] <seb128> they are asking for hints on how they could see those before releasing at this point :p
[21:23] <lifeless> seb128: API or ABI ?
[21:24] <lifeless> seb128: I would have thought the former was easy to tell (and the latter tricky...)
[21:24] <slangasek> seb128: so do libwebkitgtk-3.0-0-dbg and/or the dbgsym package actually get used?  1.2GB installed?
=== salem_ is now known as _salem
[21:24] <seb128> slangasek, not by me, but I don't know if others do ... I guess some people working on webkit can make use of debug stacktraces
[21:25] <seb128> lifeless, the first one, they dropped symbols from their public headers
[21:25] <slangasek> seb128: well, simply disabling -g would bring the size down and let it build... is it maybe better to do that, and drop the dbg for now, than to have it not buildable?
[21:25] <lifeless> seb128: -lol-
[21:25] <seb128> slangasek, for sure better, still not ideal though...
[21:26] <slangasek> seb128: so there are tools for checking API backwards-compatibility, but I'm not sure if they work for C++ or just C
[21:26] <slangasek> seb128: indeed, not ideal; just trying to suggest a way to unblock while waiting for this fix
[21:27] <seb128> slangasek, well, I'm not strictly blocked on that at this point, still waiting on upstream to sort their api,abi issues
[21:27] <seb128> slangasek, I'm unsure but it might be that the previous version had the same issue on the ppa builders but built in the archive
[21:27] <seb128> slangasek, not sure why that would happen though so I might recall wrongly
[21:28] <slangasek> hmm
[21:28] <slangasek> I don't know either
[21:29] <seb128> I've played with the build flags quite a lot though
[21:29] <slangasek> seb128: turning off -g completely should certainly let it build
[21:30] <seb128> like I added -Wl,--reduce-memory-overheads in some previous upload because otherwise it was spending over 3 hours on ld on armel and the builders were killing the build as hanging...
[21:30] <seb128> slangasek, thanks, I dropped -Wl,--reduce-memory-overheads just to see if that makes a difference
[21:31] <seb128> if that doesn't I will drop -g in the next build to try that
[21:34] <infinity> seb128: You could also try -gstabs instead of -g
[21:34] <slangasek> yes, a little stabbing always helps when dealing with debug options
[21:35]  * infinity smirks.
[21:36] <seb128> I could just declare that I don't care enough about webkit, let it where it is and see if anyone else picks it up after some time ;-)
[21:36] <seb128> I'm ready to pay a beer every night at UDS to whoever takes over it :p
[21:36] <infinity> I'd fix it if I wasn't reviewing the mess in precise/NEW.
[21:36] <ajmitch> seb128: just one? :)
[21:37] <seb128> ajmitch, hey, I say "one every night", it's better than one :p
[21:38] <chrisccoulson> seb128, BEEEEEEEEEEEEEER, you say?
[21:38] <chrisccoulson> every night?
[21:38]  * chrisccoulson thinks about that one
[21:39] <seb128> chrisccoulson, indeed!
[21:40] <seb128> chrisccoulson, and see I'm in a good mood if you take the offer I will double that offer
[21:41] <seb128> chrisccoulson, and think about it, it would give you some extra perspective on how good firefox is ;-)
[21:41] <chrisccoulson> lol
=== mcclurmc_away is now known as mcclurmc
=== mcclurmc is now known as mcclurmc_away
=== mcclurmc_away is now known as mcclurmc
[22:06] <doko> seb128, slangasek and this fix is in quantal, even if it doesn't help
[22:06] <seb128> ok
[22:06] <slangasek> doko: ok, thanks for looking
[22:07] <slangasek> seb128: an strace of the failing ar command may help here
[22:08] <seb128> slangasek, will try to get one
=== mcclurmc is now known as mcclurmc_away
=== cpg|away is now known as cpg
=== cinerama_ is now known as cinerama
=== henrix is now known as henrix_
=== Ursinha` is now known as Ursinha