[00:34] <cjohnston> nice work xnox! cjwatson did you see the xchat change?
[00:35] <infinity> cjohnston: Most important change in the distro in years? :P
[00:35] <infinity> cjohnston: I need to make the same change for irssi.
[00:35] <cjohnston> infinity: probably. lol
[00:35] <infinity> Actually, that may already be the irssi default, it may just not always keep enough history to remember who my last-tabbed cj was.
[00:36] <infinity> I'll have to experiment.
[00:36] <cjohnston> jtaylor: how did the work go with shiboken? ever figure it out?
[00:36] <infinity> cjwatson: Testing, ignore.
[00:36] <infinity> Yeah, my irrsi does the last-tabbed cj correctly on this machne.
[00:36] <infinity> irssi, too.
[00:37] <cjohnston> mine defaults to cjw.. :-)  lucky me! lol
[00:37] <cjohnston> Glad I don't ping myself
[00:38] <infinity> I still get messed up on ogra/ogasawara though, since I talk to both of them alternately.  Oh well.
[00:38] <infinity> Need a telepathic IRC client.  Or to not be lazy and type 3 chars.
[00:39] <StevenK> infinity: You? Not lazy?
[00:39] <TheMuso> I've trained myself to type 3 chars now, tends to help.
[00:39] <cjohnston> hehe.. 1 2 3 tab works in two cases
[00:39] <infinity> StevenK: Hush, you.
[00:39] <slangasek> infinity: instead of just hitting tab twice when it autocompletes wrong?  same number of keypresses ;)
[00:40] <infinity> slangasek: Cycling through hurts my tiny brain.  All that flashing text.
[00:40] <slangasek> cycling is good exercise
[00:40] <infinity> *rimshot*
[00:41] <cjohnston> I could say I finally made a changelog.. lol
[00:41] <infinity> Although, that may have been more deserving of a sadtrombone.com
[00:42] <cjwatson> cjohnston: Yeah, I noticed - hopefully it'll trickle down to people's configuration eventually ...
[00:43]  * infinity ponders changing his name to cjfinity.
[00:43] <cjohnston> go for it
[00:44] <infinity> cjwatson: You could have avoided this whole mess by going back to Kamion.
[00:44]  * StevenK waits for infinity to say "See, this is all your fault. Not mine for being inflexible, at all."
[00:45] <infinity> StevenK: Absolutely.  And I'm infinity, not inflexible.  Your tab-completion sucks.
[00:45] <cjwatson> I got lazy and wanted same username everywhere.  Spare neurons are in shorter supply nowadays.
[00:45] <StevenK> Or is awesome for tab-completing a word that doesn't appear in the nick list?
[00:46] <cjohnston> cjwatson: in that case I should change to chrisjohnston
[00:46] <infinity> StevenK: It's the new gmail tab completion that scans your email and offers suggestions based on your grandmother's eulogy.
[00:46] <cjohnston> cjohnston was taken on LP :-(
[00:46] <StevenK> infinity: Good job that I don't use gmail, then.
[00:47] <StevenK> And my grandmother's eulogy was in Polish only.
[00:47] <infinity> You sure can ruin a joke.
[00:47] <StevenK> I try.
[00:48] <infinity> StevenK: I think this is an appropriate time to point out that when Pete and I were doing some budgeting earlier, we only budgeted for one Soyuz developer.
[00:48] <infinity> StevenK: You and William will be expected to battle to the death.
[00:49] <StevenK> Hah
[00:50] <cjohnston> lol
[01:56] <Logan_> bdrung: Hey, mind if I PM?
[02:00] <jbicha> pitti: I figured out my apport question: http://paste.ubuntu.com/5566568/
[02:11] <psusi> ps will show WCHAN while a task is blocked... how can I get a full kernel stack backtrace instead?
[02:13] <sarnold> psusi: there's a sysrq key for that...
[02:13] <sarnold> psusi:
[02:14] <sarnold> psusi: 'l' will dump the stack for all cpus
[02:14] <sarnold> psusi: 't' will dump a list of current tasks "and their information" -- whatever that is. it might be more useful (and also likely much uch more data)
[02:19] <psusi> sarnold, right, I was hoping for a way to just get the stack trace of the one task
[02:20] <sarnold> psusi: hehe yeah :) I just don't know the way to do that
[02:22] <psusi> blargh... damn recent kernels and their disabling magic-sqreq functions by default
[02:23] <hyperair> sarnold: tasks == processes + kthreads.
[02:24] <hyperair> psusi: it's not a recent kernel thing. it's a sysctl.d thing
[02:24] <sarnold> hyperair: sorry, I meant it in the sense of, "I don't know if that includes the stack dumps or just eip"...
[02:24] <psusi> yea, but where's the defaults set?  not sure if it's an Ubuntu thing or an upstream change that changed the defaults
[02:24] <psusi> but it's annoying as all hell
[02:24] <hyperair> psusi: /etc/sysctl.d/10-magic-sysrq.conf
[02:25] <hyperair> i agree it's annoying.
[02:25]  * hyperair uses alt+sysrq+k all the time
[02:25] <psusi> yea, same
[02:26] <psusi> well, not all the time, but... when things go wrong, which is not all that infrequently
[02:26] <hyperair> well the idea was that if you trigger the OOM killer enough, you might accidentally kill the screensaver (but not the rest of the X session), allowing you to gain access into the X session
[02:26] <hyperair> and from there, possibly an open sudo session..
[02:26] <hyperair> or cached sudo session, for that matter
[02:27] <infinity> Not an entirely implausible situation.
[02:27] <hyperair> infinity: yeah, but i'd prefer for gnome-screensaver to just poke oom_adj itself
[02:27] <infinity> screensavers swap out quickly, and as children of other more interesting things, would likely die early in the reaping.
[02:28] <psusi> seems to me you could still do that by hogging memory, so the proper fix is to make the screensaver immune to oom
[02:28] <infinity> Nothing's immune to the oom killer, is it?
[02:28] <psusi> iirc, there were knobs you could tune to tell it not to consider certain processes
[02:28] <hyperair> infinity: well, it's enough to make gnome-session or X11 go out before gnome-screensaver.
[02:29] <sarnold> /proc/self/oom_*adj
[02:29] <psusi> if you kill those then you end the X session
[02:29] <hyperair> https://lwn.net/Articles/317814/
[02:29] <hyperair> set oom_adj to -17, and it isn't considered for OOM killing
[02:29] <hyperair> bingo
[02:30]  * hyperair dpkg-divert's gnome-screensaver
[02:42] <hyperair> psusi: well that's the idea, right? you don't want it to unlock your screen -- you want it to take out your X session, which is much more useful when a program goes into a runaway memory allocation loop
[02:42] <hyperair> which does happen.
[02:42] <psusi> hyperair, indeed
[02:42] <hyperair> and unity deals *very* badly with such situations
[02:42] <psusi> or when you are trying to play an opengl game and the gpu goes apeshit ;)
[02:42] <hyperair> the whole display just freezes up because unity can't draw anything
[02:43] <hyperair> psusi: that's alt+sysrq+k, not f
[02:43] <psusi> ohh, thought that's what you were talking about
[02:44] <hyperair> speaking of which, i wonder how ubuntu phone deals with application lifetime?
[02:44] <hyperair> does it also do the android oom-killer thing
[02:44] <hyperair> ?
[02:44] <lifeless> hyperair: 'phone-home' :P
[02:44] <hyperair> lifeless: phone-home?
[02:44] <lifeless> hyperair: bad joke
[02:45] <hyperair> heh
[02:45] <hyperair> the unity amazon issue, was it?
[02:45] <psusi> no idea, but I was doing a kernel config today and saw the opportunistic system sleep and wakelocks that android introduced and wondered if that might be a nice thing for my server to do... automatically enter S3 when nobody is connected
[02:45] <lifeless> hyperair: nah, referencing ET
[02:45] <hyperair> oh.
[02:45] <psusi> wake on lan when someone connects...
[02:45] <hyperair> wasn't that S4 or something?
[02:46] <psusi> well, it certainly isn't hibernation on androids ;)
[02:46] <hyperair> well yes
[02:46] <hyperair> er wait, is S4 hibernation?
[02:46] <psusi> not sure if it's S1 or S3, but generally I think S1 died
[02:46] <psusi> yea
[02:47] <hyperair> ah, S4 is hibernate.
[02:47] <psusi> way back before power supplies supported standby mode, S1 was kind of a useless state that stopped everything executing but since the psu didn't go to standby, about the only power it saved was putting the hard drive to sleep
[02:48] <hyperair> lol
[02:48] <hyperair> surely it's up to the individual devices to draw power from the PSU?
[02:48] <hyperair> the CPU is powered down isn't it? and iirc that's a significant amount of power
[02:48] <psusi> not really.. for most devices, if psu gives them power, they are on
[02:48] <hyperair> oh
[02:48] <hyperair> interesting.
[02:49] <psusi> these days the CPU powers off while the system in in S0, via deep C states
[02:49] <hyperair> but not completely
[02:49] <psusi> does at least with Intel deep C6
[02:49] <hyperair> oh
[02:49] <hyperair> what about C7?
[02:49] <psusi> deep C6 is the bottom
[02:50] <hyperair> hmm, it says C7-SNB on mine.
[02:50] <psusi> hrm... last I read the Intel specs, they did C0, C1, C3, C6, and in C6 vcc to the cpu was 0
[02:50] <hyperair> hmm
[03:32] <psusi> well, the sysrq full task info turned out to be sufficient... I found the bug in ext4
[04:26] <pitti> Good morning
[04:26] <pitti> jbicha: indeed, that seems right
[04:27] <pitti> jbicha: but NB that this will still use the default configuration which crashes to send to LP and which not
[04:27] <pitti> jbicha: if you want to keep crash reports even if "main" ubuntu disables LP reports by default, you can do that, too; let me know what you need
[04:27] <pitti> infinity: I am now
[04:31] <erickLee> hello. pbuilder-dist <realease> create command not working for precise pangolin.
[04:33] <infinity> pitti: I know we've been over this a few dozen times in the past, but do you have a reasonable estimate for growth-over-time of ddebs, so we can capacity plan for the librarian shift?
[04:36] <pitti> infinity: no precise numbers for each release, as /pool overlaps, etc. but let me try an estimate how much we would have if I hadn't removed older releases
[04:37] <jbicha> pitti: I think that will be fine for now, it was annoying not to be able to use ubuntu-bug
[04:37] <pitti> jbicha: ah yes, for bug reporting your stanza is perfectly fine
[04:38] <pitti> jbicha: btw, I take it we want to put that into /usr/share/apport/general-hooks/ubuntu.py, not into every single GNOME package?
[04:40] <jbicha> pitti: oh wow that would be a lot nicer
[04:41] <pitti> infinity: so http://paste.ubuntu.com/5566793/ is what we have today
[04:41] <pitti> infinity: NB that none of the releases have powerpc ddebs
[04:42] <infinity> pitti: Okay, well, that's much (much) smaller than I initially budgeted for, so we should be alright for a little while once we get this sorted.
[04:42] <pitti> infinity: /pool gets a bit fatter due to pulling ddebs from magic PPAs, and we currently keep old ddebs around for 30 days
[04:43] <infinity> pitti: Yeah, but I have to account for PPA storage too, so...
[04:43] <pitti> infinity: so assuming we keep 3 arches and stop removing packages for still supported releases, and assume that we stop losing ddebs, my guesstimate would be that with 1 TB we should be okay
[04:43] <pitti> infinity: but again, that's with removing old ddebs after 30 days, which I'm not sure we'd be doing on the librarian?
[04:43] <infinity> pitti: No, we won't be culling nearly as aggressively to start with, though we might have to eventually.
[04:43] <pitti> but removing old ddebs seems prudent to me, given how fat they are
[04:44] <infinity> pitti: But I budgeted for 10TB, so we'll see.
[04:44] <infinity> pitti: See, in my ideal world, we'd have ddebs matching every deb in the librarian.  But we'll find out if that's untenable later, and we can twiddle some knobs to make them expire more aggressively.
[04:45] <pitti> infinity: do we have expiry knobs in LP?
[04:45] <infinity> pitti: Vaguely hardcoded, but yes.
[04:46] <infinity> pitti: Also, raring really has no PPC ddebs? :/
[04:46] <pitti> infinity: they were "first against the wall" while we had them on macquarie
[04:46] <pitti> infinity: I can enable them now, if anyone wants to use them
[04:47] <StevenK> Which is probably infinity and BenC. Only.
[04:47] <infinity> Well, to be fair, I tend to just rebuild things when I need to debug anyway (or, frankly, read gdb backtraces from stripped binaries half the time).
[04:48] <infinity> But if ddebs were actually 100% reliably available, my workflow would likely change, on all arches. :P
[04:48] <infinity> I get so used to stripped backtraces, unstripped ones sometimes seem like information overload.
[04:48] <infinity> "WHOA, HOW DO YOU KNOW ALL THESE THINGS ABOUT MY SOURCE, GDB, ARE YOU SOME SORT OF WIZARD?!"
[04:49] <vibhav> Arent backtraces from striped binaries only "???"?
[04:49] <infinity> vibhav: Assuming they don't end in corrupted frames, stripped backtraces still give me function names, and I can still examine registers and such, it's enough.
[04:50] <infinity> vibhav: And if they do end in corrupted frames, debug symbols won't help you much.
[04:50] <infinity> When I was your age, we used to debug in the snow, uphill, both ways.
[04:50] <erickLee> infinity:pitti:vibhav: can any of you take time out to help a beginner?
[04:50] <vibhav> erickLee: Never ask to ask :)
[04:51] <erickLee> vibhav:well i clearly asked and no one has responded
[04:52] <vibhav> erickLee: Can you tell me the arguments to pbuilder-dist?
[04:52] <erickLee> pbuilder -dist <release> create, not working for precise pangolin
[04:52] <erickLee> or precise-pangolin
[04:52] <erickLee> or Precise-Pangolin
[04:52] <vibhav> erickLee: You typed <release>?
[04:53] <erickLee> no
[04:53] <StevenK> erickLee: 'precise'
[04:53] <erickLee> i typed the distro without <>
[04:53] <erickLee> also tried precise
[04:53] <erickLee> also tried pangolin
[04:53] <erickLee> also googled
[04:53] <StevenK> erickLee: Pastebin the output of 'pbuilder-dist precise create' ?
[04:54] <erickLee> Warning: Unknown distribution "Precise". Do you want to continue [y|N]? n
[04:54] <vibhav> infinity: You used to debug at the age of 15?
[04:54] <vibhav> erickLee: Its "precise", not "Precise"
[04:54] <infinity> vibhav: Much younger.
[04:55] <pitti> infinity: you used protection, I hope?
[04:55] <pitti> like efence?
[04:55] <StevenK> Bad pbuilder-dist, that's a series, not a distribution.
[04:56] <infinity> Bad docs still recommending pbuilder. :/
[04:56] <vibhav> infinity: :O
[04:56] <erickLee> vibhav:thank you. sorry. could have sworn i tried the lower case.
[04:56] <infinity> Can we somehow burn them all with fire and get people standardized on schroot/sbuild and mk-sbuild?
[04:56] <vibhav> clearly, people in the older days were geniuses
[04:56] <infinity> vibhav: Not a genius, I just had cruel parents.
[04:56] <infinity> vibhav: They bought us a computer instead of a Nintendo and said "if you want to play video games, learn to write them first".
[04:57] <vibhav> That aint cruel
[04:57] <pitti> infinity: OOI, do we have some scriptery which sets up schroots with ephemeral tmpfs overlays automatically?
[04:57] <vibhav> infinity: Thats excellent parenting :)
[04:57] <infinity> vibhav: It is when you're 4.
[04:57] <pitti> infinity: that would be the one thing that would finally cause me to move away from plain schroots
[04:58] <infinity> pitti: mk-sbuild sets up ephemeral schroots by default.
[04:58] <StevenK> I quite like LVM plus snapshots for sbuild, it's handy
[04:58] <infinity> pitti: The overlay 'area' is just a directory, and I mount a tmpfs there.
[04:59] <infinity> schroot        /var/lib/schroot/union/overlay/            tmpfs   size=75%          0       0
[04:59] <infinity> schroot          12G  1.6G   11G  14% /var/lib/schroot/union/overlay
[04:59] <pitti> infinity: sweet, that's just what I'm looking for
[04:59] <pitti> infinity: can you get an interactive shell in these, too? (for running tests etc. manually)
[05:00] <infinity> pitti: Of course.  It's just an schroot like any other.
[05:00] <infinity> pitti: Just that when you leave the session, the overlay goes away.
[05:00] <infinity> pitti: But you can start schroot sessions and make them long-running, and kill them later.
[05:00] <pitti> infinity: I'm sold, I think
[05:01] <infinity> (By default, entering and exiting starts and kills a session, though, which is also the mode that sbuild uses)
[05:01] <pitti> old habits die hard, but that does sound much nicer than repeatedly installing and uninstalling packages from experimental in my sid chroot
[05:01] <infinity> But you can ask sbuild not to do that, etc.
[05:01] <infinity> pitti: And, on top of that, there's some fancy from Andy to keep schroots pocket-free.
[05:02] <infinity> pitti: Witness the subtle difference when I enter a source chroot or an ephemeral one: http://paste.ubuntu.com/5566819/
[05:03] <pitti> oh, sweet
[05:03] <pitti> infinity: what does "source:" mean in that context?
[05:03] <pitti> it sounds like "release-only:"
[05:03] <infinity> pitti: The on-disk underlay.
[05:03] <pitti> oh
[05:04] <infinity> pitti: As in, the chroot you'd actually upgrade occasionally, rather than the ephemeral overlay you play in.
[05:04] <pitti> i. e. that's what you log into for running dist-upgrade and initial setup
[05:04]  * infinity nods.
[05:05] <infinity> I find combining tmpfs-overlay schroots, sbuild, and a local apt-cacher-ng on my laptop makes sbuild pretty much the most pleasant experience ever.
[05:05] <infinity> Build-deps "download" and install in a matter of seconds.
[05:05] <infinity> So, repeated fresh builds don't annoy you.
[05:05] <StevenK> infinity: Your local mirror is unloved?
[05:05] <pitti> yeah, it's always a pleasure to see how fast stuff installs in kvms that run an overlay in tmpfs
[05:06] <infinity> StevenK: My local mirror is dead right now, but that's not really relevant.  The laptop has a cache regardless, so it can travel to conferences and make me not want to stab small children with forks.
[05:06] <micahg> that only works if your mirror is *.ubuntu.com and redirected to the conference mirror
[05:07] <infinity> micahg: You assume I only travel places with Canonical IS in a back room...
[05:07] <StevenK> Which is a UDS only thing, and isn't what infinity said.
[05:07] <micahg> infinity: heh, right, well, nevermind, I use mirror.anl.gov from conferences, so ignore me
[05:08] <infinity> micahg: Well, that's another bonus for apt-cacher-ng.  You can just have your sources.list always say archive.ubuntu.com and then twiddle the backend config to aim it at different mirrors if you georelocate.
[05:09] <micahg> ooh, haven't tried that one yet
[05:10] <infinity> I don't tend to muck with the Ubuntu configs much, but my Debian mirror du jour seems to change every few months, when I find a better one. :P
[05:12] <vibhav>  /win 15
[05:39] <pitti> infinity: I set up a fresh one, and it complains about "union-type" in the config file; do you have that in there as well? (/etc/schroot/chroot.d/sbuild-lucid-amd64 says union-type=overlayfs)
[05:41] <infinity> pitti: Mine are set to aufs, because overlayfs bugs annoy me, but both should work.
[05:42] <pitti> $ LANG= schroot -c lucid-amd64
[05:42] <pitti> W: line 10 [lucid-amd64] union-type: Configuration key name ‘union-type’ is not a permitted name.
[05:42] <pitti> hmm
[05:44] <infinity> How... Odd.
[05:44] <infinity> http://paste.ubuntu.com/5566870/ <-- schroot likes that one just fine.
[05:45] <infinity> On raring here, but I'm sure precise would be happy too.
[05:45] <pitti> ah, I created it as type=filel
[05:45] <pitti> "file", too
[05:45] <infinity> Ahh.
[05:45] <pitti> that is an implied overlay, I guess :)
[05:45] <pitti> I want to keep the rarely used ones compressed
[05:45] <infinity> Well, not an overlay, but implied ephemeral, cause it unpacks a fresh copy every time.
[05:45] <infinity> You could just have your underlays on a compressed filesystem.
[05:46] <infinity> Get fancy and make it a readonly lzma squashfs or something.
[05:46] <infinity> Bit of a pain to maintain and upgrade, though.
[05:46] <pitti> *shrug* untar into tmpfs is fine for the four times in a year I have to build a lucid package
[05:47] <infinity> Perhaps, but an uncompressed base chroot isn't exactly big.
[05:49] <infinity> pitti: http://paste.ubuntu.com/5566879/ <-- 6G total isn't much, is it?
[05:49] <infinity> Unless you're on a 64G SSD or something.
[05:49] <pitti> indeed
[05:49] <infinity> Then everything looks big.
[05:49] <pitti> 128 GB here
[05:56] <lifeless> you could use a qcow2 file as your base
[05:56] <lifeless> mount with a throwaway overlay
[05:57] <pitti> that's what I use for kvm
[06:32] <erickLee> bzr branch ubuntu:kdetoys
[06:32] <erickLee> Agent admitted failure to sign using the key.
[06:32] <erickLee> Permission denied (publickey).
[06:32] <erickLee> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
[06:32] <erickLee> Agent admitted failure to sign using the key.
[06:32] <erickLee> Permission denied (publickey).
[06:32] <erickLee> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[06:33] <erickLee> help please
[06:35] <StevenK> erickLee: lp:ubuntu/kdetoys
[06:36] <erickLee> Stevenk: what is lp
[06:47] <lifeless> StevenK: Isn't ubuntu an alias to lp:ubuntu, added by buildded?
[06:48] <StevenK> lifeless: I hadn't been exposed to it, but it does look that way
[06:48] <lifeless> erickLee: lp: is the actual name that bzr is using.
[06:49] <lifeless> erickLee: looks like an ssh key issue with your configured username on Launchpad
[06:49] <lifeless> erickLee: that, or your agent error - forgetten your passphrase perhaps ?
[06:50] <erickLee> lifeless:okay i'm on launchpad. what must i change?
[06:50] <lifeless> I don't know, I'm not you.
[06:51] <lifeless> erickLee: you need to figure out your ssh key issue
[06:51] <erickLee> lifeless: i imported it to launchpad.
[06:56] <ScottK> erickLee: Also, if you're interested in kdetoys, the Kubuntu team doesn't use those branches.  https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdetoys
[06:57] <erickLee> ScottK: i'm not exactly instrest in them i am simple trying to follow te steps in setting up.
[06:57] <ScottK> OK.
[06:58] <erickLee> scottK: it would e okay if things worked as they are apparently suppose to.
[06:59] <erickLee> honestly i can't complain. i've gotten this far.
[07:02] <erickLee> what is suppose to happen when you click on your own ssh key?
[07:05] <ScottK> You're supposed to see the key.
[07:05] <ScottK> https://launchpad.net/~kitterman/+sshkeys
[07:07] <erickLee> Stevenk: lifeless: apparent fix was turning my computer off and then on again.
[07:22] <dholbach> good morning
[08:52] <darkxst> didrocks, Hi
[08:52] <didrocks> hey darkxst
[08:52] <darkxst> just wondering if you are able to add an endorsement for my membership application
[08:53] <didrocks> darkxst: do you have the list of packages I sponsored for you? I need to have a look again :)
[08:55] <darkxst> didrocks, there are a few on this list, http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*Lunn*&sponsoree_search=name
[08:58] <didrocks> darkxst: hum, I only sponsored very trivial things, I unfortunately can't give an endorsement with the few work I sponsored for you, I can add a comment if you want me to :)
[08:58] <darkxst> there might have been a couple more, but I am having a hard time tracking down all packages I have done
[08:58] <darkxst> didrocks, sure that is fine
[08:59] <didrocks> darkxst: doing then :)
[08:59] <darkxst> I will just blame jbicha for sponsoring too much of my work ;)
[09:00] <didrocks> heh
[09:19] <doko> main.c: In function 'main':
[09:19] <doko> main.c:391:2: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669) [-Werror=deprecated-declarations]
[09:19] <doko>   g_type_init();
[09:19] <doko>   ^
[09:19] <doko> cc1: all warnings being treated as errors
[09:19] <doko> seb128, didrocks: there are a lot of these ... how should these be fixed?
[09:20] <seb128> doko, by dropping the g_type_init() call or not use Werrror
[09:20] <doko> seb128, just dropping?
[09:21] <seb128> doko, yes
[09:22] <seb128> doko, e.g http://git.gnome.org/browse/gedit/commit/?id=a68100b607f165497bcc05ce48d11694e2f795ed
[09:22] <doko> ok
[09:24] <Laney> doko: You can forward patches to only call that #if !GLIB_CHECK_VERSION(2,35,0)
[09:24] <doko> mehh
[09:24] <Laney> upstreams might be concerned with keeping backwards compatibility
[09:25] <Laney> where's that common FTBFS causes wiki page?
[09:30] <Laney> oh yeah, Debian wiki passwords got compromised, didn't they?
[09:37] <seb128> doko, https://mail.gnome.org/archives/commits-list/2012-December/msg04044.html for an example of version check as Laney mentioned
[09:37] <seb128> if you want your code to work on both old and new glib
[09:41] <Laney> yeah added it to http://wiki.debian.org/qa.debian.org/FTBFS
[09:46] <seb128> Laney, thanks
[09:49] <seb128> doko, btw, would be nice if you could do a merge request against lp:remote-login-service for your fix there
[10:01] <seb128> doko, same for ubuntu-geoip?
[10:06] <mlankhorst> hmmz
[10:06] <mlankhorst> https://launchpad.net/ubuntu/+source/mesa-lts-quantal 'pending publication' what does that mean?
[10:08] <doko> infinity, pdl: ...
[10:08] <doko>   int pipes[2];
[10:08] <doko>   if(pid==0) {
[10:08] <doko>     dup2(pipes[1],1);
[10:08] <doko>     dup2(pipes[2],2);
[10:09] <mlankhorst> RAOF: ^
[10:11] <geser> mlankhorst: it means the debs are in binary NEW (an archive admin needs to check and approve them)
[10:12] <mlankhorst> oh
[10:12] <mlankhorst> well that explains why bug description didn't update then
[10:34] <doko> Daviey, do you have any plans for ruby? e.g. dropping 1.8?
[10:34] <doko> and adding 2.0?
[10:34]  * doko ducks
[10:36] <seb128> doko, do you plan to file the merge requests/upstream the patches for the stuff you fix? ;-)
[10:36] <Daviey> doko: I have no plans for ruby at all :)
[10:36] <doko> Daviey, I did fear that ...
[10:37] <doko> seb128, if you do want to have it now, please could you merge it?
[10:37] <seb128> doko, I'm not upstream for those and I don't plan to touch them soon, but I would prefer to see those fix go upstream so nobody else duplicate the work you are doing
[10:38] <seb128> doko, otherwise we just waste time/resources redoing the same things at different places
[11:04] <wookey> I'm doing second stage of a multistrapped filesystem image and ifupdown puts a line into /var/lib/dpkg/status which is a conffile with no md5sum
[11:04] <wookey> this is an illeghal entry and breaks dpkg
[11:04] <wookey> what should be there is apparently:  /etc/init.d/networking ce96a6f22cc836088eef6673d853a765 obsolete
[11:04] <zyga> wookey: why on earth would ifupdown want to mess with dpkg/status?
[11:04] <wookey>  /etc/init.d/networking f5a562ab343f7e58dd7cb21636429332
[11:05] <wookey> zyga: werll I don';t suppose it does it itself
[11:05] <wookey> I mean that if that package is included then the status file ends up looking like that
[11:05] <wookey> I don;t know what/who is responsible fo creating those entreis
[11:05] <wookey> that was kind of my question.
[11:05] <wookey> presumably dpkg is, so packages can;t screw it up
[11:06] <zyga> wookey: smells like some dpkg internal or debian config file helper
[11:06] <wookey> hmm. mind you . I think multistrap may mess with it. Maybe it's not getting obsoleted conffiles right...
[11:07] <wookey> I'll check to see if it's bust before I even boot. I assumed it was something int eh dpkg --configure -a stage that was going wrong, but maybe not
[11:08] <wookey> that file is a link to /lib/init/upstart-job
[11:09] <wookey> so I guess the database is updated when a package replaces a conffile in this way?
[11:09] <zyga> wookey: sounds sensible but I don't know dpkg that much
[11:10] <apw> pitti, i seem to have an apport recursion issue with ccsm
[11:10] <apw> pitti, obviosly apport won't file a bug on it :/
[12:06] <apw> didrocks, hey ... pidgin in raring seems to have gone to hell for me, is this known
[12:06] <didrocks> apw: hum, not really (I don't use it), the last upload I did was only linked to the IRC client plugin
[12:06] <didrocks> maybe seb128 will know a little bit more, he's using it ^
[12:07] <apw> arse
[12:07] <apw> just hangs dead mostly, not a well bunny
[12:07] <didrocks> apw: did you try to remove the IRC plugin? would be a first step to find if this is the guilty part
[12:07] <didrocks> apw: do you have IRC configured?
[12:07] <apw> didrocks, i have irc accounts in my config, but disabled
[12:08] <apw> for emergency use, but not being used activly
[12:08] <didrocks> ok, shouldn't be the guilty then, let's wait if seb128 knows more about it
[12:10] <apw> didrocks,   /usr/lib/purple-2/libirc.so ?
[12:10] <apw> is that the plugin?
[12:10] <didrocks> apw: yep, you can try rename it
[12:10] <didrocks> and restart pidgin
[12:12] <apw> didrocks, this is more serious, it is ticklng someting which is bustin compiz or X
[12:12] <apw> sigh
[12:13] <apw> i knew i should have kept this machine on quantal
[12:14] <didrocks> apw: I just tried again, don't have anything, let's see if the latest gtk/gnome stack my impact
[12:14] <didrocks> may*
[12:15] <apw> didrocks, yeah this is a fresh upgrade q->r though pidgin is broken on another R i have as well it seems
[12:36] <seb128> didrocks, apw: I'm back from lunch
[12:36] <seb128> apw, what's the issue exactly? pidgin works fine here
[12:39] <apw> seb128, when i start it it just greys out, typically starting when i hit a second account enable
[12:39] <Laney> blame the kernel
[12:39]  * Laney runs
[12:39] <apw> though .. i have just discovered i am having issues with flipping, so perhaps compiz is being broke by that and its just what pidgin displays
[12:40] <seb128> apw, can you gdb pidgin and ctrl-C, bt when it hangs?
[12:40] <apw> seb128, will do
[12:40] <seb128> thanks
[12:40] <seb128> I had an issue yesterday with dbus
[12:40] <seb128> stuff would hang for like 15 seconds in dbus calls
[12:41] <seb128> I'm wondering if you have something similar, though mine was affecting random apps, like xchat when clicking on an url, firefox, etc
[12:41] <apw> bt shows it polling
[12:42] <apw> seb128, but it has 5 threads, and only one stack trace
[12:42] <seb128> apw, can you pastebin the bt?
[12:43] <apw> http://paste.ubuntu.com/5567518/
[12:43] <apw> oh now it wants to be raised all the time
[12:43] <seb128> #6  0xb75a1374 in g_spawn_command_line_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
[12:43] <apw> ?
[12:44] <seb128> apw, can you install the dbg package for glib? would be nice to see what commands it calls which is hanging
[12:45] <apw> seb128, why is it so hard to find the name of the debug packages
[12:46] <seb128> apw, I tend to dpkg -S <binary> and append -dbgsym to the name it gives me
[12:47] <apw> seb128, ok ... isntaling the -dbg version of that made the issue go away
[12:47] <seb128> hum
[12:48] <seb128> I guess time made it go away
[12:48] <seb128> no reason the dbg should change anything
[12:48] <apw> libglib2.0-0-dbg
[12:48] <apw> was what i installed
[12:49] <apw> seb128, ahh no just sometimes ione gets lucky
[12:50] <apw> seb128, http://paste.ubuntu.com/5567533/
[12:50] <seb128> apw, "gsettings get org.gnome.system.proxy mode" ... does that hang the same way?
[12:50] <seb128> or takes time to return?
[12:52] <mlankhorst> bregma: I pushed packaging for xorg-gtest 0.7.1 to the xorg-gtest git tree in debian
[12:53] <apw> seb128, nope
[12:53] <mlankhorst> oh looks like you put it in collab-maint :/
[12:54] <seb128> apw, weird, did you try a few times?
[12:54] <seb128> apw, it seems like the issue I had yesterday where dbus call where randomly hanging for a while
[12:54] <seb128> that impacted several apps for me
[12:55] <seb128> apw, in any case I doubt it's a pidgin issue, I'm pretty sure that if you look at the processes running when you get the issue the gsettings get command will be running and hanging a dbus call (if you gdb to it you can check)
[12:55] <apw> seb128, just tried several 1000 and nothing unusual
[12:56] <seb128> apw, can you get pidgin to hang, look at ps afx | grep gsettings and gdb to the gsettings get if there is one?
[12:57] <apw> seb128, even seems fine when pidgin is stuck
[12:57] <seb128> apw, no gsettings get process?
[12:57] <seb128> apw, that stacktrace doesn't make sense then...
[12:57] <apw> seb128, 18734 pts/8    Z+     0:00              \_ [gsettings] <defunct>
[12:57] <apw> so there was and it is dead
[12:58] <seb128> that's pretty weird
[12:58] <apw> seb128, the pdigin thread which ran it has also exited, and not been reaped
[12:59] <seb128> there is something weird going on at the low level
[12:59] <apw> seb128, can i get gdb to give me bts on the other threaads
[12:59] <seb128> not sure what though
[12:59] <seb128> apw, you can "thread apply all bt"
[13:01] <apw> seb128, http://paste.ubuntu.com/5567558/
[13:01] <apw> (this is a new repoduce)
[13:01] <seb128> apw, well, thread 1 is waiting for the command_line=0xb74cc214 "gsettings get org.gnome.system.proxy mode", to return
[13:02] <seb128> can you see if that one is running/defunct/...?
[13:02] <seb128> apw, do you have hangs in other commands, e.g gvfs-ls ?
[13:02] <apw> seb128, it is defunct
[13:03] <seb128> or gvfs-mount -li
[13:03] <apw> gvfs-ls works fine
[13:03] <apw> nope that works too
[13:03] <seb128> apw, nothing weird in system log, syslog, dmesg, etc?
[13:04] <seb128> apw, the bottom of the issue is that those gsettings call go defunct and that pidgin has a sync call waiting on the output of those commands
[13:04] <seb128> I've no idea why would that happen though :-(
[13:04] <apw> seb128, implies there is a bug in there, that the glib call is not noticing that the other end is gone
[13:04] <seb128> but I hit a similar bug yesterday with firefox
[13:04] <apw> seb128, classic fail there is to not close your copy of the other end of the pipe
[13:05] <apw> so that you don't get an eof on exit
[13:05] <seb128> apw, well, is "defunct" really "gone"?
[13:08] <apw> yes, that means it is a zombie, the process slot only has the exit status for the parent
[13:08] <apw> there is no process any more
[13:08] <apw> that means someone asked for the exit to be reported and didn't wait for it yet
[13:08] <apw> and the thread being in poll tends to fit witht hat
[13:09] <seb128> apw, did you do an upgrade before the issue started? what did it include?
[13:09] <seb128> apw, yeah, there might be a bug there in the handling of the buggy situation, still the bottom of the issue to me is that those gsettings process get defunct
[13:29] <apw> seb128, that is a normal part of life for a process, if you run something it always goes defunct
[13:29] <apw> seb128, then either the parent or init reads the exit value and releases it
[13:29] <cjwatson> right, the problem is that it's not being reaped, not that it's defunct
[13:29] <apw> the issue is that the parent is stuck in poll whne we might expect it to be reaping the exit
[13:30] <cjwatson> (though I think that's probably what seb128 meant ...)
[13:30] <apw> oh heh, language barriers :)
[13:30] <seb128> cjwatson, right
[13:30] <seb128> sorry for the confusion
[13:31] <apw> now to guess which source pacakge that g_spawn_sync hides in
[13:31] <cjwatson> IME tracking that down is a matter of staring at an strace until enlightenment arrives
[13:31] <cjwatson> apw: glib2.0
[13:31] <cjwatson> g_spawn_sync is used all over the place - it's rather unlikely to be broken itself, I think?
[13:32] <seb128> right, and it didn't get any change upstream since novembre
[13:32] <apw> cjwatson, well we could have changed a kernel semantic within the valid ranges and found a bug
[13:32] <cjwatson> true
[13:32] <seb128> apw, is that bug persistant across reboots?
[13:32] <apw> seb128, yep
[13:32] <apw> seb128, though in gdb i get away with it sometimes
[13:32] <seb128> apw, do you use the raring kernel? can you try booting an older one?
[13:32] <apw> so it must be a race
[13:33] <apw> seb128, i could try that i suspect in a bit yeah
[13:38] <apw> this has a nasty comment about a second child to prevent zombies ... sounds racy
[13:42] <seb128> apw, when did the issue start? can you try if downgrading libglib2.0-0 to the previous version fixes it for you?
[14:11] <Quintasan> dholbach: ping
[14:14] <dholbach> Quintasan, pong
[14:14]  * Laney 
[14:14] <Laney> @pilot in
[14:15] <Quintasan> dholbach: hmmm, actually mind if I query?
[14:15]  * dholbach hugs Laney
[14:15] <dholbach> not at all, please do
[14:20]  * Laney prods xnox https://code.launchpad.net/~brightbox/ubuntu/raring/lvm2/fix-for-1075994/+merge/142531
[14:20] <Laney> top item in the queue(!)
[14:21] <xnox> Laney: sure, but it needs ideally thin_provisioning package & update to much newer lvm2
[14:21] <xnox> (ahead of debian)
[14:25] <Laney> xnox: then could you reply to the MP saying so and set it to WIP?
[14:26] <xnox> ok.
[14:27] <Laney> merci
[14:28] <xnox> although, I could just apply, as it literally makes no difference to the archive as it is, but does help testing thin provisioning.
[14:28] <Quintasan> Laney: urgh, first two weeks at my uni are a nightmare, I will look at this im-{config,switch} magic now
[14:28] <Laney> awesome
[14:30] <Quintasan> Laney: in short, im-switch works but im-config does not, right?
[14:31]  * Quintasan downloads the Debian source instead
[14:31] <Laney> right, im-config needs special work (I understand in the im-config source package itself)
[14:31] <Laney> you should get maliit-{framework,plugins} from raring-proposed
[14:31] <Laney> it's newer - I'll update Debian once it gets out of NEW
[14:32] <Quintasan> okay
[14:42] <Quintasan> Laney: well, this looks like "make patch; send upstream; wait" procedure, writing patch then
[15:06] <Quintasan> Laney: One thing, shouldn't maliit-framework binary package Recommend maliit-dbus-activation as well?
[15:06] <Laney> no, we don't want that by default
[15:07] <Quintasan> I see
[15:07] <Laney> we/upstream
[15:07] <Laney> otherwise you get it all the time which is annoying
[15:07] <Laney> you're supposed to select it as your input method if you want it
[15:07] <Laney> or install that package
[15:08] <Laney> like some types of image (tablets) might seed that package too
[15:11] <Quintasan> Laney: Yeah, now that I look at it, it's a great idea
[15:11]  * Quintasan woulnd't think about it until he go Mallit on all the time
[15:11] <Quintasan> s/go/get
[15:19] <mitya57> hi barry, I wonder if you have an opinion on http://lists.debian.org/debian-python/2013/02/msg00209.html and what should we do in Ubuntu?
[15:21] <mitya57> I propose that we keep the patch this cycle but try to fix as many packages as we can (there are more in Ubuntu than in Debian)
[15:21] <barry> mitya57: hi.  i have to admit, i'm uncomfortable with removing those scripts, but tumbleweed makes a persuasive argument (esp. w.r.t. the -dbg flavors).  i should follow up on that thread, but ubuntu should follow debian (i'd rather not have them behave differently)
[15:21] <mitya57> and get rid of it next cycle
[15:21] <barry> mitya57: how many do we have?
[15:21] <tumbleweed> barry: those weren't actually all my arguments - I just summarised :)
[15:21] <barry> tumbleweed: ah ;)
[15:22] <barry> tumbleweed: i wish we could do #4 though ;)
[15:22] <tumbleweed> I was in favour of 4, but the tide seemed against me
[15:22] <tumbleweed> als, -dbg...
[15:22] <tumbleweed> *also
[15:22] <barry> yeah
[15:23]  * barry should at least follow up on the mlist
[15:23] <mitya57> so do you like my plan (above)?
[15:23] <barry> mitya57: how many do we have to fix in ubuntu?
[15:25] <mitya57> barry: some ubuntuone/signon/software-center stuff b-d's on python3-nose, but I haven't yet looked at that
[15:27]  * mitya57 wonders why upstream hasn't yet released 1.3 (they promised it last week)
[15:35] <mitya57> barry: it was actually jcristau who was against #4
[15:35] <barry> mitya57: oh, then we should just do #4 then :)
[15:36] <doko> seb128, Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/remote-login-service/trunk doesn't exist
[15:37] <mitya57> barry: feel free to commit that or wait until I have time for that (probably on weekend)
[15:37] <tumbleweed> barry: of course, it's also the kind of thing that we were trying to get away from, in python-support
[15:38] <barry> tumbleweed: they don't have to be symlinks ;)  but yeah, i get the larger point.  it bothers me less for targetted command line scripts like this, but otoh, it might be setting a bad precedent (what about other python scripts that are version dependent?)
[15:38] <seb128> doko, I guess it's being transitioned to inline packaging, just submit to lp:remote-login-service
[15:39] <barry> tumbleweed: maybe nose really needs a driver script that isn't version dependent but invokes a version dependent subprocess, kind of like the way virtualenv takes a -p option
[15:39] <doko> seb128, well, you could fix the header and submit it too ;)
[15:39] <tumbleweed> barry: that kind of thing would probably be useful
[15:39] <barry> tumbleweed, mitya57 then /usr/bin/nosetest could even be a shell script
[15:39] <tumbleweed> (and this applies to all the tools like this - mostely test runners, I guess)
[15:40] <barry> i suppose we should engage with upstream about it
[15:40] <seb128> doko, I could ;-)
[15:40] <doko> barry, tumbleweed: you mean, creating the scripts in the maintainer scripts?
[15:40] <barry> doko: yes
[15:40]  * doko reset's barry's karma to -5000
[15:40] <barry> :-D
[15:41] <tumbleweed> I guess doko has strong opinions on this :)
[15:41] <doko> THATS INSANE!
[15:41] <barry> i'll bring the issue up on the tip list to see what suggestions they might have
[15:41] <mitya57> the current patch doesn't look sane as well
[15:42]  * barry is starting to like `nose -p python3.3`
[15:42] <doko> well, we are trying to go away with creation of files in the maintainer scripts (besides the bytecode), so why add another one?
[15:42] <mitya57> python3.3 -m nose?
[15:43] <tumbleweed> doko: yes, which is why we are talking about alternatives
[15:43] <barry> mitya57: hmm, i suppose so, yes
[15:43] <barry> % python3.3 -m nose
[15:43] <barry> /usr/bin/python3.3: No module named nose.__main__; 'nose' is a package and cannot be directly executed
[15:43] <tumbleweed> we could encourage upstreams to support usage like that
[15:44] <tumbleweed> (it's painful to implement in 2.6, though)
[15:44] <tumbleweed> err impossible
[15:44] <barry> tumbleweed: what's this "2.6" you speak of? <wink>
[15:44] <tumbleweed> debian still has it
[15:44] <tumbleweed> but hopefully soon :)
[15:44] <barry> :)
[15:45] <mitya57> nose itself still supports 2.4 :)
[15:45] <barry> mitya57: why do you make me cry?
[15:45] <mitya57> barry: https://github.com/nose-devs/nose/commit/e1de7970df7a03e49fe3305394bf92020d3944ef
[15:46] <doko> jodh, the upstart build hangs on sagari/powerpc. I'm asking to kill it
[15:46] <barry> sigh
[15:48] <tumbleweed> people use redhat...
[15:49] <tumbleweed> still, nothing wrong with trying to get this supported for the pythons that support it
[15:50] <vibhav> Does glibc in arm have gets() undeclared?
[15:54] <timrc> hallyn, would lxc-ssh -n <name_of_container> be a completely dumb feature?  I find myself start'ing lxc containers and hating the console and I'm not aware of a way of easily getting the IP of the container without logging into the console, first
[15:54] <timrc> in via the console, rather
[15:55] <hallyn> timrc: i thought we had somethinglike that, actually,
[15:56] <hallyn> timrc: what i use is a ~/.ssh/config section to do 'ssh container@lxc'
[15:56] <hallyn> stgraber: didn't we have 'lxc-ip' at one point?
[15:57] <timrc> hallyn, ah, yeah I don't see lxc-ssh or lxc-ip with lxc  0.9.0~alpha3-0ubuntu2 (in Raring)
[15:57] <stgraber> hallyn: very briefly
[15:57] <Laney> hyperair: are you aware jockey is universe?
[15:57] <hallyn> timrc: http://paste.ubuntu.com/5567956/
[15:57] <Laney> re: bug #1130684
[15:57] <hallyn> timrc: gotta run, server mtg - ttyl
[15:57] <stgraber> timrc: https://www.stgraber.org/2012/07/17/easily-ssh-to-your-containers-and-vms-on-ubuntu-12-04-lts/
[15:58] <stgraber> timrc: doesn't work terribly well on 13.04 at the moment because of some dnsmasq weirdness (randomly fails to resolve here)
[15:59] <timrc> stgraber, cool, this will be useful :)
[16:00] <barry> tumbleweed, mitya57, doko https://github.com/nose-devs/nose/issues/634
[16:03] <cjwatson> vibhav: I expect you've run into a gnulib bug for which there's a fairly standard patch you can backport - look at any of m4, cpio, diffutils, parted (off the top of my head)
[16:08] <mitya57> barry: subscribed, thanks
[16:08] <tumbleweed> that sounds like it'd be a trivial patch, maybe in an hour or two...
[16:16] <vibhav> cjwatson: apparently, guile ftbfses on arm with this message
[16:16] <vibhav> stdio.h: gets() undeclared
[16:17] <cjwatson> vibhav: bet it'd fail on i386 if rebuilt nowadays
[16:18] <cjwatson> vibhav: sounds like the same thing fixed in those other packages I mentioned
[16:20] <vibhav> cjwatson: Wait, so the bug is not platform specific?
[16:20] <infinity> vibhav: Nope.
[16:20] <infinity> vibhav: gets() jas been deprecated for a decade, and was removed entirely in C11.
[16:21] <vibhav> Ah, I forgot the standard
[16:21] <infinity> vibhav: The irony here being that gnulib tries to check for the use of gets() to warn you not to use it. :P
[16:21] <infinity> vibhav: But fails if it's not defined at all (oops).
[16:21] <vibhav> Yeah, there is some code which warns you for using gets
[16:21] <vibhav> Not secure, or something
[16:23] <vibhav> cjwatson, infinity: Thanks. I will have a look ASAP then.
[16:24] <infinity> vibhav: Upstream has probably already fixed it.
[16:24] <infinity> vibhav: So, I'd start by looking there.
[16:26] <vibhav> infinity: just a question. Shouldn't gnulib fix the bug rather than the apps using it?
[16:28] <cjwatson> gnulib has fixed the bug
[16:29] <cjwatson> But the model for using gnulib involves copying files into other package sources, because the point of gnulib is to supply compatibility for systems lacking things
[16:29] <infinity> vibhav: gnulib tends to be embedded (and in a variety of ways) in other people's source, it's not a standalone build-dependency.
[16:29] <vibhav> Ah, I see
[16:35] <didrocks> hey barry! seems bug #1105215 is due to python3 piston, right?
[16:47] <mitya57> didrocks: s/message/strerror/g should work
[16:48] <didrocks> mitya57: thanks for the pointer!
[16:48] <mitya57> and btw socket.gaierror is subclass of socket.error so no need to catch both
[16:50] <didrocks> mitya57: it seems you are way more knowledge than I am here (especially in piston that I don't know at all), do you have time/mind prepping a patch for it? dobey maybe can review as well as piston-mini-client is part of what software-center used/produced, maybe?
[16:50] <Riddell> ogra_: don't forget your promise to make kubuntu nexus images last week :)
[16:51] <ogra_> Riddell, oh, ah ... whats the flavour name ? kubuntu-active ?
[16:51] <mitya57> didrocks: ok, will propose merge now ;)
[16:51] <didrocks> mitya57: thanks a million :-)
[16:51] <Riddell> ogra_: yep
[16:52] <ogra_> ok
[16:52] <ogra_> fiddling with it now
[16:55] <ogra_> Riddell, running a manual build with what i think is the right command, lets see what comes out, if it works i'll add it to the crontab
[16:56] <Riddell> ogra_: groovy
[16:59] <dobey> pitti: can you accept tomboy into precise-proposed? looks like it got uploaded, and accepted everywhere but on precise. thanks
[17:15] <didrocks> dobey: do you want to look at the piston branch?
[17:26] <barry> @pilot in
[17:29] <GridCube> hi, if someone wanted to help translating the ubuntu documentation to spanish, who would he have to contact?
[17:32] <didrocks> barry: I have a branch for you to sponsor I guess (see my above ping ;)): https://code.launchpad.net/~mitya57/piston-mini-client/lp1105215/+merge/150619
[17:32] <didrocks> thanks mitya57 :)
[17:38] <barry> didrocks: i'll take a look after lunch
[17:39] <didrocks> thanks barry :)
[18:01] <Laney> @pilot out
[18:07] <mitya57> GridCube: if you mean https://help.ubuntu.com/12.10/ubuntu-help/index.html, then it looks fully translated
[18:08] <GridCube> where?
[18:09] <mitya57> https://translations.launchpad.net/ubuntu/raring/+source/ubuntu-docs/
[18:09] <GridCube> :) good
[18:10] <GridCube> in any case, they want to help contributing with documentation, if its not translations then something else could be done
[18:12] <mitya57> GridCube: they can ask on #ubuntu-doc probably
[18:22] <GridCube> C: i recommended them that too
[18:41] <psusi> smoser: ping
[18:42] <smoser> psusi, here.
[18:43] <psusi> smoser: I saw you merged the kpartx -u patch... I got the parted version backported if you were interested in that
[18:44] <psusi> err, partx... I keep wanting to add that darn k ;)
[18:48] <smoser> psusi, i'm ok to look at that and sponsor that if you want
[18:48] <smoser> but i dont have a real need for it.
[18:53] <psusi> smoser: ok... just wasnt sure if it should go in this cycle or wait... but if you're up for it I'll propose merge and request yuo on it?
[18:53] <smoser> sure.
[18:53] <smoser> its upstream, right?
[18:53] <smoser> and doens't have any fallout (ie, all new feature?)
[18:57] <psusi> smoser: all new feature, patches been posted on the upstream ml for a while now but the old maintainer is kind of stepping down and hasn't had time to review and apply it
[19:01] <psusi> or anything else for that matter
[19:01] <psusi> smoser: do you think it should wait for that?
[19:02] <smoser> psusi, well, if we dont have anything that would use it, then there isn't a lot of pressing need for it.
[19:02] <smoser> thats just my opinion, though.
[19:03] <psusi> well, I'm using it right now ;)
[19:03] <smoser> i'm definitely grateful for your work there, and hope not to sound ungrateful.
[19:03] <psusi> to split my raid5 array and use half the space for a raid0 to test if the problem I'm seeing is specific to raid5
[19:04] <psusi> no worries there, just figured now is the time to do it before the freeze if it is going to make it into raring
[19:05] <psusi> I also have worked up a patch to gparted so it can take advantage of it as well
[21:25] <zyga> hi, I'm looking for a way to file bugs on ubuntu vagrant images
[21:26] <zyga> does anyone know where they are hosted (on launchpad) as a project
[22:02] <cjohnston> zyga: talk to utlemming
[22:04] <zyga> cjohnston: thanks
[22:04] <zyga> utlemming: ping
[22:04] <cjohnston> np
[22:04] <zyga> utlemming: I'm using vagrant more and more and one thing starts to bug me, our images have linux-source installed (a whooping 85MB), is that really needed or just an artifact from development stage?
[22:05] <utlemming> zyga: required due to Virtualbox
[22:05] <utlemming> zyga: virtual box won't build the dkms without it
[22:05] <zyga> utlemming: oh? I thought vms only need -headers?
[22:06] <zyga> utlemming: I mean, I have a number of VMs and I'm almost sure they don't have linux-source at all
[22:06] <zyga> (and they all use fs sharing features and other vbox things)
[22:06] <utlemming> zyga: there was a reason for it...and I believe it precise only
[22:06] <zyga> utlemming: ah, might be
[22:06] <zyga> utlemming: is it only on precise, I also have quantal images (though that may be lost in the logs)
[22:07] <utlemming> zyga: precise is bigger...
[22:08] <zyga> utlemming: one more question, is raring working yet? I had to stop using it because vboxfs was not supported at the time
[22:08] <utlemming> zyga: virtualbox is pretty foobar'd at the moment. amd64 might work, but 32-bit won't
[22:08] <zyga> (using raring images)
[22:08] <zyga> utlemming: is that upstream fault or something we can do?
[22:09] <utlemming> zyga: loog at Bug #1101867
[22:10] <zyga> utlemming: it seems there's an upstream patch for that already
[22:11] <zyga> utlemming: any chance raring could get 4.2 with all the patches?
[22:12] <utlemming> zyga: well, I do cloud images...and I'm not a motu. I think that getting a motu to look at importing it would be a first step
[22:14] <zyga> utlemming: I see, perhaps that issue could be escalated if we spend time on getting our vagrant images to work we really need to spend the same time on vagrant and dependencies (so virtualbox) in the same manner for the first expense to be meaningful outside of ubuntu
[22:14] <infinity> Getting 4.2 in Debian would be the path of least resistance.
[22:14] <zyga> utlemming: thanks a lot for the info though
[22:14] <utlemming> zyga: the virtualbox dependency is the _exact_ reason why the images are not officially supported.
[22:14] <zyga> utlemming: I see
[22:14] <utlemming> zyga: you said there were other annoyances...what are they?
[22:15] <zyga> :-)
[22:15] <zyga> utlemming: ah, apart from lack of 4.2 in the archive, vagrant 1.0.6, raring vboxfs and linux-source, vagrant is really a joy to use
[22:27] <utlemming> zyga: looks like I'll have a build that doesn't include linux-source
[22:27] <utlemming> zyga: 12.04 should exit building in ~20 minutes
[22:29] <zyga> utlemming: I'll gladly test that
[22:39] <utlemming> zyga: go ahead and try 12.04
[22:43] <zyga> utlemming: ping me when you know those images are ready please
[22:43] <utlemming> zyga: 12.04 is ready
[22:43] <zyga> utlemming: ok
[22:45] <barry> @pilot out
[23:01] <TheMuso> @pilot in