[00:00] <dub> sorry I dont have time
[00:03] <dub> I'll bypass it and let the user log one if they feel the need
[00:04] <dub> might I suggest that you dont use tcp/80 if you're not doing http and if you are use expires
[00:13] <lifeless> dub: we're doing HTTP
[00:14] <lifeless> dub: and expires is orthogonal to the issue @ hand; VCS data doesn't have a strict semantic value for expires
[00:14] <lifeless> expires wouldn't help us at all
[00:15] <dub> expires is the only way to reliably prevent caching
[00:15] <dub> in my limited experience anyway
[00:17] <lifeless> dub: no-cache does it fine
[00:18] <lifeless> we don't care if caches cache, we cache bust. We have to because there are folk that run caches that don't conform to the rfc's
[00:18] <dub> if you say so. yet you seem to have an application that causes caching issues
[00:18] <lifeless> no
[00:18] <lifeless> failing to process specific http messages != caching issue
[00:18] <dub> we cache several gbps and I dont know of other problem apps
[00:18] <dub> expires fixes all stale data type problems
[00:18] <lifeless> sure, but this is a proxy issue, not a caching issue
[00:19] <lifeless> I repeat, its not a stale data issue, not if it looks like rbistolfi's issue.
[00:19] <dub> regardless, i've spent enough time on this, thanks for your assistnace
[00:19] <lifeless> anytme
[00:19] <lifeless> please do encourage your user to file a bug
[00:21] <dub> will do
[00:43] <igc> morning
[00:44] <igc> hi lifeless
[00:44] <lifeless> hi igc
[01:10] <verterok> igc, lifeless: hi!
[01:11] <verterok> igc: OS X 10.4 DMG's uploaded. hopefully I'll get Leopard DMG for tomorrow (actually as soon I reboot my "work laptop" into OS X :/ )
[01:11] <igc> verterok: well done and thank you
[01:13] <verterok> igc: np
[01:17] <spm> lifeless: ref upgrading the bzr pqm chroot to hardy; any probs at your end if we stop pqm while the upgrade is done? or would you prefer a less intrusive cutover? I image it'd take an hour or two max.
[01:22] <lifeless> spm: stop it
[01:22] <spm> lifeless: ta
[01:22] <lifeless> spm: I presume you'll take a backup in case we have to roll back?
[01:23] <spm> lifeless: heh. 1st thing pjdc did - how big is the chroot vs how much space do we have :-)
[01:32] <verterok> igc: http://developer.apple.com/mac/library/DOCUMENTATION/Carbon/Conceptual/ProvidingUserAssitAppleHelp/authoring_help/authoring_help_book.html#//apple_ref/doc/uid/TP30000903-CH206-CIHEAADH
[01:33] <verterok> igc: ^ there is a description of the layout/format required by the Mac Help viewer
[02:02] <jrwren> dash: thanks! I'll bet uncommit is how I got multiple heads.
[02:04] <spm> lifeless: the upgrade is done. Can you fire in a trivial request so we can verify how much we've broken?
[02:11] <robert_ancell> Can anyone tell me what is wrong with the branch lp:~ubuntu-desktop/gdm/ubuntu.  When I try and push it says the branches are diverged and when I look at https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu it says LP is processing changes for this branch
[02:13] <zsquareplusc> someone else seems to have pushed up new revisions
[02:14] <zsquareplusc> you probably need to "merge"
[02:14] <spm> robert_ancell: ahhh. that'd possibly be related to an issue we're having atm. see #launchpad.
[02:15] <robert_ancell> spm, ok, thanks
[02:21] <lifeless> spm: do we have python-subunit installed now?
[02:22] <spm> lifeless: indeed we do!
[02:25] <lifeless> ok,  I'll do something shortly
[02:26] <lifeless> lunch is begging first
[02:26] <fullermd> Ooh, what a good idea.
[02:31] <lifeless> http://paste.ubuntu.com/280891/
[02:31] <lifeless> I need someone to audit that
[02:31] <lifeless> I think its robust and clear; I'd like it to be moreso
[02:33] <spiv> lifeless: the layout and invariants section are inconsistent about saying MD5HASH vs. HASH
[02:33] <spiv> lifeless: the meaning of "There is always 1 and only one match for:
[02:33] <spiv> " and the following bullet list isn't obvious to me.
[02:34] <lifeless> I'll clean it up. the intent is that only one of the following statements is true
[02:34] <lifeless> I hope you have the spare cycles to also logic check it ;)
[02:34] <spiv> "- current" isn't a statement, though?
[02:34] <lifeless> its a file
[02:34] <lifeless> as per layout
[02:35] <lifeless> so 'there is a file called current'
[02:35] <lifeless> bbs
[02:35] <spiv> So just say that ;)
[02:37] <spiv> e.g. "There is always: - a file called 'current'; - exactly 1 file matching '*.check'; - exactly 1 file matching HASH.{current,delete}"
[02:39] <spiv> It might be worth saying upfront in the Invariants section if the intent is that this recovery will be performed automatically, or if it will need human intervention.  I'm guessing you intend automatic (I hope so :)
[02:42] <spiv> In the insert operations, it's not clear what "check if the insert should complete", and jumping ahead to the commentary still doesn't make it clear exactly what the check is, or what the check is for.
[02:45] <spiv> In read sequence, what about the (small) race between listing *.check and opening the result vs. another process renaming foo.check?
[02:45] <spiv> I assume the answer there is the same as in the next bullet; loop.
[02:45] <spiv> s/;/:/
[02:46] <spiv> What does "Closing a dirstate" mean?
[02:47] <spiv> What about multiple concurrent processes attempting recovery of the same dirstate?
[02:48] <spiv> Your markup is a bit inconsistent about using \n or \\n
[02:48] <spiv> Typo: "remaned"
[02:49] <lifeless> spiv: I intend to make automatic recovery possible, I don't intend to do so in the initial spike
[02:50] <lifeless> spiv: well, any policy that someone might implement, such as stat cache updates, policy checks, what have you
[02:50] <spiv> What happens in during insert if "mv current foo.check" fails (due to concurrent insert)?
[02:50] <lifeless> this is good - thanks
[02:50] <spiv> lifeless: so "don't write new file if stat cache has barely changed?
[02:51] <lifeless> more 'dont trash someone elses changes'
[02:51] <lifeless> its a critical section, the only time you can be sure noone else inserts (unless they invoke recovery concurrently, and that would be a mess
[02:52] <lifeless> so, listing *.check and the .check rename happening, - loop
[02:52]  * lifeless pages up and starts implementing improvements
[02:53] <spiv> "errors can be removed" probably should be "errors can be ignored"?
[02:57] <spiv> I'm not sure how "dont trash someone elses changes" fits with "check if the insert should complete".  If you got as far as the "rename current statefilename.check" succeeding, then as you say you're in the critical section, so how can there be other changes that could be inadvertently trashed?
[02:57] <spiv> Ok, read it all now.
[02:59] <spiv> In my ideal world, I think maybe there'd be some sort of formal proof, or at least exhaustive state diagram, to demonstrate that all states are unambiguous in the face of concurrency.  That would be a lot of work, though.
[03:00] <spiv> But it is just complex enough that I can't feel 100% sure that it's robust on a single read-through, although it seems plausible that it is.  (With some assumptions about what the FS guarantees, of course...)
[03:01] <spiv> (And I don't see any obvious simplifications you could make to the design.)
[03:02] <spiv> So, I worry a little about bugs in edge-cases.  I guess they are likely to have easy-to-repair consequences if they do happen.
[03:03] <lifeless> so stat cache updates
[03:03] <lifeless> say you have two writers A and B
[03:03] <lifeless> they both concurrently prepare an update
[03:03] <lifeless> A is doing a stat cache update
[03:03] <lifeless> we don't know what B is doing
[03:04] <lifeless> B wins the race on 'mv current HASH.check'
[03:04] <lifeless> and thus completes its insert first
[03:04] <lifeless> now, A has a new state file it wants to write
[03:05] <lifeless> so once A is in the critical section
[03:05] <lifeless> it can reliably see that the pointer has changed
[03:05] <spiv> Oh, so it's a check that the renamed current has the same pointer we think it has?
[03:05] <lifeless> if we care, yes
[03:05] <lifeless> a stat cache update cares that its unchanged
[03:05] <spiv> We need to care, I think, or else we risk losing semantic changes from B.
[03:05] <lifeless> a 'merge' or 'add' or whathaveyou doesn't care if the pointer changed.
[03:06] <lifeless> spiv: so there is a lockdir lock surrounding the WT still
[03:06] <lifeless> spiv: only one semantic writer is permitted.
[03:06] <spiv> Ah, ok.  That's worth mentioning briefly then :)
[03:07] <spiv> So a stat cache update cares that it's unchanged because otherwise there may be a semantic change from another process?
[03:08] <lifeless> right
[03:08] <lifeless> I'm writing prose about this at the top of the docstring
[03:08] <spiv> But an 'add' or whatever doesn't mind, because it will have first read the pointer inside the semantic lockdir write lock?
[03:08] <lifeless> no
[03:08] <lifeless> an add doesn't care because it is happy to trash stat cache updates
[03:09] <lifeless> and it knows noone else is allowed to be an 'add' concurrently.
[03:09] <spiv> That's what I meant!
[03:09] <lifeless> ok, but its not what you said :)
[03:09] <lifeless> [the old pointer value /doesn't matter/ to logicalwriters
[03:09] <spiv> It's inferring from its ownership of the semantic write lock that the only possible concurrent changes were stat cache only.
[03:09] <lifeless> yes
[03:10] <lifeless> thank you very much
[03:10] <lifeless> I'm sure it will need more polishing, but I feel its clearer now.
[03:10] <lifeless> and I'm glad you didn't find conceptual holes
[03:11] <spiv> That's ok, I know how hard it is to write precise and clear text about complex state machines :)
[03:11] <spiv> Not yet ;)
[03:11] <lifeless> with that, I'm going back to full screen editing;
[03:11] <lifeless> oh
[03:11] <lifeless> do you have anything that needs to land?
[03:11] <lifeless> spm needs a guinea pig
[03:12] <spiv> lifeless: Actually, I'm a little uncertain about how automatic recovery would interact with concurrent inserts.
[03:13] <lifeless> spiv: so, automatic recovery would want to be a logical writer - and thus hold the external lock
[03:13] <lifeless> There Can Be Only One
[03:13] <spiv> lifeless: i.e. how can a process tell "I need to do a recovery" apart from "another process is mid-insert"?  Via the semantic write-lock?
[03:13] <spiv> Ok.
[03:13] <lifeless> spiv: I think it boils down to time
[03:13] <spm> lifeless: is no rush; is more if we do it sooner vs later; but worst case we have a backup that can be failed to.
[03:13] <lifeless> the critical section should be _very fast_
[03:13] <lifeless> so waiting a second (say) and then offering would be appropriate.
[03:14] <spiv> "should" :)
[03:14] <spiv> Yeah, I think prompting the user is necessary.
[03:14] <lifeless> anyhow, as I say, I'm designing to permit, not to implement automatic recovery.
[03:14] <lifeless> like break-lock
[03:14] <spiv> I'm thinking someone will try this on sshfs over a crappy, slow link at some point :)
[03:14] <lifeless> the idea is to fail rarely, and only when the machine crashed
[03:14] <lifeless> or that FTP server we had the other week
[03:14] <spiv> Yep.
[03:14] <lifeless> the one that took up to 10 minutes to delete files
[03:15] <lifeless> There's a limit to which I'll design for that. Obviously-broken is not ok :)
[03:15] <lifeless> I think this will work well on windows.
[03:15] <lifeless> and Unix
[03:19] <lifeless> spiv: so, do you have any to-land branches?
[03:20] <spiv> lifeless: no, but apparently you do: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279
[03:21] <lifeless> blah :P
[03:21] <lifeless> no I don't
[03:21] <lifeless> thats landed
[03:22] <abentley> lifeless: you gave me a "needs fixing" on https://code.edge.launchpad.net/~abentley/bzr/fix_get_mtime/+merge/10544 but I replied that the requested fix wasn't suitable.  Could you please comment?
[03:22] <spiv> lifeless: if you review https://code.edge.launchpad.net/~spiv/bzr/paramiko-keyboard-interactive/+merge/12559 I will...
[03:22] <spiv> lifeless: (it's short)
[03:22] <lifeless> abentley: will do
[03:23] <spiv> lifeless: I can easily enough make an uncontroversial branch that removes some unused import lines if you like
[03:23] <lifeless> beuno: / abentley: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279 - why is the 'change status' edit link at the far right
[03:23] <lifeless> when on e.g. +me the edit thing is beside fields
[03:23] <spiv> lifeless: it's just a matter of pointing mwhudson's pyflakes branch at practically any file in bzrlib :)
[03:23] <abentley> lifeless: rockstar misunderstood an aspect of the 3.0 migration.
[03:23] <lifeless> ok
[03:24] <lifeless> is there a bug for that form, or would you like me to file one?
[03:24]  * spiv mumbles "affects me too"
[03:25] <abentley> lifeless: I'm not sure, but rockstar is aware that it needs to be changed.
[03:25] <lifeless> ok, no need to for pointless bit-setting then ;)
[03:25] <lifeless> spiv: doit
[03:26] <spiv> lifeless: on the trivial imports, or the paramiko (or both?)
[03:26] <spiv> (I'm doing the trivial atm :)
[03:26] <lifeless> paramiko
[03:26] <spiv> lifeless: cool, thanks
[03:29] <barry> spiv: hello!
[03:29] <spiv> barry: good afternoon :)
[03:29] <lifeless> abentley: I've commented; you may need to escalate to Martin - I think its worth writing the code to do the path calculations
[03:30] <barry> spiv: good evening :)
[03:30] <spiv> :)
[03:30] <barry> spiv: can i play dumb user and maybe we can walk through the upgrade instructions?
[03:30] <spiv> barry: I have a message from the future for you: Tuesday is a good day :)
[03:30] <lifeless> abentley: but my only data is years old now when I got close to inventory-free commits at 0.92 time
[03:30] <barry> :)
[03:30] <lifeless> beuno: have you read the upgrade guide?
[03:30] <lifeless> bah
[03:30] <lifeless> barry: ^
[03:30] <spiv> barry: sounds good.
[03:31] <barry> lifeless: sort of, but there are some holes missing that i think we should fill to make life easier for the next person
[03:31] <barry> let me bring up the instructions on this box
[03:32] <barry> spiv: let's start here: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad
[03:32] <barry> #1.  i nominate myself )
[03:32] <barry> er, :)
[03:32] <barry> #2.  "unset the current trunk from being the development focus"
[03:33] <lifeless> oh right, today is tuesday
[03:33] <SamB_XP_> lifeless: is not!
[03:33] <SamB_XP_> it's still monday
[03:33] <barry> spiv: i think we need a lot more detail there.  unfortunately it is not obvious how to do this on launchpad
[03:33] <barry> spiv: and, while i think i know how to do it, even then it's not 100% clear
[03:34] <barry> spiv: so, let's try to do it and then let's document it so it's really easy for the next person
[03:34] <barry> spiv: i start by going here: https://edge.launchpad.net/mailman
[03:34] <barry> spiv: i click on 'Change detals'
[03:35] <barry> spiv: i scroll down to Development focus
[03:35] <barry> spiv: i click on the pull down menu
[03:35] <barry> spiv: uh oh, i've hit my first snag.  i cannot "unset" this, i can only assign it to a different series, none of which are correct
[03:35]  * spiv tries to play along on another project on staging
[03:36]  * barry waits
[03:37] <abentley> barry: You used to be able to set the branch associated with the dev focus via the registry pages.  You could set it to blank there.  I think this has been removed in 3.0
[03:37] <spiv> barry: yeah, I see that too.
[03:38] <barry> abentley: is that hiding somewhere behind a url hack perhaps?
[03:38] <barry> abentley: iow, maybe the functionality is still there but the link to the page to do that got lost
[03:38] <abentley> barry: You would know about the secret URLs of registry pages better than me.
[03:38]  * barry has seen that in a couple of instances
[03:38] <barry> abentley: heh
[03:40] <barry> spiv: okay, so we've hit our first snag.  i'm updating my copy of the code to see if there's a hidden page somewhere for this.  if not, i will file a bug
[03:41] <spiv> barry: https://edge.launchpad.net/mailman/3.0/+edit and blank the branch, maybe?  (try on staging perhaps)
[03:41] <barry> spiv: good idea!
[03:41] <spiv> barry: I hope you're keeping notes :)
[03:41] <barry> spiv: i log all my irc sessions :)
[03:42] <spiv> Close enough!
[03:42] <rockstar> lifeless, the fix for moving change status is about to hit PQM (it's in ec2test now)
[03:42] <barry> spiv: yep, i think that's it.  https://code.staging.launchpad.net/mailman
[03:42] <barry> "A development focus branch hasn't been specified"
[03:44] <barry> spiv: iirc, i will have to push my migrated branch under a name other than "3.0" because the latter is pack-0.92 and shouldn't be changed due to any stacking going on
[03:44] <barry> spiv: so moving forward my dev focus branch will have to be something else unfortunately.  right?
[03:46] <lifeless> rockstar: cool
[03:46] <lifeless> barry: you can upgrade in-place too, which the guide doesn't documented
[03:46]  * lifeless thinks in-place is nicer
[03:46] <spiv> barry: Hmm, I'm not sure.  Launchpad might be smart enough there, but I'm not certain.  mwhudson, abentley, do you guys know?
[03:47] <lifeless> but its a problem if contributors don't upgrade their stacked branches
[03:47] <lifeless> spiv: lp doesn't rewrite the stack-on
[03:47] <lifeless> spiv: so no, its not smart enough
[03:47] <spiv> Drat.
[03:47] <spiv> mwhudson, abentley: turns out lifeless knows everything :)
[03:47] <barry> lifeless: yes, in-place would be nicer.  in this particular case, there is only one unmerged branch potentially stacked on it, and i can't merge it into my 0.92 branch anyway
[03:48] <spiv> barry: So, sadly, yes.  Unless you upgrade in-place, as lifeless says.
[03:48] <spiv> It might be good to mention that as an option in the upgrade guide, but at the same time overwhelming people with options isn't so good either.
[03:48] <barry> spiv: okay.  let's try this.  let's finish the instructions as written, and then try an in-place upgrade.  then someone <wink> can document both
[03:49] <barry> spiv: so actually, now i need to grab a copy of the trunk and do the migration.  talk to you tomorrow :)
[03:49]  * barry is guessing it will take a while
[03:50] <spiv> lifeless: btw: http://pqm.bazaar-vcs.org/
[03:50] <lifeless> barry: winking isn't gonig to help :P
[03:50] <lifeless> spiv: looks hopeful
[03:50] <lifeless> spiv: next patch, turn on --subunit ;)
[03:51] <barry> lifeless: i'll be happy to document the steps.  is doc.bazaar-vcs.org a wiki?
[03:51] <lifeless> no
[03:51] <lifeless> the upgrade guide is a branch somewhere
[03:51] <lifeless> I suspect it may even be a separate project, and if thats so I have no idea where it is
[03:51] <spiv> Isn't it part of the docs in bzr's source?
[03:51] <tedg> I need some help "decoding" an error.  http://pastebin.ubuntu.com/280929/
[03:52] <spiv> doc/en/upgrade-guide ?
[03:52] <tedg> I'm unsure of where to start looking.  I'm thinking by the 17000 number there it's looking for an older SVN revsion than I have?
[03:52] <spiv> tedg: on what command?
[03:52] <tedg> spiv: bzr gannotate configure.ac
[03:53] <SamB_XP_> tedg: it would ;-)
[03:53] <tedg> Normal annotate gives approximately the same error.
[03:53] <SamB_XP_> that, too, is expected
[03:53] <SamB_XP_> I mean, that you would get the same error
[03:53] <SamB_XP_> not that you would get an error ...
[03:53] <tedg> Oh, good. I was confused :)
[03:53] <spiv> tedg: yes, it appears that revision of that file is not present in your repo
[03:54] <tedg> spiv: So how do I decode that revision number into something useful?
[03:54] <spiv> Possibly due to a bug in the bzr-svn conversion?  /me checks if that is on Launchpad
[03:54] <spiv> tedg: not sure what you mean by "useful" in this context?
[03:54] <tedg> Well, it's not a conversion yet.  But hopefully will be soon... so I'm trying to get bugs out first.
[03:54] <SamB_XP_> whatever it is it sounds like a bug!
[03:54] <tedg> spiv: i.e., it's a missing SVN version.
[03:55] <tedg> spiv: Or, it was because I used bzr-svn to merge in a branch that somehow it figured out about.
[03:55] <SamB_XP_> tedg: how can you have a missing svn version ?
[03:55] <tedg> spiv: Or, it's just foobar :)
[03:55] <SamB_XP_> also that's spelled fubar
[03:56] <barry> lifeless: i will at least email the public mailing list when i figure it out.  can you explain "migrate in-place" though?
[03:56] <tedg> SamB_XP_: So the history of the repo is that it was converted from CVS.  But the way that SF did it is that they lumped everything into one repo, which was split out -- so there is a discontinuity around revision 20K which I believe that bzr-svn just sees as "the beginning of time"
[03:56] <lifeless> there's also a mythic button on LP that says 'doit'
[03:57] <tedg> Which honestly, is kinda fine.  As long as it's really "the beginning of time."
[03:58] <SamB_XP_> tedg: that sounds kinda crazy ...
[03:58] <tedg> SamB_XP_: People who know me, will not disagree with you on that one. :)
[03:58] <SamB_XP_> what happens if you try to checkout the previous revision with SVN itself?
[03:59] <tedg> Well, yes.  You kinda have to know the previous layout, which wasn't a "standard SVN layout" as it was in CVS.
[03:59] <spiv> tedg: so there's a missing record in bzr's database.  It's for the configure.ac file introduced in SVN 17075, and it's modification you made to it in revision ted@canonical.com-20081121044907-chfl7r1x8s1kcp5n.
[04:00] <spiv> tedg: I'm not sure why it's absent, but it's almost certainly due a bug somewhere along the line :(
[04:03] <tedg> Ah, I see now.  It looks like the first SVK cherry-pick is the issue: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/configure.ac?view=log
[04:03] <tedg> Which means there are most definitely other files with this problem.
[04:03] <spiv> Oh, if you're trying to round-trip via the SVN repo, that might explain it I guess.
[04:04]  * barry -> sleep
[04:04] <spiv> That would presumably make all the foreign revisions be ghosts.
[04:04] <barry> spiv, lifeless, abentley thanks.  we'll pick this up again tomorrow.  the future awaits
[04:04] <tedg> spiv: No, not round trip in that regard.  The problem is that SVK (not SVN) did some very funny things with how it merged in.
[04:05] <lifeless> night barry
[04:05] <tedg> spiv: It records complex merges as odd copies with changes.  Borders on evil :)
[04:05] <spiv> barry: g'night
[04:06] <tedg> So if I could find all these "oddities" by hand.  Could I fix them with something like the rebase plugin?
[04:06] <tedg> If I assumed that I'd never go back to SVN again.
[04:10] <tedg> For those who are curious here's the rev where the repo was converted from CVS to SVN and rearranged: http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=10643
[04:15]  * igc lunch
[04:19] <spiv> tedg: so, that particular data appears to still exist in lp:~ted/inkscape/devbuild
[04:19] <spiv> (and some of your other Launchpad branches)
[04:20] <spiv> tedg: so if you rebranch that into your local repo that might be enough to fix it (i.e. to copy the data that is missing locally)
[04:25] <lifeless> 50% there
[04:25] <lifeless> .oO
[04:25] <lifeless> interface tests passing
[04:29] <abentley> lifeless: I've replied.  The gist is that you're asking for complicated code that will only be used in a corner case and usually won't prevent a path<->id map being generated.
[04:45] <tedg> spiv: Sorry, I walked away... I'll give that a try!
[04:46] <tedg> spiv: Just to be curious, how did you find that out?
[04:46] <lifeless> does anyone here have a windows machine?
[04:46] <rbistolfi> Peng_, lifeless: Sorry I got an emergency and I was afk
[04:46] <rbistolfi> re: http://pastie.org/633561
[04:46] <rbistolfi> I am not behind a proxy and I dont know if it is a privete branch, I just found it in launchpad
[04:47] <lifeless> rbistolfi: its not
[04:47] <Peng_> I branched it, so I guess it's not a private branch.
[04:47] <Peng_> Eh, there we go.
[04:47] <lifeless> rbistolfi: the error you have looks like a interecepting proxy to us
[04:47] <abentley> lifeless: I have a windows machine.
[04:47] <lifeless> abentley: I need to know what exception dirstate raises
[04:47] <Peng_> Or, something just went Horribly Wrong with the connection.
[04:47] <lifeless> could you do a small test for me?
[04:48] <abentley> lifeless: Okay.
[04:48] <lifeless> given a bzrlib wt4 tree at path foo
[04:48] <lifeless> state1 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
[04:48] <lifeless> state1.lock_read()
[04:48] <lifeless> state2 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
[04:49] <lifeless> state2.lock_write()
[04:49] <spiv> tedg: http://paste.ubuntu.com/280963/
[04:49] <lifeless> the last line should raise something from bzrlib.errors
[04:49] <rbistolfi> lifeless, Peng_: thanks, I will try to branch from a server I admin connected to another isp, maybe I am being intercepted after all
[04:49] <lifeless> you'll want to state1.unlock(), and you're done.
[04:49] <tedg> spiv: Didn't go well: bug 438509
[04:50] <lifeless> I should say, wt4 or newer, anything dirstate based
[04:50] <spiv> tedg: oh wow, I haven't seen that assert triggered before
[04:51] <tedg> I assume I get some kind of award? ;)
[04:51] <spiv> tedg: I wonder if that's a symptom of the same problem, I suppose it could be...
[04:51] <abentley> lifeless: I have 1.2.0dev0 on my Windows box, and it seems to be broken, too.
[04:51] <lifeless> abentley: bzrlib is broken, or the python I gave you is broken?
[04:52] <abentley> lifeless: bzrlib is broken.  "bzr init foo" fails.
[04:52] <lifeless> oh, eep
[04:52] <lifeless> abentley: is the tree you have there dirstate based? if so you don't need to init...
[04:53] <abentley> lifeless: It is a lightweight checkout from an ext3 partition which has since been reformatted.
[04:53] <lifeless> works for me
[04:53] <lifeless> as long as it has a dirstate file the results should be useful
[04:54] <lifeless> windows OS locks will mutually exclude the two locks
[04:54] <lifeless> I just need to catch the error so my test for dirstate2 doesn't blowup on windows
[04:56] <spiv> tedg: I wonder if making a new shared repository ("bzr init-repo --1.9-rich-root") and branching lp:~ted/inkscape/devbuild into that and then your other local branches would work better?
[04:56] <abentley> lifeless: I get errors.LockContention
[04:56] <lifeless> thank you very much
[04:56] <abentley> lifeless: You're welcome.
[04:57] <spiv> tedg: FWIW, bzr 2.0.0 should be much more aggressive about preventing incomplete data to be committed in the first place.
[04:57] <tedg> spiv: No, similar error.  Are the details useful?
[04:58] <spiv> Obviously that doesn't help your existing situation (unless you have a time machine), but I thought I should reassure you a little bit :)
[04:58] <tedg> spiv: I am running 2.0 now... should I reimport the repo?
[04:58] <spiv> tedg: Did it fail on the first branch?
[04:59] <tedg> spiv: I had a copy of devbuild locally in a shared repo, I then branch the branch in the new shared repo over.
[04:59] <spiv> tedg: please use the copy from Launchpad
[05:00] <spiv> Because we know that that copy has that missing record in its repo.
[05:00] <spiv> "bzr check" on your local repos might be interesting, probably it will report the same issue.
[05:01] <spiv> I just successfully branched lp:~ted/inkscape/devbuild from Launchpad, so it appears that that copy isn't missing anything that it is supposed to have.
[05:02] <lifeless> ok, dirstate2 works
[05:02] <lifeless> time to put a tree on it and user-level test it
[05:02] <spiv> lifeless: nice
[05:03] <lifeless> I just wish we'd not been scraping performance issues right up to 2.0.0
[05:03] <lifeless> this would have been so nice to have in there
[05:04] <spiv> lifeless: yeah.
[05:04] <lifeless> I've had this in my head for about a year
[05:04] <lifeless> as a 'TUIT' problem
[05:06] <rbistolfi> lifeless, Peng_: well if I tunnel my conection through Miami I can branch it just find, I think that fits well with the proxy theory. I have pretty much the same setup in both machines.
[05:06] <rbistolfi> s/find/fine/
[05:07] <Peng_> You can avoid the issue, and get a speed boost, if you get a LP account and use bzr+ssh.
[05:07] <rbistolfi> I will do, tyvm
[05:20] <tedg> spiv: Okay, so branching that way makes the error MUCH larger: http://pastebin.ubuntu.com/280979/
[05:20] <tedg> spiv: Still running the check.
[05:21] <spiv> tedg: hmm, looks like text versions from the original SVN import are missing somehow!
[05:21] <spiv> Very odd.
[05:22] <spiv> Oh, that's interesting; one way the missing text revisions were svn-v4:..., the other they are svn-v3-trunk:...
[05:23] <tedg> So could it be a disagreement between versions of the SVN plugin?
[05:23] <spiv> I wonder if a "bzr svn-upgrade" somewhere along the line is part of the cause...
[05:24] <tedg> I don't think there is a svn-upgrade.
[05:26] <spiv> Hmm, I'm sure there used to be a command that would rebase revisions from an older version of a plugin to use the new mapping.
[05:26] <spiv> s/a plugin/the svn plugin/
[05:27] <spiv> Yes, there was definitely a "bzr svn-upgrade" in the past, I wonder why it's gone now.
[05:27] <spiv> Ah, it's now "bzr foreign-mapping-upgrade"
[05:33] <tedg> spiv: I don't seem to have that command, is it in a plugin?
[05:33] <tedg> The bzr check is still running... is there a point I should give up?
[05:34] <lifeless> spiv: your patch landed?
[05:39] <tedg> spiv: It seems to be in rebase.  But I can't get it to work.
[05:40] <tedg> It basically says the SVN repository isn't a repository.
[05:40] <igc> bbiab
[05:40] <spiv> lifeless: yes
[05:41] <spiv> tedg: I'm not very familiar with it, I was just speculating that it may have been involved in the history of this branch.
[05:41] <tedg> I think I'm going to try a new import tonight with the new and shiny 2.0 and see if that helps... start fresh tomorrow.
[05:42] <tedg> spiv, thanks for your help!
[05:42] <spiv> tedg: you're welcome, sorry I couldn't be more helpful
[05:55] <lifeless> \o/
[05:55] <lifeless> WTFormat7 passes interface tests
[05:56] <fullermd> Does that mean it works right, or that the tests have insufficient coverage?  :p
[05:57] <lifeless> fullermd: bit of both
[05:58] <lifeless> fullermd: I suspect that its possible to make it delete the HASH file for the current pointer with a sufficiently clever flip-flop state change at the moment
[05:58] <lifeless> fullermd: so I want to add a random seed to the state files
[05:58] <lifeless> fullermd: or tweak that more, before folk are doing more than play with it as a shiny shiny
[06:00] <lifeless> fullermd: however, you can do a diff while a commit editor is open
[06:02] <spiv> lifeless: oh yeah, that reminds me
[06:02] <spiv> lifeless: I was also going to ask about two concurrent stat cache updates to the same state
[06:02] <spiv> Which may be why you want some random bits in the filenames?
[06:02] <lifeless> spiv: same issue ;)
[06:03]  * spiv nods
[06:03] <lifeless> yes
[06:03] <lifeless> in practice, doing 'bzr add foo' 'bzr rm foo' with no other changes can flip flop
[06:04] <lifeless> doing 'bzr diff' and keeping the process alive in a GUI in between could cause something that sees the old state around
[06:04] <lifeless> but I'm /not sure/ you can force destructive behaviour without being able to run stat fingerprints backwards
[06:05] <lifeless> I think simply putting the 'lazy delete' inside the 'I own the current file' "mutex" may be sufficient.
[06:05] <lifeless> though if we start doing that I may simply start using regular lockdirs to do the locking, though they will be a lot slower.
[06:15] <lifeless> its fun to close 6 bugs with one push :)
[06:21] <lifeless> heh, I lied, 7
[06:31] <lifeless> poolie: are you here, or is it just a bot?
[06:34] <lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/dirstate2 :)
[06:35] <lifeless> note the bug list ;)
[06:40] <lifeless> ahhh bugspam
[07:35] <vila> hi all
[07:57] <igc> hi vila
[07:57] <igc> out for a bit - bbl
[07:58] <bialix> hello all
[07:59] <bialix> (ru) people asking about comparison of 2a format to hg/git: storage size, speed. Is there already exists one, or planned?
[07:59] <vila> hello bialix
[07:59] <bialix> bonjour vila
[08:00] <fullermd> I'm not aware of a useful existing one.  fast-import probably makes it a lot easier to put one together though.
[08:00] <vila> igc ran tests and should have a few numbers
[08:01] <vila> but, AIUI, there is no absolute rule here, what I understand is that 2a has sizes comparable with hg/git, sometimes better, sometimes worse, but always in a reasonable amount
[08:02] <vila> for speed, things are even more unclear as benchmarks are like statistics...
[08:02] <vila> now, all of that is also highly subjective and on that front people seem quite happy :D
[08:03] <bialix> it seems so
[08:03] <bialix> but anyway I'd better asking
[08:03] <fullermd> A historical problem with those sort of comparisons is that they're often done on trees with no history.  I'd be very happy to never see such a thing again...
[08:04] <bialix> fullermd: IIUC fast-import should be a key here
[08:04] <fullermd> ("Oh, look, I benchmarked VCS A, B, and C on importing two tarballs of a project.  Now we all know what's faster and smaller.")
[08:04] <bialix> convert the same repo into different systems
[08:04] <bialix> tarball is a wrong attempt IMO
[08:04] <fullermd> Yah.
[08:04] <vila> fullermd: hmm, I don't think that's the case anymore but may be the more recent benchmarks need more exposure...
[08:05] <lifeless> I saw someone test a single commit benchmark just riday
[08:05] <lifeless> *friday*
[08:05] <lifeless> :)
[08:05] <fullermd> Yeah, they come up with painful regularity out around the Interblog.
[08:06] <fullermd> 'course, historically, we wouldn't want to argue against that, since it painted bzr in a better light than otherwise   :|
[08:07] <lifeless> by which you mean only slightly worse than tar?
[08:07] <vila> the last benchmarks igc produced showed that bzr was not the best for all operations, I think that's enough to make it an honest one :D
[08:08] <fullermd> Back around 1.0, we had claims of speed and size comparable to brands G and H.  And the benchmarks to back them up; we were of similar overall speed and similar (or better!) size on disk!
[08:08] <fullermd> ... for projects with one revision...
[08:11] <bialix> so, good benchmark will depend on how good and robust fast-import conversion
[08:12] <spiv> vila: can you help with testing my fix for https://bugs.launchpad.net/bugs/433846 ?
[08:12] <vila> spiv: I still haven't a working windows setup :-/
[08:12] <fullermd> Yah, without some way of getting as-nearly-as-practical identical sizable histories in both tools, any benchmark is going to be of very limited use.
[08:12] <vila> spiv: that what you need here right ?
[08:12] <fullermd> Luckily, fast-import fills that niche nicely   :)
[08:13] <spiv> vila: that would be ideal
[08:13] <spiv> vila: it's not really Windows-specific, but it would be nice to test a scenario as close to the actual reporters as possible.
[08:13] <spiv> vila: if you don't have working Windows I'll do some Windows-less testing myself.  Thanks.
[08:14] <vila> spiv: you're welcome :-/
[08:14] <spiv> vila: (alternatively, if you can push a button and produce a test Windows installer with that fix we can offer to the reporter, that would do ;)
[08:14] <vila> lol
[08:15] <bialix> lol
[08:15] <fm> i just hit http://pastebin.com/m6fa4b0de
[08:15] <vila> spiv: unfortunately even the installer builds are failing on kerguelen for quite a few days now :-/ And they are outdated anyway AIUI
[08:17] <fm> vila: can you look at the backtrace?
[08:17] <bialix> fm: bzr unable to version control fifo
[08:17] <fm> but it gives an internal error ...
[08:19] <bialix> file a bug please
[08:19] <bialix> bzr should not allow you to add fifo in first place
[08:20] <bialix> or maybe some of your entries was plain file/symlink and now fifo
[08:20] <fullermd> Hm, it'd be fun to be able to 'revert' a FIFO...
[08:23] <vila> fm: definitely a bug to be filed, bzr shouldn't backtrace, as a workaround, try to identify which file is a fifo and bzr ignore it
[08:23] <fm> bialix: https://bugs.launchpad.net/bzr/+bug/438569
[08:24] <vila> great
[09:00] <BjornT> jelmer: i'm trying to use bzr-git to branch from github, but after exactly 5 minutes i get this error: http://paste.ubuntu.com/281091/
[09:00] <BjornT> jelmer: do you know why that would be? i can access github using git without any problems
[10:45] <jelmer> BjornT: bzr/bzr-git doesn't support rsync-style URLs
[10:46] <jelmer> BjornT: and it is not yet possible to fetch individual branches (as we have no way to address branches that are not on the filesystem)
[10:46] <jelmer> BjornT: you might want to try 'bzr branch git://github.com/bjornt/windmill.git'
[10:47] <jelmer> BjornT: or s/branch/git-import/ (for all branches, not just HEAD)
[10:51] <Tak> jelmer: ping
[11:11] <jelmer> Tak: pong
[11:11] <Tak> hi
[11:12] <Tak> would you like for me to merge your 2.0 changes before merging 2.0 into ... what is that called, mainline?
[11:12] <jelmer> Tak: please do
[11:12] <jelmer> Tak: yeah, mainline/trunk/ whatever you want to call it :-)
[11:13] <Tak> yeah, I have a habit of referring to my development branch as "trunk", plus there's another one actually labeled "trunk" I think ... :-P
[11:13] <Tak> ok, doing that now
[11:20] <gioele> Hello
[11:21] <Tak> hello gioele
[11:25] <gioele> What is the state of keyword expansion? bzr help content-filters does not says nothing specific about keyword expansion. Also, in the wiki there are only old (2004/2005) blueprints
[11:27] <spiv> gioele: I think you need the bzr-keywords plugin (https://launchpad.net/bzr-keywords)
[11:27] <spiv> gioele: which hooks into the content filtering feature in core bzr
[11:41] <gioele> Do lightweight checkouts have to be in the same format of the remote branch?
[11:43] <beuno> gioele, it probably needs to at least be rich-root or non-rich-root
[11:43] <beuno> and, different formats will likely make it slower
[11:51] <eLBati> hi
[13:51] <eLBati> I can't understand why this happens
[13:51] <eLBati> 8# bzr checkin -vm "first translation" index.rst
[13:51] <eLBati> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[13:51] <eLBati> launchpad-login is set
[13:55] <eLBati> but what is checkin trying to do? shouldn't it do a local checkin?
[14:17] <eLBati> uhm it does so with every command
[14:20] <mzz> eLBati: what does "bzr info" say?
[14:20] <vila> eLBati: you created a checkout from a branch you can't commit to
[14:20] <mzz> eLBati: I'm guessing you created a checkout where you wanted a branch
[14:20] <Lo-lan-do> Hi all
[14:21] <Lo-lan-do> jelmer, james_w: I'd like to upload loggerhead to unstable and add myself as an uploader if it's all right with you.
[14:21] <mzz> eLBati: if that's indeed what happened I think you can use "bzr reconfigure" to turn it into a regular standalone branch you can commit to
[14:22] <Lo-lan-do> jelmer, james_w: Also, I'll need to get it into bpo at some point, do you have a procedure for that?
[14:22] <eLBati> mzz, yes it's a checkout
[14:22] <eLBati> so, with a checkout I can't commit?
[14:22] <mzz> eLBati: you can only commit to a checkout if you can commit to the thing it is a checkout of
[14:23] <mzz> eLBati: (it commits to the branch the checkout is "bound" to first, then locally)
[14:25] <mzz> eLBati: to avoid this use "bzr branch" (or the alias "bzr get") to create a standalone copy of the remote branch instead of "bzr checkout"
[14:26] <jelmer> Lo-lan-do: please do
[14:26] <jelmer> Lo-lan-do: we don't have any procedure for bpo uploads
[14:27] <eLBati> thanks mzz
[14:29] <Lo-lan-do> jelmer: I don't even know how to do an upload to bpo :-)  I'll read up on that.
[14:30] <james_w> hey Lo-lan-do
[14:30] <james_w> does loggerhead now use the system yui correctly?
[14:30] <Lo-lan-do> james_w: It does, but unfortunately the system yui isn't the same as the one expected by loggerhead.
[14:31] <Lo-lan-do> LH uses 3.0rc2, whereas sid only has 2.7something.
[14:32] <Lo-lan-do> So unless --use-cdn is used, some of the Ajaxy things are broken.
[14:33] <Lo-lan-do> I guess I could add a check for the presence of an appropriate version, and add the --use-cdn switch if needed.
[14:35] <eLBati> what is target configuration of bzr reconfigure?
[14:38] <Lo-lan-do> eLBati: It's what you want to turn your directory into.
[14:41] <Lo-lan-do> jelmer, james_w: Any thoughts about this automated use of remote YUI?
[14:42] <james_w> I'm not sure it would go down well in some comments
[14:42] <james_w> some contexts I mean
[14:42] <james_w> I'm not sure we should be using the system one if it is the wrong version
[14:43] <james_w> 2 and 3 are basically different projects as I understand it, so trying to force it seems unnecessary
[14:43] <Lo-lan-do> jaldhar tells me he'll upload yui 3 soonish.
[14:43] <eLBati> thanks Lo-lan-do
[14:43] <james_w> cool
[14:44] <Lo-lan-do> I guess I could revert the "use system yui" patch until then…
[14:52] <Lo-lan-do> Oh well, I'll just document the "feature" until yui3 appears, and then I'll use a versioned dependency.
[14:54] <eLBati> mzz, # bzr reconfigure --branch
[14:54] <eLBati> bzr: ERROR: Working tree "..." has uncommitted changes
[14:54] <mzz> eLBati: --standalone
[14:54] <eLBati> I just did a checkout
[14:54] <mzz> eLBati: I know. bzr reconfigure --standalone
[14:55] <mzz> or "bzr unbind", actually.
[14:57] <eLBati> thanks mzz
[15:28] <eLBati> if I have uncommited changes, how could I undo such changes and get the repository version of files?
[15:29] <dash> you can do "bzr revert" if you want to remove those changes
[15:29] <dash> or "bzr shelve" if you want to save them for later
[15:34] <eLBati> thanks
[16:04] <igc> night all
[16:14] <Tak> can one dpush from an unbound checkout?
[16:14] <jelmer> Tak: yes
[16:14] <jelmer> Tak: unbound checkout == standalone branch
[16:15] <Tak> yeah - I didn't know if there were some internal semantics that would make it work differently
[16:15] <Tak> thanks
[16:18] <mzz> an unbound (heavyweight) checkout *is* a standalone branch, so I don't know what kind of "internal semantics" you mean
[16:19] <mzz> (they're not equivalent or the like, unbinding the checkout turned it into exactly a standalone branch)
[17:00] <awilkins> Yeesh, --2a might be the New Hotness, but it repacks a lot slower than older formats
[17:01] <awilkins> It's just taken 15 minutes to repack ~800MB
[17:04] <mathrick> hi
[17:04] <mathrick> http://pastebin.com/m6d14728b
[17:04] <mathrick> what gives?
[17:04] <mathrick> it's not an error that makes any sense to me
[17:06] <Lo-lan-do> mathrick: You're in a repo, not in a branch inside that repo.
[17:07] <Lo-lan-do> The branches are probably in a subdir?
[17:07] <idnar> heh, that's ironic, I just did that myself about 2 minutes ago
[17:08] <mathrick> Lo-lan-do: oh, so that means I forgot to init that dir. No good :(
[17:08] <mathrick> thanks
[17:08] <idnar> the message is a bit confusing
[17:08] <mathrick> it is
[17:08] <idnar> although I immediately figured out my problem when I saw what directory I was in
[17:09] <mathrick> I thought I had it init'd already
[17:10] <mathrick> hmm
[17:10] <mathrick> is there an option to make bzr add symlinks by their pointed-to contents?
[17:10] <mathrick> add/commit, really
[17:11] <mathrick> oh, it's the incremental commit plugin interfering
[17:22] <Tak> hooray!
[17:23] <Tak> my mysterious bzr-svn crash was being caused by the dbus plugin
[17:28] <awilkins> ubottu: #43805
[17:28] <awilkins> ubottu: #438805
[17:28] <awilkins> Gah
[17:28] <mathrick> ubottu: bug #43805
[17:28] <awilkins> https://bugs.launchpad.net/bzr/+bug/438805
[17:29] <mathrick> hmm
[17:29] <mathrick> ubottu: bug #43805 in bzr
[17:29] <mathrick> it doesn't seem to understand that
[17:29] <awilkins> Wrong bug number ... they're globally unique per LP instance AFAIK
[17:30] <mathrick> oh
[17:30] <awilkins> Just doing a `bzr check` on the repository that's provoking the problem
[17:30] <mathrick> right
[17:30] <mathrick> okay, thanks for the help, gotta be going
[18:47] <tolstoy> Anyone having issues running on Snow Leopard using the installer?
[18:48] <tolstoy> bzr: ERROR: Unsupported protocol for url "sftp://kirwin@host/path/to/code/": Unable to import paramiko (required for sftp support): No module named paramiko
[18:53] <tolstoy> Who put together the installer anyway? No one to email!
[18:55] <kirkland> is there a way to pass -uc -us to bzr builddeb ?
[18:55] <kirkland> it didn't "just work"
[19:03] <tolstoy> jfroy|work: Hi, I'm the one with the snow leopard error from twitter.
[19:04] <jfroy|work> tolstoy: hey
[19:04] <jfroy|work> so basically I didn't include paramiko in the 10.6 installer.
[19:04] <jfroy|work> And it seems that was the wrong decision.
[19:04] <tolstoy> Yeah.
[19:04] <jfroy|work> The initial thought being that the bazaar installer should only install bazaar and nothing else.
[19:04] <tolstoy> Heh. ;)
[19:05] <tolstoy> Well, you know how people are about dependency hell.....
[19:06] <tolstoy> Seems like there should at least be enough there to support all the commands.
[19:06] <tolstoy> I just tried "bzr miss sftp://me@host:/path/to/project" and it errors out.
[19:06] <jfroy|work> well it's not that it doesn't support all the commands
[19:06] <jfroy|work> it just won't support sftp transports
[19:06] <tolstoy> Isn't sftp kind of fundamental? (I don't really know. I've always used it, though.)
[19:07] <jfroy|work> I don't use it ever.
[19:07] <LarstiQ> jfroy|work: or ssh in certain cases
[19:07] <jfroy|work> I use the smart server or work with svn repositories.
[19:07] <Lo-lan-do> Isn't "dependency hell" kind of 1998?
[19:07] <jfroy|work> Lo-lan-do: unfortunately, Mac OS X doesn't really have a good story w/r to dependency management.
[19:07] <tolstoy> Exactly.
[19:08] <jfroy|work> Well not for binary packages anyways.
[19:08] <jfroy|work> In any case, I'm going to bake another installer.
[19:08] <tolstoy> That would be awesome.
[19:09] <tolstoy> Hm. The only other thing I could think of is a bzr command to settle dependencies on its own.
[19:09] <tolstoy> Which seems kind of, well, out of scope.
[19:11] <jfroy|work> no
[19:11] <jfroy|work> a better idea would be for bzr to offer to install those dependencies
[19:12] <jfroy|work> something like "SFTP support requires Paramiko, which you do not have installed. Would you like to from PyPI? Yes | No", and if yes run sudo easy_install paramiko
[19:12] <jfroy|work> done
[19:12] <jfroy|work> that would be classy
[19:12] <jfroy|work> and broken on Linux and Windows, but that's a detail :p
[19:12] <tolstoy> Heh. Works for me.
[19:13] <jfroy|work> verterok: ping
[19:13] <tolstoy> You could even keep stats, and if practically everyone always installs paramiko, might as well bundle it in the original install.
[19:13] <verterok> jfroy|work: pong
[19:13] <jfroy|work> verterok: did you push a new packaging branch and all. Might want to rebake the 10.6 installer using that.
[19:14] <verterok> jfroy|work: I started working on something, lp:~verterok/+junk/OSX-package
[19:15] <verterok> jfroy|work: it adds the "download all stuff before build" script
[19:15] <jfroy|work> ok, I'll just use my setup for now just to quickly rebake
[19:15] <verterok> jfroy|work: ok :)
[19:24] <jfroy|work> baking....
[19:24] <jfroy|work> pretty easy to do now once that the infrastructure is in place :)
[19:25] <jfroy|work> one further improvements would be to use remote packages for optional installs (to keep the download small)
[19:25] <jfroy|work> and sign the packages
[19:25] <jfroy|work> *and another to sign
[19:30] <james_w> kirkland: "bzr builddeb -S -- -uc -us"
[19:30] <james_w> annoying I know
[19:30] <kirkland> james_w: ah, thanks
[19:30] <james_w> it will "just work" one day
[19:43] <jfroy|work> And there we go, new installer up.
[19:43] <jfroy|work> Enjoy your paramiko flavored goodness.
[19:43] <jfroy|work> tolstoy:
[19:43] <tolstoy> I'll give it a try! Thanks.
[19:44] <tolstoy> jfroy|work: http://bazaar-vcs.org/MacOSXDownloads, right?
[19:44] <jfroy|work> yeah
[19:44] <jfroy|work> it's feeding off my blog right now.
[19:44] <tolstoy> It is larger.
[19:44] <jfroy|work> which scares me :p
[19:46] <tolstoy>   from sha import *
[19:46] <tolstoy>    /Library/Python/2.6/site-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[19:46] <tolstoy>   from sha import *
[19:46] <tolstoy> I think it works, but there's that "interesting" output. ;)
[19:46] <tolstoy> jfroy|work: This has got to be such a headache for you.
[20:05] <tolstoy> jfroy|work: Maybe link against the Python 2.5 lib? Seems to be installed on my Snow Leopard, anyway.
[20:06] <Pilky> tolstoy: I think he links against 2.6 as that allows for 64 bit
[20:06] <Pilky> tolstoy: I think 2.5 is only 32 bit on snow leopard
[20:06] <tolstoy> Ah (drkirwin here). It seems reasonable. Wonder why there's the deprecation warning, then?
[20:07] <Pilky> could be that it is deprecated, but paramiko hasn't been updated to use hashlib?
[20:09] <fullermd> No, that's from pycrypto.  It needs a patch to not throw deprecation warnings against py2.6.
[20:09] <fullermd> It works, it's just noisy.
[20:10] <tolstoy> Right. I was able to push my changes.
[21:04] <jfroy|work> tolstoy: I target Python 2.6 on SL because it's the default interpreter and because it's 64-bit
[21:04] <jfroy|work> and bzr eats memory like candy
[21:09] <tolstoy> jfroy|work: Works for me. Well, except for those pesky deprecation warnings.
[21:14] <mwhudson> jelmer: does bzr-git support accessing git over http?
[21:17] <jelmer> mwhudson: no, not yet
[21:17] <mwhudson> rockstar: ^^
[21:17] <jelmer> mwhudson: bug 373688
[21:21] <Meths> I'm getting a file lock issue using bzr (1.18) shelve on Windows, even after a reboot, are there any known issues with shelve?
[21:30] <tolstoy> Well, gotta go.
[21:32] <tolstoy> jfroy|work: I'll see if there's a new package later this afternoon (PST) that fixes the deprecation working. I mean, if it's in the works.
[21:32] <jfroy|work> There isn't, it's a problem with PyCrypto.
[21:33] <tolstoy> Oh. So all snow leopard BZR users will have to see those messages indefinitely?
[22:01] <tolstoy> So, bzr, on snow leopard, using the installer, spews deprecation messages for every sftp operation.
[22:01] <tolstoy> How should I report that? Launchpad bug?
[22:01] <tolstoy> It's not an installer issue?
[22:06] <bialix> tolstoy: at least you can send message to main bzr ML or to bzr-mac one
[22:07] <tolstoy> Okay. I didn't realize there was a bzr-mac list. I'll look it up.
[22:48] <lifeless> moin
[22:49] <RAOF> mushi mushi.
[22:50] <lifeless> mmm sushi sushi
[22:51] <RAOF> Not for breakfast, thanks.
[23:07] <dkobozev> hi all. i have a workflow-related question.
[23:08] <dkobozev> i'm working on a php website. i have a bunch of php files that should go into public_html folder. plus, i have a database schema file and a db dump with test data.
[23:09] <dkobozev> the latter two shouldn't go into public_html, obviously. what would be the best way to manage these with bzr?
[23:12] <dkobozev> creating two separate branches - one for php files, one for db files - seems very impractical.
[23:14] <fullermd> I use a single branch, but use scripts to deploy the files that need to be deployed.
[23:15] <dkobozev> like post-commit hooks in svn?
[23:15] <fullermd> No, like Makefiles.
[23:16] <fullermd> I (speaking for nobody but myself, natch) am a firm believer in separation of VCS and deployment.
[23:17] <dkobozev> so you would keep both php and db files in public_html in my case?
[23:17] <fullermd> No, I'd keep both in the _bzr branch_.  And the bzr branch out of public_html.
[23:17] <dkobozev> got it.
[23:17] <fullermd> Then I do the equivalent of a 'make install' to copy the files into place for deployment.
[23:18] <fullermd> (though my dev environment is actually often a symlink into the subdir of the branch where the files are)
[23:18] <fullermd> But that's just local anyway.
[23:18] <dkobozev> i like the symlink idea...
[23:20] <fullermd> Yeah, it streamlines the dev process.
[23:20] <dkobozev> are there any security implications to having a symlink to a branch subdir vs copying the files to public_html?
[23:20] <fullermd> Though it sometimes requires a little fiddling, since what's in the branch isn't always directly workable (another reason for the install scripts)
[23:21] <fullermd> Well, if you copied everything under that subdir, it would be equivalent.
[23:21] <jelmer> lifeless: What's the easiest way to get my key in the PQM updated?
[23:21] <fullermd> Hard to say much beyond that; it's pretty case-by-case what exactly is where.
[23:22] <fullermd> But the root of my branches 'typically' has two dirs, a db/ where the database schema and such live, and a src/ which is roughly a mirror of how the deployed files look.
[23:23] <fullermd> (there are differences, e.g. which config files are enabled in different deployments, which the Makefiles handle)
[23:24] <dkobozev> yeah, config files is another consideration. i usually do not put them under version control at all, which is not nice sometimes.
[23:24] <fullermd> My default skeleton that I branch from for new projects has a live.conf and a dev.conf.  The install process symlinks one or the other (as appropriate) to the 'real' config file name.
[23:25] <fullermd> And in manual environments, I .bzrignore the 'real' name and symlink as appropriate, or have the code default to loading the dev if the normal name isn't there, or various other permutations.
[23:26] <fullermd> By not deploying via VCS, I'm freed from having to have the stuff under version control be an exact replica of the deployed state, which gives me flexibility for those sort of customizations.
[23:26] <fullermd> The downside, which people who swing the other way will point out, is that now I have two systems to deal with (and probably one of them to maintain myself).
[23:27] <dkobozev> what language do you use to write your install scripts? bash?
[23:27] <fullermd> For me, that's trivial overhead with big gains.  I can see that the scales may be reversed for other people.
[23:27] <fullermd> At the moment, they tend to be Makefile's, so the real work is done by gobs of standard *nix utils (mostly install(1)).
[23:28] <fullermd> Though special cases sometimes call for more specific sh scripts or throwing something together with awk or perl or...
[23:28] <dkobozev> i'd say it would have to be a pretty big project for such heavy machinery :)
[23:29] <fullermd> I do my best to slaughter all the special cases, but they keep creeping in under the door at night...
[23:32] <dkobozev> you pointed me in an interesting direction. somehow, i never considered tools such as make for web development.
[23:34] <fullermd> Always look at every possible tool for a job, and ask yourself, "Will using this make people think I'm a giant nerd?"
[23:35] <fullermd> If the answer is 'hell yeah', wallow in it   8-}
[23:36] <lifeless> jelmer: make sure its updated on the keyservers, and ping spm
[23:38] <dkobozev> true enough. but i also dislike killing flies with nukes and napalm :)
[23:39] <dkobozev> and thanks for the symlink suggestion. i'll use that or something similar.
[23:39] <jelmer> lifeless: thanks
[23:46] <fullermd> Pfft.  The surest way to kill a fly is to destroy the planet it's on!
[23:47] <abentley> lifeless: What's the correct URL to submit to the 2.0 branch?  I tried bzr+ssh://bazaar.launchpad.com/~bzr-pqm/bzr/2.0
[23:49] <lifeless> abentley: I think its http; its in the docs
[23:49] <lifeless> I'll just check my locations, one sec
[23:49] <lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
[23:49] <lifeless> abentley: ^
[23:50] <abentley> lifeless: Thanks.
[23:50] <dkobozev> fullermd: if it's worth doing, it's worth over-doing, eh?
[23:50] <lifeless> black holes
[23:50] <lifeless> only way to be sure
[23:51] <lifeless> jelmer: bug 438959
[23:51] <lifeless> jelmer: seems valid to me: user does something, gets error.
[23:51] <jelmer> lifeless: it's still valid, but assigned to bzr
[23:51] <jelmer> lifeless: not bzr-svn
[23:51] <lifeless> ok
[23:51] <lifeless> thanks
[23:58] <jelmer> ls