[01:25] <grantbow> maybe a newbie question: any idea why in debian/source/options extend-diff-ignore = "(^|/)(\.bzr)$" isn't excluding the .bzr directory in a source/format 1.0 package?
[01:30] <broder> grantbow: i don't think that option does anything on its own - my understanding is you have to pass -i to debuild/dpkg-buildpackage/whatever to ignore files in the diff, and -i automatically ignores .bzr
[01:30] <broder> err, -I
[01:32] <broder> oh, nope. -i
[01:33] <grantbow> perhaps my older dpkg-source and lack of source/format 3.0 are an issue. when I run debuild it says it's using the option but doesn't ignore the files.
[01:33] <broder> but are you passing -i?
[01:33] <broder> --extend-diff-ignore changes the behavior of -i, but it doesn't imply the option
[01:34] <broder> at least, that's my read of the dpkg-source manpage
[01:34] <broder> you might be able to put "diff-ignore" in debian/source/options
[01:35] <grantbow> k, thanks, I'll have a look
[01:36] <grantbow> aha, diff-ignore seemed to work where extend-diff-ignore didn't.
[01:45] <grantbow> broder: seems to work now, thanks for your help
[03:39] <Alison_Chaiken> Would it be correct to say that the purpose of the debian/rules file is to describe the project's pre-existing build system to the packaging system?
[03:40] <Alison_Chaiken> Obviously there are a few other things in the rules, like resources that the usual build system won't normally touch but that need to be bundled in the package.
[03:41] <micahg> Alison_Chaiken: it's like the controller for the packaging
[03:41] <micahg> here's how the Debian policy manual describes it: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[04:58] <JanC> Alison_Chaiken: I think that's an interesting description of it, but it is actually a build system on its own that in most cases re-uses the pre-existing build system for convenience (and in that case it "describes the project's pre-existing build system")
[05:00] <Alison_Chaiken> I take your point, JanC: the debian/rules is a Makefile that consumes and extends other makefiles because it has larger work to do.
[05:01] <Alison_Chaiken> Part of the task of the rules-monger is to make sure that the dpkg-build knows what it's eating, but only part, as the normal project build is just the first step.
[05:01] <JanC> well, in theory it could be the complete Makefile on its own, just that most package maintainers wisely re-use the existing ones  ;)
[06:25] <Alison_Chaiken> Hey, I have a reprepro with two packages in it now: yahoo!   How far behind can fame and fortune be?
[06:25] <Alison_Chaiken> Thanks to everyone here for their patient and valuable advice (not sarcastic -- serious).
[07:19]  * ajmitch wonders if it's safe to sync coffeescript 1.2.0-2 from sid
[07:35] <geser> ajmitch: is bug #777554 fixed in this version?
[07:37] <ajmitch> geser: I'll check, just updating my local mirror so I can build it
[07:38] <ajmitch> our nodejs version is a debian revision behind, but updating that requires updating libv8 as well
[07:41] <ajmitch> er, looks like I was wrong about libv8, I misread the changelog :)
[18:42] <ScottK> jtaylor: So if your libyaml multiarch patch gets in, does that mean I'm going to have to multi-arch pyyaml too?
[18:43] <jtaylor> you don't have too
[18:43] <jtaylor> non multiarch packages should work fine with multiarch'd ones
[18:48] <ScottK> So it's only be if something needed a foreign python[3]-yaml that I'd need to do it.
[18:49] <jtaylor> yes
[18:49] <jtaylor> unless pyyamls build is broken and can't deal with multiarch paths
[18:49] <jtaylor> which is not rare in python extensions :/
[18:49] <jtaylor> python-gd and numpy come to mind
[18:50] <jtaylor> let me just try pyyaml build
[18:53] <jtaylor> works fine
[18:53] <ScottK> OK.  Thanks for checking.
[18:57] <jtaylor> speaking of numpy, we should probably fix numpy multiarch handling for precise
[18:57] <jtaylor> not to late in the cycle this time
[19:09] <Resistance> woah net explosion
[19:40] <ScottK> jtaylor: Yes.  Please.
[19:40] <jtaylor> ScottK: just pushed a branch, still ufly but works
[19:41] <jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867
[19:42] <jtaylor> you can test it with natty's python-enable package
[19:50] <ScottK> jtaylor: Are the unmerged changes from Debian worth taking on too?
[19:51] <jtaylor> I'm hoping numpy 1.6 gets in testing in time for precise
[19:51] <ScottK> Right, but in the meantime do we want what's in -3?
[19:52] <jtaylor> I'll have a look
[19:52] <Resistance> question for the motus when you're not busy discussing amongst each other...
[19:52] <Resistance> how much additional work is necessary to go from a single-binary source package, to a multiple-binary source package?
[19:52] <ScottK> thanks
[19:53] <ScottK> Resistance: The first time you do it it's probably a bit of work to understand what you're up to, but in general, not hard at all.
[19:53] <jtaylor> hm looks like a change for binNMU's
[19:53] <jtaylor> doesn't look necessary for ubuntu
[19:54] <Resistance> ScottK:  well given i'm most likely going to be making test packages through pbuilder, to make sure i get the gist of it, so any pointers would be appreciated :)
[19:54] <jtaylor> or maybe it is
[19:54] <Resistance> (I'm aware of how single-binary packages are made :P)
[19:55] <ScottK> The first one is that files in /debian that were generic like install or docs need to be binary specific.
[19:55] <ScottK> So it might be libfoo.install and libfoo-dev.install
[19:57] <jtaylor> ScottK: no its not necessary for ubuntu
[19:57] <ScottK> K
[19:57] <jtaylor> we only have one python version left + no binNMU's
[19:58]  * ScottK is busy with $WORK now, but might be able to sponsor later if no one else does.
[19:58] <ScottK> I bet micahg would do it.
[19:58] <jtaylor> thx
[20:03] <psusi> the gtk+-2.0 package's rules file has patch-stamp and clean rules to apply and deapply the quilt patches, but it's supposedly a 3.0 (quilt) format package.. that's a packaging error isn't it?
[20:06] <Alison_Chaiken> I am building a package that requires Qt packages, which can be from upstream repos without mods.
[20:07] <Alison_Chaiken> If in my debian/control file, I list the Qt packages as Depends, does that mean that the user will be prompted to install the Qt packages when they try to install my package?
[20:07] <Alison_Chaiken> Or must I perform some additional step to make this prompting happen?
[20:07] <jtaylor> they will be installed automatically, but I already told you you don't need to manually list them
[20:08] <jtaylor> *when installed with apt-get or aptitude
[20:08] <jtaylor> or gdebi
[20:08] <Alison_Chaiken> Because I can just use the {shlibs} macro in the Depends.
[20:09] <Alison_Chaiken> Sorry if I'm repeating myself.    It's a lot of new material.   I am making some progress, but am stopping to reflect whether I'm doing everything the right way.
[20:09] <jtaylor> psusi: looks like a relict from pre 3.0 times, now its just an "autoreconf-stamp"
[20:09] <Alison_Chaiken> I guess I should just put the repo up and let everyone try it.
[20:10] <ajmitch> morning
[20:10] <jtaylor> Alison_Chaiken: setting up a local repo is very easy
[20:11] <psusi> jtaylor, right... it should have been removed when converting to 3.0 right?
[20:11] <jtaylor> s/removed/renamed/
[20:11] <psusi> renamed?
[20:12] <jtaylor> useful to quickly test upgrades without having to wait for slow ppas
[20:12] <psusi> it shouldn't be (de)applying patches in the rules file at all since dpkg-source takes care of that
[20:12] <psusi> shouldn't it?
[20:12] <jtaylor> it doesn't it now only autoreconf#s
[21:06] <micahg> jtaylor: I can sponsor sat night, not enough time left today for me
[21:06] <jtaylor> thx, there is no rush
[21:10] <micahg> jtaylor: what am I sponsoring?
[21:11] <jtaylor> micahg: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867/+merge/87165
[21:11] <jtaylor> I also fixed up the svn sasl fix
[21:12] <micahg> k
[21:14]  * ajmitch sees why you said it was a very ugly method
[21:23] <jtaylor> yes but it works, figuring out how to fix this distutils reinvention does not look worth it
[21:26] <jtaylor> it doesn't even look easily fixable, the whole thing seems to be built on knowing all possible libdirs
[21:31] <micahg> jtaylor: I thought that's a problem with python in general
[21:31] <micahg> *python apps
[21:32] <jtaylor> depends, python distutils has tools to just try linking to figure out if a library is there
[21:32] <jtaylor> like autotools
[21:32] <jtaylor> but as you have the full power of python in distutil every app tends to invent its own little broken method
[21:35]  * micahg thought barry was trying to fix it upstream somehow
[21:38] <micahg> jtaylor: I'm wondering ATM why the x11 pkg-config file seems useless
[21:38] <jtaylor> pkg-config is the solution but numpy.distutils does not use it
[21:39] <micahg> still, if it properly exported paths, couldn't you use those?
[21:41] <jtaylor> subprocess pkg-config instead of dpkg?
[21:41] <jtaylor> I don't see the difference except dpkg is always installed pkg-config not
[21:42] <micahg> oh, is this runtime?
[21:42] <jtaylor> yes
[21:42] <micahg> ah, yeah, this is right then, annoying as it is
[21:43] <micahg> unless you do a build time substitution
[21:44] <jtaylor> which is just as ugly
[21:44] <micahg> yeah, although would be a tad faster
[21:44] <micahg> but less robust for upstream
[21:45] <jtaylor> I don'tthink performance is an issue its not like distutils is imported in performance critical tools
[21:45] <jtaylor> just for pkg building
[22:17] <Alison_Chaiken> One more question: my packages as built are missing some files.   Should I tell dh_make to include them with "--add-missing" when I create the debian/<package>.install file?
[22:17] <Alison_Chaiken> Or is it more usual to hand-edit the debian/<package>.install file by hand?
[22:17] <Alison_Chaiken> Or is there a 3rd preferred method I've missed altogether?
[22:18] <Alison_Chaiken> My files show up in debian/tmp, but not in the final debs, presumably because the <package>.install files don't list them.
[22:18] <Laney> you only need to use dh_make once at the start, to create a template for you to edit
[22:18] <Laney> after that just create stuff by hand
[22:19] <Alison_Chaiken> Okay, so debian/<package>.install is a template we expect to change: no problem.