[00:04] <bdmurray> jgoguen: doesn't everything lose data when you hd is full?
[00:04] <bdmurray> jgoguen: okay, I read the report ;-)
[00:05] <jgoguen> bdmurray: not everything gets data corruption when the HDD is full though, and the interactive things should allow you to save elsewhere
[00:05] <jgoguen> bdmurray: admittedly, thunderbird isn't interactive that way :) and I don't know what else it could do for POP3...
[00:06] <bdmurray> it'd be good to test it in Jaunty
[00:07] <jgoguen> bdmurray: ok...do you think High is right then?  When I get a chance, I'll create a Thunderbird profile on a nearly-full partition and see if I can reproduce
[00:07] <bdmurray> jgoguen: yes, at least high
[00:08] <jgoguen> Critical if it still exists?
[00:08] <bdmurray> jgoguen: perhaps
[00:09] <jgoguen> bdmurray: ok...I'm going to an exam in a bit, I'll come ask about it once I get a chance to test and see just what happens
[00:11] <bdmurray> jgoguen: oh, if its not fixed upstream its unlikely to be fixed in Jaunty ;-)
[00:11]  * jgoguen looks again
[00:11] <jgoguen> heh :)
[00:13] <jgoguen> wonder if it's been fixed in Thunderbird 3 since Jan 11...I've seen at least one other bug, either there or in GNOME, that's fixed but not marked fixed
[00:14] <bdmurray> Yeah, it would be good to know for sure
[00:14] <jgoguen> is there a PPA for Thunderbird 3 builds?  it's failing for me right now, apparently GCC doesn't follow the C++ standard for temporary object destruction...
[00:14] <jgoguen> as of gcc-4.3
[00:16] <bdmurray> The mozillateam does not have one
[00:17] <jgoguen> ok...I have to run now, either late tonight when I get home or sometime tomorrow I'll install gcc 4.2 and compile Thunderbird 3 and test
[00:49] <bdmurray> Does anybody hear the logout sound? bug 253763
[00:50] <dtchen> i thought a decision was made to not play any logout sound
[00:50] <dtchen> IIRC, part of the TearDown spec?
[00:55] <bdmurray> I don't see anything in that spec
[05:19] <dtchen> bdmurray: i don't know offhand if the logout sound is *supposed* to be played. perhaps one of keybuk, pitti, or mdz would know.
[06:49] <YoBoY> good morning
[09:09] <davmor2> Guys is there anywhere special to report translation bug to or is it just on the normal ubuntu bug tracker
[09:14] <YoBoY> davmor2: better to go to the translation page of the package to make your proposition of correction and send a mail to the maintener of the translation
[09:15] <davmor2> YoBoY: thanks
[09:43] <efraser> Hello guys
[09:44] <efraser> I've got a bug when using dual head DVI on a dell docking station with a Dell Lattitude E4300, but I'm not sure what to file the bug against.
[09:44] <efraser> Or to search against.
[09:46] <efraser> Basically xrandr is messing up when it configures the monitors when you login.
[09:56] <efraser> nm, I've found the guides on reporting bugs.
[09:56] <YoBoY> efraser: hi, you can beggin your jorney by reading this page https://wiki.ubuntu.com/X/Debugging
[09:56] <efraser> cheers, that's what I'm doing :)
[10:07] <james_w> it's bug day today people! https://wiki.ubuntu.com/UbuntuBugDay/20090409
[10:07] <james_w> feel free to ask about anything you are unsure about how to deal with
[10:08] <james_w> the idea today is to do two things, remove the "patch" flag from attachments that aren't patches so the flag becomes more useful
[10:09] <james_w> and to move the patches that are there closer to being integrated in to the package, so that we can fix bugs or add features.
[10:34] <efraser> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/358315
[10:35] <efraser> Yeah, thats me.
[10:35] <efraser> I'm not troubled by the bug really, but it has been there since I started using Jaunty, so I figure I should report it before jaunty goes live.
[10:36] <miki4242> hi all, should a debdiff always include a new changelog entry describing the fix?
[10:40] <miki4242> example in Bugs/Patches on wiki doesn't have one
[10:41] <TheHobbit> hi
[10:42] <TheHobbit> I'm working on bug 321688. The bug could be better solved by upgrading the package to the new upstream release, should I?
[11:24] <TheHobbit> hmmm I need some clarification on policy.... The bug I'm hugging now is solved upstream in a new release. Moreover, jaunty already has the new release solving the bug, thus the problem only stays for intrepid...
[11:25] <TheHobbit> what is the right thing to do? bring the new release in intrepid or patch the old one?
[11:25] <james_w> miki4242: a debdiff should generally, yes
[11:26] <miki4242> thanks
[11:26] <james_w> miki4242: it's not usually crucial, but having it makes proper attribution easier
[11:28] <miki4242> ok.
[11:29] <james_w> TheHobbit: hi, I don't see the reference in the upstream changelog, which version fixes it?
[11:30] <miki4242> after lunch i'll work on espeak/portaudio bugs which are quite a problem for accessible ubuntu. any help greatly appreciated.
[11:31] <TheHobbit> james_w: I did not download all the releases, but 0.77 has it cleaned... The fact that is not in the changelog does not surprise me...
[11:31] <james_w> why's that?
[11:31] <TheHobbit> is such a blunder, I wouldn't like to have it remembered each time someone opens the changelog:D
[11:32] <james_w> ok, I see it now
[11:33] <james_w> so, as this is fixed in Jaunty it should be marked "Fix Released"
[11:33] <TheHobbit> ok, but what for intrepid?
[11:33] <james_w> but we know this affects Intrepid, so we should decide whether it is appropriate to fix there
[11:34] <james_w> we need to weigh up the impact of the problem, against the potential for regression
[11:34] <TheHobbit> ok, I just found it
[11:34] <TheHobbit> is solved in release 0.67 of the upstream package
[11:34] <james_w> cool, thanks
[11:35] <TheHobbit> that is just the release after the one that is in intrepid
[11:35] <TheHobbit> I do not think that upgrading to 0.67 should pose any regression problems... just a sec
[11:35] <james_w> there seems to be little potential for regression, except that something may be relying on the fact that it only accepts odd numbers of arguments
[11:36] <james_w> we can check what packages depend on that one using "apt-cache rdepends"
[11:36] <james_w> so there are a few
[11:41] <TheHobbit> yes, so there are... I'm looking for changes in the 0.67 wrt 0.66
[11:43] <TheHobbit> hu?
[11:44] <TheHobbit> in the 0.66 version on cpan there is no bug!!!!
[11:45] <TheHobbit> either the developper put on cpan two 0.66 versions, or the matainer had a problem somewhere
[11:48] <james_w> I can't see it in the Intrepid version either
[11:49] <TheHobbit> mee too, I'm sorry, I was wrong
[11:49] <TheHobbit> :(
[11:49] <james_w> it was fixed in ubuntu with the upload of 0.62-1
[11:50] <TheHobbit> yes, i saw
[11:50] <TheHobbit> i'm correctin my blunder
[11:50] <james_w> dapper, gutsy and hardy are then affected, but nothing after
[11:51] <TheHobbit> thus? should be 'confirmed'?
[11:51] <james_w> nope, still "Fix Released"
[11:51] <james_w> the status tracks the development release
[11:52] <james_w> we can add a bug task for earlier releases if we want to fix it there
[11:52] <TheHobbit> hmmm
[11:53] <TheHobbit> if someone ask for it...
[11:56] <TheHobbit> I'm closing it on the hugday page too
[11:58] <TheHobbit> well, a closed bug before lunch, and after I'll tag another;)
[11:58] <TheHobbit> at least being unemployed will produce something
[11:58] <TheHobbit> see you later
[13:55] <TheHobbit> hi
[14:07] <TheHobbit> I'm looking into bug 176862, proble is: the patch attached is a diff against the whole tree, almost a debdiff, for a old release of the package
[14:08] <TheHobbit> moreover the package has no patches for now, so I should choose a patch handler (I'm only familiar with dpatch,,,,)
[14:10] <james_w> TheHobbit: that patch appears to be a debdiff to me
[14:10] <TheHobbit> yes, but against an old release
[14:10] <james_w> when there is no patch system already then we typically do not add one for packages which originate from Debian
[14:10] <james_w> ah
[14:11] <TheHobbit> moreover, I thought that patches should be in the debian/patches, not idden in the diff.gz
[14:11] <TheHobbit> +h
[14:12] <james_w> that's what I was saying
[14:12] <TheHobbit> I have some doubt about the patch, by the way....
[14:12] <james_w> if there is no patch system already then we don't generally add one, as that can cause issues with merging from Debian
[14:12] <TheHobbit> it solves the proiblem yes
[14:12] <james_w> so in this case it would be ok
[14:12] <TheHobbit> but only for english speaking people:D
[14:13] <james_w> also, it's only a tiny bit old, so it should be easy to update it to apply to the new version
[14:13] <james_w> heh :-)
[14:13] <TheHobbit> yes it is easy, just modify the files :)
[14:14] <TheHobbit> debian has a related bug, #167339
[14:14] <TheHobbit> which asks for displaying the country codes too
[14:15] <TheHobbit> anyhow, I can adapt the patch and upload a debdiff against current release
[14:15] <TheHobbit> should I?
[14:15] <james_w> that would be great
[14:15] <james_w> also, if you could forward it to Debian it would be even better
[14:15] <james_w> it appears the author is also the Debian maintainer, so it's two birds with one stone doing that
[14:15] <TheHobbit> what? the debdiff or the bug report? or both?
[14:16] <james_w> both please
[14:16] <TheHobbit> hmmm I'll be back for direction about how to do it...
[14:16] <james_w> plus, adding the note about the sponsors to the Ubuntu bug so that the reporter might know about that next time would be triple good
[14:16] <TheHobbit> who's the sponsor?
[14:17] <hggdh> what should be done on patches that change Makefile.am?
[14:17] <james_w> TheHobbit: the sponsors team
[14:18] <james_w> ah, I thought that was on the Bugs/Patches page
[14:18] <james_w> hggdh: they are tricky. It sometimes depends on the package
[14:19] <james_w> hggdh: generally though a sponsor should be able to do the necessary things with it, as it is often easier for them to do it themselves than review a patch that includes autotools changes.
[14:19] <TheHobbit> you mean subscribing the ubuntu-(main|universe)-sponsors to the bug james_w ?
[14:19] <hggdh> james_w, yes... I would really not need to run autotools in the build
[14:19] <james_w> hggdh: mentioning that "Makefile.am" is changed along with the patch would be good though
[14:19] <james_w> hggdh: plus, check debian/rules, some packages already run it there
[14:20] <hggdh> james_w, thanks
[14:20] <james_w> TheHobbit: yeah, but also add a comment explaining that that is what you are doing, and that if they attach a patch they should do the same thing
[14:20] <TheHobbit> I'll do it...
[14:20] <james_w> thank you
[14:21] <TheHobbit> is universe by the way in this case
[14:21] <TheHobbit> I'll be back
[14:28] <TheHobbit> hu..... being an ubuntu patch, should I change debian/control too?
[14:29] <savvas> TheHobbit: update-maintainer usually does the trick :)
[14:29] <TheHobbit> savvas: thanks...
[14:30] <savvas> np
[14:30] <TheHobbit> sorry, but I'm new to this game:D
[14:47] <TheHobbit> hmmm something does not work as expected...
[14:47] <TheHobbit> must dwell a litle bit deeper
[14:55] <TheHobbit> apparently the patch is not enough.... :s
[15:09]  * TheHobbit kicks himself in the ass.... stupid stupid stupid:D
[15:11] <bddebian> Boo
[15:12] <BUGabundo> foo
[15:14] <TheHobbit> ok, now I have the right debdiff... I'm going to do the amministrative work, only I would like to know how to notify debian (And upstream being the same...)
[15:22] <TheHobbit> by the way....
[15:22] <TheHobbit> having posted a debdiff, should I set the status to fix-released or something? Or should it stay 'confirmed'?
[15:23] <james_w> confirmed is fine
[15:23] <james_w> having the sponsors subscribed is the important bit
[15:23] <TheHobbit> that's done
[15:23] <james_w> and not closing the bug, so "Fix Released" would actually be bad
[15:23] <james_w> cool :-)
[15:24] <TheHobbit> now about notifying upstream...?
[15:24] <james_w> and https://wiki.ubuntu.com/Debian/Bugs should help with forwarding to Debian
[15:26] <TheHobbit> reading it....
[15:42] <TheHobbit> just a question.... when it is said that the debdiff generated by submittodebian can be edited, is to remove specific ubuntu things? Like the update-mainatiner thing?
[15:51] <james_w> exactly
[15:57] <bdmurray> james_w: How's it going?
[15:58] <james_w> hey bdmurray
[15:58] <james_w> pretty good, how are you?
[15:58] <bdmurray> good, I was looking at bug 176862 which TheHobbit was working and part of the changelog has been modified is that alright?
[15:59] <TheHobbit> bdmurray: modified by me you mean?
[16:00] <bdmurray> TheHobbit: yeah the removed obsolete variables from changelog bit
[16:00] <TheHobbit> hu....
[16:00] <TheHobbit> that was the Local variable part
[16:00] <TheHobbit> I could add them again...
[16:01] <TheHobbit> :)
[16:01] <bdmurray> TheHobbit: right, I'm not sure modifying the changelog is the right thing to do and wanted to check w/ someone else
[16:01] <bdmurray> I mean its not worth carrying a diff from Debian for
[16:02] <TheHobbit> I was asking myself the same thing...
[16:03] <TheHobbit> bdmurray: I'll wait to notify upstream then....
[16:04] <TheHobbit> these variables are mode setting for some text editor or other I think
[16:07] <bdmurray> james_w: ?
[16:07] <james_w> yeah, harmless, but discouraged
[16:07] <james_w> if there's no effect on the package then it's not worth diverging from Debian
[16:07] <TheHobbit> thus I'm back to generate a debdiff then..
[16:08] <TheHobbit> ok, learning is made through doing the wrong thing and starting over
[16:08] <TheHobbit> as my grandmother was fond to say
[16:08] <james_w> indeed :-)
[16:09] <exosyst> Can anyone verify some odd behaviour after the last intrepid update?
[16:09] <bdmurray> james_w: once he's got that done what do we need to do to get it in?
[16:10] <james_w> at the moment it would need motu-release approval
[16:31] <thekorn> woohoo, happy hugday everybody ;)
[16:31] <TheHobbit> ok, now the debdiff is minimal........
[16:31] <TheHobbit> should I notify upstream?
[16:34] <TheHobbit> james_w: ?
[16:38] <TheHobbit> must go...
[16:38] <bdmurray> TheHobbit: Thanks for helping out!
[16:39] <TheHobbit> bdmurray: no problem:)
[16:39] <TheHobbit> 'till next week I've time
[17:00] <bdmurray> james_w: I've a question about the patch tagging guidelines
[17:00] <james_w> shoot
[17:01] <bdmurray> So in a dpatch patch it says:
[17:01] <bdmurray> ## All lines beginning with `## DP:' are a description of the patch.
[17:01] <bdmurray> So is ## DP: Ubuntu: url appropriate?
[17:03] <james_w> I think so, yes
[17:09] <bdmurray> james_w: okay, I wasn't sure if it was redundant.  Is there somebody else to checkw with I'd like to update the wiki page too
[17:14] <james_w> bdmurray: I'm not sure that there is
[17:14] <james_w> I think the DP: lines are there to mark the description so that tools could parse them out
[17:15] <james_w> I don't see why the links shouldn't be part of the description, their valuable information
[17:15] <bdmurray> My question was whether or not is should be ## DP: Ubuntu: url vs ## Ubuntu: url
[17:21] <james_w> yeah
[17:21] <bdmurray> Can anybody recreate bug 346474?  I can't on Jaunty
[17:23] <Pici> bdmurray: I cannot either.
[17:23] <bdmurray> okay the source code looks a bit different too
[18:36] <HammerHead66> can anyone help me with the BugDay/Tools this is my first time and I'm vary new to Linux
[18:37] <HammerHead66> I get this error when installing it E: Couldn't find package ubuntu-qa-tools
[18:38] <bdmurray> HammerHead66: what release are you on?
[18:39] <HammerHead66> 8.04 64bit Gnome
[18:39] <bdmurray> And where did you find the bugday tools?
[18:40] <HammerHead66> https://wiki.ubuntu.com/UbuntuBugDay/Tools       ran it in terminal   "sudo apt-get install ubuntu-qa-tools"
[18:40] <bdmurray> ah, okay ubuntu-qa-tools is only available in Jaunty
[18:41] <HammerHead66> lol ok that's why it won't work.
[18:42] <HammerHead66> so those tools are only for jaunty do they have any tolls for 8.04?
[18:42] <HammerHead66> *tools
[18:43] <bdmurray> the tools will work in Hardy its just a bit harder to set them up
[18:51] <HammerHead66> ﻿bdmurray: I'll try if your willing to help me
[18:54] <bdmurray> HammerHead66: You don't really *need* the tools to particpate your time might be better spent participating rather than setting up tools.
[18:54] <HammerHead66> ok
[19:40] <efefppo> Has the google calendar bug in evoluition been fixed?
[19:51] <bdmurray> Can anybody recreate bug 342332?
[19:51] <bdmurray> I'm having a hard time of it
[20:17] <imachine> helllo!
[20:17] <imachine> http://paste.ubuntu.com/147849/ <-nvidia 71 fails to build @ 8.10
[20:17] <imachine> any ideas?
[20:44] <HammerHead66> ﻿imachine: see im
[20:45] <imachine> HammerHead66, that was a bunch of bloat I couldn't see through sorry
[20:45] <imachine> irssi doesn't autocreate chat windows for me
[20:46] <imachine> HammerHead66, also, I don't think it has to do with any of that. it looks upstream.
[20:46] <imachine> first it couldn't find semaphore.h (looked in asm/), I symlinked it from linux/
[20:46] <imachine> then it just failed
[20:46] <imachine> http://paste.ubuntu.com/147849/
[20:46] <imachine> like this
[20:54] <HammerHead66>  ﻿imachine:    ERROR: Kernel configuration is invalid."; this is the error you are getting so it has to do with drivers... at lest that's what I think. But I may be wrong
[20:58] <imachine> HammerHead66, you get that with every driver build through DKMS, at least with the other ones that work noprobs.
[20:58] <imachine> it's a standard error one can somewhat ignore.
[20:59] <HammerHead66> I don't have it on mine
[20:59] <imachine> nvidia setup just seems to be overly cautious.
[20:59] <imachine> explain
[20:59] <imachine> what version of nvidia do you run?
[20:59] <HammerHead66> did you try what I im you?
[20:59] <imachine> send it again please
[21:00] <imachine> it went out all rubbish since irssi doesn't auto-open im windows here for me.
[21:00] <imachine> I've opened a query now
[21:00] <imachine> right
[21:00] <imachine> :-)
[21:01] <imachine> dude what you wrote is for ati
[21:01] <imachine> what the hel
[21:01] <HammerHead66> did it work?
[21:01] <imachine> it's for another card.
[21:02] <HammerHead66> it will work for all cards
[21:02]  * imachine fails
[21:02] <imachine> riiight;
[21:02] <imachine> anyone else?
[21:04] <HammerHead66> if you don't try it your just showing how much you don't want to  try something that someone is giving you that will work I hope you get it all worked out
[21:06] <imachine> cheers
[21:09] <IntuitiveNipple> imachine: just looked at your original pastebin report. Where did the dkms package come from?
[22:11] <imachine> IntuitiveNipple, apt
[22:11] <imachine> IntuitiveNipple, it's standard package from apt.
[22:11] <imachine> 8,10
[22:15] <imachine> IntuitiveNipple, I did dpkg-reconfigure nvidia-71-kernel-source or whatever it's called
[22:15] <imachine> and during dkms module build, it failed.
[22:16] <imachine> I think it's upstream, since it fails to build with nvidia-installer with .run file from NVIDIA.com
[22:16] <imachine> I can provide that debug as well
[22:16] <imachine> but not now since that pc is off and people sleep in the same room it's in
[22:16] <IntuitiveNipple> imachine: There are plenty of reports about that issue from a Google search. It seems the problem is the kernel changed the definition of some functions and Nvidia didn't update some driver packages
[22:17] <imachine> yes, very likely
[22:17] <imachine> like I said, it's upstream 99$
[22:17] <imachine> 99%
[22:17] <imachine> tho, it's a bug nonetheless and should be reported, so that it at least gets marked as upstream/won't fix
[22:17] <imachine> :-)
[22:17] <imachine> I'll browse laucnhpad later for it; the bigger problem is that nvidia 96 which should work is broken.
[22:18] <imachine> it displays RGB not as RGB but as GBR
[22:18] <imachine> ;p
[22:20] <IntuitiveNipple> This may help: http://www.nvnews.net/vbulletin/showthread.php?t=120971
[22:20] <IntuitiveNipple> what video chip-set is that?
[22:21] <imachine> gf3 ti
[22:22] <IntuitiveNipple> 96.x.x displays as GBR?
[22:23] <imachine> yes
[22:23] <imachine> on DVI
[22:23] <imachine> works fine on VGA
[22:24] <imachine> it's a known issue
[22:24] <imachine> http://www.nvnews.net/vbulletin/showthread.php?t=106496
[22:25] <imachine> that's what I have
[22:25] <imachine> seems it's not just GF3
[22:25] <imachine> I'd gladly use 71x
[22:25] <imachine> but they fail to build :)
[22:25] <IntuitiveNipple> What's connected to the DVI?
[22:31] <imachine> a monitor
[22:31] <imachine> 20" dell
[22:32] <imachine> works fine on window$
[22:32] <imachine> works fine with nv on linux
[22:32] <IntuitiveNipple> I was wondering if the nvidia xorg.conf EDID over-rides might help so you can set the parameters manually
[22:33] <imachine> what might help me is turning off VGA
[22:34] <IntuitiveNipple> ftp://download.nvidia.com/XFree86/Linux-x86/96.43.11/README/appendix-d.html
[22:34] <imachine> because I think it's the fact that the card falsly keeps both outputs on, and therefore corruption comes up
[22:34] <IntuitiveNipple> There's an IgnoreDisplayDevices option that may help
[22:35] <IntuitiveNipple> also possibly ExactModeTimingsDVI if you over-ride EDID
[22:35] <imachine> its not EDID, I think
[22:35] <imachine> there's no errors in xorg.0.log
[22:35] <imachine> it used to work on older drivers
[22:36] <imachine> and if I killed and restarted X a few times, it worked fine
[22:36] <imachine> so I'm guessing it's some nasty nvidia issue that makes it pick up both outputs at once.
[22:36] <IntuitiveNipple> From what I've read though, the driver is not using the provided EDID info correctly, so over-riding it could help
[22:36] <imachine> and it should not.
[22:36] <imachine> I'll check it out later tomorrow, thanks
[22:36] <imachine> it's tomorrow in 20 minutes over here anyway
[22:36] <imachine> and I guess I should be off
[22:36] <imachine> so lates! and thanks for the hints.
[22:37] <imachine> I'll report back later
[22:37] <IntuitiveNipple> the other one is ModeValidation
[22:44] <desavel> hi all
[22:44] <BUGabundo> desavel: ehy
[22:44] <desavel> what is Ubuntu?
[22:46] <desavel> hm.........I feel myself lonely
[22:48] <BUGabundo> humm
[23:16] <bdmurray> Wooo, found a fixed bug
[23:18] <BUGabundo> eheh