| bdmurray | I'll leave some bugs for you then. ;) | 00:00 |
|---|---|---|
| hggdh | :-) thanks | 00:00 |
| bdmurray | bug 263533 | 00:04 |
| ubottu | Launchpad bug 263533 in ubuntu "Intrepid: MacBook Pro screen is missing in choose screen system menu" [Undecided,New] https://launchpad.net/bugs/263533 | 00:04 |
| bdmurray | anybody have a guess at what menu they are talking about? | 00:04 |
| hggdh | perhaps hardware choice? | 00:13 |
| bdmurray | it's a mystery to me - could be screen resolution too | 00:14 |
| mrooney | Sorry if slightly off-topic, but does anyone know details of UDS Sponsorship such as who reviews applications (is it a team?), and a general magnitude for how many people are being sponsored? | 00:23 |
| mrooney | Also if there is a better channel I can ask there :) | 00:23 |
| === eddie is now known as Guest51834 | ||
| james_w | mrooney: there will be a few people reviewing the applications | 00:27 |
| james_w | sponsorship is probably of the order of 50 people | 00:27 |
| james_w | maybe not quite that many | 00:27 |
| james_w | though it could all be different this time | 00:27 |
| mrooney | james_w: Okay, I am just trying to get an idea of, if the people reviewing will know me or not, and if I have any chance :) | 00:28 |
| james_w | the people reviewing won't know everyone | 00:29 |
| james_w | but they would ask the relevant people who would know them | 00:29 |
| mrooney | sounds good | 00:30 |
| xteejx | Hi guys, haven't been on here in a LONG time, but can someone have a quick look at LP#:269193 please? | 00:30 |
| mrooney | bug 269193 | 00:30 |
| ubottu | Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 | 00:30 |
| xteejx | ahhh is that the syntax now | 00:30 |
| mrooney | xteejx: :) | 00:31 |
| xteejx | mrooney: thanks :) | 00:31 |
| mrooney | james_w: I have started to get into development a little (I'm a CS major) and was thinking UDS was a great way to really get into the mix | 00:31 |
| james_w | mrooney: it would be | 00:31 |
| james_w | however, lots of people obviously want to go | 00:32 |
| xteejx | I haven't a clue why the wifi is overheating could it be a kernel problem with this particular brand setting the TX power too high causing it to overheat? | 00:32 |
| james_w | it seems like this time there is more emphasis on getting attendees to lead sessions and drive ideas | 00:32 |
| bdmurray | mrooney: is ubotu part of your application? | 00:33 |
| mrooney | bdmurray: hm, I don't think I put it in there, though it's on my wiki which is linked to from my launchpad | 00:34 |
| mrooney | james_w: I know, I'd really love to lead a discussion / present on alternate desktop input schemes | 00:34 |
| bdmurray | mrooney: your plans for it might be interesting | 00:34 |
| mrooney | like new docks and launchers and input paradigms | 00:34 |
| mrooney | bdmurray: that's true, could you recommend an email address to follow up with re: my application? I wanted to include some more stuff, and a brief synopsis of where I think EeeBotu could go would be neat | 00:35 |
| xteejx | Hello again guys... is bug 269193 formatted out ok I tried to get all teh info I could but I didn't know what package to assign it to - kernel or network-manager wasn't sure | 00:51 |
| ubottu | Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 | 00:51 |
| james_w | xteejx: probably kernel | 00:51 |
| xteejx | james_w: Thanks! Is there any way for now I can reduce the tx power to stop it happening as a kinda 'quick fix'? | 00:52 |
| xteejx | If you know...:) | 00:52 |
| james_w | I don't know, sorry | 00:53 |
| xteejx | Ok no problem, does anyone else know how to change the TX power on a wifi card within the terminal as a short-term solution for bug 269193? | 00:54 |
| ubottu | Launchpad bug 269193 in ubuntu "[hardy] Realtek 8187 wifi overheating problems" [Undecided,New] https://launchpad.net/bugs/269193 | 00:54 |
| bdmurray | It might be an option to the kernel module look at 'modinfo modulename' | 00:55 |
| xteejx | bdmurray: OK I'll have a look, thanks :) | 00:55 |
| bdmurray | You could also try Intrepid with a Live CD! :-) | 00:56 |
| xteejx | True, but the problem is the Ubuntu PC is half a mile away and its 12:56am lol | 00:56 |
| bdmurray | that's an interesting predicament | 00:57 |
| bdmurray | you'd probably have to unload and reload the module to be able to set an option | 00:57 |
| xteejx | Hmm, it is...it's actually my partners machine, so I can't get to it. | 00:57 |
| xteejx | How do I do that, sorry I'm a bit rusty... | 00:57 |
| bdmurray | rmmod; modprobe module option | 00:58 |
| xteejx | ahhhh thanks hehe :) | 00:59 |
| xteejx | One question, how do I find out which wifi driver is in use? Sorry | 01:04 |
| bdmurray | look at the output of lsmod and guess? | 01:04 |
| xteejx | thanks! | 01:04 |
| bdmurray | removing the module will drop the wifi connection though | 01:05 |
| xteejx | Its kool I know that one lol I'm not that rusty ;) | 01:05 |
| mrooney | bdmurray: would you mind checking out https://wiki.ubuntu.com/MikeRooney/EeeBotuSpec and seeing if the there are any use cases I missed under subscriptions or if I should change anything? | 01:25 |
| hggdh | mrooney, not that it helps any, but I like it | 01:35 |
| hggdh | although I am not sure how censoring could be enforced | 01:36 |
| hggdh | what about the ability to route bugs to specialised channels (e.g., xorg bugs with its channel, Evolution with its own, etc) | 01:37 |
| mrooney | hggdh: thanks! I thought I covered that in the first bullet point, maybe it wasn't clear | 01:38 |
| hggdh | yes, could be a bit expanded | 01:39 |
| mrooney | hggdh: would you mind doing it? then it can have a different viewpoint! | 01:39 |
| mrooney | by the way, is there anything new I should push to bzr? | 01:39 |
| hggdh | no, not yet (got busy earning a life) | 01:40 |
| hggdh | but I was thinking it might be a good idea to move IRC read to something more complete. With your plan, it now makes a lot of sense | 01:41 |
| hggdh | like twisted-words, for example | 01:41 |
| hggdh | mrooney, darn it! You put me back with my programmer helmet (which I thought I had already retired from) ;-) | 01:41 |
| hggdh | mrooney, you would like t=me to add the text to the wiki? | 01:42 |
| mrooney | hggdh: :) sure if you don't mind, just so it has explanations from two viewpoints | 01:43 |
| mrooney | so more people "get it" | 01:43 |
| hggdh | :-) | 01:43 |
| hggdh | np | 01:43 |
| hggdh | mrooney, first try in. I also added picking up on bugs from other common BTSs | 01:52 |
| Guest51834 | i have a bug for you guys... | 02:07 |
| Guest51834 | how come the font on this page looks so messed up? http://mpt.net.nz/archive/2008/08/01/free-software-usability | 02:08 |
| hggdh | Guest51834, thank you, but I am unsure what this has to do with us. Could you please expand a bit? | 02:10 |
| Guest51834 | sorry, | 02:25 |
| Guest51834 | on my ubuntu systems the font rendering on that page is fubared | 02:26 |
| Guest51834 | on my friends mac it's not | 02:26 |
| Guest51834 | the text looks normal and is readable there | 02:26 |
| Guest51834 | hence, i'm assuming there's a bug somwhere | 02:26 |
| hggdh | Guest51834, the best bet would be to open a bug, describe what browser you use (and its version), your Ubuntu version, and add -- ideally -- screenshots | 02:29 |
| Guest51834 | yeah, been thinking about it but i dont know how to do a bug report | 02:30 |
| hggdh | if you could get screenshots from your friend's mac, it would be even better | 02:30 |
| Guest51834 | it looks the same in both firefox and opera | 02:30 |
| Guest51834 | already have one :) | 02:31 |
| hggdh | go to https://bugs.launchpad.net; also please read https://help.ubuntu.com/community/ReportingBugs | 02:31 |
| === Guest51834 is now known as AbtZ | ||
| AbtZ | too much to read at 3.30 am :( | 02:32 |
| hggdh | on firefox you can use Help/Report a problem to open the bug | 02:32 |
| hggdh | this will add all necessary version information; then it is just attaching the screenshot(s), and -- of course -- describing what happens | 02:33 |
| AbtZ | sweet | 02:33 |
| AbtZ | i forget the name of the font though | 02:34 |
| AbtZ | ah, think it's palatino | 02:35 |
| hggdh | don't worry about it, although you can always use the "view source" of the browser to look for the font | 02:35 |
| AbtZ | what's the html syntax that defines the font to be used? | 02:38 |
| AbtZ | i searched the source for "font", but didn't get any results | 02:38 |
| AbtZ | also, it seems like i can only attach one screenshot? | 02:41 |
| AbtZ | nvm, made a second post | 02:46 |
| AbtZ | https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269226 | 02:46 |
| ubottu | Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,New] | 02:46 |
| hggdh | no, you can attach one file per time | 02:46 |
| AbtZ | there i filed my first bug report | 02:47 |
| hggdh | good. One small step, etc ,etc | 02:48 |
| AbtZ | hehe | 02:48 |
| AbtZ | i can live with that particular page being rendered improperly | 02:48 |
| AbtZ | what i don't like is that the font renders quite well on my snotty friends mac ;) | 02:48 |
| hggdh | if it helps any, mine displays the same thing yours does | 02:49 |
| hggdh | so you are not alone | 02:49 |
| AbtZ | yes, i'm assuming this is an ubuntu/linux problem | 02:50 |
| hggdh | hum | 02:50 |
| hggdh | interesting | 02:50 |
| hggdh | I was playing around on the page, and suddenly my ffox started displaying it extremely nice | 02:51 |
| AbtZ | oh? | 02:52 |
| AbtZ | how did you solve it? | 02:52 |
| hggdh | nah, just a result of mesing around showing style sheets, css, etc | 02:52 |
| hggdh | it is now back to normal (which is to say, ugly) | 02:52 |
| hggdh | but it really seems like the rendering is bad | 02:53 |
| hggdh | ah well. bed calls me now | 02:54 |
| AbtZ | hmm | 02:54 |
| AbtZ | all right | 02:54 |
| AbtZ | thanks for you help | 02:54 |
| AbtZ | hopefully someone who knows takes a look at the report | 02:55 |
| hggdh | AbtZ, lets see if someone with the necessary knowledge looks at it soon | 02:55 |
| hggdh | yes | 02:55 |
| === hggdh is now known as hggdh|away | ||
| AbtZ | g'night | 02:55 |
| hggdh|away | g'night | 02:55 |
| === nhandler_ is now known as nhandler | ||
| === nhandler_ is now known as nhandler | ||
| bcurtiswx | question for bug control: I have confirmed bug 269226 and it appears there is enough information for it to be triaged. I wonder if this is something I can hand off to you guys (to set to triage) or if its something that should be sent upstream (and if so, should I take care of this) | 04:13 |
| ubottu | Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,Confirmed] https://launchpad.net/bugs/269226 | 04:13 |
| mrooney | hmmm | 04:19 |
| bcurtiswx | check through dupes, couldn't find anything | 04:19 |
| greg-g | just so I know, how do you find out what font is being used by Firefox in that case? | 04:20 |
| bcurtiswx | i use firebug to see whats coded into the pages | 04:23 |
| bcurtiswx | but i know theres a program that tells you whats being sent between the server and firefox.. i can't remember it | 04:23 |
| bcurtiswx | that may tell you | 04:23 |
| bcurtiswx | not sure thoug | 04:23 |
| bcurtiswx | h | 04:23 |
| greg-g | thanks bcurtiswx | 04:23 |
| bcurtiswx | np | 04:24 |
| maco | so what's convention when a bug is confirmed but there's not enough info to mark the package? if you ask for info and mark it incomplete, should it be marked off the bug day list to avoid repeating the same bugs, or should it be left alone? | 05:33 |
| mrooney | maco: I think that counts as "hugged" | 05:41 |
| maco | mrooney: ok | 05:43 |
| dholbach | good morning | 05:45 |
| maco | morning...in your area | 05:46 |
| dholbach | maco: I'm not going to say "good morning to you Daniel, hello there techno_freak, good night bdmurray, good afternoon persia, etc" :-) | 05:47 |
| maco | dholbach: mmm? oh sorry, i meant that as a reply "good morning in your time zone" better? | 05:49 |
| dholbach | oh ok, np :-) | 05:49 |
| dholbach | maybe I need some more coffee :) | 05:49 |
| maco | the internet is funny like that | 05:49 |
| maco | there are usually hugday stats showing how many bugs changed over how much time during hug day and whatnot, aren't there? | 06:55 |
| maco | oh wait, i see it on the last one. when do those usually get posted? | 06:56 |
| === dholbach_ is now known as dholbach | ||
| === bdmurray changed the topic of #ubuntu-bugs to: Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | If you have been triaging bugs for a while, please apply to https://launchpad.net/~ubuntu-bugcontrol/ | Want to report a bug? Read https://help.ubuntu.com/community/ReportingBugs | User support (not related to triage) is in #ubuntu | ||
| === BugMaN1 is now known as BugMaN | ||
| === dholbach_ is now known as dholbach | ||
| nullack | Ping seb128 : quick one RE bug 256494 | 09:44 |
| ubottu | Launchpad bug 256494 in compiz "compiz turned on again during update after I had desktop effects turned off" [Undecided,Incomplete] https://launchpad.net/bugs/256494 | 09:44 |
| seb128 | nullack: hi | 09:51 |
| nullack | seb128 Hi mate | 09:51 |
| seb128 | nullack: about your crashes discussion on the list | 09:51 |
| nullack | sure, shoot | 09:51 |
| seb128 | - debug version by default wouldn't work, we could build CDs | 09:51 |
| seb128 | - the apport bugs are automatically retraced using debug symbols | 09:51 |
| nullack | Whats missing in the retrace to see bug squaders then marking it as invalid due to no backtrace? | 09:52 |
| seb128 | see bug #267014 for example | 09:53 |
| ubottu | Launchpad bug 267014 in gconf-editor "gconf-editor crashed with SIGSEGV in gconf_value_copy()" [Medium,Triaged] https://launchpad.net/bugs/267014 | 09:53 |
| seb128 | nullack: sometimes the retracing fails for some reason (versions changed, crash while upload issue, etc) | 09:53 |
| seb128 | not sure why, the debugging toolchain is not trivial | 09:54 |
| seb128 | there is just case or the crashdump doesn't give you a good stacktrace | 09:54 |
| nullack | Yeah, or it might be an optimised compile that cant be | 09:55 |
| seb128 | in some case that a retracer bug, in some case that's gdb not doing a good job, in some case that's there is upload issues | 09:55 |
| seb128 | right | 09:55 |
| seb128 | I'm not sure what issue you try to address there | 09:55 |
| nullack | Basically I see a problem, and Im interested in us trying to identify an easier way for users to respond | 09:55 |
| seb128 | we close bugs which don't have enough informations to be worked on, which seems fair enough | 09:55 |
| nullack | right now they dont, the devs dont get the feedback they need and the problem doesnt get resolved | 09:56 |
| seb128 | let's formulate this way (random numbers for the example) | 09:56 |
| seb128 | ubuntu gets 300 crash report a week | 09:56 |
| pochu | thanks dholbach! | 09:57 |
| seb128 | 260 of those are good and not close | 09:57 |
| seb128 | closed | 09:57 |
| seb128 | we have the manpower to work on 10 of those | 09:57 |
| seb128 | do you think the not-good ones handling is the issue? | 09:58 |
| seb128 | we still have 250 good bugs we don't work on already | 09:58 |
| seb128 | why should we spend effort trying to figure details about the few which are broken if we have plenty of good ones already we could work on | 09:58 |
| nullack | Because your missing one key thing | 09:59 |
| nullack | The user experience and how it is broken should be the determining factor | 09:59 |
| persia | And for a number of the not-good bugs, someone provides hints on how to generate a good bug. One of the annoyances about the crash reporting system is that each new report is a new bug, even when it's just a refreshed report to generate good symbols. | 09:59 |
| seb128 | persia: that's a detail, we can dup easily | 10:00 |
| nullack | The criteria to decide what bug gets worked on shouldnt be driven by complexities with backtraces - it should be about how seriously it effects the user experience | 10:00 |
| seb128 | nullack: right and we consider that | 10:00 |
| nullack | And what I see is these sorts of bugs get reported but dont go anywhere because the users get confused about backtracing and dont provide it | 10:00 |
| seb128 | but a bug which happened one and has no debug information is not worth spending a debugging day | 10:00 |
| seb128 | nullack: well, if we don't have enough informations to work on the bug why should we keep the bug open? | 10:01 |
| nullack | Agreed Sebastien, which is why I am suggesting a debate about what is needed to be done to overcome that | 10:01 |
| seb128 | there is no debate needed | 10:01 |
| nullack | There seems to be ideas that would help the problem | 10:01 |
| seb128 | which ones? | 10:01 |
| nullack | The other two ideas I mentioned in my mail | 10:01 |
| nullack | From the others | 10:02 |
| nullack | Or, my idea, though I think personally the other ideas seem better | 10:02 |
| seb128 | nullack: alright, so | 10:04 |
| seb128 | "tells the user the situation and downloads a debug | 10:04 |
| seb128 | version of the package and waits for it to occur again." | 10:04 |
| seb128 | why? | 10:04 |
| seb128 | the debug retracing happens automatically on the server side | 10:05 |
| nullack | So then why are users being told they have to backtrace it under a debug build? | 10:05 |
| seb128 | nullack: because the crashdump doesn't work for some reason | 10:06 |
| seb128 | there is no garanty that it'll work next time | 10:06 |
| seb128 | could be that gdb doesn't work correctly in this situation | 10:06 |
| nullack | Right, so lets make it easy for them because what I see happening consistently is that the users dont respond and the bug sits there | 10:06 |
| seb128 | those reply are usually a "we don't know why retracing didn't work but it didn't, could you try that in case" | 10:06 |
| nullack | I think we need to more automate the get a debug build thing and help users walk through replication | 10:07 |
| seb128 | they don't sit there, they are closed | 10:07 |
| nullack | Sitting there or being closed the net effect is it isnt resolved :) | 10:07 |
| seb128 | the issue is not the lack of debug build | 10:07 |
| seb128 | it's that gdb doesn't work in all case | 10:08 |
| seb128 | and what do we do in cases where it doesn't work and we have no clue why | 10:08 |
| seb128 | I don't know what is required to get a good stacktrace in some case | 10:09 |
| nullack | I like the idea of sending a user a debug build and capturing the problem, with apport resending the complete backtrace back to the existing bug that didnt have enough info | 10:09 |
| seb128 | but I know the bug is not useful | 10:09 |
| seb128 | what would you do with the bug? | 10:09 |
| seb128 | again we have debug builds | 10:10 |
| seb128 | and user "capturing the problem" would not make a difference | 10:10 |
| Ampelbein | a possible solution could be to have a wikipage for each package which describes what debug-symbols are needed and point the user to it? | 10:10 |
| seb128 | there is case where gdb is just not good at providing what we need | 10:10 |
| seb128 | and we have no better tool | 10:10 |
| seb128 | Ampelbein: again the issue is not the debug symbols | 10:10 |
| seb128 | the question is | 10:11 |
| seb128 | "what do we know when debugging an issue require a way to trigger if for somebody who has real clues" | 10:11 |
| seb128 | it | 10:11 |
| seb128 | gra | 10:12 |
| seb128 | "what do we do when debugging an issue require a way to trigger it for somebody who has real clues" | 10:12 |
| seb128 | there is just cases where automatic or manual gdb use will not give you enough | 10:13 |
| nullack | Can I say, you wont always be able to replicate serious user experience problems in house. | 10:13 |
| Ampelbein | i guess this is experience. when you concentrate on few packages you will learn what the developers need in special cases. | 10:13 |
| persia | Essentially, we need a means by which to verify/analyse the steps required to reproduce. Unfortunately, it's not simple to descrbe these, as there are too many factors involved. | 10:13 |
| nullack | So, then it becomes a matter of giving users tools to diagnose it and send it to people with those clues | 10:13 |
| seb128 | nullack: right, but we don't have the manpower to spend a week on a bug | 10:13 |
| seb128 | nullack: we don't write softwares, we distribute those | 10:14 |
| nullack | seb128 : well I think you would spend a week on a bug if it broke enough users machines seriously enough :) But I understand your point about limited resources | 10:14 |
| seb128 | nullack: it's not our responsability to track tricky upstream bugs | 10:14 |
| nullack | So heres an idea | 10:14 |
| persia | Well, that's arguable. As much as I don't mind closing bugs that aren't useful, I think it's worth tracking all the bugs, and linking upstream. | 10:14 |
| nullack | Maybe the approach is something like "this is technical thing to fix and instruct the user how to go upstream?" | 10:15 |
| elmargol | I think one problem is that ubuntu ships old software. Most issues are solved upstream allready | 10:15 |
| nullack | Right now, users get confused about techno gooble double speak about backtracing | 10:15 |
| seb128 | persia: right, that's a different topic, I often ask people with tricky issue to open a bug on the upstream bug tracker too in case upstream has a better idea about the issue | 10:15 |
| nullack | If Ubuntu cant fix it, why not just be honest to he reported and say go upstream | 10:15 |
| seb128 | nullack: what I just wrote | 10:16 |
| persia | seb128: And you are also incredibly dilligent about passing bugs upstream when they are well described :) | 10:16 |
| nullack | Yes he is | 10:17 |
| seb128 | well, I try to pass bugs upstream when I judge them good enough to be worked | 10:17 |
| nullack | So can I summarise your view point sebastien so Im clear | 10:17 |
| seb128 | my issue is what to do when I know the bug is not good enough to be worked | 10:17 |
| seb128 | nullack: sure | 10:17 |
| nullack | Your saying we shouldnt ask for bracktraces anymore | 10:17 |
| persia | nullack: Part of the issue is defining what "Ubuntu can't fix it" means. Some upstreams are also involved with Ubuntu. There are a number of upstream fixes that come from Ubuntu users. It all depends on who looks at the bug, and how many people who can fix it desire to do so in Ubuntu. | 10:17 |
| nullack | We should ask them to go upstream | 10:17 |
| nullack | Essentially scrap the standard boilerplate backtrace bug squad response | 10:18 |
| seb128 | no, it's not as simple | 10:18 |
| nullack | Ok, please explain | 10:18 |
| seb128 | do you have a bug number example which is an issue for you? | 10:18 |
| nullack | Yep, hang on | 10:19 |
| seb128 | what I'm saying is basically we have | 10:19 |
| seb128 | - bugs which are good and have enough information -> we send those upstream | 10:19 |
| seb128 | - bugs which don't have enough information -> we try to get those informations | 10:19 |
| seb128 | - bugs which might have enough information, that looks upstream issues but where we are not sure what is the issue -> we try to ask users to open those directly upstream where they have a better change to get a reply | 10:21 |
| seb128 | the thing is that a good stacktrace is often enough information | 10:21 |
| seb128 | but in case of tricky bugs debugging often requires interaction with somebody having the issue | 10:22 |
| nullack | seb128 : this bug isnt a serious user experience one but just to give an example : 204272 | 10:22 |
| seb128 | so forwarding doesn't work very well in such cases, that's where we encourage whoever has the issue to open the bug upstream too | 10:22 |
| nullack | bug 204272 | 10:22 |
| ubottu | Launchpad bug 204272 in pulseaudio "totem-gstreamer crashed with SIGSEGV in pa_stream_write()" [High,Confirmed] https://launchpad.net/bugs/204272 | 10:22 |
| seb128 | that's a pulseaudio issue ;-) | 10:22 |
| seb128 | this bug is not closed | 10:23 |
| seb128 | we just have nobody really looking at pulseaudio in ubuntu | 10:23 |
| seb128 | it should be sent upstream by somebody | 10:23 |
| seb128 | preferably by somebody who get the bug and can reply to upstream questions on how to trigger it | 10:23 |
| nullack | Can we go back to the bit about not being able to look at backtraces. | 10:24 |
| seb128 | especially that such bugs might depend of the audio configuration | 10:24 |
| nullack | Maybe the bug squadders need new instructions | 10:24 |
| seb128 | right | 10:24 |
| seb128 | do you have examples? | 10:24 |
| seb128 | easier to comment based on a concrete example | 10:24 |
| persia | nullack: Better instructions are usually good, but it's a matter of getting them right. | 10:24 |
| nullack | yes I had one about totem crashing that had 9 made invalid incomplete I dont have the number of it with me right now | 10:25 |
| seb128 | well, most likely this bug has: | 10:25 |
| seb128 | - no instruction on how to trigger the crash | 10:26 |
| nullack | persia and seb128 : what I see is this boilerplate thing being put about needing backtrace, but now we find that devs like Sebastien are point out that it may not be Ubuntus role to fix it | 10:26 |
| seb128 | - no debug stacktrace | 10:26 |
| seb128 | what do you suggest to do? | 10:26 |
| nullack | I think maybe we should better instruct users about going upstream | 10:26 |
| nullack | Currently they get this response about installing special debug packages, they get confused and they dont do it | 10:27 |
| persia | nullack: In every case where we can't get a stacktrace? | 10:27 |
| persia | nullack: Sometimes the crash isn't an upstream issue at all. | 10:27 |
| nullack | persia : I think only when the trace from apport is no good | 10:27 |
| seb128 | often upstream gets an higher number of crashers that we do and have very low tolerance to incomplete bugs | 10:27 |
| nullack | persia : So how does Seb figure out its not upstream if the backtrace wont tell him what he needs to know? | 10:27 |
| seb128 | at least for GNOME | 10:27 |
| seb128 | I'm fine sending them to bugzilla but the bug will be closed there in a way similar to what we do | 10:28 |
| persia | nullack: OK. I worked a bug on hydrogen a while back. I couldn't get a stacktrace, but I could reproduce. It came from the way hydrogen was patched, and I fixed it. Debian did the same, and fixed it differently. Upstream never had the issue. | 10:28 |
| nullack | Well what does MS do? They seem to get by with a user friendly way of getting the technical details of crashes back to them. | 10:29 |
| nullack | One of the responses to my mail was about that | 10:29 |
| persia | When someone is triaging a bug that is a crash but has no stacktrace, they should try to reproduce, and collect enough information from the developer. In cases where it can't be reproduced reliably, and we have no symbols, it's probably not interesting upstream either. | 10:29 |
| nullack | persia : sometimes I find that apport has given a dump but then it comes back with need a stack trace | 10:30 |
| persia | MS collecting crashes is similar to what we do with apport. As MS doesn't make their bug DB available, we don't know how they triage them once received. | 10:30 |
| persia | nullack: Yep. Sometimes it doesn't work. The solution is probably to improve apport, or try other means to find the bug, not to blindly pass upstream. | 10:30 |
| nullack | persia : I like the sound of that | 10:31 |
| nullack | seb128 and persia : my biggest problem is what I see the current situation to be the user is asked to do stuff they dont know how to do, they dont do it, and the issue goes unresolved | 10:31 |
| nullack | The point of my mail was to explore how this might be fixed given everyone agreed its a problem | 10:33 |
| persia | nullack: Can't really help that. The triager can do it, but if the triager can't reproduce, it may require something special on the submitter's system. | 10:33 |
| seb128 | nullack: there is just no way to investigate some issue without the help of somebody having the issue | 10:34 |
| nullack | Markus has ideas about improving apport to make it easie | 10:34 |
| nullack | *easier | 10:34 |
| nullack | But, the issue then turns too this | 10:34 |
| nullack | Is it worth doing that | 10:34 |
| seb128 | I don't see a real problem in the current system | 10:34 |
| nullack | If devs like Sebastien are too thin on the ground and it should be analysed upstream anyway | 10:34 |
| seb128 | if the user doesn't reply an another will do | 10:35 |
| nullack | Which Ive done, and you and I have gone upstream, but thats rare | 10:35 |
| nullack | seb128 : surely you agree that the current systems hit rate is very low | 10:36 |
| seb128 | "hit rate"? | 10:36 |
| nullack | seb128 : actually getting another back trace back after the user has installed debug packages and compiled with the request for backtrace | 10:36 |
| seb128 | let's say I've enough valid bugs to be busy full week so I'm not looking to invest too much on incomplete bugs | 10:37 |
| seb128 | I just reply using the stock reply | 10:37 |
| RAOF | We've probably got enough reproducible crashes to fix before we try _too_ hard to fix heisenbugs. | 10:37 |
| seb128 | if they can figure how to get extra details good | 10:37 |
| nullack | seb128: So I say again that shouldnt be the case | 10:37 |
| seb128 | if not we close the bug and move on | 10:37 |
| nullack | seb128: The criteria for working on bugs should be how much it effects the user experience | 10:38 |
| nullack | Not the difficulty in debugging | 10:38 |
| seb128 | sure | 10:38 |
| seb128 | we will consider bugs which have lot of duplicates differently | 10:38 |
| seb128 | see bug #252174 | 10:38 |
| ubottu | Launchpad bug 252174 in gvfs "gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch()" [High,Triaged] https://launchpad.net/bugs/252174 | 10:38 |
| seb128 | it has no good stacktrace | 10:38 |
| seb128 | and no detail on how to trigger it | 10:39 |
| persia | nullack: Bugs are ranked in both senses. We want as much *total* user experience as possible, so something that affects 10,000 people and requires an hour to fix is more important than something that affects 20,000 people and takes 10 hours to fix. | 10:39 |
| seb128 | it's a frequent crasher though, I've sent it upstream and it's milestoned | 10:39 |
| nullack | persia : I see, thanks | 10:39 |
| persia | Also, if a developer can't get enough information to fix it, no amount of time will result in a fix. | 10:39 |
| seb128 | nullack: we will investigate bugs which get a dup a week or something | 10:39 |
| seb128 | I'll no put days efforts on something which one user ran into once and which has no detail | 10:40 |
| nullack | seb128 : I think thats fair, but thats not what I am getting at | 10:40 |
| nullack | If the problem cant be replicated by the dev | 10:41 |
| nullack | It seems to me the process of getting a user to replicate it with the required debug package and all the rest is difficult | 10:41 |
| nullack | People have suggested atleast two ways we can improve the process | 10:41 |
| seb128 | which ones? | 10:42 |
| nullack | Markus with changing apport and the other bloke about copying what MS does | 10:42 |
| RAOF | But what MS does appears to be basically a subset of apport. | 10:43 |
| nullack | So lets stick with Markus' idea then | 10:43 |
| persia | Actually, we have no idea what MS does after the upload: it could well be all of apport. | 10:43 |
| seb128 | nullack: changing apport to do what? | 10:44 |
| nullack | seb128 : its in his email and I summarised it in mine | 10:44 |
| RAOF | I'd quite like a "install a dbgsym package for each package in the dependency chain of $PACKAGE" tool; that could be useful. | 10:44 |
| seb128 | nullack: could you summarize it there? | 10:44 |
| RAOF | nullack: It's having a button "install dbgsym package", right? | 10:44 |
| nullack | Yes Chris | 10:44 |
| seb128 | to me it looks like "install debug packages and wait for the crash to happen again" | 10:45 |
| nullack | That too | 10:45 |
| seb128 | what do you think that would bring? | 10:45 |
| seb128 | we have apport-retrace which does that now | 10:45 |
| seb128 | how would that be different? | 10:45 |
| nullack | Well bug squadders are saying in bug reports that its needed | 10:45 |
| nullack | For one, some packages may not be able to be debugged due to compiler options | 10:45 |
| seb128 | no, what they say is "gdb didn't work on your bug for some reason" | 10:46 |
| nullack | So in that case, its needed for a debug compile to diagnose | 10:46 |
| nullack | Seb128: I see them putting the boilerplate do a backtrace message | 10:46 |
| Hobbsee | nullack: sure, but the bugsquadders probably have no idea what they are and arent' supposed to be doing now - there's a lot of obsolete info. | 10:46 |
| seb128 | right, which is a lame way to say "try again, maybe it was a random error" | 10:46 |
| nullack | seb128: can we focus on what you just said | 10:47 |
| seb128 | nullack: ie, an easy way to send those bugs away | 10:47 |
| nullack | seb128: Because what then happens is the user gets confused/afriad to install these types of packages and typically gives up | 10:47 |
| nullack | Thats what I mean about the hit rate being poor | 10:47 |
| seb128 | I use that as "this bug is not useful, I'm too busy to work with you on getting details, read that and try if you figure something or we will close it" | 10:47 |
| seb128 | nullack: right, which is somewhat what I expect to be honest | 10:48 |
| seb128 | that's "either figure by yourself or to make it useful or let's close the bug" reply for me | 10:48 |
| seb128 | s/or/how | 10:48 |
| nullack | I think we need to come up with a better message because thats not what it means to a user that isnt experienced | 10:48 |
| seb128 | I could as well close it as "retracing didn't work, I'm closing the bug, try sending it again next time you get the issue" | 10:49 |
| nullack | To me, that makes more immediate sense | 10:49 |
| nullack | And the benefit is the user isnt left at a quandry about what do next | 10:49 |
| seb128 | and what do we do if the next one is still not better? ;-) | 10:50 |
| nullack | Id like to think in the meantime the community could be encouraged to improve the debugging tools to make real differences there | 10:50 |
| seb128 | right | 10:51 |
| nullack | seb128: its not just you that does the boilerplate response, it happens with others too, so please dont think Im pointing the bone my friend :) | 10:51 |
| seb128 | I know, but other do it for the same reason | 10:51 |
| seb128 | we just don't want to keep useless bugs open | 10:51 |
| nullack | So it seems like we might be able to agree on two points | 10:52 |
| seb128 | but we don't have the resource to spend one day on each bug | 10:52 |
| seb128 | it comes to what you expect from the bug tracker | 10:52 |
| nullack | 1. Debugging tools need to be improved over FOSS and there is limits right now | 10:52 |
| seb128 | either that's a way for user to describe their issues | 10:52 |
| nullack | 2. There should be a change to the boiler plate response to better show the user what the real situation is | 10:53 |
| seb128 | or that's a way for maintainers to work on problems which are described well enough to be worked | 10:53 |
| seb128 | right | 10:53 |
| nullack | persia? RAOF? those two points sound fair? | 10:53 |
| seb128 | I think having a page explaining what the retracing does | 10:54 |
| seb128 | why it doesn't work sometime | 10:54 |
| seb128 | and how similar work can be done manually | 10:54 |
| seb128 | would make sense | 10:54 |
| nullack | As a third item, right | 10:55 |
| seb128 | so we could point user there, they would have something explaining that the retracing didn't work, that we need a proper stacktrace, and how they can get one if they are wanting to do the work required | 10:55 |
| nullack | right, walk them through it to help them not give up | 10:56 |
| nullack | I think a dev would be better drafting the changes than me on that, given the technicalities of the debug | 10:57 |
| persia | nullack: Indeed. Part of it is a cultural shift: many long-term opensource developers are used to bug reports with a high degree of technical information, and so ways of handling bugs have evolved from that. | 10:58 |
| nullack | Thanks guys, Ive got to have dinner shortly. Sebastien can I quickly ask you about bug 256494 | 10:58 |
| ubottu | Launchpad bug 256494 in compiz "compiz turned on again during update after I had desktop effects turned off" [Undecided,Confirmed] https://launchpad.net/bugs/256494 | 10:58 |
| persia | As we build a trained layer of people with sufficient knowledge to prepare an excellent report, but insufficient knowledge to just fix it, and expose the processes to end-users, we'll have a better overall model. | 10:58 |
| nullack | seb128 : Ive confirmed it, compiz gets re enabled each time on reboot | 10:59 |
| nullack | persia : I could help with doco but Im not a dev so the harder debugging techo stuff would need to be done by someone else | 10:59 |
| persia | nullack: Understood. Best to review the docs as they stand, and maybe some of the sessions held in -classroom. | 11:00 |
| nullack | persia : noted Ill take a look | 11:00 |
| seb128 | nullack: I'll have a look, thank you, that's likely a gnome-session issue | 11:00 |
| persia | If you've specific questions about handling apport-generated bugs, I'm probably one of several who could provide more detail in getting from good report to solution. | 11:00 |
| persia | I'm not sure we have much of a body of knowledge about getting from problem to good report. | 11:01 |
| nullack | Yes which is shown with the problem weve been discussing :) | 11:01 |
| persia | Right. There's some good documentation on collecting useful information for debugging problems with Audio, including a couple scripts that users can run to get the right information. | 11:02 |
| === pochu_ is now known as pochu | ||
| persia | Looking for similar opportunities is probably worthwhile, and if you can find some that apply generally, apport can be extended to collect additional information when the bug is submitted, | 11:02 |
| nullack | persia : right, and with Sebastien's idea about walkthrough doco for why backtracing is needed, how to do the debug install etcetc the process can be alot more familiar for people | 11:03 |
| james_w | https://wiki.ubuntu.com/DebuggingProgramCrash | 11:04 |
| persia | Right, which would be good. I've done a couple sessions on how to go from backtrace to solution, for which logs are available on the wiki. | 11:04 |
| persia | james_w: That provides instructions, but not really much narrative or explanation, so is confusing to a first-time reader, unless they are trying to accomplish some specific goal and just need a reference for commands. | 11:05 |
| nullack | james_w The most immediate problem I see with that URL is an Intrepid bug reporter whos been asked to install debugging stuff will look at that and go, Oh, Im on Intrepid I dont know what to do now | 11:05 |
| persia | Anyway, personally, I think turning on apport as described at https://wiki.ubuntu.com/Testing/EnableProposed is generally better than locally installing ddebs. | 11:06 |
| james_w | I hate to say this, but it's a wiki | 11:06 |
| nullack | james_w Yes :) Ive committed to doing some doco | 11:06 |
| persia | Indeed, and from the point of view of the right URL for this information to be collected, that's an ideal link :) | 11:06 |
| nullack | persia : Simplier, and default alpha builds are set that way | 11:07 |
| persia | nullack: Right, but release versions aren't, and if a user is sufficiently willing to follow-up on a crash to try to collect information, apport is probably better than locally installing dbgsyms. | 11:07 |
| nullack | seb128 persia : Im going to dinner now, Ill summarise this discussion and update the discuss list about it | 11:10 |
| seb128 | thanks | 11:10 |
| seb128 | have a good dinner | 11:10 |
| === hggdh|away is now known as hggdh | ||
| === pedro__ is now known as pedro_ | ||
| === _neversfelde is now known as neversfelde | ||
| thekorn | hello bugsquad! | 13:13 |
| hggdh | morning thekorn | 13:18 |
| thekorn | hey hggdh | 13:22 |
| thekorn | james_w, hi, nice screencast! | 13:22 |
| james_w | hi thekorn, thanks | 13:22 |
| thekorn | is extmerge an alias or plugin? | 13:23 |
| james_w | it's a bit long and incoherent I thought | 13:23 |
| james_w | thekorn: plugin | 13:23 |
| james_w | http://erik.bagfors.nu/bzr-plugins/extmerge/ | 13:23 |
| thekorn | ok, cool | 13:23 |
| thekorn | I don't think it's too long, although my vlc shows it's about 50 minutes, | 13:25 |
| thekorn | which seems to be a bug | 13:25 |
| === mvo__ is now known as mvo | ||
| === ConnorImes is now known as Rocket2DMn | ||
| === ogra_ is now known as ogra | ||
| === Jazzva_ is now known as Jazzva | ||
| === mvo__ is now known as mvo | ||
| pochu | bug 269409 | 15:55 |
| ubottu | Launchpad bug 269409 in meta-gnome2 "[intrepid] gnome doesn't start any more." [Medium,Confirmed] https://launchpad.net/bugs/269409 | 15:55 |
| pochu | pedro_: I'm suffering from that too. I've attached my .xsession-errors and a few more logs as you requested. would you mind having a look at it? | 15:56 |
| pedro_ | pochu: i was just looking to it :-P | 15:56 |
| pochu | oh, cool :) | 15:56 |
| pochu | thank you | 15:56 |
| pochu | I think this is the first time I join IRC from a tty :-) | 15:59 |
| persia | I had that a few hours ago, but upgrading again and rebooting restored X for me. Are you sure it's not transient? | 16:06 |
| bddebian | Boo | 16:06 |
| === warp10_ is now known as warp10 | ||
| pochu | persia: I've rebooted into 2.6.27-2 and 2.6.27-3 without success, and the only updated available right now are firefox and jockey | 16:10 |
| persia | pochu: Then I guess my problem and yours might be different. | 16:11 |
| pochu | persia: X starts, gdm loads, but when I try to log in, only the screensaver loads, but nothing else (panel, nautilus, etc) | 16:12 |
| pochu | I can move the mouse but nothing else | 16:12 |
| persia | pochu: Ah. That's different than mine. X didn't start for me. | 16:12 |
| pochu | ok | 16:12 |
| persia | Does it work if you create a new user? | 16:13 |
| pochu | nope, but I've tried to log in into a user which I have (almost) never used | 16:14 |
| pochu | I can try into a new one, let me see | 16:15 |
| pochu | doesn't work either | 16:18 |
| pochu | pedro_: ^^ | 16:19 |
| pedro_ | ouch, the only weird thing i see on the logs are: | 16:19 |
| pedro_ | x-session-manager[6754]: WARNING: Could not launch application 'gnome-panel.desktop': Unable to start application: Failed to execute child process "gnome-panel" (No such file or directory) | 16:19 |
| pedro_ | x-session-manager[6754]: WARNING: Unable to find provider 'nautilus' of required component 'filemanager' | 16:19 |
| pedro_ | pochu: may you check if the gnome-panel.desktop is at the /usr/share/applications/ ? | 16:20 |
| pedro_ | pochu: please have a look to the nautilus one also | 16:22 |
| pochu | sure | 16:22 |
| pochu | pedro_: gnome-panel.desktop is there, but there's no *nautilus* in /usr/share/applications/ | 16:24 |
| pochu | wtf | 16:25 |
| pedro_ | m? it should be there | 16:25 |
| pochu | gnome-panel isn't installed here | 16:25 |
| pochu | just gnome-panel-data | 16:25 |
| pedro_ | wth! | 16:25 |
| pedro_ | do you have your upgrade logs? | 16:26 |
| pedro_ | i wonder why it was removed | 16:26 |
| === CarlFK1 is now known as CarlF1 | ||
| pedro_ | pochu: check if nautilus is installed also, probably isn't | 16:27 |
| pochu | pedro_: dpkg.log is in the bug reprot | 16:27 |
| pochu | report | 16:27 |
| pedro_ | ok cool | 16:27 |
| pochu | it's not either | 16:27 |
| pochu | (nautilus) | 16:27 |
| pedro_ | doh | 16:27 |
| pochu | nor is ubuntu-desktop | 16:27 |
| pochu | I don't remember removing it | 16:27 |
| pochu | perhaps it was update-manager | 16:28 |
| pochu | I've seen bug reports about update-manager removing ubuntu-desktop and essential packages | 16:28 |
| pochu | BTW, I'm enjoying IRC from this tty :) | 16:28 |
| pedro_ | old school heh? :-P | 16:29 |
| pochu | pedro_: do you think it would be ok to mark this as a dup of the update-manager removing packages bug, and raise that one to high or even critical? | 16:30 |
| pedro_ | pochu: yep , high is ok | 16:30 |
| * pochu reinstall ubuntu-desktop | 16:32 | |
| pochu | pedro_: thanks a lot! | 16:32 |
| * pochu hugs pedro_ | 16:32 | |
| pedro_ | you're welcome ;-) | 16:32 |
| * pedro_ hugs pochu back | 16:32 | |
| === asac_ is now known as asac | ||
| === Initial_1 is now known as Initial_M | ||
| mvo__ | pochu: do you remember what bugreport that was? | 17:38 |
| bdmurray | mvo__: Hi! | 17:38 |
| mvo__ | pochu: removing essential package in the "Essential: yes" sense ? | 17:38 |
| mvo__ | hey bdmurray | 17:38 |
| === mvo__ is now known as mvo | ||
| mvo | pochu: aha, you mentioned it on #ubuntu-desktop, thanks | 17:39 |
| bdmurray | mvo: I ran across bug 264181 yesterday and thought it might be interesting | 17:39 |
| ubottu | Launchpad bug 264181 in update-manager "release upgrade for EOL releases fails" [Undecided,New] https://launchpad.net/bugs/264181 | 17:39 |
| mvo | bdmurray: we have a fix to enable update in feisty-proposed, I need to dig out how to verify it so that it can go to -updates | 17:40 |
| bdmurray | mvo: oh, heh - that'll be interesting | 17:41 |
| mvo | bdmurray: ideally we would just keep the releases on releases.ubuntu.com for a bit longer, but apparently space on that server is tight | 17:41 |
| * elkan76 hello everybody! | 17:41 | |
| pochu | mvo: I attached dpkg.log to 269409, let me know if you need any other logs or whatever | 17:42 |
| bdmurray | mvo: also do you work with powernowd or did you just upload it? | 17:43 |
| mvo | bdmurray: I just uploaded it, I think I touched it once or twice, but have no real knowledge about it. why? | 17:45 |
| bdmurray | it looks like there is a simple patch in bug 261608 to add support for a processor | 17:45 |
| ubottu | Launchpad bug 261608 in powernowd "AMD CPU Family 17 not recognized by cpufreq-detect.sh" [Medium,Confirmed] https://launchpad.net/bugs/261608 | 17:45 |
| persia | bdmurray: Unfortunately, it's in the wrong queue to get uploaded. I'll unsubscribe the universe sponsors and subscribe the main sponsors. | 17:48 |
| bdmurray | persia: oh look at that, thanks! | 17:48 |
| persia | bdmurray: Unfortunately, the universe queue is currently long enough that it's not getting the triage it needs, as well as growing. | 17:49 |
| elkan76 | Maybe you can help me. I've a Broadcom 4318 AirForceOne rev.02, and Ubuntu Hardy with kernel 2.6.24-21. I use the b43 module. Today after an update, my wireless drop down, i try to reload the module, but nothing happened. | 17:49 |
| persia | We're working on it, but sometimes things like this slip through the cracks. Please feel free to subscribe the right team if you notice any others. | 17:49 |
| === eddie is now known as Guest67521 | ||
| mcas | hi | 18:18 |
| mcas | i need help with bug 269418 | 18:19 |
| ubottu | Launchpad bug 269418 in base-installer "8.10 installer fails to mount cdrom" [Undecided,New] https://launchpad.net/bugs/269418 | 18:19 |
| mcas | i think it is high importance but i am not sure | 18:19 |
| elkan76 | Did you try the i386 installer?? | 18:21 |
| mcas | no | 18:21 |
| elkan76 | If the bug repeats, you can assume that's is for the project, but if does't, you can think that' is only for this arch. | 18:23 |
| mcas | the unofficial ppc version shows the same problem | 18:25 |
| persia | Importance "Critical" seems appropriate to me, if it's actually present for many users, as that means the alternate CD doesn't work (and the liveCD doesn't work for many use cases). It's worth checking in #ubuntu-testing, as they do a lot of CD image testing, and may have some idea how often it occurs. | 18:26 |
| mcas | persia: thanks i am asking there | 18:29 |
| === bddebian2 is now known as bddebian | ||
| bdmurray | pedro_: ping | 19:06 |
| pedro_ | bdmurray: hello | 19:06 |
| bdmurray | pedro_: Hi, I've noticed that bug 194921 and 203424 are likely and there are dups in gnome's bugzilla too | 19:07 |
| ubottu | Launchpad bug 194921 in evolution-exchange "evolution-exchange-storage crashed with SIGSEGV in soup_message_queue_next()" [Medium,Triaged] https://launchpad.net/bugs/194921 | 19:07 |
| ubottu | Launchpad bug 203424 in evolution-exchange "evolution-exchange-storage crashed with SIGSEGV in soup_message_queue_next()" [Medium,Triaged] https://launchpad.net/bugs/203424 | 19:07 |
| bdmurray | likely dups that is | 19:07 |
| pedro_ | looking | 19:08 |
| === eddie is now known as Guest91702 | ||
| pedro_ | bdmurray: mm not quite sure, but it's indeed crashing at the same function, will look at the upstream backtraces, thanks | 19:16 |
| james_w | bdmurray: hey. Do you think adding a note to the brainstorm part of the standard bug responses clarifying its purpose would be a good idea? | 19:19 |
| bdmurray | james_w: absolutely | 19:25 |
| === philwyett_ is now known as philwyett | ||
| james_w | I had a stab at it: https://wiki.ubuntu.com/Bugs/Responses | 19:42 |
| james_w | improve it if you can | 19:42 |
| pochu | that sounds like a challenge ;) | 19:42 |
| james_w | marnanel: congratulations | 19:57 |
| marnanel | james_w: thanks :) | 19:59 |
| === eddie is now known as Guest38539 | ||
| === ph33ror is now known as pheeror | ||
| bdmurray | james_w: which reply is that? | 20:55 |
| bdmurray | james_w: found it | 20:55 |
| === eddie is now known as Guest37939 | ||
| === norsetto_ is now known as norsetto | ||
| mrooney | well I think bug 269553 might be a good example of what nullack was talking about | 21:38 |
| ubottu | Launchpad bug 269553 in ubuntu "[apport] gnome-panel crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/269553 | 21:38 |
| bcurtiswx | mrooney, did we ever figure out what to do with the bug i mentioned last night? | 21:42 |
| mrooney | can you remind me of the bug? :) | 21:42 |
| bcurtiswx | haha yeah let me get on launchpad, one sec | 21:43 |
| bcurtiswx | 269226 | 21:44 |
| bcurtiswx | bug 269226 | 21:44 |
| ubottu | Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,Confirmed] https://launchpad.net/bugs/269226 | 21:44 |
| mrooney | bug 269226 :) | 21:44 |
| bcurtiswx | haha, i realized i forgot the "bug" just in time | 21:44 |
| bcurtiswx | reading up on the triage how-to i could confirm.. and it appears theres enough information for traige | 21:49 |
| bcurtiswx | but idk if i should subscribe the package manager for bug control to triage or push it upstream | 21:50 |
| bcurtiswx | or even if its a firefox issue.. | 21:51 |
| mrooney | bcurtiswx: yeah, are you sure it is a firefox issue? | 21:55 |
| mrooney | I don't know all that much about fonts in Ubuntu | 21:55 |
| bcurtiswx | i can't say i do either. | 21:56 |
| bdmurray | try using palatino in openoffice.org | 21:58 |
| bcurtiswx | hmm.. good idea | 21:58 |
| mrooney | bdmurray: did you have any comments or suggestions for the use cases I outlined at https://wiki.ubuntu.com/MikeRooney/EeeBotuSpec ? | 21:59 |
| bcurtiswx | open office does this too with the palatino font | 21:59 |
| bcurtiswx | so its not firefox | 21:59 |
| bcurtiswx | so where do I need to traige it to? | 22:00 |
| bcurtiswx | triage* | 22:00 |
| bdmurray | I don't think there is a palatino font as nothing showed up in the list | 22:00 |
| bcurtiswx | just type in palatino | 22:00 |
| bcurtiswx | it works | 22:00 |
| bcurtiswx | so its a font-config issue? | 22:02 |
| bdmurray | I'm really not certain perhaps they'd know in ubuntu-artwork? | 22:03 |
| bcurtiswx | so far that channel is a ghost channel | 22:07 |
| === eddie is now known as Guest12502 | ||
| bdmurray | bcurtiswx: yes, it sounds like fontconfig but I'm getting more information | 22:13 |
| bcurtiswx | im talking to ubuntu-devel too | 22:14 |
| bcurtiswx | will let you know if i get a good answer | 22:14 |
| Ampelbein | any KDE4-user here willing to check on bug 269503 ? | 22:14 |
| ubottu | Launchpad bug 269503 in kdebase-workspace "plasma crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/269503 | 22:14 |
| bcurtiswx | just an FYI, where do i search to see which package the palatino font is a part of | 22:16 |
| bcurtiswx | FMI* actually | 22:16 |
| bcurtiswx | lol | 22:16 |
| bdmurray | palatino isn't installed | 22:17 |
| bcurtiswx | so, should it be by default then? | 22:18 |
| bdmurray | it seems there is a font fallback system and also a fallback font in the css on that web page | 22:20 |
| jibel | bcurtiswx: regarding this bug the fallback (and badly rendered) font is urw palladio | 22:23 |
| jibel | bcurtiswx: the bug affects either pango or freetype but not firefox one for sure | 22:23 |
| bcurtiswx | jibel, thank you! Im guessing freetype is more likely the culprit? | 22:24 |
| bcurtiswx | (as in, who i should assign this bug to?) | 22:25 |
| bdmurray | the bug should be assigned to the gsfonts package | 22:26 |
| bdmurray | as it provides the urw palladio font | 22:26 |
| bcurtiswx | ok, how do you find the package manager to assign this to? | 22:26 |
| bdmurray | bugs shouldn't be assigned to people | 22:27 |
| bcurtiswx | ok, j/w TY! | 22:28 |
| bdmurray | people should assign bugs to themselves when they are going to work on them | 22:28 |
| bcurtiswx | requesting triage for bug 269226 | 22:35 |
| ubottu | Launchpad bug 269226 in gsfonts "Ubuntu fallback font 'urw palladio' is poorly rendered" [Undecided,Confirmed] https://launchpad.net/bugs/269226 | 22:35 |
| Ampelbein | bcurtiswx: done | 22:38 |
| bcurtiswx | Ampelbein, ty! | 22:39 |
| bcurtiswx | bdmurray, how did you find out which package urw palladio belonged to? | 22:49 |
| jibel | bcurtiswx: "fc-match palatino" returns "p052003l.pfb: "URW Palladio L" "Roman"" then "dpkg -S p052003l.pfb" returns gsfonts | 22:55 |
| bcurtiswx | thank you very very much jibel and bdmurray | 22:55 |
| === eddie is now known as Guest93077 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!