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