[00:07] <spiv> It's not special, but IIRC it was the proposed convention
[00:19] <jelmer> Noldorin: lp:bzr-git and lp:dulwich
[00:19] <Noldorin> jelmer, hmm?
[00:20] <jelmer> Noldorin: rmbranch support
[00:20] <Noldorin> jelmer, oh, update both of them eh?
[00:21] <jelmer> yep
[00:21] <Noldorin> okay :-)
[00:29] <Noldorin> jelmer, weird. now i get accessed denied every time i pull
[00:29] <Noldorin> try to pull dulwich
[00:29] <Noldorin> bzr: ERROR: [Error 5] Access is denied: 'c:\\users\\alex\\appdata\\local\\temp\\tmp5trcyz.pag'
[00:33] <jelmer> Noldorin: no idea..
[00:33] <Noldorin> https://bugs.launchpad.net/bzr/+bug/820805
[00:33] <Noldorin> known bug
[00:34] <Noldorin> jelmer, how's work on the other bugs going?
[00:44] <Noldorin> ERROR: Repository not found.
[00:44] <Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
[00:44] <Noldorin> jelmer, now i get that error when dpsushing ^
[00:50] <jelmer> Noldorin: typo in your repository URL?
[00:51] <Noldorin> sorry it was
[00:51] <Noldorin> forgot to change : to / this time
[00:51] <Noldorin> jelmer, thanks, that works now :-)
[00:52] <Noldorin> jelmer, how close are we to fixing the bug with directory processing order?
[00:53] <jelmer> Noldorin: Sorry, I've got lots of bugs in progress and this is just one of them (and a harder one at that)
[00:53] <jelmer> Noldorin: I'll update the bug report
[00:53] <Noldorin> no prob
[00:53] <Noldorin> jelmer, i was just under the impression you had already re-written that function yesterday?
[00:53] <Noldorin> or at least you know
[00:55] <jelmer> Noldorin: well, I looked at that a bit but that's a nontrivial amount of work.
[00:56] <Noldorin> jelmer, ok sure. well if you update the bug report, maybe i can try..?
[00:56] <Noldorin> hrrm, rmbranch still gives:  Unable to write to standard output: The pipe is being closed.
[00:57] <jelmer> Noldorin: not sure I follow, update it how?
[00:58] <Noldorin> jelmer, add a comment explaining how it need to be fixed? :-P
[00:58] <jelmer> Noldorin: it's not as easy to describe as that, I'm going to make some pretty rigorous changes to it. You're welcome to have a stab at it though.
[01:00] <Noldorin> jelmer, ahh fair enough
[01:00] <Noldorin> jelmer, well, i have time so, so if you update the bug report then i can try... no promises though ;-)
[01:00] <Noldorin> jelmer, maybe this 'Unable to write to standard output' issue is simpler though?
[01:02] <jelmer> Noldorin: basically, I'm hoping to gather the changed blobs first and then update the affected trees.
[01:02] <jelmer> Noldorin: WHen are you getting that last error?
[01:03] <Noldorin> jelmer, during rmbranch i said...
[01:03] <jelmer> Noldorin: no idea about that, it sounds like an issue with ssh
[01:04] <Noldorin> jelmer, yeah
[01:04] <Noldorin> jelmer, only happens during rmbranch though
[01:27] <Noldorin> jelmer, well i get this: NotBranchError: Not a branch: "git+ssh://git@github.com/alexreg/ircdotnet.git,branch=foo1".
[01:27] <Noldorin> in .bzr.log
[01:28] <jelmer> Noldorin: that's correct, there is no such branch
[01:28] <Noldorin> jelmer, oh lol, i already removed it
[01:30] <Noldorin> jelmer, so actually, rmbranch behaves correctly in all cases now.... it just gives an error *even* when it succeeds
[01:30] <Noldorin> that being Unable to write to standard output: The pipe is being closed.
[01:30] <Noldorin> jelmer, .bzr.log contains this: http://pastebin.com/uzeF34tE
[01:31] <jelmer> Noldorin: that's windows specific I'm afraid
[01:31] <Noldorin> yeah
[01:31] <Noldorin> makes sense
[01:31] <Noldorin> jelmer, do you know the exact cause though...any way around it?
[01:31] <Noldorin> jelmer, it may me windows-specific, but it's still a ""bug""
[01:38] <poolie> good morning
[01:48] <Noldorin> jelmer, i am probably done for today, but if you could fill in the info on the LP bug about directory renames, would be cool :-)
[01:48] <Noldorin> jelmer, the Windows SSH issue....no idea! should be trivial though
[02:00] <Noldorin> g'night
[02:12] <Kamping_Kaiser> is it possible to have bzr ignore a particular sub directory so i can version it independently?
[02:12] <poolie> yes
[02:13] <Kamping_Kaiser> in my case /etc/ is maintained by bzr, and i'd like /etc/cfengine/ to be a seperate repo
[02:13] <poolie> just ignore it, and don't add it
[02:13] <poolie> that's fine
[02:13] <Kamping_Kaiser> fab, thanks poolie
[06:07] <Guest2952> I currently have a shelved change, which I cannot access (bzr unshelve crashes). If I manually fiddle the change out of .bzr/checkout/shelf/shelf-1, do I have to keep anything in mind to avoid corrupting the repository? How do I then get rid of the broken shelf? Just delete .bzr/checkout/shelf/shelf-1?
[06:08] <poolie> i think that's enough
[06:08] <poolie> it won't damage the repositoyr
[06:08] <poolie> please file a bug about the crash, if you haven't already
[06:08] <vila> hi all !
[06:08] <poolie> hi there vila
[06:11] <Guest2952> Thanks poolie. Here is the bug report, for reference: https://bugs.launchpad.net/bzr/+bug/850594
[06:11] <poolie> oh, ok, i think i saw that before
[06:11] <poolie> thanks
[06:14] <Guest2952> on a related note, what is the recommended workflow to get new files in new directories committed separately from their directories?
[06:16] <vila> Guest2952: you can't do that, bzr tracks trees, a file is always part of a tree
[06:22] <Guest2952> so my "bug" isn't really a bug? Just a misunderstanding on my part of how bzr works?
[06:22] <poolie> well, it should never crash
[06:22] <poolie> you should never get a traceback whatever you do ,that's always a bug
[06:23]  * vila nods
[06:23] <poolie> vila, i think he's asking for the opposite
[06:23] <poolie> he/she
[06:23] <poolie> which is to commit the addition of the directory but not the addition of the files within it?
[06:23] <vila> ooooh
[06:23] <poolie> given that shelving apparently doesn't handle this
[06:23] <Guest2952> yes, what poolie said
[06:23] <vila> 'bzr version' ?
[06:24] <poolie> i would recommend doing 'bzr rm --keep dir/newfile'
[06:24] <vila> 2.4.0, sry
[06:24] <poolie> which will unversion it
[06:24] <poolie> then commit the directory addition
[06:24] <Guest2952> Bazaar (bzr) 2.4.1
[06:24] <Guest2952>   Python interpreter: /usr/bin/python 2.6.5
[06:24] <Guest2952>   Python standard library: /usr/lib/python2.6
[06:24] <Guest2952>   Platform: Linux-2.6.32-33-generic-i686-with-Ubuntu-10.04-lucid
[06:24] <poolie> or use 'bzr add --no-recurse' in the first place
[06:25] <vila> Guest2952: you're not the first asking for committing new dirs first in one commit and new file later, I don't completely understand the use case, can you elaborate ?
[06:25] <poolie> we ought to add a 'commit --no-recurse' too
[06:27] <vila> Guest2952: some background: we try to make directory tracking as transparent as possible so dirs are added when needed (i.e. if you add a file and its directory is not yet tracked, it's added automatically)
[06:27] <vila> poolie: so we can commit a dir without its content ?
[06:29] <vila> poolie: so, I did some prodding of the package importer and found some interesting stuff:
[06:29] <vila> Trying to reproduce some failures with 2.4.1 failed (so deploying 2.4 on jubany is more important than ever)
[06:30] <Guest2952> For example, my project starts out small, and I only use a single test file for my testing. At some point it grows to the point, where I want to use a more elaborate testing framework, which requires a complex directory setup mapping my test files 1:1 to the tested modules. So I want to commit "setting up the dir structure to support the testing framework" as a separate commit to the actual "implement test foo" commit.
[06:30] <vila> requeuing with --full fixed several DivergedBranches failures too (but not all, a bit ruining the web page regarding the history of the last failures, no big deal but if you track it you may be surprised)
[06:32] <vila> Guest2952: right, I just did the same yesterday evening and I committed the new file and its associated test file which triggered committing the dir containing them, but I see your point
[06:34] <Guest2952> having the directory setup commit separate from the file implementation commit means I can later reject the "implement foo test" without breaking "implement bar test" and "implement quux test"
[06:34] <vila> Guest2952: waiting for the 'commit --no-recurse' poolie just mentioned, the only workaround I can think of is to commit an *empty* dir (after all, that's what bzr will create if you ask for this revisions to be checked out from scratch)
[06:35] <vila> Guest2952: ha ! I see even better with that !
[06:36] <Guest2952> that's what I thought, so I shelved the file, and committed the empty dir, but now bzr won't let me unshelve the file again
[06:37] <vila> poolie: so, toying with requeue --full, lead to think that we should make sure import_package can always be retried from scratch (I think we're pretty close to that already but if it's guaranteed, it will simplify the way we think about it)
[06:38] <vila> Guest2952: hmm, can you add that on the bug report ? It's probably a key fact to reproduce the issue
[06:39] <Guest2952> which part?
[06:39] <Guest2952> the steps I list in the report reproduce it
[06:39]  * vila re-reads
[06:40] <vila> oh yeah, perfect (sorry, I jumped to the backtrace at first read)
[06:46] <poolie> jelmer, hi?
[06:49] <vila> poolie: I also noticed some packages are retried more than others (lxc, lillypond among others), I suspect some cruft in JOB_TABLE or something, not sure yet
[06:50] <vila> it's more obvious when using analyze_log from a tail -F process_log as most imports are processed in lexical order and those aliens pop up in-between
[06:51] <Guest2952> ok, I'm happy to change/add/clarify/test anything that might help resolve it. For now, I'll just manually extract the shelf, and be more deliberate about my directories in future. Until bzr (at some point possibly) supports my use case, it would be nice, from a user perspective, if bzr would refuse to let me shelve things that I won't later be able to unshelve. It's a big break of trust when your change-manager gobbles up your change :)
[06:51] <vila> lxc just popped up again
[06:51] <vila> and apt-daemon and linux-firmware,
[06:52] <vila> not an issue in itself, this breaks nothing, but the cumulated effect on the time to try all imports is increased for no good reason
[06:52] <poolie> huh, ok
[06:52] <poolie> that's interesting
[06:52] <poolie> i don't know off hand what order it uses
[06:53] <vila> I thought it was all controlled by mass_import (JOB_TABLE, then packages) but I discovered that categorize_failures trigger some imports
[06:54] <vila> i.e. each time the web page is refreshed, we requeue some packages, that may be it, I need to check
[06:59] <vila> and lxc again
[07:01] <vila> and landscape-client, the pattern is a bit hard to grasp (the timing vary depending on which imports are in flight but that's roughly every 5 minutes)
[07:02] <vila> hmm, the crontab also runs add_import_jobs but I think this one is for tracking lp)
[07:04] <vila> It's nice to see people from all over the world trying to hack my desktop, but guys, fail2ban makes your brute-force attempts a bit futile, please find another target ;)
[07:12] <bignose> vila: sadly, the computers actually attacking are likely not doing so with the knowledge of their owners
[07:13] <bignose> but rather are under the control of a small number of individuals, who control them en masse to attack indiscriminately
[07:13] <vila> bignose: Oh, I'm sure about that :)
[07:15] <vila> similar attacks coming from russia, china, brazil, france and so on, clearly indicates puppets
[07:46] <jam> morning all
[08:04] <poolie> hi jam, bignose
[08:09] <Riddell> morning
[08:36] <poolie> hi riddell,
[10:19] <poolie> jam, would you mind doing a quick rereview of https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 ?
[10:21] <jam> poolie: certainly. It will be a little bit, getting lunch now, then I have to read in the conversation again. But it will be done by your tomorrow
[10:21] <poolie> thanks very much
[10:21] <poolie> wallyworld offered to land it but he wants some reassurance
[11:11] <AfC> What's the git equivalent of `bzr revert`?
[11:11] <AfC> [I know, I know, don't ask; having just established this project is at all viable I'm going to bzr import it now]
[11:16] <vila> AfC: 'git  help stash' ?
[11:16] <vila> AfC: no guarantee
[11:18] <AfC> vila: found it; `git checkout .` or `git checkout filename` apparently.
[11:18] <vila> AfC: or git reset ?
[11:18] <AfC> Turns out `git revert` ≃ `bzr uncommit`
[11:18] <AfC> !
[11:19] <vila> ouch
[13:11] <Riddell> jelmer: when you were asking about translating plugins did you have any one in mind?
[13:25] <jelmer> Riddell: not specifically. the most interesting plugins for this are the ones that have some public-facing bits, e.g. because they add a command or raise some custom exceptions
[13:26] <jelmer> Riddell: bzr-rewrite, bzr-svn or bzrtools might be a good candidate if you're looking for an example
[13:45] <jelmer> Noldorin: hi
[13:45] <Noldorin> hi jelmer
[13:45] <jelmer> Noldorin: I've added some comments to the dpush rename bug
[13:45] <Noldorin> yes i saw just before i went to bed :-)
[13:45] <jelmer> Noldorin: not sure about the windows rmbranch issue
[13:46] <Noldorin> jelmer, the error has appeared before in other contexts. some difference with the way plink and openssh work?
[13:50] <Noldorin> jelmer, where is rmbranch in the code? maybe i can take a look
[13:51] <jelmer> Noldorin: dulwich/client.py in the dulwich code
[13:52] <Noldorin> ta
[14:03] <Noldorin> jelmer, specifically within that file? sorry, i see no mention of removing branches
[14:06] <jelmer> Noldorin: removing branches is done by updating the refs of the remote repository and excluding the ref you want to remove
[14:06] <jelmer> Noldorin: this gets called by destroy_branch() in remote.py in bzr-git
[14:18] <Noldorin> ah ok
[14:18] <Noldorin> makes sense!
[14:52] <Noldorin> jelmer, i presume it's using TraditionalGitClient here?
[15:17] <Wiz_KeeD> hello everyone
[15:17] <Wiz_KeeD> how's everybody feeling?
[15:17] <Wiz_KeeD> can anyone give me a hand with configuring bzr?
[15:20] <jelmer> Wiz_KeeD: hi
[15:20] <Wiz_KeeD> hello jelmer
[15:21] <LeoNerd> configuring?
[15:22] <Wiz_KeeD> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Registering_the_key_with_Launchpad
[15:22] <Wiz_KeeD> trying to follow this guide so i can download and install aeroolib
[15:22] <Wiz_KeeD> to build aeroo reports in openerp, i can see the ssh key in the file (don't know if i generated it well_
[15:23] <jelmer> Wiz_KeeD: you should be able to download branches from launchpad without setting up ssh
[15:23] <Wiz_KeeD> yeah i did that buuut...
[15:23] <jelmer> wiz_keed: just through http
[15:23] <Wiz_KeeD> i don't know how to install aeroolib
[15:23] <Wiz_KeeD> and if i do
[15:24] <Wiz_KeeD> ImportError: No module named setuptools
[15:24] <Wiz_KeeD> that when executing python setup.py install
[15:33] <Riddell> why does this small change to bzr-rewrite prevent me from running the bzr rebase command?  http://bazaar.launchpad.net/~jr/bzr-rewrite/broken-import/revision/239?start_revid=239
[15:35] <vila> Riddell: <whistles> a plugin is imported specially under the bzrlib.plugins namespace, I have *no* idea what import __init__ will do there
[15:36] <vila> Riddell: there may be some info in .bzr.log, otherwise, try adding a pdb.set_trace() before this import
[15:37] <vila> well, 'import pdb; pdb.set_trace()' that is
[15:37] <Riddell> ah, using from bzrlib.import.rewrite  works
[15:38]  * vila nods (fixing the tyop on the fly ;)
[16:08] <timrc> The context of file system storage, is there a way to "stack" a branch on top of an existing branch? It seems to me like a "stacked" branch in bzr cannot share a file system location with its parent?
[16:08] <timrc> In the context^
[16:08] <timrc> I guess I'm expecting something akin to quilt
[16:29] <Noldorin> jelmer, hey
[16:30] <Noldorin> jelmer, the .pag issue btw is a problem with Pageant... when you run it in admin mode
[16:30] <Noldorin> nothing wrong with bzr of course
[16:33] <jelmer> Noldorin: hi
[16:34] <jelmer> Noldorin: ah, interesting. any chance you can add a comment to the bug about that?
[16:35] <Noldorin> jelmer, the old bug submitted by someone else?
[16:36] <jelmer> Noldorin: yeah
[16:36] <Noldorin> https://bugs.launchpad.net/bzr/+bug/820805
[16:36] <Noldorin> i think
[16:36] <Noldorin> jelmer, sure will do
[16:38] <Noldorin> done
[16:38] <Noldorin> jelmer, btw should i be concerned with HttpGitBranch or TraditionalGitBranch in dulwich?
[16:41] <jelmer> Noldorin: ? I don't think there is anything by those names
[16:42] <Noldorin> jelmer, sorry, s/Branch/Client
[16:43] <jelmer> Noldorin: TraditionalGitClient for SSH (you'll see SSHGitClient derives from that)
[16:43] <Noldorin> ah ok
[16:43] <Noldorin> didn't notice that, makes sense now!
[16:46] <Noldorin> jelmer, this "Unable to write to standard output" bug is interesting, since i don't get the message until *after* bzr has terminated it seems
[16:46] <Noldorin> jelmer, that is, i get the command prompt again first
[16:47] <Noldorin> it's asynchronous i'm guessing...
[16:51] <Noldorin> jelmer, the send_pack function in dulwich never returns
[16:52] <jelmer> Noldorin: it's not asynchronous
[16:53] <Noldorin> jelmer, well Plink is doing something strange anyway
[16:53] <Noldorin> jelmer, and the send_pack function definitely throws an error
[16:54] <Noldorin> specifically, i get:
[16:54] <Noldorin> bzr: ERROR: exceptions.UnboundLocalError: local variable 'new_refs' referenced before assignment
[16:56] <Noldorin> err, my bad sorry
[17:01] <Noldorin> jelmer, basically the dulwich client needs to handle the remote SSH host hanging up unexpectedly...in a more graceful way
[17:03] <jelmer> Noldorin: the server shouldn't be hanging up unexpectedly
[17:04] <jelmer> Noldorin: it should confirm the refs have been changed
[17:04] <Noldorin> jelmer, shouldn't, but is
[17:04] <Noldorin> hmm
[17:04] <Noldorin> jelmer, when you try to delete a branch that does not exist it does
[17:10] <Noldorin> jelmer, by the way, i read your comments. it looks complicated to fix the rename-related bug :-P i might leave it to you
[17:24] <Noldorin> jelmer, withouy being too pushy...any idea when you might be able to submit that fix? :-)
[17:44] <jelmer> Noldorin: again, please see the bug report
[18:13] <Noldorin> jelmer, with regards to? :P don't think it contains any answer to any questions i'e asked
[18:27] <jelmer> Noldorin: the bug report will automatically be updated as soon as there is a branch that addresses the bug
[18:28] <jelmer> Noldorin: which questions?
[18:28] <Noldorin> jelmer, i know... i was just specifically asking for estimates...because i'm a very impatient guy :-P
[18:28] <jelmer> Noldorin: I have no idea, I work on this in my spare time and that's pretty unpredictable. I could be days or weeks.
[18:28] <Noldorin> jelmer, ohh i see. sorry, i thought bzr-git was part of your job
[18:28] <Noldorin> jelmer, only core bzr i guess
[18:31] <jelmer> Noldorin: well, it's not as black and white as that, but this bug isn't particularly high priority
[18:31] <Noldorin> jelmer, well, just for me it is ;-)
[18:31] <Noldorin> very high priority for me
[18:31] <Noldorin> but in general, fair enough...
[18:45] <Noldorin> jelmer, okay, as long as these two items are on your task list, i'll just leave them with you
[18:46] <Noldorin> jelmer, thanks so far...feel free to contact me over the next week, though i'll try not to pester you :-)
[18:46] <Noldorin> ta
[18:46] <jelmer> Noldorin: thanks, I'll update the bug reports when I have more
[18:46] <Noldorin> jelmer, cheers.
[18:47] <Noldorin> jelmer, if you like i can submit a quick report on the 'Unexpecte pipe close' issue too
[18:47] <Noldorin> and then leave you to tackle those 2 issues in your own time
[18:47] <jelmer> Noldorin: Sure, I do want to help out getting this bug fixed
[20:17] <Noldorin> jelmer, https://bugs.launchpad.net/bzr-git/+bug/856769 -- there you go
[20:17] <Noldorin> jelmer, two fun bugs to work on :-) good luck, and i look forward to testing the fixes!
[23:58] <poolie> hi all
[23:59] <jelmer> hi poolie