[00:09] <poolie> igc, does explorer have any launchpad-api client code yet?
[00:26] <poolie> spiv, can you triage bug 526132 if you know about it
[00:47] <spiv> poolie: sure, doing now
[00:48] <_TiN_> spiv: there work with https+urllib, thanks
[00:49] <_TiN_> /s/there/it
[00:56] <spiv> _TiN_: you're welcome
[00:57] <_TiN_> spiv: where is the rst of http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/http_smart_server.html I can send a patch, to explain how to really make it work
[01:12] <spiv> _TiN_: doc/en/user-guide/http_smart_server.txt in the bzr source tree
[01:12] <spiv> Hmm, we really should have a small footer on every doc page saying which file to make patches against.
[01:14] <spiv> _TiN_: thanks!
[01:14] <_TiN_> yw :-)
[01:15] <lifeless> jelmer: ping
[01:15] <jelmer> lifeless, pongish
[01:15] <lifeless> jelmer: I haven't read the code yet, but wanted to discuss named branch opening
[01:15] <lifeless> what does your patch change?
[01:16] <jelmer> lifeless: it basically adds a name argument to BzrDir.open_branch(), BzrDir.destroy_branch() and BzrDir.create_branch()
[01:16] <jelmer> then checks that they raise NoColocatedBranchSupport if a name is actually specified
[01:16] <lifeless> ok; does it set limits (e.g. is a name 'foo/bar' supported (I'd like that :>)
[01:17] <lifeless> for Branch.open, thats where the url support will come in ?
[01:17] <lifeless> have you done the url parameter support yet ?
[01:17] <jelmer> The URL parameter support isn't done yet, that's up next
[01:17] <lifeless> ok this is sounding nice
[01:17] <lifeless> I'll try and review this weekend
[01:18] <jelmer> thanks :-)
[01:34] <Kilroo> If I had a commit at revision x that did nothing but add a 1.5gb zipped .mov file to the repository and I wanted to get rid of it, would the best way to do so be branching from revision x-1 and them merging from x+1 to the present or what?
[01:34] <Kilroo> I'm curious because of what my boss did to one of our subversion repos and how much the linux sysadmin is dragging his feet over fixing it.
[01:36] <maxb> If the aim is to remove the huge file from the history completely, merge would not acheive your goal
[01:37] <maxb> You'd want rebase, I guess, though bzr's rebase plugin has some problems that I happen to be working on fixing
[01:38] <Kilroo> Hm. Ok.
[01:39] <Kilroo> The aim would be to fix it so that people trying to branch from it would actually be able to do so without getting an out-of-memory error, which I guess means I would want rebase.
[01:49] <dOxxx> good evening
[01:50] <meoblast001> good evening to you dOxxx
[02:45] <poolie> i wonder if we should have a news file per x.y series
[02:45] <poolie> merging them into just one is a bit weird
[02:45] <poolie> though getting to grep just one is useflu
[03:04] <mwhudson> jelmer: incremental import failure :( https://code.staging.launchpad.net/~kiko/linux/2.6.31
[03:28] <meoblast001> i was thinking
[03:28] <meoblast001> then i had a panic attack
[03:29] <meoblast001> when you do `bzr uncommit`, does it keep a record of the commit?
[03:29] <dOxxx> yes
[03:29] <meoblast001> oh jeez
[03:29] <meoblast001> forever?
[03:29] <dOxxx> the modifications get added back into your working tree
[03:29] <dOxxx> and the message is remembered for when you next run bzr commit
[03:30] <dOxxx> i.e. it looks like you hadn't run bzr commit
[03:30] <meoblast001> i've uncommitted things and then recommitted them more than a few times
[03:30] <meoblast001> once i recommit, are they removed?
[03:30] <dOxxx> I'm not sure what you mean...
[03:30] <meoblast001> i do uncommit
[03:30] <meoblast001> then do bzr commit
[03:30] <meoblast001> i've done that quite a few times
[03:31] <dOxxx> that's fine
[03:31] <meoblast001> every commit i've uncommitted, are those completely removed once i commit?
[03:32] <dOxxx> I'm not 100% certain, but I believe that revision will no longer exist in the branch. Essentially it's replaced by the new revision you create with the second commit.
[03:32] <meoblast001> ok
[03:32] <meoblast001> hopefully you're right
[03:32] <dOxxx> :)
[03:32] <meoblast001> or i'll have another panic attack
[03:32] <dOxxx> I'm not a core developer, just a part time contributor, so you may want to verify by posting to https://answers.launchpad.net/bzr or on the mailing list.
[03:33] <meoblast001> ok, thanks
[03:33] <jml> is there a command to mirror a repo?
[03:33] <dOxxx> scp?
[03:33] <dOxxx> ;)
[03:33] <jml> download all branches in a repo -- pulling ones we already have, branching new ones?
[03:34] <dOxxx> I think the bzr mirror plugin does that
[03:34] <dOxxx> https://launchpad.net/bzr-mirror
[03:35] <jml> dOxxx, thanks -- it's not mentioned on the BzrPlugins page on the wiki
[03:35] <dOxxx> np
[03:36] <meoblast001> hm, it says "Uncommit leaves the working tree ready for a new commit.  The only change   it may make is to restore any pending merges that were present before   the commit."
[03:36] <meoblast001> i'm not sure what that means though
[03:37] <dOxxx_away> it means that if you were to then run bzr commit again, it would appear as if you had never run bzr uncommit
[03:38] <dOxxx_away> seeya later
[03:39] <jml> no, that doesn't do what I want.
[03:42] <mwhudson> jml: i think something like rsync might be your best bet
[03:42] <mwhudson> i guess you could do something involving all_revision_ids and fetch, but it seems like it's going to be a bit expensive, one way or the other
[03:44] <jml> mwhudson, well, I was thinking something a little like Repository.open(...).find_branches
[03:45] <jml> mwhudson, then doing some set operations
[03:45] <mwhudson> jml: that won't find "dead heads" i.e. revisions in the repo that are not in the ancestry of any branch in the repo
[03:45] <mwhudson> jml: i guess looking at the code for bzrtools 'heads' command will probably be instructive
[03:47] <jml> mwhudson, I don't think we care about that
[03:48] <mwhudson> jml: on in that case, what you said sounds fine
[03:51]  * poolie is merging 2.1 back to trunk
[03:51] <poolie> overrideAttr is a big win
[03:51] <poolie> causes a lot of conflicts though
[04:02] <_TiN_> spiv: i have the doc patch, now?
[05:19] <spiv> _TiN_: I don't understand your question.  Are you asking where to send a patch?
[06:36] <lifeless> mwhudson: can you recommend a small git repo to do bzr git tests with? I know you're finished...
[06:40] <wgrant> lifeless: linux!
[06:41] <lifeless> wgrant: FSVO small
[06:41]  * wgrant has used http://git.samba.org/?p=jelmer/dulwich.git
[06:44] <lifeless> jelmer: hi
[06:44] <lifeless> jelmer: why does bzr-git register a network format? do you do native network streaming ?
[06:45] <jelmer> lifeless, moin
[06:45] <jelmer> lifeless, we don't, but things broke when we didn't
[06:45] <jelmer> I don't remember the details
[06:45] <lifeless> jelmer: oh. did you file a bug?
[06:45] <jelmer> no, I don't recall thinking that this was one
[06:46] <lifeless> yeah, it wasn't meant to be an API break
[06:46] <lifeless> it was meant to add an optimised path to determine the control dir format over the smart server
[06:47] <jelmer> mwhudson, hi
[06:47] <wgrant> Is update-sourcecode broken for anyone else?
[06:47] <wgrant> It can't find bzrlib.branch.
[06:48] <lifeless> wgrant: #launchpad-dev ? :>
[06:48] <lifeless> thats (I don't know)
[06:48] <wgrant> lifeless: Oops, thought I was there. Sorry.
[06:55] <lifeless> wgrant: nothing to be sorry about
[07:27] <vila> hi all
[07:29] <jelmer> moin vila
[07:29] <poolie> hello vila, jelmer
[07:29] <vila> hi jelemer, poolie
[07:30] <vila> jelmer, in bug #525752, I realized you were referring tips, I asked for revids in case nobody can look at it before the tips change :D
[07:31] <poolie> a traceback might help there too
[07:31] <jelmer> vila: ah, k
[07:31] <jelmer> I'll add them
[07:31] <poolie> vila, i'm at the moment merging 2.1 and 2.0 back to trunk
[07:31] <poolie> there are quite a few real conflicts
[07:31] <poolie> i mention this just to save you trying to resolve them too
[07:32] <vila> poolie: I saw you mentioned conflicts related to overrideAttr, I'm  a bit surprised... are there a lot ? hard to resolve ?
[07:32] <vila> poolie: thks for that
[07:32] <poolie> quite a few
[07:33] <poolie> at first i thought it was a merge bug but i think people really have done different cleanups on the two
[07:33] <poolie> branches since we last merged
[07:33] <vila> hmm, bad, I thought we were merging back to trunk regularly enough....
[07:37] <poolie> hm
[07:37] <poolie> actually no, i think the criss-cross is being handled poorly
[07:37] <vila> poolie: try remerge --weave maybe ?
[07:42] <poolie> --lca did much better
[07:42] <poolie> maybe we should look at changing some defaults here
[07:42] <poolie> it's been discussed before
[07:42] <bob2> best. flag. ever.
[07:42] <poolie> heh
[07:46] <vila> bob2: you know it means Least Common Ancestor right ?
[07:47] <bob2> no!
[07:47] <bob2> I mean yes!
[07:48] <poolie> vila, do you know off hand how fsencoding is originally set?
[07:49] <vila> defaultfilesysencding or default to utf8 from memory
[07:49] <vila> sys.default...()
[07:49] <poolie> but i mean how would a user change it?
[07:49] <vila> in osutils search for fs_enc ?
[07:49] <vila> no no no, no user is allowed to do that :D
[07:49] <vila> seriously, I don't think we have a hook for that
[07:50] <vila> _fs_enc = sys.getfilesystemencoding() or 'utf-8'
[07:51] <vila> so, set at load time
[07:52] <vila> poolie: what use case do you have in mind ?
[07:53] <vila> lifeless: by the way, still no T-shirt here, any news from your side ?
[07:58] <poolie> vila, things like bug 526263
[07:58] <poolie> it would be nice to say "you need to set X"
[07:58] <poolie> perhaps hacking site.py will do it
[08:00] <vila> fsenc: 'ANSI_X3.4-1968' is another name for ascii, we use utf8 in that case
[08:00] <poolie> i know
[08:00] <vila> .. and your comment is exactly what I would have said
[08:00] <poolie> i mean i know it's ascii
[08:00] <poolie> but it looks like we're not using utf8
[08:00] <vila> yeah, sorry, your comment wasn't in the first page
[08:02] <vila> weird, if I read osutils._walkdirs_utf8 correctly, we use UTF8DirReader in that case or emit a warning about extensions failing to load
[08:03] <vila> grr, we really need to display unicode exceptions correctly, the exception objects have the string as an attribute... why python doesn't display it is... censored
[08:06] <vila> poolie: tweaking LC_TYPE and LANG sould be the way to go
[08:09] <poolie> could you suggest that too him then?
[08:10] <poolie> we should show them better
[08:12] <lifeless> vila: nope
[08:12] <lifeless> jml: did the t-shirt get returned to you/
[08:13] <poolie> nearly <100 New bugs
[08:14] <lifeless> poolie: bug 523703
[08:14] <lifeless> poolie: I think your retitling is wrong
[08:14] <lifeless> poolie: both jam and I think its deeper than revnos
[08:14] <poolie> ok, retitle away then
[08:15] <poolie> good night
[08:16] <lifeless> gnight
[08:16] <vila> gnight
[08:42] <Anteru> Hi
[08:43] <Anteru> Just installed bzr 2.1 final, and I'm getting an empty toolbar in bazaar explorer ... known issue or am I doing something wrong? (This is on Windows)
[08:49] <naoki_> Anteru: It is known issue.
[08:50] <Anteru> Any workaround
[08:50] <Anteru> ?
[08:50] <naoki_> https://launchpad.net/bzr-explorer/+download
[08:50] <Anteru> thanks
[08:51] <naoki_> Please try 1.0.0rc2
[09:07] <Anteru> works, thanks
[09:13] <wgrant> I'm merging a branch into trunk. A file in the branch collided with an unversioned file in my checkout of trunk. bzr said "Moved existing file <filename> to <filename>.moved."
[09:13] <wgrant> But it seems the one from the branch is .moved, not the one that existed in the trunk checkout.
[09:15] <wgrant> Oh, no, ignore me, I'm just crazy.
[09:52] <eelik> question about bzr-svn documentation in http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html
[09:53] <eelik> "Merging trunk to your feature branch" says: merging trunk into your feature branch should be avoided
[09:54] <eelik> but then it shows how trunk is merged to feature branch and feature branch back to trunk
[09:54] <eelik> "Instead, use merge to reintegrate your changes back to the mainline."
[09:55] <eelik> It seems to be conflicting with itself because it first tells NOT to merge to feature branch, but then shows how it can be done safely
[09:57] <eelik> The "Instead" part talks about merging to trunk vs. pushing/pulling to trunk, not merging to trunk vs. merging to feature branch
[09:58] <eelik> The question is: should merging trunk into feature branch be avoided or not?
[10:00] <bigjools> it's done routinely in Launchpad development
[10:01] <eelik> So, the first clause in the doc is misleading?
[10:01] <bigjools> oh, this is subversion
[10:01] <bigjools> all bets are off :)
[10:02] <bigjools> jelmer will be around later, he'll know
[10:46]  * bialix waves
[14:24] <gnomefreak> i keep getting errors about connection when pulling a branch? is this known?
[14:29] <rubbs> gnomefreak: can you post the error?
[14:29] <gnomefreak> http://paste.ubuntu.com/382281/ rubbs i was just pastebinning it :
[14:30] <maxb> "Permission denied (publickey)." indicates you are failing to authenticate to Launchpad
[14:31] <maxb> Check that:
[14:31] <gnomefreak> maxb: the key or in all
[14:31] <maxb> 1. You've run bzr launchpad-login <your lp user id>
[14:31] <maxb> 2. Your Launchpad user has a ssh key associated
[14:31] <maxb> 3. You actually have that ssh key available locally
[14:32] <gnomefreak> i do or at least i did
[14:32] <maxb> Run 'ssh your-lp-user-id@bazaar.launchpad.net'. It should print "No shells on this server"
[14:33] <gnomefreak> ok trying
[14:34] <gnomefreak> Permission denied (publickey).
[14:35] <maxb> So the problem is at the ssh level, before bzr ever actually gets to do anything
[14:36] <gnomefreak> maxb: i tried renaming ~/.ssh and tried again i get same error
[14:38] <maxb> Do you use a ssh-agent? Does it know about your key?
[14:39] <gnomefreak> i thought i was
[14:39] <jpds> gnomefreak: Try: ssh-add -l
[14:40] <gnomefreak> ok i forgot to install it after re installing it seems
[14:40] <gnomefreak> no identities
[14:43] <gnomefreak> ok trying a few things. ill let you know what happens
[14:44] <jam> eelik: what should be avoided is merging trunk => feature and the *pushing* => trunk
[14:44] <jam> merging trunk => feature and merging feature => trunk is probably be fine
[14:45] <james_w> hi jam
[14:45] <jam> morning james_w
[14:45] <james_w> your possible_transports fix, or something else, fixed the fd leak issue, so thanks!
[14:45] <jam> james_w: probably the possible_transports
[14:46] <jam> given that it was opening up 2 sockets for every file
[14:46] <jam> it wanted to download
[14:46] <jam> (one to lp.net, one to lplib.net)
[14:46] <jam> james_w: can you start a totem import?
[14:47] <james_w> have you started on another failure class, or have you switched to some other task
[14:47] <jam> or... have me understand why we don't have one
[14:47] <james_w> jam: you can do it!
[14:47] <jam> currently working on windows installer
[14:47] <james_w> http://package-import.ubuntu.com/status/totem.html
[14:48] <james_w> which I'm tempted to just retry
[14:48] <jam> check hottest says "lp:ubuntu/totem" has no default branch
[14:48] <james_w> "locked 0 seconds ago" would indicate it trying to double lock
[14:48] <jam> is it possible we have a broken object somewhere?
[14:48] <jam> but yes, 0s definitely indicates a double lock
[14:49] <jam> anyway, when i get back to this it will probably be either bug #508254 or bug #513282
[14:49] <jam> they both are tied with 3 failures
[14:49] <jam> though apparently 508254 is already fixed?
[14:50] <james_w> yeah
[14:50] <james_w> it's imported both samba and OO.org, which were both hit by it
[14:51] <bialix> .ьу цфмуы фе офь
[14:51] <bialix> >	/me waves at jam
[14:52] <jam> hi bialix
[14:52] <james_w> jam: you realise the lists in the bugs aren't exhaustive?
[14:52] <james_w> when you said "both tied with 3 failures"
[14:53] <jam> bialix: was that just a typo? I tried to translate it from russian, and I get:
[14:53] <jam> http://translate.google.com/#ru|en|%0A%D1%8C%D1%83%20%D1%86%D1%84%D0%BC%D1%83%D1%8B%20%D1%84%D0%B5%20%D0%BE%D1%84%D1%8C
[14:53] <jam> james_w: hottest100 has 3 packages affected with the first, and 3 affected with the second
[14:53] <jam> the 2 highest impact bugs
[14:53] <james_w> ah, I see
[14:54] <bialix> jam: no, it was english in russian layout
[14:54] <jam> bialix: yeah, I did that a lot with dvorak / qwerty
[14:54] <james_w> jam: does it put the output somewhere, or would I have to run it locally?
[14:54] <jam> james_w: we cache the last run in 'status'
[14:55] <jam> I just ran it, but I'm going to remove 508254 and run it again
[14:55] <jam> http://paste.ubuntu.com/382294/
[14:55] <jam> summary of delta for last run
[14:56] <james_w> jam: could you paste me all the info? I'd like to take a look
[14:56] <jam> james_w: http://paste.ubuntu.com/382295/
[14:56] <jam> the full status file
[14:56] <jam> found at
[14:56] <jam> lp:~canonical-bazaar/udd/hottest100 filename status
[14:57] <jam> bzr cat lp:~canonical-bazaar/udd/hottest100/status
[14:57] <james_w> thanks
[14:57] <jam> should give the value for whoever ran it last and committed it
[14:57] <jam> I'll be updating it again now
[14:57] <jam> though it takes a while to run from here
[14:57] <jam> lots of lp api round trips
[15:02] <jml> lifeless, it did
[15:08] <GaryvdM> Hi all
[15:08]  * GaryvdM seeks johnf
[15:20] <jelmer> GaryvdM, he's in Australia, I doubt he's around at the moment
[15:20] <jelmer> also, hi :-)
[15:21] <GaryvdM> Hi jelmer
[15:22] <james_w> jam: https://code.edge.launchpad.net/~james-w/udd/hottest100-updates/+merge/19975 is some updates with fresher information
[15:22] <GaryvdM> His package in the bzr ppa for bzr 2.1.0 final has a smaller version than tho 2.1.0rc2 package in the beta ppa
[15:23] <jelmer> it's not named 2.1.0~rc2 ?
[15:27] <GaryvdM> I made the rc2  2.1.0~rc2-0~bazaar2~karmic1  (which probably should have been  	 2.1.0~rc2-0~bazaar2~karmic1
[15:27] <GaryvdM> which probably should have been  	 2.1.0-0~rc2-0~bazaar2~karmic1
[15:28] <GaryvdM> His final is  bzr - 2.1.0~bazaar1.9.10
[15:30] <gnomefreak> maxb: using an old ~/.ssh seems to work. thanks for the help
[15:31] <jam> james_w: merging now and re-running
[15:31] <james_w> thanks jam
[15:31] <james_w> I didn't check if it didn't bother running the test for a package with a bug, so nothing may change
[15:42] <jam> james_w: http://pastebin.ubuntu.com/382314/
[15:43] <jam> it skips if it thinks there is a bug
[15:43] <james_w> ok
[15:43] <james_w> and things like "kde" will make it skip checking the package branch?
[15:43] <jam> I think so
[15:43] <jam> it sums to 100
[15:43] <james_w> because AIUI that's not something that will have a bearing on the package branch
[15:45] <jam> sure, I'll update the script a bit
[15:46] <jam> james_w: maybe you can help me understand the 'special' tag as well
[15:46] <jam> stuff like 'hplib' and 'initramfs-tools'
[15:46] <james_w> that's something to do with whether there should be an upstream import
[15:46] <jam> AIUI they have strange upstreams
[15:47] <james_w> I think hplip might have no public VCS
[15:47] <jam> yeah, so that shouldn't disqualify packaing, right?
[15:47] <james_w> I don't know why initramfs-tools is in that category
[15:47] <james_w> correct
[15:47] <jam> I think some of it was just for us to focus on getting the whole stack working
[15:47] <james_w> I think only package-bug shoud
[15:47] <jam> and if we couldn't import an upstream
[15:47] <james_w> right
[15:47] <jam> then we just skipped that one for now
[15:47] <jam> but for the summary, it has been useful to know about packaging separately
[15:47] <jam> so I'll work on that
[15:51] <james_w> thanks
[15:52] <james_w> I just saw at one point "there is a lower number of ok package branches, so that seems to be the area of most concern", and if the number of ok package branches can't exceed the number of ok upstream branches that would seem to be a bad way to asses it
[15:52] <jam> actually, the upstream check is done after the packaging check
[15:52] <jam> only explicitly excluded ones fell differently
[15:56] <james_w> ok
[15:59] <cr3> if I run bzr builddeb -S in pexpect.run(), it seems to stall forever. any ideas what might be going on? attaching to the process using gdb only shows that the process is waiting
[15:59] <james_w> debuild may be prompting you for something
[16:00] <james_w> perhaps passphrase to sign?
[16:00] <james_w> or one of it's "you appear to be doing this, we think you mean that, do you want to continue with this?" prompts
[16:01] <jam> james_w: current totals, trying to only filter out upstream based on special flags: http://paste.ubuntu.com/382330/
[16:01] <jam> 76 ok, 8 missing packages, 4 out of date, a small handful of bugs
[16:01] <jam> james_w: should I include "old_version" rather than missing package?
[16:02] <cr3> james_w: I get a prompt for "This package has a Debian revision number but there does not seem to be...", so pexpect seems to prompt properly.
[16:02] <jam> though some old-versions became 'ok'
[16:02] <james_w> jam: what are there meanings?
[16:02] <jam> (grub became ok, glibc became no_source_package)
[16:02] <james_w> their
[16:02] <jam> old-version was supposed to be stuff like firefox which moves to a new project each release
[16:02] <cr3> james_w: by the way, calling debuild --no-tgz-check -S in pexpect.run works just fine
[16:02] <jam> (mozilla-thunderbird vs thunderbird, etc)
[16:03] <jam> glibc vs eglibc
[16:03] <james_w> cr3: well, builddeb doesn't pass --no-tgz-check
[16:03] <jam> I think 'linux-restricted-modules' also moved around somehow
[16:03] <james_w> I'm not sure
[16:04] <james_w> what's "broken"?
[16:04]  * james_w remembers the README
[16:04] <cr3> james_w: yeah, I'm not sure how big a deal that really is
[16:04] <jam> james_w: if we get an exception trying to read the bzr branch that isn't 'no default branch' it is 'broken'
[16:04] <james_w> ah
[16:05] <jam> openoffice.org seems to be saying it is at revision 'null:'
[16:05] <james_w> yeah, it's having trouble pushing it to LP
[16:05] <james_w> I just had it start to try again
[16:06] <jam> so what do you think, should we just not worry about packaging for 'old-version'?
[16:06] <jam> special also seems to be a mixed bag
[16:07] <jam> but again, some specials end up 'ok'
[16:07] <james_w> we should have packaging for special
[16:07] <james_w> old-version we should have packaging, but it may not have a lucid branch
[16:07] <jam> right
[16:07] <jam> linux-restricted-modules seems the only broken special
[16:08] <james_w> broken how?
[16:08] <james_w> as it "broken"?
[16:08] <jam> no, "no_source_package"
[16:09] <james_w> ah, it's old_version really I guess
[16:10] <james_w> I don't remember where that stuff lives now
[16:11] <jam> sure
[16:12] <jam> well, I think it is 'special' in that there is no clear upstream
[16:12] <jam> but 'old-version' in that it isn't packaged their either
[16:12] <jam> I'll poke
[16:12] <jam> see what I get
[16:13] <jam> I'll probably just make old-version be a package import flag
[16:13] <jam> and 'special' be an upstream flag
[16:21] <Ng> is there a way to have bzr use non-zero return codes on errors?
[16:22] <jelmer> ng: it should do so already
[16:22] <jelmer> if not, that's a bug
[16:22] <Ng> jelmer: I'm prepared to believe it's a config or plugin issue on my end, but.. http://paste.ubuntu.com/382346/
[16:26] <jelmer> Ng: hmm
[16:26] <jelmer> Ng: Not sure what's happening there - please file a bug
[16:26] <jelmer> I think we should be returning 1 in that case
[16:26] <awilkins> I'm getting 3  : http://pastebin.ubuntu.com/382352/
[16:27] <awilkins> That's for a root-owned folder with no read permissions for ag though ; don't know what config Ng has
[16:30] <Ng> my /etc/.bzr is root:root 700
[16:35] <Ng> jelmer: done, bug #526551 :)
[16:35] <jelmer> Ng: thanks
[16:35] <Ng> I stuck in some obviously relevant things about which plugins I have where
[16:42] <GaryvdM> jelmer: I'm trying to merge the bzr ppa package branches with debian unstable. Are there any tools to help resolve conflicts in debian/changelog?
[16:49] <jam> Ng: generally we would file the bug against bzr itself, rather than 'bzr (Ubuntu)'
[16:50] <jam> we return 3 on otherwise unhandled exceptions, I don't know why you would be getting 0
[16:50] <GaryvdM> jelmer: since it is just a ppa, can I replace the entries from the ppa with the entries from debian?
[16:51] <Christoph^> Hi, I have a question about bzr:
[16:51] <Ng> jam: oh, sorry, I just did "ubuntu-bug bzr" out of habit
[16:51] <Ng> I wonder if it's the pager plugin
[16:52] <Ng> yeah, it is :(
[16:52] <Christoph^> In my working directory, I have a configuration file. Is it possible to say that this configuration file should not be exported for releases, exporting a sample config file instead?
[16:55]  * mtaylor complains: while I've got bzr commit going in one window, it would be great if bzr diff still worked
[16:56]  * mtaylor understands locks are needed to prevent changes,  but still allowing reads wouldn't hurt anyone... :)
[16:56] <jelmer> mtaylor: I believe there's an open bug about this :-)
[16:56] <mtaylor> jelmer: yay!
[16:57] <GaryvdM> mtaylor: You can also use bzr qcommit
[16:59] <jam> mtaylor: there is a structure that is read and written in place, so reading it while updating it could cause reads of corrupted data
[17:00] <jam> that said, there is bug #98836
[17:00] <jelmer> GaryvdM: No, that's not really possible
[17:00] <jelmer> GaryvdM, You can wait for 2.1.1 :-)
[17:01] <jam> there is also 'bzr commit --show-diffs'
[17:02] <mhall119|work> how can I set my working copy to a specific revision in a repository?
[17:02] <GaryvdM> jelmer: re commit/diff or merging changelog
[17:02] <jam> mhall119|work: bzr revert -r X
[17:02] <mhall119|work> I can do hg update -r $rev
[17:02] <jam> in bzr 2.1.0 I believe 'bzr update -r X' also works
[17:02] <jam> sort of depends what you want the end result to be
[17:03] <mhall119|work> no, revert isn't what I want
[17:03] <GaryvdM> +1 for bzr update -r
[17:03] <mhall119|work> I'm on bzr 2.0.3
[17:04] <mhall119|work> which is the latest in karmic
[17:04] <jelmer> GaryvdM: regarding version numbers
[17:05] <awilkins> verterok, I think the update to 2.1 has busted a bunch of stuff in bzr-java-lib
[17:05] <GaryvdM> jelmer: ok, thanks
[17:07]  * Ng hrms at bzr diff. It seems like it doesn't imply the equivalent of diff -N, I just get told "[17:10] <awilkins> Ng, That seems odd, I'm getting the contents for added files in a vanilla diff command
[17:12] <jelmer> Ng: is the file empty perhaps?
[17:12] <Ng> I seem to have the most broken bzr install in the world ;)
[17:13] <Ng> jelmer: good point, well made
[17:14] <jam> james_w: current status summary: http://paste.ubuntu.com/382390/
[17:15] <mhall119|work> okay, I can bzr branch -r $rev lp:$project
[17:15] <mhall119|work> that'll work
[17:15] <jam> so we currently have 25 'failures', 9 of which are packages we don't really care about
[17:15] <mhall119|work> then bzr pull -r $rev
[17:15] <james_w> jam: cool, good to know, thanks
[17:16] <bialix> hi GaryvdM! and bye
[17:16] <jam> which is up from... 18 ok when we started the check-hottest.py script :)
[17:25] <verterok> awilkins: oh, I didn't tried it with 2.1, will take a look tonight
[17:26] <verterok> awilkins: could be bzr-xmloutput compatibility issues?
[17:30] <renpytom> Is there a way to convert a branch to use a repository?
[17:39] <GaryvdM> renpytom: I *think* bzr reconfigure
[17:39] <renpytom> GaryvdM, thanks!
[17:39] <GaryvdM> renpytom: bzr reconfigure --use-shared
[17:43] <Christoph^> In my working directory, I have a configuration file. Is it possible to say that this configuration file should not be exported for releases, exporting a sample config file instead?
[17:46] <GaryvdM> Christoph^: Maybe make a release branch. Change the configuration file in this branch. When you do a release, merge your trunk into the release branch, and export from there.
[17:46] <renpytom> GaryvdM, it worked for me. Thanks again.
[17:46] <GaryvdM> renpytom: pleasure
[17:53] <Christoph^> GaryvdM: uhm, ok
[18:03] <jfroy|work> morning ya'all
[18:06] <Adys> Is there a way to run a specific command/file when I run bzr update?
[18:06] <Adys> eg. compressing my css/js
[18:13] <mkanat> Adys: You could write a plugin that hooked on_branch_tip_change
[18:13] <mkanat> Or whatever that hook is called.
[18:14] <mkanat> post_change_branch_tip
[18:23] <fullermd> Wouldn't expect that to be the best choice, since there's no reason to assume the branch would change.
[18:23] <jam> fullermd, mkanat: we don't have a 'wt changed' hook yet, so post_branch_tip_changed is the current best to chose
[18:23] <jam> choose
[18:26] <Adys> mkanat, jam: What about committing changes without having them stick in the branch?
[18:26] <Adys> I dunno if that's clear, I just wouldn't want compressed js/css in every changelog
[18:26] <jam> Adys: I don't quite understand what you mean
[18:26] <jam> why do you want to commit the compressed files ?
[18:27] <jam> if you just auto-generate them
[18:27] <Adys> Well, apparently java is the only choice I have to compress javascript efficiently, and I'm not installing that on the server
[18:27] <Adys> so I'd need it on my computer
[18:28] <jam> if you are using 'bzr-upload' I *think* that supports uploading files that aren't versioned
[18:28] <Adys> http://wiki.bazaar.canonical.com/BazaarUploadForWebDev
[18:28] <Adys> looking good. ill have a test run :)
[18:30] <Adys> jam: nevermind, apparently you need them in your working tree
[18:31] <jam> do they need to be versioned?
[18:31] <Adys> yea looks like it
[18:32] <keithy> hi, is there a way to view a single file in a remote repo
[18:32] <keithy> like bzr cat
[18:32] <jam> keithy: bzr cat $REMOTE_BRANCH/path
[18:33] <keithy> tired that
[18:34] <keithy> ah http://bazaar.launchpad.net/~keithy/cuis/testing/files
[18:35] <keithy> could be a problem
[18:35] <keithy> oh it works now
[18:36] <keithy> bzr: ERROR: Permission denied: "Cannot create 'build.sh'. Only Bazaar branches are allowed."
[18:37] <keithy> bzr cat  lp:~keithy/cuis/testing/build.sh
[18:37] <keithy> thats what I was trying to do
[18:37] <keithy> the file is there http://bazaar.launchpad.net/~keithy/cuis/testing/annotate/head%3A/build.sh
[18:37] <keithy> lets try another branch
[18:38] <GaryvdM> Jelmer: The ppa versions of bzr have debian/bzr-doc.install, but debian unstable does not.
[18:38] <keithy> nope
[18:38] <GaryvdM> Jelmer: Is there a reason for this, or is it a bug?
[18:38] <keithy> jam sorry your suggesting doesnt seem to work
[18:41] <jam> keithy: works here: bzr cat -r -1 http://bazaar.launchpad.net/~keithy/cuis/testing/build.sh
[18:41] <jam> you may need the -r -1, not sure
[18:46] <jam> bzr cat lp:~keithy/cuis/testing/build.sh also worked for me, but that is going over bzr+ssh with my configuration
[18:47] <GaryvdM> jam: bzr cat lp:~keithy/cuis/testing/build.sh does not work for me
[18:47] <GaryvdM> bzr: ERROR: Permission denied: "Cannot create 'build.sh'. Only Bazaar branches are allowed."
[18:47] <jam> GaryvdM: hmm.. just failed, I spoke a bit too soon
[18:48] <GaryvdM> Maybe platform specific bug
[18:48] <jam> shouldn't be trying to create a file
[18:48] <jam> you know what...
[18:48] <jam> I know the bug
[18:48] <jam> they were just talking about it (mwhudson and lifeless)
[18:48] <jam> the code hosting server aborts if you supply it any file that isn't .bzr
[18:48] <jam> even for reading
[18:48] <jam> see the recent bug about wanting to unload 'bzr-git'
[18:48] <jam> because it was probing for .git directories
[18:49] <GaryvdM> ah
[18:49] <keithy> hmm
[18:49] <keithy> it doesnt translate line endings
[18:50] <jam> keithy: cat gives you the 'canonical' version
[18:52] <GaryvdM> jam: Intresting: You can do bzr qbrowse lp:~keithy/cuis/testing and then right click on build.sh, but not bzr qcat lp:~keithy/cuis/testing/build.sh
[18:52] <jam> GaryvdM: right, the issue is that we are probing for build.sh/.bzr/format
[18:53] <jam> and codehosting says "you are not allowed to create that file"
[18:53] <jam> which you aren't
[18:53] <GaryvdM> Ah
[18:53] <jam> but you should get NoSuchFile when trying to *read* it
[19:03] <keithy> k
[19:03] <keithy> ty
[19:05] <GaryvdM> Ah
[19:06] <GaryvdM> err sorry - wrong window had focus
[19:06] <awilkins> verterok, some of the commands seem to be missing attributes, but there also seems to be issues where the client code isn't receiving any output from STDOUT
[19:07] <verterok> awilkins: oh, ok. I need to take a look to 2.1 soon
[19:08] <verterok> awilkins: please file a bug about this, in bzr-java-lib or bzr-xmloutput
[19:09] <awilkins> verterok, Got 13 fails and 9 errors on the test suite.. I'll check out a branch of 2.0.x and make sure that the version difference is really the problem
[19:12] <verterok> awilkins: ok, thanks!
[19:39] <GaryvdM> ~/qbzr/wd/qbzr $ bzr rocks --Derror
[19:39] <GaryvdM> bzr: ERROR: no such option: --Derror
[19:39] <GaryvdM> Huh???
[19:39] <lifeless> -Derror
[19:39] <lifeless> not --Derror
[19:40] <lifeless> the option is -D, the value given to it is error, or evil, or hpss etc
[19:40] <GaryvdM> Ah, thanks lifeless
[19:41] <GaryvdM> lifeless: Good morning to you. :-)
[19:43] <lifeless> :) moin moin
[19:55] <RumblePure> I checked out a branch to my laptop. Having modified the code over a couple of days, I wanted to commit back to my stationary.
[19:55] <RumblePure> I did this trough bzr+ssh. Problem is my stationary had switched ip-number (dont have dyndns at the moment).
[19:56] <RumblePure> On my laptop in dir .bzr I found a conf file that contained the bzr+ssh://213.45.... address, and so I changed it, and could connect.
[19:56] <RumblePure> My question is, should I instead had used some kind of command to change the address?
[19:56] <lifeless> 'bzr switch'
[19:57] <RumblePure> aaaah, ok!
[19:57] <RumblePure> but no harm made now that I changed the conf-file manually right? I mean bzr switch would do the same, right?
[19:57] <lifeless> probably
[19:58] <lifeless> depends which conf file you mean and what command you ran; you didn't give any details ;)
[19:58] <RumblePure> yaiks! probably is not reassuring! ;-)
[19:58] <lifeless> what command were you running that was erroring
[19:58] <lifeless> [probably would have done the same thing] is what I meant
[19:58] <lifeless> didn't mean to scare you
[19:59] <RumblePure> I did bzr commit that simply could not find my stationary through ssh since it had changed ip-number
[20:00] <RumblePure> So I found the address in .bzr/branch/branch.conf (variable named bound_location) and changed it.
[20:00] <RumblePure> Then I could run bzr commit.
[20:00] <RumblePure> Would bzr switch had changed the same file?
[20:00] <lifeless> yes
[20:01] <RumblePure> aaaaah, thx so much lifeless!
[20:01] <RumblePure> spooky nick by the name :-P
[20:02] <RumblePure> another thing, so when I had changed the address and did bzr commit, it complained about conflicts regarding a file.
[20:02] <RumblePure> But the weird thing is that that file was under revision control! It was under control on my stationary before i checked out to my laptop!
[20:02] <lifeless> RumblePure: that means you already had the conflcts locally; bzr st would have shown you that.
[20:03] <RumblePure> Why do you think there was a problem with the file even if it was under revision control?
[20:04] <lifeless> a conflict means that it had not merged cleanly
[20:05] <lifeless> you have more info about the specific case than I do
[20:05] <RumblePure> well there is no more info because I dealt with the problem. What's frustrating is that I really can't be sure what i did. :-/
[20:06] <RumblePure> I did bzr resolve file_name, and that messed up the file (added stuff like "<<<<< TREE" to some lines in the file).
[20:06] <RumblePure> Then I could do bzr commit, and after that I changed the file bac manually on my stationary. In hindsight, I really would like to know what that was about :-/
[20:06] <RumblePure> *changed the file back
[20:11] <newz2000> Hi, is there a way to make bzr ignore changes to file permissions for a particular commit?
[20:15] <lifeless> newz2000: revert or shelve the change
[20:16] <lifeless> RumblePure: bzr resolve did not add the <<< markers
[20:16] <lifeless> RumblePure: 'bzr update' would have added them.
[20:16] <newz2000> ah, ok, thanks lifeless
[20:17] <RumblePure> lifeless you're right. I did run bzr update too. Just didn't think that caused it.
[20:18] <RumblePure> But dare to take a guess what the conflict was about? Did the file somehow differ between my laptop and stationary? Of course it did! I had been working on it on my laptop :-/
[20:18] <lifeless> and you had done another commit on your stationary after starting work on it on your laptop
[20:20] <RumblePure> lifeless I'm not sure if I did so but that can really be the case! I'll settle with that as a likely explanation in my speculations. :-)
[20:20] <lifeless> if you had not, you would not have needed to update
[20:20] <eelik> jam: thanks for the answer :)
[20:20] <lifeless> bzr log -n0 can tell you
[20:21] <RumblePure> thx very much lifeless, you put some extra effort to help me in this guesswork. appreciated.
[20:21] <eelik> jam: I think the first clause in http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html#merging-trunk-to-your-feature-branch is inaccurate or erroneous
[20:22] <eelik> clause -> sentence
[20:23] <herbtea> hello all, I'm a newbie to irc and bazaar
[20:24] <herbtea> I'm hoping someone can help me out with a question I haven't been able to find in answer to in the documentation
[20:25] <herbtea> In the bazaar explorer options>behavior there is something called "workspace Model" with different options
[20:25] <herbtea> Options like, shared repository, feature-branches, etc. where can I find out what each of those options do?
[20:26] <rubbs> herbtea: I'm not sure on where you can find the info, but I could probably tell you what they all mean.
[20:26] <herbtea> excellent, I'm all ears
[20:27] <GaryvdM> This may help: http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_your_workspace.html
[20:27] <rubbs> Shared repos are a common root directory that all branches underneath share history. This is great for space saving.
[20:27] <rubbs> feature branches are just branches you create to implement a particular branch.
[20:28] <herbtea> how about collocated branches and plain branch?
[20:28] <rubbs> er...
[20:28] <herbtea> thanks GaryvdM, I'll check that out
[20:28] <rubbs> plain branches are just that, one branch with no special features. All the history is stored at that branches location
[20:28] <rubbs> collocated branches are branches that share one particular workspace.
[20:29] <rubbs> so you can "switch" between branches in the same directory
[20:29] <rubbs> collocated brances are similar to Git's workflow if that helps (probably doesn't if you've never used git)
[20:29] <herbtea> thanks rubbs, this will give me some more info to ponder
[20:30] <herbtea> I'm a web developer who is finally taking the plunge into using a VCS
[20:30] <herbtea> lots to think about in terms of what type of structure makes the most sense for my workflow
[20:33] <rubbs> herbtea: np. I would suggest trying out the feature branch workflow.
[20:33] <rubbs> might be hard to understand at first, but once you get it, it's very powerful
[20:33] <herbtea> how do I specify a person I'm chatting with?
[20:34] <herbtea> what's the syntax
[20:34] <herbtea> rubbs: test
[20:34] <herbtea> ahh
[20:34] <rubbs> well, most of the time you can just chat in the main room and to get the attention of them, you just type their name
[20:34] <rubbs> herbtea: yep, you did it right
[20:35] <herbtea> kewl :)
[20:35] <herbtea> rubbs: so yeah, I think the feature branch is what I've been considering
[20:35] <rubbs> if you need to (not always recommended because group chats can benifet others and others can chime in) you can type "/msg nickname message" and it will open a private chat with nickname
[20:35] <herbtea> thanks
[20:36] <herbtea> is there a help function to access with this type of info?
[20:36] <rubbs> yes,
[20:37] <rubbs> "bzr help" will get you started
[20:37] <rubbs> "bzr help topics" is also nice.
[20:37] <rubbs> bzr help and a command will give you specific help with a command.
[20:37] <herbtea> great, I'll be doing some more reading
[20:37] <rubbs> np. and feel free to come back and ask questions.
[20:38] <awilkins> Is there a way to stop bazaar loading bundled plugins (the ones in dist-packages/bzrlib/plugins) but still load the ones on BZR_PLUGIN_PATH ?
[20:39] <herbtea> quit
[20:39] <herbtea> bzr help
[20:40] <rubbs> herbtea: to quit irc type "/quit" or sometimes "/bye" or "/exit" work too
[20:41] <herbtea> ahh, thanks bro
[20:41] <rubbs> np, I had to learn too!
[20:41] <awilkins> e.g. for testing purposes, even if you are running from a source tarball it still insists on loading plugins from this location.. in fact, isn't this a bug? It's rather confounding testing of 2.0.4 vs 2.1.0 because news_merge isn't compatible with the older release.
[20:43] <gregcoit> a terminology question: is "bzr branch" appropriate for grabbing code from launchpad w/o an account (i don't need to push changes back)?
[20:43] <lifeless> awilkins: yes
[20:43] <lifeless> awilkins: set the bzr plugins path
[20:43] <lifeless> gregcoit: yes
[20:43] <gregcoit> lifeless: thanks!
[20:43] <Peng> gregcoit: Although performance over http:// isn't as good.
[20:44] <awilkins> lifeless, That doesn't seem to override the behaviour of loading plugins from /usr/lib/python2.6/dist-packages/bzrlib/plugins, but I'll just check
[20:44] <rubbs> gregcoit: yes, because branch only means to "clone" the branch. Push would require an account
[20:44] <gregcoit> rubbs: as would co, right?
[20:44] <gregcoit> Peng: not a huge issue in this case I think - but good to know!
[20:45] <rubbs> gregcoit: no, co would just clone the very last revision. Branch takes down the whole branch history.
[20:45] <gregcoit> rubbs: ahh, so maybe co is a better option...
[20:45] <Peng> Ehh.
[20:45] <lifeless> awilkins: there is definitely a way. hmm
[20:45] <Peng> Especially over http://, I wouldn't be surprised if checkout was really inefficient.
[20:45] <rubbs> gregcoit: yeah, if you're just trying to just get the latest snapshot.
[20:46] <lifeless> rubbs: 'co' does a full branch by default
[20:46] <Peng> And you need a decent chunk of the history to extract the latest revision from.
[20:46] <lifeless> gregcoit: 'branch' is fine
[20:46] <rubbs> gregcoit: oh I'm wrong please see lifeless's comment abouve.
[20:46] <gregcoit> lifeless: ok, branch is it = thanks!
[20:46] <gregcoit> rubbs: np - that's the beauty of irc - crowd sourced support
[20:46] <lifeless> rubbs: the difference between co and branch is that you use 'update + commit' in one, and 'pull/merge + commit+push' in the other
[20:47] <lifeless> rubbs: co --lightweight downloads only the working files : but does so /much/ less efficiently. Do Not Use Over The Internet.
[20:47] <rubbs> lifeless: ah thanks, so you have to explicitly say lightweight to make it act like svn?
[20:47] <rubbs> lifeless: ah, ok. cool. thanks
[20:47] <lifeless> depends on what you mean by 'act like svn'
[20:47] <rubbs> just meant checked out the working tree, but you answered my question as I posted it.
[20:47] <lifeless> if you mean 'use update and commit with what it outputs', that what it does and why it exists.
[20:48] <lifeless> rubbs: well, even with --lightweight its not acting like svn
[20:48] <lifeless> rubbs: svn keeps a cache of the unmodified files, bzr does not.
[20:48] <lifeless> rubbs: and svn has a wire protocol optimised for this style of working - bzr does not.
[20:48] <rubbs> ah I c, ok then thanks!
[20:54] <thumper> lifeless: how do you do a partial checkout?
[20:54] <thumper> lifeless: just a subtree
[20:55] <rubbs> I don't think that's possible.
[20:55] <thumper> I recall reading something somewhere about it though
[20:55] <lifeless> thumper: views
[20:55] <thumper> lifeless: how do you create a view?
[20:55] <lifeless> bzr help view
[20:55] <thumper> bzr help views?
[20:55] <gregcoit> lol
[20:55] <gregcoit> jinx
[20:56] <lifeless> note that using a view still requires all the history
[20:57] <lifeless> it does not save disk space usage by bzr; but it does avoid having files outside the view in your work area.
[21:18] <GaryvdM> Hi poolie
[21:21] <poolie> hello GaryvdM
[21:32] <GaryvdM> Bla - This office that I'm working at, I have to be out before 12, else I'm locked in till tommorow.
[21:33] <GaryvdM> Bye all.
[21:33] <poolie> ok
[21:33] <poolie> bye
[22:14] <mwhudson> this doesn't seem like it should be that hard
[22:15] <mwhudson> what's the easiest way, in a test, to get a standalone branch with a repository that has two heads?
[22:15] <lifeless> get_branch_builder or whatever
[22:27] <mkanat> mwhudson: Sooo...no more hangs?
[22:28] <mwhudson> mkanat: not that i've been informed of, no
[22:28] <mwhudson> nearly a week now...
[22:28] <lifeless> mwhudson: so you get a branch builer
[22:28] <lifeless> start branch
[22:28] <mkanat> mwhudson: Okay.
[22:28] <lifeless> do a commit adding root
[22:28] <lifeless> do a commit with implicit parent
[22:28] <mkanat> mwhudson: What an annoying time for it to be stable.
[22:28] <lifeless> do a commit with explicit parent of the first commit
[22:28] <lifeless> voila, two heads
[22:29] <lifeless> there are plenty of tests that do that now
[22:29] <mwhudson> oh, maybe that'
[22:29] <mwhudson> s where i'm going wrong: not adding the root
[22:29] <lifeless> if you look at bzrlib's tests
[22:29] <lifeless> for anything using bb, you'll see the first thing is an added file for the root; cargo cult that.
[22:33] <mwhudson> lifeless: thanks
[22:33] <mwhudson> finally a failing test
[23:35] <mathrick> jelmer: hi
[23:35] <mathrick> http://pastebin.com/vYVMNWjf
[23:35] <mathrick> a nice crasher in dulwhich
[23:35] <mathrick> it tries to do map.read(), without actually defining map, so it ends up going to the built-in function
[23:42] <mathrick> oh, I see, it was supposed to be mmap
[23:51] <mathrick> hmm, no
[23:58] <gregcoit> can I make a new branch from a dir in a branch using bzr?