[00:37] hi [00:38] is there any way to get a sierra wireless mc8755 wwan hsdpa modem working under 10.4 ? [00:39] 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] We expect the issue to be fixed in Ubuntu 10.4. [00:55] tec: can you see which chipset that is. In a Terminal run: lspci | grep Network [00:55] tec: also please tell us where you found this note [00:56] 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:57] duanedesign: heh. I am not sure this is good or bad ;-) [02:13] hey hggdh [02:13] hggdh: there is one trouble with the hook we wrote. [02:23] nigelb: what gives? [02:24] hggdh: the aplay thing uses a question.wav file [02:24] which is not included in default install [02:24] now I'm wondering whether we can include a small audio test file [02:25] which package carries this .wav? [02:26] qnome-audio (answering myself) [02:27] so, if gnome-audio is part of the standard desktop install, no problem. Otherwise, we will have to discuss this with Seb [02:27] it is not part [02:27] (the file is not there in my system either) [02:28] then we have to discuss it [02:28] ot change the wav [02:28] for example, is there a sound file from rhythmbox we can use? [02:30] example-content is part of the standard install [02:30] But many users remove it, so it may be only of some use. [02:30] nigelb: ^^^see persia's comment [02:32] speech-dispatcher also has some test .wav files, which are very likely to be available. [02:33] oh, anyway nigel quit... we will wait (and I will spend some time with my S.O.) [02:38] Always important to have balance :) [02:51] indeed [03:22] hi, is anybody there? I can't understand this bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/523039 [03:22] 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] it looks as been generated by a machine [03:28] malev: It was machine-generated, but then the reporter added more machine-generated stuff as the "description". [03:28] persia, but hi is not explaining anything about the bug... what can I do to try to reproduce it? [03:31] 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:32] I suspect the reporter believes it to be a kernel bug, but they would do better with `ubuntu-bug linux` for that. [03:32] But it may also be exposing some apport bug: depending on how it was filed. [03:32] persia, so, can I change it to ubuntu-bug linux ? [03:33] Do you have access to the reporter's machine, at the time the error is exposed? [03:34] 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] 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] I don't think there's any benefit to that. There aren't enough kernel-related logs to understand the bug anyway. [03:35] And if the machine in question has been rebooted (likely), it may be impossible to collect them. [03:35] The bug happened at 113061.168817, which is about 30 hours of uptime. [03:35] But the logs only go through about 2 minutes. [03:35] Err, 3 [03:35] * persia fails at math [03:37] guau! it's a lot of information. I'm gonna recommend him to open a new bug. .. [03:39] 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:40] Having a CPU lock up for about 2 hours is unpleasant, but that alone doesn't tell us what happened. [03:40] I'm gonna show you a pastie of my answer, and you help me with it, please [03:42] persia, http://pastie.org/private/fesheyubcv6vfq1yedniaa [03:43] the thing is that I'm not sure what are yout talking about :D [03:43] That's very clear :) [03:43] So, do you understand anything about this bug? [03:44] 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] maybe it's my english :S [03:44] I think there may be some other confusions, and it could as well be my explanations. [03:45] so, do you agree with my answer to the reporter? [03:45] 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] The current response doesn't make any sense to me, as phrased. [03:46] oks! [03:47] So, the bug title looks like a kernel output line to me. [03:47] Try running `dmesg | tail` to see some kernel output lines on your current install. [03:47] looks like the bug's report [03:47] Right. [03:48] So the bug report is probably something from the kernel. [03:48] Which would be the "linux" package. [03:48] Next, let's look at the description. [03:48] 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:49] So I'm guessing the reporter pasted it. [03:49] yes. I supose so [03:50] Scrolling down, the next label is lspci-vnvn.log [03:50] And the output looks like what I get running `lspci -vnvn` [03:50] other paste? [03:50] So I'm guessing it's a similar log. [03:50] I'm just reading the bug report. [03:50] If you scroll down past the dmesg part, there's another section. [03:51] uname-a log [03:51] ? [03:51] That looks like the output of `uname -a` [03:52] I'm unsure where version.log comes from, but it looks like a kernel version to me. [03:52] yes [03:52] Then we have the standard apport stuff, indicating the bug was filed against nautilus. [03:52] and then the apport attachments for nautilus. [03:53] 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] But they mostly look like other apport attachments: nothing appears especially striking to me. [03:54] you're right [03:54] 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] And I suspect that the "Report a bug" menu item was used in nautilus to report the bug. [03:55] nice, [03:55] you're a bug's detective! [03:55] :D [03:55] Now, looking at the bug title, we can see that the issue happened 113061.168817 seconds after boot. [03:55] and that is a long time [03:56] But the attached kernel log only goes up to 188.141010 seconds after boot [03:56] It's a bit more than a day: something like 30-35 hours. [03:56] So we don't have any kernel logs from around the time the problem happened. [03:56] And we don't have any information about what else was happening on the machine. [03:57] that is correct. [03:57] 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] so the report is a bite unusefull? [03:57] Entirely :) [03:57] useless [03:57] 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:58] (well, until the next time the bug was triggered) [03:58] ... but, it's a pity with all the work and enthusiast that the reported put on it :D [03:58] Right. [03:58] 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:59] ... great idea! [03:59] i'm gonna think of a new speach [03:59] 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] or answer [04:00] oks. [04:00] I thought I remembered there being a wiki page about dealing with kernel bugs, but I can't find it :( [04:00] 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:01] there might be and "common responses" in the wiki [04:01] Right. [04:01] So, look around in the wiki. See if you can find the kernel stuff. [04:01] IF you can't, you can maybe invent a response. [04:02] persia, oks! [04:02] 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] I'm going for it [04:02] malev: And this all makes sense now? [04:02] hell yeah! [04:02] thanks! [04:02] Excellent! [04:03] 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] 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:07] you are right === kermiac is now known as kermiac_ [04:28] I'm looking for an upstream report of bug 525128 [04:28] Launchpad bug 525128 in tzdata (Ubuntu) "Australian timezone incorrectly labelled in date output (affects: 1)" [Undecided,New] https://launchpad.net/bugs/525128 [04:29] I think it is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810 [04:29] Debian bug 93810 in tzdata "Australian zoneinfo wrong - should be AEST, not EST" [Wishlist,Open] [04:29] but it may also be bug 149902 [04:29] 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] oops [04:29] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149902 [04:29] Debian bug 149902 in libc6 "date: does not understand some timezones" [Wishlist,Open] [04:29] any thoughts? [04:33] kermiac_: 1st one is closed won't fix [04:33] kermiac_: unless adoption of AEST has grown, it's not likekly to be fixed [04:34] 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] if it is [04:34] otherwise, no point === nhandler_ is now known as nhandler [04:35] micahg: being in australia, I have always referred to it as AEST [04:35] and the 2nd debian bug had (sort of) recent discussion - well, from a year ago [04:35] I don't think it's worth opening another new bug regarding this [04:36] second bug last comment is 2006 [04:36] should I just mark link the 2nd upstream bug & mark the LP bug wontfix? [04:36] kermiac_: no, does everyone now refer to it as AEST in au? [04:36] sorry, I mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810 [04:36] Debian bug 93810 in tzdata "Australian zoneinfo wrong - should be AEST, not EST" [Wishlist,Open] [04:36] last comment is from last year [04:37] as far as I know, I had never heard of "EST" until I started using ubuntu [04:38] kermiac_: http://www.ga.gov.au/bin/gazmap_moonrise [04:40] this is getting strange [04:40] that link is contradicted by http://www.australia.gov.au/about-australia/our-country/time [04:40] kermiac_: well, the debate's been going on for a long time [04:41] tzdata can't be updated until the gov't has consensus [04:41] seems like even my govt can't make up their mind, lol [04:41] true [04:41] kermiac_: maybe you can push for a local solution in au [04:41] then we can get tzdata updated [04:42] 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] so I agree that tzdata can't be changed as it stands now, what should happen with the new LP bug? [04:42] kermiac_: i know the feeling...but that's the only real solution [04:43] hggdh: still around? === kermiac_ is now known as kermiac [04:44] kermiac: I'm leaning towards triage with milestone ubuntu-later and an explanation in the description [04:45] "ubuntu-later"? I've never heard of that type of milestone. [04:45] is it exaclty that? instead of lucid beta 1 (for example) i put in "ubuntu-later"? [04:46] kermiac: yeah, because we're not sure [04:46] kermiac: but I wanted to get another's opinion first === nhandler_ is now known as nhandler [04:46] 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:47] my head is spinning just trying to make sense of the issue atm ;) [04:53] 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] 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:54] 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:55] I'm going to leave that alone for a while as I am going 'round in circles === kermiac is now known as kermiac_ === kermiac_ is now known as kermiac [05:02] Let's not get overly excited about milestoning bugs that have no clear timeframe. [05:02] There's *lots* of those. [05:03] 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] persia: well, it's something that should probably be fixed with no clear timeframe, isn't that what ubuntu-later is for? [05:04] 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] micahg: But *every* crash bug falls into that category, for example. [05:04] persia: yes, but we know this has to be resolved by someone else [05:04] mainly the australian govt [05:05] it should probably be reviewed once a cycle to see if any progress has been made [05:05] I guess. [05:05] But I think it's an upstream problem, more than an Ubuntu issue. [05:05] persia: upstream dismissed it years ago [05:05] We tend to patch tzdata a lot, but most of that is really just upstream changes being backported, etc. [05:06] persia: they won't fix it until the gov't does [05:06] Yes, but if the Australian government takes a decision, upstream will change it. [05:06] right [05:06] And if the Australian government doesn't take a decision, we're not likely to do anything else. [05:06] true [05:06] s/else/either/ [05:06] So I don't see how this is special. [05:07] well, it's for our userbase mainly so they don't feel like we don't care I would think [05:18] 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] 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:19] 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:21] persia: well, I think this is exceptional in that upstream marked won't fix when it's really should be delayed [05:22] That's a fair argument, and you've convinced me. [05:22] 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] 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:27] *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] kermiac: that would be great [05:28] Indeed. [05:29] 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:44] * nigelb curses the power company [05:45] persia: what is the speech-dispatcher you were talking about? (when I got kicked coz I lost my power) [05:45] nigelb: It's a package installed by default in ubuntu-desktop, ubuntu-netbook, and xubuntu-desktop that contains some test .wav files. [05:46] kubuntu? [05:46] nigelb: The example-content is another package that has .wav files that is installed by default (but for fewer flavours). [05:46] when we plan for apport hooks, do we need to think about all the distros or just the ubuntu one? [05:46] How many people run rhythmbox in kubuntu? [05:46] ah [05:47] 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] I dont the example content helps, its in ogg if I'm not mistaken [05:47] In the case of rhythmbox, I think it's safe to provide more limited support for kubuntu. [05:48] So, don't crash if you can't access the .wav file, but use it if it is there. [05:48] good point :) [05:49] any clue where in speech dispatcher these files come into play (I can't find them) [05:49] never mind, got it [05:50] dpkg -L speech-dispatcher :) [05:50] but on the other hand, is it sane to include a test file with rhythmbox for such purposes? [05:51] Adds to the package size, and therefore to the CD size, which reduces the number of applications that can be provided. [05:52] 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] 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] But that's a lot of work, and should be done before FeatureFreeze, so maybe next cycle. [05:53] so, I'll just use the speech synthesizer files for now and plan for this for lucid+1? [05:54] That seems like a reasonable plan. [05:54] thanks :) [05:55] just a doubt though, what does speech-dispatcher do? [05:55] assistive technology? [05:56] Yes. [05:56] cool, so thats why its default package :) [05:56] It's a common interface to all the speech synthesisers, for the speaking desktop. [05:57] Is it possible to write code to record speech and replay back? [05:57] 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] How do you mean? [05:57] like system testing does [05:58] earlier it used beep files, which have gone and made for record-replay [05:59] if that can be done with a hook with less dependencies, then we'd be in luck [06:00] I don't see any reason one couldn't use speech-dispatcher to generate some sound for testing. [06:00] Under the same principles one uses the rest of the accessibility framework for testing other stuff. [06:00] I don't personally know how it would be done. [06:01] hm. that would be added to later milestones ;) [06:02] for now, I'll just get this stuff ready. [06:03] 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] will do on Monday [06:03] I need to talk to pitti about apport too [06:03] 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:04] I want to know if there is a way to make apport reports private by default in certain cases [06:05] I'm sure there is, but it might need some extensions. [06:05] Because un-retraced crash reports end up private. [06:05] Actually, super-private: it's the retracer that makes them normally private. [06:06] there seems to be no way to make non-crash reports private [06:06] apport interface does not provide a way, only the retracer makes them private [06:07] 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] 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] exactly! [06:16] 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:20] kermiac: midnight UTC [06:21] ty micahg :) [06:22] \o/ i overtook echidnaman ;p [06:22] woot! :) [06:23] 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:25] * vish glad ^ .. more happy with micahg's amazing work on tb3 :) [06:25] micahg: when will tb3 replace tb2 in lucid? [06:25] vish: still hasn't been accepted? [06:26] nope :( [06:26] vish: as soon as someone gets it out of NEW I guess [06:27] .. ah will have to wait for NEW [06:40] 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] https://answers.edge.launchpad.net/launchpad/+question/101795 was filed by "Fail2Ban" [06:40] * kermiac shakes his head [06:43] kermiac: i noticed that too [06:43] do you think it is the same person [06:44] and this is some pathetic attempt to look legitemate [06:44] 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] tutinhkhuc05 created his profile and clearly put the name Bongcaivang in the new profile [06:45] but then there was no activity with tutinhkhuc05, it all been with Fail2ban [06:45] yes, if it was the spammer "Bongcaivang" back again, I don't think they would use the same email address [06:46] i figured they were all three the same person? Because it seems odd that Fail2Ban woul have posted that LP Answer [06:47] yes, I tend to agree with you [06:47] frustrating nontheless [06:47] * vish wonders what drives/motivates such people :/ [06:47] i know rye was working on something to make correcting these things easier to fix [06:48] i think you guys talked about it earlier kermiac [06:48] yes, we were discussing it earlier === kermiac is now known as kermiac_ [08:21] micahg: Thanks for the quick bookmark fix. [08:23] wgrant: np [08:23] wgrant: if only all fixes were that easy ;) [08:24] 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:27] wgrant: that's probably something we could've pushed with an update [08:28] but now, we'll get it pushed to Hardy/Jaunty/Karmic when they're backported [08:29] micahg: 3.6 will be pushed to all those? [08:29] wgrant: yes, not sure on exact timetable though [08:29] Aha. [08:30] 3.0 is EOL, so we need to do something [08:30] Indeed. [08:30] I am glad there is a solution now. [08:30] wgrant: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model [08:31] I knew about that, but not that it was to be retroactive. [08:32] wgrant: yeah, we're also backporting xul192 [09:16] om26er: Bug #460286 is not triaged... hasnt been sent upstream [09:16] 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] om26er: or is it an ubuntu specific change? if so you need to mention it [09:17] vish, let me ask that at #empathy [09:17] hmm.. :( [09:17] 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:26] 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:41] https://bugzilla.gnome.org/show_bug.cgi?id=610589 [09:41] Gnome bug 610589 in Notifications "enable notifications when chat is not focused" [Enhancement,Unconfirmed] [09:45] om26er: also mentioning the lp bug# upstream would be good [09:46] ah.. forgot this time [09:46] 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:47] always [09:47] just add a comment with that [09:47] I guess I forget to write the Lp almost every time ;) [09:48] .. once you do it several times it becomes involuntary :) [09:48] true. wish there was a script for that [09:49] in the begining I used to start the bug report with 'originally reported at:" then the description that was silly ;) [09:50] I just add a last line. This bug was originally reported on Ubuntu's bug tracker, launchpad, at --- [09:51] 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] change to fix released [09:51] (I think, your take vish ?) [09:52] you can change it to fix released.. [09:52] vish: om26er: not so sure [09:53] depends if the problem is clearly identified or not [09:53] micahg: we have to locate the exact changelog entry for it then? [09:53] nigelb: idk exact, was teh crash confirmed by anyone? [09:53] 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] thats what even I was told [09:53] from the bug status wiki it says invalid though [09:54] well, if it's a desktop team package, then do what they say, otherwise, I'd say follow the wiki [09:54] https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/458367 [09:54] Launchpad bug 458367 in empathy (Ubuntu) "empathy crashed with SIGSEGV in FcFontSetSort() when some utf characters are sent (affects: 3)" [Medium,Invalid] [09:54] 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] This is true for both Desktop and non-Desktop bugs :) [09:54] ;) [09:55] persia: well, you have no idea if it was that package unless you know what caused it [09:55] om26er: the earlier empathy bug was started for notify-osd... add the empathy details in the bug description [09:56] 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] micahg: exactly the point i made.. or tried to make :) [09:56] 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:57] 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] micahg: i marked a few bugs as invalid.. but seb came behind me and marked the as fix released.. [09:57] persia: right, I'm thinking that maybe we need another status called no longer applies or something... [09:57] (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:58] No, I like "Fix Released" when we know it got fixed. [09:58] vish: like I said, when in the desktop team's packages follow their rules [09:58] righto.. [09:58] persia: that's the real question, was it fixed [09:58] or did it just go away [09:59] Is there a difference? [09:59] persia: their is for backporting fixes [09:59] * vish still thinks if there is no documented fix.. it should be invalid [09:59] micahg: Well, sure, but that's harder. [09:59] what about the many 100s who come to a bug from google and just add comments finding similar problems [10:00] if u mark as fix released, they know it was fixed in a particular update [10:00] (my 2 bits) [10:00] 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:01] (because of library changes, or toolchain changes, or similar) [10:01] \o/ new status... " mysterious fix" ;p [10:01] 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:02] OK, so here's an example of why I disagree (although it's old). [10:02] wxwindows2.4 had a bug that rendered utf8 as garbage. wxwidgets2.6 didn't. [10:03] 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] So, at one point, the command was changed. Packages that built after that suddenly worked. [10:03] Packages built before that didn't. [10:04] For the packages that got uploaded for some other reason, nobody did anything special to fix the bug. [10:04] For the packages that still had the bug when there were only a few left, someone specifically fixed it for the leftovers. [10:04] which futher tilts the discussion towards ambiguity. I guess we have to make a call on each bug based on situation [10:04] persia: well, you're saying through process of elimination, the one and only change was the version of this pacakge [10:04] But I still think the bug was "Fix Released" for the ones where the fix was accidental. [10:05] 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] oh, you're saying people marked packages built against it fix released? [10:05] 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:06] micahg: Right, because the bug was fixed, even though the rebuild happened for another reason. [10:06] And I think people were *correct* to mark it that way, even though the fix was accidental. [10:06] persia: right, but that's definitely a case where the bug isn't in that package [10:07] they should have all been marked as fix released in wxwidgets2.6 [10:07] but we cant really track this^ :( [10:07] and invalid in the original package [10:07] No, because when the change happened in wxwidgets2.6, there were still about 40 packages that had the problem. [10:07] And the bug in wxwidgets *was* marked fixed. [10:07] persia: hmm.... [10:07] And when the list got down to about 10, the last ones were pushed just before release, fixing the bug. [10:08] This happens all the time, and the developers have the "NBS" list they use to track some of the transitions. [10:08] persia: yeah, I guess you're right here [10:08] I'm doing something similar for xul192... [10:08] But usually a goodly chunk of any of the transitions happens by accident, just through uploads of other bugfixes. [10:09] 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:10] On the other hand, if we can't reliably replicate a bug, and it magically goes away, I agree "Invalid" is better. [10:10] persia: but "fix released" seems that something specific was done to fix the bug.. we could rather use a better status, [resolved ???] [10:10] vish: +1 to that suggestion [10:11] persia: yeah, that does make sense... [10:11] but that would add a whole lof ambuigity [10:11] 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] +1 ^ [10:11] +1 [10:11] persia: that would be _the_ best way to track fixes.. [10:12]