[06:42] <peitschie> hiya everyone
[06:42] <peitschie> is there someone here that can lend a hand troubleshooting a corrupted repo?
[06:42] <AuroraBorealis> oh gee
[06:43] <spiv> peitschie: sure
[06:43] <peitschie> I'm getting the following error every time I run a command: bzr: ERROR: No such file: u'/vsl/bedrock/BSDSRG/Projects/Bond Advance/Bazaar/.bzr/repository/indices/1243d19cced51e076aaf9e36f173c9ee.rix': [Errno 2] No such file or directory: u'/vsl/bedrock/BSDSRG/Projects/Bond Advance/Bazaar/.bzr/repository/indices/1243d19cced51e076aaf9e36f173c9ee.rix'
[06:43] <peitschie> hi spiv :)... it's been a long time btw... bzr has been humming along without incident for almost 10months since the svn ghosting issues :)
[06:44] <spiv> peitschie: hmm, take a look in .bzr/repository/obsolete_packs, it might have that file
[06:44] <peitschie> it looks similar to this: https://answers.launchpad.net/bzr/+question/96346 ... I'm walking through those now
[06:44] <peitschie> no joy on the obselete packs
[06:44] <spiv> Was there a system crash around that time?
[06:44] <peitschie> only one file in there which has a vastly different name
[06:46] <peitschie> spiv: looking into it now...
[06:49] <jam> morning all
[06:52] <peitschie> spiv: looks like some nfs issues somewhere...
[06:52] <spiv> peitschie: ah, ouch
[06:53] <spiv> poolie's just-landed patch to call fdatasync may help avoid this problem in future.
[06:54] <peitschie> spiv: mm... could be fun... what are the chances I can save the repo if this has caused some kind of file corruption?  the thing will have done this in the last few hours
[06:55] <peitschie> spiv: interestingly, I can see the desired pack file listed in the pack names, just the actual indicies file seems to be missing
[06:55] <peitschie> spiv: there also appears to be no actual pack name with that file under packs
[06:56] <spiv> peitschie: the suggestions on that link you found are probably your best bet
[06:56] <spiv> peitschie: i.e. remove that entry from pack-names, on the assumption it was only that new pack that is missing.
[06:57] <peitschie> spiv: ok.  I'll give that a shot and see what happens :).  What will that do to any clients that believe the file was uploaded to the server?
[06:58] <spiv> peitschie: most likely there's a single new revision that's been lost
[06:59] <spiv> If there's a client that had a repository stacked on this one, that might be an issue (although probably they'll have the necessary data locally)
[07:00] <spiv> If there's a lightweight checkout using that repo that thinks it's current version is the lost revision it'll be understandably sad and confused :)
[07:01] <spiv> Probably though other repositories will be fine.  If there's a branch in that particular repo that was pointing to the missing revision it'll be broken and need to be repaired to point to an existing revision
[07:01] <AuroraBorealis> seems like bzr is pretty easy to break.
[07:02] <AuroraBorealis> is there no safeguard for when one file goes magically missing?
[07:02] <peitschie> spiv: mmm... well.. once IT gets their NFS stuff together again we shall start the great exploration I guess.  Most of these are straight checkouts so hopefully things are not lost yet :)
[07:02] <spiv> AuroraBorealis: if the filesystem randomly loses data from under you without warning?  yes
[07:02] <AuroraBorealis> i mean...if the OS crashes, if the internet dies in the middle of a commit, seems like a lot of things could cuase this...
[07:02] <spiv> AuroraBorealis: the repair tools could certainly be better, but usually the best answer to FS corruption is "restore from your backup"
[07:03] <spiv> AuroraBorealis: we're robust against network connection dropouts
[07:03] <AuroraBorealis> even if the repo is on a dumb ftp server?
[07:03] <spiv> AuroraBorealis: this case is bzr has committed it's transaction, i.e. renamed files into place, then finally updated the central index file to refer to the new files, and then somehow those files that were totally definitely there a moment ago are gone
[07:04] <spiv> AuroraBorealis: yes, even on FTP
[07:04] <spiv> AuroraBorealis: at worst bzr might ask you to run 'bzr break-lock'
[07:05] <spiv> AuroraBorealis: but it won't damage the repository
[07:05] <AuroraBorealis> ok
[07:09] <fullermd> We need a bzr plugin that punches you in the head if you use FTP.  And ideally, the server's admin too.  Twice.
[07:09] <AuroraBorealis> uhhh
[07:09] <AuroraBorealis> i use ftp
[07:09] <AuroraBorealis> because i dont have root access to my box
[07:09]  * fullermd winds up...
[07:10] <AuroraBorealis> what else am i supposed to use
[07:10] <fullermd> Punching the person with root in the head.
[07:10] <AuroraBorealis> that doesn't answer my question
[07:10] <AuroraBorealis> its a cheap hosting plan, they never give you root access
[07:10] <AuroraBorealis> and since the documentation for the supposed 'bazaar smart server' is laughably nonexistant
[07:11] <fullermd> That probably calls for high explosive.
[07:11] <fullermd> There are things in life more infuriating and revolting than the continued existence of FTP.  But it's a short list.
[07:11] <AuroraBorealis> since you since to be a troll, i'll stop now :>
[07:11] <poolie> hrm
[07:12] <poolie> AuroraBorealis: if the os dies in the middle of a commit, bzr has various ways to recover
[07:12] <AuroraBorealis> ah ok.
[07:12] <poolie> the recent sync patch is to respond to ext4 and xfs caching very aggressively
[07:12] <poolie> which means if the machine crashes or powers off suddenly, a lot of data can be lost
[07:13] <AuroraBorealis> i thought that the caching time of ext4 was shortened for that reason hehe
[07:13] <fullermd> poolie: Speaking of that, I wondered in passing how much of the added time in your test on that could come from it rooting around to find fdatasync || fsync || nothing on every call (as it looked to do)
[07:13]  * fullermd has no idea at all of the expense ballpark on that.
[07:14] <poolie> fullermd: almost certainly nothing
[07:14] <poolie> that's just one python object lookup
[07:14] <poolie> and this should only be hit about say 5 times in a bzr commit command
[07:14] <poolie> it's trivial compared to physically moving disk heads around
[07:14] <poolie> reasonable question though
[07:15] <poolie> if it was wrapping a very cheap operation and called very often it could be a probelm
[07:15] <fullermd> Well, you did your test on a memory filesystem, AIR.  So it occured to me.
[07:16] <spiv> poolie: Unless testing the flag accidentally triggered a fresh reload of the various potentially-relevant config files...
[07:16] <fullermd> The time delta did look a little higher than I'd expect just for the extra jumping into the kernel.
[07:16] <poolie> actually that is more feasible
[07:17] <spiv> poolie: a bit like not opening the wt object in the test tear down (to check isolation) was apparently causing locations.conf to be re-parsed
[07:18] <spiv> Or maybe I'm getting confused with Branch.open reading the stacked_on_location value
[07:18] <spiv> Which we also fixed to avoid looking at the whole config stack :)
[07:18] <poolie> you are quite right this might cause more config work
[07:19] <spiv> I think vila has some preliminary bits to count config file opens in the test suite
[07:26] <poolie> in the test suite on a tmpfs i would have thought that io would be pretty cheap too, though perhaps the cpu overhead is significant
[07:29] <spiv> poolie: I guess do a run with and without the patch and compare what 'time' says for user and system time?
[07:29] <poolie> that should have been in there...
[07:29] <fullermd> Going into the kernel to look at files is expensive, even if it's all in memory.  See that comment I made on the find_branches bug...  last week?
[07:29] <spiv> Or use the new-fangled perf thingy that gives more numbers and less clarity ;)
[07:30] <poolie> wow, interesting
[07:30] <poolie> and, there is indeed a lot more userspace cpu time
[07:30] <spiv> fullermd: I guess all that repeatedly resolving paths to dentries takes some work
[07:30] <fullermd> Yeah.  Almsot 5 minutes longer, but only 9 more seconds system.
[07:30] <spiv> poolie: hmm
[07:31] <spiv> poolie: I would actually start to be suspicious of the config system at this point.
[07:31] <poolie> likewise
[07:31] <poolie> i might profile a single run of a commit
[07:31] <spiv> poolie: I suppose you could try hacking the points that test the flag to just be hard-coded True without looking at the config?
[07:31] <poolie> indeed
[07:31] <fullermd> Well, probably not dentries in this case of course   ;)
[07:31] <fullermd> But going into the kernel and walking through the VFS isn't free, especially when you do it a crapload of times.
[07:32] <poolie> spiv, i'll try that
[07:49] <jelmer> 'morning spiv, poolie, fullermd
[07:49] <poolie> istm that the tests probably want to by default just not have a file for the per-user or per-location config
[07:49] <poolie> we know it won't have anything in it
[07:49] <poolie> hi jelmer
[07:51]  * fullermd waves at jelmer.
[07:54] <spiv> poolie: and generally they don't
[07:54] <poolie> generally they won't care
[07:55] <spiv> poolie: yet apparently the cost of looking for them is noticeable
[07:55] <poolie> of course it does make an interesting benchmark in this case, but not a totally representative one
[07:55] <poolie> is anyone else seeing test_unicode_bzr_home failing on linux?
[07:55] <jelmer> jam: hi
[07:55] <spiv> Grar, wireless dropping out.
[07:56] <jam> hi jelmer
[07:56] <poolie> hi jam
[07:56] <poolie> it looks like you touched this last in https://code.launchpad.net/~jameinel/bzr/2.3-unicode-home/+merge/46015
[07:56] <spiv> Ah, back.  I'll just assume a neighbour was using the microwave…
[08:02] <poolie> the cosmic rays of our time
[08:05] <jam> poolie: that code is all done inside an "if win32" block
[08:05] <poolie> true
[08:06] <Riddell> happy Wednesday all
[08:06] <poolie> hello riddell
[08:46] <poolie> ok, good night all
[08:48] <spiv> poolie: g'night
[10:48] <jelmer> hmm, is there a UDD meeting today?
[10:49] <jelmer> it has been two weeks since the last one but I don't see anything on the wiki
[10:49] <poolie> hi
[10:49] <poolie> i was expecting one
[10:58] <exarkun> What is the state of https://bugs.launchpad.net/bzr/+bug/427773 ?  It's not clear why it is "Confirmed" for "Bazaar" and "Fix Released" for 2.0.
[10:59] <poolie> exarkun, vila's last message is not very helpful is it?
[11:00] <poolie> exarkun: are you hitting this bug, or something that looks like it?
[11:00] <poolie> if so, saying so on the bug would help
[11:00] <exarkun> I'm hitting it on a somewhat old version of bzr that will be a real pain to upgrade.
[11:01] <jam> jelmer, Riddell, poolie: Hey guys, Kareem just came home with a 41C fever. So I'll be out for the afternoon. At this point I have to figure out if I can still go on vacation...
[11:01] <poolie> sorry to hear that jam, i hope he gets better soon
[11:01] <Riddell> ouch, good luck jam
[11:01] <poolie> there seems to be a lot of it around
[11:02] <exarkun> Hm, not that old though, 2.1.1.
[11:03] <jam> poolie: yeah, I didn't get nearly as bad of a fever. And the only childrens medicine they seem to have is a suppository, which he is not taking very well... :(
[11:06] <jelmer> jam: ouch :( good luck, I hope he gets better soon
[11:08] <jam> jelmer: do you just not have childrens liquid paracetamol ?
[11:08] <jam> (or motrin/ibuprofen )
[11:12] <jelmer> I dont think I have ever seen it.
[11:13] <jelmer> jam: I would expect a pharmacy to have it though, maybe not a drugstore
[11:17] <jelmer> jam:
[11:21] <jelmer> I am off again, back in a couple of hours
[11:23] <jam> jelmer: well, I went to the pharmacy and asked for something in liquid form, and this is what they gave me.
[11:23] <jam> but maybe if I try harder
[11:27] <jelmer> p
[11:31] <spiv> jam: eek
[11:32] <spiv> jam: hope he gets better quickly
[11:35] <jelmer> jam: they should be able to recommend something else in the pharmacy perhaps?
[11:39] <jam> jelmer: yeah, we see the doctor in 20 min, we'll certainly ask then
[11:39] <jam> spiv: your comment on: https://code.launchpad.net/~jameinel/bzr/2.4-launchpad-package-freshness-609187/+merge/69218
[11:39] <jam> it seems to be rendering like I wanted. Did you have something in mind?
[12:02] <poolie> riddell, jelmer, #ubuntu-meeting?
[12:04] <jelmer> I am not really here, on my cell
[12:06] <poolie> np
[12:24] <spiv> jam: no, just that the ReST looks weird to me, but it must be a corner of the syntax I'm not familiar with.
[12:24] <spiv> (Or have forgotten)
[13:17] <SeTTleR> hi, how can i create such a shortcut like lp: for bzr, so that I do not have to write a full url everytime i want to create or delete a branch?
[13:19] <fullermd> Take a look at the bookmarks plugin.
[13:20] <SeTTleR> ok, will do that. thx!
[13:20] <jimis> Is there a way to mark a branch as closed, so that I don't accidentally commit in the future?
[13:21] <fullermd> `chmod -R a-w .bzr`?   ;)
[13:22] <fullermd> No explicit way.  I could probably dream up a few more horrific hacks that would pull it off...
[13:24] <jimis> :-)
[13:25] <jimis> thanks fullermd, I also found this has been asked before: https://answers.launchpad.net/bzr/+question/80723
[13:26] <fullermd> Ooh, I think there's some way to put a plugin directly in a branch (so it only triggers on that).  So maybe you could make a plugin that hooks in pre-commit and puts on the brakes there.
[13:26] <jimis> it would be useful
[15:42] <jml> looks like loom is broken in oneiric?
[15:42] <jml> http://paste.ubuntu.com/653183/
[22:31] <peitschie> you around spiv?
[23:49] <poolie> hi all
[23:49] <poolie> 4rgbmjcn3
[23:50] <poolie> well, i won't be using _that_ one again
[23:50] <poolie> :)
[23:51] <fullermd> Red Gallumphing Bottles of Merely Juvenile Collected Nailpolish?  :p
[23:53] <poolie> hi fullermd