[00:08] 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] Launchpad bug 582199 in alsa-driver (Ubuntu) "No sound on Dell Optiplex 380 (ALC269Q, probably new chip)" [Medium,Fix released] [00:10] indy__, $ update-manager -d #and click to upgrade to 10.10 ;-) [00:10] but that's if you are ready to upgrade now [00:10] you can request it to be considered for lucid SRU [00:10] !SRU [00:10] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [00:12] indy__, use the "Nominate for release" button at the top of the bug [00:12] xnox, it's vital for me (and every other one using DELL OPTIPLEX 380) to have sound in my system :) [00:12] so, thanks, I will nominate it ;) [00:16] you'd think at some point people would stop reinventing how to do simple sound cards === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [01:21] Hi! [01:21] I have some important issue to report. [01:21] But didn't got it done by Apport. [01:22] Language Support does not download new language. [01:22] This is for the maverick alpha-3 latest update. [01:22] Is there some developers here who can try get it fixed? [01:43] Could someone give-back gstreamer0.10/powerpc? https://launchpad.net/ubuntu/+source/gstreamer0.10/0.10.30-1build2/+build/1913366 [01:46] persia: done [01:46] cjwatson, Thank you. [01:49] 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 === steve|m1 is now known as steve|m [03:33] in spd-say the language option is just for the accent change? === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [07:58] Could someone please give-back utouch-gesturetest/powerpc : https://launchpad.net/ubuntu/+source/utouch-gesturetest/1.0.4-0ubuntu1/+build/1917849 [07:58] give-back? [07:58] did someone steal it? [08:00] "give-back" is short for "Re-add the source to the buildd queue". [08:01] 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] 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] 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] maco, Nope. [08:04] persia, given-back [08:04] cody-somerville, Thanks. [08:09] persia: i thought you were core dev... [08:09] Everyone thinks that for some reason. [08:10] But until recently, I had no interest in being core-dev. [08:10] i think we assume if youre on the MC youre a core dev [08:11] Silly assumption. Only folks that actually work on core stuff ought be core-dev. [08:11] other direction... [08:11] more like assumed that only core devs would get elected [08:11] 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] 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] 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] 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] done [08:14] cody-somerville, Thank you. [08:14] * nigelb wonders about the content of the PM [08:14] Something that caused a violation of information hygine. Be careful: it may be contagious! [08:15] heh [08:15] nigelb: female...linux...surprise [08:15] No sexism. [08:15] maco: Sigh. [08:15] !gender [08:15] yes, I can confirm I am a female bot :) [08:16] :) [08:16] Ugh. [08:16] argh! [08:16] moo [08:16] apt? [08:16] heh, quite fun. [08:16] No super cow powers. [08:16] super moo! o/ [08:17] one of my laptops has an apt-get sticker with a cow on it [08:17] one of.... [08:17] nigelb: the ugly one with all the stickesr [08:18] maco: that /isn't/ ugly :) [08:18] Beauty is in the eyes of the beholder. [08:18] the stickered one is stickered to hide the ugly [08:20] 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] persia: you know, with so many of us asuming you're core dev, its probably time to be one.... [08:21] That's kinda why I'm working on main stuff now. [08:21] persia, done [08:21] \o/ [08:22] 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] You're membership meeting would be one that we'd always point out to others :D [08:22] DMB member would still have to come for a meeting and no shortcuts etc. [08:23] There's already examples of that from the MC. [08:23] cody-somerville, Thank you. [08:23] Ah. I'm new. Haven't looked up MC logs. [08:23] s/new/sortof new/ [08:24] new is relative. I'm new in some collections of folks. [08:24] :) === yofel_ is now known as yofel === bilalakhtar_ is now known as bilalakhtar [10:24] Hi [10:25] Hi === apache2logger is now known as apachelogger [10:45] 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] 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] 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] Yep. [11:05] But there seems to be an off-by-one error somehow. [11:06] 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] persia: something certainly doesn't look right [11:12] I'm 99% certain the armel and i386 test hack patch is wrong. [11:13] But strangely, it passed on amd64. [11:13] well on amd64 I get the right result [11:13] yeah [11:13] persia: let me hunt down a 32bit VM :) [11:13] 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] (or rather, why the result would be any different than that for powerpc, which is my reference) [11:14] G, Also, thanks :) [11:16] persia: the only 32bit VM I have is RHEL... but I'll also have a look on my mac (i386) as well [11:16] 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] yeah, thats my plan [11:26] 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] (Of note, Windows 7 Ultimate and Ubuntu Lucid) [11:28] persia: ha I see exactly what you mean [11:29] persia: how is this for an 'oddity' though: [11:30] RHEL5: tickcount.difference(20, -10) returns -31 [11:30] 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] Lucid 64bit returns 4294967265 [11:30] there has to be a bug somewhere, I'm sure of it [11:30] -31 is really 4294967264 (uint vs. int) [11:30] ahhh good point [11:31] right. I get 4294967264 on powerpc too, and apparently chuck got it on armel. [11:31] let me have a play on OSX [11:31] But when I follow the program logic manually, I get -4294967265 [11:31] won't take a minute [11:31] (any arch) [11:32] Err, 4294967265 [11:32] james_w, u there? [11:35] persia: okay, OSX 10.6.4 produces the AMD64 results [11:36] And that's 32-bit OS X? [11:36] yeah, OSX Desktop [11:36] uname -a shows i386 [11:37] * G tries something [11:38] nigelb: can he get me the specific information I requested? [11:39] 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] nigelb: perhaps reinstall grub2 to recreate the problem, with the aid of a live CD? [11:55] persia: I've got an idea... [11:56] persia: on a 64bit AMD system.... 'diff' is a 'long int', UINT_MAX is an unsigned_int [11:56] And on a 32-bit system? [11:57] Python is telling me I'm dealing with longs when I use large numbers like that. [11:57] hold on, just trying to work out, because in my printf, C didn't complain about using %u for either [11:57] which is unsigned int for both [11:57] * persia is trying to build current tickcount against lucid python, expecting it to fail. [11:58] even though diff is defined as 'long' [11:58] printf does an implicit cast when needed. [12:00] but yeah, using a calculator w/i GNOME works fine, but as soon as I do it in C it goes haywire [12:01] So, in lucid, I get 20, and in maverick I get 21 when executing the test on i386. [12:01] For precisely the same tickcount source. [12:01] Which makes me think that this is a regression in python, or in gcc. I'm not sure I like that implication. [12:02] persia: http://pastebin.com/ijXXZpzJ [12:02] I'm hazarding a guess at gcc [12:03] 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] geser, So, should the testsuite use 'L' and look for 21, or is there a bug in python/gcc somewhere? [12:05] so at least the test suite is buggy to use "uint_max" when the C code uses long [12:05] 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] 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] persia: not sure yet, I first tried to reproduce it on 64bit [12:06] Maverick 64bit produces 20 [12:07] G: with "I" or "L" in the test suite? [12:07] geser: http://pastebin.com/6AmrqqFd [12:07] geser: I'm removing the python factor all together [12:09] Within lucid/maverick powerpc/armel, all four produce 21. [12:09] persia: 32 bit? [12:09] Yes. [12:09] 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] G: long is 64bit while UINT_MAX only 32bit; make old, new, diff an int and you get 21 [12:11] gcc converts long to int on 32bit systems? [12:12] hmm, can someone with 32bit check "sizeof(long)"? [12:12] will do [12:13] 4 [12:13] on 64bit you get 8 for sizeof(long) [12:14] okay, so the problem is then, that what, the numbers are wrapping around causing an extra figure or something? [12:14] so using UINT_MAX for checking an wraparound of a long looks wrong [12:15] But why would we see *different* behaviour for lucid and maverick for i386? [12:15] With lucid, I get 20 on i386. With maverick, I get 21. [12:15] persia: with that C code I pastebined? [12:15] or w/ the python lib? [12:15] With maverick tickcount source. [12:15] * persia runs the C [12:18] Diff = 21, UINT_MAX = 4294967295(maverick-i386) [12:18] Diff = 21, UINT_MAX = 4294967295(lucid-i386) [12:18] thats the code that the python unittest is basically running from what I can see [12:18] So yeah, the change is in Python, and it was buggy in Lucid and fixed in Maverick [12:18] So now the test suite is wrong [12:19] persia: well the only difference is the tickcounter includes python.h instead of limits.h [12:19] errr Python.h [12:20] persia: so try changing the #include to #include [12:20] That's not the issue. maverick/powerpc and maverick/amd64 both have 4294967295 for UINT_MAX in Python.h [12:20] and if that doesn't work, change 'diff' to 'PyInt_FromLong(diff)' in the printf [12:21] 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] and also use ULONG_MAX in the C code for the wrap-around [12:24] 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] can do [12:25] is 21 really the right result for this? [12:26] geser: I'm just seeing if I agree :) [12:26] I don't know, which is why I asked for help. G's C code seems to imply it ought be. [12:27] I'm happy to test-build for all four architectures, given a patch, just to confirm. [12:28] using G C code and using the same computation like the python code for old and new I get also 21 [12:29] yeah, I'm confident that changing all references from int to long gets 21 [12:29] going from python to C etc [12:29] I guess 21 is the correct result as ULONG_MAX is odd [12:30] so ULONG_MAX/2 gets round down to the next integer [12:30] which results then to the extra "1" when subtracting later ULONG_MAX from that value [12:31] 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] http://pastebin.com/JTSkfiem [12:31] geser: with that I get consistency between 32bit & 64bit [12:32] of course, changing the values for old & new on 32bit to what python says they should be :) [12:33] persia: a nice little brain workout none the less :) [12:35] geser, Shouldn't ULONG_MAX *always* be odd? We start counting at 0 after all. [12:36] But lifeless put 20 originally for some reason, which I'm not sure I understand. [12:36] persia: yes, it's 2^32-1 [12:36] or 2^64-1 [12:36] with the 0 you get 2^32 or 2^64 numbers [12:36] Well, 2^n-1 is always odd, so 21 feels right. Doesn't explain why lifeless put 20. === dendro-afk is now known as dendrobates [12:37] Unless there was some other bug that got fixed, and he just put the value he was getting. [12:38] nigelb: it's all on my blog [12:38] I guess that issue can be fixed once & for all now :) [12:38] nigelb: though comment 4 on the bug is pretty much the same [12:39] cjwatson: heh, my ping was in response to your blog post. You apparently dont have a comment system :p [12:40] nigelb: with the amount of spam comments these days I don't blame people who don't have comment systems :) [12:43] G: well, comments can be moderated :) [12:43] true I guess [12:43] persia: http://paste.ubuntu.com/484917/ [12:44] I didn't check if the comment in the test suite is still true [12:44] geser: looks right to me [12:46] So we're changing all the ints to longs. This is fairly normal 64-bit porting. [12:47] 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] Are we wrapping something unexpectedly? [12:47] persia: I'd say so yeah [12:47] Are we converting to the wrong types somewhere? [12:49] 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] The usual reason to use long rather than int in 64-bit porting is some sort of implicit pointer case. [12:49] s/case/cast/ [12:49] on 32bit archs you the get overflow -> 21 while on 64bit you don't get one -> 20 [12:49] Aha! [12:50] Because of differences between Python and C type definitions? [12:50] No just confusion. Right. Testing the patch. [12:50] This replaces zul&ttx7s patch, right? [12:50] yes, that replaces the existing patch [12:51] persia: the problem was the the constants used (UINT_MAX) didn't match the data types used (long) [12:52] it worked on 32bit because sizeof(int)==sizeof(long) but that's not true on 64bit [12:53] Right. I think that's a good place for the bug then :) [12:53] nigelb: yes, it's pretty much deliberate [12:53] persia: you mentioned that printf does an implicit cast - you know that isn't necessarily so, right? [12:54] varargs -> weird [12:54] haven't looked at the code [12:54] 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] I'd be surprised [12:55] gcc warns if there's a mismatch [12:56] you could easily be ending up with the first half of a long or something [12:56] And it just happens to appear to work for small numbers. This makes a lot more sense. === dendrobates is now known as dendro-afk [13:05] geser, Builds successfully (including test run) for i386/amd64/armel/powerpc : go for it. === tkamppeter_ is now known as tkamppeter [13:27] Will bug #619678 need UIFe ? [13:27] Launchpad bug 619678 in nautilus (Ubuntu) "removing the sidebar closing button" [Wishlist,Triaged] https://launchpad.net/bugs/619678 [13:30] persia: do you have a sponsor at hand for it? [13:31] Nope. It was just bothering me. [13:32] ok, I'll put it into the sponsoring queue and look for a sponsor after the beta freeze gets lifted [13:32] Might get found randomly by then :) [13:33] * persia has had surprisingly good luck with main sponsorships lately [13:35] 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] persia: whats this you are refering to? [13:37] (you got my attention at libvirt) :P [13:38] http://qa.ubuntuwire.com/ftbfs/ for main. [13:39] 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] 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] persia: the libvirt test that fails has been disabled in Fedora since 0.8.2 [13:41] 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] okay, so my question was difficult :( [13:42] persia: check out line #692 http://cvs.fedoraproject.org/viewvc//rpms/libvirt/devel/libvirt.spec?view=markup [13:43] 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] 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] persia: it's nothing to do w/ kvm support though [13:44] libvirt is independant of all virt types [13:44] So if there exists no virt type that can be a host on the system, that doesn't limit libvirt's tests? [13:44] 0.8.x added some network filtering features, look like either the feature or the test is plain broken [13:44] 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] persia: bug 625798 if you want to follow it [13:45] 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] (but not now: time for food) [13:45] * G has a look at the test upstream [13:45] heh. Good bug title. [13:48] 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] 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] persia: what may have been confusing you is the rather arcane bit of the C standard regarding default argument promotions [14:24] persia: lacking a prototype, function arguments are promoted to int or double as appropriate, using the integer promotion rules [14:24] (int> modulo signedness) [14:25] 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] cjwatson, Thanks. That makes lots of sense. [14:29] thank goodness for gcc warning me about this kind of thing, otherwise I'd never remember ... [14:29] 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] if somebody wants to take the freej FTBFS, I would greatly appreciate itb [14:30] *it [14:32] That'd probably benefit from the attention of the mozillateam [14:33] mm [14:38] * G looks at some universe FTBFS === bjf[afk] is now known as bjf[vacation] === dendro-afk is now known as dendrobates [15:50] james_w, are you there? [17:07] i'v tried looking for the lp bug about the Maverick iso not booting in virtual box... but i cant find one :( [17:07] does anyone know the bug# ? [17:07] * vish asks here because there was chat about the issue being known.. [17:33] vish: hrm, which iso? I managed to boot maverick livecds (i386 and amd64) just yesterday. [17:33] i'v been trying to use testdrive and the desktop iso does not boot and i cannot install either. [17:34] this has been for over a week .. [17:34] vish: hrm, I've not used testdrive, but I think it defaulted to kvm, though could use virtualbox. [17:35] yeah , it seems to default to kvm when we dont have VB , but uses VB if its there.. [17:37] 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] http://irclogs.ubuntu.com/2010/08/26/%23ubuntu-devel.html#t20:24 [17:40] hmm , so its the installer! [17:41] vish: I thought I'd fixed that by removing bootchart from the CD [17:41] cjwatson: tried today too , doesnt help .. still just hangs with the wallpaper [17:41] vish: but also seems to be a discussion about kvm, not virtualbox [17:42] you could try giving it more memory [17:42] 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] more memory seems to do the trick.. alteast able to get to the installer now .. :) [17:52] * vish fingers crossed [18:19] cjwatson: yup! more memory and i could install/boot! thanks. :) [18:48] lanoxx: am now [18:49] james_w, ah hi, did you get my patches? [18:50] lanoxx: to what? [18:50] tilda [18:51] I don't think so, and that's not a project that I know [18:51] lanoxx: did you send them directly to me? [18:51] jup, yesterday [18:52] james_w, to @ubuntu.com [18:53] lanoxx: why did you send them to me? [18:53] you are registered in launchpad as maintainer for tilda [18:53] i wasnt sure to whom else to send it [18:54] lanoxx: https://edge.launchpad.net/tilda <- that project? [18:55] https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/tilda/maverick [18:55] right, I created the branch, but I created all of them, so I have no specific links to that project [18:56] james_w, ah ok, well then i will send them to ira instead :) [18:56] lanoxx: please do [18:56] lanoxx: you can submit a merge proposal for Ubuntu as well if they are bugfixes. [18:57] well the patches move the config files from ~/.tilda to the XDG_CONFIG_HOME, is that considered a fix? [18:58] its just about 20 to 30 lines of code [18:58] not particularly [18:58] how about maverick? [18:59] maverick is in feature freeze [18:59] you would have to ask someone on the release team whether that required a freeze exception or not [19:02] ok, i will do that, after they got accepted in upstream [22:09] pitti: fyi, the randr 1.2 branch of xfce4-settings has just been merged in master