=== r0bby_ is now known as robbyoconnor
AfCjelmer: 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 failing10:16
ubot5Debian bug 644193 in bzr-builddeb "dpkg-source: error: aborting due to unexpected upstream changes" [Normal,Open]10:16
AfCjelmer: is it now obligatory to commit your work-in-progress changes before calling builddeb?10:20
AfCOk, so it works when invoked:10:22
AfC$ bzr builddeb --quick10:22
AfCbut not when10:22
AfC$ bzr builddeb10:22
jelmerAfC: hi13:04
jelmerAfC: you can no longer have changes in your working tree against upstream, all changes have to be in debian/patches13:05
jelmerAfC: you don't have to commit, as previously13:05
jelmerAfC: note that this is enforced by dpkg-source, not really related to bzr-builddeb13:05
AfCjelmer: that kinda really breaks the model we were using bzr builddeb under until now.13:42
AfCjelmer: we have a lot of code in our bzr branches :(13:42
AfCI wonder what the point of this change was. To force people to stop storing code in bzr?13:44
jelmerAfC: this has nothing to do with bzr13:44
jelmerAfC: it's a change in dpkg13:45
AfCjelmer: I realize it's dpkg-source that changed, but13:45
AfCjelmer: since it *completely screws* people using bzr-builddeb, it's perhaps a13:45
AfCjelmer: slight touch disingenuous for us to wash our hands of it.13:45
jelmerAfC: I think "completely screws" is an exaggeration13:45
jelmerAfC: you can either set an option in debian/source/local-options to force dpkg-source to not complain13:46
AfCjelmer: why? None of my packaging branches are building now. That counts as "blocker" in most bug trackers I've used.13:46
jelmeror manually put your patches in debian/patches (which you should be doing anyway)13:46
AfC[ok, good to know]13:46
AfCbut why would we want to force people to put the changesets in debian/patches?13:47
jelmerAfC: I agree this isn't ideal, but anybody using dpkg-source in one way or another is hitting this13:47
AfCI mean, .debian.tar.gz contains the diff against upstream when packaged13:47
=== Quintasan_ is now known as Quintasan
AfCso what's the harm [against enormous demonstrable benefit of using bzr{,-builddeb} to track code]13:47
jelmerAfC: 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(as far as I can tell, this has totally borked the importer on launchpad, too)13:49
jelmerAfC: which importer?13:49
AfCjelmer: http://package-import.ubuntu.com/status/ that importer13:49
jelmerAfC: previously dpkg-source would implicitly add a patch in debian/patches with the changes against the upstream source that were included in your working tree13:49
AfC(I could be wrong, of course, but virtually every package I care about is miles behind there, now)13:49
AfCjelmer: oh, didn't know that13:50
AfCjelmer: 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 ... bzr13:50
jelmerAfC: 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
AfCjelmer: fair enough;13:50
jelmerAfC: ideally we'd use bzr-loom and convert loom threads to quilt patches; that's still yet to emerge though13:51
AfCjelmer: 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
AfCjelmer: 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
jelmerAfC: creating an implicit patch with the changes between upstream and your working tree, you mean?13:52
AfCjelmer: sure, why not13:52
AfCjelmer: implementation detail as far as I [the bzr-builddeb user who is happily managing deltas in bzr packaging branches] can see13:53
AfCjelmer: would have expected builddeb to take care of such minor details. After all, it takes care of about 15 other similar issues13:53
AfCjelmer: but instead, a *major* behaviour change has been imposed on the user base.13:53
AfCjelmer: I'm not saying its wrong13:54
AfC(after all, Debian policy decides such things)13:54
AfCbut for your users13:54
AfC[ok, me]13:54
AfCyou have just committed a *massive* API break13:54
jelmerAfC: right, but I really think you should take that up with the dpkg maintainers13:54
AfCin my world, if we did that to our clients we'd be fired13:54
AfCjelmer: 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
AfCanyway, I appreciate you filling me in.13:55
jelmerAfC: so if you disagree with something in debian policy you would take it up with us too? That seems odd13:55
AfCis there a document somewhere that explains how we're supposed to migrate off using bzr-builddeb?13:56
AfCto be honest, I hadn't realized it was deprecated.13:56
jelmerAfC: huh, in what way is it deprecated?13:56
AfCjelmer: uh13:56
AfCjelmer: it doesn't work anymore13:56
AfCjelmer: in the way that we were taught to use it13:56
jelmerAfC: 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 directory13:56
AfCjelmer: when a tool stops working13:57
AfCjelmer: we generally try to help people get through the migration13:57
AfCjelmer: [and we were taught to record changes to source trees in bzr]13:57
AfCjelmer: I have in turn taught numerous clients this practice. They're all screaming at me now.13:57
jelmerAfC: that makes sense for the 1.0 format perhaps, but certainly not for 3.0(quilt)13:57
AfCjelmer: I realize it's my problem for having convinced them to work in bzr, but still13:58
jelmerAfC: either way, you're doing Debian packaging and you're not just using bzr-builddeb but the entire set of debian packaging tools13:58
AfCa behaviour break like this was unexpected13:58
jelmerAfC: this has nothing to do with bzr13:58
AfChence my asking if there's a document about how to migrate to new practices. I didn't see anything in bzr-builddeb's documentation13:58
jelmerAfC: the bzr-builddeb documentation documents bzr-builddeb itself, not debian packaging in general13:59
AfCjelmer: I get that; I've been packaging for Debian since 199713:59
AfCjelmer: 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
AfCjelmer: 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
jelmerAfC: that still works for the "1.0" format I believe14:00
AfCjelmer: 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
jelmerAfC: there's no need to bzr commit14:01
AfCjelmer: so you're not allowed to make *any* changes in bzr?14:01
AfCjelmer: they all have to be done outside Bazaar?14:01
jelmerAfC: you're not allowed to make any changes in the working copy, dpkg-source barfs if there are changes not in debian/patches14:02
AfCDoes it work like bzr or git? ie, does it have status and diff and commit?14:02
jelmerAfC: I don't think it does14:03
jelmerAfC: some of the git packaging tools have ways of converting these quilt patches to and fro branches14:03
jelmerwhich can make them a bit more convenient to work with14:03
AfCjelmer: 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
AfCjelmer: [I'd hate to be giving out wrong information anymore]14:06
jelmerAfC: FWIW I've personally never had local changes in the working tree with bzr-builddeb14:06
AfCjelmer: ah. That explains it14:06
jelmerAfC: that isn't to say that's not a valid way of working with it14:06
AfCjelmer: there's nothing like NOT using the tool like its authors do to really set you up for a total goat-screw.14:07
jelmerAfC: Sorry, but how have we set you up for that?14:07
AfCjelmer: because those current and former #bzr employees who taught me how to use builddeb included that practice in what they showed me.14:08
AfCjelmer: anyway, I'm willing to accept that I've been completely in the wrong14:08
jelmerAfC: And I've not said you're using it wrong, just that I'm not using it that way.14:08
AfCjelmer: and clearly need to mend my ways.14:08
jelmerAfC: I have no idea how lifeless, james_w, etc use it.14:09
AfCjelmer: certainly worth a very bitter blog post, though.14:09
jelmerAfC: if you were doing the same thing in git you would be hitting the same issue14:10
jelmerAfC: I still don't quite see how this is on bzr-builddeb rather than dpkg14:10
AfCOh, wow. Now it's failing with "no such file or directory" on the patch I just committed with dpkg-source. Fun.14:10
jelmerAfC: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64303714:11
ubot5Debian bug 643037 in dpkg-dev ""dpkg-source --commit" fails if there are no patches yet: No such file or directory" [Normal,Fixed]14:11
AfCjelmer: {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
jelmerAfC: I agree with that, but $tool in this case is dpkg-source, not bzr-builddeb14:12
AfCjelmer: well, obviously I think you're wrong about that, but we can move on.14:12
jelmerAfC: I'd really like to understand why you think that's wrong14:13
AfCthat doesn't seem to be the ubg14:13
AfCjelmer: if the scrollback doesn't do it, I'll send you a link to the blog when I write about it.14:13
AfCanyway, dpkg-source --commit succeeeded14:13
jelmerAfC: http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html is the background of this14:14
AfCit's bzr-builddeb that's again failing, this time with a different error. I'll see what happens with a fresh build14:14
jelmerAfC: you can also go back to the 1.0 format, for which dpkg considers this an appropriate way of building14:14
jelmerAfC: if there is only one diff file, why are you using "3.0 (quilt)" in the first place?14:15
AfCjelmer: 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 too14:17
AfC{shrug} this is the first package I hit this on, [it's gedit]14:17
AfCbut this is the first packaging I've done since Precise came out14:18
jelmerAfC: right, so if they picked 3.0 (quilt) that has an effect on the workflow you have to use14:18
AfCso I see14:18
jelmerAfC: 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
jelmerI also believe that's why the dpkg maintainers changed the default to no longer generate a diff but to error out14:21
AfCjelmer: yeah I understand14:22
AfCjelmer: seems like a regression though14:22
AfCfor the past year I've been using bzr to manage changes to packages14:22
jelmerAfC: you still can manage your existing packages with "1.0" source format14:23
AfCNow apparently I'll have to throw those branches out and go back to not using a VCS.14:23
jelmerAfC: what would you have us do for "3.0 (quilt)" ?14:23
AfCjelmer: yeah, most of our branches are of packages that are existing Debian packages, and most of them have migrated to 3.014:23
AfCjelmer: {shrug} I'd have you force in a single diff14:24
jelmerAfC: so you would want bzr-builddeb to alter the behaviour in existing tools?14:24
AfCjelmer: I'm not submitting this packages to anyone. I'm just trying to build .debs14:24
jelmerAfC: looking through dpkg-source, it seems adding "auto-commit" to debian/source/options would prevent this error14:25
AfCjelmer: 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
AfCjelmer: 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
jelmerAfC: yeah, debuild/dpkg-buildpackage/etc :)14:27
AfCso, like I said, it feels like a 5+ year regression.14:27
AfCjelmer: 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
AfCjelmer: and where you do your actual packaging work?14:28
jelmerAfC: Again, you weren't off base. "3.0 (quilt)" is incompatible with working-directory changes against upstream.14:28
jelmerAfC: I use it as an easy way to build, mostly as an alias for "debuild"14:29
jelmerAfC: occasionally to build historical revisions, and to get the orig source out of the packaging branch.14:29
jelmerAfC: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ might also be of help14:29
AfCHm. So I committed a patch with dpkg-source, but the build is still failing.14:32
AfCBack to the drawing board.14:32
jelmerAfC: how did it fail, are there any unknown files reported by 'bzr st'?14:34
AfCI haven't used Quilt since running Gentoo in about 200314:34
AfC  .pc/applied-patches14:35
AfC  debian/patches/series14:35
AfC  .pc/99-change-redo-accelerator.patch/14:35
AfC  debian/patches/99-change-redo-accelerator.patch14:35
AfCthe failure is weird, though:14:35
AfCdpkg-source: error: cannot read gedit-3.4.1.orig.vU2NEG/debian/patches/99-change-redo-accelerator.patch: No such file or directory14:36
AfCwhat a strange filename14:36
jelmerAfC: you'll need to 'bzr add' the new files in debian/patches14:38
jelmerAfC: and either add the .pc directory or undo the changes from the working tree14:39
jelmer"QUILT_PATCHES=debian/patches quilt pop -a" should do the latter for you14:39
jelmerthere might be a shorter way, but my 3.0-quilt-foo is kindof limited14:39
AfCjelmer: does bzr-builddeb do a `bzr export` under the hood, or just a copy of the current working tree [with changes]?14:40
AfCI thought the latter14:40
jelmerAfC: it does an export of the working tree14:40
AfCso I have to bzr commit the .pc stuff, *then* build?14:41
jelmerAfC: so unversioned files won't be included in the export, but modifications will be14:41
AfCoh, ok14:41
AfC[weird corner case]14:41
AfCyou said "add"14:41
jelmerAfC: yes, you'll have to add them so they're versioned14:41
jelmerAfC: but they don't have to be committed - bzr just has to know about them14:41
AfCok, so this is just charming :/14:42
AfCa) I used `dpkg-source --commit` to create a patch14:42
AfCb) I reverted the change in my working tree14:43
AfCc) added the aforementioned .patch14:43
AfC[`bzr add` that is]14:43
AfCwhich got me past the previous crash14:43
AfCand now I have a crash which is identical to that which started the whole conversation: aborting due to unexpected upstream changes14:43
AfCfreaky :)14:43
jelmerAfC: 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
AfCjelmer: it doesn't say...14:45
AfC(reading the .build file)14:45
AfCjelmer: ok14:46
AfCjelmer: so it said14:46
AfC   .pc/applied-patches14:46
AfCjelmer: was modified14:46
AfCjelmer: I reverted that file14:46
AfCand now it's building14:47
jelmerAfC: the .pc directory contains the quilt state, so which patches are applied, which unapplied, etc14:47
AfCjelmer: I couldn't believe it had an entire copy of the original [unmodified] file in there.14:48
AfCjelmer: I mean, I thought we got away from that after Subversion :)14:48
AfCtalk about primative.14:48
jelmerheh, yeah :)14:48
AfCand this is the brand new shiny Debian packaging format? Jeesh14:49
AfCjelmer: well, thank you for your help14:50
AfCjelmer: there's no way I would have navigated that by myself.14:51
AfCMajor conceptual mismatch, to be sure14:51
jelmerAfC: anytime :)14:51
AfCI'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
AfCThey were quite enthusiastic about bzr as a result of what I'd showed them about comparing different branches14:52
jelmerI 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
AfCSeeing patches in VCS diffs is not exciting in the sightest.14:52
jelmerI'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
AfCjelmer: I have no Git skills at all, which is becoming harder and harder to admit to people.14:54
AfCI can't believe I am about to commit a *patch* to a version control system.14:57
AfCNext they'll be telling me to commit binaries :/14:57
jelmerAfC: 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
AfCjelmer: 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 mess15:00
AfCwe'll see15:00
AfC[I dog fooded Git for 6 months circa 2006. Ick. Oh well :)]15:00
AfC[back to packaging]15:02
AfCWow, this is a horrid regression15:02
AfCso before when upstream released a new version and that code propegated to us via import-dsc and friends,15:02
AfCwe would get those changes into our working tree and then could resolve conflicts and carry on.15:02
AfCNow my changes are *not* in the working tree, but instead in unapplied patches.15:03
AfCGod, I hope I'm missing something obvious about all this.15:03
jelmerAfC: yep15:03
jelmerAfC: you can use quilt to try and fix up the patches afterwards15:04
AfCThis is awful15:04
AfCAre you sure we can't just take our working tree and blat it down as a single patch before building binaries?15:04
jelmerit would be really nice if we could represent patches as branches here (and just "up-merge" the new upstream release)15:04
jelmerAfC: you can, but I'm not sure if your comaintainers will appreciate that, since they changed to 3.0(quilt)15:04
AfCjelmer: {shrug}15:05
jelmerAfC: I think "echo auto-commit > debian/source/options" will do that15:05
jelmer(and bzr adding that file)15:05
AfCjelmer: 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
AfCjelmer: ok, I'll look at that15:06
AfCjelmer: I'm just reading the man page for dpkg-source now15:09
AfCjelmer: there's a useful discussion under --single-debian-patch15:09
jelmerAfC: hmm, indeed15:10
AfCjelmer: so I'm starting to get it now. I see the difference between 3.0 ({native,quilt,git,bzr})15:11
jelmerAfC: (note that 3.0 (git) and 3.0 (bzr) aren't actually used in practice)15:11
AfCjelmer: right; I need to adapt to whatever is going on in the original package I've forked from15:11
jelmerI don't think I've actually seen a package that used either "3.0 (git)" or "3.0 (bzr)"15:12
AfCjelmer: 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
AfCformat package[15:12
jelmerAfC: yeah, looks like it15:13
AfCjelmer: I will definitely write this up15:14
AfCjelmer: thanks for your help15:14
AfC[trying that experiment now, while everything is open]15:14
AfCBuild running15:17
AfCNice. So I suspended the build, and looked in ../build-area/15:18
AfCThere is indeed a new patch added to the end of debian/patches/series15:18
AfCalong with a new patch file there15:18
jelmerah, cool :)15:20
AfCRaises an interesting issue, of course15:20
AfCAre the debian/patches applied in the bzr[-builddeb] working tree, or not?15:21
AfCHuh. It seems they *are* applied.15:22
AfCjelmer: did you know that?15:23
jelmerAfC: yeah, they would have to be15:24
jelmerbzr exports the tree including the working tree changes15:24
AfC[and then dpkg-source unapplies them before building where it ... applies them? Head hurts]15:24
jelmerand 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 applied15:24
jelmerAfC: 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
AfCRemind me to use 3.0 (native) for my own work :)15:25
AfCjelmer: maybe15:25
AfCjelmer: I'm just pleased that bzr-builddeb's working tree includes the debian/patch series applied15:25
AfCjelmer: 01:30 local, time for me to pack it in. Business calls first thing tomorrow.15:27
AfCjelmer: Thanks for your patience.15:27
AfCjelmer: 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
jelmerAfC: sure, it would be great to document this better15:29
jelmerAfC: good night!15:29
hmmhhi 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
hmmhwhat am i doing wwrong?15:40
jelmerhmmh: hi15:44
jelmerhmmh: does building the package on your local machine work?15:44
hmmhyes (i have not confirmed the last recepie - will check that now, thanks) but I have no err during build and so on .... hmm15:48
hmmhyes it does build/install no problem16:04
hmmhif tested locally16:04
hmmh.....but there is no binary as well in the local install ....this is definitely a wrong recipe - any help?16:09
jelmerhmmh: have you tried the recipe locally?16:35
jelmerhmmh: this kind of issue is generally just a bug in the packaging16:35
hmmhjemler: yes i tried it locally - but i have the same result - makes and installs a pkg ..but with no binaries..16:38
hmmhjelmer: my recepie has "nest-part packaging lp:~our/+junk/ourpkg debian debian" - is this correct?16:41
jelmerhmmh: that seems right16:44
jelmerhmmh: have you tried creating just the source package and seeing if that has the right contents?16:45
hmmhjelmer: when i create regular pkgs (not for daily builds, not using the "code brunch") - there is no problem installing and creating the pkg16:46
jelmerhmmh: recipe builds only create source packages, the binaries that are created afterwards are built from those source packages and are not in any way special16:51
jelmerso 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
hmmhjelmer: 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
hmmhjelmer: could "maverick" be the issue16:58
hmmhhi, does anybody know how can i upload to my "code" from Git?19:47
lifelesswhat do you mean by your "code" ?20:08
hmmhwell ... i would like to make a bazaar branch FROM a git repo..20:11
hmmhand then build daily pkg based on a receipt20:11
hmmhi meant recipie20:12
lifelessIn Launchpad, or separately ?20:31
hmmhin launchpad20:33
hmmhI 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
lifelessyou can use an import branch to get your code into bazaar20:34
hmmhyep I saw that - so this is the only way - I have to request an official import?20:35
lifelessthat or manage it yourself20:46
lifelesse.g. use git-bzr or bzr-git and cron and so on20:47
hmmhthank you for the answer - how do i use bzr-git? ant example?20:48
jelmerhmmh: 'bzr branch git://some/git/url bzr-import', if you have bzr-git installed20:53
lifelesshmmh: most folk wanting recipe builds do it all in Launchpad20:56
lifelesshmmh: as its easier20:56
hmmhjelmer: 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
jelmerhmmh: bzr git-import imports all branches, 'bzr branch' just the current one21:25
hmmhjelmer: the current one , you mean the current revision of git?21:26
hmmhthe last commit ?21:27
jelmerhmmh: the active branch21:29
jelmerhmmh: IOW, HEAD21:30
hmmhk, thanks21:31
hmmhjelmer: after i do "'bzr branch git://some/git/url" , can i import that directly - "bzr push lp:~ourlaunchpad" ?21:34
hmmhjelmer: 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
jelmerhmmh: you can push to lp:~ourlaunchpad after you've imported, yes21:42
jelmerhmmh: a recipe can use branches owned by different users21:42
lifelesshmmh: 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 different21:43
hmmhthank you guys21:53
jelmerhmmh: have you tried downloading the source package and seeing if that is correct?21:58
hmmhjelmer: 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
jelmerhmmh: have you tried downloading the source package and seeing if that is correct?21:58
hmmhyes ... when i get the source pkg , i get the tar.gz the .dsc everything is there...22:06
jelmerhmmh: in that case the recipe is unrelated - the recipe is only used to build the source package22:50
jelmerhmmh: after that, it's just the regular build process for source packages22:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!