[00:59] <Kamping_Kaiser> can i use bzr-buildpackage with only debian/ in revision control, or do i need to have upstream source there too?
[01:04] <lifeless> it can work either way
[01:05] <Kamping_Kaiser> perfect. i'll just keep debian/ around then.
[01:05] <Kamping_Kaiser> thanks :)
[01:08] <AfC> Say I've previously I did a
[01:08] <AfC> $ bzr branch lp:ubuntu/empathy natty
[01:08] <AfC> It was "natty" at the time. Now I pull and suddenly it's "oneiric". I guess it did what I told it to, but I surely didn't get what I wanted; I thought I had a branch with natty's version in it
[01:09] <AfC> Is there a modification to the lp:ubuntu/package syntax to bind it to a specific release series?
[01:13] <mwhudson_> AfC: i think lp:ubuntu/natty/package works
[01:14]  * AfC tries `bzr missing` with that
[01:16] <AfC> Grr. Why oh why is it transferring megs and megs of data to give `missing --line` when I already have the revisions present!
[01:16] <AfC> Anyway
[01:16] <AfC> mwhudson_: yes, that works. Thanks
[01:26] <Kamping_Kaiser> related to my last question, is it possble to copy the debian/ dir between repositories keeping history? i'd like to move it from packagename/debian into shared/packagename/debian so i don't have to carry all the source too
[02:45] <AfC> If I would like `bzr builddeb` to build both a source package and a .deb binary package, what options would I do?
[02:45] <AfC> $ bzr builddeb -S -- ...
[02:45] <AfC> seems not to build the .deb
[02:45] <AfC> (ok, fine)
[02:45] <AfC> but what is the complimentary option?
[02:45] <AfC> Or should we not use `-S --` and instead be doing `-- -S -sa` or so?
[02:46] <Kamping_Kaiser> -S == source only
[02:47] <AfC> [the other problem I ran into is about 1 of 15 packages I've done lately didn't have the .orig.tar.gz available in target distro, so uploading to PPA bombed, whereas the rest of the time it all Just Worked™ leaving me quite gunshy]
[02:48] <AfC> [and thinking for good measure I should always be passing `-- sa`
[06:35] <thumper> hi bzr people
[06:35] <thumper> I have some code right now that works on working trees
[06:36] <thumper> handling things like adding or editing files
[06:36] <thumper> I want to write some other code that does the same work, but works on a branch instead
[06:36] <thumper> how do I get a tree representation of a branch that I can use like a working tree?
[06:37] <thumper> is a revision tree the way to go?
[06:50] <lifeless> yyou can use a revision tree + a transform
[06:50] <lifeless> the lp translations export code does this, if you want to cargo cult
[07:06] <thumper> hmm...
[07:06] <thumper> lifeless: ta
[07:39] <vila> maxb: about to restart the package importer, anything I should know ?
[07:44] <maxb> vila: for anything in particular?
[07:44] <vila> maxb: well, no, that's the trick :) Anything that crosses your mind !
[07:45] <maxb> I was wondering if I need to fix my change to the path to lp_creds.txt first
[07:45] <vila> maxb: p-i stopped
[07:45] <vila> maxb: argh, landed ?
[07:45] <maxb> yes
[07:45] <vila> maxb: wait, no need, your change is ok for jubany right ?
[07:45] <vila> so you can do that later
[07:46] <maxb> I thought it was ok, but now I think I may have miscalculated the number of dirname calls
[07:48] <vila> maxb: depends on local setups if I read it correctly it works for udd/branch but not for udd/bugs/branch and anyway you can't have both
[07:48] <vila> maxb: the real solution is to have it in pkgimport.conf anyway
[07:49] <maxb> I am somewhat unconvinced about pkgimport.conf, unless it supports relative paths
[07:49] <vila> maxb: waiting for GSA to update the script and then start the pi again
[07:49] <vila> maxb: relative to what ?
[07:49] <vila> to the file itself ?
[07:50] <maxb> Possibly
[07:50] <vila> wow, 'somewhat' 'possible', you make it hard to satisfy :)
[07:50] <maxb> Anyway, I think jubany is now going to be looking for lp_creds.txt in the wrong place - /srv/package-import.canonical.com/new/scripts/ rather than /srv/package-import.canonical.com/new/ :-/
[07:50] <vila> what's wrong with conf file ?
[07:51] <vila> maxb: are you sure about that ? losa is ready to start it again, should I hold him ?
[07:53] <maxb> Yes, sure :-(  Probably best to just put in a symlink for now, to not block on admin actions
[07:53] <maxb> i.e. cd /srv/package-import.canonical.com/new/scripts/ && ln -s ../lp_creds.txt
[07:53] <vila> maxb: confirmed
[07:54] <vila> maxb: done
[07:56] <vila> maxb: re-started
[08:00] <maxb> thanks
[08:01] <maxb> can you requeue --all-of-type bzr ?
[08:01] <vila> maxb: and stopped
[08:01] <maxb> oh
[08:01] <vila> maxb: and started again
[08:01] <maxb> ?
[08:02] <vila> mass-import is bogus for 'restart' it doesn't delete STOPFILE, I'll file a bug and fix
[08:02] <maxb> oh, heh
[08:02] <vila> maxb: requeue done
[08:02] <maxb> I have also filed a MP to minimally undo my path thinko
[08:05] <vila> maxb: cool, could you mention that we need to delete the symlink when this lands ?
[08:07] <maxb> s/need to/can/, but yes
[08:08]  * vila nods
[08:08] <vila> maxb: just making sure someone don't run into it and spend time wondering why it's there
[08:09] <maxb> Hmm, there are a bunch of spurious failures - I suggest requeue_package.py --auto linux-restricted-modules haskell-utf8-string language-pack-kn language-pack-sq-base
[08:10] <vila> maxb: old spurious or new spurious ?
[08:11] <vila> maxb: wow, nice to the failure split !
[08:13] <vila> maxb: requeue done
[08:14] <vila> rhaaa lovely... finally I can type just 'categorise_failures.py'
[08:15] <maxb> oh?
[08:15] <vila> yeah, fixit.sh set the right env vars....
[08:16] <maxb> So, 465 failures... now we just wait to see how many of the currently retrying ones succeed :-)
[08:17] <vila> maxb: should we proceed with bug #795703 then ?  :D
[08:21] <maxb> Yes - shall I sort the instructions for the new fixit syntax now?
[08:22] <vila> maxb: as you will, I'm doing it right now, we can compare notes (I don't mind a double-check there ;)
[08:22] <vila> s/will/wish/
[08:22] <vila> s/as you wish/yes, please do/
[08:22] <vila> or something ;)
[08:26] <vila> hmm, right, UI mistake, the package should come first, that's what we are acting upon (a GUI could display the relevant packaging branches or even tags, allow selection then action)
[08:26] <vila> we'll see to it later
[08:28] <maxb> done, posted to the bug.
[08:28] <maxb> And I wish launchpad could be asked not to line-wrap for displa
[08:28] <maxb> y
[08:28] <maxb> it all comes out right in copy/paste, though
[08:28] <vila> at least copy/pastin works...
[08:28] <vila> hehe
[08:29] <maxb> awesome, the failure count is going to settle at at most 469 already
[08:30] <maxb> which is a nice step down from the 485 we were at when all this LP mess started
[08:32] <vila> maxb: yeah, well done
[08:36] <vila> maxb: http://paste.ubuntu.com/630689/ ok ?
[08:38] <maxb> ah, oops. yes
[08:42] <vila> no problem, I had one too :) double checks are good :)
[08:44] <vila> maxb: procedding
[08:45] <vila> a bit slow
[08:45] <vila> of course establishing ssh connection for each command doesn't help
[08:46] <maxb> Right, so that's A through E.
[08:47] <maxb> I should have a look at the rest of the alphabet :-)
[08:47] <vila> owww
[08:47] <vila> done
[08:48] <vila> maxb: and report posted on comment
[08:49] <maxb> Hmm, I need to revisit bug 494481 one of these days
[08:50] <vila> maxb: pfew, that took long overall (sorry for that) but I think it's a nice step in the right direction
[08:52] <vila> maxb: feel free to update the topic ;)
[08:53] <maxb> I'll be waiting on that to check that they *actually* succeed :-)[5~
[08:54] <vila> shouldnt' be long now, 0 outstanding jobs
[09:02] <vila> jam, Riddel: jelmer being sick, spiv offline, poolie sleeping, sprint next week, should we drop the standup ?
[09:03] <jam> vila: I'm fine either way
[09:04] <Riddell> I don't mind
[09:04] <maxb> Hmm, it's looking quite achievable to drive the Ubuntu main UDD failure count below 100 in the next fortnight
[09:04] <Riddell> was going to try and convince people to review my gpg stuff
[09:07] <Riddell> do we know what we're doing at the sprint next week?
[09:13] <vila> maxb: what about bug #796751, should it be marked invalid ?
[09:14] <vila> \o/
[09:14] <maxb> Yes, I think it should
[09:16] <maxb> done
[09:17] <vila> hehe, done too :)
[09:25] <vila> maxb: boom http://webnumbr.com/ubuntu-package-import-failures.from%282011-06-16%29 :)
[09:27] <vila> maxb: setting bug #795703 on the assumption that you'll post more there
[09:27] <vila> maxb: setting it 'im progress' that is...
[09:32] <maxb> hah, nice graph
[09:32] <maxb> vila: I've landed the lp_creds.txt path change, if you want to deploy and then remove the symlink
[09:33] <vila> maxb: done, waiting a bit to delete the symlink (just because)
[09:36] <vila> maxb: ha right, just got your mails about the symlink, good, we're on the same page
[09:57] <Kamping_Kaiser> is there a way to make bzr only show files below `pwd` that have been modified? (like svn would). i keep trying to copy+paste the paths it tells me are modified and realsing i'm not in the repo root
[10:00] <vila> Kamping_Kaiser: not that I know of but I'm pretty sure there is a bug about that
[10:02] <Kamping_Kaiser> vila: i'll have a look on lP, cheer
[10:02] <Kamping_Kaiser> s
[10:43] <Kamping_Kaiser> can i do something in bzr if i want to redirect http attempts to access foo/packages/ so its foo/packges-version instead? would i have to do it using the webservers rewriting, or can i use bzr somehow?
[12:17] <a7ndrew> There's an incomplete sentence at http://doc.bazaar.canonical.com/latest/en/mini-tutorial/#starting-a-new-project where would be the best place to report that?
[12:27] <Riddell> a7ndrew: bugs.launchpad.net/bzr  or if you can work out how to fix it we can just commit the fix
[12:28] <Riddell> well I know how to fix it, just need to think about what text
[12:50] <a7ndrew> I'm not quite sure what the author meant to say to finish off that sentence.
[12:57] <Riddell> a7ndrew: well report a bug and we'll get to it
[14:48] <johnf> How would it be possible for me to have a shared respository which also seems to have revisions in it? i.e. it has shared sub branches but if I run bzr log I also have revisions
[14:48] <johnf> This repo was originally created in 2006 so it is quite old
[14:53] <briandealwis> johnf: you can have a branch coexist with a repository.  In fact a standalone branch is exactly that
[14:53] <briandealwis> I remember being puzzled by this too
[16:24] <poolie> hi all
[16:24] <poolie> johnf, i think we now warn if you try to create that but it may have been possible in the past
[16:25] <poolie> or, obviously, yo ucould just move the branch directory
[16:28] <Riddell> good $timeOfDay poolie
[16:28] <Riddell> poolie: I don't notice any warning if i run init-repo then init
[17:04] <poolie> hello there
[17:04] <poolie> hm
[17:31]  * maxb marves at bug 800771
[17:31] <maxb> *marvels
[17:53] <fullermd> Impressive.
[17:54] <ScottK> Nice.
[18:24] <pommeverte> hello
[18:28] <pommeverte> I have a question (that may sound a little stupid). But I have a project that is going to be setup for a few clients. Each client will have specific (personal) code implementations. I was thinking of branching my project for each client but then how would I go about correcting, say.. a bug accross all branches?
[18:28] <pommeverte> or am I not going the right way with this?
[18:29] <pommeverte> I'm kind of looking for a way to make patches
[18:31] <pommeverte> is there maybe a way to shelve changes and then share them with another diverging branch? Or is there maybe a way of merging a single commit and dealing with conflicts?
[18:32] <pommeverte> Any help would be appreciated I couldn't seem to find anything about this in the documentation
[18:32] <jelmer> pommeverte: do you mean like "bzr merge -c" ?
[18:34] <pommeverte> hmmm what does the -c do?
[18:34] <pommeverte> (looking through man)
[18:35] <jelmer> merges just the changes in one particular revision
[18:40] <pommeverte> hmm well yes that sounds exactly like it. Completely overlooked it since I checked the (outdated) man online
[18:40] <pommeverte> thanks
[18:40] <pommeverte> do you think this is the best way of going about it?
[18:43] <jelmer> I think so
[18:44] <pommeverte> ok perfect. Thank you very much
[20:25] <poolie> hi jelmer
[20:25] <jelmer> hi poolie
[20:44] <poolie> how's your week?
[20:48] <jelmer> apart from the sick day, pretty good
[20:50] <jelmer> I did some more Launchpad work this week, and had a look at adding support for multiple upstream tarballs in the package importer.
[20:50] <poolie> oh, right
[20:50] <poolie> i hope you're feeling better
[20:50] <jelmer> I am, thanks :)
[22:19] <etenil> Hey there
[22:21] <maxb> Hello
[22:21] <etenil> I've made a small bzr repo on my server. My workflow is to create branches for each feature I work on and then merge them into trunk and delete the now useless branch. I've discovered I can easily push new branches up to my small server, but I haven't found yet how to delete them.
[22:22] <etenil> Could you give me a hand?
[22:23] <maxb> There is not a command within bzr itself for deleting branches. People usually just rm -rf them
[22:23] <etenil> ah
[22:23] <etenil> :/
[22:24] <etenil> the thing is, I'm not working alone, and I'm restricting the ssh access of the other devs to running bzr
[22:24] <etenil> is there really no way to accomplish this but rm -rf?
[22:25] <maxb> bzrtools provides "bzr zap --branch" - i've never used it though, so I don't know if it works remotely
[22:26] <etenil> well that's a start anyway. I'll give it a try
[22:26] <etenil> thanks maxb
[22:27] <etenil> mmh
[22:27] <etenil> that doesn't seem like the right thing.
[22:27] <etenil> I guess I'm good for posting a feature request :)
[22:59] <__yhvh__> hey I built in a recently downloaded repo, did make clean and make distclean, bzr status shows loads of files changed
[23:00] <__yhvh__> I also rm'ed the whole thing and d/led again fresh but the modified still show up,
[23:00] <__yhvh__> is this info stored outside the repo dir?