| 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:08 |
|---|---|---|
| ubottu | Launchpad bug 582199 in alsa-driver (Ubuntu) "No sound on Dell Optiplex 380 (ALC269Q, probably new chip)" [Medium,Fix released] | 00:08 |
| 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:10 |
| ubottu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 00:10 |
| 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:12 |
| penguin42 | you'd think at some point people would stop reinventing how to do simple sound cards | 00:16 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| halvors | Hi! | 01:21 |
| halvors | I have some important issue to report. | 01:21 |
| halvors | But didn't got it done by Apport. | 01:21 |
| 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:22 |
| persia | Could someone give-back gstreamer0.10/powerpc? https://launchpad.net/ubuntu/+source/gstreamer0.10/0.10.30-1build2/+build/1913366 | 01:43 |
| cjwatson | persia: done | 01:46 |
| persia | cjwatson, Thank you. | 01:46 |
| 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 | 01:49 |
| === steve|m1 is now known as steve|m | ||
| pranay_09 | in spd-say the language option is just for the accent change? | 03:33 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| 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? | 07:58 |
| persia | "give-back" is short for "Re-add the source to the buildd queue". | 08:00 |
| 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:01 |
| 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:02 |
| maco | you dont have upload rights to it? | 08:03 |
| * 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:04 |
| maco | persia: i thought you were core dev... | 08:09 |
| persia | Everyone thinks that for some reason. | 08:09 |
| 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:10 |
| 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:11 |
| 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:12 | |
| 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:13 |
| 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:14 |
| nigelb | heh | 08:15 |
| maco | nigelb: female...linux...surprise | 08:15 |
| persia | No sexism. | 08:15 |
| nigelb | maco: Sigh. | 08:15 |
| nigelb | !gender | 08:15 |
| ubottu | yes, I can confirm I am a female bot :) | 08:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| persia | Could someone please give-back unity/amd64 : https://launchpad.net/ubuntu/+source/unity/0.2.32-0ubuntu2/+build/1935946 | 08:20 |
| * 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:21 |
| 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:22 |
| 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:23 |
| persia | new is relative. I'm new in some collections of folks. | 08:24 |
| nigelb | :) | 08:24 |
| === yofel_ is now known as yofel | ||
| === bilalakhtar_ is now known as bilalakhtar | ||
| Padhu | Hi | 10:24 |
| Padhu | Hi | 10:25 |
| === apache2logger is now known as apachelogger | ||
| 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:45 |
| 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) | 10:46 |
| G | persia: without looking at the source etc, when you are talking about ticks are you talking about time ticks etc? | 11:04 |
| * 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:05 |
| 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:06 |
| G | persia: something certainly doesn't look right | 11:11 |
| persia | I'm 99% certain the armel and i386 test hack patch is wrong. | 11:12 |
| 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:13 |
| 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:14 |
| 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:16 |
| G | yeah, thats my plan | 11:17 |
| 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:26 |
| G | persia: ha I see exactly what you mean | 11:28 |
| G | persia: how is this for an 'oddity' though: | 11:29 |
| 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:30 |
| 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:31 |
| persia | Err, 4294967265 | 11:32 |
| lanoxx | james_w, u there? | 11:32 |
| G | persia: okay, OSX 10.6.4 produces the AMD64 results | 11:35 |
| persia | And that's 32-bit OS X? | 11:36 |
| G | yeah, OSX Desktop | 11:36 |
| G | uname -a shows i386 | 11:36 |
| * G tries something | 11:37 | |
| cjwatson | nigelb: can he get me the specific information I requested? | 11:38 |
| 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:39 |
| cjwatson | nigelb: perhaps reinstall grub2 to recreate the problem, with the aid of a live CD? | 11:43 |
| G | persia: I've got an idea... | 11:55 |
| 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:56 |
| 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:57 | |
| G | even though diff is defined as 'long' | 11:58 |
| persia | printf does an implicit cast when needed. | 11:58 |
| G | but yeah, using a calculator w/i GNOME works fine, but as soon as I do it in C it goes haywire | 12:00 |
| 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:01 |
| G | persia: http://pastebin.com/ijXXZpzJ | 12:02 |
| G | I'm hazarding a guess at gcc | 12:02 |
| 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:03 |
| 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:05 | |
| 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:06 |
| 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:07 |
| 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:09 | |
| geser | G: long is 64bit while UINT_MAX only 32bit; make old, new, diff an int and you get 21 | 12:10 |
| G | gcc converts long to int on 32bit systems? | 12:11 |
| geser | hmm, can someone with 32bit check "sizeof(long)"? | 12:12 |
| G | will do | 12:12 |
| G | 4 | 12:13 |
| geser | on 64bit you get 8 for sizeof(long) | 12:13 |
| 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:14 |
| 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:15 | |
| 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:18 |
| G | persia: well the only difference is the tickcounter includes python.h instead of limits.h | 12:19 |
| G | errr Python.h | 12:19 |
| 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:20 |
| 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:21 |
| geser | and also use ULONG_MAX in the C code for the wrap-around | 12:22 |
| 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:24 |
| * G has a look | 12:25 | |
| geser | can do | 12:25 |
| geser | is 21 really the right result for this? | 12:25 |
| 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:26 |
| persia | I'm happy to test-build for all four architectures, given a patch, just to confirm. | 12:27 |
| geser | using G C code and using the same computation like the python code for old and new I get also 21 | 12:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| G | of course, changing the values for old & new on 32bit to what python says they should be :) | 12:32 |
| G | persia: a nice little brain workout none the less :) | 12:33 |
| persia | geser, Shouldn't ULONG_MAX *always* be odd? We start counting at 0 after all. | 12:35 |
| 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:36 |
| === dendro-afk is now known as dendrobates | ||
| persia | Unless there was some other bug that got fixed, and he just put the value he was getting. | 12:37 |
| 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:38 |
| nigelb | cjwatson: heh, my ping was in response to your blog post. You apparently dont have a comment system :p | 12:39 |
| G | nigelb: with the amount of spam comments these days I don't blame people who don't have comment systems :) | 12:40 |
| nigelb | G: well, comments can be moderated :) | 12:43 |
| G | true I guess | 12:43 |
| geser | persia: http://paste.ubuntu.com/484917/ | 12:43 |
| geser | I didn't check if the comment in the test suite is still true | 12:44 |
| G | geser: looks right to me | 12:44 |
| persia | So we're changing all the ints to longs. This is fairly normal 64-bit porting. | 12:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| geser | persia: the problem was the the constants used (UINT_MAX) didn't match the data types used (long) | 12:51 |
| geser | it worked on 32bit because sizeof(int)==sizeof(long) but that's not true on 64bit | 12:52 |
| 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:53 |
| 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:54 |
| cjwatson | gcc warns if there's a mismatch | 12:55 |
| 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. | 12:56 |
| === dendrobates is now known as dendro-afk | ||
| persia | geser, Builds successfully (including test run) for i386/amd64/armel/powerpc : go for it. | 13:05 |
| === tkamppeter_ is now known as tkamppeter | ||
| bilalakhtar | Will bug #619678 need UIFe ? | 13:27 |
| ubottu | Launchpad bug 619678 in nautilus (Ubuntu) "removing the sidebar closing button" [Wishlist,Triaged] https://launchpad.net/bugs/619678 | 13:27 |
| geser | persia: do you have a sponsor at hand for it? | 13:30 |
| persia | Nope. It was just bothering me. | 13:31 |
| 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:32 |
| * persia has had surprisingly good luck with main sponsorships lately | 13:33 | |
| 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:35 |
| G | persia: whats this you are refering to? | 13:37 |
| G | (you got my attention at libvirt) :P | 13:37 |
| persia | http://qa.ubuntuwire.com/ftbfs/ for main. | 13:38 |
| 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:39 |
| * 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:40 | |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| geser | persia: bug 625798 if you want to follow it | 13:45 |
| ubottu | Launchpad bug 625798 in tickcount (Ubuntu) "Don't use int constants with a long data type." [Undecided,New] https://launchpad.net/bugs/625798 | 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:45 |
| 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:48 |
| 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 | 13:53 |
| cjwatson | persia: what may have been confusing you is the rather arcane bit of the C standard regarding default argument promotions | 14:23 |
| 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:24 |
| 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:25 |
| persia | cjwatson, Thanks. That makes lots of sense. | 14:28 |
| 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:29 |
| cjwatson | if somebody wants to take the freej FTBFS, I would greatly appreciate itb | 14:30 |
| cjwatson | *it | 14:30 |
| persia | That'd probably benefit from the attention of the mozillateam | 14:32 |
| cjwatson | mm | 14:33 |
| * G looks at some universe FTBFS | 14:38 | |
| === bjf[afk] is now known as bjf[vacation] | ||
| === dendro-afk is now known as dendrobates | ||
| lanoxx | james_w, are you there? | 15:50 |
| 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:07 | |
| 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:33 |
| 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:34 |
| vish | yeah , it seems to default to kvm when we dont have VB , but uses VB if its there.. | 17:35 |
| 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:37 |
| * vish tries to read logs again.. | 17:38 | |
| vish | http://irclogs.ubuntu.com/2010/08/26/%23ubuntu-devel.html#t20:24 | 17:39 |
| vish | hmm , so its the installer! | 17:40 |
| 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:41 |
| 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:42 |
| * vish adds memory | 17:43 | |
| vish | more memory seems to do the trick.. alteast able to get to the installer now .. :) | 17:52 |
| * vish fingers crossed | 17:52 | |
| vish | cjwatson: yup! more memory and i could install/boot! thanks. :) | 18:19 |
| james_w | lanoxx: am now | 18:48 |
| lanoxx | james_w, ah hi, did you get my patches? | 18:49 |
| james_w | lanoxx: to what? | 18:50 |
| lanoxx | tilda | 18:50 |
| 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:51 |
| lanoxx | james_w, to @ubuntu.com | 18:52 |
| 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:53 |
| james_w | lanoxx: https://edge.launchpad.net/tilda <- that project? | 18:54 |
| 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:55 |
| 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:56 |
| lanoxx | well the patches move the config files from ~/.tilda to the XDG_CONFIG_HOME, is that considered a fix? | 18:57 |
| lanoxx | its just about 20 to 30 lines of code | 18:58 |
| james_w | not particularly | 18:58 |
| lanoxx | how about maverick? | 18:58 |
| 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 | 18:59 |
| lanoxx | ok, i will do that, after they got accepted in upstream | 19:02 |
| mr_pouit | pitti: fyi, the randr 1.2 branch of xfce4-settings has just been merged in master | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!