=== ubott2 is now known as ubottu
[02:18] <james_w> hey, I got a build failure on ia64 on a package that uses XTest.h due to XInput.h not being installed.
[02:18] <james_w> http://launchpadlibrarian.net/19774512/buildlog_ubuntu-jaunty-ia64.cairo-dock_1.6.3.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[02:19] <james_w> the package doesn't use symbols from XInput.h from what I can see, so it seems like something might be missing a dependency
[02:19] <james_w> (I can't work out if it should be libxtst-dev or x11proto-something)
[02:20] <james_w> or is it something else entirely?
[02:43] <bryce> james_w: sounds like a dropped patch
[02:43] <james_w> in cairo-dock, or some X component?
[02:51] <bryce> one sec
[02:53] <bryce> x11proto-input provides XInput.h
[02:54] <bryce> however I don't see any dropped patches there
[02:54] <james_w> I'm not sure why it's ia64 only either
[02:55] <james_w> though a few ports architectures haven't built yet
[02:55] <bryce> that could be why
[02:59] <bryce> james_w: libxi is involved as well
[02:59] <bryce> via the 100_add_xinput.h.patch patch
[03:00] <bryce> however it also looks like it's not dropped any patches that I can see
[03:01] <james_w> there's a sponsor request open for a package which adds a dependency on libxi-dev due to a build problem a while ago, I'm not sure if that is the same issue
[03:02] <bryce> quite possible
[03:05] <james_w> the sponsor request is bug 298496
[03:06] <ubottu> Launchpad bug 298496 in anyremote "Please merge anyremote 4.6-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/298496
[03:06] <james_w> which has In file included from xemulate.c:32:
[03:06] <james_w> /usr/include/X11/extensions/XTest.h:50:35: error: X11/extensions/XInput.h: No such file or directory
[03:06] <wgrant> Right, Debian is out of date.
[03:06] <wgrant> I believe upstream moved it into libxi-dev, and we followed.
[03:06] <wgrant> Or was it the other way around...
[03:07] <wgrant> ANywya, we do have it in the other package, although it was gone altogether in Jaunty until a couple of days ago.
[12:00] <tseliot> mvo: did you have a look at this bug again? https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/292774
[12:00] <ubottu> Ubuntu bug 292774 in xorg "multiseat xorg.conf setup broken after upgrade to 8.10" [Undecided,Incomplete]
[12:00] <tseliot> if you give me a link to the script you put in Update Manager I think I can fix the bug
[12:28] <Ng> <random>anyone have any idea how to extract video timings from windows to make a modeline?</random>
[12:35] <mvo> tseliot: I have seen it, yes. but haven't done anything about it yet
[12:36] <mvo> tseliot: do you think the suggestion to check for multiseat is ok? my understanding was that the multiseat setup would be broken after the upgrade anyway unless 'Option "AutoAddDevices" "off" is set
[12:36] <mvo> tseliot: or do you think we should aim for transitioning that as well?
[12:59] <Ng> hmm, bah, I don;t think this is a timing issue, it's using exactly what the TV asks for. stupid G45 driver must be doing something wrong then
[13:03] <tseliot> mvo: I think that counting the number of serverlayout sections should be enough. If there's more than one then don't touch the xorg.conf
[13:05] <tseliot> mvo: look for "serverlayout" (case-insensitive) in lines which don't start with "#"
[13:07] <mvo> tseliot: thanks I add that
[13:18] <tseliot> great
[13:20] <mvo> tseliot: do you think its common enough to justify a sru?
[13:21] <tseliot> mvo: not very common but I guess it's still worth a SRU
[13:24]  * mvo nods
[13:43] <mvo> tseliot: I commited the "do not touch" bits now
[13:44] <tseliot> mvo: great, thanks
[16:16] <superm1> kees, bryce i was thinking this morning when i came to unlock my keyboard, i wonder if ctrl-alt-backspace is available by default even when locked.  to my surprise it was.  isn't that a bit of a security hole?  someone can go and muck with any of your running apps just by pressing that combination
[16:18] <tseliot> superm1: CTRL+ALT+DEL should work too ;)
[16:19] <superm1> tseliot, no it doesn't.  that only brings up your session log out options
[16:19] <superm1> tseliot, however if you switch to a VT and try it, it does
[16:19] <tseliot> superm1: ok, you can simply press the (physical) "power" button :-P
[16:21] <tseliot> superm1: did you mean that ctrl-alt-backspace works even when "dontzap" is set in the xorg.conf?
[16:21] <superm1> tseliot, but at least for behaviors like that you have things such as bios and power on passwords
[16:21] <superm1> tseliot, no i dont have it in xorg.conf, but i'm saying that it should at least be toggled on the fly in the running session - particularly if you lock your screen
[16:21] <superm1> i'm not sure if that is available however
[16:22] <kees> superm1: it's a bit of a DoS, yeah, but I think the benefits have continued to outweight the down sides
[16:22] <kees> if I could spell
[16:22] <tseliot> superm1: maybe we should allow users to choose to add that option in some UI
[16:23] <superm1> kees, benefits in the sense of debugging and availability to restart an X server when things go wrong you mean?
[16:25] <superm1> tseliot, yeah that would be sensible i think, at least combined with also toggling that behavior automatically when the screen gets locked/unlocked
[16:25] <superm1> but again it begs whether the X server can allow you to change the feature on the fly
[16:25]  * tseliot nods
[16:26] <tseliot> superm1: maybe you could write a blueprint about this so that we can discuss it at the UDS.
[16:27] <superm1> yeah. i can do that (unless someone hear is sure that there is a piece in the chain that won't allow this)
[16:27] <superm1> *hear = here
[16:28] <tseliot> bryce, jcristau: any ideas ^^ ?
[16:29] <kees> superm1: it's been a long-debated config item.  I have no personal opinion, but would want to have it available since I use it (especially on myth when the frontend hangs...)
[16:30] <superm1> kees, yeah i think leaving the default behavior as how it is when sessions are active, but provide a UI capplet for changing it - and then always change it if the screen locks
[16:31] <superm1> it would provide the closest to the same behavior while still helping the problem at hand
[16:31] <superm1> you still get hangs though in myth? i guess i turn off my frontend every night, so if there was say a memory leak that grows over time i wouldn't have seen it =)
[16:32] <kees> superm1: yeah, though I isolated (but have no solved) one of them to exiting xine: xine just kind of doesn't fully quit sometimes.
[16:33] <kees> superm1: and sometimes when trying to start a really giant HD recording it just kind of goes away
[16:33]  * kees shrugs
[16:33] <superm1> kees, ah actually i have seen that in xine, but its infrequent enough that i never bothered to look at it.  just pkill at that point
[16:35] <kees> superm1: yeah, in my .Xsession I've added a little ircat loop that waits for POWER to be pressed on the remote and then kills xine if it's running, and if xine isn't running, kills the frontend.  now I don't have to get up to use ctrl-alt-bkspc.  :)
[17:19] <jcristau> superm1: zap defaults to off upstream now, fwiw
[17:19] <jcristau> so ctrl-alt-bs doesn't do anything
[17:20] <jcristau> not that i think it's a good thing, but hey
[17:45] <superm1> jcristau, so at the ubuntu level, we are intentionally turning it back on, or this was a recent change in defaults?
[17:45] <jcristau> that was post-1.5
[17:47] <superm1> ah okay.  so is there any type of interface exposed for turning it back on that a capplet can stub out?
[17:47] <jcristau> not without changing xorg.conf or the X command line
[17:50] <superm1> and it would probably be a significant amount of work to add a runtime option somewhere in the stack?
[17:52] <jcristau> not really. enable zap, and change its mapping in xkb.
[17:52] <jcristau> it's not hardcoded to ctrl-alt-backspace, aiui
[17:55] <superm1> so just map it to some non-present key, and then remap it to ctrl-alt-backspace when you "turn it on"
[17:55] <jcristau> something like that
[17:55] <jcristau> should work today, even
[18:03] <bryce> superm1: daniels disabled it a few weeks ago.  We'd been discussing in ubuntu to change it to requiring holding it down for several seconds, or beeping or some such; one of the users involved in that discussion went upstream, figuring it should be the same way across distros
[18:04] <bryce> daniels thought it was more sensible to just shut it off by default, and provide it on by default with the -retro option
[18:05] <bryce> superm1: the xorg.conf option editor spec tseliot has worked on will expose the option in a GUI (although it may be too many options for an ordinary user to wade through to get to it)
[18:06] <superm1> bryce, I thought the idea was to be moving away from xorg.conf in general though?
[18:06] <superm1> still for settings like these it makes sense i take it?
[18:06] <bryce> I was thinking maybe rather than expose just the dontzap option, if we could have a toggle for -retro
[18:06] <superm1> so there is a second part to this though, what about VT switching? is that also disabled when you set dontzap?
[18:06] <bryce> superm1: longer term I expect upstream will be making the server and driver options dynamically settable
[18:07] <bryce> dontzap doesn't affect vt switching
[18:07] <bryce> or, if it does, that'd be a bug ;-)
[18:09] <superm1> bryce, okay.  then i think the second part is to just make sure that whatever functionality is allowing you to ctrl-alt-delete from a VT even when X is running gets disabled if X is running
[18:09] <bryce> you mean -backspace?
[18:09] <superm1> no i mean ctrl-alt-delete
[18:09] <superm1> it triggers a restart if you switch to a VT
[18:09] <bryce> ok, that's not handled by X afaik
[18:10] <jcristau> that's handled by the kernel
[18:10] <jcristau> probably only in KD_TEXT though
[18:10] <bryce> yeah
[18:10] <jcristau> or, only when the console is not in raw mode, or something
[18:10] <superm1> i seem to remember that functionality being configurable by something in etc/
[18:11] <superm1> at least what behavior occurs when ctrl-alt-delete is pressed from a console
[18:12] <superm1> etc/event.d/control-alt-delete
[18:20] <superm1> okay i've filed a separate bug about that - bug 300771.  
[18:20] <ubottu> Launchpad bug 300771 in upstart "control-alt-delete should not restart the machine if gdm,kdm, xdm, or X is running" [Undecided,New] https://launchpad.net/bugs/300771
[22:20] <tormod> hi I am trying to build latest intel again (succeeded some weeks ago). now libtool looks for libdrm.la and fails. there is "-ldrm" on the libtool command, don't know how that turns into libdrm.la now and not before. any hints?
[22:27] <bryce> tormod: do you have libdrm 2.4?
[22:27] <tormod> bryce: yes
[22:27] <bryce> ok
[22:54] <tormod> the file list of the libdrm-dev is the same, the libtool command line is the sam
[22:55] <tormod> hmm I should try debian-unstable, it's newer than debian-experimental ...