[02:57] <L-----D> hi, I'm a java/c# developer, I want to start Unity2D QT dev, where can I start?
[03:12] <Chester> hola
[03:13] <Chester> alguien por ahi?
[03:22] <Chester> hay alguien?
[03:25] <JuN1x> Chester: Este canal es en ingles
[03:29] <Chester> some one are there?
[03:30] <JuN1x> Chester: this channel is for developing
[03:30] <Chester> i have a question abaut ubuntu, some one can help me?
[03:32] <JuN1x> Chester: try with #ubuntu channel
[03:32] <Chester> ok, thx
[03:32] <JuN1x> here is offtopic
[06:03] <slangasek> bdmurray: bug #913947 is french for bug #545790
[08:31] <pitti> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption has a WI "Investigate blktrace for reporting issues with excessive disk wakeups" -> it seems you already did that? yesterday I overheared you mentioning it when talking to Chris
[08:47] <slangasek> pitti: so, I've certainly been using blktrace locally, but its output isn't very consumable for end users
[09:10] <pitti> cking: just read through your power notes; this is great work!
[09:11] <cking> pitti, thanks! It's still "work in progress" but I've covered 80%+ of the low-hanging fruit
[09:12] <pitti> with that it almost seems to me that we should implement the proposed changes first, before sending bigger calls for sending bugs (as there will probably be many dupes)
[09:13] <pitti> cking: ^ or do you think that would still be useful at this time?
[09:16] <cking> pitti, yes, there are a load of bugs filed that should be fixed which generally look quite trivial which will give us a sufficient win
[09:17] <cking> ..and then we can move into phase 2 to ask for users to identify rouge processes for the ones we missed
[09:19] <pitti> cking: agreed, sounds good to me; want me to look into some of the bugs?
[09:19] <pitti> cking: are you already working on the pm-utils ones, or want me to help out there? otherwise I'd start with the ubuntuone bug
[09:21] <robert_ancell> cnd, do you know the best way to provide a patch to the linuxwacom project?
[09:21] <cnd> robert_ancell, no, I've never touched that project
[09:21] <cnd> you may want to ping whot on #xorg-devel
[09:21] <robert_ancell> cnd, thanks
[09:22]  * cnd is afraid to look at that project
[09:22] <\sh> hmmm..did anybody ever saw this error: init: udev-fallback-graphics main process (...) terminated with status 1 and then failing to boot?
[09:36] <ogra_> SpamapS, jodh .... we were just discussing serial consoles in the arm room and i remembered bug 702574, how about we upload the fix before final release ?
[09:36] <ogra_> ;)
[09:53] <Sweetshark> doko: could you complete/fixup the arm-patch? _rene_ is already reverting this out of upstream with http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/revert-468fe685e3c58c84bce6d9a48b931dcc21682679.diff;h=7b9f67c5dbb85c7f2633234ea40c1226e8d96815;hb=0f0bc4431463d26b45df01995d68c781d87712aa
[10:09] <doko> Sweetshark, no, -> janimo and/or NCommander
[10:11] <ogra_> doko, Sweetshark, NCommander is currently (like right now) hacking on it (though at this very moment he is in a meeting)
[10:20] <Sweetshark> ogra_, doko: thx
[10:37] <NCommander> Sweetshark: I'm staring at the ARM code right now to try and figure out where in UNO we are breaking in hardfloat
[10:37] <NCommander> I *think* we're getting through the trampolines into at least cpp_vtable_call, but I'm not sure where we're getting back that
[10:38] <NCommander> (gdb really hates UN)
[10:38] <NCommander> *UNO
[10:40] <NCommander> *getting broken past that
[10:42] <NCommander> (I think we're exploding in cpp_meditate now that I got my fprintf's in the right places
[11:05] <micahg> cjwatson: was just wondering if you were planning on uploading xubuntu-meta for the linux-headers change or if I should plan to do that later
[11:07] <cjwatson> micahg: I can do that
[11:08] <micahg> cjwatson: ok, thanks
[11:08] <cjwatson> it wasn't urgent or anything, just cutting down on CD size a bit
[11:08] <micahg> sure, our alternate is oversized as well
[11:18] <YokoZar> Is the ★ character allowed in package descriptions?
[11:19]  * YokoZar thinks he might just try it and see if Lintian complains
[11:24] <ogra_> YokoZar, iirc as long as its utf8 it will just work
[11:28] <cjwatson> YokoZar: anything UTF-8 should be allowed, yes
[11:29] <YokoZar> cjwatson: I wonder if a package description with stars in the wrong place could mislead about its rating ;)
[11:53] <sveinse> I'm trying to install some packages to a staging directory. I'm using apt.conf setting RootDir to prefix root into the staging directory. apt-get update downloads the indexes, but at the end it fails as it tries to access the system's /var/lib/dpkg/lock, despite the RootDir setting. I suspect a bug (or some kind of feature). Please see http://paste.ubuntu.com/799261/ to recreate
[11:53] <sveinse> If I run the script, I notice that apt-get update accesses /var/lib/dpkg/lock while it IMHO is configured not to do so
[11:53] <sveinse> This is on amd64 Natty
[12:01] <sveinse> It does work if I call the script as root, since root gives it access to /var/lib, but I was hoping to be able to run the script without being root. And frankly I don't understand what apt is doing outside of its RootDir
[12:03] <cjwatson> sveinse: the dpkg admindir is set independently apparently; Dir::State::status
[12:03] <cjwatson> sveinse: or you could set Debug::NoLocking=true
[12:05] <sveinse> cjwatson: dpkg admindir locking works half ways: Strace tells me that apt is locking within RootDir prior to running apt-get update, but it tries to access the system's lockfile when it's done with update and about to exit
[12:05] <sveinse> cjwatson: I'll certainly try nolocking, thanks
[12:06] <cjwatson> I suspect changing that behaviour now would be inconvenient; there is certainly a good deal of code that relies on the current behaviour
[12:06] <cjwatson> if nothing else by setting a dpkg admindir with rootdir prepended
[12:23] <sveinse> cjwatson: The Debug::NoLocking works like a charm. Finally! Thanks a lot.
[12:26] <cjwatson> sveinse: I think it's actually not necessarily unreasonable for apt to handle dpkg and apt metadata separately; I can think of cases where I might want to use my normal apt configuration with a separate dpkg admindir, for instance, and I suspect with a bit more effort I could imagine something the other way round
[12:26] <cjwatson> it's not documented brilliantly, though
[12:30] <sveinse> cjwatson: I think there is something not quite all right with the locking mechanism. Not that I can put my finger on it, but I'm not able to get apt-get update to run as-non root even if the locks and status is set inside a staging dir with full permissions
[12:33] <cjwatson> sveinse: chdist manages it
[12:33] <cjwatson> (devscripts; config e.g. http://paste.ubuntu.com/799299/)
[12:34] <cjwatson> (er, I meant to say http://paste.ubuntu.com/799300/)
[12:35] <sveinse> Great! This might be what I have been looking for...
[12:57] <sveinse> cjwatson: chdist is definitely what I want, but it doesn't report back command status from apt-get. This makes things a bit harder when scripting though
[12:57] <sveinse> Think I need to copy chdist and modify it
[12:58] <cjwatson> sveinse: really?  the version on my system simply execs apt-get, so apt-get's exit status will be the exit status of chdist
[12:59] <cjwatson> (I don't have any local modifications to that; running precise)
[12:59] <sveinse> I'm getting "E: broken packages" from apt-get/chdist, but my script (with "set -ex") continues in bliss
[13:00] <cjwatson> check whether apt-get is actually exiting non-zero ...
[13:11] <wyuka> hello
[13:11] <wyuka> i am investigating how wubi and lupin work internally.
[13:12] <wyuka> where can i get the source code for the initramfs used by ubuntu?
[13:12] <wyuka> it seems that it supports a "loop" argument to the kernel
[13:56] <sveinse> cjwatson: FYI apt-get returns status code 100, but this isn't passed on by chdist. Once I've dissected the inner workings of chdist and implemented what I need manually, I've have no need for it, so for me everything is ok now. Thanks for your assistance
[13:58] <sveinse> (The key seems to be to use apt.conf Dir together with Dir::State::status, and not RootDir as I did)
[15:09] <stokachu> pitti: ping debug packages generated automatically for updates repo?
[15:09] <stokachu> pitti: im in the kernel room if you would like to talk more
[15:10] <pitti> stokachu: they are supposed to be, yes
[15:10] <pitti> stokachu: this stuff keeps breaking randomly, though, so some are always missing :(
[15:13] <stokachu> pitti: i was looking for ghostscript-dbgsym, seems to be missing for 8.71.dfsg.1-0ubuntu5.4
[15:13] <stokachu> on lucid
[15:14] <stokachu> looks like 8.71.dfsg.1-0ubuntu5 is the only one available atm
[15:18] <barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/3083012
[15:19] <barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/3083013
[15:46]  * mneptok pokes all the Unity devs
[15:46] <mneptok> https://twitter.com/1990LinuxGuy
[15:47] <psusi> has there been a shortage of patch pilots lately?  I've had some pending merges for a month now... like https://code.launchpad.net/~psusi/ubuntu/precise/lm-sensors/merge
[16:02] <micahg> psusi: next round of patch pilots scheduled for next week, there haven't been any scheduled since Dec 23
[16:26] <psusi> micahg: ahh, I see... thanks
[16:57] <janimo> mvo, around?
[17:00] <mvo> janimo: yes
[17:01] <dholbach> janimo, mvo: I won't be part of the vegetarian caravan later on - we moved out team dinner to today
[17:02] <janimo> dholbach, me neither, was just pm-ing mvo
[17:02] <mvo> dholbach, janimo: aha, ok
[17:34] <doko> kees, ping
[17:42] <lazka> Will there be another unstable import before the import freeze?
[17:44] <micahg> lazka: no, that was yesterday
[17:44] <micahg> lazka: and we were only syncing from testing
[17:44] <micahg> lazka: feel free to file a sync request (preferably from testing unless there's a reason to sync from elsewhere)
[17:44] <lazka> oh :(
[17:45] <micahg> lazka: see requestsync in ubuntu-dev-tools
[17:45] <lazka> ok, I will do when it hits testing in some days
[17:45] <lazka> thanks
[17:51] <l3on> micahg, hey, but what about merge bugs filed before yesterday?
[17:52] <l3on> I mean, I opened 5 o 6 merge bugs that are still pending
[17:52] <micahg> l3on: we can still merge/sync, this was only for the autosync
[17:52] <l3on> ah ok micahg :)
[17:59] <cjwatson> I probably would have done one more autosync but the new autosync script had already caused enough chaos
[18:00] <lazka> requestsync works nicely. I was impatient :)
[18:20] <ahasenack> hi, can someone sponsor/review the python-tz upload for lucid, maverick, natty and oneiric? (SRU)
[18:21] <broder> ahasenack: i can't review them now, but i don't see anything on the sponsorship queue
[18:22] <ahasenack> broder: would that be https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= ? What did I forget to do?
[18:22] <broder> ahasenack: oh, they've already been uploaded then
[18:22] <broder> you're waiting for someone from ubuntu-sru to review them now
[18:22] <broder> might be sluggish since they're all rallying
[18:23] <ahasenack> broder: ah, ok
[20:15] <RoAkSoAx> ea/win 3
[22:07] <tormod> patch pilot or not, can some dev please confirm and subscribe u-a on this sync request: bug 908711
[22:26] <Laney> did it
[22:28] <Laney> but I forgot to sponsor it. oops.