| tec | hi | 00:37 |
|---|---|---|
| tec | is there any way to get a sierra wireless mc8755 wwan hsdpa modem working under 10.4 ? | 00:38 |
| tec | i found this, and cant belive it: **Note: Ubuntu 9.10 distribution is not supported with Sierra Wireless modems. Ubuntu 9.04 distribution is still supported with all Sierra Wireless modems listed in this KB article. | 00:39 |
| tec | We expect the issue to be fixed in Ubuntu 10.4. | 00:39 |
| duanedesign | tec: can you see which chipset that is. In a Terminal run: lspci | grep Network | 00:55 |
| hggdh | tec: also please tell us where you found this note | 00:55 |
| duanedesign | hello hggdh, i thought i was in a different channel, but as soon as i saw you I knew which channel i was in :) | 00:56 |
| hggdh | duanedesign: heh. I am not sure this is good or bad ;-) | 00:57 |
| nigelb | hey hggdh | 02:13 |
| nigelb | hggdh: there is one trouble with the hook we wrote. | 02:13 |
| hggdh | nigelb: what gives? | 02:23 |
| nigelb | hggdh: the aplay thing uses a question.wav file | 02:24 |
| nigelb | which is not included in default install | 02:24 |
| nigelb | now I'm wondering whether we can include a small audio test file | 02:24 |
| hggdh | which package carries this .wav? | 02:25 |
| hggdh | qnome-audio (answering myself) | 02:26 |
| hggdh | so, if gnome-audio is part of the standard desktop install, no problem. Otherwise, we will have to discuss this with Seb | 02:27 |
| nigelb | it is not part | 02:27 |
| nigelb | (the file is not there in my system either) | 02:27 |
| hggdh | then we have to discuss it | 02:28 |
| hggdh | ot change the wav | 02:28 |
| hggdh | for example, is there a sound file from rhythmbox we can use? | 02:28 |
| persia | example-content is part of the standard install | 02:30 |
| persia | But many users remove it, so it may be only of some use. | 02:30 |
| hggdh | nigelb: ^^^see persia's comment | 02:30 |
| persia | speech-dispatcher also has some test .wav files, which are very likely to be available. | 02:32 |
| hggdh | oh, anyway nigel quit... we will wait (and I will spend some time with my S.O.) | 02:33 |
| persia | Always important to have balance :) | 02:38 |
| hggdh | indeed | 02:51 |
| malev | hi, is anybody there? I can't understand this bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/523039 | 03:22 |
| ubot4 | Launchpad bug 523039 in nautilus (Ubuntu) "[113061.168817] BUG: soft lockup - CPU#0 stuck for 5890s! [lsb_release:27063] (affects: 1)" [Undecided,New] | 03:22 |
| malev | it looks as been generated by a machine | 03:22 |
| persia | malev: It was machine-generated, but then the reporter added more machine-generated stuff as the "description". | 03:28 |
| malev | persia, but hi is not explaining anything about the bug... what can I do to try to reproduce it? | 03:28 |
| persia | malev: I don't think you can reproduce it with the information available. I don't believe it to be a nautilus bug, because the information attached (ProcMaps, ProcStatus) does not appear to show anything wrong with nautilus. | 03:31 |
| persia | I suspect the reporter believes it to be a kernel bug, but they would do better with `ubuntu-bug linux` for that. | 03:32 |
| persia | But it may also be exposing some apport bug: depending on how it was filed. | 03:32 |
| malev | persia, so, can I change it to ubuntu-bug linux ? | 03:32 |
| persia | Do you have access to the reporter's machine, at the time the error is exposed? | 03:33 |
| malev | persia, no, I don't. but... I mean, how can I change the package that it points at (I don't know if it's clear what I'm saying) | 03:34 |
| persia | If so, invalidate the bug, and file a new one. If not, I'd recommend invalidating the bug, and asking the reporter to file a new one with `ubuntu-bug linux` | 03:34 |
| persia | I don't think there's any benefit to that. There aren't enough kernel-related logs to understand the bug anyway. | 03:34 |
| persia | And if the machine in question has been rebooted (likely), it may be impossible to collect them. | 03:35 |
| persia | The bug happened at 113061.168817, which is about 30 hours of uptime. | 03:35 |
| persia | But the logs only go through about 2 minutes. | 03:35 |
| persia | Err, 3 | 03:35 |
| * persia fails at math | 03:35 | |
| malev | guau! it's a lot of information. I'm gonna recommend him to open a new bug. .. | 03:37 |
| persia | malev: Just make extra clear that a kernel bug needs to be reported against "linux", or apport won't be able to collect the right information. | 03:39 |
| persia | Having a CPU lock up for about 2 hours is unpleasant, but that alone doesn't tell us what happened. | 03:40 |
| malev | I'm gonna show you a pastie of my answer, and you help me with it, please | 03:40 |
| malev | persia, http://pastie.org/private/fesheyubcv6vfq1yedniaa | 03:42 |
| malev | the thing is that I'm not sure what are yout talking about :D | 03:43 |
| persia | That's very clear :) | 03:43 |
| persia | So, do you understand anything about this bug? | 03:43 |
| malev | I think. I don't undestand: "Just make extra clear that a kernel bug needs to be reported against "linux", or apport won't be able to collect the right information." | 03:44 |
| malev | maybe it's my english :S | 03:44 |
| persia | I think there may be some other confusions, and it could as well be my explanations. | 03:44 |
| malev | so, do you agree with my answer to the reporter? | 03:45 |
| persia | So, if it works for you, I'll walk through what we can see from the bug, and how I came to my conclusions. I'll also walk through bug reporting, and why I think the reporter should do something specific. | 03:45 |
| persia | The current response doesn't make any sense to me, as phrased. | 03:45 |
| malev | oks! | 03:46 |
| persia | So, the bug title looks like a kernel output line to me. | 03:47 |
| persia | Try running `dmesg | tail` to see some kernel output lines on your current install. | 03:47 |
| malev | looks like the bug's report | 03:47 |
| persia | Right. | 03:47 |
| persia | So the bug report is probably something from the kernel. | 03:48 |
| persia | Which would be the "linux" package. | 03:48 |
| persia | Next, let's look at the description. | 03:48 |
| persia | The first part is labeled "dmesg.log", and it looks like the beginning of /var/log/dmesg.log on my system (except mine isn't so fast). | 03:48 |
| persia | So I'm guessing the reporter pasted it. | 03:49 |
| malev | yes. I supose so | 03:49 |
| persia | Scrolling down, the next label is lspci-vnvn.log | 03:50 |
| persia | And the output looks like what I get running `lspci -vnvn` | 03:50 |
| malev | other paste? | 03:50 |
| persia | So I'm guessing it's a similar log. | 03:50 |
| persia | I'm just reading the bug report. | 03:50 |
| persia | If you scroll down past the dmesg part, there's another section. | 03:50 |
| malev | uname-a log | 03:51 |
| malev | ? | 03:51 |
| persia | That looks like the output of `uname -a` | 03:51 |
| persia | I'm unsure where version.log comes from, but it looks like a kernel version to me. | 03:52 |
| malev | yes | 03:52 |
| persia | Then we have the standard apport stuff, indicating the bug was filed against nautilus. | 03:52 |
| persia | and then the apport attachments for nautilus. | 03:52 |
| persia | and the content of the attachments doesn't show anything particularly suspicious (although I'll admit to not having a deep understanding of nautilus, so maybe there is something wrong) | 03:53 |
| persia | But they mostly look like other apport attachments: nothing appears especially striking to me. | 03:53 |
| malev | you're right | 03:54 |
| persia | So, based on this, I'm fairly sure the reporter wanted to file a bug about the kernel (because of all the kernel logs, etc.). | 03:54 |
| persia | And I suspect that the "Report a bug" menu item was used in nautilus to report the bug. | 03:54 |
| malev | nice, | 03:55 |
| malev | you're a bug's detective! | 03:55 |
| malev | :D | 03:55 |
| persia | Now, looking at the bug title, we can see that the issue happened 113061.168817 seconds after boot. | 03:55 |
| malev | and that is a long time | 03:55 |
| persia | But the attached kernel log only goes up to 188.141010 seconds after boot | 03:56 |
| persia | It's a bit more than a day: something like 30-35 hours. | 03:56 |
| persia | So we don't have any kernel logs from around the time the problem happened. | 03:56 |
| persia | And we don't have any information about what else was happening on the machine. | 03:56 |
| malev | that is correct. | 03:57 |
| persia | And we don't have any information about the state of the machine at the time of the error (for instance, we don't know if the machine was rebooted after the issue appeared) | 03:57 |
| malev | so the report is a bite unusefull? | 03:57 |
| persia | Entirely :) | 03:57 |
| malev | useless | 03:57 |
| persia | And I'm not sure it can be made useful, because if the machine was rebooted, the kernel would reset, and not express the issue. | 03:57 |
| persia | (well, until the next time the bug was triggered) | 03:58 |
| malev | ... but, it's a pity with all the work and enthusiast that the reported put on it :D | 03:58 |
| persia | Right. | 03:58 |
| persia | So, we know we want to make this bug "Invalid", because it contains no useful information, but we also want to tell the submitter how to give us useful information next time. | 03:58 |
| malev | ... great idea! | 03:59 |
| malev | i'm gonna think of a new speach | 03:59 |
| persia | We also know that when we adjust the status, we'll want to adjust the source package to be "linux", because it's a kernel bug. | 03:59 |
| malev | or answer | 03:59 |
| malev | oks. | 04:00 |
| persia | I thought I remembered there being a wiki page about dealing with kernel bugs, but I can't find it :( | 04:00 |
| persia | Ideally, we'd want to find the page, and suggest whatever best practices the kernel team has documented on how to get a good bug report. | 04:00 |
| malev | there might be and "common responses" in the wiki | 04:01 |
| persia | Right. | 04:01 |
| persia | So, look around in the wiki. See if you can find the kernel stuff. | 04:01 |
| persia | IF you can't, you can maybe invent a response. | 04:01 |
| malev | persia, oks! | 04:02 |
| persia | I believe the best way to report a bug about the kernel is to use the ubuntu-bug program, and tell it to report against "linux", but I'm not 100% sure. | 04:02 |
| malev | I'm going for it | 04:02 |
| persia | malev: And this all makes sense now? | 04:02 |
| malev | hell yeah! | 04:02 |
| malev | thanks! | 04:02 |
| persia | Excellent! | 04:02 |
| persia | No problem. I'm always happy to share *how* to triage a bug, as I think our most common failure as a team is when we aren't sure. | 04:03 |
| persia | And if we all work together (in this channel), we can all become experts at understanding various bugs (I knew how to read this one, but there are some for which I have to ask as well) | 04:03 |
| malev | you are right | 04:07 |
| === kermiac is now known as kermiac_ | ||
| kermiac_ | I'm looking for an upstream report of bug 525128 | 04:28 |
| ubot4 | Launchpad bug 525128 in tzdata (Ubuntu) "Australian timezone incorrectly labelled in date output (affects: 1)" [Undecided,New] https://launchpad.net/bugs/525128 | 04:28 |
| kermiac_ | I think it is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810 | 04:29 |
| ubot4 | Debian bug 93810 in tzdata "Australian zoneinfo wrong - should be AEST, not EST" [Wishlist,Open] | 04:29 |
| kermiac_ | but it may also be bug 149902 | 04:29 |
| ubot4 | Launchpad bug 149902 in opendchub (Ubuntu) "package opendchub 0.7.14-2ubuntu1 failed to install/upgrade: there is no script in the new version of the package - giving up (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/149902 | 04:29 |
| kermiac_ | oops | 04:29 |
| kermiac_ | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149902 | 04:29 |
| ubot4 | Debian bug 149902 in libc6 "date: does not understand some timezones" [Wishlist,Open] | 04:29 |
| kermiac_ | any thoughts? | 04:29 |
| micahg | kermiac_: 1st one is closed won't fix | 04:33 |
| micahg | kermiac_: unless adoption of AEST has grown, it's not likekly to be fixed | 04:33 |
| micahg | kermiac_: so, I would suggest filing a new bug, reference the existing ones and explain why now is different than 7 years ago | 04:34 |
| micahg | if it is | 04:34 |
| micahg | otherwise, no point | 04:34 |
| === nhandler_ is now known as nhandler | ||
| kermiac_ | micahg: being in australia, I have always referred to it as AEST | 04:35 |
| kermiac_ | and the 2nd debian bug had (sort of) recent discussion - well, from a year ago | 04:35 |
| kermiac_ | I don't think it's worth opening another new bug regarding this | 04:35 |
| micahg | second bug last comment is 2006 | 04:36 |
| kermiac_ | should I just mark link the 2nd upstream bug & mark the LP bug wontfix? | 04:36 |
| micahg | kermiac_: no, does everyone now refer to it as AEST in au? | 04:36 |
| kermiac_ | sorry, I mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810 | 04:36 |
| ubot4 | Debian bug 93810 in tzdata "Australian zoneinfo wrong - should be AEST, not EST" [Wishlist,Open] | 04:36 |
| kermiac_ | last comment is from last year | 04:36 |
| kermiac_ | as far as I know, I had never heard of "EST" until I started using ubuntu | 04:37 |
| micahg | kermiac_: http://www.ga.gov.au/bin/gazmap_moonrise | 04:38 |
| kermiac_ | this is getting strange | 04:40 |
| kermiac_ | that link is contradicted by http://www.australia.gov.au/about-australia/our-country/time | 04:40 |
| micahg | kermiac_: well, the debate's been going on for a long time | 04:40 |
| micahg | tzdata can't be updated until the gov't has consensus | 04:41 |
| kermiac_ | seems like even my govt can't make up their mind, lol | 04:41 |
| kermiac_ | true | 04:41 |
| micahg | kermiac_: maybe you can push for a local solution in au | 04:41 |
| micahg | then we can get tzdata updated | 04:41 |
| kermiac_ | I seriously don't think 1 person would be able to rectify this issue - our govt does not like change, even when it contradicts itself - but that discussion could go way too far OT | 04:42 |
| kermiac_ | so I agree that tzdata can't be changed as it stands now, what should happen with the new LP bug? | 04:42 |
| micahg | kermiac_: i know the feeling...but that's the only real solution | 04:42 |
| micahg | hggdh: still around? | 04:43 |
| === kermiac_ is now known as kermiac | ||
| micahg | kermiac: I'm leaning towards triage with milestone ubuntu-later and an explanation in the description | 04:44 |
| kermiac | "ubuntu-later"? I've never heard of that type of milestone. | 04:45 |
| kermiac | is it exaclty that? instead of lucid beta 1 (for example) i put in "ubuntu-later"? | 04:45 |
| micahg | kermiac: yeah, because we're not sure | 04:46 |
| micahg | kermiac: but I wanted to get another's opinion first | 04:46 |
| === nhandler_ is now known as nhandler | ||
| kermiac | ok, thanks. I'll leave it alone for a while & see is hggdh or someone else can shed some light on it a bit later | 04:46 |
| kermiac | my head is spinning just trying to make sense of the issue atm ;) | 04:47 |
| kermiac | another point that may explain why there does not seem to be a concensus is made here http://en.wikipedia.org/wiki/Time_in_Australia | 04:53 |
| kermiac | The proper names of Australia's time zones vary. In international contexts they are often called Australian Western Standard Time (AWST), Australian Central Standard Time (ACST), and Australian Eastern Standard Time (AEST). In domestic contexts the leading "Australian" is often dropped. | 04:53 |
| kermiac | so it seems likely that it will change depending on what context we are discussing the time zone | 04:54 |
| * kermiac bangs his head against the wall | 04:54 | |
| kermiac | I'm going to leave that alone for a while as I am going 'round in circles | 04:55 |
| === kermiac is now known as kermiac_ | ||
| === kermiac_ is now known as kermiac | ||
| persia | Let's not get overly excited about milestoning bugs that have no clear timeframe. | 05:02 |
| persia | There's *lots* of those. | 05:02 |
| persia | Let's keep "ubuntu-later" for remilestoning stuff, if required, after first milestoning somewhere else, so that we can document the decision to defer. | 05:03 |
| micahg | persia: well, it's something that should probably be fixed with no clear timeframe, isn't that what ubuntu-later is for? | 05:03 |
| persia | For most bugs, it's not so much a decision to defer, as that there's no clear information about how long it will take, or who needs to do it. | 05:04 |
| persia | micahg: But *every* crash bug falls into that category, for example. | 05:04 |
| micahg | persia: yes, but we know this has to be resolved by someone else | 05:04 |
| micahg | mainly the australian govt | 05:04 |
| micahg | it should probably be reviewed once a cycle to see if any progress has been made | 05:05 |
| persia | I guess. | 05:05 |
| persia | But I think it's an upstream problem, more than an Ubuntu issue. | 05:05 |
| micahg | persia: upstream dismissed it years ago | 05:05 |
| persia | We tend to patch tzdata a lot, but most of that is really just upstream changes being backported, etc. | 05:05 |
| micahg | persia: they won't fix it until the gov't does | 05:06 |
| persia | Yes, but if the Australian government takes a decision, upstream will change it. | 05:06 |
| micahg | right | 05:06 |
| persia | And if the Australian government doesn't take a decision, we're not likely to do anything else. | 05:06 |
| micahg | true | 05:06 |
| persia | s/else/either/ | 05:06 |
| persia | So I don't see how this is special. | 05:06 |
| micahg | well, it's for our userbase mainly so they don't feel like we don't care I would think | 05:07 |
| persia | At first, I was inclined to agree, because I think it's good to agree. But after some time, I'm less inclined. | 05:18 |
| persia | If we pick out some bugs and say "These are special, but we're not doing them now" it seems to send a confusing message when compared against other bugs. | 05:18 |
| persia | Whereas, if we were to say "This bug is special, we're doing it for lucid beta 2", and then discover we can't, and have to reassign to "ubuntu-later", that seems more just communication, without increasing or decreaing the apparent valuation of the bug. | 05:19 |
| micahg | persia: well, I think this is exceptional in that upstream marked won't fix when it's really should be delayed | 05:21 |
| persia | That's a fair argument, and you've convinced me. | 05:22 |
| kermiac | the consensus in #ubuntu-au-chat (where a lot of us hang out) is that AEST/AEDT is more correct & will avoid confusion with the american "EST". The accuracy of BOM website was brought into question | 05:22 |
| persia | This bug *is* special in that upstream said it was "wontfix", rather than because of anything else about the bug, and deserves to be noted as something for attention in Ubuntu. | 05:22 |
| kermiac | *possibly* there is some policy that hasn't filtered through to BOM. I am very curious now, so I am simply going to subscribe to the LP bug report & try to find out "officially" tomorrow when the govt agencies are open & will hopefully be able to shed some light on the matter | 05:27 |
| micahg | kermiac: that would be great | 05:27 |
| persia | Indeed. | 05:28 |
| persia | Although, personally speaking, I think that Australians shouldn't have to add another letter to the timezone code to work around North American provincialism. | 05:29 |
| * nigelb curses the power company | 05:44 | |
| nigelb | persia: what is the speech-dispatcher you were talking about? (when I got kicked coz I lost my power) | 05:45 |
| persia | nigelb: It's a package installed by default in ubuntu-desktop, ubuntu-netbook, and xubuntu-desktop that contains some test .wav files. | 05:45 |
| nigelb | kubuntu? | 05:46 |
| persia | nigelb: The example-content is another package that has .wav files that is installed by default (but for fewer flavours). | 05:46 |
| nigelb | when we plan for apport hooks, do we need to think about all the distros or just the ubuntu one? | 05:46 |
| persia | How many people run rhythmbox in kubuntu? | 05:46 |
| nigelb | ah | 05:46 |
| persia | Thinking about all flavours is best, but as long as your failure mode is graceful, you can grant better support for the flavours more likely to be running the software being tested. | 05:47 |
| nigelb | I dont the example content helps, its in ogg if I'm not mistaken | 05:47 |
| persia | In the case of rhythmbox, I think it's safe to provide more limited support for kubuntu. | 05:47 |
| persia | So, don't crash if you can't access the .wav file, but use it if it is there. | 05:48 |
| nigelb | good point :) | 05:48 |
| nigelb | any clue where in speech dispatcher these files come into play (I can't find them) | 05:49 |
| nigelb | never mind, got it | 05:49 |
| persia | dpkg -L speech-dispatcher :) | 05:50 |
| nigelb | but on the other hand, is it sane to include a test file with rhythmbox for such purposes? | 05:50 |
| persia | Adds to the package size, and therefore to the CD size, which reduces the number of applications that can be provided. | 05:51 |
| persia | I think it makes more sense to abstract the idea of test wav files into some common package, and have all the packages that need them depend on it. | 05:52 |
| nigelb | and we're already 5 MB above and I dont think some one is going to take kindly to me adding a file, yes. True | 05:52 |
| persia | But that's a lot of work, and should be done before FeatureFreeze, so maybe next cycle. | 05:52 |
| nigelb | so, I'll just use the speech synthesizer files for now and plan for this for lucid+1? | 05:53 |
| persia | That seems like a reasonable plan. | 05:54 |
| nigelb | thanks :) | 05:54 |
| nigelb | just a doubt though, what does speech-dispatcher do? | 05:55 |
| nigelb | assistive technology? | 05:55 |
| persia | Yes. | 05:56 |
| nigelb | cool, so thats why its default package :) | 05:56 |
| persia | It's a common interface to all the speech synthesisers, for the speaking desktop. | 05:56 |
| nigelb | Is it possible to write code to record speech and replay back? | 05:57 |
| persia | One needs to install some synth, and configure stuff, but I don't expect the glue layer wouldn't be present (or it makes it that much harder to set up a screen reader) | 05:57 |
| persia | How do you mean? | 05:57 |
| nigelb | like system testing does | 05:57 |
| nigelb | earlier it used beep files, which have gone and made for record-replay | 05:58 |
| nigelb | if that can be done with a hook with less dependencies, then we'd be in luck | 05:59 |
| persia | I don't see any reason one couldn't use speech-dispatcher to generate some sound for testing. | 06:00 |
| persia | Under the same principles one uses the rest of the accessibility framework for testing other stuff. | 06:00 |
| persia | I don't personally know how it would be done. | 06:00 |
| nigelb | hm. that would be added to later milestones ;) | 06:01 |
| nigelb | for now, I'll just get this stuff ready. | 06:02 |
| persia | You might want to talk to ara about using the accessibility layer for testing. I know she's been doing stuff with that in other areas. | 06:03 |
| nigelb | will do on Monday | 06:03 |
| nigelb | I need to talk to pitti about apport too | 06:03 |
| persia | But one ought be able to automate just about anything programatically (as otherwise one has a hard time providing assistance with that class of task) | 06:03 |
| nigelb | I want to know if there is a way to make apport reports private by default in certain cases | 06:04 |
| persia | I'm sure there is, but it might need some extensions. | 06:05 |
| persia | Because un-retraced crash reports end up private. | 06:05 |
| persia | Actually, super-private: it's the retracer that makes them normally private. | 06:05 |
| nigelb | there seems to be no way to make non-crash reports private | 06:06 |
| nigelb | apport interface does not provide a way, only the retracer makes them private | 06:06 |
| nigelb | which means if I dont have a crash, but just a collection of some potentially private data, there seems to be no apparent way to make it private | 06:07 |
| persia | Right. Probably needs someone to go into the apport code and expose the privacy bit into an option of some sort that can be defined in hooks. | 06:07 |
| nigelb | exactly! | 06:07 |
| kermiac | does anyone know when http://qa.ubuntu.com/reports/five-a-day/ rolls over to the next day? or where I would find out? | 06:16 |
| micahg | kermiac: midnight UTC | 06:20 |
| kermiac | ty micahg :) | 06:21 |
| vish | \o/ i overtook echidnaman ;p | 06:22 |
| kermiac | woot! :) | 06:22 |
| vish | damn if i hadnt changed my lp name it would have been a lot higher ... but heh i'm listed there twice ;) | 06:23 |
| * micahg gave up on 5-a-day for the moment... | 06:23 | |
| * vish glad ^ .. more happy with micahg's amazing work on tb3 :) | 06:25 | |
| vish | micahg: when will tb3 replace tb2 in lucid? | 06:25 |
| micahg | vish: still hasn't been accepted? | 06:25 |
| vish | nope :( | 06:26 |
| micahg | vish: as soon as someone gets it out of NEW I guess | 06:26 |
| vish | .. ah will have to wait for NEW | 06:27 |
| kermiac | hmmm hggdh the user "Bongcaivang" is back?? https://edge.launchpad.net/~tutinhkhuc05 has the same email address, but it is very suspicious as a LP question has been filed against that user account by the person I've been cleaning up after all day | 06:40 |
| kermiac | https://answers.edge.launchpad.net/launchpad/+question/101795 was filed by "Fail2Ban" | 06:40 |
| * kermiac shakes his head | 06:40 | |
| duanedesign | kermiac: i noticed that too | 06:43 |
| duanedesign | do you think it is the same person | 06:43 |
| duanedesign | and this is some pathetic attempt to look legitemate | 06:44 |
| kermiac | duanedesign: I'm not sure. It is definately the same email address, but the person who filed the new complaint is "Fail2Ban". I have been cleaning up bug reports they changed all day, so I am not sure | 06:44 |
| duanedesign | tutinhkhuc05 created his profile and clearly put the name Bongcaivang in the new profile | 06:44 |
| duanedesign | but then there was no activity with tutinhkhuc05, it all been with Fail2ban | 06:45 |
| kermiac | yes, if it was the spammer "Bongcaivang" back again, I don't think they would use the same email address | 06:45 |
| duanedesign | i figured they were all three the same person? Because it seems odd that Fail2Ban woul have posted that LP Answer | 06:46 |
| kermiac | yes, I tend to agree with you | 06:47 |
| duanedesign | frustrating nontheless | 06:47 |
| * vish wonders what drives/motivates such people :/ | 06:47 | |
| duanedesign | i know rye was working on something to make correcting these things easier to fix | 06:47 |
| duanedesign | i think you guys talked about it earlier kermiac | 06:48 |
| kermiac | yes, we were discussing it earlier | 06:48 |
| === kermiac is now known as kermiac_ | ||
| wgrant | micahg: Thanks for the quick bookmark fix. | 08:21 |
| micahg | wgrant: np | 08:23 |
| micahg | wgrant: if only all fixes were that easy ;) | 08:23 |
| wgrant | I've been meaning to file that bug for a couple of years, but decided to do it now so the redirect wasn't locked in for another three years... | 08:24 |
| micahg | wgrant: that's probably something we could've pushed with an update | 08:27 |
| micahg | but now, we'll get it pushed to Hardy/Jaunty/Karmic when they're backported | 08:28 |
| wgrant | micahg: 3.6 will be pushed to all those? | 08:29 |
| micahg | wgrant: yes, not sure on exact timetable though | 08:29 |
| wgrant | Aha. | 08:29 |
| micahg | 3.0 is EOL, so we need to do something | 08:30 |
| wgrant | Indeed. | 08:30 |
| wgrant | I am glad there is a solution now. | 08:30 |
| micahg | wgrant: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model | 08:30 |
| wgrant | I knew about that, but not that it was to be retroactive. | 08:31 |
| micahg | wgrant: yeah, we're also backporting xul192 | 08:32 |
| vish | om26er: Bug #460286 is not triaged... hasnt been sent upstream | 09:16 |
| ubot4 | Launchpad bug 460286 in empathy (Ubuntu) (and 1 other project) "Empathy notifications not shown (affects: 2)" [Wishlist,Triaged] https://launchpad.net/bugs/460286 | 09:16 |
| vish | om26er: or is it an ubuntu specific change? if so you need to mention it | 09:16 |
| om26er | vish, let me ask that at #empathy | 09:17 |
| vish | hmm.. :( | 09:17 |
| persia | At least so mentioning it is a great help to the developers, as it helps know who is best to look at it, etc. | 09:17 |
| om26er | no response there but I think they wont enable it by default that's why sent it to the papercutters to see what they think. | 09:26 |
| * om26er opens upstream report | 09:26 | |
| om26er | https://bugzilla.gnome.org/show_bug.cgi?id=610589 | 09:41 |
| ubot4 | Gnome bug 610589 in Notifications "enable notifications when chat is not focused" [Enhancement,Unconfirmed] | 09:41 |
| vish | om26er: also mentioning the lp bug# upstream would be good | 09:45 |
| om26er | ah.. forgot this time | 09:46 |
| vish | om26er: usually how everyone does it is , we start the upstream bug with "Bug first reported in lp: Bug#" | 09:46 |
| * om26er too does that | 09:46 | |
| om26er | always | 09:47 |
| nigelb | just add a comment with that | 09:47 |
| nigelb | I guess I forget to write the Lp almost every time ;) | 09:47 |
| vish | .. once you do it several times it becomes involuntary :) | 09:48 |
| nigelb | true. wish there was a script for that | 09:48 |
| om26er | in the begining I used to start the bug report with 'originally reported at:" then the description that was silly ;) | 09:49 |
| nigelb | I just add a last line. This bug was originally reported on Ubuntu's bug tracker, launchpad, at --- | 09:50 |
| om26er | I marked a bug report invalid due to the non responsive reporter and now he replied its fixed for him in lucid (was a crash report) leave it invalid? | 09:51 |
| nigelb | change to fix released | 09:51 |
| nigelb | (I think, your take vish ?) | 09:51 |
| vish | you can change it to fix released.. | 09:52 |
| micahg | vish: om26er: not so sure | 09:52 |
| micahg | depends if the problem is clearly identified or not | 09:53 |
| nigelb | micahg: we have to locate the exact changelog entry for it then? | 09:53 |
| micahg | nigelb: idk exact, was teh crash confirmed by anyone? | 09:53 |
| vish | micahg: i'v mentioned this earlier ;) but the desktop team mentioned that if an update fixes it it is safe to mark it as fix released | 09:53 |
| nigelb | thats what even I was told | 09:53 |
| vish | from the bug status wiki it says invalid though | 09:53 |
| micahg | well, if it's a desktop team package, then do what they say, otherwise, I'd say follow the wiki | 09:54 |
| om26er | https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/458367 | 09:54 |
| ubot4 | Launchpad bug 458367 in empathy (Ubuntu) "empathy crashed with SIGSEGV in FcFontSetSort() when some utf characters are sent (affects: 3)" [Medium,Invalid] | 09:54 |
| persia | It's best practice to hunt up the changelog entry, so you can note precisely which version fixed it (helps with regression tracking later), but Fix Released should be correct for a repeatable bug that can no longer be repeated. | 09:54 |
| persia | This is true for both Desktop and non-Desktop bugs :) | 09:54 |
| vish | ;) | 09:54 |
| micahg | persia: well, you have no idea if it was that package unless you know what caused it | 09:55 |
| vish | om26er: the earlier empathy bug was started for notify-osd... add the empathy details in the bug description | 09:55 |
| micahg | for example, a gtk bug might cause a firefox crash, so if the gtk bug is fixed in teh next release, the crash probably won't happen, but fix released is inappropriate for firefox since it was a gtk crash | 09:56 |
| vish | micahg: exactly the point i made.. or tried to make :) | 09:56 |
| persia | micahg: Indeed, although I've had cases where I understood enough about the bug to know it was package X, and was able to repeat, and it went away and this wasn't mentioned in the changelog (and sometimes couldn't be found by source inspection of the diff). | 09:56 |
| persia | The reason being that there's lots of interaction between packages, especially related to libraries, and sometimes just rebuilding a package makes it magically work, but if several uploads have happened, we can't necessarily know which one has the magic side effects. | 09:57 |
| vish | micahg: i marked a few bugs as invalid.. but seb came behind me and marked the as fix released.. | 09:57 |
| micahg | persia: right, I'm thinking that maybe we need another status called no longer applies or something... | 09:57 |
| persia | (even though the bug was in the application, it may have been exposed by an older library version, and a newer version may not expose it, or the package build system may have changed in a way that no longer causes that issie, etc.) | 09:57 |
| persia | No, I like "Fix Released" when we know it got fixed. | 09:58 |
| micahg | vish: like I said, when in the desktop team's packages follow their rules | 09:58 |
| vish | righto.. | 09:58 |
| micahg | persia: that's the real question, was it fixed | 09:58 |
| micahg | or did it just go away | 09:58 |
| persia | Is there a difference? | 09:59 |
| micahg | persia: their is for backporting fixes | 09:59 |
| * vish still thinks if there is no documented fix.. it should be invalid | 09:59 | |
| persia | micahg: Well, sure, but that's harder. | 09:59 |
| nigelb | what about the many 100s who come to a bug from google and just add comments finding similar problems | 09:59 |
| nigelb | if u mark as fix released, they know it was fixed in a particular update | 10:00 |
| nigelb | (my 2 bits) | 10:00 |
| persia | nigelb: In the case where one knows which upload fixed it, I think we all agree "Fix Released" is the correct status. We're discussing the case where we had a nice, repeatable bug and it mysteriously went away. | 10:00 |
| persia | (because of library changes, or toolchain changes, or similar) | 10:01 |
| vish | \o/ new status... " mysterious fix" ;p | 10:01 |
| nigelb | it is a bit difficult to understand which is which, but when its clear its not something to do with the actual app (like micahg said) I agree Invalid is better. | 10:01 |
| persia | OK, so here's an example of why I disagree (although it's old). | 10:02 |
| persia | wxwindows2.4 had a bug that rendered utf8 as garbage. wxwidgets2.6 didn't. | 10:02 |
| persia | Lots of applications could be compiled against either, and decided which to compile against based on the output of a command that set compilation flags. | 10:03 |
| persia | So, at one point, the command was changed. Packages that built after that suddenly worked. | 10:03 |
| persia | Packages built before that didn't. | 10:03 |
| persia | For the packages that got uploaded for some other reason, nobody did anything special to fix the bug. | 10:04 |
| persia | For the packages that still had the bug when there were only a few left, someone specifically fixed it for the leftovers. | 10:04 |
| nigelb | which futher tilts the discussion towards ambiguity. I guess we have to make a call on each bug based on situation | 10:04 |
| micahg | persia: well, you're saying through process of elimination, the one and only change was the version of this pacakge | 10:04 |
| persia | But I still think the bug was "Fix Released" for the ones where the fix was accidental. | 10:04 |
| persia | micahg: Right, but as triagers we can't always know which of the last 10 uploads of a package happened to be the threshold change. | 10:05 |
| micahg | oh, you're saying people marked packages built against it fix released? | 10:05 |
| persia | We can know that it was broken in version X and fixed in version Y (and I usually leave that in a comment when I can't identify a specific version in which it was fixed) | 10:05 |
| persia | micahg: Right, because the bug was fixed, even though the rebuild happened for another reason. | 10:06 |
| persia | And I think people were *correct* to mark it that way, even though the fix was accidental. | 10:06 |
| micahg | persia: right, but that's definitely a case where the bug isn't in that package | 10:06 |
| micahg | they should have all been marked as fix released in wxwidgets2.6 | 10:07 |
| vish | but we cant really track this^ :( | 10:07 |
| micahg | and invalid in the original package | 10:07 |
| persia | No, because when the change happened in wxwidgets2.6, there were still about 40 packages that had the problem. | 10:07 |
| persia | And the bug in wxwidgets *was* marked fixed. | 10:07 |
| micahg | persia: hmm.... | 10:07 |
| persia | And when the list got down to about 10, the last ones were pushed just before release, fixing the bug. | 10:07 |
| persia | This happens all the time, and the developers have the "NBS" list they use to track some of the transitions. | 10:08 |
| micahg | persia: yeah, I guess you're right here | 10:08 |
| micahg | I'm doing something similar for xul192... | 10:08 |
| persia | But usually a goodly chunk of any of the transitions happens by accident, just through uploads of other bugfixes. | 10:08 |
| persia | But in these cases, I say we should put "Fix Released" and indicate a version we know had the issue and a version we know didn't. If someone wants to backport, they can look into it in more granularity, testing different things. | 10:09 |
| persia | On the other hand, if we can't reliably replicate a bug, and it magically goes away, I agree "Invalid" is better. | 10:10 |
| vish | persia: but "fix released" seems that something specific was done to fix the bug.. we could rather use a better status, [resolved ???] | 10:10 |
| nigelb | vish: +1 to that suggestion | 10:10 |
| micahg | persia: yeah, that does make sense... | 10:11 |
| nigelb | but that would add a whole lof ambuigity | 10:11 |
| persia | vish: That's perhaps more technically correct, but in that case I'd argue that "Fix Released" could only be set by changelog parsing, and everything else was "Resolved". | 10:11 |
| vish | +1 ^ | 10:11 |
| micahg | +1 | 10:11 |
| vish | persia: that would be _the_ best way to track fixes.. | 10:11 |
| persia | And we can distinguish those two cases anyway, by checking the identity of the user that set "Fix Released", so it adds no semantic value to have a separate status. | 10:12 |
| micahg | well, changelog or bug admin... | 10:12 |
| persia | Um, no. Just changelog. | 10:12 |
| persia | Otherwise we can't know that it was fixed by a specific upload intentionally. | 10:12 |
| micahg | persia: if someone forgets to close the bug in the changelog, the admin should be able to paste the changelog with the fixes | 10:12 |
| persia | Who is "the admin"? | 10:13 |
| persia | Why do we trust them? | 10:13 |
| micahg | persia: bug admin (-control | 10:13 |
| persia | How can we backtrack that to a changelog entry to verify? | 10:13 |
| vish | micahg: if they forget then they can use the "resolved" and mention the change.. it makes sure people have a good changelog too :) | 10:13 |
| micahg | vish: I suppose | 10:13 |
| micahg | for example, I forgot to close the changelog entry for the TB3 upgrad | 10:14 |
| micahg | e | 10:14 |
| persia | I think it's a pointless distinction, because the bug is, after all, fixed, and we can already distinguish changelog-upload-fixes-the-bug from other bugfix closures. | 10:14 |
| persia | Sure. That happens a lot. Lots of bugs get noticed and marked fixed laster. | 10:14 |
| persia | Lots of bugs get fixed upstream or in Debian, and we know them to be fixed. | 10:14 |
| persia | There are more cases. | 10:14 |
| micahg | yeah, that's true persia, but if it was a different status, we could search for it at least | 10:15 |
| persia | Personally, I trust bug control enough to not see any meaningful difference between "Fix Released" and "Resolved" for that group. | 10:15 |
| vish | persia: the distinction is more to track the fixes. now , we cant say which has been fixed or mysterioulsy reloved.. | 10:15 |
| vish | resolved* | 10:15 |
| persia | vish: Yes you can, just run a script that checks who set "Fix Released". | 10:15 |
| vish | persia: but that is a workaround ;) | 10:16 |
| persia | Why? | 10:16 |
| persia | Remember, LP needs to have statuses that make sense for *every* project in launchpad. | 10:16 |
| persia | And each one is going to have different policies. | 10:16 |
| vish | hmm.. yeah | 10:16 |
| persia | For instance, "Fix Committed" and "Fix Released" mean very different things for most projects in LP than they mean for Ubuntu. | 10:16 |
| persia | So, rather than a workaround, consider it a way of using more features of launchpad to get a more detailed view. | 10:17 |
| persia | For instance, it might be something to add to bughugger | 10:17 |
| persia | Or to the greasemonkey scripts that some of us use. | 10:17 |
| vish | that would be good | 10:17 |
| persia | Because those are project-specific. | 10:17 |
| nigelb | even a top line formated as *Resolved* would be good enough | 10:18 |
| nigelb | if it can be tracked | 10:18 |
| micahg | well, I started abusing upstream milestones to know when to close bugs that are committed upstream (mozilla) | 10:18 |
| persia | micahg: I'm sure you're not alone amoung maintainers of active well-integrated upstreams. | 10:23 |
| micahg | k, I'm off, night | 10:35 |
| micahg | or morning, or whatever.... | 10:35 |
| nigelb | lol | 10:35 |
| nigelb | later micahg :) | 10:35 |
| micahg | or afternoon for nigelb ;) | 10:35 |
| nigelb | more or less evening ... 4 pm | 10:35 |
| micahg | nigelb: you're UTC +6? | 10:36 |
| nigelb | IST, GMT+5:30 | 10:36 |
| micahg | heh, ok, almost 12 hrs difference from me :) | 10:36 |
| nigelb | so you're just hitting the bed? | 10:37 |
| micahg | yeah | 10:37 |
| * nigelb bows | 10:37 | |
| micahg | nah, just sat nights... | 10:37 |
| nigelb | a funny bug, bug 15378 | 11:19 |
| ubot4 | Launchpad bug 15378 in rhythmbox (Ubuntu) "Rhythmbox does not allow dragging from nautilus (affects: 1)" [Wishlist,Invalid] https://launchpad.net/bugs/15378 | 11:19 |
| nigelb | the OP *wants seb* to fix the issue :P | 11:19 |
| persia | The reporter would likely benefit from a gentle rebuke that other posters are just trying to help with workarounds, whilst the bug is confirmed and pushed upstream. | 11:23 |
| persia | Upstream will probably wontfix it, but we ought follow process. | 11:23 |
| persia | (or maybe it's a duplicate, or some such) | 11:23 |
| persia | Otherwise people are mad at seb, for the wrong reasons. | 11:23 |
| nigelb | will do | 11:24 |
| nigelb | upstream is mostly meh about such bugs ;) | 11:24 |
| nigelb | there was this old bug about auto-deletion from playing queue | 11:25 |
| nigelb | there was a huge bug upstream and downstream, upstream even got a patch, but they said its supposed to be that way ;) | 11:25 |
| Damascene | is there any bug about empathy not saving accounts | 11:26 |
| nigelb | Damascene: meaning every time you log out, all your informating is getting blanked? | 11:28 |
| Damascene | nigelb, yes | 11:30 |
| nigelb | Damascene: checking | 11:30 |
| Damascene | O | 11:31 |
| Damascene | sorry, I'm on Lucid | 11:31 |
| Damascene | there is strange picture with scissors | 11:32 |
| nigelb | I dont find any dups for that | 11:34 |
| Damascene | some one else have this in #ubuntu+1 | 11:35 |
| nigelb | if so, confirm that there are no dups and go ahead | 11:36 |
| _Narc_ | Hello all. Can someone tell me if Bug #524808 should be affected to linux, pm-utils or something related ? I think linux cause of the oops, but I'm not sure. I'm still learning. Thanks. | 11:41 |
| ubot4 | Launchpad bug 524808 in ubuntu "suspended comp need power button to wake up (affects: 1)" [Undecided,New] https://launchpad.net/bugs/524808 | 11:41 |
| Damascene | empathy problem have gone after udpate | 13:15 |
| Damascene | *update | 13:15 |
| nigelb | hggdh: hey, sorry about last night | 14:51 |
| nigelb | I lost power and then sorta.. um.. slept off.. | 14:52 |
| hp_ | any one here working in montreal office of canonical?? | 14:54 |
| bcurtiswx | om26er: why is bug #525189 invalid? | 14:54 |
| ubot4 | Launchpad bug 525189 in empathy (Ubuntu) (and 1 other project) "Empathy notification without icon (affects: 1)" [Low,New] https://launchpad.net/bugs/525189 | 14:54 |
| bcurtiswx | ugh hes not here.. | 14:55 |
| bcurtiswx | invalidating with no explanation!! AHHH | 14:55 |
| persia | revalidate :) | 14:55 |
| persia | Or investigate | 14:55 |
| * bcurtiswx is already ahead of ya :D thx tho | 14:55 | |
| nigelb | I was about to tell you he's not here | 14:55 |
| nigelb | bcurtiswx: is that even a bug? (just a doubt) | 14:56 |
| nigelb | because emapthy shows the icon of whatever is the person's display image | 14:57 |
| bcurtiswx | nigelb: thats what i was going to talk to him about | 14:57 |
| nigelb | bcurtiswx: you seem to be ahead of me then :) | 14:57 |
| nigelb | but probably what he means is displaying an icon when there is no image | 14:57 |
| persia | bcurtiswx is clearly in the lead by a far margin, and may well be about to lap the rest of us. | 14:58 |
| nigelb | lol, yeah | 14:58 |
| bcurtiswx | persia: don't count on that happening | 14:58 |
| bcurtiswx | persia: i tend to blow a tire about a half a lap before the end | 14:59 |
| persia | Well, it's the nature of things. This is an endurance run, so I think there's no fear when anyone draws ahead for a bit. | 14:59 |
| bcurtiswx | im a fat man, i hate endurance races :P | 15:03 |
| persia | Then it's good you're in the lead today :) | 15:04 |
| bcurtiswx | if I'm not here when om26er appears. Please make sure he knows to comment on all changes he makes in his bug reports. | 15:06 |
| bcurtiswx | well time to go make a pot roast.. garlic, celery, carrots, potatoes mmmmmm | 15:07 |
| bcurtiswx | slow cooker :D | 15:07 |
| persia | Try a bit of hard squash in that, if you have it. Surprisingly complementary. | 15:08 |
| bcurtiswx | persia: not this time, but i will grab one next time :D | 15:09 |
| nigelb | can someone help me understand this debug 486041 | 15:22 |
| BUGabundo | bug 486041 | 15:22 |
| ubot4 | Launchpad bug 486041 in rhythmbox (Ubuntu) "When ejecting a CD during playback rhythmbox shows "Could not pause playback" message (affects: 1)" [Low,Incomplete] https://launchpad.net/bugs/486041 | 15:22 |
| DawnLight | yo, i'd like help debugging X memory usage. i've got a memory leak. how do i reckognize what's causing it? it appears Xorg is using 69.5MB of my RAM but sometimes it uses much more. is there way to find out? | 15:40 |
| Laibsch | Is there a way to hide bugs in the list of "my bugs" in Launchpad if they are not affecting Ubuntu anymore? I have a ton of bugs by now that are still left open for Debian for example. Many of them just because apparently LP has an issue syncing the status with the Debian BTS. | 15:41 |
| Laibsch | It's gotten to be a pain to use the "my bugs" list as a todo list | 15:41 |
| BUGabundo | 70M aint that bad | 15:41 |
| DawnLight | BUGabundo: it grows, i've seen it | 15:41 |
| BUGabundo | 956 root 20 0 140m 50m 27m S 22 1.3 15:24.16 Xorg | 15:42 |
| BUGabundo | 956 0 0 1772K 141.0M 51528K 0K 0K 1% Xorg | 15:42 |
| nigelb | DawnLight: you could try a valgrind (https://wiki.ubuntu.com/Valgrind) | 15:42 |
| BUGabundo | DawnLight: valgrind is your firend | 15:43 |
| BUGabundo | and try #ubuntu-x on week days | 15:43 |
| nigelb | wb persia :) | 15:44 |
| DawnLight | thanks | 15:46 |
| persia | nigelb: Thanks, although I'm kinda laggy. My network blew up, but seems to be working again. | 15:53 |
| nigelb | :) | 15:53 |
| nigelb | persia: have you got some time? | 15:56 |
| persia | nigelb: In a bit: I'm still trying to recover some of the less important bits. | 15:57 |
| nigelb | I'm looking for someone to walk me through understanding --debug output of rhythmbox | 15:57 |
| nigelb | see the ^^ bug | 15:57 |
| Laibsch | what is the difference between the ubuntu-10.04 and the ubuntu-lucid milestone in Launchpad? | 16:14 |
| micahg | Laibsch: I don't see an ubuntu-lucid milestone | 16:14 |
| Laibsch | micahg: indeed | 16:15 |
| Laibsch | But there are ubuntu-10.04-beta-1 and ubuntu-lucid-alpha-1. I guess that inconsistent naming got me a bit confused | 16:16 |
| Laibsch | is there a deeper meaning for using the numbers in one case and the release name in the other? | 16:16 |
| micahg | Laibsch: probably better to ask in -devel than here | 16:17 |
| Laibsch | OK | 16:17 |
| Laibsch | I guess I shouldn't expect too much activity | 16:17 |
| micahg | Laibsch: today, probably now | 16:17 |
| micahg | *not | 16:17 |
| vish | yay , supermicahg is up... :D | 16:19 |
| * vish wonders if micahg is an insomniac ;) | 16:19 | |
| micahg | vish: sometimes :( | 16:19 |
| vish | micahg: hehe , good for us and ubuntu ;p | 16:20 |
| om26er | how can I debug empathy through gdb | 16:24 |
| om26er | actually telepathy-gabble | 16:25 |
| * nigelb wonders if micahg is an AI bot :p | 16:25 | |
| om26er | I got this from upstream "Could you run gabble in gdb and get a trace when it crashes please?" | 16:28 |
| vish | om26er: <bcurtiswx> if I'm not here when om26er appears. Please make sure he knows to comment on all changes he makes in his bug reports. | 16:35 |
| om26er | vish, read it on the bug report | 16:35 |
| vish | om26er: btw, the bug is a low priority bug. since its a cosmetic issue | 16:35 |
| * om26er rather provide the crash report upstream | 16:36 | |
| om26er | vish, ah, I actually marked it low. things are really going bad today | 16:37 |
| vish | om26er: np.. :) ..if you are here it is easier to correct your changes than mention on lp ;) | 16:38 |
| vish | om26er: also the upstream task need not be invalidated.. [if changed from papercuts] | 16:39 |
| om26er | vish, I really though that was an issue at our end(not upstream) cuz I was just chatting with someone and his avatar was visible. but this only happens for people with no avatar | 16:41 |
| vish | om26er: probably similar to the accounts menu bug.. [where the order is jagged since some protocols dont have icons].. | 16:43 |
| vish | emapthy doesnt have a default icon for those instances | 16:43 |
| * om26er have to send a debug log upstream and dont have any contact online to reporoduce :( | 16:47 | |
| Laibsch | Can somebody who can read stack traces please have a look at bug 338217, particularly comment 13? | 17:02 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 56) (dups: 74)" [Medium,Invalid] https://launchpad.net/bugs/338217 | 17:02 |
| === qense_ is now known as qense | ||
| === radoe__ is now known as radoe | ||
| hggdh | Laibsch: the stacktraces match | 17:35 |
| nigelb | hggdh: morning (or afternoon or whatever) | 17:44 |
| hggdh | morning nigelb | 18:06 |
| hggdh | well, actually, afternoon now (12:05) | 18:06 |
| nigelb | sorry I left in between yday night | 18:06 |
| hggdh | oh, np. The gist is we need to find an always-installed package that carries the sound files | 18:07 |
| nigelb | hggdh: per_sia says we should use the speech-dispatcher for now and then think of adding a voice file | 18:07 |
| nigelb | or a package with voice | 18:07 |
| hggdh | or add one to rhythmbox (not really good) | 18:07 |
| hggdh | nigelb: good enough | 18:07 |
| nigelb | (i'm for adding a file to rhythmbox | 18:07 |
| hggdh | (I am not ;-) | 18:07 |
| hggdh | the smaller delta to upstream, the better | 18:08 |
| nigelb | adding another dependency would take more space | 18:08 |
| nigelb | well, anything in debian folder is okay me thinks | 18:08 |
| hggdh | only if it is not installed by default on a desktop | 18:08 |
| hggdh | well. *any* changes to upstream require manual work here | 18:09 |
| hggdh | be in ./debian (when we get the packages from Debian) or elsewhere | 18:09 |
| hggdh | unless Debian also buys into apport | 18:09 |
| nigelb | which I doub | 18:10 |
| hggdh | I do not, not that much, but apport requires a back-office to process the dumps | 18:10 |
| hggdh | and Debian is not cut this way (but this could be adjusted) | 18:10 |
| nigelb | but at least not yet | 18:11 |
| hggdh | yes, probably. | 18:11 |
| nigelb | adding the hook is a delta, so one more file wont hurt is what I think | 18:11 |
| nigelb | but that needs to be discussed with seb | 18:11 |
| hggdh | there are impacts everywhere: (1) if rhythmbox is in main, this means a bit more of space being used | 18:12 |
| nigelb | yes, the space issue being major | 18:12 |
| hggdh | (2) or additional dependencies -- which *may* (or may not) require more space in main | 18:13 |
| hggdh | (3) etc | 18:13 |
| hggdh | so this has to be carefully looked at and justified | 18:13 |
| nigelb | now I'm wondering if I should hold off the whole exercise until after lucid or just put something up so that it works on at least gnome | 18:13 |
| hggdh | but we will have to go this way, since this allows for more data to be collected for bugs -- and this helps everybody | 18:14 |
| nigelb | hm, thats what is driving me | 18:14 |
| nigelb | hggdh: there is another option | 18:15 |
| hggdh | yes? | 18:15 |
| nigelb | we could record speech and play it back | 18:15 |
| nigelb | like how "System Testing" does it | 18:16 |
| hggdh | this could be an *option*. But you cannot guarantee that someone *listening* to <whatever> has a microphone | 18:16 |
| hggdh | I usually do not, for exaxmple | 18:16 |
| nigelb | hm. | 18:17 |
| Laibsch | hggdh: Thank you very much. IOW, bug 338217 is a dupe of bug 199592? | 18:23 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 56) (dups: 74)" [Medium,Confirmed] https://launchpad.net/bugs/338217 | 18:23 |
| ubot4 | Launchpad bug 199592 in scim-bridge (Ubuntu Hardy) (and 1 other project) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 7) (dups: 135)" [Medium,Confirmed] https://launchpad.net/bugs/199592 | 18:23 |
| hggdh | Laibsch: it does look like it is, yes | 18:26 |
| Laibsch | great | 18:26 |
| Laibsch | Thank you VERY much | 18:26 |
| Laibsch | Now I need to find out how to efficiently merge the two | 18:26 |
| hggdh | nigelb: another option is to generate a sound (fixed frequency) | 18:26 |
| hggdh | Laibsch: this is what I am not sure will be easy... | 18:26 |
| Laibsch | I think there is a tool | 18:27 |
| nigelb | hggdh: practically possible to create a wav in python? | 18:27 |
| hggdh | Laibsch: I do not know -- I think there might be a tool, but I am not sure | 18:27 |
| hggdh | nigelb: well, yes, all you need is to generate -- say -- 10 seconds of 1500Hz | 18:28 |
| hggdh | nigelb: all you need is to find the suitable python modules | 18:29 |
| Laibsch | hggdh: lp-set-dup from ubuntu-dev-tools -> http://packages.ubuntu.com/lucid/ubuntu-dev-tools "sets the "duplicate of" bug of a bug and its dups. " | 18:29 |
| nigelb | wouldn't it be too much for just a hook? | 18:29 |
| hggdh | Laibsch: I read and learn. Thank YOU for this | 18:29 |
| Laibsch | giving and receiving, the great thing about FOSS ;-) | 18:30 |
| hggdh | indeed :-) | 18:30 |
| Laibsch | It'll be the first time I will use this | 18:30 |
| Laibsch | I remember doing this manually a few times | 18:30 |
| hggdh | nigelb: collecting the correct data for a bug is a pretty important step | 18:30 |
| Laibsch | not fun ;-) | 18:31 |
| * hggdh remembers, some few years ago, moving 35 dups around | 18:31 | |
| nigelb | hggdh: milestone for lucid+1 then? | 18:31 |
| * Laibsch is happy the lp-set-dupe is already available in karmic | 18:31 | |
| Laibsch | I remember it's a fairly recent addition to the tools | 18:31 |
| hggdh | nigelb: it is your code, you know better how long it will take. We can also add it as a SRU later | 18:32 |
| hggdh | Laibsch: probably, there is tinkering going on continuously there | 18:32 |
| nigelb | hggdh: /me is coding for a production environment for the first time | 18:32 |
| hggdh | nigelb: so consider it for +1 -- safer | 18:33 |
| Laibsch | hggdh: I certainly hope so | 18:33 |
| hggdh | and, when ready, I think we can justify a SRU | 18:33 |
| nigelb | I'll change all references of question to the other file | 18:33 |
| nigelb | and test it thoroughly now | 18:33 |
| nigelb | if it works, I'll ask for a merge for lucid and then we'll work on getting a beep working | 18:34 |
| hggdh | nigelb: I also use rhythmbox, so I can test it | 18:35 |
| Laibsch | lp-set-dup works like a charm | 18:35 |
| nigelb | hggdh: beautiful, lemme get to work getting the code standards complaint | 18:36 |
| hggdh | Laibsch: cool. This actually raises up the need to publish our tools. | 18:36 |
| Laibsch | yes | 18:36 |
| * hggdh did not know about it, and *should* have | 18:36 | |
| Laibsch | that is the downside of having more and more tools, though. It can become complicated to keep up with their introduction and actually knowing aboutthem. | 18:37 |
| hggdh | indeed | 18:37 |
| Laibsch | I can't imagine the pain | 18:40 |
| Laibsch | reassignig 135 dupes would have caused | 18:40 |
| hggdh | :-) | 18:41 |
| nigelb | hggdh: http://pastebin.com/d449828b1 | 18:52 |
| nigelb | wise to cut the code 80 characters? | 18:52 |
| nigelb | (that would look really complicated | 18:53 |
| hggdh | nigelb: it is always wise to respect a theoretical limit of 80 characters to a line (old terminals) | 18:53 |
| * nigelb groans | 18:53 | |
| hggdh | :-) | 18:53 |
| hggdh | nigelb: another thing(ie): it would be a good idea *not* to use real tabs | 18:55 |
| nigelb | I used 4 spaces | 18:55 |
| nigelb | heck | 18:55 |
| nigelb | I thought of doign that | 18:56 |
| hggdh | :-D | 18:56 |
| nigelb | donno why it got messed up | 18:56 |
| hggdh | yes, remember that I told you about the 'how to write python code' yesterday? | 18:56 |
| nigelb | yep | 18:56 |
| nigelb | going through that document | 18:57 |
| nigelb | first one was make all indents to 4 spaces, done now | 18:57 |
| hggdh | there are more pearls. None of them are really required, but they help on making it easier to understand code written by others (the bane of programming) | 18:57 |
| nigelb | what more do I need to correct? | 18:57 |
| hggdh | try to limit lines to less than 80 characters | 18:58 |
| nigelb | that would be nasty | 18:58 |
| nigelb | the code would look really ugly :( | 18:58 |
| hggdh | no, it would not | 18:58 |
| hggdh | remember that (1) python allow for splitting lines (2) better to see the whole line than to see only part of it | 18:59 |
| kklimonda | hggdh: is it worth trying to revert anjal to 0.1 in lucid? 0.3.1 won't build as it depends on evo/eds 2.29.x which are not going to be in lucid (I'm asking because you are the one who made a PPA with anjal in the past and you are somehow interested in Evolution :) ) | 19:00 |
| hggdh | kklimonda: for anjal... I think the only way to have it in Lucid is to keep it at 0.1 (or the last version dependant on evo 2.28) | 19:01 |
| hggdh | we are keeping Evo in 2.28 on Lucid, too dangerous to go to 2.30 -- still under heavy development, and still *very* fragile | 19:02 |
| hggdh | so... anjal cannot be 0.3.1 | 19:02 |
| kklimonda | hggdh: I know - but I wonder if it's worth keeping such an old release at all | 19:02 |
| hggdh | perhaps we could provide it as a PPA only | 19:02 |
| hggdh | I agree that providing 0.1 is a step backwards | 19:03 |
| kklimonda | hggdh: and now due to some bizarre error anjal 0.3.1 has been uploaded to archive and is currently waiting for evo/eds 2.29 to build - so we'll have to back it out somehow. | 19:03 |
| hggdh | the upload will have to be cancelled | 19:03 |
| kklimonda | so maybe removing it completely from lucid would be a better choice than canceling upload and getting old version that the upstream won't support | 19:03 |
| hggdh | probably the uploader did not notice the requirement (and the fact we are *not* going to it) | 19:04 |
| hggdh | kklimonda: yes. anjal is universe, right? | 19:04 |
| kklimonda | hggdh: no - it was a sync request for 0.1 but for some weird reason 0.3.1 got synced | 19:04 |
| nigelb | hggdh: how do I correct the line length? using '/' ? | 19:04 |
| kklimonda | probably because in the meantime it got uploaded to experimental debian repository | 19:04 |
| kklimonda | hggdh: right | 19:04 |
| nigelb | rather \ | 19:05 |
| hggdh | nigelb: this is one option, yes | 19:05 |
| kklimonda | hggdh: so it would have no support at all - neither from us nor from upstream | 19:05 |
| hggdh | kklimonda: yes. Let's involve MOTU here | 19:05 |
| nigelb | thats causing a mess | 19:05 |
| hggdh | kklimonda: to #ubuntu-motu | 19:05 |
| kklimonda | already there :) | 19:06 |
| hggdh | nigelb: the python document shows a series of ways to split code lines | 19:06 |
| nigelb | checking | 19:06 |
| hggdh | kklimonda: ah well | 19:14 |
| nigelb | hggdh: I dont find anything in that document that is helping me :( | 19:15 |
| nigelb | the only thing I found is \ and that is giving me issues right now :( | 19:15 |
| hggdh | python can auto-join text strings between lines | 19:16 |
| hggdh | or you can say 'blah blah' + 'blah' + 'blahblah', and split the lines at the '+' sign | 19:17 |
| hggdh | etc | 19:17 |
| hggdh | ;-) | 19:17 |
| * hggdh is mean, forcing poor nigelb to read more and more and more >-) | 19:18 | |
| nigelb | well, look at this http://pastebin.com/d17d7c9f7 | 19:18 |
| nigelb | thtas the input I'm giving and the output I get | 19:18 |
| hggdh | looks correctly wrong | 19:19 |
| hggdh | or wrongly correct, I am not sure | 19:19 |
| nigelb | great | 19:19 |
| kklimonda | hggdh: I'm going to subscribe to anjal bugs and clean up those few reports we have right now - hopefully no one is going to ever use it in lucid :) | 19:19 |
| * nigelb adds the line length issue to lucid+1 | 19:19 | |
| hggdh | the \ means the line is continued on next line -- all spaces count | 19:19 |
| nigelb | that would make it look ugly like I said earlier | 19:20 |
| nigelb | so I *won't* do it | 19:20 |
| hggdh | kklimonda: thank you. But I still stand to what I stated earlier -- better to have a PPA with 0.3.1 and newer | 19:20 |
| hggdh | nigelb: I agree. Which means '\' is not the way to go | 19:20 |
| nigelb | next? | 19:21 |
| kklimonda | hggdh: agreed | 19:22 |
| hggdh | joining strings -- either automagically by python, or via "blah" + "blah" | 19:22 |
| nigelb | um, automagically? | 19:23 |
| kklimonda | hggdh: but it may be a tough job - after all we aren't shipping evo 2.30 for a reason. I have no idea how many packages would have to be rebuilt for the new evo/eds support. I may check it later | 19:23 |
| hggdh | kklimonda: the most important reason for *not* ship Evo 2.30 is stability | 19:24 |
| hggdh | Evolution itself is still very unstable at 2.29, and upstream has officially decided they will go out of standard Gnome, and actively support Evo 2.28 for one more year | 19:24 |
| hggdh | and *I* know it from being burned again, and again, and again, on evo 2.29 | 19:25 |
| kklimonda | hggdh: that's because they have rewritten quite a lot of code to get rid of old libraries. That's why I'm wondering if many packages would have to be updated. | 19:26 |
| hggdh | last try I did was just yesterday -- Evo lasted about 2 hours before sigsegv-ing | 19:26 |
| hggdh | oh, yes, I am not even considering ABI/API changes! Adding them in, it will not be fun at all | 19:26 |
| Laibsch1 | hggdh: what does that mean "go out of standard Gnome"? | 19:27 |
| Laibsch1 | pursue a WM-agnostic route? | 19:27 |
| hggdh | Laibsch1: usually gnome will support current and -1 (say, 2.30 and 2.28, as of Lucid shipment) | 19:27 |
| hggdh | which usually translates to one year for past version | 19:28 |
| Laibsch1 | BTW, lp-set-dup crashed about half-way through. Maybe 135 dupes is too much for that script, too. I'll restart the process and see how that goes. | 19:28 |
| hggdh | heh | 19:28 |
| Laibsch1 | so, are they deviating on that policy only? | 19:28 |
| Laibsch1 | or generally moving away from Gnome? | 19:29 |
| hggdh | Laibsch1: so, at this point in time, the *last* upstream release of evo 2.28 would have already been done | 19:29 |
| hggdh | but, given the status of Evo 2.29 (and, consequently, Evo 2.30), Evo upstream has decided they will keep on actively maintaining 2.28 | 19:30 |
| hggdh | for one more year (at least) | 19:30 |
| Laibsch1 | I see | 19:30 |
| Laibsch1 | But 2.28 would still be officially supported currently | 19:30 |
| Laibsch1 | since AFAICT, it currently is -1 | 19:31 |
| hggdh | yes, but no more updated tarballs | 19:31 |
| Laibsch1 | OK | 19:31 |
| hggdh | so if a fix was to be provided for an issue, it would be the distro's function to add the fix in to the last source | 19:31 |
| Laibsch1 | if it's just about how long they will support the current release, then this is not my concern (as a user). I'll entrust that to the experts | 19:31 |
| hggdh | heh | 19:32 |
| hggdh | of which I am *not* one | 19:32 |
| * Laibsch1 can't save the world and rid it from evil all by himself ;-) | 19:32 | |
| === Laibsch1 is now known as Laibsch | ||
| hggdh | but the point, as kklimonda was stating, is that this has impacts everywhere | 19:33 |
| hggdh | nigelb: python will merge strings that continue in many lines: | 19:33 |
| nigelb | hggdh: I give up on correcting the lines issue this time :( | 19:34 |
| hggdh | 'blah' \n 'blah' \n 'blah' \n will be converted in 'blahblahblah' | 19:34 |
| nigelb | my patience is to thin and my fatigue is getting to me head | 19:34 |
| hggdh | nigelb: no worries | 19:34 |
| hggdh | I will get to the code, and give you expamples | 19:35 |
| nigelb | hggdh: http://pastebin.com/d34a2a383 | 19:35 |
| nigelb | save this thing as source_rhythmbox.py in /usr/share/apport/package-hooks/ and run ubuntu-bug rhythmbox | 19:35 |
| nigelb | and just confirm everything works for you. its fine here | 19:36 |
| hggdh | nigelb: will do | 19:36 |
| hggdh | nigelb: BTW -- thank you for your work here | 19:36 |
| nigelb | hggdh: still a long way to go on this one | 19:36 |
| hggdh | may be, but the important point is you *are* on the way | 19:37 |
| nigelb | I should probably adopt this as a personal project, making apport hooks for all commonly used gnome apps by lucid+1 | 19:37 |
| hggdh | if you do that, we will be forever in your debt :-) | 19:38 |
| nigelb | I think its possible.. lemme talk to pitti on monday | 19:38 |
| nigelb | if someone can set a wiki of which package and what info is required from each, I can get to it | 19:38 |
| hggdh | oh, please do not get me wrong. It *is* possible. It *is* the way we should go. It just happens to *also* be a LOT of work. | 19:39 |
| nigelb | we could milestone the beast | 19:40 |
| nigelb | into like 2 release cycles | 19:40 |
| hggdh | and, as we learn more about hooks (and usage) we will also have to adjust the already written hooks | 19:41 |
| hggdh | but this *is* the way to go | 19:41 |
| hggdh | yes | 19:41 |
| nigelb | aiming for next LTS would be the most viable option | 19:41 |
| hggdh | milestoning it, and having people actively working on it would help | 19:41 |
| nigelb | the thing is for each app, I need to know what info is required | 19:42 |
| hggdh | yes | 19:42 |
| hggdh | and this is a problem, since we cannot be experts on everything | 19:42 |
| nigelb | exactly | 19:42 |
| hggdh | but collecting something and then adding/adjusting is also goo | 19:42 |
| hggdh | *good | 19:42 |
| nigelb | yes | 19:42 |
| nigelb | I'll probably start off small with apps I know | 19:43 |
| nigelb | and grow bigger | 19:43 |
| hggdh | and bigge | 19:43 |
| hggdh | and BIGGER | 19:43 |
| kklimonda | nigelb: is test.wav going to be always available? :) | 19:43 |
| hggdh | and suddenly... it is a MONSTER | 19:43 |
| bdrung | to have access to the private ubuntu bug, the membership in ubuntu-bugcontrol is required, right? | 19:44 |
| hggdh | kklimonda: this is one thing we were discussing earlier | 19:44 |
| nigelb | bdrung: or you should be subscribed | 19:44 |
| nigelb | kklimonda: the test file I'm using now will be avaiable in ubuntu and xubuntu | 19:44 |
| nigelb | but we are thinking of generating it live | 19:44 |
| hggdh | bdrung: yes, for some of them (as long as we are subscribed either direct or inderctly) | 19:44 |
| hggdh | bdrung: you have a specific issue in view? | 19:45 |
| kklimonda | nigelb: ach - so it's a sort of placeholder? I see :) | 19:45 |
| nigelb | kklimonda: yep. it will work for ubuntu lucid | 19:45 |
| nigelb | the rest needs to be worked wth guys from main | 19:45 |
| bdrung | there is a upstream dev cleaning our buglist. it would be nice, if he has access to the private ones, too. | 19:45 |
| kklimonda | bdrung: he can ask for -bugcontrol membership | 19:46 |
| kklimonda | bdrung: the requirements for upstream developers and bug triagers are not as strict as for ubuntu volunteers :) | 19:46 |
| kklimonda | I | 19:46 |
| hggdh | bdrung: if he could email bug-control asking for it, and you vouch for her/him, yes, I do not see any issues | 19:46 |
| hggdh | or you could short-circuit it somehow ;-) | 19:47 |
| bdrung | hggdh: and how? | 19:48 |
| nigelb | subsrcribe him to all bugs in that upstream? | 19:48 |
| bdrung | k | 19:49 |
| Laibsch | micahg: Can you please try "lp-set-dup 338217 199592" pastebin the output in case that errors out? | 19:52 |
| micahg | bdrung: https://wiki.ubuntu.com/UbuntuBugControl | 19:52 |
| Laibsch | It seems to permanently choke on the last couple of bugs | 19:52 |
| micahg | Laibsch: what is lp-set-dup? | 19:52 |
| Laibsch | oops | 19:52 |
| Laibsch | Sorry, I meant to talk to hggdh | 19:52 |
| Laibsch | hggdh: ^^^ | 19:53 |
| micahg | Laibsch: that has a lot of bugs...maybe the function should move 10 at a time | 19:53 |
| bdrung | micahg: thx | 19:53 |
| Laibsch | micahg: you mean the script is buggy? | 19:53 |
| Laibsch | I managed to move over about 125 of 135 dupes | 19:54 |
| Laibsch | but now I'm stuck | 19:54 |
| micahg | Laibsch: not necessarily buggy, but could support LP better...maybe 10 to 20 and then wait 5 secs and move more | 19:54 |
| Laibsch | and I wonder if it's due to something cached on my end | 19:54 |
| Laibsch | I waited about 30 minutes | 19:54 |
| micahg | Laibsch: I'm saying between transactions | 19:55 |
| Laibsch | the problem is the script now recognizes there are about 15 dupes left, but does not move them over: http://paste.debian.net/60825/ | 19:56 |
| micahg | it probably tries to move too many at once | 19:56 |
| Laibsch | doesn't seem to have the problem | 19:56 |
| Laibsch | 125 dupes in a single stroke | 19:56 |
| Laibsch | no issue | 19:56 |
| Laibsch | the remaining 15: no go | 19:56 |
| Laibsch | maybe it's because they are marked private? | 19:57 |
| micahg | the problem is in loading the larger one I thinik | 19:57 |
| Laibsch | larger one = 199592? | 19:57 |
| micahg | Laibsch: both are public | 19:57 |
| micahg | Laibsch: no, 338217 | 19:57 |
| Laibsch | 198998 is not | 19:58 |
| Laibsch | and I was wondering if that isn't the issue here | 19:58 |
| Laibsch | maybe it can't redupe private bugs? | 19:58 |
| micahg | Laibsch: if you don't have permissions, that could be a problem | 19:58 |
| Laibsch | I can see them fine | 19:59 |
| Laibsch | and I can redupe them manually | 19:59 |
| Laibsch | micahg: Can you help me out and try to run "lp-set-dup 338217 199592" | 19:59 |
| * micahg didn't know that exists... | 20:00 | |
| Laibsch | nifty little tool! | 20:00 |
| Laibsch | you don't have to have to redupe 135 dupes to another ticket ;-) | 20:00 |
| Laibsch | at least not manually | 20:00 |
| micahg | Laibsch: wfm | 20:01 |
| Laibsch | interesting | 20:01 |
| Laibsch | I'm afraid maybe there is some cruft from the initial crash | 20:01 |
| Laibsch | which may well have been due to the long list of bugs | 20:01 |
| micahg | did the dups and then died | 20:02 |
| micahg | Laibsch: done | 20:02 |
| Laibsch | 199592 is still not a dupe of the other one, though | 20:02 |
| Laibsch | now it is | 20:03 |
| micahg | Laibsch: it is now | 20:03 |
| Laibsch | great | 20:03 |
| Laibsch | thanks | 20:03 |
| Laibsch | at least the work is done | 20:03 |
| Laibsch | Let's see if it ever crops up again | 20:03 |
| micahg | Laibsch: thanks for letting me know about the tool :) | 20:03 |
| Laibsch | gern geschehen | 20:03 |
| Laibsch | 338217 must have one of the most impressive dupe list now ;-) | 20:04 |
| Laibsch | it's longer than the comments on that bug | 20:04 |
| nigelb | bug 338217 | 20:05 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 63) (dups: 210)" [Medium,Confirmed] https://launchpad.net/bugs/338217 | 20:06 |
| hggdh | bdrung: send an email to -control presenting the upstream dev | 20:07 |
| hggdh | or to one of the -control admins | 20:07 |
| nigelb | it is impressive | 20:07 |
| micahg | hggdh: wouldn't it be better for the upstream dev to send the e-mail? | 20:08 |
| Laibsch | an install script is not supposed to touch anything under /home/, right? | 20:08 |
| micahg | Laibsch: depends | 20:12 |
| Laibsch | I was wondering if something a bit more sophisticated, but in essence "for dir in `find /home -name .scim -type d`;do mv $dir $dir.bkp;done" should be called in postinst to deal with this? | 20:14 |
| Laibsch | (I know that script as above has certain issues, it's for illustration only) | 20:14 |
| Laibsch | There does not appear to be any other way known to deal with this legacy problem | 20:15 |
| Laibsch | It's a problem that bites users of older scim version, but not an issue in the current package per se | 20:15 |
| hggdh | micahg: yes, it would. | 20:17 |
| chrisccoulson | vish - i think it might be a coincedence that screensaver inhibiting works for you in VLC (or something else has broken recently) ;) | 20:17 |
| chrisccoulson | there is still a Xorg bug which stops it working | 20:17 |
| vish | chrisccoulson: yeah , not sure how but it works.. maybe the Xorg fix or something.. but it is really weird :s | 20:18 |
| chrisccoulson | vish - the Xorg fix isn't in Ubuntu just yet | 20:18 |
| chrisccoulson | well, not AFAIK anyway | 20:18 |
| vish | chrisccoulson: i'm using xorg-edgers ppa | 20:18 |
| chrisccoulson | vish - oh, it's most likely in that one | 20:19 |
| vish | maybe.. | 20:19 |
| chrisccoulson | the patch was committed upstream a few days ago, so I think it will be in xorg-edgers | 20:19 |
| chrisccoulson | i'll look at including that in Ubuntu this week | 20:19 |
| vish | neat.. | 20:19 |
| Laibsch | If there is somebody who can look at more stack traces to see if they are similar, I'd appreciate it. (bug 274469 - bug 243344 - bug 448091) and (bug 338217 - bug 520947 - bug 474348) | 20:25 |
| nigelb | hggdh: tested hook? | 20:25 |
| ubot4 | Laibsch: Bug 274469 on http://launchpad.net/bugs/274469 is private | 20:25 |
| ubot4 | Launchpad bug 243344 in scim-bridge (Fedora) (and 2 other projects) "scim-bridge crashed with SIGSEGV in scim::IMEngineInstanceBase::get_frontend_data() (affects: 342) (dups: 140)" [Unknown,In progress] https://launchpad.net/bugs/243344 | 20:25 |
| hggdh | nigelb: not yet, got busy elsewhere | 20:25 |
| ubot4 | Laibsch: Bug 448091 on http://launchpad.net/bugs/448091 is private | 20:25 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() - fixed by "rm -Rf ~/.scim/" (affects: 63) (dups: 210)" [Medium,Confirmed] https://launchpad.net/bugs/338217 | 20:25 |
| hggdh | but I will | 20:25 |
| ubot4 | Launchpad bug 520947 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 1)" [Medium,New] https://launchpad.net/bugs/520947 | 20:25 |
| nigelb | hggdh: i will hold of packaging until you confirm | 20:25 |
| hggdh | nigelb: I run it, but I see no gconfdata | 20:33 |
| nigelb | hggdh: um, which option did you select? | 20:33 |
| hggdh | the second one | 20:33 |
| nigelb | the audio? | 20:33 |
| nigelb | hggdh: no sound being heard one? | 20:34 |
| hggdh | yes | 20:34 |
| hggdh | oh, I see now | 20:35 |
| nigelb | it only generates gconf one first option ;) | 20:35 |
| hggdh | yes | 20:35 |
| nigelb | s/one/on | 20:35 |
| nigelb | the sound works perfectly? | 20:35 |
| hggdh | yes | 20:36 |
| hggdh | hum | 20:36 |
| hggdh | my gconf data still shows my home dir | 20:36 |
| nigelb | you wrote the script to mask it :p | 20:36 |
| hggdh | dammit | 20:36 |
| hggdh | will look at it | 20:36 |
| hggdh | now | 20:36 |
| nigelb | hggdh: brb. | 20:43 |
| nigelb | back | 20:50 |
| kklimonda | good lord, evolution just decided to duplicate all my mails in imap.. | 21:01 |
| jpds | Nice. | 21:01 |
| kklimonda | I really try to use it but it doesn't make it easy for me :/ | 21:02 |
| * hggdh feels the pain... | 21:04 | |
| nigelb | hggdh: any luck getting it removed? | 21:05 |
| hggdh | nigelb: no, not yet. Adding some debug statement | 21:05 |
| thekorn | use your backup? | 21:05 |
| nigelb | hm :) | 21:05 |
| nigelb | hggdh: can we move to some place we can see the changes the other makes? | 21:20 |
| radoe | Has someone some reference regarding the policy with packages in main requiering dependencies from universe? | 21:21 |
| === Iyunkateus is now known as aihunkatihys | ||
| jpds | radoe: That's impossible. | 21:26 |
| kklimonda | radoe: their dependencies have to be moved to main | 21:26 |
| radoe | May someone than have a look at bug 525395? | 21:28 |
| ubot4 | Launchpad bug 525395 in backuppc (Debian) (and 1 other project) "Missing dependency to libtime-modules-perl (affects: 2)" [Unknown,Unknown] https://launchpad.net/bugs/525395 | 21:28 |
| === wgrant_ is now known as wgrant | ||
| hggdh | radoe: a Main Inclusion Report has to be submitted against the missing dependency in main | 22:24 |
| hggdh | er, request | 22:25 |
| hggdh | radoe: please see https://wiki.ubuntu.com/MainInclusionProcess | 22:27 |
| persia | nigelb: Sorry, lost getting back to you from my immediate queue. Let me know if you still want to walk through a bug. | 22:41 |
| bcurtiswx | whats that thing i can do to search for a LP persons bug changes... i want to check someone | 22:42 |
| persia | bcurtiswx: There's no feature for that. You can check someone's comments from their LP page. | 22:43 |
| bcurtiswx | it was like a search engine thing.. thx tho persia | 22:43 |
| malev | I need help. Whe you go to: System, preferences, what's the name of the programa that you use to change the theme of gnome? in spanish is "Apariencia" and in english, | 22:44 |
| malev | it should be apearence, but i need to be sure :D | 22:44 |
| bcurtiswx | malev: this is a channel for bugs. Please type /join #ubuntu for general ubuntu questions | 22:44 |
| malev | bcurtiswx, I know! ... it's for a bug reply. don't worry | 22:45 |
| persia | bcurtiswx: Actually, you might be able to review the ML archives for all bugmail. | 22:45 |
| persia | malev: An easy way to get that is to grab the source, and grep for the translation in the .po files. | 22:45 |
| malev | persia, thanks! | 22:46 |
| bcurtiswx | hmm, i guess i struggled with the wording of your sentence there malev | 22:46 |
| hggdh | malev: Preferences/Appearance | 22:47 |
| malev | thanks hggdh!! | 22:48 |
| === tuxmaster is now known as anzenketh | ||
| Laibsch | If there is somebody who can look at more stack traces to see if they are similar, I'd appreciate it. (bug 274469 - bug 243344 - bug 448091) and (bug 338217 - bug 520947 - bug 474348) | 23:10 |
| ubot4 | Laibsch: Bug 274469 on http://launchpad.net/bugs/274469 is private | 23:10 |
| ubot4 | Launchpad bug 243344 in scim-bridge (Fedora) (and 2 other projects) "scim-bridge crashed with SIGSEGV in scim::IMEngineInstanceBase::get_frontend_data() (affects: 342) (dups: 140)" [Unknown,In progress] https://launchpad.net/bugs/243344 | 23:10 |
| ubot4 | Laibsch: Bug 448091 on http://launchpad.net/bugs/448091 is private | 23:10 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() - fixed by "rm -Rf ~/.scim/" (affects: 63) (dups: 210)" [Medium,Confirmed] https://launchpad.net/bugs/338217 | 23:10 |
| ubot4 | Launchpad bug 520947 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() (affects: 1)" [Medium,New] https://launchpad.net/bugs/520947 | 23:10 |
| hggdh | Laibsch: the first three have a different top-of-stack line, but the rest is the same | 23:32 |
| hggdh | so thaey *may* be related | 23:33 |
| * persia checks | 23:33 | |
| Laibsch | hggdh: thanks for taking a look once more | 23:34 |
| Laibsch | How can one be sure they are the same? | 23:34 |
| hggdh | Laibsch: persia is also checking | 23:34 |
| Laibsch | great | 23:34 |
| Laibsch | and are you saying that in fact it's not two groups of bugs (as I was trying to indicate by the (...)), but that in fact it may be one bug for all six tickets? | 23:35 |
| persia | Laibsch: One needs to make sure the same bug is expressed in the same function with essentially the same call parameters. | 23:35 |
| persia | 243344 and 274469 differ by the value of a pointer assignment, and are therefore the same. | 23:35 |
| hggdh | and, since the first three barfed on different functions, one cannot be sure except by following the code and stack | 23:36 |
| hggdh | there you go | 23:36 |
| persia | 448091 is a different bug from these two. | 23:36 |
| persia | Note that this doesn't mean the same patch can't be made to address both (in focus_out), but they need to be separately investigated to know that for sure. | 23:37 |
| hggdh | 338217 and 520947 have the same signature in frames -- look similar to the ones we looked at earlier, and a probably related | 23:37 |
| Laibsch | great | 23:38 |
| Laibsch | thanks | 23:38 |
| hggdh | might be a good idea to prepare a pattern for apport | 23:39 |
| Laibsch | IOW, we have (243344, 274469, 338217, 520947) and 448091 which is as of now, separate | 23:40 |
| hggdh | no | 23:40 |
| persia | No. | 23:40 |
| Laibsch | are you still investigating 474348? | 23:40 |
| hggdh | 338217 and 520947 are related, but different from the others | 23:40 |
| Laibsch | (243344, 274469) (338217, 520947) and 448091 which is as of now, separate? | 23:41 |
| hggdh | yes | 23:41 |
| Laibsch | OK | 23:41 |
| Laibsch | thanks | 23:41 |
| Laibsch | what about 474348? | 23:41 |
| Laibsch | still looking? | 23:41 |
| persia | The sets are (243344, 274469), (448091), (338217,520947), (474248) | 23:41 |
| Laibsch | I see | 23:41 |
| hggdh | what was the ones we looked at earlier that were duplicates with a long line? | 23:41 |
| Laibsch | thanks | 23:41 |
| hggdh | (long line of dups, I mean) | 23:42 |
| persia | 474348 *might* be related to 338217/520947 but we can't tell from available data: we need a clean retrace. | 23:42 |
| * hggdh missed this one | 23:42 | |
| Laibsch | hggdh: bug 338217 | 23:42 |
| ubot4 | Launchpad bug 338217 in scim-bridge (Ubuntu) "scim-bridge crashed with SIGSEGV in scim::Module::unload() - fixed by "rm -Rf ~/.scim/" (affects: 63) (dups: 210)" [Medium,Confirmed] https://launchpad.net/bugs/338217 | 23:42 |
| Laibsch | that's the one you were looking for, right? | 23:43 |
| hggdh | yes ;-) | 23:43 |
| * persia would probably mark 474348 as "Invalid", suggest removing the scim configuration, apologise that we weren't able to get a useful debug trace, and request the submitter to submit another bug if they can reproduce it. | 23:43 | |
| Laibsch | persia: how does one get a clean retrace? | 23:43 |
| Laibsch | persia: I'll do just that | 23:43 |
| persia | Laibsch: For an old bug it's usually impossible. For a fresh crash, just make sure the versions match the version of the ddebs, etc. | 23:44 |
| Laibsch | I see | 23:44 |
| Laibsch | OK, got some bug marking to do now ;-) | 23:44 |
| Anzenketh | Hi new to triage bugs part of the triage process is the duplicate the issue in the appropriate version correct? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!