| === r0bby_ is now known as robbyoconnor | ||
| AfC | jelmer: ping; I just hit http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644193 ; you suggest it is a bug in dpkg-source but I'm not clear on what to do about it. I'm just building packages as I always did, only now on Precise builddeb is failing | 10:16 |
|---|---|---|
| ubot5 | Debian bug 644193 in bzr-builddeb "dpkg-source: error: aborting due to unexpected upstream changes" [Normal,Open] | 10:16 |
| AfC | jelmer: is it now obligatory to commit your work-in-progress changes before calling builddeb? | 10:20 |
| AfC | Ok, so it works when invoked: | 10:22 |
| AfC | $ bzr builddeb --quick | 10:22 |
| AfC | but not when | 10:22 |
| AfC | $ bzr builddeb | 10:22 |
| AfC | (wtf) | 10:22 |
| AfC | weird | 10:22 |
| jelmer | AfC: hi | 13:04 |
| jelmer | AfC: you can no longer have changes in your working tree against upstream, all changes have to be in debian/patches | 13:05 |
| jelmer | AfC: you don't have to commit, as previously | 13:05 |
| jelmer | AfC: note that this is enforced by dpkg-source, not really related to bzr-builddeb | 13:05 |
| AfC | jelmer: that kinda really breaks the model we were using bzr builddeb under until now. | 13:42 |
| AfC | jelmer: we have a lot of code in our bzr branches :( | 13:42 |
| AfC | I wonder what the point of this change was. To force people to stop storing code in bzr? | 13:44 |
| jelmer | AfC: this has nothing to do with bzr | 13:44 |
| jelmer | AfC: it's a change in dpkg | 13:45 |
| AfC | jelmer: I realize it's dpkg-source that changed, but | 13:45 |
| AfC | jelmer: since it *completely screws* people using bzr-builddeb, it's perhaps a | 13:45 |
| AfC | jelmer: slight touch disingenuous for us to wash our hands of it. | 13:45 |
| jelmer | AfC: I think "completely screws" is an exaggeration | 13:45 |
| jelmer | AfC: you can either set an option in debian/source/local-options to force dpkg-source to not complain | 13:46 |
| AfC | jelmer: why? None of my packaging branches are building now. That counts as "blocker" in most bug trackers I've used. | 13:46 |
| jelmer | or manually put your patches in debian/patches (which you should be doing anyway) | 13:46 |
| AfC | [ok, good to know] | 13:46 |
| AfC | but why would we want to force people to put the changesets in debian/patches? | 13:47 |
| jelmer | AfC: I agree this isn't ideal, but anybody using dpkg-source in one way or another is hitting this | 13:47 |
| AfC | I mean, .debian.tar.gz contains the diff against upstream when packaged | 13:47 |
| === Quintasan_ is now known as Quintasan | ||
| AfC | so what's the harm [against enormous demonstrable benefit of using bzr{,-builddeb} to track code] | 13:47 |
| jelmer | AfC: ideally the changes against upstream should be split out in multiple quilt patches in "3.0 (quilt)" | 13:48 |
| AfC | [[I realize it wasn't you who changed dpkg-source]] | 13:48 |
| AfC | hm | 13:48 |
| AfC | (as far as I can tell, this has totally borked the importer on launchpad, too) | 13:49 |
| jelmer | AfC: which importer? | 13:49 |
| AfC | jelmer: http://package-import.ubuntu.com/status/ that importer | 13:49 |
| jelmer | AfC: previously dpkg-source would implicitly add a patch in debian/patches with the changes against the upstream source that were included in your working tree | 13:49 |
| AfC | (I could be wrong, of course, but virtually every package I care about is miles behind there, now) | 13:49 |
| AfC | jelmer: oh, didn't know that | 13:50 |
| AfC | jelmer: still, pretty annoying. I use bzr to manage changes to the code tree; the last thing I want to do is mess with quilt patches. If I was doing that, I might as well not be using ... bzr | 13:50 |
| jelmer | AfC: it was a conscious decision by the dpkg maintainers to stop doing that and to error out if there were changes in the working dir that weren't in upstream. | 13:50 |
| AfC | jelmer: fair enough; | 13:50 |
| jelmer | AfC: ideally we'd use bzr-loom and convert loom threads to quilt patches; that's still yet to emerge though | 13:51 |
| AfC | jelmer: but given that bzr-builddeb is a different (and novel, and [c.f. lifeless ← sabdfl] the whole point of "branches are the fundamental object") | 13:51 |
| AfC | jelmer: I'm a bit unclear why builddeb can't just do whatever it needs to do to trick out dpkg-whatever to get on with building the package. | 13:51 |
| jelmer | AfC: creating an implicit patch with the changes between upstream and your working tree, you mean? | 13:52 |
| AfC | jelmer: sure, why not | 13:52 |
| AfC | jelmer: implementation detail as far as I [the bzr-builddeb user who is happily managing deltas in bzr packaging branches] can see | 13:53 |
| AfC | jelmer: would have expected builddeb to take care of such minor details. After all, it takes care of about 15 other similar issues | 13:53 |
| AfC | jelmer: but instead, a *major* behaviour change has been imposed on the user base. | 13:53 |
| AfC | jelmer: I'm not saying its wrong | 13:54 |
| AfC | (after all, Debian policy decides such things) | 13:54 |
| AfC | but for your users | 13:54 |
| AfC | [ok, me] | 13:54 |
| AfC | you have just committed a *massive* API break | 13:54 |
| AfC | {shrug} | 13:54 |
| jelmer | AfC: right, but I really think you should take that up with the dpkg maintainers | 13:54 |
| AfC | in my world, if we did that to our clients we'd be fired | 13:54 |
| AfC | jelmer: but *bzr-builddeb* is the build chain we use. What goes on under the hood has (delightfully until now) been an implementation detail. | 13:55 |
| AfC | [and it's builddeb that just "broke" on us] | 13:55 |
| AfC | anyway, I appreciate you filling me in. | 13:55 |
| jelmer | AfC: so if you disagree with something in debian policy you would take it up with us too? That seems odd | 13:55 |
| AfC | is there a document somewhere that explains how we're supposed to migrate off using bzr-builddeb? | 13:56 |
| AfC | to be honest, I hadn't realized it was deprecated. | 13:56 |
| jelmer | AfC: huh, in what way is it deprecated? | 13:56 |
| AfC | jelmer: uh | 13:56 |
| AfC | jelmer: it doesn't work anymore | 13:56 |
| AfC | jelmer: in the way that we were taught to use it | 13:56 |
| jelmer | AfC: migrating away shouldn't require any special action - you can either convert the repository to a different format (such as git) or just remove the .bzr directory | 13:56 |
| AfC | jelmer: when a tool stops working | 13:57 |
| AfC | jelmer: we generally try to help people get through the migration | 13:57 |
| AfC | jelmer: [and we were taught to record changes to source trees in bzr] | 13:57 |
| AfC | jelmer: I have in turn taught numerous clients this practice. They're all screaming at me now. | 13:57 |
| jelmer | AfC: that makes sense for the 1.0 format perhaps, but certainly not for 3.0(quilt) | 13:57 |
| AfC | jelmer: I realize it's my problem for having convinced them to work in bzr, but still | 13:58 |
| jelmer | AfC: either way, you're doing Debian packaging and you're not just using bzr-builddeb but the entire set of debian packaging tools | 13:58 |
| AfC | a behaviour break like this was unexpected | 13:58 |
| jelmer | AfC: this has nothing to do with bzr | 13:58 |
| AfC | hence my asking if there's a document about how to migrate to new practices. I didn't see anything in bzr-builddeb's documentation | 13:58 |
| jelmer | AfC: the bzr-builddeb documentation documents bzr-builddeb itself, not debian packaging in general | 13:59 |
| AfC | jelmer: I get that; I've been packaging for Debian since 1997 | 13:59 |
| AfC | jelmer: what I'm saying is that until now, bzr-builddeb allowed you to use bzr as the mechanism for tracking changes to upstream code trees. | 14:00 |
| AfC | jelmer: as far as I can tell, a fair number of people thought we were supposed to be using it that way. Apparently we were wrong. Fine. | 14:00 |
| jelmer | AfC: that still works for the "1.0" format I believe | 14:00 |
| AfC | jelmer: though, at this point, I'm now vague on how you are supposed to use it. You um... dpkg-source --commit first, then bzr commit, then, um ? | 14:01 |
| jelmer | AfC: there's no need to bzr commit | 14:01 |
| AfC | jelmer: so you're not allowed to make *any* changes in bzr? | 14:01 |
| AfC | jelmer: they all have to be done outside Bazaar? | 14:01 |
| jelmer | AfC: you're not allowed to make any changes in the working copy, dpkg-source barfs if there are changes not in debian/patches | 14:02 |
| AfC | Does it work like bzr or git? ie, does it have status and diff and commit? | 14:02 |
| jelmer | AfC: I don't think it does | 14:03 |
| jelmer | AfC: some of the git packaging tools have ways of converting these quilt patches to and fro branches | 14:03 |
| jelmer | which can make them a bit more convenient to work with | 14:03 |
| AfC | jelmer: so, what is bzr-builddeb used for now that you can't manage source changes with it? Just migrating existing packages between distro/releases? | 14:05 |
| AfC | jelmer: [I'd hate to be giving out wrong information anymore] | 14:06 |
| jelmer | AfC: FWIW I've personally never had local changes in the working tree with bzr-builddeb | 14:06 |
| AfC | jelmer: ah. That explains it | 14:06 |
| jelmer | AfC: that isn't to say that's not a valid way of working with it | 14:06 |
| AfC | jelmer: there's nothing like NOT using the tool like its authors do to really set you up for a total goat-screw. | 14:07 |
| jelmer | AfC: Sorry, but how have we set you up for that? | 14:07 |
| AfC | jelmer: because those current and former #bzr employees who taught me how to use builddeb included that practice in what they showed me. | 14:08 |
| AfC | jelmer: anyway, I'm willing to accept that I've been completely in the wrong | 14:08 |
| jelmer | AfC: And I've not said you're using it wrong, just that I'm not using it that way. | 14:08 |
| AfC | jelmer: and clearly need to mend my ways. | 14:08 |
| jelmer | AfC: I have no idea how lifeless, james_w, etc use it. | 14:09 |
| AfC | jelmer: certainly worth a very bitter blog post, though. | 14:09 |
| jelmer | AfC: if you were doing the same thing in git you would be hitting the same issue | 14:10 |
| jelmer | AfC: I still don't quite see how this is on bzr-builddeb rather than dpkg | 14:10 |
| AfC | Oh, wow. Now it's failing with "no such file or directory" on the patch I just committed with dpkg-source. Fun. | 14:10 |
| jelmer | AfC: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643037 | 14:11 |
| ubot5 | Debian bug 643037 in dpkg-dev ""dpkg-source --commit" fails if there are no patches yet: No such file or directory" [Normal,Fixed] | 14:11 |
| AfC | jelmer: {shrug} I said already. Either a) we were using the tool in a legal way, in which case we've had a major user experience break, or b) we were using the tool in an illegal way, in which case it would have been nice if we'd had some warning that we were about to get in trouble. | 14:11 |
| jelmer | AfC: I agree with that, but $tool in this case is dpkg-source, not bzr-builddeb | 14:12 |
| AfC | jelmer: well, obviously I think you're wrong about that, but we can move on. | 14:12 |
| jelmer | AfC: I'd really like to understand why you think that's wrong | 14:13 |
| AfC | that doesn't seem to be the ubg | 14:13 |
| AfC | jelmer: if the scrollback doesn't do it, I'll send you a link to the blog when I write about it. | 14:13 |
| AfC | anyway, dpkg-source --commit succeeeded | 14:13 |
| jelmer | AfC: http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html is the background of this | 14:14 |
| AfC | it's bzr-builddeb that's again failing, this time with a different error. I'll see what happens with a fresh build | 14:14 |
| jelmer | AfC: you can also go back to the 1.0 format, for which dpkg considers this an appropriate way of building | 14:14 |
| jelmer | AfC: if there is only one diff file, why are you using "3.0 (quilt)" in the first place? | 14:15 |
| AfC | jelmer: think about it, mate. *I* didn't pick that. I'm branching off an existing package. If they are using 3.0, then I am too | 14:17 |
| AfC | {shrug} this is the first package I hit this on, [it's gedit] | 14:17 |
| AfC | but this is the first packaging I've done since Precise came out | 14:18 |
| jelmer | AfC: right, so if they picked 3.0 (quilt) that has an effect on the workflow you have to use | 14:18 |
| AfC | so I see | 14:18 |
| jelmer | AfC: if bzr would simply be creating a single patch for all the changes in the working tree, then that would defeat the purpose of 3.0 quilt, which is used to split the diff up into separate logical chunks. | 14:21 |
| jelmer | I also believe that's why the dpkg maintainers changed the default to no longer generate a diff but to error out | 14:21 |
| AfC | jelmer: yeah I understand | 14:22 |
| AfC | jelmer: seems like a regression though | 14:22 |
| AfC | for the past year I've been using bzr to manage changes to packages | 14:22 |
| jelmer | AfC: you still can manage your existing packages with "1.0" source format | 14:23 |
| AfC | Now apparently I'll have to throw those branches out and go back to not using a VCS. | 14:23 |
| jelmer | AfC: what would you have us do for "3.0 (quilt)" ? | 14:23 |
| AfC | jelmer: yeah, most of our branches are of packages that are existing Debian packages, and most of them have migrated to 3.0 | 14:23 |
| AfC | jelmer: {shrug} I'd have you force in a single diff | 14:24 |
| jelmer | AfC: so you would want bzr-builddeb to alter the behaviour in existing tools? | 14:24 |
| AfC | jelmer: I'm not submitting this packages to anyone. I'm just trying to build .debs | 14:24 |
| jelmer | AfC: looking through dpkg-source, it seems adding "auto-commit" to debian/source/options would prevent this error | 14:25 |
| AfC | jelmer: if that's a "bad" idea, then fine, we'll learn to get with the new way of doing it. Far be it for me to fight Debian policy. I'm just glad you were here tonight to explain to me that what we've been doing the last couple years isn't going to work anymore. | 14:26 |
| AfC | jelmer: to be honest, I've never used `dpkg-source` before, but then, I haven't used `dpkg-builddeb` directly in years either. | 14:26 |
| AfC | {shrug} builddeb was taking care of all that for us. It was delightful. | 14:26 |
| AfC | (er, -buildpackage. You know what I mean) | 14:27 |
| jelmer | AfC: yeah, debuild/dpkg-buildpackage/etc :) | 14:27 |
| AfC | so, like I said, it feels like a 5+ year regression. | 14:27 |
| AfC | jelmer: so, since I'm clearly so far off base using Bazaar to manage working trees, can I ask what you use bzr-builddeb for? | 14:28 |
| AfC | jelmer: and where you do your actual packaging work? | 14:28 |
| jelmer | AfC: Again, you weren't off base. "3.0 (quilt)" is incompatible with working-directory changes against upstream. | 14:28 |
| jelmer | AfC: I use it as an easy way to build, mostly as an alias for "debuild" | 14:29 |
| jelmer | AfC: occasionally to build historical revisions, and to get the orig source out of the packaging branch. | 14:29 |
| jelmer | AfC: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ might also be of help | 14:29 |
| AfC | Hm. So I committed a patch with dpkg-source, but the build is still failing. | 14:32 |
| AfC | Back to the drawing board. | 14:32 |
| jelmer | AfC: how did it fail, are there any unknown files reported by 'bzr st'? | 14:34 |
| AfC | I haven't used Quilt since running Gentoo in about 2003 | 14:34 |
| AfC | jelmer: | 14:35 |
| AfC | modified: | 14:35 |
| AfC | .pc/applied-patches | 14:35 |
| AfC | debian/patches/series | 14:35 |
| AfC | unknown: | 14:35 |
| AfC | .pc/99-change-redo-accelerator.patch/ | 14:35 |
| AfC | debian/patches/99-change-redo-accelerator.patch | 14:35 |
| AfC | the failure is weird, though: | 14:35 |
| AfC | dpkg-source: error: cannot read gedit-3.4.1.orig.vU2NEG/debian/patches/99-change-redo-accelerator.patch: No such file or directory | 14:36 |
| AfC | what a strange filename | 14:36 |
| jelmer | AfC: you'll need to 'bzr add' the new files in debian/patches | 14:38 |
| jelmer | AfC: and either add the .pc directory or undo the changes from the working tree | 14:39 |
| jelmer | "QUILT_PATCHES=debian/patches quilt pop -a" should do the latter for you | 14:39 |
| jelmer | there might be a shorter way, but my 3.0-quilt-foo is kindof limited | 14:39 |
| AfC | jelmer: does bzr-builddeb do a `bzr export` under the hood, or just a copy of the current working tree [with changes]? | 14:40 |
| AfC | I thought the latter | 14:40 |
| jelmer | AfC: it does an export of the working tree | 14:40 |
| AfC | so I have to bzr commit the .pc stuff, *then* build? | 14:41 |
| jelmer | AfC: so unversioned files won't be included in the export, but modifications will be | 14:41 |
| AfC | oh, ok | 14:41 |
| AfC | [weird corner case] | 14:41 |
| AfC | you said "add" | 14:41 |
| jelmer | AfC: yes, you'll have to add them so they're versioned | 14:41 |
| jelmer | AfC: but they don't have to be committed - bzr just has to know about them | 14:41 |
| AfC | yeah | 14:42 |
| AfC | ok, so this is just charming :/ | 14:42 |
| AfC | a) I used `dpkg-source --commit` to create a patch | 14:42 |
| AfC | b) I reverted the change in my working tree | 14:43 |
| AfC | c) added the aforementioned .patch | 14:43 |
| AfC | [`bzr add` that is] | 14:43 |
| AfC | which got me past the previous crash | 14:43 |
| AfC | and now I have a crash which is identical to that which started the whole conversation: aborting due to unexpected upstream changes | 14:43 |
| AfC | freaky :) | 14:43 |
| jelmer | AfC: which files does it claim have changed? | 14:44 |
| AfC | [I must admit I don't understand what the .pc files are doing, and seeing patches in diffs is always horrid to try and read] | 14:44 |
| AfC | jelmer: it doesn't say... | 14:45 |
| AfC | (reading the .build file) | 14:45 |
| AfC | jelmer: ok | 14:46 |
| AfC | jelmer: so it said | 14:46 |
| AfC | .pc/applied-patches | 14:46 |
| AfC | jelmer: was modified | 14:46 |
| AfC | jelmer: I reverted that file | 14:46 |
| AfC | and now it's building | 14:47 |
| jelmer | AfC: the .pc directory contains the quilt state, so which patches are applied, which unapplied, etc | 14:47 |
| AfC | jelmer: I couldn't believe it had an entire copy of the original [unmodified] file in there. | 14:48 |
| AfC | jelmer: I mean, I thought we got away from that after Subversion :) | 14:48 |
| AfC | talk about primative. | 14:48 |
| jelmer | heh, yeah :) | 14:48 |
| AfC | and this is the brand new shiny Debian packaging format? Jeesh | 14:49 |
| AfC | jelmer: well, thank you for your help | 14:50 |
| AfC | jelmer: there's no way I would have navigated that by myself. | 14:51 |
| AfC | Major conceptual mismatch, to be sure | 14:51 |
| jelmer | AfC: anytime :) | 14:51 |
| AfC | I'll have to sit my team down and have a review of this, because we were planning to ramp up our use of the "old" way of doing things quite substantially. | 14:51 |
| AfC | They were quite enthusiastic about bzr as a result of what I'd showed them about comparing different branches | 14:52 |
| jelmer | I guess in a way it's indeed like a primitive version control system, and that's one of the reasons it's so hard to deal with it /and/ bzr, git or hg. | 14:52 |
| AfC | Seeing patches in VCS diffs is not exciting in the sightest. | 14:52 |
| jelmer | I've been meaning to play with some of the git debian tools (there are three equivalents to bzr-builddeb for git), apparently they do some smarter stuff than we do, like maintaining separate branches for each patch and automatically generating debian/patches from that. | 14:52 |
| AfC | Interesting | 14:53 |
| AfC | jelmer: I have no Git skills at all, which is becoming harder and harder to admit to people. | 14:54 |
| AfC | Bah | 14:56 |
| AfC | I can't believe I am about to commit a *patch* to a version control system. | 14:57 |
| AfC | Next they'll be telling me to commit binaries :/ | 14:57 |
| jelmer | AfC: Git's UI is significantly better than what it used to be 5 years ago, it's really not too bad. I'm sure you could learn most of it in a couple of hours. | 14:59 |
| AfC | jelmer: well, I'm about to have to do a bunch of work against a git repo. I'm hoping I can get by using bzr to shuttle patches to my git clone. It's not clear to me yet whether bzr-git will let me push from there safely or not. Hard to experiment without [risking] making a big mess | 15:00 |
| AfC | we'll see | 15:00 |
| AfC | [I dog fooded Git for 6 months circa 2006. Ick. Oh well :)] | 15:00 |
| AfC | [back to packaging] | 15:02 |
| AfC | Wow, this is a horrid regression | 15:02 |
| AfC | so before when upstream released a new version and that code propegated to us via import-dsc and friends, | 15:02 |
| AfC | we would get those changes into our working tree and then could resolve conflicts and carry on. | 15:02 |
| AfC | Now my changes are *not* in the working tree, but instead in unapplied patches. | 15:03 |
| AfC | God, I hope I'm missing something obvious about all this. | 15:03 |
| jelmer | AfC: yep | 15:03 |
| jelmer | AfC: you can use quilt to try and fix up the patches afterwards | 15:04 |
| AfC | This is awful | 15:04 |
| AfC | Are you sure we can't just take our working tree and blat it down as a single patch before building binaries? | 15:04 |
| jelmer | it would be really nice if we could represent patches as branches here (and just "up-merge" the new upstream release) | 15:04 |
| jelmer | AfC: you can, but I'm not sure if your comaintainers will appreciate that, since they changed to 3.0(quilt) | 15:04 |
| AfC | jelmer: {shrug} | 15:05 |
| jelmer | AfC: I think "echo auto-commit > debian/source/options" will do that | 15:05 |
| jelmer | (and bzr adding that file) | 15:05 |
| AfC | jelmer: I differentiate pretty significantly between what we have to do to maintain *our* packages, and then shifting frame-of-reference and doing whatever is necessary to submit a patch upstream (or to downstream peer) | 15:05 |
| AfC | jelmer: ok, I'll look at that | 15:06 |
| AfC | jelmer: I'm just reading the man page for dpkg-source now | 15:09 |
| AfC | jelmer: there's a useful discussion under --single-debian-patch | 15:09 |
| jelmer | AfC: hmm, indeed | 15:10 |
| AfC | jelmer: so I'm starting to get it now. I see the difference between 3.0 ({native,quilt,git,bzr}) | 15:11 |
| jelmer | AfC: (note that 3.0 (git) and 3.0 (bzr) aren't actually used in practice) | 15:11 |
| AfC | jelmer: right; I need to adapt to whatever is going on in the original package I've forked from | 15:11 |
| jelmer | I don't think I've actually seen a package that used either "3.0 (git)" or "3.0 (bzr)" | 15:12 |
| AfC | jelmer: though now that I understand, I think auto-commit would be the least disruptive. Have to test it. Certainly be more sensible locally. | 15:12 |
| AfC | [in the event of a 3.0 (quilt) | 15:12 |
| AfC | format package[ | 15:12 |
| jelmer | AfC: yeah, looks like it | 15:13 |
| AfC | jelmer: I will definitely write this up | 15:14 |
| AfC | jelmer: thanks for your help | 15:14 |
| AfC | [trying that experiment now, while everything is open] | 15:14 |
| AfC | Build running | 15:17 |
| AfC | Nice. So I suspended the build, and looked in ../build-area/ | 15:18 |
| AfC | There is indeed a new patch added to the end of debian/patches/series | 15:18 |
| AfC | along with a new patch file there | 15:18 |
| AfC | filename | 15:18 |
| AfC | debian/patches/debian-changes-3.4.1-0ubuntu2~afcowie2~precise2 | 15:19 |
| jelmer | ah, cool :) | 15:20 |
| AfC | Raises an interesting issue, of course | 15:20 |
| AfC | Are the debian/patches applied in the bzr[-builddeb] working tree, or not? | 15:21 |
| AfC | Huh. It seems they *are* applied. | 15:22 |
| AfC | [great!] | 15:22 |
| AfC | jelmer: did you know that? | 15:23 |
| jelmer | AfC: yeah, they would have to be | 15:24 |
| jelmer | bzr exports the tree including the working tree changes | 15:24 |
| AfC | [and then dpkg-source unapplies them before building where it ... applies them? Head hurts] | 15:24 |
| jelmer | and then calls dpkg-source in the working tree. dpkg-source then generates a matching patch in debian/patches and makes sure the other patches are all applied | 15:24 |
| jelmer | AfC: I think dpkg-source unapplied all patches first so it can generate your auto-commit patches without including the changes from the other patches. | 15:25 |
| AfC | Remind me to use 3.0 (native) for my own work :) | 15:25 |
| AfC | jelmer: maybe | 15:25 |
| AfC | jelmer: I'm just pleased that bzr-builddeb's working tree includes the debian/patch series applied | 15:25 |
| AfC | jelmer: 01:30 local, time for me to pack it in. Business calls first thing tomorrow. | 15:27 |
| AfC | jelmer: Thanks for your patience. | 15:27 |
| AfC | jelmer: we definitely need to write this up. I'll show you the post once I've got it drafted; please feel free to offer critique or corrections. | 15:28 |
| jelmer | AfC: sure, it would be great to document this better | 15:29 |
| jelmer | AfC: good night! | 15:29 |
| hmmh | hi guys - was wondering if anyone can lend a helping hand - i have the bazaar "daily" builds going for our pkg, but when i install them, there is no binary?! | 15:40 |
| hmmh | what am i doing wwrong? | 15:40 |
| jelmer | hmmh: hi | 15:44 |
| jelmer | hmmh: does building the package on your local machine work? | 15:44 |
| hmmh | yes (i have not confirmed the last recepie - will check that now, thanks) but I have no err during build and so on .... hmm | 15:48 |
| hmmh | yes it does build/install no problem | 16:04 |
| hmmh | if tested locally | 16:04 |
| hmmh | .....but there is no binary as well in the local install ....this is definitely a wrong recipe - any help? | 16:09 |
| jelmer | hmmh: have you tried the recipe locally? | 16:35 |
| jelmer | hmmh: this kind of issue is generally just a bug in the packaging | 16:35 |
| hmmh | jemler: yes i tried it locally - but i have the same result - makes and installs a pkg ..but with no binaries.. | 16:38 |
| hmmh | jelmer: my recepie has "nest-part packaging lp:~our/+junk/ourpkg debian debian" - is this correct? | 16:41 |
| jelmer | hmmh: that seems right | 16:44 |
| jelmer | hmmh: have you tried creating just the source package and seeing if that has the right contents? | 16:45 |
| hmmh | jelmer: when i create regular pkgs (not for daily builds, not using the "code brunch") - there is no problem installing and creating the pkg | 16:46 |
| jelmer | hmmh: recipe builds only create source packages, the binaries that are created afterwards are built from those source packages and are not in any way special | 16:51 |
| jelmer | so if this is a problem with the recipe, you should be able to find the issue in the source packages that are created by "bzr dailydeb" | 16:52 |
| hmmh | jelmer: which source pkgs? it creates the sources dirs and nests the debian dir under...... what just noticed is that in my control file i have " (1.3beta1-4ubuntu4) maverick; urgency=low" | 16:58 |
| hmmh | jelmer: could "maverick" be the issue | 16:58 |
| hmmh | hi, does anybody know how can i upload to my "code" from Git? | 19:47 |
| lifeless | what do you mean by your "code" ? | 20:08 |
| hmmh | well ... i would like to make a bazaar branch FROM a git repo.. | 20:11 |
| hmmh | and then build daily pkg based on a receipt | 20:11 |
| hmmh | i meant recipie | 20:12 |
| lifeless | In Launchpad, or separately ? | 20:31 |
| hmmh | in launchpad | 20:33 |
| hmmh | I have a launchpad , I would like to clone a git repo, import that into bazaar and make daily builds based on it and continue to import new revsisions from the git master - is that possible ? | 20:34 |
| lifeless | you can use an import branch to get your code into bazaar | 20:34 |
| lifeless | https://help.launchpad.net/Code/Imports | 20:35 |
| hmmh | yep I saw that - so this is the only way - I have to request an official import? | 20:35 |
| lifeless | that or manage it yourself | 20:46 |
| lifeless | e.g. use git-bzr or bzr-git and cron and so on | 20:47 |
| hmmh | thank you for the answer - how do i use bzr-git? ant example? | 20:48 |
| jelmer | hmmh: 'bzr branch git://some/git/url bzr-import', if you have bzr-git installed | 20:53 |
| lifeless | hmmh: most folk wanting recipe builds do it all in Launchpad | 20:56 |
| lifeless | hmmh: as its easier | 20:56 |
| hmmh | jelmer: is that the preferred way, or you can use that as well - bzr git-import git://some/git/url ? | 20:56 |
| === yofel_ is now known as yofel | ||
| jelmer | hmmh: bzr git-import imports all branches, 'bzr branch' just the current one | 21:25 |
| hmmh | jelmer: the current one , you mean the current revision of git? | 21:26 |
| hmmh | the last commit ? | 21:27 |
| jelmer | hmmh: the active branch | 21:29 |
| jelmer | hmmh: IOW, HEAD | 21:30 |
| hmmh | k, thanks | 21:31 |
| hmmh | jelmer: after i do "'bzr branch git://some/git/url" , can i import that directly - "bzr push lp:~ourlaunchpad" ? | 21:34 |
| hmmh | jelmer: and use it as a base, then get the pkging info from a different LP id? would that be ok to do? or not supposed to do it that way? | 21:39 |
| jelmer | hmmh: you can push to lp:~ourlaunchpad after you've imported, yes | 21:42 |
| jelmer | hmmh: a recipe can use branches owned by different users | 21:42 |
| lifeless | hmmh: the way you're meant to do it is use an LP code import + an LP hosted packaging branch, the owners of the two things can be different | 21:43 |
| hmmh | thank you guys | 21:53 |
| jelmer | hmmh: have you tried downloading the source package and seeing if that is correct? | 21:58 |
| hmmh | jelmer: this is the problem that we have - https://code.launchpad.net/~oisf/+recipe/testing-daily-2 - everything builds fine ... but when installed , there are no binaries - sorry to bother, much appreciated if you can share an oppinion. | 21:58 |
| jelmer | hmmh: have you tried downloading the source package and seeing if that is correct? | 21:58 |
| hmmh | yes ... when i get the source pkg , i get the tar.gz the .dsc everything is there... | 22:06 |
| jelmer | hmmh: in that case the recipe is unrelated - the recipe is only used to build the source package | 22:50 |
| jelmer | hmmh: after that, it's just the regular build process for source packages | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!