[01:57] <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:58] <cnd> thanks!
[04:34] <RAOF> cnd: Looks like you've missed dropping the libaudit-dev selinux stuff, off the top of my head.
[04:50] <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:51] <inetpro> unfortunately I still get the screen with the big white blocks
[04:52] <inetpro> for the record, the daily build was downloaded from http://cdimage.ubuntu.com/daily-live/current/precise-desktop-i386.iso.zsync
[05:31] <cnd> RAOF, so I just need to drop that from the control file and everything will be peachy?
[07:20] <tjaalton> inetpro: ok
[10:44] <tjaalton> RAOF: do you have the changes to -savage stashed in your local tree? :)
[10:45] <RAOF> Do I have changes to -savage? :)
[10:45] <tjaalton> pushed to natty at least :)
[10:45] <tjaalton> hmm
[10:45] <tjaalton> wait
[10:46] <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:47] <tjaalton> i was just looking if it could be synced
[10:47] <RAOF> Looks like the answer is yes.
[10:54] <tjaalton> bz.kernel.org doesn't seem to work
[10:55] <jcristau> kernel bugzilla has been down since the compromise
[10:55] <tjaalton> oh ok
[10:55] <tjaalton> who needs it anyway..
[11:11] <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:12] <ricotz> tjaalton, this sounds reasonable
[11:17] <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:22] <ricotz> tjaalton, so you think it fits into pkg-xorg?
[11:23] <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:24] <ricotz> tjaalton, ok
[11:24]  * ricotz isnt member of pkg-xorg
[11:26] <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:27] <mistertim_> s/output of/absence of/
[11:28] <jcristau> mistertim_: you're disabling kms.  don't do that.
[11:29] <mistertim_> jcristau: aah! I thought I'd re-enabled it
[11:30] <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:31] <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:34] <mistertim_> jcristau: that did the trick, thankyou!
[11:34] <mistertim_> ls
[16:38] <popey> What ho x lovers.
[16:39] <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:45] <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:46] <broder> oh yeah - it does need to call ldconfig, too
[16:48] <broder> ...hmm, is gl_conf out of date? looks like its x86_64-linux-gnu_GL.conf now
[16:51] <Sarvatt> hmm that upstart script would be messed up on an nforce chipset without an nvidia gpu too, and lspci -n is needed
[16:53] <broder> bah, i was testing with lspci -n
[16:54] <broder> lspci -n | grep '03..: 10de:' should work
[16:56] <broder> if you want to do better than that i think you need my C helper to find the boot VGA device
[16:57] <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:58] <broder> i was trying to match the 2nd column - i thought that was the class/subclass
[16:59] <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?
[17:00] <jcristau> and look for $2 == 0300 && $3 == 01de for vga/nvidia
[17:01] <Sarvatt> don't know, i got that ion one from google, and awesome jcristau thats perfect
[17:03] <Sarvatt> broder: sorry I see what you were talking about now with the [0300]
[17:06] <jcristau> broder: the kernel tells you in sysfs what the boot vga device is
[17:07] <jcristau> (/sys/bus/pci/devices/*/boot_vga)
[17:07] <jcristau> or does that not work?
[17:54] <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:55] <broder> but it does look like that's all pciaccess is doing
[17:55] <broder> so maybe i can do this all from shell
[19:51] <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)
[20:52] <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:53] <cnd> perhaps I should be starting from something other than debian-unstable?
[21:49] <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:57] <cnd> I already have the package built in ppa:utouch-team/xorg-unstable
[22:06] <RAOF> cnd: No, I don't think that'd be a problem at all.
[22:24] <cnd> RAOF, is my process above reasonable?
[22:24] <cnd> for creating the server package
[22:25] <RAOF> I'd probably start on the ubuntu+1 branch; I can update that to debian-unstable for you if you'd like.
[22:26] <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:27] <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:28] <cnd> and let you know if I have any issues
[22:35] <RAOF> Awesome.
[22:39] <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:40] <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:41] <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:42] <RAOF> cnd: echo "debian/changelog merge=dpkg-mergechangelogs" >> .git/info/attributes
[22:42] <cnd> uhhh... what does that do?
[22:43] <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:44] <cnd> RAOF, that didn't seem to help any :(
[22:44] <RAOF> That's odd.
[22:45] <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:46] <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:47] <cnd> RAOF, nm, I realized I had a stale debian-unstable local branch
[22:47] <cnd> that's probably my issue
[22:48]  * 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:50] <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:53] <RAOF> http://paste.ubuntu.com/770621/ is what mine says.
[22:54] <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:55] <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:56] <RAOF> You, of course, have dpkg-dev installed, right?
[22:56] <cnd> yeah
[22:56] <cnd> I've got the utility
[22:57]  * RAOF dunno
[22:58] <cnd> RAOF, what version of git are you running? :)
[22:59] <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
[23:04] <cnd> RAOF, I think I was able to call dpkg-mergechangelogs manually :)
[23:04] <RAOF> :)
[23:05] <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:07] <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:08] <broder> RAOF: no, the filename. i'm working on my hybrid cleanup script
[23:08] <cnd> RAOF, was that a patch you wrote?
[23:09] <RAOF> cnd: No; a backportish of something which I think is actually in 1.11 anyway.
[23:10] <cnd> ok
[23:11] <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:12] <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:13] <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:14] <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:15] <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:16] <RAOF> bryceh may have a different opinion, though ;)
[23:16] <cnd> well, I'm not pushing it to the archive yet :)
[23:17] <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:18] <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:22] <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:23] <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:24] <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:25] <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:26] <RAOF> cnd: Ah, because it's a proto break?
[23:26] <cnd> yeah
[23:27] <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:28] <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:29] <cnd> yeah
[23:29] <cnd> libavg is in universe and is unseeded btw
[23:31] <RAOF> Yeah; that doesn't need staging.
[23:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <cnd> but I just wanted you to know I'll be out in case you were interested and had time to help out
[23:43] <RAOF> I should be able to do this in the immediate future.
[23:43] <cnd> cool
[23:47] <broder> ugh, the blah-linux-gnu_gl_conf alternatives are really unfriendly to arch-agnostic scripting
[23:51] <cnd> \o/ the server built
[23:53] <cnd> RAOF, should I rename the ubuntu branch to ubuntu-oneiric, and reset the ubuntu branch to what I've just created?
[23:55] <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