[00:01] <pwnguin> tjaalton: you have an opinion on backporting intrepid wacom to LTS?
[00:02] <pwnguin> or anyone else for that matter
[00:36] <pwnguin> well at least kees agrees with me
[00:37] <bryce> pwnguin: I at least wouldn't DISagree ;-)
[00:37] <pwnguin> cody-somerville: did you ever figure out the process on the other side of the socket?
[00:38] <cody-somerville> pwnguin, X
[00:38] <bryce> jcristau, tjaalton: cody and other xubuntu users are seeing a pretty widespread deadlock apparently triggered by a libxcb call in dbus-launch called from the xfce4 scripts.  fdo #16420
[00:38] <bryce> jcristau, tjaalton: I was hoping you might have some insights or debugging/workaround suggestions
[00:39] <pwnguin> cody-somerville: what's X up to at that point?
[00:39] <pwnguin> another select?
[00:40] <cody-somerville> pwnguin, X is wait4()
[00:41] <pwnguin> which arguments?
[00:42] <Q-FUNK> bryce: hiya
[00:42] <bryce> Q-FUNK: hi
[00:42] <cody-somerville> pwnguin, I'm not sure
[00:42] <bryce> Q-FUNK: btw I had a question on if we should remove the -amd source package in intrepid?
[00:42] <cody-somerville> pwnguin, it just said pwait4() in ...
[00:42] <cody-somerville> err
[00:42] <cody-somerville> from, not in
[00:43] <Q-FUNK> bryce: there's no amd source package.  we only have an -amd transitional package that is provided by -geode.
[00:43] <bryce> Q-FUNK: ah cool ok
[00:44] <Q-FUNK> bryce: to my knowledge, everything is now back to normal for Intrepid.  Hardy is what remains unresolved.
[00:45] <bryce> ok
[00:45] <Q-FUNK> and unless I'm mistaken, this dragged on long enough that we missed it for hardy.1 already.
[00:46] <bryce> yep
[00:47] <bryce> Q-FUNK: do you care to still try to get it in?
[00:47] <Q-FUNK> we have to. it's an LTS.
[00:47] <Q-FUNK> and geode is completely broken for the next 5 years, unless we act quickly
[00:47] <Q-FUNK> well... 3 to 5 years
[00:48] <bryce> why "quickly" if we've already missed .1 (which I think was effectively missed several weeks ago tbh)
[00:49] <Q-FUNK> I have sorf-of figured out a way to get hardy users to make this work, but most people are not reading my blog and will simply decide that what used to work in gutsy no longer works, so the hell with ubuntu
[00:49] <Q-FUNK> it's not for my lack of trying to push this SRU. I was on this issue since even before UDS.
[00:50] <cody-somerville> There will be another point release
[00:51] <Q-FUNK> cody-somerville: we all know this.  users won't wait that long.
[00:51] <Q-FUNK> they'll grab CD #2, install LTSP and notice that it doesn't work for them. 
[00:52] <Q-FUNK> .1 was a golden opportunity to fix this right after the release.
[00:52] <Q-FUNK> again, those who are patient enough to google will find my two blog posts on the issue and could fix it.
[00:53] <cody-somerville> Don't feel bad. Xubuntu users can't login half the time with Hardy. :(
[00:53] <Q-FUNK> :(
[00:53] <Q-FUNK> http://q-funk.blogspot.com/2008/06/howto-make-geode-thin-clients-work-on.html
[00:53] <Q-FUNK> http://q-funk.blogspot.com/2008/06/howto-build-clean-ltsp-boot-image-that.html
[00:53] <cody-somerville> Q-FUNK, Is your blog on the planet?
[00:54] <Q-FUNK> no, since I'm not an Ubuntu member.
[00:54] <Q-FUNK> it's on the debian planet, though
[00:54] <Q-FUNK> or is an ubuntero a sufficient status to end up on the ubuntu planet?
[00:54] <cody-somerville> It is limited to Ubuntu Members.
[00:55] <cody-somerville> However, I'd be happy to blog about your blog :)
[00:55] <bryce> Q-FUNK: I wish we had taken the time at UDS to sit down and experiment with it.  When I asked about that you seemed pretty optimistic that everything was sorted out, so it's a shame we didn't just prove it and get everything finalized right there and then.
[00:56] <Q-FUNK> bryce: I really wanted us to sit with ogra and go over this.  ogra was taken 100% by intel sales reps and the rest of us were just jumping from one session to the next.
[00:56]  * cody-somerville thinks UDS should go back to being longer than a week.
[00:56] <Q-FUNK> cody-somerville: the sessions are too packed.  there should be plenty of slack between for people to actually hack on the issues they just discussed.
[00:57] <bryce> Q-FUNK: well if it makes you feel any better, I also feel bad.  I think I put in more energy for -amd during 8.04.1 than I did for any other driver, and I'm disappointed to hear no progress was made
[00:57] <bryce> anyway, /me -> lunch.  bbiab
[00:58] <Q-FUNK> bryce: the main issue that prevents 2.9.0-1-ubuntu2.1 from doing what it's intended is that pitti didn't like the idea of backporting the complete solution. he insisted on fitting the framework used for 2.8.0-7.
[00:59] <Q-FUNK> bryce: yes and it helpped a lot getting the issue heard by Steve and Martin for the SRU
[00:59] <Q-FUNK> bryce: unfortunately, there's too many bugd and too many SRU to audit, right after the .0 release, and with an UDS to conduct in the midst of it all.
[01:00] <pwnguin> i have to wonder if ubuntu really has the resources for SRU in practice
[01:00] <Q-FUNK> I think that the next UDS should be conducted after release+1.1 is done, in the future
[01:01] <Q-FUNK> pwnguin: it mostly does, but the fact that people who are empowered to review SRU are also canoncal employees going from one plane to the next for their next canonicla event doesn't make this easier.
[01:02] <Q-FUNK> the same problme happens at debian:  too few people are empowered to review and approve freeze exceptions.
[01:02] <pwnguin> well i mean, you said the problem was requiring backported patches
[01:03] <Q-FUNK> and those people usually happen to have several other hats to wear, so their time for any given item is really limitted.
[01:03] <pwnguin> its a hell of an effort
[01:03]  * cody-somerville nods.
[01:03] <Q-FUNK> not if the backport is done and sitting in someone's PPA for weeks.
[01:04] <Q-FUNK> at that point, all it requires is for someone to review and either ack or nack the backport.
[01:04] <pwnguin> are we talking about sru or backport here?
[01:04] <pwnguin> they're different things
[01:04] <Q-FUNK> both
[01:05] <Q-FUNK> new upstream and backported package of it from debian, with hardy-specific changes.
[01:06] <Q-FUNK> SRU for newly suported hardware and important fixes.  backport of the debian packaging, with small changes to compensate for e.g. older dpkg-dev in hardy.
[01:07] <pwnguin> in related news
[01:07] <pwnguin> i hate cvs
[01:07] <Q-FUNK> :)
[01:07] <Q-FUNK> CVS is showing its age.
[01:07] <pwnguin> whoever thought independent file versions made sense should be shot
[01:08] <Q-FUNK> it's a different philosohpy
[01:08] <Q-FUNK> commit-based, versus file verison based
[01:09] <pwnguin> well when im trying to see where upstream fixed wacom going crazy bugs
[01:09] <pwnguin> commit based is what i want
[01:09] <Q-FUNK> right, thta would be git
[01:09] <pwnguin> ssh
[01:09] <pwnguin> you mean bzr ;)
[01:10] <Q-FUNK> ouch
[01:10] <Q-FUNK> please gimme my cathedral back!
[01:11] <pwnguin> ive no allegience to either git or bzr
[01:11] <pwnguin> but theres a storm a comin
[01:11] <Q-FUNK> oho
[01:11] <Q-FUNK> cody-somerville: but, sure, if you wanna blog about the above two posts, please do so :)
[01:12] <cody-somerville> Q-FUNK, will do :)
[01:17] <bryce> back
[01:40] <cody-somerville> wb
[01:50] <bryce> cody-somerville: I don't know if I got all the deps straight, but I've put together a libx11 with xcb disabled for you.  I'm uploading the debs presently.
[01:52] <bryce> cody-somerville: they'll be appearing at http://people.ubuntu.com/~bryce/Testing/libx11/
[02:20] <pwnguin> anyone ever heard of a VTBook?
[02:23] <pwnguin> its this crazy video card on a PC card
[02:23] <pwnguin> someone in -laptop went asking about it
[02:31] <bryce> pwnguin: wild
[02:31] <pwnguin> http://www.villagetronic.com/ftp/vtbook/Linux/LinuxReadMe.html
[02:31] <pwnguin> you should forward that to canonical's OEM support salesmen ;)
[02:32] <bryce> pwnguin: ok, but why?  (I may be dense)
[02:32] <pwnguin> well, they clearly need help
[02:33] <pwnguin> the provided driver is a patch to the kernel
[02:34] <pwnguin> "    *  Fedora Core 1"
[02:34] <pwnguin>     * Suse 9.1 (Thanks to Gil Spencer for important help)
[02:35] <bryce> * No kernel patch needed for systems with Kernel 2.6.22 or later
[02:35] <bryce> but yeah that looks like a painful setup process
[02:35] <bryce> "    *  Kernel 2.6.10 or newer
[02:36] <bryce>     Edit the setup-bus.c file in linux-2.6.y/drivers/pci/.
[02:36] <bryce>     Locate the following definition: #define CARDBUS_MEM_SIZE (32*1024*1024)
[02:36] <bryce>     Replace it with the following:  #define CARDBUS_MEM_SIZE (128*1024*1024)"
[02:36] <pwnguin> im checking to see if that's actually in kernel.org right now
[02:36] <bryce> using the 'trident' driver
[02:37] <pwnguin> yea
[02:37]  * bryce loves OEMs that use gfx drivers he has little experience with
[02:37] <bryce> pwnguin: <wince> yeah I think I'll pass on showing this to the OEM folks ;-) 
[02:38] <pwnguin> heh
[02:38] <bryce> although it wouldn't surprise me if with ubuntu it all "just worked" since we have a new enough kernel and it sounds like it works with stock trident and stuff
[02:39] <pwnguin> i dont own one but ive seen a couple reports of it not just working
[02:39] <pwnguin> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fe0e5c4d947d34f10002b4cf272f0ebf110305b7
[02:40] <pwnguin> the commitlog is hilarious at least
[02:44] <bryce> cody-somerville: hey there's a reply from bart
[02:44]  * cody-somerville nods.
[02:50] <cody-somerville> :)
[02:51] <bryce> ok so like I said in the email I'm starting to think the disable-xcb option is sounding more like the direction we'll need to go, esp. given the mounting evidence and bart's confirmation this pretty much a known issue
[02:53] <bryce> hopefully over the weekend someone can verify the non-xcb libx11 package I did; if not I'll finish building a xubuntu test rig monday
[02:53] <bryce> I envision this will be a painful SRU though.
[02:53] <cody-somerville> Indeed.
[02:54] <cody-somerville> Can you send off an e-mail to ubuntu-devel and techboard to let them know whats up?
[02:54] <bryce> sure
[02:54] <bryce> why techboard?
[02:54] <cody-somerville> They're supposed to be notified of regressions
[02:54] <pwnguin> what?
[02:54] <pwnguin> regressions in what?
[02:55] <bryce> cody-somerville: "techboard@lists.ubuntu.com" ?
[02:57] <pwnguin> if techboard is the place to get attention about regressions
[02:57] <pwnguin> i have some email to send
[02:57] <cody-somerville> technical-board@lists.ubuntu.com
[02:57] <bryce> cody-somerville: url for this policy?
[02:58] <cody-somerville> I'm not looking at it right now
[02:58] <cody-somerville> but I know they're supposed to be notified of serious regressions
[02:58] <cody-somerville> and all regressions introduced by SRUs
[03:00] <pwnguin> microrelease exception?
[03:01] <pwnguin> https://wiki.ubuntu.com/StableReleaseUpdates
[03:01] <pwnguin> n the event of a regression, immediately notify the [WWW] Ubuntu Technical Board via email, and ask for help on #ubuntu-devel in making urgent contact with a member of the Board or the SRU team: state the problem, the bug number, and ping "slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, keescook, jdstrand, BenC, dendrobates, davidm". For SRU in universe/multiverse, contact the [WWW] Universe SRU Team team or ask for help on #ubuntu-motu in
[03:27] <bryce> ahh
[03:28] <bryce> that doesn't apply in this case - that's for if there is a huge regression due to an SRU release
[03:28] <bryce> I think that's so people can have a chance to pull the update from the mirrors before it goes out to everyone
[03:28] <bryce> in this case the issue is already fully deployed
[03:29] <cody-somerville> I think we should delay the point release
[03:38] <bryce> cody-somerville: ok I've emailed ubuntu-devel@; you can feel free to forward to techboard and/or request point release delayment as you see fit
[03:41] <bryce> to be honest, I'd prefer to see my libx11~noxcb package verified first.
[03:47] <cody-somerville> I'll be sure to test it after I get some sleep :]
[03:51] <bryce> ok, I'm done too.  have a nice weekend.