| 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:25 |
|---|---|---|
| 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:30 |
| broder | oh, nope. -i | 01:32 |
| 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:33 |
| 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:34 |
| grantbow | k, thanks, I'll have a look | 01:35 |
| grantbow | aha, diff-ignore seemed to work where extend-diff-ignore didn't. | 01:36 |
| grantbow | broder: seems to work now, thanks for your help | 01:45 |
| === PabloRubianes_ is now known as PabloRubianes | ||
| === Guest97722 is now known as bilal | ||
| 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:39 |
| 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:40 |
| 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 | 03:41 |
| === bilal_ is now known as bilal | ||
| 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") | 04:58 |
| 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:00 |
| 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 ;) | 05:01 |
| 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). | 06:25 |
| * ajmitch wonders if it's safe to sync coffeescript 1.2.0-2 from sid | 07:19 | |
| geser | ajmitch: is bug #777554 fixed in this version? | 07:35 |
| ubottu | Launchpad bug 777554 in coffeescript (Ubuntu) "coffeescript fails to find nodejs in path" [Undecided,Confirmed] https://launchpad.net/bugs/777554 | 07:35 |
| ajmitch | geser: I'll check, just updating my local mirror so I can build it | 07:37 |
| ajmitch | our nodejs version is a debian revision behind, but updating that requires updating libv8 as well | 07:38 |
| ajmitch | er, looks like I was wrong about libv8, I misread the changelog :) | 07:41 |
| === sagaci__ is now known as sagaci | ||
| === sagaci_ is now known as sagaci | ||
| === and`_ is now known as and` | ||
| ScottK | jtaylor: So if your libyaml multiarch patch gets in, does that mean I'm going to have to multi-arch pyyaml too? | 18:42 |
| jtaylor | you don't have too | 18:43 |
| jtaylor | non multiarch packages should work fine with multiarch'd ones | 18:43 |
| ScottK | So it's only be if something needed a foreign python[3]-yaml that I'd need to do it. | 18:48 |
| 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:49 |
| jtaylor | let me just try pyyaml build | 18:50 |
| jtaylor | works fine | 18:53 |
| ScottK | OK. Thanks for checking. | 18:53 |
| jtaylor | speaking of numpy, we should probably fix numpy multiarch handling for precise | 18:57 |
| jtaylor | not to late in the cycle this time | 18:57 |
| Resistance | woah net explosion | 19:09 |
| === jrib is now known as Guest20427 | ||
| === Guest20427 is now known as jrib | ||
| ScottK | jtaylor: Yes. Please. | 19:40 |
| jtaylor | ScottK: just pushed a branch, still ufly but works | 19:40 |
| jtaylor | https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867 | 19:41 |
| jtaylor | you can test it with natty's python-enable package | 19:42 |
| ScottK | jtaylor: Are the unmerged changes from Debian worth taking on too? | 19:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| * 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 | 19:58 |
| 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:03 |
| Alison_Chaiken | I am building a package that requires Qt packages, which can be from upstream repos without mods. | 20:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| ajmitch | morning | 20:10 |
| jtaylor | Alison_Chaiken: setting up a local repo is very easy | 20:10 |
| 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:11 |
| 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 | 20:12 |
| micahg | jtaylor: I can sponsor sat night, not enough time left today for me | 21:06 |
| jtaylor | thx, there is no rush | 21:06 |
| micahg | jtaylor: what am I sponsoring? | 21:10 |
| 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:11 |
| micahg | k | 21:12 |
| * ajmitch sees why you said it was a very ugly method | 21:14 | |
| === yofel_ is now known as yofel | ||
| jtaylor | yes but it works, figuring out how to fix this distutils reinvention does not look worth it | 21:23 |
| jtaylor | it doesn't even look easily fixable, the whole thing seems to be built on knowing all possible libdirs | 21:26 |
| micahg | jtaylor: I thought that's a problem with python in general | 21:31 |
| micahg | *python apps | 21:31 |
| 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:32 |
| * micahg thought barry was trying to fix it upstream somehow | 21:35 | |
| 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:38 |
| micahg | still, if it properly exported paths, couldn't you use those? | 21:39 |
| 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:41 |
| micahg | oh, is this runtime? | 21:42 |
| jtaylor | yes | 21:42 |
| micahg | ah, yeah, this is right then, annoying as it is | 21:42 |
| micahg | unless you do a build time substitution | 21:43 |
| 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:44 |
| 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 | 21:45 |
| 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:17 |
| 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:18 |
| Alison_Chaiken | Okay, so debian/<package>.install is a template we expect to change: no problem. | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!