[01:57] RAOF, I tried merging my stuff into the debian-unstable packaging branch to make a package of my server [01:57] but I get the following: http://paste.ubuntu.com/769629/ [01:57] I have to leave for the day, but if you have some spare cycles I'd appreciate if you could help me out with it [01:58] thanks! [04:34] cnd: Looks like you've missed dropping the libaudit-dev selinux stuff, off the top of my head. [04:50] tjaalton, tumbleweed: after downloading the latest daily build last night and zsyncing this morning I burnt it to usb and just tried it out [04:51] unfortunately I still get the screen with the big white blocks [04:52] for the record, the daily build was downloaded from http://cdimage.ubuntu.com/daily-live/current/precise-desktop-i386.iso.zsync [05:31] RAOF, so I just need to drop that from the control file and everything will be peachy? [07:20] inetpro: ok [10:44] RAOF: do you have the changes to -savage stashed in your local tree? :) [10:45] Do I have changes to -savage? :) [10:45] pushed to natty at least :) [10:45] hmm [10:45] wait [10:46] right, the ubuntu branch is missing a couple of changes [10:46] Yes indeed. [10:46] It's actually missing those changes localy, too. [10:46] hehe, ok [10:47] i was just looking if it could be synced [10:47] Looks like the answer is yes. [10:54] bz.kernel.org doesn't seem to work [10:55] kernel bugzilla has been down since the compromise [10:55] oh ok [10:55] who needs it anyway.. [11:11] ricotz: apparently libwacom will be used by the driver too, it's the only place where tool/id handling in being done (in the future) [11:12] tjaalton, this sounds reasonable [11:17] Hi there all -would anyone be able to advise me on a slightly mysterious xorg problem I'm having? After running an apt-get upgrade yesterday, my machine's refused to load the xserver-xorg-video-intel driver. I'm using the xorg-edgers PPA, but removing this and downgrading hasn't helped either. [11:22] tjaalton, so you think it fits into pkg-xorg? [11:23] ricotz: maybe ron will take it when -wacom needs it [11:23] mistertim_, you should pastbin your Xorg.0.log which might contains something useful so someone can look at it [11:23] ricotz: in the meantime I'll push it to my local repo, which will be writable by pkg-xorg like the -wacom one [11:24] tjaalton, ok [11:24] * ricotz isnt member of pkg-xorg [11:26] ricotz: no problem, here you go: http://pastebin.com/iUkZsAyg. Here's the output of lshw -c video, note output of driver=i915 in configuration line: http://pastebin.com/HykfCffs [11:26] thank you! [11:27] s/output of/absence of/ [11:28] mistertim_: you're disabling kms. don't do that. [11:29] jcristau: aah! I thought I'd re-enabled it [11:30] I removed nomodeset and i915.modeset=0 from /etc/default/grub [11:30] hmm: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force" [11:31] run update-grub [11:31] very odd. Is there anywhere else it might be picking up those options from? [11:31] jristau: aah, d'oh. [11:31] thank you! [11:34] jcristau: that did the trick, thankyou! [11:34] ls === yofel_ is now known as yofel === dzan|away is now known as dzan === dzan is now known as dzan|away [16:38] What ho x lovers. [16:39] Given an install of Ubuntu on a portable device such as a USB stick, where nvidia-current has been installed to support ION hardware, with no xorg.conf configured. Taking the USB stick to another non-nvidia system (e.g. intel) causes the 'wrong' glx libs to load. [16:39] Is there any way (other than removing nvidia binary driver) to not let that happen? So a stick works seamlessly auto detecting and doing glx lovelyness on any card ? [16:45] popey: without having tested this at all, dropping http://paste.ubuntu.com/770234/ into /etc/init/glx-detect.conf may do something reasonable [16:45] but the logic in there is pretty fallible (e.g. hybrid graphics systems) [16:45] popey: outside of an upstart script that calls update-alternatives/ldconfig on the fly at boot which will make people complain about boot speed problems, not really [16:45] oh cool broder already did it :) [16:45] You guys rock. [16:45] it's just a modification of the one i sent out to ubuntu-x :) [16:45] This is for a demo, so doesn't need to be for public consumption [16:46] oh yeah - it does need to call ldconfig, too [16:48] ...hmm, is gl_conf out of date? looks like its x86_64-linux-gnu_GL.conf now [16:51] hmm that upstart script would be messed up on an nforce chipset without an nvidia gpu too, and lspci -n is needed [16:53] bah, i was testing with lspci -n [16:54] lspci -n | grep '03..: 10de:' should work [16:56] if you want to do better than that i think you need my C helper to find the boot VGA device [16:57] maybe -nn and grep for VGA and 10de, ion might be on another pci domain than 03 [16:57] err pci bus rather [16:58] i was trying to match the 2nd column - i thought that was the class/subclass [16:59] looks like X would consider anything with class 00??, 03??, 0400, or 0b40 [16:59] 02:00.0 VGA compatible controller: nVidia Corporation ION VGA (rev b1) [16:59] in a script you want lspci -mn i guess. [16:59] what's that with -n? [17:00] and look for $2 == 0300 && $3 == 01de for vga/nvidia [17:01] don't know, i got that ion one from google, and awesome jcristau thats perfect [17:03] broder: sorry I see what you were talking about now with the [0300] [17:06] broder: the kernel tells you in sysfs what the boot vga device is [17:07] (/sys/bus/pci/devices/*/boot_vga) [17:07] or does that not work? [17:54] jcristau: oh, hmm. i didn't know about that node. i just stole some libpciaccess code from x - didn't look at how it worked [17:55] but it does look like that's all pciaccess is doing [17:55] so maybe i can do this all from shell [19:51] RAOF: did you ever check whether boot_vga=1 on both GPUs on your AMD hybrid laptop? [19:51] (it looks like the ubuntu-x thread got side-tracked before you had a chance to test that) [20:52] RAOF, my current method is: [20:52] 1. reset ubuntu branch to debian-unstable [20:52] 2. merge in upstream input commits [20:52] 3. modify package as needed for ubuntu [20:53] perhaps I should be starting from something other than debian-unstable? [21:49] RAOF, do you think there's any issue with uploading a new x11proto-input to precise with version 2.1.99.3? [21:49] everything is backwards compatible, and it would help speed the entire process [21:57] I already have the package built in ppa:utouch-team/xorg-unstable [22:06] cnd: No, I don't think that'd be a problem at all. [22:24] RAOF, is my process above reasonable? [22:24] for creating the server package [22:25] I'd probably start on the ubuntu+1 branch; I can update that to debian-unstable for you if you'd like. [22:26] RAOF, sure, that would be great [22:26] RAOF, actually, how do you update it to debian-unstable? [22:26] I'm basically missing the instructions for how to do that step [22:27] git merge origin/debian-unstable, basically. [22:27] I've got the server built using my method, so I know it's just a matter of getting it working [22:27] ok [22:27] Then resolve conflicts. [22:27] I'll try that [22:28] and let you know if I have any issues [22:35] Awesome. [22:39] RAOF, when I try to merge debian-unstable, I get a ton of conflicts in the source itself [22:39] I think many patches are cherry-picked directly into the source [22:39] which is causing issues [22:40] how do you handle that? [22:40] Oh! You're not starting from ubuntu+1, are you.\ [22:40] oh crap [22:40] sorry! [22:41] RAOF: did you see my earlier ping about your hybrid AMD laptop? [22:41] RAOF, how do you merge debian/changelog? [22:41] broder: Yeah. I *think* I did check, but I'll give it another whirl. [22:42] cnd: echo "debian/changelog merge=dpkg-mergechangelogs" >> .git/info/attributes [22:42] uhhh... what does that do? [22:43] and do I do it before or after the merge command? [22:43] RAOF: you know you can also have a .gitattributes file in the repository, right? [22:43] Sets the external merge driver for debian/changelog to be dpkg-mergechangelogs. After you've set that, git merge will handle debian/changelog nicely. [22:43] oh cool! [22:43] broder: No, I did not. Hm! [22:43] i think you could just drop in a debian/.gitattributes [22:44] RAOF, that didn't seem to help any :( [22:44] That's odd. [22:45] I've just now done a "git merge origin/debian-experimental" in the ubuntu+1 branch and only got a trivial conflict in debian/rules. [22:46] I'm trying with debian-unstable [22:46] which seems to be what we want [22:46] Ahem. Indeed. [22:46] That's what I meant. :) [22:47] RAOF, nm, I realized I had a stale debian-unstable local branch [22:47] that's probably my issue [22:48] * RAOF hates that part of git [22:48] I tried the .gitattributes part [22:48] no dice [22:48] i haven't played with attributes a whole lot - i was just going off of gitattributes(5) [22:48] might be something i'm missing [22:50] argh, RAOF, still not working [22:50] is there some output I should be seeing during the merge? [22:50] cndougla@cndougla:~/Canonical/ubuntu/xorg-server/xorg-server$ git merge origin/debian-unstable [22:50] Auto-merging debian/changelog [22:50] CONFLICT (content): Merge conflict in debian/changelog [22:53] http://paste.ubuntu.com/770621/ is what mine says. [22:54] And http://paste.ubuntu.com/770623/ is my .git/info/attributes file. [22:54] hmm [22:54] The warning is because there's a malformed changelog entry somewhere deep in the depths of xorg-server history. [22:55] RAOF, have you fetched the very latest from the git repo? [22:55] I wondered if that would be the issue, but I don't even get dpkg-mergechangelogs [22:55] so nm [22:56] You, of course, have dpkg-dev installed, right? [22:56] yeah [22:56] I've got the utility [22:57] * RAOF dunno [22:58] RAOF, what version of git are you running? :) [22:59] 1.7.5.4 here [22:59] from oneiric [22:59] 1.7.7.3 from precise. [22:59] But it worked for me in oneiric :) [22:59] ok [23:04] RAOF, I think I was able to call dpkg-mergechangelogs manually :) [23:04] :) [23:05] it looks sane to me [23:05] there's not currently a reasonable way for me to map a PCI device -> the value i should be setting x86_64-linux-gnu_gl_conf et al. to quickly, right? [23:07] cnd: Oh, you'll need to drop 220_xi21_deliver_raw_events if you haven't noticed that already. [23:07] hadn't yet [23:07] broder: The numeric value? No. That value isn't stable; it depends on order of installation. [23:08] RAOF: no, the filename. i'm working on my hybrid cleanup script [23:08] RAOF, was that a patch you wrote? [23:09] cnd: No; a backportish of something which I think is actually in 1.11 anyway. [23:10] ok [23:11] Hm. Doesn't actually seem to be in 1.11. But 1.12, and it's a part of the input stack, so yay! [23:12] RAOF, so I have a branch called upstream-1.11+input [23:12] broder: You should be able to match PCIID→vendor pretty easily, and then it's pretty easy to match vendor→filename, right? [23:12] I can do a git merge of that branch [23:12] or I can create a big diff and plop it into debian/patches [23:12] what do you think is the best option? [23:13] What will be easiest for you to work on? [23:13] I suspect that would be a git merge, right? [23:13] I like the git merge way because it leaves all the commits and merges available for further investigation [23:13] but I don't know if that will throw a wrench into further merging from debian-unstable [23:13] RAOF: probably. i'd rather do it based on modalias or something, so i don't, e.g., turn on fglrx's libGL on hardware that's only supported by -ati/-radeon [23:13] or any other workflows [23:14] RAOF: i'm thinking of requiring drivers that use update-alternatives to swap libGL also drop a file somewhere with a list of modaliases i can check against [23:15] cnd: It's only going to interfere if there are conflicting changes in debian-unstable, right? And in that case, it's probably easier to learn of them at git merge time than at quilt apply time. [23:15] yeah [23:15] ok [23:16] bryceh may have a different opinion, though ;) [23:16] well, I'm not pushing it to the archive yet :) [23:17] RAOF, do you think we should name the package version something like 1.11.2.902+input-0ubuntu1? [23:17] or just leave it as 1.11.2.902-1ubuntu1 [23:18] In the past we've just done the equivalent of 1.11.2.902-1ubuntu1; that would be fine by me. [23:18] ok [23:22] RAOF, merging debian-unstable into ubuntu+1 is a much saner way of doing things :) [23:22] I'm running pdebuild right now [23:22] :) [23:23] I spent a few hours trying to find an automated way of creating the backport [23:23] various ways of calling git log on specific files and directories [23:24] but nothing worked quite right [23:24] in the end I just manually audited all the commits/merges into upstream master [23:24] took me an hour or two, but it was much faster [23:24] and I'm much more confident of the results [23:25] RAOF, just a heads up, we will need to coordinate with kubuntu and libavg when we upload the new server [23:25] it will need a Breaks for qt and libavg [23:25] RAOF, git > quilt. Large patches are ok for initial packaging but can be a PITA for future maintenance. [23:26] cnd: Ah, because it's a proto break? [23:26] yeah [23:27] libxi will need Breaks too [23:27] cnd: What's the ETA for compatible libqt? [23:27] RAOF, I haven't started on it yet [23:27] I have to get a server that works first :) [23:27] Fair call. [23:27] but it will be one of my next tasks to get to [23:27] libavg upstream is very responsive and is maintaining their packaging [23:27] I think they'll be able to handle stuff on their own [23:27] they wrote their own implementation in the first place :) [23:28] So, I think this means we'll need to stage Qt in the PPA first; breaking that will break the CDs, and that's a no-no. [23:29] yeah [23:29] libavg is in universe and is unseeded btw [23:31] Yeah; that doesn't need staging. [23:35] RAOF, so I'm hoping to have xorg-server uploaded to the staging ppa [23:35] I don't think I'll be getting to any of the input modules [23:35] well, any of the modules [23:35] they'll all need updating for at least 1.11 [23:36] I can happily upload all the video drivers. [23:36] can you also upload the 1.11 series input modules? [23:36] Yup. [23:36] I think there shouldn't be any api or abi breaks [23:36] just additions [23:36] Minus synaptics and evdev? [23:36] I'm off after today [23:36] I'll be back tuesday [23:36] They'll need XI2.2 patches, right? [23:37] you should be able to upload the 1.11 synaptics and evdev [23:37] for right now I don't want to worry about XI 2.2 [23:37] I want to ensure the server actually works with the backports [23:37] Oh, yeah! That's right. [23:37] It's just the 1.12 input stack, not with multitouch. [23:37] there are two issues: [23:37] 1. is it stable [23:37] EBRIANFART [23:37] 2. did I nick any of the video ABI/API [23:38] Yup. So we'll just drop all the multitouch input patches from the input drivers for the first pass. [23:38] yeah [23:39] RAOF, really we should just take what's in debian/unstable [23:39] Yeah, most of them should be syncs. [23:39] the inputproto I uploaded was entirely rebased on top of debian's package [23:39] I left a branch called ubuntu-oneiric [23:39] but the ubuntu branch has no relationship with it other than an ancestor [23:40] I think we might as well do similar for synaptics and evdev [23:40] if you have stuff on your plate, I'm happy to do this when I get back [23:41] but I just wanted you to know I'll be out in case you were interested and had time to help out [23:43] I should be able to do this in the immediate future. [23:43] cool [23:47] ugh, the blah-linux-gnu_gl_conf alternatives are really unfriendly to arch-agnostic scripting [23:51] \o/ the server built [23:53] RAOF, should I rename the ubuntu branch to ubuntu-oneiric, and reset the ubuntu branch to what I've just created? [23:55] two other questions: what's the location of the staging ppa again, and do we use a standard suffix for versions like ~x-staging1