[03:23] Sarvatt: Do you have any insights into why we have xserver-xorg-video-radeonhd in the archive? [03:24] some people still use it, it's certainly more maintained than half the other video drivers.. :D [03:27] I guess so. [03:27] It doesn't work with KMS, though. [03:29] I guess we're not going to remove it, so we should rebuild it. [03:30] Hm. Actually, we can remove it. [03:34] yeah it can be dropped now [03:34] we pulled it in back when there was a lot of excitement about it, but really haven't done anything with it [03:34] and in fact I think I already unsubbed ubuntu-x@ from its bug tracker (and I think I wontfixed all its bugs) [03:36] You didn't wontfix them, but I've just confirmed & sub'd ubuntu-archive on the removal bug. [03:36] ok [03:37] well, the bugs certainly can be wontfixed now :-) [03:38] Yup :) [03:53] oh man, that canonical-desktop-team/une ppa trashed things :) [03:54] think i'll hold off on indicator-appmenu until its in maverick [03:54] cant launch my most used app with it (geany) [03:57] Sarvatt: unity is in the maverick repos now [03:57] appmenu-gtk isn't though [03:57] i can't find libappmenu.so in any package [03:58] was trying to follow the ubuntu desktop installation section on here - https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu [03:59] Damn, still can't downgrade from xorg-edgers yet. [04:00] Yup. We're beavering away solidly at that. [04:10] hmm [04:10] Source: xserver-xorg-video-glide [04:10] build depends on libglide2-dev [04:10] Package: libglide2-dev [04:10] Section: libdevel [04:10] Architecture: i386 [04:11] fails on amd64 [04:46] [ 46933.281] xorg-server 2:1.8.99.0+git20100609.8e97e5f9-0ubuntu0sarvatt (For technical support please see http://www.ubuntu.com/support) [04:46] hmm that looks kind of out of place for xorg-edgers :) [04:47] xserver 1.9 PPA looks good to go though, just need to refresh the nouveau autoconfig patch [04:47] Score. [04:48] the BGNR stuff is all busted though, could be problems in maverick :) [04:48] Maybe hang back a little bit on the update until people can downgrade. [04:48] oh yeah it'd be a week or two before i did it, its not even branched yet still [04:48] It got sent upstream, though, so that's +1 [04:49] yeah had to ask 3 different people if they'd upstream it in the past few months since noone knew who originally wrote it and airlied did the other day \o/ [04:49] Once we *have* got maverick upgradable feel free to break everyone's X using -edgers. There shouldn't be any ABI changes at this point, so 1.9 is good to go! [04:49] the bgnr patch that got sent to the lists breaks the video abi [04:56] Yeah, wait a bit on 1.9. I'm still unable to downgrade from xorg-edgers due to unfinished X migration in maverick [05:13] ripps: i wouldn't, dont worry :) [05:14] and yeah it stinks, i have 9 machines here and can't test stock maverick on any of them, lucid ones cant upgrade to maverick, maverick ones are all on edgers because I was testing upgrades and cant downgrade [05:15] xorg metapackage really needs to be updated so people can just remove xserver-xorg-{video,input}-all and actually upgrade maverick now [05:17] but xserver-xorg-core still needs wacom and i didnt have any luck with that merge, that package is such a PITA [05:19] Sarvatt: You don't have any wacom hardware, do you? [05:19] yeah i've got 2 tablets [05:20] i use that from git regardless of what i'm on though, too many fixes going into it too fast [05:23] I have to rebuild my wacom module every linux update now, kernel doesn't have support for bamboo ctl-460. I wrote a script that builds, loads, and configures it automatically. [05:26] ripps: checked linux-input to see if they submitted it upstream even yet? [05:42] Sarvatt: the last wacom patch was on april 21 [05:52] Does anybody know how make a kernel module backport package? I might be able to help some people by just having a package they can install easily. [05:54] Even better, how to make a dkms package. [05:56] they haven't even tried sending them upstream :( [05:56] just looked at the last 6 months of linux-input on patchwork.kernel.org [05:57] what was the deviceid again? 00d4? [05:59] 0xd4 works with xf86-input-wacom, just not the darn kernel module [05:59] maybe fedora patches it in their kernel, lessee [06:04] Sarvatt: ah, seems i overdid my phc, which caused the hang yesterday. [06:04] lol ok that makes more sense [06:05] was wondering why i couldn't find anything [06:59] thats odd, getting [ 46933.277] 1 XSELINUXs still allocated at reset in Xorg.0.log even though i'm building with --disable-xselinux [07:09] Sarvatt: want to try a new xserver-xorg-input-wacom? [07:09] yep throw it at me :) [07:09] www.cooperteam.net [07:10] amd64... :D [07:10] only machine on amd64 is on lucid [07:11] Have a source package, then. [07:12] grabbing it, with that i should be able to downgrade to stock maverick if xorg built [07:13] debian/local should go [07:14] Oh, totally. [07:14] Whoops, forgot about that. [07:16] Fixed. [07:19] looks good to me [07:20] built fine, files in the debs are right, and it works :) [07:21] the udev rules probably could use some updating but might as well keep it the same as debian, only the serial part setting ID_INPUT_TABLET is needed anymore [07:22] Oh, really? [07:23] yeah the rest is done by the snippet [07:24] but it works as it is, no point changing it really [07:25] is the ntrig device in 50-wacom.conf the same as we added? i can't remember [07:26] yep it is [07:26] looks good to me! [07:27] Yeah. And they've also dropped the tablet thingy that doesn't have a kernel driver. [07:27] With that, coffee time. [07:28] Thanks for testing! [07:29] might as well just do no change rebuilds of nvidia-graphics-drivers* too? [07:29] No; I want to mess with their apport scripts. [07:30] trying to see how we can add IgnoreABI to the xorg.conf installed by 173 to make it work [07:30] planning on doing that today though? people with it installed have broken package managers until its rebuilt? [07:30] Planning on doing it after coffee. [07:31] It won't take long. [07:32] oh okie! [07:32] what the heck package is the xorg.conf generated in [07:35] ah jockey [07:41] jockey needs something like this [07:41] if self.version == '173': [07:41] self.xorg_conf.addOption('ServerFlags', 'IgnoreABI', 'True', optiontype='Option', position=0) [07:49] awesome, they're talking about doing video device matching with xorg.conf.d snippets upstream [08:06] Sarvatt: And it works properly with IgnoreABI? [09:02] yeah it does [09:02] http://aur.archlinux.org/packages/xorg-server-1.8-catalyst-maximize-fix/xorg-server-1.8-catalyst-maximize-fix/fglrx-xorg-version.patch [09:03] so yeah, bug against fglrx-installer asking us to pick that patch up to make fglrx work with xserver 1.8 [09:03] gave me a good laugh before sleep :D [09:03] No. [09:03] :) [10:27] RAOF: Hi! [10:27] alf__: Yo! [10:28] RAOF: What is the current status of mesa-egl on maverick? [10:29] Waiting for me to finalise the packaging of unrelated parts of mesa. [10:29] It's been lower-priority with the xserver transition. [10:30] RAOF: I can imagine :) [10:30] it'd be worth investigating the changes in 7.9 too since thats the target in maverick and its *completely* different than 7.8 there [10:32] Right. I was going to do that, too. [10:32] * Sarvatt tries building git with origin/ubuntu again to see whats u0 [10:32] up [10:33] RAOF: Any ETA on mesa-egl maverick? [10:42] alf__: Is it blocking your work? [10:43] RAOF: Without it we have to do work on lucid instead of maverick [10:44] RAOF: So, yes and no :) [10:45] The packages in the mesa-egl ppa will build & work on maverick. I can make maverick archive packages a priority if you like. [10:46] RAOF: If that isn't too much trouble it would be great! [10:47] it won't for long because libdrm will be updated any time now and it wont build against 2.4.21 [10:47] :S [10:52] Yay! libkms will now build against the in-tree headers. [10:54] well, we could disable nouveau until 7.9 [10:55] waouh, new xorg works on my mini10v [10:56] Or pull in an appropriate nouveau_class.h [10:56] it just broke gnome-screensaver idle detection or something, when it starts locking moving the mouse doesn't stop it [10:59] Hm. I haven't seen that. [11:00] seb128: you mean like a fade out before locking? [11:01] * Sarvatt doesn't use gnome-screensaver so not sure [11:01] the fade when locking was disabled in gnome-screensaver recently i think though, might have something to do with it? [11:02] when it starts locking after idle usually you can undo the locking by moving the mouse [11:02] that working this morning and I just upgraded the xorg stack [11:02] ie sudo apt-get install xserver-xorg [11:15] odd, it works here [11:16] aspire one netbook but i'm using xorg-edgers [12:00] oh joy, this again [12:00] Fatal server error: [12:00] [ 2826.174] Caught signal 3 (Quit). Server aborting [12:05] What fun! [12:06] sigquit knew you missed it, so it decided to come back? [12:17] jcristau: So, final stab at libgl1-mesa-dri-experimental. Nouveau's happy to go in there, but for radeong one of four things needs to happen: 1) it doesn't go in there at all, 2) the package conflicts with libgl1-mesa-dri, 3) dpkg-divert rears its ugly head, 4) alternatives madness! [12:17] jcristau: I lean towards 1). [12:17] Do you have any strong opinion here? [12:35] 1 seems best. [12:36] 3 i very much dislike [12:44] Yup. Good. === lifeless_ is now known as lifeless === \vish is now known as vish [18:47] RAOF: is it safe to update maverick yet? [19:03] kees, think he's asleep for a few more hours [19:04] however looking at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html it appears all the video drivers are merged in now, so I'll bet it's safe [19:05] (for the usual alpha-2 definition of the word 'safe') [19:08] bryceh: ah, cool. thanks! [19:13] kees, your comment break... http://launchpadlibrarian.net/50085515/break2.png [19:13] bbiab (dr appt) [19:16] xserver-xorg-video-fbdev is still holding back my xorg-edgers downgrade [19:19] its stuck in NEW because of the udeb [19:20] bryceh: rock! [19:24] I don't really understand the deal wit udebs [19:26] that's fine, you don't have to. [20:12] jcristau: it ok if I merge libdrm 2.4.21 in experimental? already have it done and test built locally - http://sarvatt.com/git/cgit.cgi/libdrm/ [20:13] should be fine i think [20:35] with maverick can I have two mouse cursors yet? [20:36] you can with lucid. [20:38] jcristau, how? [20:43] http://lwn.net/Articles/283957/ [20:44] hey guys, i realise this is a dumbass qusetion most likley [20:45] https://launchpad.net/~ubuntu-x-swat/+archive/x-updates [20:45] thats an official, or at least known/run by ubuntu folks repo [20:45] ie you guys, right? [20:45] yep, whats up? [20:46] well im looking to update the nvidia drivers [20:46] from .15 to .24 [20:46] and im just wondering how safe it is [20:46] not really game to roll the dice much on this machine as i use it for work [20:47] .24 isn't in there [20:47] ok well, that answers that then [20:47] not sure why i thought itwas [20:47] ;) [20:47] it's got 256.29 (the newest beta release) [20:47] ah [20:48] I think 195.24 is in -proposed? or did that never get pushed to lucid? [20:48] do you know if these dirvers will eventually make it to the main ubuntu repos? [20:48] yeah its still proposed afaik [20:48] not for already released ones most likely but for the development version yeah [20:49] so if im understanding you correctly, i will never get a driver update from the default ubuntu repos [20:49] that accurate? [20:50] pretty much for the binary blob driver, yeah :( [20:51] np, just want to understand [20:51] ill probabluy image this install [20:51] then roll the dice on one of the updated drivers ;) [20:51] Is the facility to just plug two mice in and get two pointers going to be in maverick? [20:53] chek0v: there is a package you can install in that PPA that will completely remove it [20:53] sudo apt-get install ppa-purge && sudo ppa-purge -p x-updates ubuntu-x-swat [20:53] it'll revert everything back to the stock ubuntu packages [20:53] so theres not really any harm in trying it [20:54] ahh roger [20:54] thanks for that [20:54] ripps: pitti just pushed fbdev through NEW so it should be all set here soon [21:04] Sarvatt: the LIBADD part of the libkms patch needs to stay afaict [21:05] oh you're right, unresolved symbols [21:09] let me know when you've fixed that i'll get the package in NEW. [21:19] ok fixing it up now, just figuring out how i should do it.. add RAOF's changelog entry back? [21:20] refreshed it here - http://sarvatt.com/downloads/patches/02_build_libkms_against_in_tree_drm.diff [21:23] yeah just remove the part about cflags [21:23] and it'll be good [21:28] http://sarvatt.com/downloads/libdrm.patch -- that look good or should I change the release target to experimental? [21:42] looks ok [21:42] i'm updating the copyright file. it's a pita. [21:49] hmm, can't just add Copyright © 2009 VMware, Inc., Palo Alto, CA., USA to it? [21:49] there's lots of minimally different versions of the license [21:50] including ones with typos. or ones which say 'copyright marcheu. va linux systems is not liable.' [21:51] radeon_bo_int.h radeon_cs_int.h and radeon_cs.c arent even licensed [21:53] i love how it says 'this permission notice (including the next paragraph) shall be included' except they reordered them so there's no next paragraph :) [21:53] lol [21:53] which one did that? [21:53] that's all over the radeon stuff [21:54] ah why am i not surprised [21:58] updating the copyrights in mesa/demos is going to be nightmare inducing [22:12] Sarvatt: the radeon bof stuff looks like it should be hidden [22:12] radeon/bof.h is not installed anywhere [22:14] oh? i need to read the library packaging guide some more, didn't know that [22:16] i'm hacking around it but ideally it should be fixed upstream.. [22:18] * ripps is testing a wacom-dkms package [22:31] woot! it worked [22:31] uploading to my ppa, so others can use it. [22:43] nice ripps! the wacom kernel module not supporting any entry level tablets from the last year or so is a pretty common complaint [22:44] Sarvatt: ppa:ripps818/ppa, I'm going to bed now, so after there done building. Take a look at them. [22:47] two versions: maverick has a patch that changes usb_buffer_alloc to usb_alloc_coherent and usb_buffer_free to usb_free_coherent, because apparently somebody changed the kernel api with telling anybody. Lucid version is unpatched, and should work with older versions of 2.6.30+ kernels. [22:47] g'night [22:47] nite