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