[01:37] <nickellery> bdmurray, Bug 237662 in todays Bug Day is not related/packaged to Update Manager
[01:43] <persia> nickellery: No, but as long as that bug is outstanding, changing the computer name means that update manager doesn't work.  Be nice to fix that too.
[02:10] <jjesse> hrmm jorge@bazaar.launchpad.net has a lock on add-5-a-day
[02:13] <pwnguin> what?
[02:14] <pwnguin> ive never used bzr, but it uses locks?
[02:14] <jjesse> i'm trying to use 5-a-day andsomeone has it locked
[02:14] <jjesse> probablly should go on #launchpaed
[02:16] <persia> jcastro: Are you using that lock, or did you forget it when you left?
[02:16] <persia> jjesse: For future note, user@bazaar.launchpad.net always has a homepage at launchpad.net/~user, and there is usually an associated IRC nick.
[02:17] <jjesse> persia: i know was trying to figure that out
[02:18] <jcastro> persia: yeah it was my fault, sorry, fixing
[02:20] <persia> jcastro: No worries :)
[02:22] <jjesse> jcastro: still shows locked for me
[02:26] <jcastro> jjesse: try now
[02:27] <jjesse> jcastro: worked thank you
[02:27] <jcastro> didn't know I could break things in such ways, sorry!
[02:28] <jjesse> no worries
[05:02] <mrooney> Old_Soldier: nice bug :]
[05:03] <Old_Soldier> hehe i was expevting someone to say dont be anal its been that way since breezy
[05:04] <mrooney> well if the docs say to use American English then it is indeed a bug
[05:04] <persia> Old_Soldier: You'd be surprised just how many bugs are left over from pre-Breezy :)
[05:04] <mrooney> there is a UK translation so I suppose that is where it belongs
[05:55] <mrooney> Old_Soldier: nice, a "real" typo :)
[05:56] <Old_Soldier> :) im trying to be really thorough. I've yet to earn my wings in the document team :)
[05:57] <mrooney> it is nice, I think polish in documentation is great to have
[05:58] <mrooney> isn't it really interesting that people writing documentation wouldn't use a spell check?
[06:00] <Old_Soldier> i think its because they get annoyed at the spellchesker hitting on the docbook tags
[06:00] <Old_Soldier> but yes it is pretty amazing :)
[10:17] <leoquant> i would give Bug #121346 a bump. it is really confusing for some users. (that unix-word)
[10:27] <Flannel> leoquant: Where does it say UNIX?  passwd just prompts for a New Password, and then Confirm New Password
[10:29] <leoquant> thats weird
[10:29] <leoquant> Flannel which version of ubuntu/
[10:34] <leoquant> passwd username: UNIX pass prob. in 7.04/7.10
[10:34] <leoquant> correct me when i am wrong
[10:38] <gnomefreak> it says new unix password
[10:39] <gnomefreak> when you use passwd username
[10:39] <gnomefreak> in gutsy and hardy as i recall i dont remember feisty
[10:43] <leoquant> as a moderator of the off. dutch ubuntu forum we had some questions about that unix-word. its confusing for some users.
[10:45] <gnomefreak> UNIX pass. == unix-word the bug is talking about?
[10:46] <gnomefreak> since the terminal uses UNIX commands (and some linux ones per flavor are added) but since the command is a UNIX command it says UNIX.
[11:07] <leoquant> unix pass isn´t a bug, it is confusing for some users. thats my point.
[11:18] <heno> mvo: Hi. Any view on dealing with Breezy -> Dapper upgrade bugs at this point? They may be valid and we still support Dapper (but does that mean we support upgrading _to_ dapper?), but I doubt we should prioritise them
[11:19] <heno> my inclination is to close them with Won't fix, but I'm wondering about the best wording for that
[11:21] <persia> heno: You might be able to say something like "This bug cannot be fixed, as there is no longer a means to update the unsupported "Breezy" release.  Please remove the offending package, continue the upgrade, and reinstall the package.  If you are unable to reinstall the package under Dapper, please file a new bug."
[11:23] <mvo> heno: realistically we will not fix them, so telling the user upfront is probably a good thing. if someone steps up and wants to fix issues, that is very welcome of course
[11:24] <mvo> the suggestion of persia sounds good to me (for the wording)
[11:24] <heno> persia, mvo: ok thanks
[11:42] <LimCore> hello, Im debugging some problem related to setting time
[11:42] <LimCore> anyone have a moment to also tak a look on it?
[11:42] <LimCore> take
[11:43] <heno> LimCore: bug #?
[11:44] <LimCore> heno:  https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/238805   and the reall bug is:   "ntpdate fixes only > 0.5 sec offsets, so the clock fixes using adjtime() seem to not work - so its probably a kernel/mobo driver problem"
[11:44] <heno> LimCore: thanks, I'll have a look
[11:46] <LimCore> heno: the problem is more visible in http://codepad.org/pMDclI7c
[11:48] <heno> LimCore: do you leave your machine on all the time?
[11:48] <LimCore> uptime is 1.5 day now
[11:48] <heno> I think ntp may only sync on boot to avoid file system issues
[11:48] <heno> or when you sync manually
[11:49] <LimCore> ntpdate sync only when executed manualy;  ntpd runs in background
[11:49] <LimCore> my theory is that  adjtime() do not work on my kernel/mobo,  it would explain both
[11:49] <LimCore> 1) ntpd not working at all - it uses only adjtime
[11:49] <LimCore> 2) ntpdate working only for offsets > 0.5 sec,  manual says it uses adjtime() for offsets < 0.5 sec and settimeofday() otherwise
[11:56] <heno> LimCore: Hm, so we need a test case for adjtime() in isolation on your system really
[12:00]  * LimCore writest testcase
[12:13] <LimCore> ok I tested... adj time do not work for me
[12:13] <LimCore> on my system, calling adj time does nothing
[12:14] <LimCore> http://codepad.org/tagnjrll
[12:26] <thekorn> bdmurray, IMO it would make sense to exclude 'workflow'-bugs from the bugday lists
[12:26] <thekorn> bug 223419 is an example
[13:41] <askand> If I want to file a bug about something I wish to be moved t main, how should I formulate it?
[13:42] <askand> And should I file the bug against the package I wish to be moved?
[13:42] <thekorn> askand, see https://wiki.ubuntu.com/MainInclusionProcess
[13:43] <askand> ﻿thekorn: I checked that and begun to write a mainiclusionreport but it was a lot I did not understand..
[13:44] <seb128> so don't open a bug
[13:44] <seb128> what is your rational to want something promoted anyway?
[13:45] <askand> ﻿seb128: It is needed to fix bug 213367
[13:46] <seb128> alright so there is already a bug documenting the need
[13:46] <askand> ﻿ seb128: Yes it seems so
[13:46] <seb128> now what is required is somebody following the procedure documented on the wiki, not a new bug about the promotion being needed
[13:47] <seb128> that's not that hard to do, maybe try to start on one and ask in #ubuntu-motu if there is things you don't understand?
[13:48] <askand> ﻿seb128:  Ok, thanks. Ill try
[13:48] <seb128> cool
[16:17] <sectech> Can someone review bug #238817 with me
[16:17] <sectech> It appears as this will be a wishlist, but I am not 100% sure
[16:19] <pedro_> sectech: looks like a poppler one to me instead of evince btw
[16:20] <pedro_> I've seen something similar before...
[16:20] <pedro_> https://bugs.freedesktop.org/show_bug.cgi?id=4925
[16:21] <sectech> pedro_,  I'll link the bug...
[16:22] <pedro_> sectech: rock on, thanks
[16:22] <sectech> pedro_, should I take off the assignments as well? There valid as "also affects"
[16:24] <sectech> I can't add the upstream bug for some reason
[16:24] <pedro_> sectech: re-assign the evince one to poppler and open an upstream task for it
[16:25] <sectech> Okay
[16:26] <pedro_> sectech: does launchpad gives you an error or something?
[16:26] <pedro_> while creating the upstream task
[16:26] <sectech> pedro_,  when you say open an upstream task, you mean click "Also affects project?"
[16:26] <sectech> No it didn't give an error, just not the page I was used to
[16:26] <pedro_> sectech: yes
[16:27] <sectech> There we go
[16:27] <pedro_> I'll mark it as triaged for you in the meantime
[16:29] <sectech> I'll change the description to something a little more appropriate
[16:29] <sectech> Done
[16:29] <sectech> I had it as Evince and xpdf needs...  so I changed it to poppler
[16:30] <qense> hello
[16:30] <qense> bdmurray, did you recieve my email?
[16:30] <pedro_> sectech: rock on, but xpdf doesn't use poppler so that bug may be still valid for that package
[16:31] <pedro_> sectech: just open the task and mark it as confirmed ;-)
[16:31] <sectech> ... Okay
[16:35] <bdmurray> qense: yes
[16:36] <qense> OK
[16:36] <qense> aaargh!
[16:36] <qense> just when I get online I have to go again
[16:36] <qense> my mother calls me :P
[16:37] <qense> dinner's ready
[16:38] <sectech> How is my application for bug-control coming along anyway?
[16:39] <sectech> Or is is being delayed until you guys get the new Application procedures down?
[16:41] <bdmurray> sectech: I haven't looked at it quite yet but hope to today
[16:41] <sectech> bdmurray, awesome :)
[17:07] <qense> OK, I'm back now. bdmurray, what did you think of my mail? (and do you have time to discuss it?)
[17:51] <bdmurray> mvo: ping
[17:52] <mvo> bdmurray: pong
[17:52] <bdmurray> mvo: I just was looking at bug 222801 and was wondering the status of it
[17:53] <bdmurray> mvo: it looks like you have a fix for it
[17:54] <mvo> bdmurray: yes, that is a duplicate, give me a sec, I dig what the master bug is
[17:58] <mvo> bdmurray: I updated the bug, thanks for the reminder
[18:26] <mrooney> man, #ubuntu is way to crowded and loud
[18:27] <mrooney> I wonder if they have considered doing what python did by randomly (.5) putting people in ##python instead of #python
[18:40] <sectech> 1353 in #ubuntu... wow
[18:42] <greg-g> does anyone get genuine help in there?
[18:45] <sectech> Depends on the time of day I imagine...
[18:54] <jjesse> yes
[20:18] <afflux> hi
[20:18] <afflux> something for our french people: bug 222453
[20:29] <jibel> afflux: Hi. 222453 set as incomplete. I've requested the dist-upgrade log file
[20:29] <afflux> jibel: I've actually no idea what it says, so thanks for taking it ;)
[20:40] <Cliph> Hi, I'm building a meta-dpkg and it has a bunch of dependencies that are also available in my repository, when I  try installing <my-meta-package> I get a message about some of my dependencies stating "Depends: <other dependency>  but it is not going to be installed"  Here is a pastebin of the output and my control file:
[20:40] <Cliph>  http://pastebin.comd1efb6512 And here is a pastebin of apt-cache policy <my-mfeta-package>:  http://pastebin.com/d7e10ae2b   maybe this is an APT bug?
[20:42] <bdmurray> Your first url isn't working out even after I added a / btwn com and d
[20:42] <Cliph> oh, sorry
[20:43] <Cliph> http://pastebin.com/d1efb6512
[20:46] <bdmurray> I don't see anything obvious I'd check in #ubuntu-motu
[20:46] <Cliph> ok, thanks, no one there is biting but I'll see what they say
[21:40] <mrooney> okay, so I have been getting hard lockups recently, often at login. Ctrl+Backspace doesn't respond and disturbingly enough, nor do the Sys+Req keys
[21:40] <mrooney> are there some good logs I should look at, anything specific to debug it?
[21:43] <mrooney> I'm in my Xorg.0.log, but without timestamps it is hard for me to understand where the last session ended and this one started
[22:18] <james_w> mrooney: does your mouse pointer still move?
[22:20] <mrooney> james_w: nope, I used to experience that but not recently at all
[22:20] <mrooney> and in that case the sysreq keys worked
[22:21] <james_w> yeah, I realised after that it would be really strange to have mouse but not sysreq
[22:21] <james_w> how do you manage to restart X in that case?
[22:35] <mrooney> james_w: hold down the power button until it turns off :)
[23:08] <james_w> mrooney: ah, so your Xorg.0.log won't show more than one session?
[23:08] <james_w> I think there is a way you can capture some information from the kernel so that it can be read after the reboot, but I don't remember what it is.
[23:10] <mrooney> james_w: no, I think it is (maybe?), all the other logs do, but they are also timestamped so I can tell
[23:10] <james_w> ah, I was under the impression is just got wiped everytime the X server started.
[23:11] <james_w> also, is there something that makes you think that this is an X freeze rather than a kernel freeze?
[23:11] <mrooney> james_w: nope! not at all!
[23:11] <mrooney> I just remember someone telling me to look at that once
[23:12] <james_w> well, I would assume it was kernel if sysreq doesn't work.
[23:12] <lifeless> check if num lock can still be toggled
[23:12] <james_w> hi lifeless
[23:12] <lifeless> james_w: on laptops sysrq can be really tricky to make jump
[23:13] <lifeless> hi james_w
[23:19] <mrooney> lifeless: what if my num lock requires use of the function key? is that still a useful test?
[23:19] <lifeless> yes; see numlock being toggled requires the kernel to handle the interrupt
[23:19] <mrooney> caps lock is the only non-FN lock on this keyboard
[23:20] <lifeless> caps lock is fine too
[23:20] <lifeless> does it respond?
[23:20] <mrooney> well, it does now since I restarted :)
[23:20] <mrooney> I will try again if it happens again which it has been a lot so I suspect it will