[01:25] 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] 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] err, -I [01:32] oh, nope. -i [01:33] 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] but are you passing -i? [01:33] --extend-diff-ignore changes the behavior of -i, but it doesn't imply the option [01:34] at least, that's my read of the dpkg-source manpage [01:34] you might be able to put "diff-ignore" in debian/source/options [01:35] k, thanks, I'll have a look [01:36] aha, diff-ignore seemed to work where extend-diff-ignore didn't. [01:45] broder: seems to work now, thanks for your help === PabloRubianes_ is now known as PabloRubianes === Guest97722 is now known as bilal [03:39] 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] 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] Alison_Chaiken: it's like the controller for the packaging [03:41] here's how the Debian policy manual describes it: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules === bilal_ is now known as bilal [04:58] 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] 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] 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] 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] Hey, I have a reprepro with two packages in it now: yahoo! How far behind can fame and fortune be? [06:25] 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] ajmitch: is bug #777554 fixed in this version? [07:35] Launchpad bug 777554 in coffeescript (Ubuntu) "coffeescript fails to find nodejs in path" [Undecided,Confirmed] https://launchpad.net/bugs/777554 [07:37] geser: I'll check, just updating my local mirror so I can build it [07:38] our nodejs version is a debian revision behind, but updating that requires updating libv8 as well [07:41] er, looks like I was wrong about libv8, I misread the changelog :) === sagaci__ is now known as sagaci === sagaci_ is now known as sagaci === and`_ is now known as and` [18:42] jtaylor: So if your libyaml multiarch patch gets in, does that mean I'm going to have to multi-arch pyyaml too? [18:43] you don't have too [18:43] non multiarch packages should work fine with multiarch'd ones [18:48] So it's only be if something needed a foreign python[3]-yaml that I'd need to do it. [18:49] yes [18:49] unless pyyamls build is broken and can't deal with multiarch paths [18:49] which is not rare in python extensions :/ [18:49] python-gd and numpy come to mind [18:50] let me just try pyyaml build [18:53] works fine [18:53] OK. Thanks for checking. [18:57] speaking of numpy, we should probably fix numpy multiarch handling for precise [18:57] not to late in the cycle this time [19:09] woah net explosion === jrib is now known as Guest20427 === Guest20427 is now known as jrib [19:40] jtaylor: Yes. Please. [19:40] ScottK: just pushed a branch, still ufly but works [19:41] https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867 [19:42] you can test it with natty's python-enable package [19:50] jtaylor: Are the unmerged changes from Debian worth taking on too? [19:51] I'm hoping numpy 1.6 gets in testing in time for precise [19:51] Right, but in the meantime do we want what's in -3? [19:52] I'll have a look [19:52] question for the motus when you're not busy discussing amongst each other... [19:52] how much additional work is necessary to go from a single-binary source package, to a multiple-binary source package? [19:52] thanks [19:53] 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] hm looks like a change for binNMU's [19:53] doesn't look necessary for ubuntu [19:54] 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] or maybe it is [19:54] (I'm aware of how single-binary packages are made :P) [19:55] The first one is that files in /debian that were generic like install or docs need to be binary specific. [19:55] So it might be libfoo.install and libfoo-dev.install [19:57] ScottK: no its not necessary for ubuntu [19:57] K [19:57] 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] I bet micahg would do it. [19:58] thx [20:03] 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] I am building a package that requires Qt packages, which can be from upstream repos without mods. [20:07] 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] Or must I perform some additional step to make this prompting happen? [20:07] they will be installed automatically, but I already told you you don't need to manually list them [20:08] *when installed with apt-get or aptitude [20:08] or gdebi [20:08] Because I can just use the {shlibs} macro in the Depends. [20:09] 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] psusi: looks like a relict from pre 3.0 times, now its just an "autoreconf-stamp" [20:09] I guess I should just put the repo up and let everyone try it. [20:10] morning [20:10] Alison_Chaiken: setting up a local repo is very easy [20:11] jtaylor, right... it should have been removed when converting to 3.0 right? [20:11] s/removed/renamed/ [20:11] renamed? [20:12] useful to quickly test upgrades without having to wait for slow ppas [20:12] it shouldn't be (de)applying patches in the rules file at all since dpkg-source takes care of that [20:12] shouldn't it? [20:12] it doesn't it now only autoreconf#s [21:06] jtaylor: I can sponsor sat night, not enough time left today for me [21:06] thx, there is no rush [21:10] jtaylor: what am I sponsoring? [21:11] micahg: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867/+merge/87165 [21:11] I also fixed up the svn sasl fix [21:12] k [21:14] * ajmitch sees why you said it was a very ugly method === yofel_ is now known as yofel [21:23] yes but it works, figuring out how to fix this distutils reinvention does not look worth it [21:26] it doesn't even look easily fixable, the whole thing seems to be built on knowing all possible libdirs [21:31] jtaylor: I thought that's a problem with python in general [21:31] *python apps [21:32] depends, python distutils has tools to just try linking to figure out if a library is there [21:32] like autotools [21:32] 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] jtaylor: I'm wondering ATM why the x11 pkg-config file seems useless [21:38] pkg-config is the solution but numpy.distutils does not use it [21:39] still, if it properly exported paths, couldn't you use those? [21:41] subprocess pkg-config instead of dpkg? [21:41] I don't see the difference except dpkg is always installed pkg-config not [21:42] oh, is this runtime? [21:42] yes [21:42] ah, yeah, this is right then, annoying as it is [21:43] unless you do a build time substitution [21:44] which is just as ugly [21:44] yeah, although would be a tad faster [21:44] but less robust for upstream [21:45] I don'tthink performance is an issue its not like distutils is imported in performance critical tools [21:45] just for pkg building [22:17] 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/.install file? [22:17] Or is it more usual to hand-edit the debian/.install file by hand? [22:17] Or is there a 3rd preferred method I've missed altogether? [22:18] My files show up in debian/tmp, but not in the final debs, presumably because the .install files don't list them. [22:18] you only need to use dh_make once at the start, to create a template for you to edit [22:18] after that just create stuff by hand [22:19] Okay, so debian/.install is a template we expect to change: no problem.