[01:43] Should Intrepid firefox bugs go in firefox or firefox-3.0? [02:04] I am going to assume firefox-3.0 since that is what apport chooses. === brian_ is now known as BrianFreytag === txwikinger2 is now known as txwikinger [06:46] good morning [06:47] dholbach: good morning [06:47] hiya maco [07:18] good morning [07:21] morning thekorn [07:26] hi highvoltage === BrianFreytag_ is now known as BrianFreytag === brian_ is now known as BrianFreytag [09:37] I'm running intrepid at the moment. If I downgrade to a older kernel lets say hardy will I get huge issues? [09:37] I don't know anything else I can do :( I'm out of Ideas. Noone seems to care about my bugreports and I don't want to downgrade to hardy :( [09:43] elmargol, Some things won't work. I've no idea which. You could try it, but be prepared for pain. [09:44] pain is if your system has a hard crash 5-6x / day [09:45] do you have bug number? [09:46] bug #278029 [09:46] Launchpad bug 278029 in nvidia-graphics-drivers-177 "Xserver crashes, scrambled terminals random lines and patterns (dup-of: 270617)" [Undecided,New] https://launchpad.net/bugs/278029 [09:46] Launchpad bug 270617 in nvidia-graphics-drivers-177 "Display corruption after short period" [Undecided,Confirmed] https://launchpad.net/bugs/270617 [09:50] elmargol, Is it just nvidia, or nv also? [09:51] persia: just nvidia [09:51] elmargol, Hrm. I don't have any useful suggestions. I use "vesa" on one of my computers, but I'm not sure that meets your needs. [09:52] Does it work better with one of the other versions? e,g, 173? [09:52] persia: no same problem [09:53] the most anoying thing is that i don't get any error messages [09:53] maybe I have to somehow increase the logging verbosity [09:54] elmargol, Hrm. You could complain to nvidia, but I'm not sure how much it would be fixed in intrepid. I remember a similar issue with the nvidia drivers for edgy, which didn't seem to get sorted until mid-way through feisty for me (although that was "mouse moves, X has crashed", so a different specific bug) [09:54] persia: I guess I'm just not going to buy nvidia in the future [09:55] Last year 3 nvidia gpus died in my other machine [09:55] this laptop gpu is a replacement too [10:29] wow if i use the nvidia driver from nvidia kde4 is totally broken :D [10:30] I guess you patched a lot in order to get it working inside intrepid? [10:38] I didn't personally touch it. I believe it can't be patched directly, but it lives in a wrapper which has seen extensive work. [10:40] kde4 and the vanilla 177.80 is totally broken === asac_ is now known as asac [12:07] * Treenaks wonders what could have caused bug 281825 [12:07] Launchpad bug 281825 in gzip "gzip, gunzip and zgrep manpages are missing" [Undecided,Confirmed] https://launchpad.net/bugs/281825 [12:08] there's nothing in the changelog.. [12:35] build mistake? [12:38] hggdh: hey [12:38] hggdh: do you run evolution svn? [12:53] where's seb128? [12:53] hey hggdh [12:54] hi seb128 [12:54] you vanished for a moment [12:54] hggdh: just wondering if you were running the gnome-2-24 svn [12:54] hggdh: right, restart to try some updates [12:54] I am running 2.25, but I can checkout 2.24-svn if you need [12:54] hggdh: I'm pondering uploading svn snapshots to intrepid to do the soname change earlier and test gnome-2-24 before the 2.24.1 tarballs [12:55] hggdh: don't bother, that was in case you had some opinion on current gnome-2-24 [12:55] seb128, yes, I do have opinions ;-) [12:55] I get some cores every so often, but I have not been able to zero in the issue. Usually at startup [12:56] if the svn snapshots have corrected some of the issues on 2.24, I am all for it [13:04] hggdh: that's rather than intrepid will have 2.24.1 so better to get the svn tested early so issue can be fixed for 2.24.1 rather than waiting for the tarball to notice bugs which will not be fixed before intrepid [13:05] seb128, I will checkout 2.24-svn & build & run from there [13:06] seb128, svn is good enough, or should I fix on a revision? [13:06] hggdh: current gnome-2-24 svn [13:06] seb128, OK, will do [13:15] huh, seb128, what is the tag for 2.24 svn? [13:16] gnome-2-24? [13:16] hggdh: right [13:17] merci beaucoup [13:17] de rien ;-) [13:21] Could I ask a general question, related to an interaction on bug #96148 please? It's a proven bug with the version of KOrganizer that currently is available in Gutsy. There have been a couple of comments regarding KDE4, which Gutsy doesn't come with. I made a reference to this and got kinda slammed for it. Is this a valid resolution for a gustsy bug? [13:21] Launchpad bug 96148 in kdepim "KOrganizer Doesn't Respect The Time Zone Of Imported Calendars/Events" [Undecided,Incomplete] https://launchpad.net/bugs/96148 [13:21] Did that even make sense? :) [13:23] ropetin, looking at it [13:23] Thanks hggdh [13:26] hello [13:26] ropetin, the reply is really rude [13:27] Mine or theirs? :) I put the rudeness down to to not being a native English speaker (or a jack-ass in general), I was more concerned with the contents. I.e. should whether something works with KDE4 be or any relevence to a bug in a KDE 3.x package? [13:28] of any relevance I meant [13:28] ropetin, I do not see yours being rude [13:28] Thanks [13:28] ropetin, I am logging off now (got to earn some money), so I suggest you take it over with bdmurray or ogasawara_ please wait a bit for them to come in (very early, in TZ) [13:29] Thanks for the advice hggdh [13:29] ropetin, kde4 is not usually compatible with kde3 [13:29] I agree :) [13:31] ropetin: FYI, upstream won't do much more fixing of kde3. [13:32] ropetin: so, repeatedly saying that it does still exist in gutsy, where it's never going to get fixed anyway, is kinda pointless. [13:33] and, justifiably enough, he wants to know if it occurs in kde4, so he can report it upstream for htat if it does. [13:33] ropetin: what you're doing there is shooting the messenger, and someone's reacting. [13:33] ropetin: kubuntu can't do anything much if kde upstream decide not to do more fixes for KDE3. [13:33] Hobbsee: are all fixes generated upstream or do sometimes nice, smart programming types from the Ubuntu community submit them? [13:33] Even if it's a KDE3-only bug, and it's important enough that someone upstream decides to fix it, that's more likely to happen for 8.04.2 or 8.04.3 than for gutsy. [13:34] ropetin: occasionally they do. I can probably count those people on one hand, who have committed fixes to kdepim on kubuntu, who weren't kde people. [13:34] So basically, and I"m not trying to be an ass, really, honest, the EOL of an Ubuntu version doesn't really count for much? [13:34] !sru [13:34] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [13:35] it counts for the stuff at ^ [13:35] but kubuntu has a manpower problem on top of that, there's no valid patch, and kdepim is a pain to work in. === _jason is now known as jrib [13:36] OK, points taken. I will consider that when submitting bugs in the future. ALso I'll try and learn some programming fu so I can help out a bit! [13:37] * ropetin searches for a C++ book [13:37] on some level, if upstream isn't willing to help, then you're stuffed - as they know the code base much better than anyone else. [13:38] also, kubuntu tends to focus on the next release, so as many bugs get solved there as possible, which is where the majority of the users are [13:38] It's not just Kubuntu that has a manpower problem either. The concept of 18/36/60 months of support is mostly that if someone happens to have the time and energy to fix it, it's possible to fix, rather than that it certainly will get fixed. [13:38] So in a case like that I'd be better to submit the bug upstream? Although in this case it's a moot point, someone already had [13:39] ropetin: that'd be a good try, but i doubt anyone will want to fix ti anyway [13:39] (unfortunately) [13:39] :D OK [13:39] ropetin, It never hurts to have the bug in both places, as long as you remember that it's really a matter of hoping someone feels like fixing it, rather than that someone necessarily will respond to every bug report. [13:39] True true [13:39] (that applies both to Ubuntu and upstream) === mdz_ is now known as mdz [14:01] Hello, is there any info that I should add to bug 281451 ? [14:01] Launchpad bug 281451 in linux "uvesafb does not support 1280x800 resolution for NVIDIA graphics adapters" [Undecided,New] https://launchpad.net/bugs/281451 [14:07] hey there === LucidFox_ is now known as LucidFox [14:34] ? [14:35] AnAnt: maybe ask in #ubuntu-kernel ? [14:35] no one answered there === Fallenou[oqp] is now known as Fallenou [15:45] bdmurray: hiya - can you check if https://lists.ubuntu.com/archives/ubuntu-devel/2008-October/026683.html would make sense to you? [15:56] dholbach, You probably also want to discuss with seb128, who has successfully argued against previous attempts to use a tag as part of helping manage patches. [15:57] persia: did I? [15:57] seb128, At least the last two times I raised the issue to the bugsquad. [15:58] You suggested that we should get the LP devs to fix the patch flag to be meaningful. It's hard to disagree with that :) [15:58] are you sure? I'm a bit surprise, at least I'm not against the idea but I was perhaps again the way suggested [15:58] Probably in part the way it was suggested, and perhaps in part because at least once I just did it for about 300 patches, and you got a *lot* of bugmail from me. [15:59] persia: the problem I'm trying to solve is: there's no patch status in LP, so how do we get from 2006 patches in LP to 0 - I think it'd help to be able to say "this patch A needs attention from a sponsor", "we know a lot about this patch B, but it needs work" and "nobody ever looked at patch C" [15:59] If you're not opposed to the idea, then that's good news, but I wanted to make sure, based on history :) [15:59] oh, discussing an idea and spamming me before discussing the idea are different things ;-) [15:59] without having to guess what the bug status is supposed to mean in whatever context [15:59] dholbach, I understand. That's the reason the "bugs with patches" list appears on qa.ubuntuwire.com [15:59] but yeah I tend to complain when I have 300 bugs mails when opening my mail client [15:59] persia: it appears on harvest as well [15:59] seb128, And probably the second time I just reminded you of the first :) [16:00] dholbach, We got it down to about 800 once, with some concerted effort, but part of that involved using tags, and generated a lot of bugmail. [16:00] I'm hugely in favour of such a thing, just wanted to make sure we got seb128's buy-in before we did it :) [16:00] the issue is "what do we call patches" [16:00] I expect that if we get on top of things again, it will be fine [16:01] ie, is your goal to untag all the crap there? [16:01] I triaged a bug which had a screenshot tagged as patch some days ago [16:01] The goal is to 1) untag all the crap, 2) identify stuff that needs a developer to prepare a candidate, and publish the lists so people do it. [16:01] I'm also happy to write up "if you triage a bug with a patch, please make sure that 1), 2), 3), 4) all apply, then use the tag or disable the patch flag of remove the patch altogether" [16:02] dholbach, Sounds good to me. I'd also like to see the use of "triaged patch" for when submitters put a one or two line patch in the description or a comment. [16:02] do we have some statistics on the category of patches we have at the moment? [16:02] seb128: I think it'd help if we had a way for a bug triager to say "I looked at it and to me it seems fine, this is why I use tag 'triaged-patch' for the bug" [16:02] I don't think anyone collected statistics recently. Generally, I'm against the collection, as it's easier to triage them while collecting, but that makes the statistics wrong later (I tried that once). [16:02] seb128: we just know: 1) 2006 bugs with patches, 2) ~70 bugs in the sponsoring queue [16:02] dholbach: if the patch is not correct it should probably just be untagger patch [16:02] that's it [16:03] Right, and a comment added saying why it's not a patch. [16:03] seb128: the thing is: right now all we know is: this patch needs review (sponsoring teams on it) or it has a patch [16:03] I've to admit patch to descriptions tend to sit for ever on the desktop bugs, those are so small details that the change bring trouble rather than help [16:04] if we had the additional information that somebody checked that it is a patch, it has documentation, we know where it comes from and it even applies - that'd be great [16:04] or typo fixes, etc [16:04] seb128: that's a separate problem, but I agree [16:04] well, that's going to get in the way of your "bring the number of pending patches to 0" [16:04] it'd be nice to make "collecting patches from LP if you do an upload anyway" a more common pattern [16:05] that's not the issue [16:05] typo fixes are often not worth a delta over debian or breaking all the translations because the english text had a typo [16:05] so basically that's "yeah that's a typo, the patch is correct but I don't want to apply it" [16:05] and we have no good way to deal with those nowadays [16:06] I agree [16:06] I want typo fixes to go upstream or to debian, not to be ubuntu specific [16:06] the issue is that I don't want to discourage contributors either [16:06] still, I'd like to be able to say "this bug is supposed to have a patch" or "somebody made sure that this is something that applies and we know something about it" or "this needs work" [16:06] so basically I tend to add a comment to the bug and ignore it then [16:07] that should be fine too: goes to sponsoring queue, leaves sponsoring queue again with developer comment [16:07] right, but the bug will be sitting there having a patch [16:07] but hopefully an upstream task after that too [16:07] just raising it as one case we should try to address by some way but I've no good suggestion [16:08] seb128, For most of the typo fixes, etc. wouldn't it be nice to have the procedure say "prepare a clean patch against upstream, and publish in an upstream bug"? [16:08] persia: I tend to do that and submitter don't reply half of the time [16:08] anyway... if you guys feel like it, it'd be nice if you'd reply to the mail I pointed bdmurray to :) [16:08] which means half of the time they do which is good ;-) [16:09] dholbach: you should have changed the subject, I didn't read it because it's a reply in the middle of a long discussion [16:09] seb128, Right. The submitter is probably not the right person. We want to make lists trivially available to the wider development community to help push the patches around. [16:09] seb128: right... next time :) [16:09] dholbach, What do you think about using "ubuntu-patch" and "upstream-patch" or both instead of "triaged-patch" to help in this situation? [16:10] persia: erm, I'm not sure I understand [16:10] the bit of information I wanted to add was "from a triage perspective the bug is OK, now we need somebody who can judge the code changes" [16:10] dholbach, OK. Some patches are interesting for ubuntu, and should be applied. Some patches are interesting for upstream, and should be applied. These sets are not distinct, nor are they identical. [16:11] if something should go upstream, it should be enough to add an empty upstream task, no? [16:11] It helps identify stuff that needs someone to clean up and push upstream vs. stuff for which it's useful to prepare a debdiff. Sometimes it's both, but not always. [16:11] Adding an upstream task doesn't make a good list for someone who wants to e.g. help the desktop team. [16:12] we put a lot of effort into making use of upstream tasks :) [16:12] It would be *great* if someone would comb through all the patches seb128 rejected as too painful to carry as delta, and pushed them upstream. [16:12] dholbach: well, the thing is that you want all the patches to be reviewed, how do you get those typo fix marked as patch-triaged out of your list of patches that need action? [16:13] what do you generally do with them? [16:13] put them into 'fix committed' and pick them up every once in a while? [16:13] or just flat-out ignore them? [16:15] ignore [16:15] I think that the two issues are generally related, but I think that just getting all the bugs with patches attached from stage 1 (nobody knows) to stage 2 (we know that it applies, we know where it's from and we know it's a patch) is worth on its own already [16:15] as said they often mean breaking translations [16:15] *nod* [16:15] I'd just open an upstream task and unsub the sponsors team with a comment [16:15] dholbach, I agree, but I think it's worth separating phase 2 into the two groups, to provide better direction on what people should do. [16:15] right, I do that basically [16:16] they will still be on your 2006 patches list though [16:16] Having debdiffs with .desktop HIDification changes will just annoy people. [16:16] By having two tags in the basic rules, people processing them know to take one, the other, or both actions to get them handled. [16:16] dholbach: anyway your suggestions are a good first step, I was just discussing what else we could do for some other cases [16:17] seb128: we could mark them 'fix committed' [16:17] seb128: that way we know 'a fix is available' and are more likely to close them [16:18] dholbach: the issue is that I don't want to use the fix in ubuntu [16:18] but that might be a corner case [16:18] I should maybe just unset the patch flag for those [16:18] we could use 'won't fix' [16:19] with a very nice explanation why, that would make sense too [16:19] right [16:19] but I really think it's a corner case [16:19] won't fix makes sense, but it won't get the bugs pushed upstream, which is the behaviour we want. [16:19] right, let's not spend too much time on that now [16:19] and it'd help if people would get involved with "patch triage" [16:19] I disagree it's a corner case : I see *lots* of spelling issues, grammar mistakes, HIDifications, etc. [16:19] persia: the open upstream task is something a few people are looking at already [16:19] s/HID/HIG/ [16:19] dholbach, Yes, that's the issue: a few. [16:20] dholbach: can we search for bugs which have a patch but are not tagger patch-triaged? [16:20] When we have a patch, we should be proactive about telling the many developers that the patch needs to get upstream. [16:20] persia: I don't see that blocking the proposal - people looking at upstream tasks are getting more and more and more [16:20] I think launchpad doesn't allow the negations in searches [16:20] seb128, searching for the absence of a tag doesn't work yet. [16:20] what I though [16:20] seb128: I'd ask bdmurray to add that information to the harvest patch list [16:21] dholbach, OK. As you like. I just don't think it's easy to change later, and would make a difference. No complaints if you haven't the energy to differentiate. [16:21] Could I interrupt to ask that a bug for manual partitioning in Intrepid be triaged? [16:21] Bug 280900, which seems there are now three on this [16:21] Launchpad bug 280900 in ubiquity "Intrepid daily-live won't install from desktop using manual partitioning" [Undecided,New] https://launchpad.net/bugs/280900 [16:21] persia: this is a standard workflow we use [16:21] persia: I'm not sure what you're disagreeing about [16:22] dholbach, What is a "standard workflow" and who is "we"? [16:22] if a bug with all its data needs to go upstream, we add an upstream task [16:22] I'm suggesting that we use two tags to help identify things needing doing, in the expectation that it will result in more stuff getting pushed upstream with clean patches. [16:23] Oh, right. That's irrelevant. [16:23] OK. So there's a bug. It has some number of tasks (upstream, debian, ubuntu, fedora, etc.) [16:23] Someone submits a patch. [16:23] charlie-tca: looking [16:23] thanks [16:23] The patch reviewer might say "Hmm. Good patch. Let's get it applied". That would get the "ubuntu-patch" tag. [16:24] The patch reviewer might say "Hmm. Good patch. Belongs upstream." That would get the "upstream-patch" tag. [16:24] Some bugs would only get one tag, some none, some both. [16:25] Then, people looking at the patch bugs can say "I'm preparing debdiffs today" or "I'm going to chase bugzilla today", and get a good list of patches to meet their intended work for the day. [16:25] dholbach, Does that make sense? [16:27] dholbach, Essentially, it's about creating the structure to not be overwhelmed before the people looking at the upstream tasks get overwhelmed (as the people looking at the patches generally already have) [16:27] persia: in most cases it would be the sponsor saying that [16:27] Why limit it to sponsors? [16:27] I'm not limiting it [16:27] it's my gut feeling [16:28] Only about 1/3 of the developers are potential sponsors. Most of the rest are quite capable of patch review. [16:28] let's say it's a bigger patch I don't feel comfortable just uploading [16:28] then I'd use the upstream thing as well [16:28] In fact, encouraging the other 2/3s to do patch review would be a good way to demonstrate their ability to make good decisions about things. [16:28] Right. [16:29] See, the only part of your proposal with which I disagree is the part about subscribing the sponsors to all the triaged patches. [16:29] I think of the sponsors as just checking to make sure the sponsorees are doing it right. It's not about pulling all the patches. [16:29] we don't need to do it in a mass subscription, but slowly :) [16:29] For that, we should be using *all* the developers. [16:30] See, I disagree. The sponsor teams aren't the right place for that. [16:30] The sponsor teams are small, and there's only a few active members of either (although u-m-s has been getting much better lately) [16:30] sure, if somebody can make a well-educated decision about the patch and isn't a sponsor, that's fine with me [16:31] On the other hand, the number of people who need something to do is *large*, and most of them can review sets, and prepare something. [16:31] dholbach: where can I find your harvest tool to make the url corresponding to a team on launchpad? ;-) [16:31] it'd be nice if you could follow up on the thread with your opinion [16:31] seb128: hang on [16:31] Yeah. It would. [16:32] seb128: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026118.html [16:32] thanks a lot persia [16:32] Anyway, way too late for me, again. Good night. [16:32] I need to hop on a call [16:32] sleep tight [16:33] dholbach: danke [16:34] charlie-tca: come to find out a fix is commited for that bug [16:34] Terrific! thanks very much [16:34] I didn't confirm because I reported it. [16:35] thanks for pointing out the duplicates too! I'll work on merging those [16:36] dholbach: is "mark reviewed" supposed to do something? [16:36] You're welcome. I'm trying [16:36] seb128: yes, it should - in a call now [17:01] charlie-tca: if you want to look for any other duplicates the distinguishing part is the python traceback in your debug log file particularly the last 2 lines [17:11] bdmurray: Thanks, I'll do that === txwikinger is now known as Guest90923 === txwikinger2 is now known as txwikinger [18:44] bdmurray: what should be done with the gnome-icon-theme task for bug 209072? [18:44] Launchpad bug 209072 in gnome-app-install "network tools icon is huge in "add/remove applications"" [Low,Fix released] https://launchpad.net/bugs/209072 [18:50] mrooney: it looks like what mvo did is a workaround - https://launchpad.net/ubuntu/+source/gnome-app-install see 0.5.2.7-0ubuntu1 [18:51] So I think there is still a bug there [18:51] bdmurray: I see, so I can probably confirm it at least? [18:53] mvo: ping [18:59] mrooney: I think the Hardy task can be won't fix I'm not certain whether or not the bug with gnome-icon-theme still exists [18:59] bdmurray: pong [19:01] mvo: we were looking at bug 209072 again, and I believe you worked around an issue with gnome-icon-theme there [19:01] Launchpad bug 209072 in gnome-app-install "network tools icon is huge in "add/remove applications"" [Low,Fix released] https://launchpad.net/bugs/209072 [19:03] bdmurray: I think I added code in g-a-i to deal with huge icons. did the bug reappear? [19:03] mvo: right, you worked around it we were curious if the gnome-icon-theme task was valid [19:05] bdmurray: frankly I don't know, I think it was back in hardy, not sure if the icon changed in the meantime to have a sensible default size [19:06] * pochu waves [19:06] could anybody with access to bug 281146 tell me in which package it is? is it xulrunner? [19:06] Bug 281146 on http://launchpad.net/bugs/281146 is private [19:07] * pochu would like to see it, as he's triaging bug 271807 [19:07] Launchpad bug 271807 in liferea "liferea-bin crashed with SIGSEGV in g_signal_emit_valist()" [Undecided,New] https://launchpad.net/bugs/271807 [19:08] mvo: okay, thanks. If someone was motivated they could create a debdiff and see what code changed to create a test right? [19:08] pochu: I can't see it either. I might be able to check the db for you though [19:09] hi bdmurray :) [19:09] bdmurray: I guess it's in a package in main so we would need a core-dev [19:10] pochu: it could be just the reporter is subscribed [19:11] bdmurray: right [19:11] pochu: just the reporter and apport it looks like [19:11] bdmurray: yeah, or look over the diff in the filelist, I'm not sure its terrible important [19:11] I've let the reporter know I can't access it. Perhaps he will mark it as public or something [19:11] hey mvo! [19:12] mvo: yeah, I don't think so either just wanted to document what we know for someone else [19:21] hey pochu [19:44] bdmurray, pedro_: Thursday is all ready to go, I just need to click send late thrusday night for the e-mail to go out. [19:44] pedro_: thanks for taking care of tomarrow. :) you rock as usual [19:45] Awsoonn: great, thanks pal! [19:45] Awsoonn: no problem, thanks for taking care of the next one ;-) [19:45] * pedro_ hugs Awsoonn [19:46] Awsoonn: Did you look at https://bugs.launchpad.net/ubuntu/+source/cups/+bugs when making the list? === macd_ is now known as macd [20:29] what package should bugs found during the automatic disk check when booting ubuntu go under? [20:31] nellery: what kind of bug? [20:32] bddebian: actually, I'm just wondering [20:32] sorry bdmurray [20:33] probably e2fsprogs depending on the filesystem [20:35] bddebian: ok thanks [20:42] bdmurray: what package would numlock/capslock lights not turning on fit under? [20:43] nellery: You have to press numlock twice to turn it off the first time? [20:43] nellery: and it won't stay off between reboots? [20:43] nellery: (that's my problem..) [20:43] Treenaks: no, my capslock light on my laptop doesnt turn on when I enable it from an external keyboard [20:44] but it did in Hardy, does in Windows, and works from my laptop keyboard [20:47] nellery: I'm really not certain. Have you tried it outside of X? [20:48] bdmurray: no, I'll test that now [20:58] bdmurray: the light does turn on when X is disabled [20:58] sorry, said that in -devel by accident [20:58] nellery: it's likely X related then - that's all I've got though [20:58] bddebian: ok thanks a lot [20:58] xserver-xorg has several num lock related bugs [21:00] nellery: you might also check in #ubuntu-x to see if they have any ideas [21:00] bdmurray: will do === emma_ is now known as emma [21:16] Hi bugsquad, who should I warn regarding bug 269539 ? This is a failure of the 3 way merger and reports are accumulating [21:16] Launchpad bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539 [21:23] jibel: can you elaborate a little on what you've found? [21:24] when the user has modified menu.lst then the kernel upgrade fails if the user selects the 3 way merge. [21:26] The error is caused by ucf at line 993 in update-grub [21:27] jibel: slangasek is pretty familiar with grub I believe [21:28] bdmurray: Thanks, I'll see with him then. [21:45] bug 269083 [21:45] Launchpad bug 269083 in gnome-power-manager "gnome-power-manager crashed with SIGSEGV in g_closure_invoke()" [Medium,Confirmed] https://launchpad.net/bugs/269083 [21:45] * greg-g just getting a link [21:46] greg-g: why do you use the bot for that? I have a firefox keyword search for bugs I could look up [21:48] bdmurray: I wonder gnome-do actually does a similar thing [21:50] greg-g: It does indeed. The launchpad plugin has a 'find bug by bugnumber' action. [21:50] RAOF: just found it, using it from now on, thanks! [21:51] hmm, but it seems that bug might be an issue too [21:55] Ding dong, bug chat. [21:55] paulproteus - how novel. [21:55] gnome-power-mangler compiled by me seg faults. [21:56] I'm reasonably certain my buildenv is sane. [21:56] PMT is referring to the bug I just linked to [21:56] PMT, Awesome. [21:56] Ah, pre-emptive linking. Thanks greg. :) [21:56] And by segfaults, I mean "on attempting to run it, it segfaults immediately." [21:57] NICE! it segfaults in the same place as the bug. [21:57] I can't confirm (I would normally as I run amd64) as my laptop is not in my possession currently [21:57] greg-g, I forgot you were laptopless. [21:58] :) [21:58] Fascinating! It does look like a compiler bug. [21:58] Hang on. [21:58] PMT, I suggested that BTW given what I remember of the argv corruption bug that Venkatesh and I ran into ca. 3y ago. [21:58] (that it may be a compiler bug) [21:59] It seems to be a compiler bug. I'm currently cross-referencing what 4364f7 is, since it's definitely not a valid 64-bit pointer. [22:00] PMT, http://lists.openwall.net/linux-ext4/2008/07/30/18 fwiw [22:00] Try with gcc-4.2 [22:00] I'm trying 4.1. [22:01] Okay. [22:01] I would do 4.2 first since it's what Ted Tso told me to use before. [22:01] I believe it. [22:02] Yeah, I got the exact same string as the bug-reporter using valgrind to watch this. [22:02] Sweet. [22:03] Nope, gcc-4.1 did the same damn thing. [22:03] Gack. [22:03] PMT, But wait [22:03] is it libc that should be recompiled...? [22:03] BTW, welcome to Gentubuntu. [22:03] oh god [22:03] i hope not [22:03] haha [22:03] * paulproteus giggles. [22:04] dammit ubuntu [22:04] i swear to god [22:04] if i end up running -* in my sources.list [22:04] i'll kill you all [22:05] Is "-*" Gentoo speak for "recompile world"? [22:05] -* is gentoo-speak for "so unstable it didn't even go into unstable" [22:05] Hah. [22:05] I'd be rebuilding glib; since it seems that it's glib corrupting the otherwise perfectly fine pointer being sent to it. [22:05] nope, there goes gcc 4.2 too. [22:06] RAOF makes a compelling argument. [22:06] It's even more exciting, RAOF - it's predictably corrupting it, and dropping a constant string in where the pointer belongs! [22:06] PMT, OT: #ext3grep is a good time. [22:06] uh-oh [22:06] are they flaming me in there [22:06] No, honest. [22:07] interesting question [22:08] * PMT throws his core 2 at the process of recompiling libglib [22:08] For if possible, let it be so! [22:09] PMT: Oh, really? That's pretty crazy :) [22:10] RAOF - ? [22:10] the constant string? yeah. [22:10] PMT: Sorry - delayed. The constant string thing. [22:10] even better because the constant string doesn't appear, as far as I can tell, in the original src. [22:10] The string is ":TIME **" according to Jan Evert on the bug. [22:11] But TIME as all-caps doesn't appear in the source anywhere as a string literal. [22:11] Nor does any variant on time appear inside of a toupper call. [22:11] gcc has become self aware. [22:11] OH NOOO [22:12] PMT, I wonder if it appears in libglib... [22:12] [you know, i only typed 1 O, and lag from my wireless added a few. but that's even better.] [22:12] paulproteus - checking that already. [22:12] lol re: NOO [22:12] kind of hard to grep and compile the source at the same time. [22:12] As a string literal, I'm not seeing time. [22:13] it might exist anyway. [22:13] there are toupper calls in glib, though, unlike in g-p-m, so i'm not likely to know. [22:13]