=== spiv_ is now known as spiv
pooliehi all01:10
spivHi poolie01:13
pooliehi spiv01:13
pooliespiv, today, starting quite soon, i'm going to try to improve the broken lock bug01:13
spivbug 619872?01:14
ubot5Launchpad bug 619872 in Bazaar "bzr: ERROR: exceptions.ValueError: tag/value separator not found in line '' reading lockdir info file (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/61987201:14
pooliesorry, no, the failure to release locks when we're interrupted01:14
spivAh, good, because I'm working on 619872 :)01:15
poolieso you said the file is full of nuls? or has a nul?01:15
spivWell, rio.read_stanza(['\0']) is the minimal way to reproduce that exact error text.01:15
spivBut any number of nuls would do it too.01:16
pooliei'm glad we know why it's happening but that's a bit disturbing01:16
pooliei wonder how they get in there?01:16
spiv(pedant: any natural number...)01:16
poolieooh, that's high grade pedantry01:16
poolieit reminds me of the other duped bug that was active recently where the dirstate file is truncated01:16
pooliewell, it's not very similar, but both are "don't trust the filesystem too much"01:17
spivI think some filesystems like XFS have been known to leave files full of nuls after a crash?01:17
pooliemany unix things can01:17
poolieif the inode update is not strictly ordered with writing data01:17
pooliexfs may be more prone too it01:17
pooliesome have had the bug that you could get bits of other files01:18
pooliebut that's a bit of a security bug and should be uncommon01:18
spivRight.  And ext3/4 has a bunch of different options that affect that sort of thing.01:18
spivThe original bug report in this case appears to be windows.01:19
* fullermd supposed you mean "... appears to be ON windows", but it's funnier read the other way 8-}01:24
pooliehi spiv, teddy?05:13
pooliei'm getting in to the locking bugs05:14
pooliei might try just closing a terminal with bzr running, holding a lock05:14
poolieand see what signal it gets and what it does after that05:14
pooliepresumably sighup05:14
lifelessmental image05:14
lifelessrow of bzr's lined up05:15
lifelessin terminals05:15
lifelessand a firing squad05:15
lifelesstrying to get them at just the right moment05:15
lifeless<- strange05:15
lifelessI think thats a great way to get a handle on what is happening to python/bzr05:15
pooliein some ways i think coping with broken locks by detecting them and asking if you want to steal them, would be better05:16
lifelesssomething you may have already considered is adding some instrumentation to capture in .bzr.log signal info05:16
lifelesspoolie: we should definitely do that for same-machine locks05:16
pooliei know05:16
* lifeless was emitting moral support05:17
spivpoolie: I'm pretty sure it's SIGHUP05:17
spivpoolie: I did an experiment along those lines a while back, registering a SIGHUP handler in a simple python script, blocking on raw_input(), then closing the terminal05:18
poolieit is05:18
pooliei'm not confident that unwinding will really fix all cases but it's worth a try05:19
spivHmm, if you want to be fancy you could subclass KeyboardInterrupt as SIGHUPInterrupt, and raise that from a SIGHUP handler.  All code that expects to let KeyboardInterrupt propagate would still work, and then at the top level you could potentially distinguish from KI in cause you didn't want to print 'bzr: interrupted' or whatever.05:20
lifelesspoolie: one more suggesting05:22
lifelesspoolie: when stealing, we should run some recovery / check code for half-done alterations to the repository in particular (think pack-names).05:22
pooliegood idea spiv05:31
poolieand lifeless05:31
pooliei might hook it from library_state.py05:31
CcxCZhi, I managed to break bzr http://paste.pocoo.org/show/257906/07:10
CcxCZall I did was 'bzr remove --keep <DIR>' for a dir with versioned files and then it all went breaking here and there07:13
spivCcxCZ: hmm, that sounds familiar07:24
spivCcxCZ: hmm, sounds like another instance of https://bugs.edge.launchpad.net/bzr/+bug/37726107:28
ubot5Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 4, heat: 2)" [High,Confirmed]07:28
spivCcxCZ: FWIW I can't reproduce with simple experiments locally with 'bzr remove --keep' of a dir, if you can figure out a recipe to reproduce your scenario that would be very helpful07:31
spivCcxCZ: also there's a comment on https://bugs.edge.launchpad.net/bzr/+bug/504836 (a dupe of 377361) that may help you recover07:32
ubot5Launchpad bug 504836 in Bazaar "AssertionErorr "name .. already in parent" during _generate_inventory (dup-of: 377261)" [Undecided,New]07:32
ubot5Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 4, heat: 2)" [High,Confirmed]07:32
CcxCZok, I'll mark myself affected and I'll post my dirstate07:35
spivCcxCZ: thanks!  Please give as much info as you can about how you got into this state, e.g. any uncommitted changes or merges before you ran bzr remove --keep.07:36
vilahi all !07:41
spivHi vila07:47
CcxCZspiv: submitted. Right now I don't have time to try to reproduce it, but I have the state archived.07:55
=== spm` is now known as spm
spivCcxCZ: great, thank you!08:08
pooliespiv, so as i feared, once we try handling sighup as an exception, we get back into ERESTARTSYS08:44
pooliehi vila?08:53
vilapoolie: hey !08:53
pooliehey there, how are you?08:53
vilapoolie: I'm fine08:54
pooliei just saw, catching up on my mail from last week, that the january epic is already settled08:54
pooliethat's truly epic organization :)08:54
vilaYeah, found your pm only this morning, we need to discuss before end of September (we should have booked the flights by then)08:57
spivpoolie: :/08:58
spivpoolie: one option would be a C module like https://code.edge.launchpad.net/~spiv/bzr/sigwinch-without-signalmodule-583941 proposed, or only enabling this on sufficiently new CPython. (>= 2.6.6, IIRC)09:00
spiv(2.6.6 is the version where signal.siginterrupt actually works)09:00
pooliethat seems like quite a heavy solution considering that this probably won't fix most unlocking cases09:01
spivIIRC the C module would provide basically the same behaviour as Python gives us for SIGINT09:01
pooliei feel a bit more convinced now it would be better to just let the lock break and then cope gracefully later09:01
vilapoolie: as in better stealing a broken lock ?09:02
spivFWIW I'm trying to be pretty rigorous with tests and corner cases with my lock work atm.09:02
poolievila, yes-09:02
pooliespiv, i'm glad, but what's the connection?09:02
vilapoolie: lock :)09:03
spivWell, coping with perhaps damaged locks, e.g. incompletely written.09:03
poolieoh ok09:03
pooliei was just confused because in the cases i'm thinking about, there's not much we can do about them09:04
pooliethese are stale locks left behind by bzr dying, or the connection dropping09:04
poolieor, for example, it being killed by sighup09:04
spivMy hope is that what I'm working on will make the recovery from those situations very reliable, because as you say they are hard to avoid.  (And in the worst case the network connection drops midway and there's nothing bzr can do to tidy up the interrupted op)09:06
spivOr after a messy system crash.09:07
spivIt's a bit of a shame to have to code to cope gracefully with non-bzr things failing, but that's life :)09:07
poolieoh, maybe we're overlapping then?09:08
pooliei was going to put this aside and give you a ui to break locks interactively09:08
poolieand to detect locks probably owned by dead processes09:08
spivHmm, I don't think there's much overlap, I think probably what I'm doing is more complementary.09:09
spivPartly test coverage, partly giving better exceptions in previously unexpected cases.09:09
spivAnyway, it's past 6 on a Friday, and V is letting me know by reaching for my laptop, so I should go :)09:11
pooliei hope you're all getting better?09:13
vilameh, how can "error: (32, 'Broken pipe')" be uncaught by a  "except (OSError, IOError), e:" ?09:22
vilaerr, followed by: if e.errno not in (errno.EPIPE,):09:23
vila                raise09:23
poolievila, i'm guessing it's actually a socket.error09:26
pooliewhich is a different beast09:26
pooliei think that's what it was09:26
vilagimme my bazaar.launchpad,net back09:36
pooliei know!09:36
vilaha, planned hardware maintenance: http://identi.ca/launchpadstatus/09:37
vilaone hour to go09:37
vilahmm, I can delay writes, but reads...WIBNI a read-only version was always available...09:39
vilapoolie: hmm, socket.error, sounds like it. We have some latent bugs then09:43
pooliethere's a bug asking for readonly mode09:44
pooliethough if it's a hardware fix, this might be a case where we can't do it09:44
pooliethere's also a bug about socket.error09:44
poolievila, i'm thinking of giving the ui a concept of "does the user want interaction on topic x"09:45
pooliethen we can just turn that off for break-lock09:45
poolieindeed perhaps that's overcomplicated and they just want "is this interactive at all?"09:46
vilapoolie: yup, that matches up with having config variables accepting y/n/ask instead of being pure boolenas09:46
vilabooleans even damn delete key being too close to enter ;)09:47
vilaI thought about that recently, we ould then have a '-y' generic option that would always reply yes without any user interaction09:47
poolieright, i'm thinking we should just have that poke some state in to the ui factory09:48
pooliewe could also add configuration options to control them09:48
vilayup, that could be implemented as a ui factory, which will be well suited for script usage09:49
vilathen you could chose between the config variable and the generic option or any combination that fits09:50
poolieshould we have a separate concept of asking whether you want to be interactive, or should the core ui code perhaps just ask "should i break the lock"10:05
poolieit's a bit look-before-you-leap10:05
poolievila, what do you think of http://pastebin.ubuntu.com/487726/11:09
pooliei might sign off in a bti11:09
vilapoolie: at first glance: I was thinking of a specific type for config values but I don't have a clear answer about how that should interact with the ui factory, having to register all interaction messages won't scale right11:13
vilaI think the idea was that the code still calls get_boolean, but if the value is 'ask' then the user is prompted, unless the ui is non-interactive11:15
vilathat doesn't say what the default should be though, but I think get_boolean can already return None11:16
vilaI kind of feel that the message and the default value should stay in the caller code...11:16
poolieit seems useful to me to put the message into the ui so that guis or whatever can present it differently11:18
vilapoolie: and when I mentioned the '-y' option, I was vaguely thinking about a '--no' option too, but the consequences are unclear...11:18
poolierather than just getting a string11:18
vilaright, and i18n issues too, but doesn't get_boolean accept a prompt parameter (or should it ?)11:18
pooliei was going to then make the ui look up that value in the config11:18
poolieit does take a prompt parameter11:19
pooliebut it folds the other parameters in to it11:19
pooliewhereas really we want to do i18n before that11:19
vilaWell, if we reach the point where every constant is a config variable, then, msgs are constants...11:21
poolieso what do you think?11:22
vilaso your idea will fly too but turning all messages into constants... will not rejoice everybody :-/11:22
poolieheh, i wouldn't like that11:23
pooliebut i have a feeling that ui interactions are a bit different11:23
pooliei suppose you're right though that it does make things more indirect that you can't just put them inline in the code11:23
vilaI think I prefer get_boolean(prompt=xxx) rather than interaction_messages, the prompt is indeed an interaction message11:23
pooliei think for setting interactivity and defaults11:26
vilato step back a bit, my primary example was uncommit's 'Are you sure' , where I'd like a config variable11:26
poolieand for letting the ui do something smarter than just showing the string11:27
pooliewe want a symbolic name, not just a string to match against11:27
pooliebut perhaps not?11:27
vilaerr, as far as config variables are concerned, strings *are* symbolic names11:27
poolieso what would you anticipate having in the config file?11:28
poolie"Are you sure" = no?11:28
vilaho no ! You mean that get_boolean is called with a prompt and without referring to a config variable11:28
pooliei thought that's what you were asking for11:29
vilain this case, we need config.get_uncommit_xxx() which implementation check for a conf var and fallback to get_boolean('Are you sure')11:29
vilato ui.get_boolean('Are you sure') so GUIs still have a chance to trigger11:30
pooliei'd like to keep it at still just one line for application code11:33
poolieso how about ui.get_boolean('Really uncommit?', id='bzr.uncommit.confirm')11:34
vilacould be: config.get_user_option('bzrlib.builtins.cmd_uncommit.confirm') hehe11:35
poolieheh, something like that11:35
vilaaliases could be defined11:35
poolieand then the other thing to change is to put the variables to insert into it as kwargs to the ui factory11:36
vilaso, it depends on whether config can use ui or the opposite11:36
pooliei could go either way11:36
pooliebut i think of ui as being a somewhat higher-level thing11:37
vilaso far I think there is only get_user_option_as_bool that uses config, I don't know if ui uses config11:37
vilaI don't know, a user should be able to configure the ui to use but that doesn't forbid all uis to implement all the needed features11:38
poolieistm that making them symbolic would also possibly help later with testing11:39
vilaThe uis use env variables which can be seen as config vars as well11:39
poolieright, they should be unified11:39
vilaindeed, partly by defining where they are in the config layering and partly by defining either aliases (to the corresponding config var) or a rule to go from one to the other11:41
pooliejust keeping things at a more symbolic layer rather than going straight down to strings would be good11:42
poolieoh, rules from env variables to config things? yes11:42
vilaI think my (slight) disagreement is the same regarding the show_xxx and warn_xxx additions to ui, my feeling is that this shouldn't be part of ui but stay in application code11:44
vilaI understand the benefits to group them in a single place but... dunno, something feels wrong11:45
pooliedo you mean things like show_cross_format_fetch?11:48
poolieah ok, so show_user_warning is already going in this direction isn't it, of having a warning_id11:48
vilaby the way, 'bzrlib.builtins.cmd_uncommit.confirm' is accepted as a key by configobj (I just checked)11:49
vilathat's what I'm saying, yes11:49
vilaon the other hand, we also have a config.suppress_warnings11:50
vilawhich is to say, we may need more data points to triangulate :)11:51
poolieok so it seems like we agree there should be an id passed through11:51
poolieand the arguments should be separate11:51
=== poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.2.0 is out
poolie(still needs an announcement i think)11:52
vilaand this id is probably the config var11:52
poolieso there's the question of whether the standard text for it should be inline in the caller11:53
vilastepping back to the application code, I want a boolean, I may describe its intent to the user with a string (which could be the docstring for the default value of the config var)11:53
pooliewhich will make it easy to see how to add new ones11:53
vilaall this proposals came from my thinkings about config vars to be honest11:54
pooliei think it would be nice to have purely declarative stuff for config vars11:55
poolieno methods per var11:55
poolieexcept those that have a calculated default11:55
vilaeven them11:55
poolieand then describe where it's read from and what env var it may map to11:55
pooliewell, no method, just a callable11:55
poolieso in this particular one11:55
pooliewe can declare them essentially inline at the place that uses them11:55
pooliewhich may be reasonable if they are mostly used from one call site11:56
poolieor we could have a central registry11:56
vilanot even a callable, we can manage to have declarations in bzrlib.config or just a registry so anybody can declare them inline11:56
pooliewell, if it's for example determined by reading /etc/mailname then at some level there needs to be a callable11:56
vilaright, the default value can be a callable11:57
vilawhich in turn can use othe conf vars, haha, only serious11:57
vilaand of course plugins can override the default value... endless fun11:58
poolieok, so11:58
vilain this context, the user can speak too, hence the 'ask' special value11:58
poolieadding id and args parameters to get_boolean and friends is a small change for the callers11:59
poolieand probably makes it maximally easy to implemetn new uis11:59
vilaohhhhh, yeah ! That's the ui side !11:59
vilahmm, so the conf var docstring can be a format, hence the kwargs12:00
pooliethen i guess if for some thing we want to take the default text out of the application code, we could just make the text parameter optional12:00
pooliewhat's the conf var docstring?12:00
vila<poolie> so there's the question of whether the standard text for it should be inline in the caller12:00
vila<vila> stepping back to the application code, I want a boolean, I may describe its intent to the user with a string (which could be the docstring for the default value of the config var)12:00
pooliehm, and where would that be in the code?12:01
vilaI don't know if this will work for all cases but the ui level don't have to care12:01
vilain the registry12:01
vilathat is, if you use conf vars, you pass the docstring to the ui12:02
vilaif you get straight to the ui, well, you provide it, so it will be inline in the caller12:02
vilaif you go straight to the ui, well, you provide it, so it will be inline in the caller12:03
vilawhen you said ui higher than config, I thought, well, orthogonal12:03
poolieso do you still see the app code calling a method on the ui?12:06
vilaif there is no config variable, yes12:06
pooliei would have thought we'd have a clear distinction between things that are meant to behave like config variables, and things that are possibly user interactions12:06
vilaISTM that some/most? of the  user interactions can be linked to a conf var12:07
pooliemm, but i think specifically blocking and asking the user something needs to be taken account in the code in a way that looking up a config variable does not12:08
pooliemaybe not12:08
vilawarnings about format deprecations, confirming uncommit, forcing push/pull/commit12:08
vilathat's why I say conf vars, newbies may want to be asked whether their push is valid, experienced users hate that12:09
poolieoh, i definitely agree that should be configurable12:09
pooliei just think that the intent of the app code is "here's something to possibly warn about" not "look up a configuration variable"12:09
pooliei'm tired; i should stop12:11
vilabut the code flow may depends on the user answer or a conf var... I don't have a definitive answer, both config and ui are involved it may be clearer for the application code to refer to ui, may be the call itself should be ui and the parameters from config, or just hidden in the call12:12
poolieistm there are going to be a number of callers12:13
poolieand we want them to have the simplest experience we can12:13
poolieso at least a facade that covers up checking with either config or the ui12:13
vilasounds good12:15
=== ddaa1 is now known as ddaa
=== rml_ is now known as rml
starenkahi can i hook a shell script which would be executed on the server as soon a rev is pushed to it? (bzr+ssh)13:25
=== Ursinha is now known as Ursinha-lunch
=== Ursinha-lunch is now known as Ursinha
=== basic_ is now known as basic`
=== beuno is now known as beuno-lunch
jamstarenka: look into the "post_branch_tip_changed" hook. It is a python hook, but you can have it hook into a script18:11
jamI think jelmer also had a plugin that exposed bzr hooks to shell scripts18:11
=== beuno-lunch is now known as beuno
starenkajam: thanks19:08
=== james_w` is now known as james_w
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
C-SFor all the guys who asked for testtools on FreeBSD... Here it is: http://www.freshports.org/devel/py-testtools/20:31
C-SJust ported it and it got accepted today :-)20:31
C-Sthis is in particular news for fullermd :-)20:32
jelmerC-S: \o/20:57
C-Sjelmer: what you guys wanted, right?20:57
jelmerC-S: Well, I don't use FreeBSD but it's great to have testtools available on more systems.20:58
C-Sjelmer: You should give it a try! FreeBSD is just a dream :-)20:58
jelmerI've used it in the past and quite like it21:13
fullermdC-S: Sweet   :)21:17
=== _thumper_ is now known as thumper

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!