[00:04] <xnox> Can someone give me a scenario when you want to use :parent :push :submit and :public branches
[00:08] <xnox> spiv: yeap everything gets preserved you can be bound and have :parent :push :submit and :public
[00:25] <johnjosephbachir> anyone here have any experience with add --file-ids-from ... ?
[00:26] <johnjosephbachir> it seems tantalizingly useful but i cannot find any examples
[00:27] <james_w> johnjosephbachir: you pass a path to another branch and if the path it is adding is in the other branch then it re-uses the file-id from that in this branch
[00:27] <james_w> say you have a stable and a development branch
[00:27] <james_w> you want to add COPYING to each
[00:27] <james_w> you go in to stable and "bzr add COPYING", commit etc.
[00:28] <james_w> then go to development, put the file there, and then "bzr add COPYING --file-ids-from ../stable"
[00:28] <james_w> and then when you merge there won't be a path conflict due to two random id assignments being done
[00:29] <james_w> that's not the only use, and there are other ways to achieve the same thing in that case, but it's an example
[00:29] <johnjosephbachir> cool
[00:29] <johnjosephbachir> i am interested in the last line of the paragraph in the manpage: It is also useful when merging another project into a subdirectory of this one
[00:30] <johnjosephbachir> james_w: i imagine that this should be useful in subsequently updating the files in the subdirectory project
[00:30] <johnjosephbachir> but i can't fathom what that workflow would be
[00:31] <johnjosephbachir> since there is no notion of running a merge on a subtree which points to a foreign branch (is there?)
[00:33] <james_w> well, if the ids match then it will merge the files
[00:33] <james_w> however, I'm not really sure how that would work
[00:33] <james_w> as you have to get the revision history joined as well (could perhaps just be a second step)
[00:34] <james_w> and I don't know how you deal with the root, or the path differences
[00:34] <james_w> there's a merge-into plugin for doing this task, probably better to look at that if you are actually looking to do this
[00:35] <johnjosephbachir> james_w: great, i will definitely check that out. was also looking at bzr-scmproj but it seemed a little heavy
[00:42] <johnjosephbachir> it doesn't work with 2a repos... great.
[00:55] <james_w> what doesn't?
[01:07] <poolie> igc, random idea for the plugin guide, since it came up with jml
[01:07] <poolie> document how to handle heavy dependencies
[01:07] <poolie> don't load them from __init__
[01:07] <poolie> just let the commands fail
[01:07] <poolie> hello james_w
[01:07] <igc> poolie: interesting
[01:07] <james_w> hi poolie
[01:07] <james_w> morning igc
[01:08] <igc> poolie: bialix made some changes to the command handling is explorer lately to reduce start-up time, etc. so it will be nice to capture that sort of wisdom
[01:08] <igc> in
[01:08] <james_w> poolie: the couple of threads on udd seem to be stalled
[01:09] <james_w> do we need to jump-start them?
[01:09] <poolie> they do a bit
[01:09] <igc> hi james_w
[01:09] <poolie> we are working on some bugs
[01:09] <poolie> spiv is doing per-file merge hooks today
[01:09] <poolie> but i think we need to get the earlier pipeline stages flowing too
[01:13] <poolie> james_w: any specific things we should do?
[01:13] <poolie> just reply to the loose ends?
[01:14] <der|> is there any command to remove the 'pending-deletion' and 'limbo' directories from my .bzr directory ?
[01:14] <poolie> hm
[01:14] <poolie> do you need to?
[01:15] <der|> many times bzr complains that the files exist and I can't do nothing
[01:15] <poolie> i guess you can just delete them but maybe file (or look for) a bug report
[01:15] <james_w> my mail about the things we may need over the next few months hasn't seen many responses
[01:15] <poolie> because you shouldn't need to manually remove them
[01:15] <der|> bzr: ERROR: This tree contains left-over files from a failed operation.
[01:15] <james_w> I don't think there's been an assessment of which we need and which we will do
[01:16] <poolie> i'll look at them again- but igc, spiv, can you look too please?
[01:16] <der|> now, I've heavily used bzr on a linux-based system, but since I (unwillingly) had to migrate to windows, bzr starts creating some sort of lock files and the limbo ones
[01:16] <igc> poolie, james_w: shall do
[01:17]  * spiv looks
[01:17] <der|> on linux bzr works flawlessly to my experience
[01:18] <der|> poolie, there's already a bug report in this: 427773
[01:18] <poolie> bug 427773
[01:18] <poolie> hm
[01:18] <poolie> and are you on 2.0.1 or 2.1.0b1 or later?
[01:19] <der|> Bazaar (bzr) 2.1.0b3
[01:19] <der|> poolie, so far I haven't had the annoying lock issues (thank God)
[01:19] <der|> seems like that has been fixed
[01:20] <poolie> der|: so this bug is apparently not fixed?
[01:21] <der|> poolie, btw, if I have to report something regarding the bzr explorer plugin, where should I go ?
[01:21] <poolie> and they are empty?
[01:21] <poolie> please comment there and reopen it then
[01:21] <poolie> launchpad.net/bzr-explorer
[01:21] <der|> the limbo and pending-deletion are empty correct
[01:22] <der|> poolie, maybe this helps:  I was workign with a Photoshop PSD file, and I was trying to revert it with:   bzr revert --no-backup -r5 home.psd, after that the limbo and the pending-deletion directories were conflicting
[01:22] <der|> poolie, do the bzr explorer guys have an IRC channel ?
[01:31] <poolie> they're in here -- hi igc!
[01:32] <poolie> der|: please reopen the bug and say that there
[01:32] <poolie> i'm happy to help you here but i want a record too
[01:32] <poolie> was it maybe still open in ps when you did this?
[01:32] <poolie> could be file locking
[01:32] <der|> poolie, sure, I'm filing a bug for bzr explorer now, just 1 sec
[01:32] <der|> poolie, yeah, ps was open, maybe that's the issue
[01:33] <poolie> i'm surprised it would fail on the limbo directories rather than when moving the file though
[01:35] <johnjosephbachir> james_w: merge-into doesn't work with 2a
[01:35] <johnjosephbachir> it also doesn't help with subsequent merges (i think)
[01:35] <james_w> that sounds odd
[01:36] <johnjosephbachir> indeed
[01:38] <der|> poolie, how do I reopen the bug ?
[01:38] <poolie> click 'status'
[01:38] <der|> it has 2 statuses, one says Bazaar and the other says 2.0
[01:39] <der|> both say 'Fix Released'
[01:39] <poolie> mm
[01:39] <poolie> cos it's a bug we'd like to fix in the stable series
[01:39] <der|> https://bugs.launchpad.net/bzr/+bug/427773
[01:39] <poolie> so in this case it would be reasonable to reopen both
[01:39] <der|> indeed
[01:40] <der|> so, post the same comment on both statuses ?
[01:40] <poolie> just one comment will do
[01:40] <der|> ok good, which status I set ?
[01:40] <poolie> both
[01:40] <poolie> you can change them with no comment
[01:41] <der|> ok, but where it says Fix Released, should I put 'In Progress' ?
[01:42] <poolie> i'll do it
[01:42] <poolie> you concentrate on the comment :)
[01:43] <der|> ok hehe, I'll just put the comment
[01:47] <der|> poolie, ok, posted the comment
[01:47] <poolie> can you reproduce it?
[01:47] <der|> ok, let me try, 1 sec
[01:52] <der|> poolie, if I try to revert 3 times, it first tells me about the pending-deletion, then about the limbo, and then it locks it
[01:54] <der|> poolie, ok, I'm able to reproduce it 100% of the time, what should I do now ?
[01:55] <der|> poolie, and by the way, bzr actually reverts the file, so that error or exception should not be displayed/thrown
[01:55] <poolie> just post that
[01:55] <poolie> maybe garyvdm can look at it
[01:55] <der|> ok, I'll post how to reproduce it
[01:58] <Stavros> hello
[01:59] <Stavros> does anyone know of a continuous integration server that receives pull requests, pulls, checks the build and merges if the tests pass?
[01:59] <Stavros> i can't remember the name...
[02:00] <lifeless> igc: http://blogs.sun.com/joshis/entry/hudson_integration_in_netbeans_6 <- slick :)
[02:00] <der|> poolie, just posted the comment with the replication procedure, hope it helps :)
[02:01] <bob2> Stavros: PQM?
[02:02] <Stavros> bob2: let me check, i think that's it
[02:02] <Stavros> yes, fantastic, thanks!
[02:02] <der|> well, I'm out, thanks for the support guys, and kudos for creating such a wonderful piece of software... peace and good night!
[02:02] <Stavros> does anyone know how it compares to hudson?
[02:02] <lifeless> Stavros: apples and oranges
[02:02] <lifeless> hudson does not have test-before-commit yet
[02:03] <lifeless> pqm only has test-before-commit
[02:03] <lifeless> hudson has a shiny UI and lots of toolchain support
[02:03] <lifeless> pqm has bare bones UI - its a 'hackers tool'
[02:03] <Stavros> ah, i see
[02:03] <Stavros> does it only work by email?
[02:04] <Stavros> basically as i understand it hudson only tests after the commit while pqm does not commit unless the tests pass
[02:04] <lifeless> pqm has a pluggable queue concept but only one impleentation -the email submission, locally stored queue
[02:04] <Stavros> ah right right, i see
[02:04] <lifeless> http://issues.hudson-ci.org/browse/HUDSON-1682
[02:04] <lifeless> if that ^ gets done, then it would be equivalent to pqm, but much much nicer
[02:05] <poolie> james_w: so i guess just knowing that people should report those failures as bugs on udd helps
[02:05] <Stavros> yeah, but also much harder for them to do it i imagine
[02:05] <Stavros> since they're looking to do it in a general manner
[02:05] <Stavros> i have to decide which method i want to use, then
[02:05] <lifeless> Stavros: not really, pqm is pretty general
[02:05] <lifeless> its just a matter of doing it.
[02:05] <Stavros> does it support other scms?
[02:05] <poolie> der|: fyi 'incomplete' means 'we need more data to do anything' not 'incompletely fixed'
[02:06] <spiv> poolie, james_w: replied to udd list
[02:06] <spiv> poolie, james_w: there are some points there that I think need attention from the lp code team rather than the bzr team, though
[02:07] <spiv> e.g. the query about 'Do Branch.requestMirror() and Branch.last_mirror_attempt refer to importing to the code if the branch is a vcs-imports one?'
[02:10] <fungalicious> poolie: ping
[02:11] <fungalicious> thumper: ayt?  (this is actually kfogel)
[02:12] <thumper> fungalicious: nah, you don't sound like him
[02:12] <fungalicious> thumper: :-)
[02:13] <fungalicious> thumper: heh.  At Winnie's house, left my computer elsewhere
[02:14] <fungalicious> thumper: can you do me a favor?  I forgot to send out a message to internal launchpad list, addressed to team leads, saying that we were giving up on the SIP thing and that the next call would use regular conf system
[02:14] <fungalicious> thumper: I can't send it easily from here, as my work email authn creds are not on this box
[02:15] <thumper> fungalicious: I'll send one out
[02:16] <fungalicious> thumper: my impersonation worked!  You really believed I am kfogel!  MY CORPORATE ESPIONAGE IS SUCCESSFUL!!!
[02:16] <fungalicious> thumper: thank you
[02:16]  * thumper thinks twice
[02:16] <fungalicious> c'mon, only kfogel would say that
[02:16]  * thumper thinks thrice
[02:17] <thumper> heh
[02:17]  * fungalicious goes recursive on the whole impersonation thing
[02:17] <thumper> sure, I'll send it out
[02:17] <fungalicious> Now I have to wonder if this is really thumper.
[02:17] <fungalicious> HAH
[02:17] <fungalicious> nic
[02:17] <fungalicious> nice
[02:18] <eric-the-half-a-> dang
[02:19] <fungalicious> ok, signing out as I think spending the night on IRC is perhaps not what Winnie and I had in mind
[02:19] <fungalicious> thumper: thanks
[02:42] <poolie> wonder what he wanted
[02:45] <lifeless> whom?
[02:55] <gutworth> (who you mean?)
[04:01]  * igc lunch
[05:43] <jam> lifeless: I did some work on bug 481119, it is pretty annoying as it prevents using hudson + junit with bzr selftest --subunit
[05:43] <jam> tz aware datetime is crap
[05:43] <jam> IMO
[05:47] <jam> note that *with* my ugly ugly hack, I was able to run a subset of the test suite using hudson on win32 and have it report results
[05:51]  * igc medical appointment
[05:51] <jam> igc: good luck
[05:51] <igc> hi jam - thansk
[05:52] <igc> thanks
[06:04] <lifeless> jam: oh, cool
[06:05] <lifeless> jam: let me have a look at the bug, one sec.
[06:06] <jam> is there a reasonable "display a rough summary of what is going on" that would be reasonable to include in the 'build and run the tests' output?
[06:06] <jam> I'd like something that I could check to see that it is making progress
[06:06] <jam> but I don't really want the full subunit output
[06:06] <lifeless> jam: sure, subunit2pyunit
[06:06] <poolie> night all
[06:06] <jam> so, subunit2pyunit --progress makes sense to be, but not really in a build system
[06:07] <jam> night poolie
[06:07] <jam> I guess it just gives pyunit --verbose output, which you're probably right
[06:07] <jam> is the most reasonable thing
[06:07] <jam> one line per test
[06:08] <jam> now if only pure win32 actually had a 'tee' program... :)
[06:09] <lifeless> we can make subunit2pyunit pass the stream through
[06:09] <lifeless> selftest | subunit2junitxml -o tests.xml | subunit2pyunit
[06:10] <lifeless> jam: there is a hudson ssh thingy now, for ec2 w/ windows
[06:10] <jam> lifeless: well, I have cygwin installed and can just grab that, but it seems stupid
[06:10] <lifeless> I've linked it to the ec2 windows bug
[06:10] <jam> lifeless: yeah, I saw the ssh thing
[06:10] <jam> I don't know about start/stop yet for windows
[06:10] <lifeless> jam: win32 shell can pipe can't it ?
[06:10] <jam> lifeless: shell can pipe, can't tee
[06:10] <lifeless> right
[06:11] <lifeless> so would -  selftest | subunit2junitxml -o tests.xml | subunit2pyunit work ?
[06:11] <lifeless> if that passed the stream through
[06:11] <jam> lifeless: probably
[06:11] <jam> I sort of like saving the subunit results, though
[06:11] <jam> since I can use them in debugging
[06:11] <lifeless> yes
[06:11] <jam> the hudson progress bar is quite interesting
[06:12] <jam> it seems to base it on how long things are expected to take
[06:12] <lifeless> yes
[06:12] <jam> based on previous runs
[06:12] <jam> as mine is now fully in the red
[06:12] <jam> as previously I just ran "setup.py build" which is a bit faster than 'selftest' :)
[06:12] <lifeless> what hudson instance are you using?
[06:12] <jam> local
[06:12] <lifeless> cool
[06:12] <jam> Eventually, I'd like to hook it up to ec2
[06:12] <jam> and then see about stuff with babune
[06:12] <jam> but figured one step at a time
[06:12] <lifeless> so, parameterised jobs will let you submit arbitrary branches
[06:13] <lifeless> night poolie
[06:13] <lifeless> the drizzle folk do this
[06:13] <jam> yeah, though there is also a Bazaar plugin
[06:13] <jam> that can check out code from bzr automatically
[06:13] <lifeless> they have a parameter trigger in fact - one field, put in a branch, and it kicks off 8 different configs
[06:13] <jam> which I'm also playing with
[06:13] <lifeless> jam: this is with that plugin.
[06:13] <lifeless> the two combine for more awesome
[06:13] <jam> hmm.. I haven't seen a way to use the parameter from the parameterization in the plugin
[06:13] <jam> I've seen the fields you can add
[06:14] <jam> but I would have to write the 'bzr branch' manually (from what I've seen so far)
[06:14] <lifeless> let me poke at their config
[06:14] <lifeless> you have a parameter BZR_BRANCH
[06:15] <lifeless> and in the SCM details you say
[06:15] <lifeless> ${BZR_BRANCH} as the bazaar repository URL
[06:15] <jam> So in the "configure this build" page, I have a "Repository URL" in the Source Code Management section.
[06:15] <jam> ah, ok
[06:15] <jam> I did play with params at the beginning
[06:18] <jam> I also have to say +1 to the Bruce Schneier plugin
[06:18] <lifeless> :)
[06:18] <jam> I've seen it before, but it adds a bit of levity when browsing the results
[06:18] <lifeless> chuck norris++
[06:18] <jam> Bruce Schneier's secure handshake is so strong, you won't be able to exchange keys with anyone else for days.
[06:19] <lifeless> lol
[06:19] <jam> lifeless: do you know the specifics between a 'successful build' and a 'stable' one?
[06:19] <jam> Is it returns 0 for successful
[06:19] <jam> and 'stable' is all tests pass?
[06:20] <jam> interesting, even gives an rss feed for 'all builds' or 'all failing builds'
[06:21] <lifeless> so
[06:22] <lifeless> you can introspect builds a bit if you build with more finesse than shell scripts
[06:22] <lifeless> and you can separate 'compiled' from 'something wrong after the compile'
[06:22] <lifeless> stable build is all tests passed
[06:22] <lifeless> unstable build is some tests failed but the build completed.
[06:23] <lifeless> there isn't currently an interface for shell steps to indicate unstable.
[06:23] <lifeless> I was thinking of writing a plugin to look for a file 'build-unstable' to permit that.
[06:23] <jam> lifeless: I find this odd: http://weblogs.java.net/blog/2009/05/20/project-day-ssh-daemon-ec2-windows-amis
[06:23] <jam> given that there is already cygwin with a fully functioning ssh
[06:24] <lifeless> there is
[06:25] <lifeless> but it can be a little temperamental, and its much more complex than I'd want to have a remote-setup maintain
[06:25] <lifeless> where as this is a single jar, anda  jvm, which hudson wants anyway.
[06:33] <lifeless> jam: anyhow, glad you are enjoying it; the tz thing - I think I started to stab at it; basically subunit was sending the wrong timedness for the junitxml code
[06:33] <lifeless> jam: my inclination is just to say 'always be utc (tz) aware, because subunit generates iso timestamps, which are always given a tz.
[06:34] <jam> lifeless: Did you see my branch/
[06:34] <jam> ?
[06:34] <lifeless> yes, I haven't looked at the content yet
[06:34] <jam> it implements an overly simple tzinfo class
[06:34] <jam> and then changes the line from
[06:35] <jam> datetime.utcnow() to datetime.now(local_tz)
[06:35] <lifeless> that seems reasonable. its a bit nuts that utcnow doesn't return, well, utc datestamps
[06:35] <jam> yeah
[06:36] <jam> another possibility
[06:36] <jam> is to use the test start time as the first time in the stream
[06:36] <jam> I think it is actually going to be a bit broken for my use case
[06:37] <jam> since I'm running subunit2junitxml *after* the test suite finishes
[06:37] <lifeless> I don't see why that would make it broken
[06:37] <lifeless> (but why are you running it after ?)
[06:37] <jam> lifeless: it will report a total-time of however long it takes to parse the file
[06:38] <jam> since it takes the individual time runs based on the stream
[06:38] <lifeless> huh ?
[06:38] <jam> but startTestRun() it takes from whenever the script starts
[06:39] <jam> lifeless: self._run_start seems to be set before any of the stream is parsed
[06:39] <jam> it is the only call that uses datestamp.utcnow()
[06:39] <lifeless> ah
[06:39] <jam> all the rest return the time that got set by the call to the .time() function.
[06:40] <lifeless> subunit doesn't have a start stream command
[06:40] <lifeless> so, thats likely a bug in subunit2junitxml
[06:40] <jam> lifeless: so if you just fixed that, it would avoid needing to call utcnow() (IME)
[06:40] <lifeless> it probably wants to reset the total time at the first explicit time() call
[06:40] <jam> right, something like that
[06:40] <lifeless> bbs
[06:41] <jam> well, I'm heading to sleep anyway
[06:42] <jam> subunit2pyunit seems to have the same problem, for what its worth
[06:42] <jam> Ran 13835 tests in 3.475s
[06:57] <vila> jam: sleep well ! :)
[06:57]  * vila 's not there yet
[07:23]  * fullermd waves at vila.
[07:30] <vila> hi all
[07:30]  * vila waves back to fullermd 
[09:09]  * igc dinner
[09:18] <vila> igc: ping
[11:46] <_Andrew> hi guys, quick question
[11:46] <_Andrew> how do I produce a diff with the authors name in it
[11:46] <_Andrew> so I can send it as a patch
[11:47] <Kamping_Kaiser> bundle, iirc
[12:00] <fijal> eh
[12:00] <fijal> I seem to be caught in a dependency cyclce
[12:00] <fijal> cycle
[12:00] <fijal> how do I get a checkout of bzr?
[12:01] <fijal> seemingly harmless question, but the repository is newer than my bzre
[12:01] <fijal> bzr
[12:02] <Kamping_Kaiser> your not able to upgrade your bzr?
[12:02] <fijal> ok, got the tarball
[12:02] <fijal> I don't want to upgrade my bzr
[12:02] <fijal> I just want a checkout
[12:02] <fijal> seems to be contradictory
[12:04] <fijal> how do I run bzr tests?
[12:07] <fijal> bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'get_foreign_tests_branch_factory'
[12:07] <fijal> this is what happens if I run bzr selftest
[12:08] <fijal> great
[12:17] <jelmer> fijal, looks like you have an old version of one of the foreign branch plugins
[12:19] <fijal> that's great
[12:19] <fijal> how do I tell bzr "ignore my plugins, I don't care"
[12:19] <fijal> ?
[12:33] <spiv> fijal: --no-plugins
[12:36] <fijal> any reason why bzr has yet-another test runner?
[12:37] <fijal> for example, is there an option "stop at the first crash"?
[12:54] <vila> fijal: -1
[12:55] <vila> fijal: there are many good reasons for that yes, one is that the full test suite run can be quite long and even just loading the python modules containing the tests is significant, so there is the --starting-with (-s option) that greatly speeds up that part.
[13:01] <spiv> fijal: it's basically just standard unittest with a bunch of tasteful extensions.  There's a branch from lifeless that removes a bunch of our test code and replaces it with a dependency on testtools (http://launchpad.net/testtools)
[13:19] <__monty__> How do I get to know the bzr source? Do I start at setup.py and follow every outside call?
[13:21] <james_w> __monty__: bzrlib/builtins.py might be a good place to start
[13:21] <james_w> it's the top-level for each of the commands you know and love
[13:21] <james_w> so you can see the sort of thing you have to do to display the history in "bzr log"
[13:22] <rubbs> __monty__: what james_w said. That and there are some dev docs here : http://doc.bazaar-vcs.org/developers/
[13:22] <__monty__> Ok thanks you guys.
[13:22] <rubbs> __monty__: np. good luck
[13:48] <Mez> hardy PPA isn't building.
[13:48] <Mez>   bzr: Depends: python-central (>= 0.6.11) but 0.6.7ubuntu0.1 is to be installed
[13:48] <Mez> sorry, isn't installable.
[13:51] <Mez> nvm, my mistake
[14:44] <jam> vila: looks like you had a good start to your piloting :)
[14:45] <vila> jam: thanks for the support :)
[14:49] <vila> Except for the remaining doc ones that I hope igc will look into soon, I think all mps got at least one comment and only one is still waiting for some work from me (deprecation warning).
[14:50] <vila> Nobody has voluntereed (sp?) for next week though...
[14:54] <znik> i am getting this error: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~flavour/sahana/sahana-trunk/".
[14:56] <james_w> why can't I find <built-in function utf_8_encode> in the python 2.6 docs?
[14:56] <james_w> and why does it seem to be trying to encode to ascii?
[14:57] <james_w> znik: running what command?
[14:57] <jelmer> james_w: it's in codecs
[14:57] <znik> james_w:  bzr branch lp:~flavour/sahana/sahana-trunk sahana
[14:58] <james_w> znik: do you want lp:sahana/sahanapy
[14:58] <james_w> ?
[14:58] <james_w> jelmer: yeah, I can't find it
[14:58] <vila> james_w: str.encode('utf8') ?
[14:58] <znik> james_w: ohh sorry imissed the py!!
[14:59] <james_w> vila: it's in bzr
[14:59] <jelmer> james_w: what gives you the impression it encodes to ascii?
[14:59] <james_w> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128)
[15:00] <jelmer> james_w: that suggests you're passing in a plain string, not a unicode string
[15:01] <james_w> I'm trying to pass in the result of <string>.decode("utf-8")
[15:02] <vila> james_w: it's implemented in C: ./Modules/_codecsmodule.c:684:utf_8_encode(PyObject *self,
[15:03] <vila> james_w: it's weird that you get a UnicodeDecodeError if you're *enc*oding
[15:03] <james_w> ah
[15:03] <calvin1602> Hi. I'm deperately looking for PQM documentation.
[15:04] <calvin1602> Any help ? :)
[15:04] <james_w> so it's presumably the str = PyUnicode_FromObject(str); that is failing
[15:04] <vila> james_w: ECONTEXT
[15:04] <assad> james_w: i am getting a permission denied. do i have to ask the moderators for permission
[15:04] <james_w> vila: in the function you just pointed too
[15:05] <james_w> assad: doing what?
[15:05] <assad> james_w: bzr branch lp:~flavour/sahana/sahana-trunk sahana
[15:06] <vila> james_w: if you passed in an unicode string that shouldn't occured
[15:06] <james_w> I must be passing a plain string as jelmer suggested
[15:07] <james_w> I'm looking now to see if re is getting in the way
[15:07] <james_w> or something isn't doing what I think
[15:07] <james_w> assad: I don't see why that would give a permission denied. Could you pastebin the output please?
[15:08] <vila> james_w: osutils.safe_utf8 and safe_unicode may help if in doubt
[15:08] <calvin1602> BzrDocsRock pretends that it is 90% complete, but there is no trace of it ...
[15:10] <calvin1602> and there is a question about it on launchpad, with no answer
[15:10] <assad> james_w: http://pastebin.com/d33d8e510
[15:10] <james_w> calvin1602: I don't know of any, sorry
[15:11] <james_w> assad: don't run with sudo
[15:11] <jam> assad: "Permission denied (publickey)."
[15:11] <jam> something is wrong with your ssh key when connecting
[15:11] <jam> possibly because of sudo
[15:12] <assad> james_w: http://pastebin.com/d6944f64f
[15:13] <james_w> assad: "sudo rm -r sahana"
[15:13] <james_w> then try "bzr branch ..." again
[15:13] <james_w> without sudo
[15:13] <assad> ok
[15:14] <assad> james_w: no such file or directory. cant remove 'sahana'
[15:16] <james_w> assad: perhaps the permissions on /home/user/Downloads/web2py/applications/ don't allow your user to write there
[15:17] <assad> james_w: that is why  i did the sudo bzr branch .. !
[15:17] <assad> still i wasnt able to !
[15:18] <james_w> that was because root can't access you ssh key
[15:18] <james_w> I suggest you allow your user to write to your own home folder
[15:18] <james_w> sudo chown -R user /home/user/Downloads/web2py
[15:19] <james_w> or your username if it is not in fact "user"
[15:20] <assad> james_w: its working now!!
[15:21] <james_w> nice
[15:21] <assad> thanks
[15:28] <lamont> wth does 'pretifying graph' mean, bzr-gtk?
[15:45] <vila> lamont: mostly loading the whole ancestry and building the graphical version
[15:51] <rubbs> Is their any way to remove the history of a HUGE file in a shared repo? I was dumb as a newbie and trying to backup my shared repo is slow and big because I once committed a big file, and my repo is fairly big, and I don't need that file or that history (I was playing around, dumb I know).
[15:52] <rubbs> sorry run on sentence there
[16:06] <NfNitLoop> well, as long as the file is in the history of one of your branches, and you're not doing a lightweight or stacked checkout, you need that large file in your shared repo to have a complete history.
[16:07] <NfNitLoop> if it's been a while, you could create a branch of the revision just before you added it.
[16:07] <lamont> vila: I suspect it wanted to use the (also non-word) 'prettifying"
[16:08] <NfNitLoop> then merge in all changes except the one that added that big file.
[16:08] <vila> lamont: you mean the code or the feature ? Did you try qlog instead >
[16:08] <vila> ?
[16:09] <lamont> vila: it was more that I failed totally to understand the origins/roots of 'pretify' - if it's based on 'pretty', then it needs a second 't'
[16:10] <lamont> this is in the messages spit out in 'bzr visualise'
[16:10] <vila> lamont: oooook, I can fix that:)
[16:11] <lamont> just wasn't sure if I was missing some new tech term, or if it was a bug
[16:12] <rubbs> NfNitLoop: I was afraid of that. Ok no biggie. I'll just deal with it.
[16:13] <vila> lamont: hehe, many non-native english speakers have contributed here, thanks for helping them :)
[16:14] <lamont> I speak 'merican, not English :-D
[16:14] <vila> merican girls are pretty too so that should be good ;)
[16:14] <rubbs> NfNitLoop: the merge idea is nice, but i have 3 or for more branches that were created after my mistake, and are still in on going development, so I'm just going to deal with it for a while. I might take your suggestion and do the merge later
[16:14] <lamont> vila: I'm not supposed to notice, other than my wife
[16:15] <vila> lamont: looking is not the same as touching, I have full permissions to look :)
[16:15] <lamont> heh
[16:16] <rubbs> lamont: my fiancee said this to me : "Just because I'm on a diet, doesn't mean I can't look at the menu." Of course when I look at the menu, I get in trouble ;)
[16:16] <vila> lamont: How can you still compliment here if you can't compare... There is a lot of good reasons to keep looking :)
[16:16] <rubbs> vila: haha good one.
[16:17] <vila> rubbs: here is a even worse: Just because I have lots of good bottles in my basement doesn't mean I can't have a beer at the bar...
[16:17] <vila> This one is really horrible because she just can't deny it :)
[16:18] <rubbs> I don't think that'd go over well, but it is pretty funny
[16:19] <vila> rubbs: of course that don't go, that's why it's horrible: if accepted it covers far more than just looking :)
[16:21] <rubbs> vila: true enough.
[16:25] <assad> james_w: bzr was working but after some time i got this error:   bzr branch lp:~flavour/sahana/sahanapy-trunk sahanabzr: ERROR: [Errno 13] Permission denied
[16:28] <james_w> you must still have strange permissions on your local disk
[16:28] <assad> james_w: should i work with root?
[16:34] <james_w> assad: you shouldn't need to
[16:36] <assad> james_w: bzr does work for some time "fetching revision: inserting streams" after which i get the error!!
[16:37] <pindonga> hi. I am trying to branch a project from launchpad, but I am behind a squid proxy and a firewall that block ssh access... is there any way I can branch the project?
[16:37] <cody-somerville> pindonga, http
[16:37] <pindonga> I tried, but I keep getting errors
[16:38] <pindonga> bzr branch https://code.launchpad.net/...
[16:38] <pindonga> and I get bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)
[16:39] <cody-somerville> bazaar.launchpad.net
[16:43] <pindonga> cody-somerville: how can I find out the correct url for my project?
[16:43] <pindonga> using bazaar.launchpad.net?
[16:49] <jam> pindonga: generally it is "http://bazaar.launchpad.net/~user/project/branch"
[16:49] <jam> https generally redirects
[16:49] <jam> but as it is https you may encounter different issues, versus going straight to the target.
[16:51] <pindonga> jam, indeed, I am getting some issues, if I do bzr branch https://bazaar.launchpad.net/~ricardokirkner/lalita/sentry I get 'Not a branch', if I do branch bzr+https I get 'Generic bzr smart protocol error: Invalid http response for [...] Unable to handle http code 404: Not found'
[16:52] <jam> there is no bzr+https on that location
[16:52] <jam> neither https
[16:52] <jam> just "http"
[16:52] <jam> http://bazaar.launchpad.net/~ricardokirkner/lalita/sentry
[16:53] <jam> this seems to work for me: bzr branch http://bazaar.launchpad.net/~ricardokirkner/lalita/sentry
[16:53] <pindonga> jam, yes, you are right
[16:53] <pindonga> thx
[16:54] <pindonga> now, if I want to push stuff, do I have to do that through http?
[16:54] <pindonga> is there no support for https?
[16:54] <beuno> pindonga, just use lp:~ricardokirkner/lalita/sentry
[16:54] <beuno> make sure you've specified your launchpad-login
[16:54] <pindonga> beuno, I cannot . I am behind an http proxy and firewall that blocks ssh
[16:54] <beuno> and that your ssh key is up on launchpad
[16:55] <beuno> pindonga, ssh or sftp are the only ways of pushing up data
[16:55] <pindonga> beuno, do you know where I can read about this? (I mean the underlying reasons for not supporting anything besides ssh/sftp)
[16:56] <beuno> pindonga, I don't think there is anything documented
[16:56] <beuno> I also don't know of any other services that let you write through http
[16:56] <pindonga> no, that's why https would be good
[16:57] <beuno> pindonga, http and https would be almost the same to support really
[16:59] <pindonga> I know of two services that let you write through https: googlecode and bitbucket :-)
[17:00] <pindonga> is there anything that can be done to support https directly?
[17:00] <beuno> pindonga, you can try bringing up the topic on the launchpad-dev mailing list
[17:01] <beuno> but considering there isn't a bzr smart server for http, and the cost of developing and maintaining an extra moving part, it seems unlikely to happen
[17:02] <pindonga> ok, thx
[17:45] <saedelaere> hi
[17:51] <saedelaere> i have a little project and started to use bazaar recently. this is my first version control system so I'am quite inexperienced.
[17:51] <saedelaere> now, i want to release a new stable release of my software. after that i want to start with the next development branch.
[17:51] <saedelaere>  the problem is what happens if there are bugs in the stable release. i would need to make an update for this version. do i need to start a new branch after releasing my stable version?
[17:51] <beuno> saedelaere, there are many different ways of handling these things
[17:52] <beuno> one way would be to always have a "trunk"
[17:52] <beuno> trunk is where you develop
[17:52] <beuno> when you release, you branch off, and keep that separate
[17:52] <beuno> any updates you need to do to the release, you do on the release branch
[17:55] <saedelaere> ok i started, with bazaar using one of the tutorials on the homepage. in fact i'am working alone on this project if this important. so what would i need to do now?
[17:56] <saedelaere> this is the output of [bzr info]
[17:56] <saedelaere> http://pastebin.org/63172
[17:58]  * beuno looks
[17:58] <beuno> saedelaere, you are ready to release?
[18:00] <saedelaere> ups sry pidgin crashed
[18:02] <saedelaere> beuno: no I'am not ready now :) i hope next week. i just wanted to ask now to be able to start right away.
[18:02] <saedelaere> is it complicated`
[18:09] <saedelaere> beuno still here? :)
[18:33] <saedelaere> so is it correct to go to my working directory.
[18:33] <saedelaere> bzr branch bzr://tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer tv-viewer.081
[18:33] <saedelaere> this creates a new directory tv-viewer.081 correct?
[18:33] <saedelaere> now i could work on this branch if there are any bugs and even push them back to sourceforge. so this will also create a new directory there?!
[18:33] <saedelaere> omg i'am unsure and don't want to mess it up
[18:43] <saedelaere> ok just played around with it in virtualbox. it created a new directory as i supposed. should i add this directory now to ignore files?
[18:51] <meuserj> At some point an upgrade cause the following error to happen on most of my branches in a shared repository:
[18:51] <meuserj> http://pastebin.com/d48d63a40
[19:09] <Typh> what's the best practice for moving a versioned directory somewhere else within the project
[19:09] <gutworth> bzr mv
[19:10] <Typh> I tried that but it complains the destination was unversioned. Of course it's unversioned, it doesn't exist yet
[19:11] <Typh> or should I create the required dirs, add them, then bzr mv the files
[19:12] <gutworth> add it then
[19:12] <rubbs> Typh: you could try to move them with mv and then do a bzr mv
[19:12] <rubbs> read : bzr help mv
[19:13] <rubbs> it says that if the old file exists only in the versioning and not on the fs, and the new name is on the fs but not versioned, it will assume you moved to the new location
[19:13] <Typh> so it does. shame on me :)
[19:16] <rubbs> Typh: np. it happens, I didn't know until I looked
[19:52] <NfNitLoop> Hrmm, reading 'bzr help branch' and --hardlink supposedly "Hard-link[s] working-tree files where possible."
[19:53] <NfNitLoop> working tree files!?   so if I change something in one branch it updates the other?
[19:53] <NfNitLoop> That seems wrong.
[19:59] <gutworth> NfNitLoop: hard links are not like symbolic links
[20:19] <fullermd> NfNitLoop: Well, theoretically you'd only use it with an edit{or,ing method} that breaks the link...
[20:20] <NfNitLoop> gutworth: I know hard links aren't like symbolic links, but with hard links you have two filenames pointing to the same content.
[20:20] <fullermd> saedelaere: Ignore file?  Maybe I mis-skimmed what you're trying to do, but I don't see how that would fit in...
[20:20] <NfNitLoop> fullermd: ah, I didn't know there were editors that did that.
[20:21] <NfNitLoop> does bzr hardlink its pack files / revisions?
[20:21] <fullermd> No.
[20:21] <fullermd> Seems to me somebody hacked up a patch to do it once, but it's just an unpleasant idea all 'round.
[20:21] <fullermd> (of course, so's linking the working tree, but...)
[20:24] <meuserj> ok.. still can't figure out my problem.. but I get a bit more info from bzr info:
[20:24] <meuserj> http://pastebin.com/d3202ab9d
[20:25] <fullermd> What happens if you run check on the repo?
[20:34] <meuserj> fullermd: on each branch which I'm having a problem with, I get this error:
[20:34] <fullermd> No, not on the branch.  Just the repo.
[20:35] <fullermd> I suspect the problem is a mismatch; not that something back in the ancestry went off somewhere, but that the branch is pointing at a head that's not in the repo.
[20:35] <fullermd> I can think of various ways to make that happen, but they mostly involve sneaky manual poking around behind bzr's back.
[20:37] <meuserj> found error:Internal check failed: revno does not match len(mainline) <some integer> != -1
[20:37] <meuserj> err..
[20:37] <meuserj> found error:Internal check failed: revno does not match len(mainline) integer != -1
[20:37] <meuserj> and "integer" is some integer which seems to be different for every branch
[20:37] <fullermd> That's expected if they're pointing at things not in the repo.
[20:37] <meuserj> fullermd: I get those branch errors when I run check on the repo
[20:37] <fullermd> Do an info -v on JUST the repository.
[20:38] <meuserj> http://pastebin.com/d334cc377
[20:39] <fullermd> OK, so it's not empty.
[20:39] <fullermd> But it doesn't have any of the revs the branches are pointing at.
[20:39] <fullermd> I don't know how you'd provoke that, short of manually moving stuff across the repo boundary.
[20:40] <meuserj> so, how do I fix it?
[20:40] <fullermd> Well, how'd you cause it?   8-}
[20:41] <meuserj> I didn't.. this is happing on branches which haven't had any activity for months, and have never been moved around.
[20:41] <meuserj> err happening
[20:42] <fullermd> Maybe you made an interposing repository somewhere along the line?
[20:42] <meuserj> interposing repository?
[20:43] <fullermd> e.g., you have all these branches in /var/projects/{a,b,c}, which are using a repo in /var.
[20:43] <fullermd> You make a new repo in /var/projects/
[20:43] <meuserj> no
[20:43] <fullermd> That hijacks the search, so it never finds or checks the repo in /var that actually has the revs.
[20:43] <meuserj> everything has been in /var/projects since we created the repository years ago.
[20:45] <fullermd> Mmm.  You mentioned an upgrade.  Is that recent?
[20:46] <meuserj> for some of the branches I've been able to recover things by finding a separate up-to-date branch, and pushing + overwriting the branch in the central repo.. but I may not be able to find branches for older code...
[20:46] <meuserj> well, I upgraded to 2.0 a few months ago.. I typically keep up to date with BZR
[20:46] <meuserj> and upgrade the repository and branch formats.. since you have to
[20:47] <fullermd> Maybe those branches that are having errors were (for whatever reason) not using the repo before, and something in the upgrade errored before updating their in-branch repos.
[20:47] <fullermd> You sure the upgrades completed successfully?
[20:49] <meuserj> I believe so
[20:49] <meuserj> I would have looked at it then if I had errors
[20:49] <fullermd> Are the backup.bzr/ dirs still around?
[20:49] <meuserj> yeah
[20:49] <fullermd> Or are they backup_bzr?  Something like that...
[20:49] <fullermd> Ah, good.
[20:50] <fullermd> See if any of them have a repository/ directory in them, and the current .bzr/ doesn't.
[20:54] <meuserj> nope... a few have a repository directory in both
[20:57] <Peng> fullermd: backup.bzr
[21:00] <fullermd> If you do an 'info' on those that have it in both, do they show up as standalone, or are they still trying to use the shared repo?
[21:00] <fullermd> (and is there any correlation to those that are erroring?)
[21:02] <meuserj> Standalone, and no correlation
[21:03] <fullermd> Grr.  I'm going to give you another opportunity to change your answer   :)
[21:03] <fullermd> Anything interesting in the backup.bzr/'s of the branches having issues?
[21:04] <fullermd> Is the listed head rev the same, frex?  (don't know why it wouldn't be, but...)
[21:04] <meuserj> let me get a list of ones I know there are problems with and see if I can find some common ground.. hold on.
[21:16]  * meuserj sighs
[21:16] <meuserj> I hae 28 good branches and 34 bad ones
[21:16] <meuserj> I have more that are erroring than are good.. that's not good...
[21:17] <fullermd> Well, it could be good.
[21:17] <fullermd> If it were just 1 branch going all stupid, you could chalk it up to the branch or repo being skr00d somehow.
[21:18] <fullermd> With a bunch erroring in apparently the same way, it sounds more like some particular (and possibly reversable) problem.
[21:18] <fullermd> It really sounds most like the repository the branches were using when last used isn't the same as the one currently sitting there.
[21:18] <fullermd> You have the backup.bzr from that?
[21:19] <fullermd> You could try restoring that in another place, and mv/cp'ing one of the failing branches into it, and see if that changes things.
[21:19] <meuserj> no, but I have a backup of the repository dir.
[21:25] <meuserj> bzr info -v for the good branches: http://pastebin.com/d23c5b6c6
[21:26] <meuserj> bzr info -v for the bad branches: http://pastebin.com/d7b70627c
[21:27] <meuserj> the reason there is no branch history data for any of the "bad" branches is that bzr crashes at that point.
[21:28] <meuserj> and I didn't redirect stderr
[21:28] <fullermd> Yeah, that doesn't tell anything new, it just means that it wound up asking after a revision that's not in the repo.
[21:45] <meuserj> OOoo progress..
[21:46] <NfNitLoop> oh?
[21:46] <meuserj> I copied the entire repository to anther machine to be safe and there I restored the repository.backup file, and tested one of the broken branches, and it seems to work now.
[21:46] <NfNitLoop> strange.
[21:47] <NfNitLoop> so they just didn't get updated when you updated the repo format, likely?
[21:52] <meuserj> maybe... I'll try upgrading it again.
[22:00] <meuserj> ok.. the branches which were erroring before, seem to work now, and some of the newer branches which worked fine before are now broken in a similar way (assumingly because they have revisions which didn't exist before the upgrade)
[22:00] <meuserj> if nothing else, I can branch off the broken projects from this working copy of the repository and push --overwrite them into the central repo...
[22:01] <meuserj> does that sound logical?
[22:10] <fullermd> Yeah, that should work.  Or go the other way; make a tmp branch in the new repo, and successively pull --overwrite all the broken ones from the old repo.
[22:11] <fullermd> Doesn't answer much about how it got broken in the first place; upgrade shouldn't (doesn't, AFAI've ever seen) throw away revs.
[22:11] <fullermd> But it'll get you working.  You could try experimenting with redoing an upgrade on the copy of the backup, and see if it comes up again.
[22:12] <meuserj> fullermd: yeah.. my priority of course at the moment is recovering everything I can.
[22:50] <igc> morning
[23:22] <poolie> hi all
[23:22] <lifeless> hai
[23:27] <james_w> morning poolie and lifeless
[23:28] <poolie> hi there
[23:32] <jelmer> hi poolie, lifeless, james_w
[23:32] <lifeless> hi, bye ;)
[23:35] <poolie> i'm going to be offline a bit today
[23:36] <poolie> so if anyone wants to talk... do it now
[23:40] <spiv> Maybe we like talking to ourselves ;)
[23:47] <igc> hi lifeless, spiv, jelmer, james_w
[23:48] <james_w> morning people of the future
[23:51] <spiv> james_w: I may be from the future, but I'm not a morning person!
[23:53] <james_w> heh