[00:08] <indy__> Does https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/582199/comments/111 mean I will have to live with the bug until Maverick is released?
[00:10] <xnox> indy__, $ update-manager -d #and click to upgrade to 10.10 ;-)
[00:10] <xnox> but that's if you are ready to upgrade now
[00:10] <xnox> you can request it to be considered for lucid SRU
[00:10] <xnox> !SRU
[00:12] <chrisccoulson> indy__, use the "Nominate for release" button at the top of the bug
[00:12] <indy__> xnox, it's vital for me (and every other one using DELL OPTIPLEX 380) to have sound in my system :)
[00:12] <indy__> so, thanks, I will nominate it ;)
[00:16] <penguin42> you'd think at some point people would stop reinventing how to do simple sound cards
[01:21] <halvors> Hi!
[01:21] <halvors> I have some important issue to report.
[01:21] <halvors> But didn't got it done by Apport.
[01:22] <halvors> Language Support does not download new language.
[01:22] <halvors> This is for the maverick alpha-3 latest update.
[01:22] <halvors> Is there some developers here who can try get it fixed?
[01:43] <persia> Could someone give-back gstreamer0.10/powerpc?  https://launchpad.net/ubuntu/+source/gstreamer0.10/0.10.30-1build2/+build/1913366
[01:46] <cjwatson> persia: done
[01:46] <persia> cjwatson, Thank you.
[01:49] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html - if you suffer from this problem, please follow the instructions in this post to give me more information
[03:33] <pranay_09> in spd-say the language option is just for the accent change?
[07:58] <persia> Could someone please give-back utouch-gesturetest/powerpc : https://launchpad.net/ubuntu/+source/utouch-gesturetest/1.0.4-0ubuntu1/+build/1917849
[07:58] <maco> give-back?
[07:58] <maco> did someone steal it?
[08:00] <persia> "give-back" is short for "Re-add the source to the buildd queue".
[08:01] <persia> I suspect it is also the name of some script that is part of the wanna-build suite, or similar, but that's conjecture.
[08:02] <persia> So, I'm asking that someone with upload rights to that package visit that web page and press the shiny button to get it off the FTBFS list.
[08:03] <maco> you dont have upload rights to it?
[08:04]  * vish wonders why persia explained! maco knows what give-back means! we just need to turn-off maco's sarcastic-mode! ;p
[08:04] <persia> maco, Nope.
[08:04] <cody-somerville> persia, given-back
[08:04] <persia> cody-somerville, Thanks.
[08:09] <maco> persia: i thought you were core dev...
[08:09] <persia> Everyone thinks that for some reason.
[08:10] <persia> But until recently, I had no interest in being core-dev.
[08:10] <maco> i think we assume if youre on the MC youre a core dev
[08:11] <persia> Silly assumption.  Only folks that actually work on core stuff ought be core-dev.
[08:11] <maco> other direction...
[08:11] <maco> more like assumed that only core devs would get elected
[08:11] <persia> My main motivation for doing it now is that I've become a lot more active in powerpc and armel porting, as well as flavour bring-up, all of which essentially requires core-dev.
[08:12] <persia> I can't think of any good reason to only select core-dev.  I'd rather have folks from a variety of development groups, so we're more likely to have significant personal history with new applicants.
[08:12]  * maco headdesks at a PM she just got
[08:13] <persia> Important to have one or two highly respected core-dev to help ensure that the requirements for core-dev aren't loosened, but even a majority is probably overkill.
[08:13] <persia> Could someone give-back xserver-xorg-input-evdev/amd64 : https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.3.2-6ubuntu1/+build/1931435
[08:14] <cody-somerville> done
[08:14] <persia> cody-somerville, Thank you.
[08:14]  * nigelb wonders about the content of the PM
[08:14] <persia> Something that caused a violation of information hygine.  Be careful: it may be contagious!
[08:15] <nigelb> heh
[08:15] <maco> nigelb: female...linux...surprise
[08:15] <persia> No sexism.
[08:15] <nigelb> maco: Sigh.
[08:15] <nigelb> !gender
[08:16] <nigelb> :)
[08:16] <persia> Ugh.
[08:16] <vish> argh!
[08:16] <cody-somerville> moo
[08:16] <maco> apt?
[08:16] <nigelb> heh, quite fun.
[08:16] <persia> No super cow powers.
[08:16] <vish> super moo! o/
[08:17] <maco> one of my laptops has an apt-get sticker with a cow on it
[08:17] <nigelb> one of....
[08:17] <maco> nigelb: the ugly one with all the stickesr
[08:18] <nigelb> maco: that /isn't/ ugly :)
[08:18] <nigelb> Beauty is in the eyes of the beholder.
[08:18] <maco> the stickered one is stickered to hide the ugly
[08:20] <persia> Could someone please give-back unity/amd64 : https://launchpad.net/ubuntu/+source/unity/0.2.32-0ubuntu2/+build/1935946
[08:21]  * persia is stumped at qimageblitz and decides not to submit a patch making it build on amd64/armel/powerpc that breaks i386
[08:21] <nigelb> persia: you know, with so many of us asuming you're core dev, its probably time to be one....
[08:21] <persia> That's kinda why I'm working on main stuff now.
[08:21] <cody-somerville> persia, done
[08:21] <nigelb> \o/
[08:22] <persia> Until I get some real work done in main, I wouldn't confirm myself as core-dev, so wouldn't ask others to do so.
[08:22] <nigelb> You're membership meeting would be one that we'd always point out to others :D
[08:22] <nigelb> DMB member would still have to come for a meeting and no shortcuts etc.
[08:23] <persia> There's already examples of that from the MC.
[08:23] <persia> cody-somerville, Thank you.
[08:23] <nigelb> Ah.  I'm new.  Haven't looked up MC logs.
[08:23] <nigelb> s/new/sortof new/
[08:24] <persia> new is relative.  I'm new in some collections of folks.
[08:24] <nigelb> :)
[10:24] <Padhu> Hi
[10:25] <Padhu> Hi
[10:45] <persia> Could someone help me understand tickcount?  there's a test that seems like it should pass that fails on powerpc and has been subverted to be wrong by patching on armel and i386.  I'd really appreciate a second pair of eyes on it, to help me understand if it's subtly broken everywhere, or if the logic is wrong.
[10:46] <persia> The specific point of confusion is in test_difference_wrap in test_tickcount.py (and it's a small enough program it should be obvious from source inspection)
[11:04] <G> persia: without looking at the source etc, when you are talking about ticks are you talking about time ticks etc?
[11:05]  * G grabs the source in the meantime
[11:05] <persia> Yep.
[11:05] <persia> But there seems to be an off-by-one error somehow.
[11:06] <persia> That said, I don't see why, since UINT_MAX is the same for every architecture in the set i386/amd64/armel/powerpc
[11:11] <G> persia: something certainly doesn't look right
[11:12] <persia> I'm 99% certain the armel and i386 test hack patch is wrong.
[11:13] <persia> But strangely, it passed on amd64.
[11:13] <G> well on amd64 I get the right result
[11:13] <G> yeah
[11:13] <G> persia: let me hunt down a 32bit VM :)
[11:13] <persia> Where it gets extra confusing is if I test with numbers in my python interpreter and a short c hack to show UINT_MAX, I can't see why it should pass for amd64.
[11:14] <persia> (or rather, why the result would be any different than that for powerpc, which is my reference)
[11:14] <persia> G, Also, thanks :)
[11:16] <G> persia: the only 32bit VM I have is RHEL... but I'll also have a look on my mac (i386) as well
[11:16] <persia> I'd suggest trying RHEL first: there's nothing obviously distro-specific in the code.  It might work on MacOS X, but I'm less confident of similarity of python interpreters.
[11:17] <G> yeah, thats my plan
[11:26] <nigelb> cjwatson: Re: GRUB and windows - A friend's Dell had a similar issue.  If we booted into windows, it refused to boot up (I suspect GRUB was getting re-written).  He finally reinstalled windows to get the Windows Boot loader
[11:26] <nigelb> (Of note, Windows 7 Ultimate and Ubuntu Lucid)
[11:28] <G> persia: ha I see exactly what you mean
[11:29] <G> persia: how is this for an 'oddity' though:
[11:30] <G> RHEL5:  tickcount.difference(20, -10)  returns -31
[11:30] <persia> Do you understand why it does that?  If there's an explanation that makes sense, I think it'd be good to patch it so that 32-bit architectures return 21 and 64-bit architectures return 20.  If there's no explanation, the current patch is hiding bugs.
[11:30] <G> Lucid 64bit returns 4294967265
[11:30] <G> there has to be a bug somewhere, I'm sure of it
[11:30] <persia> -31 is really 4294967264 (uint vs. int)
[11:30] <G> ahhh good point
[11:31] <persia> right.  I get 4294967264 on powerpc too, and apparently chuck got it on armel.
[11:31] <G> let me have a play on OSX
[11:31] <persia> But when I follow the program logic manually, I get -4294967265
[11:31] <G> won't take a minute
[11:31] <persia> (any arch)
[11:32] <persia> Err, 4294967265
[11:32] <lanoxx> james_w, u there?
[11:35] <G> persia: okay, OSX 10.6.4 produces the AMD64 results
[11:36] <persia> And that's 32-bit OS X?
[11:36] <G> yeah, OSX Desktop
[11:36] <G> uname -a shows i386
[11:37]  * G tries something
[11:38] <cjwatson> nigelb: can he get me the specific information I requested?
[11:39] <cjwatson> nigelb: I don't really need more reports without that information - if you look at the bug, I have plenty ;-)  What I need is the specific data that would let me detect the problem.
[11:43] <cjwatson> nigelb: perhaps reinstall grub2 to recreate the problem, with the aid of a live CD?
[11:55] <G> persia: I've got an idea...
[11:56] <G> persia: on a 64bit AMD system.... 'diff' is a 'long int', UINT_MAX is an unsigned_int
[11:56] <persia> And on a 32-bit system?
[11:57] <persia> Python is telling me I'm dealing with longs when I use large numbers like that.
[11:57] <G> hold on, just trying to work out, because in my printf, C didn't complain about using %u for either
[11:57] <G> which is unsigned int for both
[11:57]  * persia is trying to build current tickcount against lucid python, expecting it to fail.
[11:58] <G> even though diff is defined as 'long'
[11:58] <persia> printf does an implicit cast when needed.
[12:00] <G> but yeah, using a calculator w/i GNOME works fine, but as soon as I do it in C it goes haywire
[12:01] <persia> So, in lucid, I get 20, and in maverick I get 21 when executing the test on i386.
[12:01] <persia> For precisely the same tickcount source.
[12:01] <persia> Which makes me think that this is a regression in python, or in gcc.  I'm not sure I like that implication.
[12:02] <G> persia: http://pastebin.com/ijXXZpzJ
[12:02] <G> I'm hazarding a guess at gcc
[12:03] <geser> persia: I can reproduce it on 64-bit in maverick (21 != 20) when I change the "I" to "L" in the test suite (use unsigned long instead of unsigned int)
[12:05] <persia> geser, So, should the testsuite use 'L' and look for 21, or is there a bug in python/gcc somewhere?
[12:05] <geser> so at least the test suite is buggy to use "uint_max" when the C code uses long
[12:05] <G> persia: actually, I'm just using the code after 64-bit everywhere now
[12:05]  * persia is now completely certain the current patch is wrong
[12:06] <G> so with the same code on: Lucid 64, RHEL5u4 i386, OSX i386, I get 20 on Lucid & OSX, and 21 on RHEL
[12:06]  * G tries Maverick
[12:06] <geser> persia: not sure yet, I first tried to reproduce it on 64bit
[12:06] <G> Maverick 64bit produces 20
[12:07] <geser> G: with "I" or "L" in the test suite?
[12:07] <G> geser: http://pastebin.com/6AmrqqFd
[12:07] <G> geser: I'm removing the python factor all together
[12:09] <persia> Within lucid/maverick powerpc/armel, all four produce 21.
[12:09] <G> persia: 32 bit?
[12:09] <persia> Yes.
[12:09] <G> my Lucid/Mav envs are 64bit
[12:09]  * persia doesn't have any ppc64 hardware, and doesn't know of any arm64 hardware
[12:10] <geser> G: long is 64bit while UINT_MAX only 32bit; make old, new, diff an int and you get 21
[12:11] <G> gcc converts long to int on 32bit systems?
[12:12] <geser> hmm, can someone with 32bit check "sizeof(long)"?
[12:12] <G> will do
[12:13] <G> 4
[12:13] <geser> on 64bit you get 8 for sizeof(long)
[12:14] <G> okay, so the problem is then, that what, the numbers are wrapping around causing an extra figure or something?
[12:14] <geser> so using UINT_MAX for checking an wraparound of a long looks wrong
[12:15] <persia> But why would we see *different* behaviour for lucid and maverick for i386?
[12:15] <persia> With lucid, I get 20 on i386.  With maverick, I get 21.
[12:15] <G> persia: with that C code I pastebined?
[12:15] <G> or w/ the python lib?
[12:15] <persia> With maverick tickcount source.
[12:15]  * persia runs the C
[12:18] <persia> Diff = 21, UINT_MAX = 4294967295(maverick-i386)
[12:18] <persia> Diff = 21, UINT_MAX = 4294967295(lucid-i386)
[12:18] <G> thats the code that the python unittest is basically running from what I can see
[12:18] <persia> So yeah, the change is in Python, and it was buggy in Lucid and fixed in Maverick
[12:18] <persia> So now the test suite is wrong
[12:19] <G> persia: well the only difference is the tickcounter includes python.h instead of limits.h
[12:19] <G> errr Python.h
[12:20] <G> persia: so try changing the #include <limits.h> to #include <Python.h>
[12:20] <persia> That's not the issue.  maverick/powerpc and maverick/amd64 both have 4294967295 for UINT_MAX in Python.h
[12:20] <G> and if that doesn't work, change 'diff' to 'PyInt_FromLong(diff)' in the printf
[12:21] <persia> No, I'm convinced that geser has the right solution: the testcase should use 'L' rather than 'I' and look for 21 rather than 20 on all architectures.
[12:22] <geser> and also use ULONG_MAX in the C code for the wrap-around
[12:24] <persia> geser, Do you want to patch it to do that?  I can, but since it's your work, and you have the same incentives as I ... :)
[12:25]  * G has a look
[12:25] <geser> can do
[12:25] <geser> is 21 really the right result for this?
[12:26] <G> geser: I'm just seeing if I agree :)
[12:26] <persia> I don't know, which is why I asked for help.  G's C code seems to imply it ought be.
[12:27] <persia> I'm happy to test-build for all four architectures, given a patch, just to confirm.
[12:28] <geser> using G C code and using the same computation like the python code for old and new I get also 21
[12:29] <G> yeah, I'm confident that changing all references from int to long gets 21
[12:29] <G> going from python to C etc
[12:29] <geser> I guess 21 is the correct result as ULONG_MAX is odd
[12:30] <geser> so ULONG_MAX/2 gets round down to the next integer
[12:30] <geser> which results then to the extra "1" when subtracting later ULONG_MAX from that value
[12:31] <nigelb> cjwatson: I can try asking him, but I'm not sure if he'll agree.  I'll look at the bug report again to see what you want and try to get it.
[12:31] <G> http://pastebin.com/JTSkfiem
[12:31] <G> geser: with that I get consistency between 32bit & 64bit
[12:32] <G> of course, changing the values for old & new on 32bit to what python says they should be :)
[12:33] <G> persia: a nice little brain workout none the less :)
[12:35] <persia> geser, Shouldn't ULONG_MAX *always* be odd?  We start counting at 0 after all.
[12:36] <persia> But lifeless put 20 originally for some reason, which I'm not sure I understand.
[12:36] <geser> persia: yes, it's 2^32-1
[12:36] <geser> or 2^64-1
[12:36] <geser> with the 0 you get 2^32 or 2^64 numbers
[12:36] <persia> Well, 2^n-1 is always odd, so 21 feels right.  Doesn't explain why lifeless put 20.
[12:37] <persia> Unless there was some other bug that got fixed, and he just put the value he was getting.
[12:38] <cjwatson> nigelb: it's all on my blog
[12:38] <G> I guess that issue can be fixed once & for all now :)
[12:38] <cjwatson> nigelb: though comment 4 on the bug is pretty much the same
[12:39] <nigelb> cjwatson: heh, my ping was in response to your blog post.  You apparently dont have a comment system :p
[12:40] <G> nigelb: with the amount of spam comments these days I don't blame people who don't have comment systems :)
[12:43] <nigelb> G: well, comments can be moderated :)
[12:43] <G> true I guess
[12:43] <geser> persia: http://paste.ubuntu.com/484917/
[12:44] <geser> I didn't check if the comment in the test suite is still true
[12:44] <G> geser: looks right to me
[12:46] <persia> So we're changing all the ints to longs.  This is fairly normal 64-bit porting.
[12:47] <persia> On the other hand, why does it work with long and not int?
[12:47]  * persia still thinks there's a bug somewhere)
[12:47] <persia> Are we wrapping something unexpectedly?
[12:47] <G> persia: I'd say so yeah
[12:47] <persia> Are we converting to the wrong types somewhere?
[12:49] <geser> persia: the problems seems to be that the code uses long (32bit vs 64bit) while the test case is always done with 32bit
[12:49] <persia> The usual reason to use long rather than int in 64-bit porting is some sort of implicit pointer case.
[12:49] <persia> s/case/cast/
[12:49] <geser> on 32bit archs you the get overflow -> 21 while on 64bit you don't get one -> 20
[12:49] <persia> Aha!
[12:50] <persia> Because of differences between Python and C type definitions?
[12:50] <persia> No just confusion.  Right.  Testing the patch.
[12:50] <persia> This replaces zul&ttx7s patch, right?
[12:50] <geser> yes, that replaces the existing patch
[12:51] <geser> persia: the problem was the the constants used (UINT_MAX) didn't match the data types used (long)
[12:52] <geser> it worked on 32bit because sizeof(int)==sizeof(long) but that's not true on 64bit
[12:53] <persia> Right.  I think that's a good place for the bug then :)
[12:53] <cjwatson> nigelb: yes, it's pretty much deliberate
[12:53] <cjwatson> persia: you mentioned that printf does an implicit cast - you know that isn't necessarily so, right?
[12:54] <cjwatson> varargs -> weird
[12:54] <cjwatson> haven't looked at the code
[12:54] <persia> cjwatson, It isn't?  I thought that when you used one type in a format specifier and another as an argument, it tried to cast.
[12:54]  * persia is glad to be disabused
[12:54] <cjwatson> I'd be surprised
[12:55] <cjwatson> gcc warns if there's a mismatch
[12:56] <cjwatson> you could easily be ending up with the first half of a long or something
[12:56] <persia> And it just happens to appear to work for small numbers.  This makes a lot more sense.
[13:05] <persia> geser, Builds successfully (including test run) for i386/amd64/armel/powerpc : go for it.
[13:27] <bilalakhtar> Will bug #619678 need UIFe ?
[13:30] <geser> persia: do you have a sponsor at hand for it?
[13:31] <persia> Nope.  It was just bothering me.
[13:32] <geser> ok, I'll put it into the sponsoring queue and look for a sponsor after the beta freeze gets lifted
[13:32] <persia> Might get found randomly by then :)
[13:33]  * persia has had surprisingly good luck with main sponsorships lately
[13:35] <persia> I can't figure out gawk/amd64 or gcj-4.4/amd64.  likewise-open/powerpc seems to be intentional by upstream.  openjdk-6/armel and openoffice,org/armel are claimed, debian-installer waits on archive recovery, libvirt/powerpc runs into some limitations with how poorly powerpc supports emulation (as a host), and the rest are either depwaits or have bugs awaiting sponsors.
[13:37] <G> persia: whats this you are refering to?
[13:37] <G> (you got my attention at libvirt) :P
[13:38] <persia> http://qa.ubuntuwire.com/ftbfs/ for main.
[13:39] <persia> But the libvirt one needs someone with a powerpc, and I *think* it really needs work on qemu-kvm, so perhaps not your cup of tea :)
[13:39] <persia> That said, there's heaps of stuff in universe (which I was saving for tomorrow).  Please feel free to beat me to it :)
[13:40]  * persia mostly focuses on armel/powerpc stuff anyway, figuring lots of folks have i386/amd64 HW
[13:40]  * bilalakhtar would like to know if the people over here like repeated questions and if they don't mind, then he would repeat his question
[13:41] <G> persia: the libvirt test that fails has been disabled in Fedora since 0.8.2
[13:41] <persia> bilalakhtar, Generally repeated questions are best if one waits 6-30 hours between : I suspect nobody here is able/prepared to answer that.
[13:42] <bilalakhtar> okay, so my question was difficult :(
[13:42] <G> persia: check out line #692 http://cvs.fedoraproject.org/viewvc//rpms/libvirt/devel/libvirt.spec?view=markup
[13:43] <persia> G, Works for other arches.  qemu-kvm support for powerpc in Ubuntu was deliberately trimmed by me to get it to build for lucid: as much as anything else, this is a reminder that I should check the status, and maybe build a bit more on powerpc.
[13:43] <persia> Worst case, yeah, I'll comment out the test, but as seen with tickcount, I generally don't like to do that sort of thing, if changing the code makes the test work.
[13:43] <G> persia: it's nothing to do w/ kvm support though
[13:44] <G> libvirt is independant of all virt types
[13:44] <persia> So if there exists no virt type that can be a host on the system, that doesn't limit libvirt's tests?
[13:44] <G> 0.8.x added some network filtering features, look like either the feature or the test is plain broken
[13:44] <persia> Well, it's arch skew, so needs investigation.  Thanks a lot for the hint, but I'm still going to try to figure out why powerpc is different.
[13:45] <geser> persia: bug 625798 if you want to follow it
[13:45] <persia> (but not now: time for food)
[13:45]  * G has a look at the test upstream
[13:45] <persia> heh.  Good bug title.
[13:48] <geser> persia: if you also look at FTBFS in universe: ldc needs an update 0.9.2+hg1650 to fix the FTBFS as we have only llvm 2.7 in the archive and this support for llvm 2.7 got fixed upstream in that revision
[13:53] <G> persia: I'd take a look at it, but I lack powerpc access but it looks like the XML that libvirt is producing isn't quite what it expects
[14:23] <cjwatson> persia: what may have been confusing you is the rather arcane bit of the C standard regarding default argument promotions
[14:24] <cjwatson> persia: lacking a prototype, function arguments are promoted to int or double as appropriate, using the integer promotion rules
[14:24] <cjwatson> (int> modulo signedness)
[14:25] <cjwatson> persia: the effect of this is that you can get away with passing char to %d, for instance, but it doesn't work with long types when sizeof(long) > sizeof(int)
[14:28] <persia> cjwatson, Thanks.  That makes lots of sense.
[14:29] <cjwatson> thank goodness for gcc warning me about this kind of thing, otherwise I'd never remember ...
[14:29] <persia> geser, universe is next (as I'm running out of main).  I'll start with ldc tomorrow if someone else doesn't get to it first.
[14:30] <cjwatson> if somebody wants to take the freej FTBFS, I would greatly appreciate itb
[14:30] <cjwatson> *it
[14:32] <persia> That'd probably benefit from the attention of the mozillateam
[14:33] <cjwatson> mm
[14:38]  * G looks at some universe FTBFS
[15:50] <lanoxx> james_w, are you there?
[17:07] <vish> i'v tried looking for the lp bug about the Maverick iso not booting in virtual box... but i cant find one :(
[17:07] <vish> does anyone know the bug# ?
[17:07]  * vish asks here because there was chat about the issue being known..
[17:33] <sbeattie> vish: hrm, which iso? I managed to boot maverick livecds (i386 and amd64) just yesterday.
[17:33] <vish> i'v been trying to use testdrive and the desktop iso does not boot and i cannot install either.
[17:34] <vish> this has been for over a week ..
[17:34] <sbeattie> vish: hrm, I've not used testdrive, but I think it defaulted to kvm, though could use virtualbox.
[17:35] <vish> yeah , it seems to default to kvm when we dont have VB , but uses VB if its there..
[17:37] <vish> does not boot in the sense , it just loads and then hangs later on , either hangs with the wallpaper "Try Ubuntu"  or when i try to install the installer just crashes and again hangs
[17:38]  * vish tries to read logs again..
[17:39] <vish> http://irclogs.ubuntu.com/2010/08/26/%23ubuntu-devel.html#t20:24
[17:40] <vish> hmm , so its the installer!
[17:41] <cjwatson> vish: I thought I'd fixed that by removing bootchart from the CD
[17:41] <vish> cjwatson: tried today too , doesnt help .. still just hangs with the wallpaper
[17:41] <sbeattie> vish: but also seems to be a discussion about kvm, not virtualbox
[17:42] <cjwatson> you could try giving it more memory
[17:42] <vish> sbeattie: yeah , but it looks like the CD fault than the kvm/VB , [well seemed the same, since i seem the have that prob :D]
[17:43]  * vish adds memory
[17:52] <vish> more memory seems to do the trick.. alteast able to get to the installer now .. :)
[17:52]  * vish fingers crossed
[18:19] <vish> cjwatson: yup! more memory and i could install/boot! thanks. :)
[18:48] <james_w> lanoxx: am now
[18:49] <lanoxx> james_w, ah hi, did you get my patches?
[18:50] <james_w> lanoxx: to what?
[18:50] <lanoxx> tilda
[18:51] <james_w> I don't think so, and that's not a project that I know
[18:51] <james_w> lanoxx: did you send them directly to me?
[18:51] <lanoxx> jup, yesterday
[18:52] <lanoxx> james_w, to @ubuntu.com
[18:53] <james_w> lanoxx: why did you send them to me?
[18:53] <lanoxx> you are registered in launchpad as maintainer for tilda
[18:53] <lanoxx> i wasnt sure to whom else to send it
[18:54] <james_w> lanoxx: https://edge.launchpad.net/tilda <- that project?
[18:55] <lanoxx> https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/tilda/maverick
[18:55] <james_w> right, I created the branch, but I created all of them, so I have no specific links to that project
[18:56] <lanoxx> james_w, ah ok, well then i will send them to ira instead :)
[18:56] <james_w> lanoxx: please do
[18:56] <james_w> lanoxx: you can submit a merge proposal for Ubuntu as well if they are bugfixes.
[18:57] <lanoxx> well the patches move the config files from ~/.tilda to the XDG_CONFIG_HOME, is that considered a fix?
[18:58] <lanoxx> its just about 20 to 30 lines of code
[18:58] <james_w> not particularly
[18:58] <lanoxx> how about maverick?
[18:59] <james_w> maverick is in feature freeze
[18:59] <james_w> you would have to ask someone on the release team whether that required a freeze exception or not
[19:02] <lanoxx> ok, i will do that, after they got accepted in upstream
[22:09] <mr_pouit> pitti: fyi, the randr 1.2 branch of xfce4-settings has just been merged in master