[02:09] <bandit5432> any ideas on how to get xserver-xorg-video-ivtv to work with xorg egers?
[02:09] <bandit5432> edgers'
[02:14] <RAOF> bandit5432: How does it currently fail?
[02:14] <bandit5432> its depends on Depends: xorg-video-abi-11
[02:15] <RAOF> So you could rebuild it, and see if it builds against the new server.
[02:15] <bandit5432> yes i am slow and have never had this issue 
[02:16] <bandit5432> xorg-core 1.12.1.902 provides xorg-video-abi-12
[02:18] <bandit5432> and all because i wanted to keep testing new kernels
[02:18] <RAOF> You don't need xorg-edgers to test new kernels, though.
[02:18] <bandit5432> if i wanted the nvidia drivers to work i think i did
[02:19] <RAOF> That's quite possible.
[02:19] <RAOF> So you want both the nvidia drivers in xorg-edgers and the ivtv driver to work? :)
[02:20] <RAOF> It would be a simple matter to test if ivtv builds against the 1.12 server - “sudo apt-get build-dep xserver-xorg-video-ivtv && apt-get -b source xserver-xorg-video-ivtv” should do it.
[02:20] <bandit5432> face palms
[02:21] <bandit5432> this is why i still like linux 
=== ubott2 is now known as ubottu
[07:02] <ricotz> bjsnider, thanks for uploading nvidia-settings
[07:09] <mlankhorst> morning all :-)
[07:13] <tjaalton> mlankhorst: morning, you forgot the changelog update from the merge, and perhaps pushed one commit too much (the "hack") :)
[07:13] <mlankhorst> tjaalton: I know, was going to fix it in morning, i pushed old tree accidentally
[07:14] <mlankhorst> thought i was on ubuntu branch, but had a detached head
[07:14] <tjaalton> heh, ok
[07:14] <ricotz> hello all
[07:15] <ricotz> tjaalton, i hope you noticed there is a new xf86-input-wacom 0.15.0
[07:16] <tjaalton> ricotz: nope, don't see any announce mail for it
[07:17] <mlankhorst> is that a jedi mind trick?
[07:17] <ricotz> tjaalton, http://sourceforge.net/projects/linuxwacom/files/xf86-input-wacom/
[07:18] <ricotz> tjaalton, unfortunately it doesnt compile with input abi 17
[07:18] <ricotz> but 16 (1.12) is fine
[07:19] <tjaalton> there's not much that we don't already have
[07:22] <ricotz> ok
[07:24] <mlankhorst> tjaalton: I can't fix the commit description sadly, first it was just disabling debian/patches/series, but this commit just fixes things
[07:25] <tjaalton> mlankhorst: that's ok
[07:26] <mlankhorst> bryceh thought for a while I was pushing things to quantal, but I wouldn't do that as last act for a day :P
[07:30] <tjaalton> a nitpick, the urgency tag got probably copied from debian, but it has basically little meaning for us, so low is used by default
[07:31] <tjaalton> it does bump the build priority a little, but it's basically never used
[07:31] <mlankhorst> oh..
[07:31] <mlankhorst> ok
[07:32] <mlankhorst> yeah I've used it in the past to get ahead of the queue in launchpad ppa, too many dailies were being built at the time :x
[07:55] <mlankhorst> ok so what name for the xorg 1.12 ppa?
[07:57] <tjaalton> what's the rush :)
[07:58] <tjaalton> or use a personal one for now
[07:58] <mlankhorst> sure
[08:09] <mlankhorst> if i upload something to a ppa that hasn't been built yet, and something else that will depend on it at the same time, will the second package wait for the first one to be built or not?
[08:11] <RAOF> mlankhorst: Yes, ish.  You may need to prod it.
[08:11] <tjaalton> yes, it'll wait in dep-wait
[08:11] <tjaalton> or not?
[08:12] <RAOF> In my experience, which may or may not still apply, things in a PPA may stay in dep-wait indefinitely.
[08:12] <tjaalton> ok
[08:12] <mlankhorst> ok :)
[08:15] <mlankhorst> I'll just try some simple things for now, evdev + synaptics + nouveau
[08:40] <mlankhorst> RAOF: what happens to packages like xserver-xorg-input-evdev, it has a ubuntu branch but it doesn't look like it needs it currently any more?
[08:41] <tjaalton> then we sync it
[08:41] <RAOF> mlankhorst: If it's not current, then you get to complain to the last uploader.  If we don't need the ubuntu branch anymore, then we ignore it until we need it again.
[08:41] <tjaalton> but for the ppa you can just grab the debian package and push it so that it's updateable
[08:42] <tjaalton> so if debian has -1, you can push -0ppa1 or such there
[08:43] <mlankhorst> hm was just checking, seems to be a small delta for broken hardware
[08:44] <tjaalton> yeah some quirks?
[08:47] <mlankhorst> tjaalton: yeah although one of them looks like it would belong to kernel
[09:03] <mlankhorst> RAOF: .. maybe I should spend some time on https://bugs.freedesktop.org/show_bug.cgi?id=47266 ?
[09:04] <ubottu> Freedesktop bug 47266 in Server/Acceleration/EXA "Graphics corruption using recent Cairo" [Normal,Reopened: ]
[09:04] <tjaalton> yes, we've got that in quantal now..
[09:26] <mlankhorst> indeed.. if really necessary i could try to backport the exa things past the abi breakage, but I would be more comfortable with a hack to temporarily disable cairo exa acceleration on nouveau
[09:28] <tjaalton> it's the same for ati as well
=== yofel_ is now known as yofel
[09:28] <tjaalton> oh radeon worked around it
[09:31] <mlankhorst> nouveau too, but after the new abi
[09:38] <tjaalton> right
[11:40] <tjaalton> cleaning up the x-updates ppa
[11:40] <mlankhorst> sure
[11:41] <mlankhorst> was working on my h262 stream generator :-)
[11:45] <tjaalton> bjsnider: don't think there's much point in providing updates to maverick anymore, since it's EOL'd
[11:52] <tjaalton> the repository was at 80% quota, dropping the obsolete ones should bring it below 50%
[12:05] <mlankhorst> mdeslaur: nice exit code :P
[12:06] <mdeslaur> mlankhorst: hehe :)
[12:10] <jcristau> mdeslaur: hi.  have you guys worked on CVE-2012-2118 yet?
[12:10] <ubottu> Format string vulnerability in the LogVHdrMessageVerb function in os/log.c in X.Org X11 1.11 allows attackers to cause a denial of service or possibly execute arbitrary code via format string specifiers in an input device name. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2118)
[12:10] <jcristau> trying to avoid double work if possible :)
[12:11] <mdeslaur> jcristau: no, it's low priority for us, so we haven't started yet
[12:11] <jcristau> ok
[12:28] <mlankhorst> X isn't compiled with SSP?
[12:29] <jcristau> not in squeeze
[12:40] <mdeslaur> jcristau: in case you didn't see it, there a bug open with a patch: bug 996250
[12:40] <ubottu> Launchpad bug 996250 in xorg-server (Ubuntu Hardy) "input device names used in logging format strings" [Undecided,New] https://launchpad.net/bugs/996250
[12:43] <jcristau> ta.  i'll see how that applies to 1.7.
=== seb128 is now known as robert_ancell
=== robert_ancell is now known as seb128
[17:05] <seb128> cnd, hey
[17:05] <cnd> seb128, howdy
[17:05] <seb128> cnd, bug #997630 you removed utouch, but the stracktrace (https://launchpadlibrarian.net/105053932/gdb-evince.txt) shows it's hanging in a select() call from libutouch-geis
[17:05] <ubottu> Launchpad bug 997630 in evince (Ubuntu) "[precise] evince and eog broken on remote sessions (X, NX, x2go and VNC)" [Undecided,Confirmed] https://launchpad.net/bugs/997630
[17:06] <cnd> seb128, yeah, I'm trying to figure out who is still on my team and who can be allocated to that (and a few other) bug
[17:06] <seb128> cnd, ok, I was just wondering why you removed the utouch part
[17:06] <cnd> I'm cleaning up all the utouch bugs and generating a report so I can start to assign bugs to people
[17:07] <cnd> seb128, oh, because utouch is a meta project
[17:07] <cnd> libgrip or utouch-geis are the likely real culprits
[17:07] <seb128> cnd, can I reassing to utouch-geis then?
[17:07] <cnd> you might as well leave it at libgrip for now
[17:07] <cnd> we can switch to utouch-geis if we find that the issue is there
[17:07] <seb128> cnd, well the ubuntu part is on evince (ubuntu)
[17:07] <seb128> cnd, I'm pretty sure it's not an evince issue...
[17:07] <cnd> you can switch the ubuntu part to libgrip (ubuntu) then
[17:08] <seb128> cnd, thanks
[17:08] <cnd> actually, yo umight as well switch them to utouch-geis
[17:08] <cnd> it's most likely a geis issue
[17:08] <cnd> doesn't matter too much either way right now
[17:08] <seb128> cnd, I've made it "also affect libgrip" and I'm setting the evince component invalid, that will let visibility on both sides
[17:08] <cnd> ok
[17:08] <seb128> cnd, done, thank you!
[17:08] <cnd> np
[17:09] <cnd> bryceh, how do I run the arsenal scripts again? it can't find the arsenal lib
[17:10] <bryceh> cnd, ?
[17:10] <cnd> cndougla@cndougla:/tmp/arsenal/scripts$ ./get_touch_bugs.py 
[17:10] <cnd> Traceback (most recent call last):
[17:10] <cnd>   File "./get_touch_bugs.py", line 25, in <module>
[17:10] <cnd>     from arsenal.arsenal_lib import ArsenalBug, bugtask_as_dict
[17:10] <cnd> ImportError: No module named arsenal.arsenal_lib
[17:10] <bryceh> did you install it or are you running from the bzr tree?
[17:11] <cnd> I'm running from the bzr tree
[17:11] <cnd> is it available to be installed from somewhere?
[17:11] <cnd> I thought it wasn't packaged before
[17:11] <bryceh> it's packaged as of yesterday :-)
[17:11] <cnd> heh
[17:11] <bryceh> however, running from bzr works for me here
[17:12] <cnd> probably because you have it installed
[17:12] <bryceh> both running ./scripts/get_touch_bugs.py and from run inside scripts
[17:12] <bryceh> possibly, yeah
[17:12] <cnd> so what do I need to do?
[17:12] <bryceh> ok so  I do have a fix for this
[17:12] <bryceh> in the script copy in these lines up towards the top before the  import statements
[17:13] <bryceh> import sys, os
[17:13] <bryceh> sys.path.insert(0, os.path.realpath(
[17:13] <bryceh>         os.path.join(os.path.dirname(__file__), "..")))
[17:13] <bryceh> then you should be able to run it from bzr, without having it installed
[17:13] <cnd> great
[17:13] <cnd> thanks
[20:16] <bryceh> mlankhorst, <tgardner> bryceh, I've uploaded Quantal kernel and meta package backports to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[20:16] <bryceh> mlankhorst, let's chat tomorrow about getting a renamed X stack into the ppa
[20:17] <mlankhorst> what renamed x stack, we're still on the old precise one :-)
[20:18] <bryceh> right; we can just rename the existing stack as a "pretend" stack just for the practice to test the upgrade procedure
[20:18] <mlankhorst> hm true
[20:19] <bryceh> in fact it'd help isolate problems if we know the actual X code is unchanged; we'd know that issues are likely being caused by the mere rename
[20:20] <mlankhorst> bryceh: yeah we need to exclude the packages we're not going to rename though
[20:22] <Sarvatt> Prf_Jakob: that commit message confused me :)
[20:23] <Sarvatt> thought i merged the wrong tag
[20:23] <tjaalton> mlankhorst, bryceh: speaking of which http://pastebin.com/wfNE6LTT
[20:24] <mlankhorst> tjaalton: eod, not looking ;)
[20:25] <tjaalton> mlankhorst: tl;dr, the drivers having depends on the abi virtual package and a versioned depends on the xserver might make the renames a no-go
[20:25] <tjaalton> unless the deps are relaxed
[21:18] <bjsnider> tjaalton, you mean edgers?
[21:20] <tjaalton> bjsnider: no, x-updates, the nvidia ones for maverick..
[21:20] <tjaalton> i just went ahead and deleted them, hope you don't mind :P
[21:20] <bjsnider> i would love to stop adding the old distros
[21:21] <tjaalton> please do
[21:21] <tjaalton> at least for the ones that are no longer supported
[21:21] <bjsnider> as long as someone deals with the angry emails
[21:21] <tjaalton> hehe
[21:22] <bjsnider> "i'm still using maverick because my hardware, that nobody's ever heard of, works with it and nothing else!"
[21:23] <tjaalton> that's the way it goes..
[21:24] <Sarvatt> bjsnider: all the maverick excuses i get are unity
[21:25] <bjsnider> in other words, it's unity-free?
[21:25] <Sarvatt> yeah
[21:25] <tjaalton> right, natty got the first version
[21:25] <Sarvatt> natty also had old gnome though :P
[21:26] <tjaalton> true
[21:26] <Sarvatt> i want to install crack drivers but dont know how to change my desktop session!
[21:27] <bjsnider> can we drop lucid too?
[21:28] <Sarvatt> ya can stop updating it of course, better to keep the packages in there though
[21:28] <tjaalton> yeah
[21:29] <Sarvatt> thats gotta be the biggest pain to update :(
[21:29] <Sarvatt> so much changed in the blob packaging every release after 10.04, that was the first with the gl alternatives
[21:29] <tjaalton> also kinda the most important one, though we have the new lts now
[21:29] <Sarvatt> but then again just reusing packaging and throwing the new .run's in it works :P
[21:29] <bjsnider> doesn't one lts replace another, or how long is llucid supported?
[21:30] <Sarvatt> another year on the desktop
[21:30] <Sarvatt> lucid to precise doesnt even start getting offered till june or july
[21:32] <Sarvatt> all the features getting ripped out of xf86-input-synaptics killed KDE
[21:32] <tjaalton> it got pushed to august
[21:32] <tjaalton> .1
[21:32] <tjaalton> Sarvatt: hah
[21:32] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/synaptiks/+bug/1002736
[21:32] <ubottu> Launchpad bug 1002736 in synaptiks (Ubuntu) "[xorg-edgers] Synaptics driver crashes KDE touchpad control module" [Undecided,New]
[21:36] <Prf_Jakob> Sarvatt: which one?
[21:36] <Prf_Jakob> Or do you mean the announce message?
[21:36] <Sarvatt> Prf_Jakob: http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=3a828d876772d05577b9372e8f6dc068794f4704 :)
[21:37] <Prf_Jakob> Sarvatt: -ECOPYPASTE
[21:37] <Sarvatt> 12.8.0
[21:45] <cnd> RAOF, would you be able to help with some SRU stuff?
[21:46] <cnd> I've done verification testing on utouch-geis in precise-proposed, so it can be copied to precise-updates
[21:47] <cnd> it also needs to be copied to quantal, since it was uploaded after the archive branch but before quantal was open
[21:47] <cnd> also, there's an SRU for xserver-xorg-input-evdev that needs to be approved for precise-updates
[22:22] <kees> mdeslaur: jcristau: hrm? I ported the fix to precise and added it to the bug during uds
[22:23] <kees> mdeslaur, jcristau: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/996250
[22:23] <ubottu> Launchpad bug 996250 in xorg-server (Ubuntu Hardy) "input device names used in logging format strings" [Undecided,New]
[22:50] <RAOF> cnd: Yup. I'm going to sweep the SRU queue today.
[23:07] <cnd> RAOF, thanks :)
[23:08] <cnd> RAOF, for the -evdev upload, that will need to be pocket copied to quantal too
[23:08] <RAOF> Ok.
[23:08] <cnd> should that happen when it is approved for precise-proposed?
[23:09] <cnd> or when it is copied to precise-updates?
[23:20] <mdeslaur> kees: yes, I mentioned the bug having a patch
[23:25] <kees> mdeslaur: ah-ha, cool