[12:44] <bryce> hmm, I'm getting odd errors attempting to reach archive.ubuntu.com:
[12:44] <bryce> Err http://archive.ubuntu.com gutsy/main dpatch 2.0.22
[12:44] <bryce>   404 Not Found [IP: 91.189.89.8 80] 
[02:40] <bryce> nevermind, figured it out
[03:19] <ubotu> New bug: #117638 in xorg (main) "Graphics problem when users have different screen resolutions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117638
[07:50] <tepsipakki> every epoch has been committed to git.d.o
[08:10] <keescook> tepsipakki: very cool!
[08:14] <tepsipakki> there are 24 packages with different orig.tar.gz, 45 packages with changes committed and waiting for upload, and 16 that otherwise can be synced after an upload
[08:14] <tepsipakki> maybe I should put all of this in the wiki..
[08:14] <tepsipakki> its just easier to edit a text file which is always open on my screen session :)
[05:31] <keescook> bryce: okidoky.  evil evil beforelight
[05:31] <bryce> yup
[05:31] <keescook> I think we're very close -- I suspect there are just some patch thingies missing from the rules
[05:31] <bryce> I'd checked dpkg -c on the deb before I sent it in, and didn't see the recursive paths
[05:31] <keescook> which other package uses the x patch stuff?
[05:32] <bryce> appres, xorg-docs, bitmap, xorg-server, etc. etc.
[05:32] <bryce> basically all the ones I've touched have used this system
[05:32] <keescook> bryce: weird.  I wonder why we're seeing different results.  does your build log show it as having applied the patch?
[05:32] <bryce> I seem to recall it did, yes
[05:33] <keescook> appres and bitmap don't seem to have it
[05:33] <keescook> do you still have the log?  Something must be wrong with my build environment
[05:34] <keescook> ah, yeah, xorg-docs has it
[05:35] <keescook> okay, so, comparing the build and clean rules between xorg-docs and beforelight.  xorg-docs has:
[05:35] <keescook> build: patch build-stamp
[05:35] <keescook> build-stamp:
[05:35] <keescook> where as beforelight is just:
[05:35] <keescook> build: build-stamp
[05:35] <keescook> build-stamp:
[05:36] <bryce> no, don't have the log
[05:36] <keescook> go ahead and build it again (it's quick).  I'd like to track down the source of the problem.
[05:37] <bryce> ok building
[05:42] <bryce> hmm, there's nothing indicating the patch applied
[05:44] <keescook> can you paste-bin the results of dpkg -c ?
[05:48] <bryce> http://pastebin.ca/522850
[05:54] <ubotu> New bug: #117222 in xorg (main) "Dell Latitude X1 Screen Resolution" [Undecided,Needs info]  https://launchpad.net/bugs/117222
[05:55] <keescook> bryce: drwxr-xr-x root/root         0 2007-05-30 08:37 ./tmp/buildd/beforelight-1.0.2/debian/beforelight/
[05:56] <keescook> so there are bad paths in your .deb too.  Okay, I'm not going crazy.  :)
[05:56] <ubotu> New bug: #117782 in linux-restricted-modules-2.6.20 (restricted) "Upgrade of linux-restricted-modules-2.6.20-16-generic failed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117782
[05:56] <keescook> bryce: alright, so, to hook up xsf fully.
[05:56] <keescook> do you still have the xorg-docs source tree to look at?
[05:57] <bryce> yeah
[05:57] <keescook> in xorg-docs's debian/rules, take a look at the "build" rule.
[05:57] <keescook> before it can run the "build" rule, it has to do the pre-reqs, so it performs "patch" and then "build-stamp".
[05:58] <keescook> "build-stamp" is immediately below the "build:" rule, and "patch" is defined in the xsf included makefile
[05:59] <keescook> if you look at beforelight's debian/rules, you'll see that "patch" is missing.  go ahead and add it (order is important: it needs to do "patch" before "build-stamp" -- gotta build the patched source)
[06:03] <bryce> ah, I thought "patch" was leftover from dpatch, so removed it
[06:04] <keescook> it tends to be a general rule for invoking whatever patch system has been included in the packaging.
[06:04] <keescook> no matter what the patch system, it always has to happen before the build and after the clean, etc.  :)
[06:13] <keescook> bryce: any luck with rebuilding beforelight with the fixed rules file?
[06:13] <bryce> nope, it complained I didn't have quilt
[06:13] <bryce> (installing)
[06:14] <bryce> er wait, it's already installed
[06:14] <keescook> ??
[06:14] <bryce> hrm
[06:14] <keescook> that's a build-dep
[06:14] <keescook> so you'll need to update your control file too (adding the xsf stuff, I guess, requires quilt)
[06:15] <bryce> however quilt is already listed in the Build-Depends 
[06:15] <bryce> wait
[06:15] <bryce> clearly I need stronger coffee
[06:15] <keescook> heh.  :)
[06:16] <bryce> man what a pita for such a irrelevant bit of x ;-)
[06:16] <bryce> ah well, you learn the most on things that *don't* go smoothly, eh?
[06:16] <keescook> :) but it's all for the learning.  right.  :)
[06:22] <bryce> hrm
[06:22] <bryce> No patches in series
[06:22] <bryce> No patches to apply
[06:22] <bryce> oh!
[06:22] <bryce> mv 00list series
[06:27] <bryce> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[06:27] <bryce> is that normal?
[06:27] <keescook> I think that's normal, but I honestly don't know what it means.
[06:27] <bryce> ahh
[06:27] <bryce> 100_appdefaultdir_prefix.patch
[06:27] <bryce> Applying patches...successful.
[06:27] <keescook> yay!
[06:28] <keescook> have you used quilt before?  I hadn't before doing debian packaging.  I find it... weird.
[06:28] <keescook> if you use quilt directly, don't forget to set  QUILT_PATCH=debian/patches  otherwise it'll write them to just "patches"  :)
[06:29] <bryce> there was a brief period when I started on nfsv4 where they were using quilt, before they switched to git
[06:30] <bryce> so I used it like once or twice, but I found I just needed to deal with their patches in aggregate anyway, so didn't really learn it
[06:30] <bryce> yup, got it in my .bashrc
[06:30] <keescook> cool.
[06:31] <bryce> http://pastebin.ca/522957
[06:31] <keescook> oh! sorry, it's QUILT_PATCHES  (I missed the "ES" before)
[06:31] <keescook> what do you think of the dpkg -c output?
[06:34] <bryce> hmm, well it looks the same to me as the last one
[06:35] <keescook> I would agree.  :(
[06:35] <bryce> so I'm not sure that the patch works correctly
[06:35] <keescook> what you see there is what would be installed from the deb, and nothing should ever go in /tmp or /home, etc
[06:36] <keescook> so, here's another thing, your patch only changes Makefile.am; this file is not used by the build.  (Makefile.in is used)
[06:37] <keescook> so you'll like need to add Makefile.in's changes too.
[06:37] <bryce> ah, that could be it
[06:37] <keescook> (and send the Makefile.am patch upstream, since that seems to be a legit bug)
[06:53] <bryce> 100_appdefaultdir_prefix.patch
[06:53] <bryce> Applying patches...successful.
[06:53] <keescook> :)
[06:56] <bryce> looks clean http://pastebin.4programmers.net/2319
[06:56] <keescook> eeexcellent!
[06:56] <bryce> that xorg-docs patch got accepted and applied upstream :-)
[06:56] <keescook> nice.  :)
[06:57] <keescook> okay, go ahead and upload beforelight, and I'll sponsor it in.
[06:57] <jcristau> is that patch the same as http://git.debian.org/?p=pkg-xorg/app/xbase-clients.git;a=blob;f=debian/patches/16_beforelight_install_app-defaults.diff;hb=HEAD ?
[06:57] <bryce> the xorg-docs patch was Debian's 023_specs_doc_fixes.diff
[06:58] <jcristau> yes, i saw that, thanks for forwarding it!
[06:58] <keescook> jcristau: yeah, that looks like the same beforelight patch
[06:58] <bryce> ah yes, the beforelight patch is that one
[06:58] <jcristau> ok
[07:01] <bryce> ok, posted upstream
[07:02] <jcristau> \o/
[07:02] <jcristau> i should have done that when i added the patch in the first place...
[07:03] <bryce> no prob; made for a good learning opportunity for me
[07:04] <bryce> jcristau: which brings up a question...  why does debian-x use this xsfbs system for handling patches, rather than dpatch?
[07:04] <jcristau> the primary reason would be that dpatch sucks :)
[07:05] <jcristau> but the xsfbs stuff was basically imported from the monolith, and most of it is unused now...
[07:05] <jcristau> we should work on integrating the rest in quilt proper
[07:05] <bryce> well I do have to admit I could never get dpatch working, whereas xsfbs was reasonably straightforward (all the problems I ran into were my own doing)
[07:06] <jcristau> (the fact that dpatches aren't proper patches isn't exactly helpful, e.g.)
[07:06] <bryce> yeah
[07:07] <bryce> jcristau: btw, I don't remember if I showed this to you already - http://people.ubuntu.com/~bryce/Xorg/versions_current.html
[07:07] <bryce> just for my own sanity to check what still needs merged/updated
[07:08] <jcristau> nice
[07:09] <bryce> most of what's left is just epoch number variances, or stuff that will come from the apps split out
[07:12] <jcristau> ok
[07:17] <johanbr> Hi. Has it been decided which version of Mesa will land in Gutsy? The reason I ask is that 3D support for my card was added very recently, and it'd be nice to able to ditch the fglrx driver.
[07:18] <bryce> 6.5.3 is in gutsy now
[07:18] <bryce> but the plan is for 7.0.0
[07:18] <bryce> we're just waiting for the 7.0.0 release, which I understand should be any day now (tm)
[07:19] <johanbr> I see, thank you. Will Mesa 7.0.0 include current git, or is that a different branch?
[07:20] <jcristau> it's mesa_7_0_branch
[07:20] <bryce> johanbr: any testing you could do of that branch for the mesa guys could be a big help
[07:33] <keescook> bryce: the resulting patch in debian/patches looks a little funny -- I've dropped the duplication of itself, and will upload this once it finishes building
[07:33] <keescook> the final results look fine, though.  \o/
[07:33] <bryce> ah ok
[07:35] <bryce> oh, I see, I had an extra/different copy of the patch hanging around that got tucked in.  hrm
[07:36] <keescook> yeah, before each upload, I review any patches I've touched, and then the debdiff itself between the current and older package.
[07:36] <keescook> (and I look at the diff.gz to make sure there weren't any out-of-debian/ changes
[07:36] <bryce> I think I was just being impatient, I usually check that
[07:37] <keescook> okay, uploaded!  :)
[07:37] <bryce> kewl!  thanks!
[07:39] <keescook> np :)
[07:58] <bryce> keescook: I figured out debian's naming scheme for X *proto packages.  Filled in a ton of blanks:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
[07:58] <bryce> still haven't figured out where the font-* packages go though
[07:59] <keescook> check the debian/copyright files, they should mention where they were downloaded from
[07:59] <keescook> oh, you mean the reverse, sorry
[07:59] <bryce> no, the issue... yeah
[07:59] <jcristau> xfonts-base has font-arabic-misc font-cursor-misc font-daewoo-misc font-dec-misc font-isas-misc font-jis-misc font-micro-misc font-misc-misc font-mutt-misc font-schumacher-misc font-sony-misc font-sun-misc
[08:00] <keescook> check xfonts-base, ah jcristau is too fast for me.  :)
[08:00] <bryce> ahh
[08:00] <bryce> jcristau: any plans on ever breaking those out, or will that package stay as is for a while?
[08:01] <jcristau> that'll stay as is
[08:01] <bryce> cool
[08:01] <jcristau> xfonts-100dpi: font-adobe-100dpi font-bh-100dpi font-bh-lucidatypewriter-100dpi font-bitstream-100dpi
[08:02] <jcristau> xfonts-75dpi: font-adobe-75dpi font-bh-75dpi font-bh-lucidatypewriter-75dpi font-bitstream-75dpi
[08:02] <bryce> what's the command to list what is contained in them?
[08:02] <johanbr> bryce: I tried building Mesa git a week ago, but the compile failed, apparently because it found the (old) system libdrm and I wasn't able to get it to work right. I'll see if I have time one of these days...
[08:03] <bryce> johanbr: cool, let us know if you get it working
[08:03] <jcristau> bryce: i'm using "ls" in the source tree :)
[08:03] <bryce> ahh heh
[08:03] <jcristau> xfonts-cyrillic has font-*-cyrillic
[08:04] <johanbr> bryce: Sure, will do. The Mesa 7.0.0 branch does appear to contain the support for my chipset (rs480), so it looks like I'll be able to use free drivers in Gutsy.
[08:05] <jcristau> and it looks like xfonts-scalable is actually font-bitstream-type1
[08:06] <bryce> ok /me hacks in some translation tables
[08:07] <jcristau> xfonts-encodings is called "encodings" upstream
[08:36] <jcristau> bryce: "xproto" upstream is "x11proto-core" in debian
[11:07] <ubotu> New bug: #117828 in xorg (main) "switch user" [Undecided,Needs info]  https://launchpad.net/bugs/117828