[00:01] <Sarvatt> whoa! syncpackage -d unstable -r maverick -V 1:1.0.1.xsf1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589528 libxprintutil   
[00:01] <Sarvatt> syncpackage -d unstable -r maverick -V 1:2.3.0-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589530 vesa
[00:02] <RAOF> I've pushed to the branch again, now as 2:1.7.6-2ubuntu7.1 and targetting lucid-proposed.
[00:02] <Sarvatt> oops xserver-xorg-video-vesa for that second one
[00:02] <Sarvatt> at the end
[00:02] <Sarvatt> syncpackage -d unstable -r maverick -V 1:1.4.11.dfsg-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589531 xserver-xorg-video-mga
[00:03] <Sarvatt> syncpackage -d unstable -r maverick -V 6.8.1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589540 xserver-xorg-video-r128
[00:03] <Sarvatt> that rocks, auto uploads and closes the bugs
[00:04] <bryceh> Sarvatt, ok syncs updated, ack'd, and archive subbed
[00:04] <Sarvatt> syncpackage -d unstable -r maverick -V 1:12.6.9-2 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589925 xserver-xorg-input-vmmouse
[00:04] <Sarvatt> i dont know raof's email for the evdev one
[00:05] <bryceh> RAOF, should be 7.2 - remember my "don't email bryce" patch the other day ;-)
[00:05] <RAOF> Aaah!
[00:06] <bryceh> sorry, didn't know you were planning to maintain the lucid xserver in git else I'd have committed it there
[00:06] <Sarvatt> syncpackage -d unstable -r maverick -V 0.8.8-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589535 xf86-input-evtouch
[00:06] <bryceh> actually if I'd known I'd have just slipped it in with these four, that'd be easiest
[00:06] <RAOF> bryceh: Yeah.  These fixes got a little bit lost in the ubuntu branch.
[00:06] <Sarvatt> ahhh synaptics, merging
[00:07] <Sarvatt> err building i should say
[00:07] <RAOF> Sarvatt: It's already merged, innit?
[00:07] <Sarvatt> yup
[00:08] <bryceh> https://wiki.ubuntu.com/X/PackageNotes updated
[00:08] <RAOF> bryceh: Launchpad doesn't seem to think you've uploaded xorg-server with the “don't email bryce” patch?  It should therefore be possibly to merge the patch in with the other four?
[00:09] <bryceh> RAOF, alrighty, you mind merging it in?
[00:09] <RAOF> Not at all.
[00:09] <bryceh> worst case the admins will ask us to redo it and untangle
[00:09] <bryceh> I got an ack but no indication it's been accepted into the queue yet
[00:10] <Sarvatt> we arent in import freeze so you can just upload directly cant ya? those lines i pasted earlier automatically grab everything and upload and close the bugs
[00:11] <bryceh> oh do they?  hmm
[00:11] <Sarvatt> yeah need ubuntu-dev-tools from bzr though! its an awesome script
[00:11] <bryceh> bryce@blumonc:~/src/xorg-server$ syncpackage -d unstable -r maverick -V 0.8.8-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589535 xf86-input-evtouch
[00:11] <bryceh> Command not found
[00:11] <bryceh> bryce@blumonc:~/src/xorg-server$ apt-cache search syncpackage
[00:11] <bryceh> bryce@blumonc:~/src/xorg-server$ 
[00:12] <Sarvatt> yeah ubuntu-dev-tools git, its not released yet
[00:12] <bryceh> git?
[00:12] <Sarvatt> http://sarvatt.com/downloads/merges/xserver-xorg-input-synaptics/ (its building now to be sure itsall there)
[00:12] <Sarvatt> bzr
[00:12] <Sarvatt> sorry :)
[00:13] <bryceh> do I just run from the bzr tree or is there some installation magic?
[00:13] <Sarvatt> deb is here if you are on i386 http://sarvatt.com/downloads/merges/
[00:14] <bryceh> ok
[00:14] <Sarvatt> oh its all arches
[00:15] <bryceh> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
[00:16] <Sarvatt> too good to be true huh
[00:17] <Sarvatt> oh guess i already created credentials
[00:18] <bryceh> ok sorted that out
[00:18] <bryceh> hmm, doesn't like me trying to upload stuff as you
[00:18] <Sarvatt> try passing -k KEYID?
[00:19] <bryceh> should I specify myself as the uploader?
[00:19] <bryceh> or do I need to just import your key or something?
[00:20] <bryceh> gpg: skipped "KEYID": secret key not available
[00:20] <Sarvatt> nah just do it as yourself, more important we get them uploaded anyway
[00:20] <jcristau> replace it with your actual key id :)
[00:21] <bryceh> aha
[00:21] <bryceh> dpkg-buildpackage: binary and diff upload (original source NOT included)
[00:21] <bryceh> xf86-input-evtouch_0.8.8-4fakesync1_source.changes
[00:21] <jcristau> RAOF: so i'm looking at putting stuff in pristine-tar for xorg-server, and every tarball i import seems to add 1M to the repo.
[00:21] <bryceh> what is "-b 589535"?
[00:22] <bryceh> bytes?
[00:22] <jcristau> bug?
[00:22] <Sarvatt> bug number it closes
[00:22] <bryceh> ahh
[00:23] <bryceh> Successfully signed dsc and changes files
[00:23] <bryceh> xserver-xorg-input-vmmouse_12.6.9-2_source.changes
[00:24] <Sarvatt> nice, it adds Launchpad-Bugs-Fixed: to the .changes
[00:24] <bryceh> bryce@blumonc:~/src/ubuntu-dev-tools$ syncpackage -k E0E67611 -d unstable -r maverick -V 6.8.1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589540 xserver-xorg-video-r128
[00:24] <bryceh> WARNING! Overwriting modified Ubuntu version 6.8.1-2ubuntu1, setting current version to 6.8.1-2
[00:25] <Sarvatt> huh
[00:25] <bryceh> hmm same with mga
[00:25] <bryceh> $ syncpackage -k E0E67611 -d unstable -r maverick -V 1:1.4.11.dfsg-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589531 xserver-xorg-video-mga 
[00:25] <bryceh> WARNING! Overwriting modified Ubuntu version 1:1.4.11.dfsg-2ubuntu1, setting current version to 1:1.4.11.dfsg-2
[00:26] <Sarvatt> hmm now ubuntu-dev-tools has acksync in it too! wth
[00:26] <bryceh> hrm, got it for -vmmouse too, but didn't notice it before doing the upload
[00:26] <bryceh> $ syncpackage -k E0E67611 -d unstable -r maverick -V 1:12.6.9-2 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589925 xserver-xorg-input-vmmouse
[00:26] <bryceh> WARNING! Overwriting modified Ubuntu version 1:12.6.5-4ubuntu2, setting current version to 1:12.6.5-4
[00:27] <jcristau> i guess the warning is to make sure you really want to get rid of the delta?
[00:27] <bryceh> jcristau, yep
[00:27] <bryceh> also the -evtouch sync failed... needs to be fakesync'd
[00:27] <bryceh> so add that one to the merges pile
[00:28] <jcristau> RAOF: so i'm looking at putting stuff in pristine-tar for xorg-server, and every tarball i import seems to add 1M to the repo :/
[00:29] <RAOF> jcristau: Urgh, really?
[00:30] <Sarvatt> nice, ack-sync even has an option to build the packages too
[00:30] <Sarvatt> its just a wrapper around syncrequest
[00:30] <RAOF> jcristau: I don't have much more insight than “man, that sucks”, though :)
[00:31] <RAOF> Sorry, call with Rick.
[00:31] <jcristau> RAOF: i'm thinking it's because it has a lot of autotools-generated files, which aren't in git
[00:31] <RAOF> That may well be it.
[00:32] <bryceh> ok looks like for -mga the only change is a patch that's already upstream, according to https://edge.launchpad.net/ubuntu/maverick/+source/xserver-xorg-video-mga/1:1.4.11.dfsg-2ubuntu1
[00:32] <bryceh> so I've put -mga through
[00:33] <RAOF> jcristau: Incidentally, I noticed there were a lot of files in git but not in the tarball.  I've removed them locally, so lintian now doesn't complain about changing files outside of debian/.  I'll merge that in to debian-experimental later, if you like.
[00:33] <Sarvatt> yup, made sure each of those had every patch we had upstream before requesting it (or bugged jcristau to update things to sync) :D
[00:34] <bryceh> Sarvatt, ok are you 100% sure all of these can just sync and ignore the ubuntu changes?
[00:34] <Sarvatt> syncpackage -d unstable -r maverick -V 1:2.3.2-6 --uploader="insert roafs info here" -b 586659 xserver-xorg-input-evdev
[00:34] <bryceh> otherwise we'll need to go through and check each individually
[00:35] <Sarvatt> yes 100% positive, i didn't request anything that wasn't in debian or upstream already
[00:35] <Sarvatt> and if it was in upstream and not debian i updated debian :D
[00:35] <bryceh> alrighty
[00:36] <bryceh> xserver-xorg-video-r128_6.8.1-3_source.changes done
[00:36] <RAOF> syncpackage -d unstable -r maverick -V 1:2.3.2-6 --uploader="Christopher James Halse Rogers <raof@ubuntu.com>" -b 586659 xserver-xorg-input-evdev
[00:36] <RAOF> ^^ That's what you were after, Sarvatt  ;)
[00:36] <jcristau> RAOF: i tend to ignore this lintian bit.  the files are in upstream git, so deleting them means merge pain if they get modified upstream, and unless they're huge removing them doesn't buy us much. i don't care much though.
[00:36] <bryceh> RAOF, thanks
[00:37] <bryceh> xserver-xorg-input-evdev_2.3.2-6_source.changes uploaded
[00:37] <jcristau> RAOF: (if they're in the debian branch but not upstream, then that's a different story, but i think we mostly got rid of that a while back)
[00:38] <RAOF> jcristau: Fair enough.
[00:38] <bryceh> libxprintutil_1.0.1.xsf1-3_source.changes uploaded
[00:38] <bryceh> Sarvatt, got more for me?
[00:39] <Sarvatt> going back over and seeing what ya uploaded
[00:39] <bryceh> everything in the Waiting list at https://wiki.ubuntu.com/X/PackageNotes was done
[00:39] <bryceh> except one
[00:39] <bryceh> -evtouch has to be fakesync'd
[00:45] <Sarvatt> sweet, edit-patch automatically adds patches if you have any local ones now too
[00:45] <bryceh> 15 min remain... anything else I can help y'all with today?
[00:49] <RAOF> The xorg-server SRU would be good.  I've merged your patch, and double checked that it builds.  I'll just push up to git.
[00:50] <bryceh> ok
[00:52] <RAOF> Pushed in git.
[00:57] <bryceh> uploaded to lucid-proposed
[00:57] <RAOF> Thanks!
[01:01] <RAOF> bryceh: Have a good dinner tonight!
[01:02] <bryceh> no prob, good luck with the rest of the uploads
[01:02] <bryceh> hopefully you'll be able to find other sponsors but if you get in a pinch lemme know
[01:02] <RAOF> I think I'll be able to tap some of #ubuntu-desktop :)
[01:25] <Sarvatt> argh, had to run out there, take care and thanks bryce
[01:27] <Sarvatt> not to ppa-purge all these machines and upgrade as things come :)
[01:28] <Sarvatt> now to do that rather
[01:28] <Sarvatt> and \o/ you dropped the ati patch series, that ended up not doing anything for those bug reports anyway
[01:29] <Sarvatt> oh.. you probably just forgot to git add huh? :( we had some other real post 6.13 fixes in there
[01:36] <RAOF> Sarvatt: What are you talking about?
[01:38] <Sarvatt> ati?
[01:38] <Sarvatt> in git?
[01:38] <RAOF> Hm.  Maybe I did forget to git add.
[01:39] <RAOF> Well, it hasn't been uploaded yet.
[02:15] <Sarvatt> i think i hit a new point of lazyness when i rename a tarball and include all the new commits as patches in the diff :D
[02:16] <Sarvatt> mv libdrm_2.4.20+git20100527.607e228c.orig.tar.gz libdrm_2.4.20+git20100607.66375fd6.orig.tar.gz it is!
[02:17] <Sarvatt> such a pain syncing libdrm and people think they are using the old one because of the name
[02:17] <Sarvatt> bjsnider: your vaapi acceleration stuff is all in there now
[02:18] <bjsnider> in the libdrm?
[02:21] <RAOF> Ah, the multi ringbuffer patch has finally landed?
[02:21] <Sarvatt> yeah
[02:22] <RAOF> That was a bit of a drama.
[02:22] <bjsnider> wish i had an intel card to test it on
[02:22] <bjsnider> wait, no i don't
[02:29] <RAOF> Hah.  You totally do.  Intel hardware rocks.
[02:31] <bjsnider> yes it does
[02:44] <jcristau> RAOF: so running git import-orig on all tarballs to get the upstream/* tags on http://git.debian.org/?p=users/jcristau/xorg-server.git + the pristine-tar branch there adds up to ~15M afaict, which is more reasonable.
[02:45] <RAOF> That's not terrible.  It's mostly a one-off cost, too, and bandwith is (generally) cheaper than my attention :)
[02:46] <jcristau> i downloaded all tarballs from snapshot.debian.org so that should be pretty much all xorg-server tarballs ever uploaded to debian
[02:48] <RAOF> Excellent!
[03:18] <RAOF> Sarvatt:  You've added 102-disable-page-flipping-v2.patch to xf86-video-intel - on what hardware is that meant to be a problem?  Is there a bug link available?
[03:21] <Sarvatt> i dont have a bug link handy because wenever shipped it, it's been a problem all throughout the late 2.10+ cycle and still a problem today in git and fedora is shipping the same thing
[03:21] <Sarvatt> they haven't figured out where the problem is yet
[03:21] <RAOF> Sarvatt: I ask this because I'm very happily running without that patch on my invincible laptop.
[03:21] <Sarvatt> 915-X3100 seems to be the range bad off
[03:22] <RAOF> Fair enough.
[03:22] <Sarvatt> and some of the devs are having it on GM45 too
[03:22] <Sarvatt> (what you have)
[03:22]  * RAOF can recognise his own chipset :)
[03:23] <Sarvatt> here is fedoras http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-drv-intel/intel-2.11-no-pageflipping.patch?view=markup
[03:24] <Sarvatt> some people like hyperair can't go 10 minutes with it enabled, figured it was better to patch it preemptively since there isn't any kind of freeze
[03:24] <Sarvatt> https://bugzilla.redhat.com/show_bug.cgi?id=588421
[03:24] <ubot4> bugzilla.redhat.com bug 588421 in xorg-x11-drv-intel "Pageflipping disabled in F13" [Medium,Assigned]
[03:25] <Sarvatt> http://www.pubbs.net/201005/fedora/1529-page-flipping-on-intel-211-driver.html
[03:26] <RAOF> Man, that's a useless bug report :)
[03:26] <Sarvatt> (the patch was from jbarnes, I just changed the info message in it)
[03:31] <ripps> That's it, I'm taking the plunge and upgrading to maverick
[03:33] <RAOF> Get in quick, before xserver 1.8 has been published :)
[03:35] <ripps> I'm already using 1.8 from xorg-edgers, is it very different?
[03:35] <Sarvatt> ppa-purge first!!
[03:36] <Sarvatt> no its the same but ati has had a ton of changes since 6.13
[03:36] <Sarvatt> word of warning though, i'm putting edgers on 1.9 any day now :D
[03:36] <Sarvatt> just in maverick
[03:36] <ripps> good, I'll probably try it from maverick
[03:37] <ripps> xorg-edgers has maverick packages, right?
[03:37] <Sarvatt> yeah, basically the same as lucid now, i upload the same stuff to both
[03:37] <Sarvatt> maverick's i686 instead of i486 though
[03:37] <Sarvatt> if you're on x86
[03:38] <ripps> I use a athlonxp 2500+, I'm pretty sure that's i686
[03:38] <stenten> Wait, would being on xorg-edgers interfere with the 1.8 switch in Maverick?
[03:39] <ripps> I'm purging xorg-edgers now
[03:39] <stenten> Most of the people on the Maverick Forum are running edgers.
[03:39] <ripps> I have alot of ppa's, any other's I should purge, like nautilus-elementary?
[03:39] <RAOF> stenten: Yeah, they're not really helping test X in Ubuntu.
[03:40] <ripps> I should probably purge the Unity and gnome-shell stuff too, while I'm at it
[03:41] <Sarvatt> well they probably wont be on edgers soon with all the breakage incoming :)
[03:42] <RAOF> Sarvatt: So, it looks like there's at least one pageflipping bug that's been fixed upstream.  I think I'll pull those patches and drop the pageflipping disablement patch.
[03:43] <Sarvatt> okie, the bugs will be hard hangs with the system completely dead and no way to get info out of it when you come across them
[03:44] <RAOF> Hm.  I might check that we've actually got the kernel side of the fix - it doesn't seem to be in yet.
[03:46] <Sarvatt> i've been dropping the patch from edgers every kernel upgrade to see if its fixed and readding it when its not
[03:47] <Sarvatt> some of the hangs might be fixed in rc2 though, i saw a few commits
[03:47] <RAOF> It doesn't look like it's in 2.6.35-rc2, so that puts the kybosh on enabling page flipping it seems.
[03:49] <Sarvatt> i think it was merged in the rc2 cycle but the commits were old enough to be back before rc1
[03:52] <Sarvatt> drm/i915: Kill dangerous pending-flip debugging is one
[03:52] <RAOF> There should also be a gen 3 patch; that doesn't seem to be in any git repository.
[03:53] <Sarvatt> looks like thats it upstream :(
[03:53] <RAOF> I'm talking about http://lists.freedesktop.org/archives/intel-gfx/2010-April/006463.html
[03:53] <Sarvatt> yeah i saw it on the lists
[03:53] <Sarvatt> april...
[03:54] <RAOF> So, the result is: page flipping is probably still broken, leave it disabled.
[03:58] <RAOF> Anyway, lunch time!
[03:58] <Sarvatt> will ask jbarnes whats up
[03:59] <Sarvatt> that one patch of his fixing hangs on dpms events still isn't upstream and it was from january i think..
[04:11] <RAOF> Hah.  We get 1.8 uploaded and 1.9 rc1 gets branched.
[04:16] <Sarvatt> yeah been testing it the past few days, intel is horribly broken :)
[04:17] <Sarvatt> i'm blaming the gtk stuff since other people arent seeing it
[04:20] <Sarvatt> was hoping bgnr support could make the cut :(
[04:22] <Sarvatt> holy crap, i got almost10k karma from uploading all the x driver/libs/protos
[04:29] <Sarvatt> ever figure out whats forcing 96 dpi everywhere?
[04:32] <Sarvatt> we had a patch doing it before -     - 138_fedora_xserver-1.3.0-default-dpi.patch
[04:32] <Sarvatt>       Changes default dpi to 96.
[04:34] <Sarvatt> hmm might be gdm's xsettings manager plugin?
[05:15] <ripps> okay, system has been cleaned of a lot of ppas
[06:11] <RAOF> We interrupt your regularly scheduled IRC proxy to bring you 5.8 GiB swap usage.
[06:11] <RAOF> Sarvatt: http://bugs.freedesktop.org/show_bug.cgi?id=23705 is why X is set to 96 DPI
[06:11] <ubot4> Freedesktop bug 23705 in Server/general "xserver 1.7.0rc0 uses wrong dimensions" [Normal,Reopened]
[06:12] <RAOF> I'd like to revert that and let GNOME and KDE handle it if they feel they must.
=== AlanChicken is now known as AlanBell
[10:29] <lucazade> hi Sarvatt
[10:30] <lucazade> did you read my message yesterday about poulsbo patch?
[10:45] <asac> RAOF: !!
[10:46] <asac> RAOF: did you get my message about stuff failing on armel?
[11:19] <RAOF> asac: Hi!
[11:20] <RAOF> asac: Ah, yes I did, but for some reason I didn't read it as something that needed responding to - I got it quite a lot after you sent it.
[11:21] <RAOF> asac: Does any arm hardware actually have intel graphics hardware?  If not, it shouldn't be hard to just drop the dependency and drop the intel build (on arm, so the same package builds appropriately in the archive)
[11:22] <jcristau> building libdrm-intel on arm is nonsense afaik
[11:24] <asac> RAOF: it fails on armel with intel .so not there
[11:24] <asac> yes
[11:28] <RAOF> Aha.  Ok.  I'll update the packaging to handle that, then.
[11:28] <RAOF> (Tomorrow)
[11:29] <RAOF> Hm.  Now that there's an openvg library to build against, I wonder how cairo's openvg backend does… :)
[11:29]  * RAOF is off to the movies.  See you tomorrow!
[11:29] <asac> RAOF: whats the idea?
[11:29] <asac> i can do that too then?
[11:32] <asac> RAOF: we could --disable-intel on !x86/amd64 i guess?
[11:33] <RAOF> asac: The idea would be, in debian/rules, to not build anything that requires libdrm_intel on arm.  Right something like that.
[11:33] <asac> RAOF: yeah. so just not on armel or everywhere? how does the package actually build for all the archs in maverick?
[11:33] <RAOF> I didn't think intel built by default, but perhaps it does.
[11:34] <asac> it seems to do ... but i see that the build succeeded everywhere in maverick ... which feels like this might not be the problem
[11:34] <asac> anyway, enjoy your evening. i will try :)
[11:34] <RAOF> The current archive package would build everywhere because it only enables i915 and i965 on amd64 and i386.  But it also --disable-gallium's
[11:34] <RAOF> Ta.  Good luck!
[12:52] <apw> Sarvatt, seems i am about to expire out of xorg-edgers are you able to wave a wand over that?
[16:45] <Sarvatt> asac: you need libdrm-intel1 to build plymouth on arm :)
[16:48] <asac> Sarvatt: why is that?
[16:48] <asac> then i will just enable all the intel packages everywhere
[16:48] <asac> they seem to build ... not sure why just the intel1 package was disabled on arm in the first plac
[16:51] <tseliot> asac: because plymouth has a drm plugin with different backends for radeon, intel and nouveau. It's what it uses to map the framebuffer, etc.
[16:52] <asac> kk
[16:52] <asac> will remember that when touching it next time
[16:52] <asac> (reenable intel everywhere)
[16:58] <tseliot> good
[17:24] <jcristau> tseliot, Sarvatt: plymouth needs to be able to disable some of the backends.
[17:26] <tseliot> jcristau, Sarvatt: I *think* it's possible to disable the drm renderer (thus disabling radeon, intel and nouveau)
[17:27] <jcristau> not good enough
[17:28] <tseliot> I'm not even sure about that. I haven't checked
[18:57] <nperry> Hello guys, wondered if somone could have a look at xserver-xorg-video-nouveau for maverick, it seems to of failed its last build becuase its still depending on  Xserver 1.7
[19:01] <seb128> nperry, it didn't fail it's depwaiting
[19:02] <seb128> there is a known soyuz issue that it's taking a while to see that the depwait is cleared
[19:02] <seb128> the new xorg has only be newed some hours ago so you just have to wait
[19:05] <nperry> Ah ok, no problems!
[20:06] <bryceh> there was an email to ubuntu-devel@ sent about this the other day
[23:47] <RAOF> asac: Any joy with the mesa build?
[23:47] <asac> RAOF: let me check ;)
[23:48] <asac> took more time then i had before leaving so felt good
[23:48] <asac> thumbs up: https://edge.launchpad.net/~asac/+archive/armel1/+build/1778126
[23:48] <asac> yay
[23:48] <RAOF> Yay!
[23:48] <asac> RAOF: anyway, i was told that we need to resurrect intel for something
[23:48] <asac> will just enable it everywhere
[23:48] <asac> it seems to build everywhere at least ;)
[23:48] <asac> right
[23:49] <asac> here the reason:
[23:49] <asac> 17:51 < tseliot> asac: because plymouth has a drm plugin with different backends for radeon, intel and nouveau. It's what it uses to map the framebuffer, etc.
[23:49] <asac> RAOF: ^^
[23:49] <asac> for me it feels not particular !armel specific to build a driver for an intel chip
[23:49] <asac> as long as it builds it should be fine imo
[23:49] <asac> so anything against just setting the intel1 thing to any?
[23:50] <RAOF> Apart from the fact that there's no hardware it could possibly drive on !{i386,amd64}, not really.
[23:50] <RAOF> It'll just needlessly inflate the build times & package sizes on those archs.
[23:50] <asac> right
[23:50] <asac> but i think things like radeon and ati could in theory exist
[23:50] <asac> why not intel ;)
[23:51] <asac> if its a usb/pci card, then it should just work
[23:51]  * asac considers to find a card for his intel chipset ;)
[23:51] <RAOF> Intel don't make usb/pci cards :)
[23:51]  * cwillu feels a sudden urge to check for video chipsets on digikey :p
[23:51] <asac> they dont? hmm ... /me sees a market gap ;)
[23:51] <asac> opportunity its called
[23:51] <asac> btw, http://identi.ca/notice/35424509 ... just so you know ;)
[23:53] <jcristau> asac: plymouth just needs fixing.  it's a 5 minutes job..
[23:54] <RAOF> That would be the other option, yes.
[23:54] <asac> ok i let you guys figure ouw what you want ... imo usb/pci based drivers don't need to be disabled just because its arm and its called intel ;)
[23:55] <jcristau> it's not usb/pci.  it's integrated graphics on intel kit.
[23:56] <jcristau> it comes on the chipset with an intel cpu.  or on the same chip as the cpu, lately.
[23:56] <asac> jcristau: but the driver is registered as pci ;)
[23:56] <asac> isnt it?
[23:57]  * asac types lspci
[23:57] <cwillu> asac, when a device becomes available, the driver can be trivially enabled
[23:57] <cwillu> until then, why waste the resources?
[23:57] <asac> cwillu: right. why waste resources and disable it ;) ... we can just keep it enabled and dont need to touch packging
[23:58] <lifeless> RAOF: so, I have a gt200 (gtx260) reva
[23:58] <lifeless> RAOF: and I play games on it
[23:58] <RAOF> A fine use of a dedicated GPU.  GO on.
[23:58] <lifeless> RAOF: also, remind me about cedega full screen being offset by a couple of inches
[23:59] <lifeless> RAOF: what driver should I run on the gt200 - is nouveau there yet for (say) wow, civIV, steam:source games ?
[23:59] <RAOF> No, I don't think so.