[12:57] alioth (git.d.o) down [14:11] I'm preparing a security fix for CVE-2011-4613 in xorg. Debian fixed the issue by backing out a change that we added for starting X directly from within upstart wihout using a display manager. [14:11] mdeslaur: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4613) [14:11] Is anyone aware of anything that actually uses that that could get regressions from that update? [14:11] bryce: ^ [14:12] (fyi, this is the CVE: http://www.debian.org/security/2011/dsa-2364) [14:14] meh, git.d.o is down, can't check what the change was [14:15] i'm not, fwiw [14:15] tjaalton: basically this: http://paste.ubuntu.com/807415/ [14:15] jcristau: hi! [14:16] hi mdeslaur [14:16] jcristau: I can't seem to locate anybody who remembers the exact reason we had added that change in the first place :P [14:17] i talked to lool when i did the revert [14:17] he agreed it was the right thing to do [14:17] yeah, I talked to him too, and he can't recall the exact use case [14:17] ok :) [14:18] I agree it's the right thing to do, I'm just trying to figure out what the use case was that I will be breaking :P [14:18] all I can think of that wouldn't use a display manager would be some oem project, maybe unity light or something [14:19] that was over three years ago [14:19] well before unity [14:19] ah right [14:19] oem [14:19] whoops, I meant ubuntu light [14:19] yeah [14:39] mdeslaur: I think this predates ubuntu light, but it might have been in some moblin / maemo / moblin 2 / meego based projects ; albeit I suspect none of them shipped, but ICBW [14:39] it's hard to tell whether some hacks might have been used at a later date or not [14:40] lool: hi! well, in theory the oem stuff should vet updates before they are pushed, so I'll just put them in -proposed for a week or two and make sure nothing terrible happens [14:40] mdeslaur: I think that's fair [14:40] lool: thanks [14:40] mdeslaur: Also, I believe OEM is not pulling updates which concern only local root exploits on single-user devices such as netbooks [14:43] lool: don't say stuff like that, you make me sad :) [14:44] oh sorry [14:46] because clearly there's never any code execution flaw in, say, browsers, that would turn a local root into a remote root [14:47] * jcristau hides [14:47] :) [15:54] tjaalton, libwacom has a new upstream tarball btw if you want to do the update while you fix the copyright and reupload ;-) [15:58] seb128: yeah I noticed that it got rejected [16:55] seb128: are you planning on putting the new g-c-c in precise? [16:56] tjaalton, no [16:56] why? [16:56] just wondering why the interest in libwacom :) [16:57] it helps for those of us who work on GNOME patches and want to build g-c-c from git [16:57] ok [16:57] hmm, can't seem to work out a watch file for it [16:57] we don't need to jhbuild or do a git build of libwacom [16:58] just copy any GNOME one? [16:58] i.e [16:58] version=3 [16:58] http://ftp.gnome.org/pub/GNOME/sources/libwacom/([\d\.]+[02468])/ \ [16:58] libwacom-(.*)\.tar\.xz [16:58] ? [16:58] it's hosted on sourceforge.. [16:58] as a subdir on linuxwacom [16:59] well [16:59] http://ftp.acc.umu.se/pub/GNOME/sources/libwacom/ [16:59] it's mirrored there then, track the GNOME side? [16:59] .xz [16:59] do we support that yet? [16:59] sourceforge has only .bz2 [16:59] yes, since oneiric at least [16:59] GNOME does .xz only since this cycle [17:00] ok [17:00] tjaalton: "http://sf.net/linuxwacom/ libwacom-(.*)\.tar.gz" doesn't work? [17:00] s/gz/bz2/ [17:01] nope [17:01] with or without the space :) [17:02] hmm. http://qa.debian.org/watch/sf.php/linuxwacom/ has a libwacom tarball, but maybe it's ood [17:02] yeah, it is [17:03] oh well, I'll see what the status is tomorrow, maybe even alioth is up again :) [17:03] ah, is already [17:04] yep, came back up a few minutes ago [17:05] that's nice [17:06] seb128: I'll have it done tomorrow, just the copyright left to fix [17:12] tjaalton, thanks [20:23] i filed a bug about automatic detection not working properly (https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/888134) a couple of months ago. i just now figured out that it's a problem with either only with awesomewm, or with all non-unity/gnome ones - i'm not really sure what else to do to try and debug it, or find a fix - is there anyone that can point me in the right direction? [20:23] Launchpad bug 888134 in gnome-desktop3 (Ubuntu) "automatic detection of plugged in / removed monitor is too aggressive (affects: 1) (heat: 6)" [High,Incomplete] [20:34] mdeslaur, right that's the old mid stuff [20:34] bryce: ok, so nothing to worry about? [20:34] mdeslaur, they used to launch ubuntu on those devices using a startx type script rather than a display manager [20:35] mdeslaur, let me dig up some background info just to fill in all the details but yeah I'm sure that's utterly obsolete by now [20:36] mdeslaur, http://irclogs.ubuntu.com/2008/09/08/%23ubuntu-devel.txt start around 10:47 [20:36] mdeslaur, that was one of the hacks to get poulsbo working [20:37] bryce: awesome, old stuff...thanks! [20:37] mdeslaur, which we no longer maintain in the distro, so I believe it can be killed with fire with no prob. [20:41] cool [20:43] mdeslaur: for precise, we could just merge xorg [20:44] ? [20:46] tjaalton: yeah, that sounds good [20:47] mdeslaur: ok, I could prepare that tomorrow if that's fine [20:48] tjaalton: that wouldbe awesome, thanks! [20:52] hmm actually, I'll check it the staging ppa already has it [21:02] nope [21:03] maybe this should be uploaded there first [22:29] RAOF, I *think* all the input-related stuff is in ppa:canonical-x/x-staging [22:30] in the email I sent out, I mentioned having to rebuild utouch-grail, but that isn't the case [22:30] I also added the breaks clause for xorg-server myself [22:30] so now it just needs all the other bits that you can upload (and for the build queue to fall down so something will actually build) [22:33] cnd: Awesome. [22:34] RAOF, we may be able to do a syncpackage for libxi and libx11 [22:34] I haven't looked into it [22:34] From Debian? I'll check. [22:35] the bug there is that we have x11proto-input-dev 2.1.99.4.really.2.0.2-0ubuntu1 [22:35] and most of the debian libs depend on >= 2.1.99.3 [22:35] so if we want to sync with debian, we need to bump the depends in debian :( [22:35] to x11proto-input-dev >= 2.1.99.5 [22:36] I'm going to switch to upstream synaptics multitouch work now [22:36] Cool. [22:36] I can take it from here. [22:37] Ah, we've even got the Qt in there. [22:37] Magnificent. [22:38] Heh. 1 package building: qt4, armhf. [22:38] I guess that buildd will be ready to do something else tomorrow :) [22:47] the buildd's seem slow again today [22:47] (at least for ppas) [22:48] armhf is motoring along. [22:49] But that would be becuase general PPAs don't get to build on arm :) [22:52] RAOF, and on top of that, armhf is new and I had to specifically ask for it [22:52] there's probably only two or three PPAs with armhf turned on :) [22:52] Do we need to build for both armel and armhf, or just armhf? [22:53] RAOF, it's covered in ubuntu-devel, but they aren't sure yet if they want to support armhf or armel for the LTS yet [22:53] ogra insisted we build for armhf [22:54] Yeah, I saw he wanted us to additionally build armhf. The PPA is only building armhf, though. [22:55] oh, hrmph [22:55] let me ping the lp folks again [22:55] Ah, there's more to that thread I haven't read yet. [23:13] cnd: the upload all at once and let depwait fix it really fails in PPAs where we dont have auto retries for depwait, they need manual retries that are automatically at the end of the build queue and scored lower [23:13] makes lots of sense to upload protos, wait for published, repeat for libs then server then driver [23:14] s [23:14] with the bonus that build depends dont matter that way :P [23:15] Sarvatt, I planned on watching the ppas and retrying :) [23:16] they go to the end of a 9 hour queue with a retry, at least new uploads are scored a bit higher :( [23:16] heck maybe we should make the ppa private for a bit, then it'd get like +10000 build score and skip the queues :) [23:17] heh [23:18] they were going to make it private, but I didn't like the idea of a private ppa for ubuntu-specific content [23:19] cnd: this stuff is going to be copied into ubuntu right? [23:19] yeah [23:19] RAOF, all the arches should be turned on now [23:19] xserver-xorg-input-synaptics 1.5.0+git20120101-1ubuntu1~nomt3 [23:19] ~nomt3? [23:20] Sarvatt, that ~nomt3 was meant to be temporary, it probably will be whacked off [23:20] the initial X upload may be without the multitouch on trackpads [23:20] cause I'm working on that right now :) [23:21] I don't mind having a ~nomt upload to the archive. But given the PPA queue you'll probably have a fair amount of time to work on synaptics MT before it's an issue :) [23:23] multitouch seems to be working with 1.12 and synaptics from git with debian's debian/ [23:24] Event code 334 (BTN_TOOL_TRIPLETAP) [23:24] Event code 335 (BTN_TOOL_QUADTAP) [23:24] * Sarvatt tries to figure out how to really test it [23:29] Sarvatt, that's not multitouch :) [23:29] that's multifinger [23:45] 4 finger taps were supported before? [23:48] yeah http://cgit.freedesktop.org/~whot/multitouch agrees on the no multitouch aspect :P [23:53] RAOF: wow, 2 nights in hotels between flights? [23:54] Yup. [23:54] It was awesome. [23:59] RAOF, did they let you have your luggage?