[00:11] <Awsoonn> I would like to know how I can find out if a commit made to xorg has made it to 8.10
[00:12] <Awsoonn> how shall I do this? commit d3c36fe721edc55636438bc3e0e7a6c03f62784e
[00:12] <bryce> Awsoonn: ok first you need to know which package that commit was to
[00:13] <bryce> now, there might be an easier way, but here's how I do it:
[00:13] <bryce> 1.  Go to http://gitweb.freedesktop.org/ and find the package, click on it
[00:14] <bryce> 2.  Click on one of the 'commit' links
[00:14] <bryce> 3.  in the Location bar, delete the h=... stuff, and paste in your commit id
[00:14] <bryce> so it looks like this might be your commit?  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=d3c36fe721edc55636438bc3e0e7a6c03f62784e
[00:16] <bryce> 4.  apt-get source xorg-server
[00:16] <bryce> 5.  Look at the code in the patch for that commit id, and compare it against the corresponding file in the xorg-server code
[00:17] <bryce> Sometimes it's enough to simply compare the date on the commit log message against the release date of the package.  But there can be some rare cases where that's not enough.
[00:18] <bryce> oh, another thing to check, if you *don't* see the code in the codebase, make sure to also peek in debian/patches/ to see if that patch is already present there
[00:18] <Awsoonn> ok, gotcha. Thanks Bryce
[00:18] <bryce> (I'm sure the above sounds like a PITA... and it sort of is, but that's what I do)
[00:19] <tjaalton> you can also just search for the commit id
[00:20] <tjaalton> select the branch that the current release has, and search for the commit there
[00:20] <tjaalton> or git pull the source and grep from git log :P
[00:22] <tjaalton> git clone not pull
[00:43] <pwnguin> what should I do about bug reports in hardware I don't have? they've provided good information, but im not sure I can mark it confirmed
[00:44] <bryce> pwnguin: if they've provided all the typical info we ask of users as per X/Reporting, then I typically go ahead and mark them Triaged
[00:45] <bryce> generally at that point, unless there's a task for us to do in Ubuntu for them, the next step is to report them upstream.
[00:47] <pwnguin> well
[00:47] <pwnguin> triaged requires super abilities
[00:50] <Awsoonn> someone with those abilities, 242984 need status set as well
[00:51] <Awsoonn> pwnguin: post the bug number and hopefully someone can set it for you :)
[00:52] <LaserJock> pwnguin: you don't have such super powers?
[00:53] <pwnguin> LaserJock: is this astonishing?
[00:55] <LaserJock> pwnguin: I would've thought you had
[00:56] <pwnguin> ive never needed it
[00:56] <LaserJock> huh
[00:56] <pwnguin> most of the time i can confirm and move from there
[00:56] <pwnguin> but i dont have a usb tablet
[00:56] <bryce> I've updated 242984
[00:57] <LaserJock> the "super powers" thing started since I've been a MOTU (and hence automatically have powers) so i forget they exist
[00:59] <Awsoonn> I've been waiting a month to break the Kyrptonite shackles :p
[01:06] <pwnguin> another question
[01:06] <pwnguin> recently a Toshiba-Tablet group was formed
[01:07] <pwnguin> what's the best way to create a group specific list of bugs without interfering with the rest of ubuntu?
[01:08] <LaserJock> pwnguin: subscribing the team to the relevant packages?
[01:08] <pwnguin> bug tags? subscriptions? assignment seems like it might not work
[01:08] <pwnguin> LaserJock: HAL is a relevant package, but not every bug is relevant to toshiba hardware
[01:08] <LaserJock> true
[01:08] <pwnguin> maybe just subscribing to relevant bugs
[01:09] <LaserJock> if you want you can subscribe to individual bugs
[01:09] <bryce> pwnguin: sounds like a job for tagging
[01:09] <pwnguin> if i do that, will it dump subscribed bugs to the ML?
[01:09] <pwnguin> bryce: im not sure whether tagging is any better than subscribing
[01:09] <pwnguin> additionally, it pollutes the tagspace ;)
[01:09] <LaserJock> pwnguin: it depends on if the ML is is set as the team contact
[01:12] <pwnguin> i guess the next question is, do I want that?
[01:12] <pwnguin> or perhaps, does the team want that?
[01:12] <LaserJock> I generally tend to not and then let the bugmail go to all the team members individually
[01:13] <LaserJock> bugmail going to a mailing list tends to just turn into spam and makes it harder to really have a discussion
[01:14] <LaserJock> on the other hand, if the team is basically just doing bug work then maybe it'd make sense
[01:30] <bryce> ogasawara: #68440 seems to also be a misfiled kernel bug
[01:35] <bryce> ok, all of the Confirmed->Triaged tasks are done
[01:40] <pwnguin> oh, today's a hug day
[01:41] <pwnguin> i wondered why people were doing things
[01:41]  * bryce chuckles
[01:41] <pwnguin> https://bugs.edge.launchpad.net/ubuntu/+source/wacom-tools/+bug/244993
[01:41] <ubottu> Launchpad bug 244993 in wacom-tools "mapping incorrect with widescreen" [Undecided,Incomplete]
[01:41] <pwnguin> bryce: can you think of anything else that report needs?
[01:44] <bryce> looking
[01:44] <pwnguin> i guess i should mark it undecided if i dont know
[01:45] <bryce> that's sufficient, it can be set to triaged
[01:45] <bryce> pwnguin: next step would be to forward it upstream
[01:45] <pwnguin> right
[01:46] <pwnguin> i just wanted to have a look at the configuration options again before I did that
[01:47] <Awsoonn> 39 bugs in Confirmed status.... DONE! Way2Go Bryce~ :)
[02:17] <jkary_> hello.  I am using pbuilder to test a patch to apt-get.  I can't seem to figure out how to use pbuilder --login to load the apt package I've built.  Every time I try to test I get the original apt-get version.  What am I doing wrong?
[02:40] <Awsoonn> jkary_:  you may want to ask in #ubuntu-devel I think they might know more about that stuff
[03:29]  * persia turns on all the lights
[03:30] <bddebian> BOO! :)
[03:32] <RAOF> bddebian: To slow to catch persia, it seems :)
[03:32] <persia> RAOF: But today was extra-loud: to compensate.
[03:33] <bddebian> Aye :)
[03:50] <kgoetz> is the 5-a-day build-dep on cdbs a hard dependancy? 0.4.49 i only have 0.4.48 here.
[03:52] <persia> kgoetz: I don't see anything special in the 0.4.49 changelog.  You might try with 0.4.48, but no promises.
[03:52] <crimsun> doesn't seem to be.
[03:53] <kgoetz> thanks both, i'll give it a go.
[06:56] <Awsoonn> bug #230571 status should be set to -triaged- but I lack super cow powers, someone care to do the job for me? :)
[06:56] <ubottu> Launchpad bug 230571 in xorg "Monitor input not supported" [Undecided,Confirmed] https://launchpad.net/bugs/230571
[06:58] <LaserJock> Awsoonn: done
[06:58] <Awsoonn> ども
[06:58] <Awsoonn> thanks**
[07:02] <Awsoonn> LaserJock: bug #243860 too if you don't mind. :)
[07:02] <ubottu> Launchpad bug 243860 in xorg "Dell Inspiron 1420n Touchpad Stopped Working in Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/243860
[07:04] <LaserJock> Awsoonn: done
[07:04] <Awsoonn> domo
[07:59] <Iulian> G'morning
[08:02] <thekorn> morning Iulian
[08:04] <Iulian> Hello thekorn!
=== thekorn_ is now known as thekorn
=== mdz_ is now known as mdz
[10:21] <afflux> morgen
[10:22] <thekorn> afflux: guten morgen
[10:22] <afflux> huh... thought I wrote "morning" or something. Will make a coffee in a minute :P
[10:23] <afflux> a friend of mine is experiencing bug 200841, but he has no idea how to get either a crash file or a stacktrace. Will apport generate a crash file for that issue or do I have to generate a wrapper script for gdm?
[10:23] <ubottu> Launchpad bug 200841 in gdm "gdm[5020]: WARNING: main daemon: Got SIGABRT. Something went very wrong. Going down!" [Medium,Invalid] https://launchpad.net/bugs/200841
[10:23] <afflux> (apport, when enabled, of course)
[10:25] <seb128> afflux: I'm not sure that apport catches SIGABRTs
[10:26] <afflux> hm, looking
[10:26] <persia> afflux: Understanding the bug requires attaching the debugger to gdm, and somehow trapping it for a trace at the time it ends.  Personally, I suspect this is a side-effect of the unsafe-shutdown-for-speed efforts: it's not important that gdm crashes, as long as it reinits cleanly when coming back up.
[10:26] <seb128> honestly that would be better placed upstream, I don't think we have anybody in the team knowing well the gdm code
[10:27] <afflux> indeed, it does not seem so: sh -c 'kill -ABRT $$'  didn't do anything useful.
[10:27] <seb128> and the bug has no detail on the issue or how to trigger it
[10:27] <persia> seb128: Do you not have the message in your logs on reboot?
[10:28] <seb128> persia: no, no such message neither on my laptop or desktop apparently
[10:29] <persia> I don't see it either, and the user doesn't provide information about in which logfile they found the error.  I don't think this bug is in a fit state to go upstream.
[10:30] <persia> afflux: Could you maybe track down the specifics of the problem with your friend, update the bug report, and push upstream?  At minimum, it needs the specific log file and some information as to whether this happens every time or just once in a while.
[10:30] <afflux> alright, will try so.
[10:31] <seb128> persia: right, I was not suggesting to send the current bug upstream, though upstream might have suggestions on how to get useful informations on such issues
[10:32] <persia> seb128: Maybe, although I suspect upstream would prefer to have some guidance as to which logfile, etc.
[10:33] <persia> I also think we ought not have triaged the bug the way we did: we never asked the submitter for any details about the problem beyond an apport trace (which wouldn't happen), and then marked it invalid.
[10:33] <persia> Better to link and push upstream, I'd think.
[10:33] <afflux> is there a way to automate gdb? ie. when catching a sigabrt, do thead apply all bt full
[10:33] <seb128> right
[10:35] <persia> afflux: There are ways to tell gdb to trap sigabrt interactively, and stop for activity.  For a gdm crash, you can probably launch gdb from a VT, attach it to the running gdm, tell it to trap the signal, and write a logfile with the backtrace, and then reproduce the issue.  As long as you put the file in a good location, it should be available for review on reboot.
[10:35] <persia> As to how to do this specifically, I can only point you at the gdb manual.
[10:35]  * persia *really* likes apport because it saves the hassle of using gdb most of the time
[10:36] <afflux> hehe, alright. thanks, I'll have a look.
[11:15] <popey> morning all, I have a problem.. an app causes x to explode sometimes, sending me back to GDM. I know which app and i can probably reproduce it, is there some trace/log of x that I could get to file a bug?
[11:15] <\sh> popey: /var/log/X* ?
[11:15] <popey> doesn't seem to be much in there
[11:16] <\sh> popey: strace <app> &> strace.app.log
[11:17] <\sh> and eventually starting X with a higher debug level ;)
[11:17] <popey> ok, will trace the app
[11:17] <popey> thanks \sh
[11:18] <popey> how would i bump the xorg trace level?
[11:20] <persia> popey: You may also find some of the resources linked from https://wiki.ubuntu.com/X/Debugging useful
[11:22] <popey> thanks persia
[11:24] <popey> miro.real: Fatal IO error 1 (Operation not permitted) on X server :0.0.
[11:24] <popey> from the strace. . not much to go on :)
[11:38] <persia> popey: Excellent find.  Now, install the miro -dbgsyms, and run miro from a VT under gdb (with DISPLAY set).  That lets you get the bt from miro after X crashes.
[11:55] <popey> persia: i started going through https://wiki.ubuntu.com/X/Backtracing
[11:56] <popey> and in a VT when i do the attach, gdb (and x) freezes, so i can't type "cont"
[11:56] <popey> bug 223579 appears to be what I'm getting so i wanted to attach the x backtrace to it
[11:56] <ubottu> Launchpad bug 223579 in xserver-xorg-video-intel "X crash: libextmod.so(XvdiPutImage) on i945 when playing videos in miro" [Undecided,Incomplete] https://launchpad.net/bugs/223579
[11:57] <persia> popey: Can you not get to the BT with Alt-F2 or the like?  Maybe try attaching from an ssh session?
[11:57] <popey> BT?
[11:57] <persia> backtrace
[11:58] <popey> i will try gdm over ssh, yes
[11:58] <persia> gdb?
[11:58] <popey> sorry, gdb
[11:59] <persia> Ideally you'll want to get 20-30 frames of trace, ideally for both miro and X.  There's something about the video rendering and EXT that people have complained about, and this is likely that bug.
[12:00] <popey> ok, will see what I can do
[12:00] <persia> popey: Thanks.  Good luck with it.
[12:13] <popey> hmm, whilst gdb is attached, miro crashed this time but didn't take x with it!
[12:15] <popey> ah, got it this time
[12:16] <popey> can I dump this "backtrace full" out to disk?
[12:18] <james_w_> popey: there's a gdb command to set an output file
[12:19] <popey> once it's already running and the app has crashed?
[12:19] <popey> or is this something that should be set before?
[12:19] <james_w_> set logging file gdb-<program>.txt
[12:19] <james_w_> set logging on
[12:19] <popey> ah, ok
[12:19] <james_w_> I hope that's the right thing
[12:19] <popey> trying
[12:24] <popey> http://launchpadlibrarian.net/15820752/gdb-miro.txt does that look comprehensive enough?
[12:28] <persia> popey: That is exceptionally helpful from a miro perspective.
[12:28] <james_w_> popey: yep, looks pretty comprehensive. Incomprehensible, but comprehensive.
[12:29]  * persia disagrees with "incomprehensible"
[12:30] <popey> heh
[12:30] <persia> popey: Looks like an issue with the Xv call.  Given the trace bryce found earlier, I'm tempted to blame X.  That said, it's also worth a task against miro, as miro ought detect the failure and give you an error message, rather than blindly continuing to do things assuming X works.
[12:30] <popey> thanks for the help guys
[12:30] <popey> that makes sense
=== rbs-tito_ is now known as rbs-tito
=== james_w_ is now known as james_w
=== emgent_ is now known as emgent
=== thekorn_ is now known as thekorn
=== LucidFox_ is now known as LucidFox
=== LucidFox is now known as ContinuumFox
[15:07] <Awsoonn> mornin'
=== bddebian2 is now known as bddebian
[15:27] <pedro_> hey good morning Awsoonn
[15:28] <Awsoonn> G'morin' pedro_~
[15:30] <Awsoonn> pedro_: What must one do to become approved for Bug Control?
[15:31] <pedro_> Awsoonn: ah there's a wiki page with instructions about that https://wiki.ubuntu.com/UbuntuBugControl
[15:33] <Awsoonn> domo
=== ContinuumFox is now known as LucidFox
[16:43] <dholbach> Global Bug Jam Preparation Session in #ubuntu-meeting in 16 minutes.
[16:55]  * parthan joins in
=== parthan is now known as techno_freak
=== LucidFox is now known as CounterStrikeFox
[17:33] <bliZZardz> w.r.t bug #229575 - this looks like a valid request. i am able to find this right from feisty(not sure abt versions before that :) ) - should this be taken up during packaging?
[17:34] <ubottu> Launchpad bug 229575 in python-cherrypy "cherrypy tutorial files in wrong directory" [Undecided,New] https://launchpad.net/bugs/229575
[17:34] <yuriy> bddebian: in LP you can sort by "least recently changed". any way to get this with bugnumbers?
[17:37] <yuriy> sorry, bdmurray ^
[17:43] <yuriy> or perhaps pedro_ ^?
[17:45] <pedro_> yuriy: i'm using last comment (lc) and sort for that
[17:47] <yuriy> pedro_: the man page doesn't mention that one
[17:48] <yuriy> pedro_: you good with a hug day next tuesday?
[17:48] <pedro_> perhaps --help ?
[17:49] <pedro_> yuriy: I'm not going to be around a lot next Tuesday but if you want to run the KDE one there that's ok for me ;-)
[17:51] <yuriy> pedro_: hmm --lc lets me specify a specific date? or can I get it to do before some date?
[17:52] <pedro_> yuriy: yes, for example you can use it like: --lc=d:<2008-06-17 and grab all the ones before that date
[18:19] <thekorn> yuriy, do you mean something like    bugnumbers -p firefox --sort=-recently_changed
[18:19] <thekorn> this is not in bugnumbers (yet), but supported by python-launchpad-bugs
[18:19] <thekorn> I plan to update bugnumbers at the beginning of the next week, so I will add this functionality
[18:21] <bliZZardz> i am looking at some old bugs .. bug #174160 - am not sure what(if at all mentioned) the problem is !
[18:21] <ubottu> Launchpad bug 174160 in straw "Straw doesn't handle gnome proxy settings" [Undecided,New] https://launchpad.net/bugs/174160
[18:23] <yuriy> thekorn: yep, nice
[18:27] <Awsoonn> Bug #239964
[18:27] <ubottu> Launchpad bug 239964 in xorg "xorg;conf lost at hardy upgrade, screen resolution cannot be set" [Undecided,Incomplete] https://launchpad.net/bugs/239964
[18:28] <Awsoonn> the output of sudo ddcprobe does not give the edid of the monitor, is there something that can be done about this bug?
[18:29] <Rocket2DMn> question: should this bug be marked as Won't Fix: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/244779 - the OP is opening a bug upstream and was using Edgy (no longer supported)
[18:29] <ubottu> Launchpad bug 244779 in gvfs "permission denied when removing a directory via SSH" [Low,Incomplete]
[18:39] <mcas> hiho
[18:45] <techno_freak> Rocket2DMn, as Edgy is not supported any more [1] it's invalid... [2] but still ask him to confirm whether he can reproduce it with gutsy or hardy?
[18:45] <Rocket2DMn> techno_freak, it is unlikely he will try and reproduce it, he's using a server
[18:46] <Rocket2DMn> if he does anything, he should just reinstall fresh with Hardy
[18:46] <techno_freak> Rocket2DMn, please ask him before closing, to be on safer side
[18:46] <techno_freak> Rocket2DMn, if he doesnt respond, it expires and you can close it.
[18:47] <Rocket2DMn> ok, should i just ask him to try hardy? or any supported version?
[18:48] <techno_freak> Rocket2DMn, Hardy (though intrepid would be awesome) ;)
[18:49] <Rocket2DMn> yeah but hardy is LTS
[18:50] <ogra> rather ask him for the upstream bug id and set up a bugtask for that than just closing it as invalid
[18:50] <Rocket2DMn> ogra, what is a bugtask
[18:50] <ogra> there is hardy technology (gvfs) involved
[18:51] <ogra> you can click on "also affects project" and link to another bugtracker
[18:51] <ogra> changes there will then automatically update the bug in launchpad
[18:51] <Rocket2DMn> ok, then just add the link huh?
[18:51] <Rocket2DMn> what status do i put the bug into?
[18:51] <ogra> since he said he would open an upstream bug t gnome for gvfs
[18:52] <ogra> keep it as inclomplete and ask the guy to give you the gnome bugnumber
[18:52] <ogra> if he adds that, create the upstream task with the "also affects project" button on the bugpage
[18:53] <Rocket2DMn> ogra, if i just get the link, is that enough?
[18:54] <ogra> you just need the bugnumber
[18:54] <Rocket2DMn> so where it says "I have the URL for the upstream bug" I just put the number with a # sign?
[18:54] <ogra> if you click on "also affects. ..." it will give you a pulldown ... select gnome there, then enter the number into the input field and LP will do the monitoring
[18:54] <Rocket2DMn> like "@12345"
[18:54] <Rocket2DMn> shoot #12345
[18:55] <ogra> LP will moan if you do it wrong ;)
[18:55] <ogra> and tell you :)
[18:55] <Rocket2DMn> Also Affects Project
[18:55] <ogra> right thats the button
[18:55] <Rocket2DMn> then click Choose another project
[18:55] <ogra> but you need the numer first
[18:55] <ogra> exactly ... there select gnome
[18:57] <Rocket2DMn> is there actually a package that is just "gnome"
[19:00] <Rocket2DMn> ogra, i requested the information, i will probably come back here if/when the OP responds so i can be sure i do this right
[19:00] <Rocket2DMn> i have to go right now, thank you for helping
=== asac_ is now known as asac
=== ryanakca is now known as Guest7804
=== ryanakca_ is now known as ryanakca
[21:51] <chrisccoulson> got an intrepid bug here: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/245180
[21:51] <ubottu> Launchpad bug 245180 in linux-restricted-modules-2.6.24 "package linux-restricted-modules-2.6.24-19-generic 2.6.24.13-19.44 failed to install/upgrade: " [Undecided,New]
[21:52] <chrisccoulson> looks like lrm failed to install during hardy -> intrepid upgrade
[21:52] <chrisccoulson> this guy has reported the same bug 3 times
[21:52] <ubottu> Launchpad bug 3 in rosetta "Custom information for each translation team" [Wishlist,Confirmed] https://launchpad.net/bugs/3
[21:53] <chrisccoulson> not sure how to handle this one really. not even sure whether the reporter realises it's a development release
[21:53] <chrisccoulson> 245382 and 245506 look identical
[22:13] <undadecor> I'm triaging a bug report and the reporter is requesting that a package be added to the standard install of the python package.  What is the proper response to these types of reports?