[00:12] <mkanat> jam: pqm was a customized branch for launchpad specifically.
[00:12] <mkanat> jam: It had changes that were only relevant to Launchpad.
[00:14] <mkanat> jam: I have a feeling mwhudson didn't actually look over your merge code.
[00:15] <mkanat> Since it was immediately obvious to me that some of those things should not have been merged back into the main loggerhead.
[00:15] <mkanat> jam: It's also slightly mysterious why certain things were there that weren't on experimental, like HACKING.
[00:16] <mkanat> jam: It's possible that when doing the merge you restored files that were removed on experimental, since pqm was based on the stable branch, not on trunk.
[00:30] <lifeless> mkanat: this is part of sorting out th emess
[00:30] <mkanat> lifeless: Sure.
[00:30] <mkanat> lifeless: I'm sure that jam and mwhudson will be able to figure it all out.
[00:33] <mkanat> I actually noticed the problem immediately when it was posted, but I'm not on contract anymore and I figured that somebody would notice it too.
[00:33] <mkanat> Once this particular merge is handled it should be fine from here on out.
[00:34] <mkanat> jam: BTW, I noticed that you've been keeping up the tests now, which is so awesome. :-)
[00:35] <mkanat> jam: That was exactly what I was going to do next if I'd had a few more hours. :-)
[00:39] <poolie> hi mkanat, lifeless, jam
[00:39] <mkanat> Hey poolie.
[00:52] <mkanat> I've left ~loggerhead-team for now--if anybody has specific questions that they want my feedback on, feel free to subscribe me directly or request review from me directly.
[01:00] <palhmbs> I'm stuck!
[01:01]  * palhmbs puts his hand up... how do I get my bzr branch uploaded to launchpad.... bzr push lp:~john.doe/+junk/myproject -- just says bzr: ERROR: Invalid url supplied to transport !!
[01:01] <mkanat> palhmbs: You need a project first.
[01:02] <mkanat> palhmbs: Then it would be like lp:~john.doe/myproject/trunk
[01:02] <palhmbs> I have created a PPA -- do I -- bzr push lp:~palhmbs/~palhmbs/+archive/ppa-for-gtg ??
[01:02] <maxb> No, +junk should work
[01:02] <maxb> palhmbs: branches and PPAs do not directly relate
[01:03] <palhmbs> ah - I see...
[01:03] <palhmbs> so I have to set a location for my branch... under .bzr ?
[01:04] <maxb> 'bzr push lp:~palhmbs/+junk/anythin' should just work, assuming you have registered a SSH key with launchpad
[01:04]  * palhmbs has tried using groundcontrol... which got me logged in, but no further
[01:04] <spiv> palhmbs: does "bzr plugins" list the "launchpad" plugin?
[01:04] <palhmbs> spiv, yep - launchpad 2.2.1
[01:05] <maxb> palhmbs: Could you try 'bzr push bzr+ssh://bazaar.launchpad.net/~palhmbs/+junk/something' ?
[01:06] <spiv> palhmbs: is that the full text of the error?
[01:07] <palhmbs> I've even wrote a ~/.ssh/config -- to help identify
[01:07] <spiv> palhmbs: that error suggests to me that you have some sort of typo in your URL, e.g. if I typo my username in the URL I get 'bzr: ERROR: Invalid url supplied to transport: "lp:~spivv/+junk/hmm": No such person or team: spivv'
[01:08] <palhmbs> spiv, no -- fulltext is:  bzr: ERROR: Invalid url supplied to transport: "lp:~palhmbs/ppa-for-gtg/trunk": No such project: ppa-for-gtg
[01:08] <palhmbs> I did try -- bzr push sftp://palhmbs@bazaar.launchpad.net/~palhmbs/ppa-for-gtg -- but got -- bzr: ERROR: Permission denied: "/~palhmbs/ppa-for-gtg": [Errno 13] mkdir failed
[01:08] <spiv> palhmbs: ah, that's your problem: "No such project: ppa-for-gtg"
[01:09] <palhmbs> so um, where does it go when you push to +junk ??
[01:09] <spiv> palhmbs: when you push to +junk it goes to +junk
[01:09] <palhmbs> because bzr push bzr+ssh: -- is working... :-0
[01:10] <spiv> palhmbs: you'd also be able to use "lp:~palhmbs/+junk/something" I'm sure
[01:10] <spiv> palhmbs: "+junk" is basically a special name for "no associated project"
[01:10] <palhmbs> thanks - right np
[01:10] <spiv> palhmbs: otherwise that part of the URL has to be the name of an actual project on Launchpad
[01:12] <palhmbs> and I have to package specially for a PPA...
[01:12] <palhmbs> I see... I think -> b <- thumbs up
[01:15] <palhmbs> ah well - my code can live in junk for awhile.
[01:20] <mwhudson> yes, i have to admit i went by the description more than the diff for jam's branch
[01:45] <jbowtie> I think there's a revision in my repository that *should* be the head revision for the current branch, but isn't.  Can anyone remind me how to locate it?
[01:48] <mwhudson> jbowtie: bzr heads --dead
[01:48] <mwhudson> which is in bzrtools
[01:51] <jbowtie> mwhudson: thanks, I don't have bzrtools installed on this server, is why I couldn't find it.
[01:51] <mwhudson> np
[01:56] <jbowtie> OK, I do have a dead head, can I reattach it?
[01:57] <mwhudson> if you already have a branch that should have that as a head, i think bzr pull -r $dead_head in the branch should be all it takes
[02:02] <jbowtie> mwhudson: Hmm, didn't work. Looks like I will have to investigate further.
[02:03] <mwhudson> jbowtie: what failed?
[02:03] <mwhudson> maybe you need --overwrite or something, or maybe you should do 'bzr init new-branch; cd new-branch; bzr pull -r revid:$dead_head'
[02:04] <mwhudson> ah, i forgot the "revid:" bit before
[02:07] <jbowtie> mwhudson: Trying with overwrite; I knew enough to put in "revid:"
[02:09] <jbowtie> mwhudson: It's trying to pull from the parent branch in a foreign vcs instead of pulling the existing rev from the repository.
[02:09] <mwhudson> oh
[02:09] <mwhudson> !
[02:10] <mwhudson> jbowtie: pull -r revid:$deadhead .
[02:10] <mwhudson> that . is important :)
[02:10] <jbowtie> Brilliant, that did it.
[02:11] <mwhudson> good!
[02:15] <jbowtie> Interesting, there are two other dead heads that are missing from the branch history. I might need to write a splice command to insert them where they belong.
[02:25] <thumper> hmm...
[02:25] <thumper> I want to add an existing branch as a pipe in a pipeline
[02:25] <thumper> not so easy it seems
[02:35] <mwhudson> thumper: probably easiest to move the branch out of the way, add the pipe, and then move the branch back?
[02:35] <thumper> mwhudson: I just did add-pipe oldbranch-copy, then pulled the other branch into it
[02:36] <thumper> I really should file a bug on pipelines
[02:36] <mwhudson> ah righ
[02:36] <mwhudson> t
[02:36] <mwhudson> yeah
[02:42] <thumper> bug 716826
[02:45] <maxb> Is there a document I can read which outlines bzr's architecture concerning unicode and bytestrings?
[02:46] <maxb> e.g. is revision.message supposed to be a utf8 bytestring or a unicode object. Likewise file-ids. etc.
[02:46]  * maxb is trying to rescue bzr-xmloutput
[02:48] <poolie> maxb i think this is discussed in HACKING
[02:48] <poolie> generally, ids are utf8 byte strings
[02:48] <poolie> (because they are normally opaque)
[02:49] <poolie> messages, filenames, etc should match the general python advice of converting from bytes to unicode on entry/exit of the program
[02:51] <maxb> ah.... I grepped doc/developer/ and found not much :-)
[02:55] <lifeless> jam: I think I may have fixed the spam on proposals to lp:loggerhead
[02:55] <lifeless> jam: please let me know if you get another
[03:27] <jam> lifeless: I got one about 3 hours ago, but that predates your message from 30min ago
[03:28] <lifeless> yeah, I changed it 30 minutes ago
[03:28] <lifeless> it may be incomplete
[03:28] <lifeless> at which point I'll be asking thumper
[03:28] <lifeless> and then following htat reading code t figure out wtf the rules are
[03:28]  * thumper looks up here
[03:48] <jam> lifeless: just got a rejected message as of 1min ago
[03:48] <lifeless> bah
[03:48] <lifeless> what list ?
[03:49] <jam> launchpad-bugs-owner@lists.canonical.com
[03:50] <jam> looks like it was trying to send to "launchpad-bugs@lists.ubuntu.com"
[03:50] <jam> X-Launchpad-Message-Rationale: Subscriber @loggerhead-team
[03:50] <lifeless> ~launchpad
[03:50] <lifeless> sigh
[03:50] <lifeless> what branch
[03:52] <jam> lifeless: that was trunk-into-experimental, so the target should be ~loggerhead-team/launchpad/experimental
[03:52] <jam> I don't know about others yet
[03:52] <jam> though I'll be proposing something tonight
[03:52] <lifeless> they need to be configured individually
[03:53] <lifeless> right, changed the subscription for loggerhead team to 'no email'
[03:53] <lifeless> mmm
[03:53] <lifeless> actually, I'll try a direct sub + no email on that
[03:53] <lifeless> this is a fraking annoying list config
[03:54] <lifeless> fingers crossed
[03:57] <lifeless> mwhudson: hi
[03:57] <lifeless> mwhudson: what stops us using loggerhead as an egg?
[03:57] <mwhudson> lifeless: probably nothing
[03:57] <lifeless> does lp import it as a bzr plugin, or as a top level item?
[03:57] <mwhudson> top level currently
[03:58] <lifeless> cool
[03:58] <lifeless> ok, we might want to do that soon
[03:58] <mwhudson> otherwise my answer would have been different :-)
[03:58] <mwhudson> yeah, should be easy
[04:02] <maxb> jam: ooi, why would PQM be good for lp:loggerhead (compared with pretty much all the other bzr plugins in Launchpad not using it) ?
[04:02] <poolie> maxb, what do you mean?
[04:02] <jam> maxb: because *I* want it?
[04:03] <jam> poolie: none of the bzr plugins use a bot to manage trunk
[04:03] <poolie> if you want to set one up i'd rather we try this on tarmac
[04:03] <maxb> Indeed. I am just curious as to the motivation for doing loggerhead differently
[04:03] <jam> poolie: well, I don't want to maintain it..
[04:03] <jam> or have it running on my personal hardware, etc.
[04:04] <jam> I certainly don't want to have to be online for people to land things
[04:04] <poolie> and you feel you'd have to maintain it if it was tarmac but not pqm?
[04:04] <poolie> no, i don't think you should either
[04:04] <poolie> and i think enforcement of the test suite would be good
[04:04] <jam> poolie: does canonical have Tarmac running in the DC somewhere?
[04:04] <poolie> yes, i believe other teams are using it
[04:04] <poolie> u1 iirc
[04:04] <jam> since I've poked on the project, it was always run on personal hardware
[04:04] <jam> but that was a while ago
[04:05] <jam> lifeless: so far, I can't tell the colorscheme difference between old-trunk and pqm, I'm still trying to figure out the screeshots you would want
[04:05] <jam> looks pretty identical to me
[04:06] <jam> stupid, that's because I reverted it to experimental's tip, where I had already merged the trunk updates....
[04:06] <jam> stupid stupid
[04:07] <jam> lifeless: pqm's loggerhead uses orange, Experimental uses blue
[04:07] <jam> for the menus at least
[04:10] <lifeless> so, I'd like someone - curtis perhaps, or huwshimi, to be briefed on the situation, and make a recommendation.
[06:01] <lifeless> jam: does the raw controller output the byte content directly, or does it htmlise it just without annotation ?
[06:02] <jam> lifeless: raw content
[06:02] <jam> no html
[06:02] <jam> same as /download but not Content-disposition: Attachment
[06:02] <lifeless> in which case thats an experimental only thing, right ?
[06:02] <lifeless> its not in trunk yet
[06:02] <jam> lifeless: I believe so
[06:03] <lifeless> cool
[06:03] <lifeless> I won't leap on it in a panic then :)
[06:03] <jam> lifeless: thats the xss concern?
[06:04] <lifeless> yes
[06:05] <lifeless> I know there is a similar answer to lps, but we need to write the glue - which includes adding a API for allocating the time limited tokens and gluing that into the Application
[07:32] <vila> hi all !
[07:37] <mr-russ> Hi,
[07:37] <mr-russ> more questions today.
[07:38] <mr-russ> When converting from SVN, can I get tags converted bzr tags rather than branches?
[07:39] <lifeless>    exarkun@divmod.com-20110209125926-8d98psdzhqru0vrs
[07:54] <poolie> mr-russ, i think bzr svn-import can/will do that?
[07:55] <mr-russ> K, I used svn2bzr.py and it's not created a shared repo or tags that do what I want.
[07:55] <mr-russ> will look further at svn-import.
[07:55] <mr-russ> What is the implication of non-determinsic revisions?
[07:55] <mr-russ> I got a little worried when reading that in the docs as I don't know the implications of it.
[08:00] <mr-russ> svn$ bzr svn-import civian
[08:00] <mr-russ> Using repository layout: trunk0
[08:00] <mr-russ> bzr: ERROR: exceptions.TypeError: fetch() got an unexpected keyword argument 'needed'
[08:00] <mr-russ> ??
[08:01] <poolie> that looks a lot like an out-of-date plugin
[08:01] <poolie> please file a bug with the traceback from .bzr.log and paste the number here
[08:01] <mr-russ> just installed against lucid.
[08:01] <poolie> or just update bzr-svn
[08:01] <mr-russ> will file bug now.  is there a fast way from command line to do it?
[08:02] <mr-russ> it fails because I wasn't importing into a repository.
[08:02] <mr-russ> which it didn't complain about.
[08:24] <poolie> ah, well, that's a bug worth filing
[08:24] <poolie> but lucid's a bit old, and it might be fixed by now
[08:24] <poolie> there's a ppa with newer builds of bzr and plugins
[09:29] <Lo-lan-do> Hi all :-)
[09:29] <Lo-lan-do> It seems that bzr diff --using "wdiff -n" ceased working recently…  Is that known?
[09:30] <Lo-lan-do> It apparently tries to run a command called "wdiff -n", rather than running wdiff with a -n option.
[09:31] <Lo-lan-do> strace shows: execve("/home/roland/bin/wdiff -n", ["wdiff -n", "/tmp/bzr-diff-Gf9RoE/old/Makefil"...,
[09:31] <jelmer> Lo-lan-do: not sure - can you file a bug?
[09:32] <Lo-lan-do> Sure
[09:57] <mr-russ> I migrated from svn, my tags are now showing in bzr tags;  as TagName  ?
[09:58] <mr-russ> I thought, there are not version numbers, so the tag is useless.  I'll delete those tags.
[09:58] <mr-russ> when I delete a tag and try and commit, it tells me nothing has changed.  How do I commit and push/pull tag changes?
[09:58] <mr-russ> bzr 2.1.x lucid installation
[09:58] <jelmer> mr-russ: you can use them, but since they have no relation to the curretn revisin tip we can't print a revision number
[09:58] <jelmer> mr-russ: tags are independent of commits in bzr
[09:58] <mr-russ> really.
[09:59] <jelmer> after a tag has been deleted there's no need to do a commit
[09:59] <mr-russ> how to I keep tags in sync between people.
[09:59] <mr-russ> get push the tag delete.
[09:59] <mr-russ> How do I push the tag addition or deletion,  as push says, no revisions to push.
[10:01] <mr-russ> https://lists.ubuntu.com/archives/ubuntu-mobile/2008-March/001625.html
[10:01] <jelmer> push will actually push new tags even if there were no revisions pushed
[10:01] <mr-russ> hopefully that comment is true.
[10:02] <mr-russ> Not exactly noob friendly though.
[10:02] <jelmer> yes, the push ui should be clearer if it actually updated any tags
[10:03] <mr-russ> another question about my ? tags.  How do I use them.  If I bzr update -r tag:Release_1_1  I get;
[10:03] <mr-russ> bzr: ERROR: branch has no revision svn-v4:deb830e7-bb10-0410-bcbb-ea420f43d34b:tags/Release_1_1:16
[10:03] <mr-russ> bzr update --revision only works for a revision in the branch history
[10:04] <mr-russ> jelmer: You said I could use them, however I'm not sure how to.
[10:06] <jelmer> e.g. 'bzr branch yourbranch -rtag:Release_1_1 newbranch'
[10:06] <jelmer> depending on how the branch was cloned it might not have copied all the tag contents though
[10:06] <jelmer> svn-import should have copied all the tag contents
[10:07] <mr-russ> yeah, but I put that on a remote shared repository.  I think branched trunk.
[10:08] <mr-russ> $ bzr branch . -r tag:Release_1_1 ../civian-1.1
[10:08] <mr-russ> bzr: ERROR: The branch . has no revision <RevisionSpec_tag tag:Release_1_1>.
[10:08] <mr-russ> so trunk doesn't have the tag revision information?
[10:08] <mr-russ> I think I was better off when not attempting to import from svn.
[10:10] <jelmer> mr-russ: svn-import will import all the tags, and there's an open bug about 'bzr branch' importing all the tags even if they're not pointing at revisions in the branch itself
[10:11] <mr-russ> okay.  I might just delete them as they are confusing and move along.
[10:11] <jelmer> if you're doing a conversion, I'd recommend svn-import
[10:11] <jelmer> if you're just trying to contribute to an existing svn branch, bzr branch
[10:12] <mr-russ> I ran svn-import to convert a repository.  Put that repository using scp on another server.  then did bzr branch remote_location;  bzr tags
[10:12] <mr-russ> and have the ?'s
[10:13] <mr-russ> interesting.  delete tags, bzr push.  tags gone.  bzr pull, tags back.
[10:14] <bialix> heya
[10:14]  * bialix looking for vila
[10:15] <bialix> bonjour vila
[10:15] <vila> hey bialix !
[10:15] <bialix> I have question about our internal config machinery
[10:16] <vila> .me all ears
[10:20] <vila> bialix: I'm still holding my breath, don't be too long ;)
[10:20]  * fullermd waves vila around by the ears.
[10:20] <vila> ouch
[10:20] <vila> I'm not *that* small anymore you know !
[10:20] <fullermd> Well, it's probably more comfortable than bialix jamming our internal config machinery into them...
[10:21] <bialix> sorry
[10:21] <bialix> phone call
[10:21] <vila> haa, ok, np
[10:21]  * vila breathes again
[10:22]  * vila goes to polishing config rough edges a bit more to ease with ears
[10:22] <bialix> Bug 716384
[10:22] <bialix> vila: in qbzr.conf I have such line
[10:22] <bialix> diff_window_maximized = True
[10:22] <bialix> in qbzr/lib/utils.py we trying to read it
[10:23] <bialix> is_maximized = config.get_option(name + "_window_maximized")
[10:23] <bialix> the bug is:
[10:23] <bialix> first time the option read as u'True' (unicode sting)
[10:23] <bialix> second time the option read as bool True
[10:23] <bialix> why?
[10:24] <vila> O_o
[10:25] <fullermd> The machines...  they're taking over!
[10:25] <vila> err, short answer will be use get_user_options_as_bool
[10:25] <bialix> vila: you mean always use another method?
[10:26] <vila> bialix: I mean stop relying on configobj, use bzrlib.config ;)
[10:27] <bialix> bzrlib.config does not have the method to delete options
[10:27] <bialix> or it has now?
[10:27] <vila> bialix: more half-seriously, configobj can be weird, I can't answer precisely, that may be a configobj bug, but you could probably avoid it using bzrlib.config
[10:27] <vila> it has now
[10:28] <vila> well, not all cases are covered but the ones you use should be (not all sections can be reached now I think)
[10:28] <bialix> I need Gary to talk about
[10:28] <vila> err, looking at the code, even sections are supported
[10:29] <vila> so the missing bit is probably only in 'bzr config' actually
[10:29] <vila> i..e: you don't have to care
[10:29] <vila> 'bzr config' doesn't support qbzr.conf either anyway
[10:31] <vila> by the way, if you move to bzrlib.config only, the long term plan is that qbzr options should be supported by bazaar.conf, locations.conf, branch.conf, zoo.conf by prefixing them by 'qbzr.',  i.e. qbzr.log_window.size and the like
[10:32] <vila> or even qbzr.log.window.size or whatever
[10:32] <vila> not sure it makes sense to have branch specific window locations though
[10:33] <bialix> щл
[10:33] <bialix> ok
[10:33] <vila> but at least you'll get the opportunity to decide and won't need to handle an additional config file anymore
[10:33] <bialix> thank you vila
[10:33] <bialix> I need to talk with Gary first
[10:34] <maxb> it may be better to not put gui sizing caching in bazaar.conf
[10:34] <bialix> he has changed our internal config machinery a lot in the recent times
[10:34] <maxb> it irks me that bzr-gtk does
[10:34] <bialix> maxb: it's not actually
[10:35] <maxb> as this makes sharing a bazaar.conf between machines messy
[10:35] <bialix> btw vila, if configobj so weird as I think what if the same bug will be hit by bzr core with reading bool option twice?
[10:36] <bialix> ah, I see
[10:36] <vila> bialix: well, get_user_option_as_bool with return either a bool or None, but never a string
[10:37] <bialix> you have explicit check that incoming value is a string in bool_from_string
[10:37] <bialix> actually that method returns either object itself (bool) or convert from string
[10:37] <vila> maxb: yup, that's one thing that should be considered. The idea is that you define ConfigOptions specifying in which files they can appear
[10:38] <bialix> I'm going to adopt that function only for now
[10:38] <vila> bialix: use the one from ui and you'll be fine until you migrate to bzrlib.config
[10:38] <bialix> ok
[10:38] <bialix> many thanks
[10:39] <bialix> even talking to wise man help to understand the problem and solutions
[10:40] <vila> maxb: deciding in which file config options should be allowed become trickier when remote branches or repos are involved (not to mention bazaar.conf and locations.conf on a smart server...)
[10:41] <vila> maxb: and that's ignoring the side-effects if both  smart and a dumb server are used for the same branch (with config files access allowed for the smart server but not for the dumb one...)
[10:51] <bialix> vila: ok, another problem
[10:51] <bialix> it seems configobj can't store to config bool value
[10:52] <bialix> do you have set_option_as_bool in bzrlib.config?
[10:58] <bialix> configobj -> :-/
[11:03] <maxb> Hi poolie  - thanks for the ~maxb/bzr/make-lp-mirror-work review - was that "good, I'll PQM it later when I have a moment" or "good, find someone on IRC to PQM it" ?
[11:08] <fullermd> Speaking of qbzr, what's up with the fix on bug 715067?  Shouldn't it fall back to bzrlib?
[11:08] <jelmer> hi jam
[11:09] <bialix> vila: bzr config --scope <-- ???
[11:09] <bialix> what scope could be?
[11:09] <bialix> fullermd: yes, it should
[11:09] <jelmer> maxb: I think poolie is off for his evening, I can have a look at landing it
[11:10] <bialix> actually it should use copy from bzrlib first
[11:11] <vila> bialix: afk abit, will answer later
[11:12] <jelmer> spiv: still there?
[11:13] <bialix> vila: np
[11:17] <vila> bialix: so, set_user_option is enough, we store only strings and there is probably a '%s' somewhere in configobj for turning bools into proper strings
[11:17] <bialix> vila: apparently it's not
[11:18] <bialix> I mean configobj lost boolean options for me
[11:18] <vila> bzrlib.config
[11:18] <bialix> ok. I understood you
[11:18] <bialix> already sent mail to Gary asking
[11:19] <vila> the idea is that only strings are handled in files, get_user_option_as_xxx just convert for convenience, every{thing,one} else should deal with strings and only strings
[11:20] <vila> unicode even, stored as utf-8 in config files
[11:20] <bialix> the idea is perfect, but the reality is not
[11:22]  * bialix is not happy
[11:25] <spiv> jelmer: sort of
[12:52] <Miika--> Hello! I first added accidentally some files to my bzr repo and then I did bzr revert and added right files and committed. But thing is, that I really didn't know what revert does... So all the work I hadn't changed was gone from working copy... Is there any way to get them back?
[12:53] <jelmer> Miika--: revert should have created backup files for all the files it reverted
[12:53] <Lo-lan-do> Look for the *.~1~ files
[12:55] <Miika--> Oh, thanks a lot. Everything ok.
[12:57] <jelmer> maxb: hi
[12:57] <maxb> hi
[12:58] <jelmer> maxb: One of the points of the daily builds is to catch the test failures, I'd rather not mask them by running the tests in a UTF8 locale
[12:59] <maxb> jelmer: bzr-xmloutput's encoding behaviour is pretty broken internally. As far as I can tell, the entire plugin is only sanely usable in a UTF-8 locale at all. It needs a major internal overhaul for sane encoding behaviour
[13:00] <jelmer> maxb: if it's really that bad I think we should probably not ship it at all, or at the very least it would've been nice to discuss this change upfront
[13:03] <maxb> The reason I felt comfortable directly committing the change was that I believed that there was absolutely no possibility of the testsuite passing otherwise - was I wrong in that belief?
[13:03] <pindonga> hi, I want to write a python script that uses a bzr plugin internally... is there an easy way to access a plugin's code, as that resides not in the standard python path?
[13:04] <pindonga> I was thinking of using some utility of bzrlib to get to the plugin maybe?
[13:04] <jelmer> maxb: that's not wrong, but the goal is to actually fix the test failures rather than hiding them
[13:05] <maxb> Agreed - I wouldn't have done that to mask test failures, I only thought it a reasonable course of action because the actual non-test plugin code is just outright broken in non-UTF8 locales, so at least this makes the tests test the current capabilities of the plugin
[13:06] <maxb> pindonga: import bzrlib.plugin; bzrlib.plugin.load_plugins(); import bzrlib.plugins.myplugin
[13:07] <pindonga> maxb, great! thanks
[13:09] <jelmer> maxb: Fixing the plugin for non-utf8 locales isn't impossible, so it would've been nice to discuss this.
[13:12] <jelmer> maxb: Anyway, not to take away from all the other nice work you've done on getting the daily builds working again.
[13:12] <jelmer> maxb: Are you going to forward the bzr-dbus patch upstream?
[13:13] <maxb> jelmer: Understood. Again - the only reason I even considered this committable was because I thought I was taking the packaging from a state of being completely unbuildable on any buildd - and thus I couldn't possibly be making things worse, since I *believe* it could never build before.
[13:14] <maxb> Have the bzr-xmloutput tests ever passed on a buildd before?
[13:15] <jelmer> maxb: no, which is exactly why I didn't mind that they were failing - bzr-xmloutput simply wouldn't land in the daily builds PPA until the plugin was fixed
 maxb: Are you going to forward the bzr-dbus patch upstream?  --- whoops, I pushed it but forgot to merge-propose. Done.
[13:20] <jelmer> maxb: r=me
[13:21] <maxb> Regarding the bzr-xmloutput tests - since it's present in ubuntu and debian, I think it's a net improvement to be able to run the tests on build in a forced UTF8 locale than not being able to run the tests on build at all
[13:21] <maxb> But yes, it's not a good final state to remain it.
[13:22]  * maxb --> lunch
[13:27] <jelmer> maxb: why the extra PYTHONPATH override in bzr-dbus' debian/rules /
[13:29] <jelmer> 'morning jam
[13:56] <vila> jelmer: hi almost-PP ;) I'm not sure jam is up yet, there have been random reconnections for a couple of hours
[13:57] <maxb> jelmer: slightly pointless here, I suppose. It's there because I copied the concept from something I was working on for bzr itself, where it lets the compiled extensions be loaded.
[13:58] <jelmer> maxb: ah, ok
[13:59] <fullermd> Yeah, who in his TZ would be up at this time of day?   :p
[13:59]  * jelmer has learned to stop looking for a correlation between location and timezone
[14:00] <jelmer> vila: heh, ok
[14:02] <vila> fullermd: between you and jelmer, I long ago stopped trying to correlate presence here and TZs
[14:02] <vila> hmm, I should have included myself in this list ;)
[14:04] <fullermd> Nah, _we_ never tell you anything.  Why should you?
[14:05] <vila> I don't need anybody to listen to when I talk here ? Is that what you're saying ?
[14:06] <fullermd> Eh?  Who said that?
[14:07] <jelmer> Did somebody say something?
[14:10] <guilhembi> jelmer: hello! I'm reading a debian changelog:
[14:10] <guilhembi>   [ Jelmer Vernooij ]
[14:10] <guilhembi>   * Cherrypick fix for compatibility with python2.7 >= 2.7.1-2.  LP: #693880
[14:10] <guilhembi>   * Switch to python-support. Closes: #568462
[14:10] <guilhembi>   * Add missing build dependency on python-configobj.
[14:10] <guilhembi>   * Make dependency on python-testtools versioned (>= 0.9.5).
[14:11] <guilhembi>   * Re-remove included elementtree and configobj. Closes: #555343, #555336
[14:11] <guilhembi> ...
[14:11] <guilhembi>  -- Jelmer Vernooij <jelmer@debian.org>  Fri, 21 Jan 2011 22:08:19 +0100
[14:11] <guilhembi> So in the debian version of bzr, bzr's configobj is removed. Is that "deviation" from the stock bzr expected to stay?
[14:12] <guilhembi> I'm asking, because it caught us: we have a plugin which does
[14:12] <guilhembi> "from bzrlib.util.configobj import configobj"
[14:12] <guilhembi> and it always worked, and it still works with bzr.dev or the normal bzr installs, but not with Debian's latest bzr...
[14:13] <guilhembi> We solved it by falling back to the system configobj if bzr's is missing, but I thought I'd ask...
[14:13] <guilhembi> eof
[14:13] <jelmer> guilhembi: it's actually been there in the past as well, but because of a regression we still shipped it
[14:14] <jelmer> guilhembi: we could import the system configobj to bzrlib.util.configobj, but one of the concerns is that the system configobj isn't exactly the same as the one that is shipped with bzr
[14:15] <guilhembi> jelmer: won't there be deviations over time: if bzr's configobj behaves differently from the system configobj, bzr will break on Debian...?
[14:15] <guilhembi> Or is there a plan to delete configobj from the stock bzr too, to be consistent everywhere?
[14:15] <jelmer> guilhembi: we can verify it's sufficient for bzr - we run the testsuite to do so
[14:16] <guilhembi> ok...
[14:16] <jelmer> guilhembi: I don't think there are any plans to remove it from stock bzr, but we should probably make it private
[14:17] <maxb> I was going to try to insert some sort of compatibility, but it turns out it's not trivial to alias a python module under a different name.
[14:19] <maxb> You can make it work, I think, if you're willing to assume everyone uses "from bzrlib.util.configobj import configobj", but you can't make it fully compatible such that "import bzrlib.util.configobj.configobj" works as it did before the removal
[14:46] <jam> jelmer, vila: Well, I did reconnect to IRC, but I wasn't really online yet. I think my son was playing with my laptop while I was sleeping.
[14:47] <vila> haaaa, this explains all these branch deletions then, I was wondering...
[14:47] <vila> jam: morning :)
[14:48] <jam> maxb, guilhembi: On Debian and Ubuntu we plan on using the system configobj if possible. I believe we just didn't want to require people running from source to have it installed. (We did the same for ElementTree a long time back.) As for divergence... that is why we run the tests as part of the build process now.
[14:48] <jam> vila: oh noes! my super-important-but-not-backed-up work
[14:48] <jam> vila: I guess it's bzr revert for me
[14:48] <vila> :)
[14:49] <maxb> jam: I think the problem here is more that by placing copies within bzrlib.util, they become part of bzrlib's API in the perception of plugin authors
[14:53] <guilhembi> maxb: indeed, in the latest qbzr:
[14:53] <guilhembi> ./lib/util.py:from bzrlib.util.configobj import configobj
[14:53] <guilhembi> (http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/)
[14:53] <guilhembi> that will break on Debian, unless Debian has a custom qbzr?
[14:54] <jelmer> Debian has a patched qbzr, but the qbzr devs are also fixing it upstream
[14:55] <fullermd> Yeah, right now it's fixed so it doesn't work on my non-Debian system   :p
[14:55] <jelmer> fullermd: what's a non-Debian system ? :P
[14:56] <fullermd> jelmer: It's a thing with up to date software   :p
[15:05] <ssandberg> hi! when bzrgtk is installed, is there a way to detect from a pre-commit hook of another plugin whether this was a gcommit or a commit ?
[15:07] <jelmer> ssandberg: not really - why would you want to?
[15:07] <jelmer> ssandberg: I mean, you could inspect the stack..
[15:07] <ssandberg> jelmer, the plugin needs to display a message. would be nice if the message was a dialog for gcommit and a text for commit
[15:12] <jam> maxb: everything in util is 3rd party code, hence the 'util' section. So the general recommendation is to do stuff like "try import foo except ImportError: import bzrlib.util.foo" or something along those lines.
[15:12] <jam> (possibly reversed)
[15:13] <maxb> Right, but is that actually stated as a mandatory rule of bzrlib api compatibility?
[15:41] <jml> hello
[15:41] <jml> just another vote for fixing that thing where merging branches that delete directories that contain build artifacts causes conflicts.
[15:43] <vila> jml: you haven't paying attention to bzr.orphan_policy=move don't you ?
[15:43] <vila> s//been/
[15:44] <vila> err, bzr.transform.orphan_policy=move
[15:44] <jml> vila: no. it's been a long time since I've read NEWS file, and I don't recall seeing it mentioned in release announcements.
[15:44] <vila> jml: it's off by default :-/
[15:45] <vila> jml: I thought you were subscribed to the relevant bug and every day since I landed the fix I waited for your feedback ;-(
[15:46] <jml> vila: I saw that it had been split into two bugs and lots of talk about possible ways of fixing but nothing about it actually being fixed. maybe it slipped by.
[15:48] <vila> hmm, I don' remember the details... oooh, now that you mention it, yeah a more complete solution has been asked for, but for your particular case, the config option should do
[15:48] <vila> jml: as always, bugs and feedback welcome ;)
[15:48] <vila> jml: and sorry for not telling you more directly, I didn't realize you missed it
[15:48] <jml> vila: np.
[16:38] <vila> jelmer: I didn;t dream after all: bzr-builddeb 2.6+bzr518~lucid1
[16:39] <jelmer> vila: ah, the daily builds have 2.6 :-/
[16:39] <vila> yeah, so the upstream should too no ?
[16:40] <vila> jelmer: and sorry for not pointing you there yesterday, Alzheimer... you'll see... pain...
[16:40] <jelmer> no, the daily builds debs have it completely wrong - they claim to be /post/-2.6
[16:40] <jelmer> vila: hey, you're talking to the guy who probably actually set it to 2.6 in that recipe...
[16:40] <vila> lol
[16:41] <vila> thanks, I feel better ;)
[16:43] <vila> grr, no whoami set, grr
[16:43] <jelmer> vila: What, and bzr let you commit without a whoami set??
[16:43] <vila> hehe, no indeed
[16:44] <vila> but in this particular case I don't want to set one... err... let me explain :)
[16:44] <vila> on my local package importer I don't want a whoami set in bazaar.conf, except that I'm fixing a bug and I need to commit...
[16:45] <vila> and I don't think I can set one in branch.conf... let's try locations.conf
[16:46] <vila> Yes !
[16:46] <vila> <evil grin>
[16:47] <jelmer> hehe
[16:47] <vila> jelmer: point is (playing the devil's advocate), the actual behaviour suits me :)
[16:48] <jelmer> vila: would it have been sufficient if it just warned?
[16:48] <vila> if we add a warning, we may think about adding an option for restoring the *actual* behavior
[16:48] <vila> in that precise case no
[16:48] <jelmer> I guess we can have a tri-state option ("strict", "guess", "warning") that defaults to "warning" ?
[16:48] <vila> I want to stay without a default whoami because I'm paranoid here, I don't want to commit anything so I won't push anything to lp
[16:49] <vila> but that's one a good reason to keep the actual behaviour as the default one, hence the option mentioned above
[16:50] <jelmer> jam: hi
[16:50] <jelmer> jam: I'm digging into my lazy hooks work again, and am wondering if your comments on lp:~jelmer/bzr/lazy-hooks-pt1 were perhaps intended for lp:~jelmer/bzr/lazy-hooks ?
[16:53] <jam> jelmer: possibly
[17:24] <vila> jam: did you get some feedback on the forked server ?
[17:24] <jam> vila: I've put up a lot here: https://wiki.canonical.com/IncidentReports/2011-02-11-Codehosting-Forking-Service-Down
[17:24] <jam> from what I can glean from the logs
[17:25] <jam> but there is a 30-min gap where we don't have any logs... :(
[17:25] <jam> and things are fine before it, and failing after it
[17:25] <jam> the forking service itself was up and running and still servicing connections until it was stopped
[17:25] <jam> so it might be bugs in the Twisted code I wrote
[17:25] <jam> by the time it started failing (that I can see) it seems that Conch was out of file-handles
[17:25] <vila> ha, right, so, AIUI, there was some 'no more fd available' at some point
[17:25] <jam> maybe we have a handle leak in there
[17:25] <vila> yup
[17:26] <jam> vila: well, there were a lot of "no random entropy source available" which could have been masking no-more fd
[17:26] <jam> but there was one no more fd at some point
[17:26] <vila> right, that was the piece of info I wanted to make sure you had
[17:32] <jam> vila: any idea why os.urandom would be failing?
[17:33] <jam> I was trying to check the Python source code, but it looks to me like "urandom" is only available for #MS_WINDOWS and #__VMS, but that doesn't make any sense, since I see it on babune
[17:33] <vila> O_o
[17:33] <jam> but the code tries os.urandom before it tries to open the file
[17:34] <vila> /dev/urandom exists here indeed
[17:34] <jam> vila: so, in "os.py" if there isn't a built-in random, it creates one by opening /dev/urandom
[17:34] <jam> built-in urandom
[17:35] <jam> however, that also doesn't make sense, since Babune says it is a builtin function
[17:35] <jam> ah wait, that is locally, let me check babune again
[17:35] <jam> it is the native one
[17:35] <jam> which opens the file
[17:36] <jam> vila: so... if open() is failing, then you will, indeed, get secureRandom failures
[17:37] <jam> now the question is how do you find those...
[17:38] <vila> jam: IMHO you'd better check on the code hosting host, it probably runs lucid for one so babune may not be the best reference
[17:38] <vila> hosting host...
[17:59] <jam> vila: I just checked the python source code. I'm not worried about it, I doubt it changes much
[17:59] <jam> /usr/lib/python26/os.py
[17:59] <jam> Implements 'urandom' in pure python by opening /dev/urandom
[18:06] <vila> bzr 2.3.0 is still in the upload queue :-/
[18:07] <vila> what;s the process from there ? Is it automatic or should someone approve something ?
[18:07] <jelmer_> vila: which upload queue?
[18:07] <vila> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=&start=30
[18:09] <jelmer> I think it needs an archive admin to look at it
[18:09] <jelmer> uhm
[18:09] <jelmer> I think it needs be looked at by an archive admin
[18:12]  * vila summons archive admins
[18:12]  * vila needs more goats
[18:13] <jelmer> hehe
[18:15] <fullermd> I've got a chicken with a mean temper; is that close enough?
[18:17] <vila> fullermd: what ? You're supposed to be my goat official provider remember ?
[18:17] <vila> nokia/microsoft and now no more goats >-/
[18:18] <vila> I can live without a mobile phone but...
[18:19] <jelmer> maemo was great in that it could run bzr-gtk out of the box :)
[18:19] <fullermd> Sadly, work has got my goat.
[18:21] <vila> wow, you mean you work with no goat at all now ? Scary...
[18:22] <fullermd> Well, wandering around bleating about it won't help anything, so...
[18:23] <jelmer> vila: I'm trying to add a function somewhere that returns an old bzr format (e.g. one that uses old style locking, or doesn't support stacking)
[18:24] <jelmer> vila: and I'm not sure where to put it. bzrlib.tests.TestCase already has enough stuff on it. Would it work as a fixture?
[18:24] <vila> jelmer: whatever you chose, make sure it's well hidden ;)
[18:25] <vila> fixtures sounds like a better place than test case, especially if you prefix it when you use it ;-D
[18:52] <jelmer> vila: did you see my comment about the contact address for udd?
[18:52] <vila> no ?
[18:53] <jelmer> vila: it still mentions james as the contact address in case of broken imports at the moment
[18:53] <jelmer> vila: s/it/the web page/
[18:54] <vila> hmm, right (how did I miss that 8-/)
[18:54] <vila> s//#bzr on freenode / ?
[18:54] <jelmer> vila: in the MP
[18:55] <vila> ooh, I see your comment now, I often have a hard time when you don't leave a blank line ;-/
[18:56] <vila> but do we want to put a real email there ?
[18:56] <vila> I thought james_w put his name (instead of his email) to avoid spam ?
[18:57] <jelmer> vila: Perhaps we could just mention the list, or the bug tracker
[18:57] <jelmer> I'll try to remember to leave a blank line next time :)
[19:00] <vila> jelmer: the bug tracker is now mentioned, I was about to put an URL for the list, but the page contains the email, so i think I will just put the email ;)
[19:00] <jelmer> wfm :)
[19:05] <cody-somerville> Is there a document that describes bzr error codes?
[19:05] <cody-somerville> It seems like 3 is used when there are no changes to commit AND when the bound branch is out of date with the master branch.
[19:15] <jelmer> cody-somerville: IIRC we use three different exit codes - success, failure and success but e.g. differences (for bzr diff)
[19:46] <jam> cody-somerville: we only really use 0, 1, 3
[19:47] <jam> cody-somerville: and I'm pretty sure we don't distinguish for those particular cases
[19:48] <shakaran> Hi, I would contribute with bazaar translating the docs to spanish, where should I start for find the files, maybe on rosetta launchpad?
[19:58] <fullermd> I'm pretty sure it's all in a branch somewhere; I don't believe the bzr project uses Rosetta.
[20:41] <cody-somerville> Odd.
[20:43] <cody-somerville> I just did an update of a branch that fetched a single small revision, that took 7.675s. Doing it again took 7.970s immediately after (tree is up to date).
[20:43] <lifeless> most of that is probably ssh handshaking
[20:43] <lifeless> + bzr invocation on the server side
[20:43] <lifeless> we have an improvement in the works but it blew up when we deployed it last night
[20:44] <cody-somerville> ah, cool.
[20:47] <jam> cody-somerville: "time echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes"
[20:47] <jam> that gives the baseline time for bzr to handshake to the server
[20:48] <jam> hi lifeless
[20:48] <lifeless> hi jam
[20:50] <jam> lifeless: the symptoms all point to a file-descriptor leak, but I haven't been able to reproduce it yet.
[20:50] <lifeless> jam: ouch
[20:51] <lifeless> unreproducable issues suck
[20:51] <jam> yep
[21:17] <jam> lifeless: argh... 'make run_codehosting' dump the file handles I'm using. Spawn 20 connections, it goes up to 60, next connection, back down to 12,13,14, perfectly clean
[21:17] <lifeless> jam: its using 3 fds per connection ?
[21:20] <jam> lifeless: stdin, stdout, stderr, yes
[21:20] <lifeless> jam: how long does it hold them open ?
[21:20] <vila> . o O (A thread with its 3 subprocess file handles not join'ed  ?.... ? ... ? 40% bet)
[21:21] <jam> at the time the forking service was shutdown it claimed to have 138 children active
[21:21] <jam> that is about 400 file handles
[21:21] <lifeless> accounted for, yes.
[21:21] <lifeless> did we get an lsof ?
[21:21] <jam> lifeless: we didn't get any extra debug info, AFAIK
[21:21] <vila> hmm, I'm pretty sure wgrant pointed to a graph with ~300 connections
[21:21] <jam> I wasn't around
[21:22] <lifeless> so
[21:22] <lifeless> we have this live on qastaging
[21:22] <lifeless> hammer that?
[21:22] <vila> +1
[21:22] <vila> with hammer >> 300
[21:22] <jam> lifeless: I did a hammer of it when we were deploying it, running 10+ concurrent connections for ~10 hours and didn't see it
[21:22] <jam> but yes, we can do more
[21:23] <jam> vila: I'm checking https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ now
[21:23] <vila> jam: if it's related to some limits setting you may run 10 years if you're below
[21:23] <jam> vila: sure, but getting 300 concurrent connections is way over what we've generally seen. 138 is high
[21:23] <jam> it is certainly possible
[21:24] <jam> lifeless: I can say that for "echo hello | ..." the file handles are closed ~ as soon as the process exits
[21:24] <lifeless> our log files should tell us the concurrency we see
[21:24] <vila> hmm, I think the graph was showing an average of ~260
[21:24] <lifeless> jam: hang on
[21:24] <jam> lifeless: they do, but it is a bit tricky
[21:24] <jam> vila: just waiting for lpstats to actually graph something
[21:24] <lifeless> jam: why are the file handles kept open in the parent at all ?
[21:24] <jam> lifeless: to ferry the content from the bzr process to the client
[21:24] <jam> same as before
[21:24] <jam> no more file handles than we used to have
[21:25] <jam> just to a different process
[21:25] <lifeless> ok
[21:25]  * lifeless is imaginging a design where once handed off the fds are only needed by the bzr-sftp service
[21:25] <lifeless> less handshaking as well
[21:25] <vila> jam: meh, me too, wth ?
[21:26] <lifeless> lpstats has a linear-growth design
[21:26] <lifeless> we're pushing its capacity
[21:26] <vila> . o O (Or spwan a clone once you reach too many fds)
[21:26] <lifeless> first thing I think is what jam is already doinig - reproduce
[21:27] <jam> vila: or run multiple front end services load balanced across instances... ooh look, already working on that :)
[21:27] <vila> :)
[21:27] <vila> jam: well done ;)
[21:27] <jam> lifeless: right. As for lpstats, not having intermediate filtered content is a bit of a pain. Just a denormalized table with pre-averaged samples by day or something would probably make a big difference
[21:28] <jam> vila: https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ link is cached now
[21:28] <jam> spikes of active connections up to 360
[21:28] <jam> but the important ones *should* be Active Smartserver Processes
[21:28] <vila> yup, same here, not the one wgrant showed me, 100% sure
[21:28] <jam> which is pretty much always under 100, usually under 90
[21:28] <jam> or even average of about 40
[21:28] <vila> https://lpstats.canonical.com/graphs/CrowberryProcesses/20110211/20110212/nocache/
[21:28] <jam> I don't really know how those are computed, though
[21:29] <vila> ~sure the fork server was killed at the peak
[21:29] <jam> vila: the peak of 360 I see is back on 2011-01-29
[21:29] <jam> but I'm checking your graph
[21:29] <jam> vila: the # of processes
[21:30] <jam> there is ~200 baseline processes on Crowberry
[21:30] <vila> indeed
[21:30] <jam> so that is only 320 - 200
[21:30] <jam> or 120 new bzr processes
[21:30] <vila> when this was occurring I couldn't even get 'bzr info lp: xxx' working
[21:30] <jam> vila: well, some people could
[21:30] <vila> jam: not 'bzr pull lp:bzr'
[21:30] <jam> I saw connections made and finished
[21:31] <vila> hmm
[21:31] <jam> it depended when a connection would close so that handles would free up
[21:31] <jam> and then get used by the next connection
[21:31] <lifeless> jam: how well did it perform before it went bang, do we know ?
[21:31] <jam> vila: there does seem to be an issue with child processes not terminating immediately.
[21:31] <vila> at the time it was switched off, nobody in the #launchpad-ops mentioned a successful connection which was part of the decision to switch it off
[21:32] <jam> lifeless: very hard to tell from this graph: https://lpstats.canonical.com/graphs/CodehostingPerformance/20110211/20110212/
[21:32] <vila> jam: I just give you my feeling, better check the irc logs...
[21:32] <jam> the problem is the 23s spike drowns out the numbers
[21:32] <jam> vila: sure. I'm just going through the disk logs and seeing a new connection come in, and successfully exit
[21:32] <jam> I don't doubt that it could have been a 90% failure rate
[21:32] <jam> looking at bzr-sftp.log
[21:33] <jam> lots of "I can't open a new file"
[21:33] <jam> I don't know what would have happened if we just restarted without disabling the forking code
[21:33] <vila> then that's an additional data point, not all of my connections failed, the other only hung
[21:33] <jam> ATM, I'm wondering if there is a failure condition that is leaving the spawned bzr processes still alive
[21:34] <vila> jam: yeah, *I* would have wait a bit longer, but it's  easier to say when your finger is not on the trigger
[21:34] <jam> vila: what really bothers me is that the 30 minutes that are probably the most interesting, are just completely missing from the logs
[21:34] <jam> somewhere between bzr-sftp.log.10 and bzr-sft.log.11
[21:35] <jam> I see the process get started, things get handled fine
[21:35] <vila> jam: on the flip side, *I* wasn't expecting troubles either, so when they showed up...
[21:35] <jam> and then 11:01 ish, they are all dying with no file handles available
[21:35] <jam> vila: what also concerns me about: https://lpstats.canonical.com/graphs/CrowberryProcesses/20110210/20110212/
[21:35] <jam> is that the baseline has moved
[21:35] <jam> even after restarting the machine
[21:35] <jam> it was 200-240
[21:36] <jam> it is now 260-280
[21:36] <vila> jam: yeah, I encounter the same problem when my HDD died and they were no trace in the logs because.... well, the systeme couldn't tell me...
[21:36] <vila> jam: blame the p-i ?
[21:37]  * vila hopes jam can connect my replies to his remarks :-/
[21:38] <vila> jam: I'm long EOD, take my thoughts as random inputs, I offer no guarantee on their technical merit ;)
[21:38] <fullermd> vila: Well, they'd still be written to the other drive in your RAID, right?   :p
[21:39] <vila> fullermd: indeed not, and the more I think about it, the less I'm tempted by RAID as a substitute for good backups and admin mods versioning :-P
[21:42] <jam> vila: serve different purposes. but certainly important
[21:42] <jam> RAID won't save you from rm -rf /
[21:43] <jam> backups don't save you from hardware crashes
[21:43] <jam> especially hot-swap RAID
[21:43] <fullermd> Actually, the one time I did that (intentionally; the box was being decomissioned), it blew away something the system needed before it got done.  So rm -rf / saved me from rm -rf /   :p
[21:44] <vila> fullermd: hehe, doesn't feel the same when you really tried it ;)
[21:46] <vila> jam: but yeah sure
[21:46] <vila> my current experiment starts from the assumption that we crossed the point where you can archive what matters for... ever
[21:47] <jam> fullermd: certainly, I can imagine it removing a kernel module that it wanted to read, etc.
[21:47] <vila> so I have ~10 full backups of the important family data
[21:47] <jam> vila: except how can you archive those 10 backups... wait
[21:47] <fullermd> Well, I dunno what it ended up being.  But it stopped cold before it finished the rm.
[21:48] <fullermd> 'course, I've also induced hard "failures" by putting small pieces of metal at very high speeds through the drive.  Not while it was running though; maybe I should try that sometime...
[21:49] <vila> fullermd: err, how did you achieve the high speed then ?
[21:49] <vila> fullermd: Or is it just a way to say you *throw* them ?
[21:49] <fullermd> Extremely exothermic chemical reaction inside a small brass case.
[21:49] <vila> :)
[21:49] <vila> bra what ?
[21:50] <fullermd> i.e., I shot it   :p
[21:52] <vila> hehe, indeed , for same value of throw ;-D
[21:53]  * vila off... really ;)
[22:00] <wgrant> jam: Sorry, I was more concerned about getting codehosting back up. Did minimal gathering of what processes were around, and then restarted everything.
[22:00] <wgrant> jam: Some connections did succeed.
[22:00] <jam> wgrant: I understand
[22:00] <wgrant> But then hung.
[22:01] <jam> just hard to debug the next day with only so much logging
[22:01] <wgrant> Most were dropped during kex.
[22:01] <wgrant> Yeah.
[22:01] <wgrant> There also seems to be 30 minutes of logs missing.
[22:01] <wgrant> Possibly because it couldn't open the new one.
[22:01] <jam> wgrant: dropping during kex because it was trying to open /dev/urandom and couldn't open another file
[22:01] <jam> wgrant: possible. A bit odd that it succeeded 30min later when it was still failing to open files
[22:02] <wgrant> jam: Really good timing, maybe?
[22:02] <jam> wgrant: certainly possible
[22:02] <jam> It does seem to hold open a log file
[22:02] <jam> since there were lots of failures in the next log
[22:05] <wgrant> Right.
[22:05] <wgrant> I initially thought the quick rotation meant that the rsync had missed a log.
[22:05] <wgrant> But it was confirmed that that was not the case; the log really is missing.
[22:15] <wgrant> jam: FWIW things were already going wrong in the bit before the missing log.
[22:15] <jam> wgrant: the previous log shows no failures
[22:15] <wgrant> jam: I couldn't see anything relevant in the log, but the connection time graph showed that things were bad.
[22:16] <jam> wgrant: AIUI the connection time graph is only computed every 5-10 minutes or so, so not very good granularity
[22:16] <jam> but sure
[22:16] <wgrant> Hmm.
[22:16] <jam> I certainly could say that things were close to dying at the point, since it was unable to open the log file
[22:16] <wgrant> We should get the actual data points.
[22:16] <wgrant> True.
[23:04] <maxb> jelmer: I'm confused. Why is the bzr-builddeb-daily recipe set to a 2.5.1~ based version?
[23:07] <maxb> (Given that 2.6 is tagged and in maverick/natty/sid/wheezy
[23:10] <jelmer> maxb: consistency with its changelog
[23:11] <jelmer> maxb: we need to ping james_w about this