[00:29] it's quiet today... [00:32] and how does that make you feel? [00:32] :) [00:37] moin poolie, lifeless [01:09] * mwhudson grumbles [01:09] other things that turn out not to be thread safe in bzrlib: lazy imports [01:12] mwhudson: for that one, you might want to file a bug [01:15] things not being thread safe that have bitten me today: LP API [01:16] jml, did you send a metronome mail? [01:25] lifeless: https://bugs.edge.launchpad.net/bzr/+bug/396819 [01:25] Ubuntu bug 396819 in bzr "lazy imports are not threadsafe" [Undecided,New] [02:00] contrary to what i thought yesterday, lrucache doesn't seem to be that thread un-safe [02:01] (although if a cleanup function raises, that seems to break the cache pretty badly) [02:11] lifeless: is there a command to dump the pack-names file (re bug 396308) [02:11] Launchpad bug 396308 in bzr "bzrlib.errors.ShortReadvError: readv() read 0 bytes rather than X bytes for pack" [Undecided,New] https://launchpad.net/bugs/396308 [02:21] poolie: bzr dump-btree .bzr/repository/pack-names [02:21] poolie: (for 1.9 and above formats) [03:02] poolie, no, it got crowded out. [03:22] poolie: for bug 391411 can the reconfigure --stacked-on give a relative remote path for the branch? [03:22] Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411 [03:22] poolie: I think that is what we really want for LP stacking [03:48] thumper: my current idea (indeed current code) is that you give a cwd-relative or absolute url, but it stores it relative to the branch [03:48] poolie: we use absolute paths from /, like /~bzr/bzr/devel [03:49] poolie: so it works over whatever transport [03:49] ok [03:49] hm maybe we need a transport-relative path [03:49] btw, staging is a bit hard to test this against because it recommends new branches be stacked on staging/~bzr/bzr/trunk (for example) [03:49] but that branch doesn't exist :) [03:50] on staging [03:50] poolie: bzrtools is on staging [03:51] poolie: but I think it is the only project we copy across for testing [03:51] ok [03:51] i'll test on that then [03:51] let me know if you have any problems [03:51] although with spm not around, I'm not sure there will be much I could do :) [04:21] lifeless, Just confirming, is the full fix for bug 390563 in bzr.dev? [04:21] Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563 [04:29] jml, it may be that there are other bugs that look similar [04:29] not sure [04:32] anyone using maven? [04:34] The only thing I've heard about maven has not been complementary. [04:34] I want to download source for a lib [04:40] I'm trying to help someone who is new to bzr, I asked him the bzr checkout a branch that we can both commit to on launchpad but when he goes to commit he gets: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-learning-board/ubuntu-learning-moodle/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [04:40] I think I may have advised him wrong, any help getting out of this position? [04:41] doctormo, he hasn't set his launchpad id [04:41] bzr launchpad-login USERNAME [04:41] beuno: Ah right [04:42] poolie, done! [04:43] beuno: running the launchpad-login caused the same error: Transport operation not possible: http does not support mkdir() [04:45] doctormo, that's... odd [04:45] doctormo, does he have write permission for the branch? [04:46] that is, is he a member of ~ubuntu-learning-board? [04:47] beuno: Ah no sorry the login didn't error, a new commit command failed the same way,. [04:47] bad communication [04:58] doctormo, as jml asked [04:59] is he part of the team? [05:04] jml: checking (sorry, laptop powered off, came back and the kms thing had me wedged for a bit) [05:04] and now X has locked up. [05:04] [05:04] beuno: yes team: https://code.launchpad.net/~ubuntu-learning-board code: https://code.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk and user: (launchpad wouldn't load) [05:05] doctormo: now you need him to do 'bzr bind lp:<...>' [05:05] matthew.lye [05:05] doctormo: to change the URL that bzr has recorded locally [05:05] or bzr switch lp:... [05:05] lifeless: I see [05:05] I think I remember this problem from before [05:18] https://code.edge.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk <- on here, we got his commit working, but he shows us as an odd name /email, config problem? [05:18] thanks lifeless, beuno for your help with the commit problem [05:21] doctormo: bzr help whoami [05:22] thanks lifeless [05:56] hey [05:56] I was just talking with Twisted folk about NEWS files. [05:58] apparently when they had a NEWS file that was edited on each mainline commit, they got conflicts on every landing [05:58] this doesn't seem to happen with the Bazaar project: why? [06:00] jml: two things [06:00] a) it does [06:01] we often have to merge down trunk and fix conflicts with news [06:01] just run log -n0 (man that should be the default) and you can see those commits. [06:01] b) we alphabetically order the news items under each header. [06:02] this reduces concurrent editing of the same locations [06:03] lifeless, ok. thanks. [06:04] chronological ordering will generate many successive edits to the same place [06:15] the args are given to a plugin command by bazaar, right? [06:16] yes [06:16] I mean, I have a source code here, and the command class has a run method with the *args argument [06:16] these args are full objects, right? e.g the rev [06:18] I'd like to know who fills in the data for the rev object... [06:18] it seems that the fields are utf-8 str objects, not unicode [06:19] plugins are no different than any other command [06:19] but I need a documentation [06:19] look at something like cmd_pull [06:20] there are api docs, but there isn't a narrative about this part of bzrlib [06:20] ok, bazaar gives the cmd an arg called rev, it's an object [06:20] I want to know what bazaar has to tell me about the rev strings [06:21] are they always utf-8? may change the encoding? may become unicode someday? [06:21] show me your code [06:21] lifeless: what code exactly? [06:21] lifeless: what I'm trying to achieve is... [06:25] bzr-eclipse gets branch's log by running an xml-rpc call, which in turn runs xmloutput plugin, which returns the XML version of the log. I looked at the source, the xmllog command just runs the builtins.cmd_log passing an XML formatter for the log. This formatter handles the revision object given by bazaar... [06:26] and puts the commit message inside a CDATA for example [06:26] inside bzrlib revisionids are utf8 bytestrings [06:26] I'm not sure if it's using a custom writer or if the data comes from bzr already as utf-8 str [06:26] the commit message is unicode [06:26] the fact is that the data is utf-8 [06:27] lifeless: only message or all data in rev object? [06:27] "only message or all data in rev object?" - what? [06:27] lifeless: what's the compromise of bazaar rgarding rev data format? [06:28] I'm sorry, I'm really not following you. You're talking about objects, not data formats. [06:28] the Revision class has a number of fields, and they are all different types. [06:28] s/data format/string format (aka str+encoding or unicode) [06:29] if you're talking about how something is serialising stuff, it depends on what the serialiser is doing [06:30] lifeless: I need to check if the plugin is using a self writer [06:30] this may help: [06:30] there are three sets of strings that bzr deals with: [06:31] - internal disk data (stuff under .bzr). These we have specific formats for that have varied over time. Commonly they are xml within compressed archives [06:31] and more specifically, the xml tends to be utf8 encoded [06:31] I just want to find the reason I'm receiving utf-8, if it's bzr or the plugin [06:32] - local environment strings: command line parameters, working directory, file system encoding, console encoding [06:33] for these strings bzr usually decodes them to unicode objects, so the core bzr code doesn't have to know what encodings are in use [06:33] - internal strings. These are strings like revision ids, index keys, file ids. For these bzr strives to have them in utf8 all the time, decoding to unicode and encoding to the external encoding only when required [06:33] we do this for speed [06:34] RenatoSilva: You want to know if you're getting utf8 *in python code* ? Or on stdout ? [06:36] lifeless: I want to know what happens from e.g. commit message inside .bzr to it being read by the java plugin. I want to know if the plugin is re-encoding stuff as utf-8 or if it was already encoded by bzr [06:36] anyway I want to know [06:36] sorry [06:38] it will be reencoding [06:38] because the repository is not required to use xml [06:38] as to where it is reencoding, I haven't looked at the xmloutput plugin, so I don't know what code paths its using [06:39] I'm still not clear what you mean 'it being read by the java plugin'. You might be meaning 'when the eclipse process reads teh xml'. Or you might mean 'when a revision object is given to bzr-xmloutput' [06:39] or you might mean 'when xmloutput receives an xml revision string' [06:39] or something else [06:40] I'm checking bzrlib.revision.py, there are just 2 refs for message field, one in __eq__ and the other in get_summary [06:40] ok let me start again... [06:40] the problem is: [06:41] wrong chars in bzr-eclipse log view [06:42] that is, when you want to see the log through ui using bzr-eclipse, you see wrong chars because of an ecoding issue [06:42] this issue can be fixed by just re-decoding the xml-rpc response as UTF-8 [06:43] the problem here is that... [06:43] so the xmlrpc response has to start out as octets [06:43] because its a network protocol [06:43] I don't want to put "UTF-8" hard-coded in the fix [06:43] I want... [06:44] XML defines how encodings are represented [06:45] I want to who is ensuring the data is UTF-8, and if it will always be this way, etc. [06:45] lifeless: ok you could guess by XML preamble but... [06:46] so, you're looking at lass XMLLineLogFormatter(log.LineLogFormatter): [06:46] yes? [06:46] lifeless: unfortunately just printing out a charset in the XML header won't ensure that the XML itself matches such encoding... [06:47] so, bzr-xmlloutput is responsible for this [06:48] it recieves Revision objects [06:48] and it should serialise them [06:48] the revision_id and parent_ids attributes have utf8 bytestrings; the other fields are variously dicts, ints, floats, and unicode [06:50] lifeless: and the data I'm particularly interested in is not generated by the plugin, it's given by bzr.... the question is: is bzr giving unicode and the plugin encoding as utf-8? or is bzr giving utf-8 str, and in this case is the plugin doing any conversion still? or still, is bzr giving non-utf-8 str and the plugin is re-encoding as utf-8? [06:50] RenatoSilva: I think I've answered this [06:52] lifeless: I'm reading the code to find the answer... you're giving me me info about rev object, but in bzrlib.revision.py for example, I can't find the message field. Am I looking at the wrong file? [06:52] Revision is poorly documented, and a bit of a 'data holder' class [06:53] deserialisation is per-repository, you can look at repository.py, and repofmts/*.py to see the different serialisers [06:53] and bzrlib/xml* and bzrlib/*serial* [06:53] as I said above though. revision.message is *unicode* [06:54] you just know this or are you looking at some source code? [06:54] As I said I can't find the definition of the message field :( [06:57] logxml.XMLLogFormatter has a to_file field, but I can't find where it comes from [06:57] the log infrastructure [06:58] I'm trying to know if it is being overwritten by the plugin (codecs.getwriter) [06:59] well I think I don't need to [06:59] I have no idea :) [06:59] if the message is given as unicode by bzr, and it gets in the client as utf-8, that's because bzrl-xmloutput is doing it, no matter how :) [07:00] lifeless: so I can trust that rev object strings will be either unicode or utf-8 str, right? [07:01] in the log formatter yes [07:01] I can't make any assertions about what the log formatter outputs [07:03] anyway I think the plugin should handle the data properly, ensuring its policy will be applied (for example, print always utf-8) [07:03] lifeless: conclusion the answer about what is the encoding should be given by the plugin [07:03] so simple o.O [07:25] hi all [07:33] lifeless: I agree with your feelings about pycurl hanging bug, *but* digging to the root cause requires crossing the python/C barrier and that could be really time consuming, keep in mind though, that if real servers can produce such behavior, I will, sooner or later knows it via local_test_server (once I restart my efforts there) [07:34] s/I agree/I *share*/ [07:50] vila: so a few thoughts [07:50] vila: have you checked that the socket is actually being closed? [07:51] lifeless: just asnwering to your mail [07:51] lifeless: I've seen the close() calls [07:51] in strace? [07:51] in pdb [07:51] hi vila [07:51] hi poolie ! [07:52] spiv, istr you had a patch a while ago, that might have been abandoned, to do with better reporting of exceptions masked by unlock failures... [07:52] so _socketobject.close seems to rely on gc() [07:52] vila: ^ [07:52] Huh, I wasn't expecting to find a hpss hang here. [07:52] lifeless: >-/ [07:52] poolie: I did, I think it was essentially abandoned. [07:52] vila: I'd really like a little more investigation. Not a lot. [07:53] vila: just - add a gc.collect() call after the server calls close() [07:53] lifeless: like a call to gc from the server after the close ? [07:53] :) [07:53] I think the bug report(s) are probably fairly up to date about where that's at. [07:53] and when it hangs, poke with lsof [07:54] perhaps run under strace quickly, which should show the data being written, and read, and the socket closed [07:54] spiv, where? [07:54] i mean, where is the hpss hang? [07:54] if thats all inconclusive, keep it as it is... [07:55] lifeless: works for me [08:00] poolie: there's a race condition(!) in the v3 decoder, if it receives multiple calls to accept_bytes after parsing the end of the message it overwrites, not accumulates, the excess bytes. [08:02] The fix is trivial (+= rather than = in the relevant function), but it certainly was confusing for a while, especially before I didn't realise it wasn't necessarily deterministic once sockets get involved... so I was getting random test failures. [08:12] oh ok [08:13] And of course when you don't realise there's randomness then you start going crazy as you change minor things to debug the failure and get different results... [08:15] Just finishing up the network backwards-compat part of this inventory delta patch and then it's ready for review. [08:21] jml: ping [08:24] lifeless, pong [08:24] lifeless, just got back from an urgent hair cutting appointment. [08:24] heh [08:24] I wanted youropinion on my last post on https://bugs.edge.launchpad.net/testresources/+bug/284125 [08:24] Ubuntu bug 284125 in testresources "Provide an option for easy instrumenting of resource setup and teardown" [Medium,Triaged] [08:26] oh right. I saw that go through my email last night.. [08:28] I could ring you? [08:28] yeah. [08:29] although skype is better for me [08:29] I'm just heading for a walk [08:32] lifeless: summary: I need to call gc.collect() *after* the server thread ends to get some difference :-/ [08:32] which seems to validate poolie's theory.. [08:42] hi there, the location of my bound branch has moved (ip has changed), is there any way to tell bzr this pleasE? [08:43] edit .bzr/branch/branch.conf or 'bzr bind nelocation' [08:44] sorry closed my irc by mistake, thank you bob2 [08:55] jelmer, can you please set the development focus branch of https://launchpad.net/git to the vcs-imports branch? [09:13] jml, still around? [09:13] or any of the devvies :D [09:14] Mez, I am. [09:14] jml: I'm thinking of a feature request - don't know whether it's viable. [09:15] Well, 2 feature requests. [09:15] 1) When you commit, an option to set the "whoami" data for just that commit [09:15] 2) the option to force you to have to set that per commit (so you have to specify who you are) [09:16] It's cause we've got a dev environment where we all seem to login to and commit, and it doesnt show in the log WHO actually made the commit [09:16] Mez, ok. [09:16] Mez, so you can set the author of a commit already [09:16] Mez, note that 'author' is distinct from 'committer' [09:17] hows that then ? [09:17] Mez, 'bzr commit --author 'Jonathan Lange ' [09:17] jml: does that show up in the log ? [09:18] Mez, I don't know off the top of my head. It should be easy enough to do the experiment though. [09:18] he said, hintingly. [09:19] I'm already doing an experiment, just thought you might know off the top of your head [09:19] :) [09:19] revno: 459 [09:19] author: Martin Meredith [09:19] committer: root [09:21] Mez, as for forcing you to set the author... [09:21] lifeless: ok, bzr-guess just helped me :) [09:21] or it tried [09:21] i ^cd it by instinct first [09:22] Mez, I guess it's a valid feature, but you might well be the only person who wants it :) [09:22] probs [09:22] Mez, as a crappy hack, you could do this: [09:22] bzr alias commit='commit --author' [09:22] or you can set BZR_EMAIL [09:23] (but that's a really crappy hack.) [09:24] or I can write some sort of plugin [09:25] yeah. [09:26] I've talked with lifeless before about a feature for setting the author(s), for use in pair programming sessions. [09:42] jelmer: does bzr-git import the kernel yet? :) [09:42] it might be nice if the config system also looked in the environment [09:42] for cases like this [09:42] lifeless, poolie: I've got a cleaner fix calling shutdown(socket.SHUT_RDWR) and catching EBADF and ENOTCONN when the server connection is closed [09:43] well, it's also the fact we all use the same user (near enough) when we're on there [09:48] nice [09:49] Mez, that's why i was suggesting an env var [09:49] so it's not on disk or shared [09:49] vila, nice - i agree with you in questioning whether this is worth it, but if you've fixed it, yay [09:49] lifeless: are you still here? [09:49] jml, nice metronome [09:49] ta [09:49] poolie, then they have to work out how to set that env var [09:50] poolie, lifeless is gone, methinks. [09:50] poolie: I feel better having it fixed that way, lifeless rightly pointed the grey area [09:50] vila, just to talk over the reconfigure stuff [09:51] apparently it fails if there's new history in the stacked branch on top of the fallback repository [09:51] 'it' meaning set_stacked_on_url [09:51] in other words, if the tip of the stacked branch is new, it fails with revision not present [09:51] this is a pretty typical scenario if you think about it [09:52] i suspect this covers some number of existing bugs [09:52] now i need to work out if i can get fetch() to backfill history the right way [09:53] poolie: new history ? Between which dates ? [09:54] new history in the sense of revisions that aren't in the fallback repository [09:55] so it can be called only at creation time ? [09:57] yeah apparently so [09:57] or rather, before committing to the stacked branch [09:57] it looks like it tries to handle the other one but it doesn't seem to work [09:58] hmm, worth fixing :) [10:14] lifeless: in passing: using --parallel=fork in the test farm gives a very obscure failure: the execution is killed after the timeout without output has triggered but there is no clue about why. I think I'll keep using it though at least until I stabilize the whole setup [10:17] vila: you know socket shutdown may (on some OSs?) discard any data sent to the socket and not read by the other party? [10:17] poolie: pffff, even flushed data ? [10:19] poolie: because here, both read and write makefiles are flushed, closed, and yet, pycurl got nothing while polling... [10:19] where is that data then ???? :-D [10:20] I ate it. I'm sorry. [10:20] vila, it can discard the socket buffers inside the os kernel [10:20] i'm not sure if this is relevant to your patch [10:21] vila, do you know if there's a way to do a fetch that allows for this situation i described above? [10:21] ie the tip revision we want to fetch is not in the source, but some of its ancestry is? [10:21] maybe i should just change it to fetch everything... [10:22] poolie: the more bugs of that kind I see, the more I'm convinced there is a bug in the python socket stack... [10:22] poolie: err, I'm not familiar with fetch internals, sorry :-/ [10:22] well [10:22] doing that makes it pass :) [10:23] i think i'll leave it there for tonight and talk to jam or lifeless tomorrow [10:23] but I feel strange that you request a tip that is not in the source instead of fetching what you're missing [10:29] it may be possible to make a fetch spec for it [10:29] i agree it sounds strange [10:46] Hi everyone. [10:46] Any bzr-gtk developers available? [10:49] Fauli: depending on your question you may have different answers, so please just ask [10:50] Is it possible to make release? The current 0.95.0 is broken with Bazaar 1.16, but fixed in trunk. [10:50] I help maintain the Gentoo Bazaar overlay where we have an ebuild available (and I am the Bazaar maintainer in Gentoo anyway). [10:50] poolie: you around? [10:51] Fauli: ping jelmer and phanatic, I thought jelmer was about to make a release though... [10:52] jelmer: What's the status on a new bzr-gtk release? [10:53] vila: Thanks for the information. [11:05] verterok: Hi there ; is there anything more to installing a Hudson plugin than uploading the hpi to the web interface? I can't seem to get the Bazaar plugin to install [11:08] verterok: Never mind, it installs it rather than just putting it in the list of available plugins [11:31] jml: done [11:31] mwhudson: it should support importing the kernel if you're importing to a 2a repo [11:32] Fauli: I'm not sure - I won't have time for it any time soon, maybe one of the other bzr-gtk folks will [11:35] jelmer: Could you convince them or should I file a bug for that? [11:37] poolie: guess - good. [11:37] poolie: you can ring if you need to chat but I'm not at the laptop after these lines [11:37] vila: yes, I suspected shutdown would be useful [11:37] Fauli: can you perhaps mail to bzr-gtk@lists.canonical.com ? [11:37] vila: this starts to smell less like a pycurl bug with that data [11:37] * lifeless goes again [11:39] jelmer: Done. [11:40] Fauli: thanks [11:53] jelmer: what goes wrong in 1.9-rr? [11:56] jelmer: https://code.edge.launchpad.net/~vcs-imports/git/trunk:) [12:09] jelmer: also https://code.edge.launchpad.net/~vcs-imports/wine/git-trunk :( === mrevell is now known as mrevell-lunch === mario__ is now known as pygi === mrevell-lunch is now known as mrevell [13:48] mwhudson: in 1.9-rr xml-invalid characters are squashed [13:49] mwhudson: meaning that you need the cache for proper incremental imports [13:54] jelmer: I'd be happy to *help* release bzr-gtk but I don't know what need to be done to make a release [14:23] jelmer, thanks [14:24] jelmer: good $timeofday [14:30] vila: there's a tasklist here: http://bazaar-vcs.org/bzr-gtk/releasing [14:30] Tak: hey [14:31] I had the same bzr-svn error again yesterday :-/ [14:32] I couldn't find any cache dir to remove this time, but a rebase seems to have "fixed" it for now [14:34] Tak: please file a bug next time you hit it [14:39] ok - I can't seem to reproduce it consistently - just a couple times I've gone to pull, and bam [14:52] jelmer: from http://bazaar-vcs.org/bzr-gtk/releasing, I can push a branch where 1-6 are done, I can then do 15-18, can you do 6-14 ? (12 and 13 being... optional it seems, see updated wiki) [14:52] did bzr get a new progress bar in 1.16? [14:52] Pilky: changes where made in that area yes [14:53] cool, it's a hell of a lot more useful than it was before :) [14:53] Pilky: compared with what ? [14:54] well I've got 1.10 on my main machine and it doesn't show as much info and seems to be kinda buggy, but 1.16 on my laptop seems more informative and not buggy [14:54] though I didn't realise I was that far behidn on my main machine [14:56] Pilky: oh, so, you just discovered the traffic blinken lights :) [15:12] Hello, I'm new to Bazaar. I was going through the tutorial (mini version) and tried to publish to my ftp website and got this error message "FTP temporary error 451:......." I noticed some of the files and directories were created on the ftp server but my version files were not copied. Can anyone help me resolve this? === andreas__ is now known as ahasenack [15:15] ramaral: it would help if you say what is after the 451, if it's about appending, you're likely out of luck with a server that doesnt' support a feature bzr need [15:18] The stuff after the 451 error is "/Projects/myproject/.bzr/repository/upload/iqbx62....ftech: Append/Restart not permitted, try again. retrying." [15:18] vila: bonjour [15:21] ramaral: exactly [15:21] bialix: hi ! [15:25] vila: do you mean exactly I'm out of luck because my ftp server does not support append or you want the rest of the GUI that I truncated in the last message? [15:29] ramaral: your ftp server doesn't support append [15:30] OK, thanks for your help! [15:41] vila: http://pastebin.com/m7f3976a3 [15:41] vila: any ideas why explicit URL gives this warning every time? [15:42] it affects qpull (in qbzr) [15:42] can I file a bug? [15:48] bialix: because some code is stripping the the final '/' you carefully added :-/ [15:49] qpull reads saved URL and then run bzr pull with exact string [15:49] and I've got this every time [15:49] it makes bad impression (even for me) [15:49] then, the http server, being Apache, insists that you really should put a final '/' if you're talking about a directory, even if it knows damn well that the path is a directory [15:51] bialix: it's either a trivial patch or a tricky one, depending on how you look at it (I haven't in the last months, but lifeless and abentley discussed it and I seem to remember they ended up with a trivial, I don't remember why it was never submitted...) [15:51] so, I'm file the bug. I hope it's possible to fix it in trivial way rather than tricky one [15:52] https://bugs.launchpad.net/bzr/+bug/397046 [15:52] Ubuntu bug 397046 in bzr "explicit URL for pull command: bzr eats trailing slash from URL and then complains about permanent redirection" [Undecided,New] [15:54] vila: I don't remember. [15:55] abentley: what ? The fix or why it wasn't submitted ? [15:55] vila: All I remember was agreeing that it should be fixed. [15:55] :) [15:55] I don't find a similar bug report to mine [16:05] morning vila, bialix [16:05] btw vila, it seems "Review: approve" doesn't work anymore [16:05] you need to do "vote: approve" [16:05] (I've run into this a couple times where I approved something and LP didn't notice) [16:06] jam: good day [16:06] I did it yesterday and it did work [16:06] vila: it didn't work here: https://code.edge.launchpad.net/~jameinel/bzr/1.17-rework-annotate/+merge/8281 [16:06] not sure why [16:06] but the mail should be signed [16:06] rats, I forgot to sign that one too ??? [16:07] I thought you got an error mail in that case but may be that changed :-. [16:08] jam: I'm reviewing your lru-cleanup, let's see [16:10] hmm, reading the help again: Note that you must start the command line with a space or your command will not be recognized. [16:11] vila: sure, I thought you had [16:11] I *think* vote is for the vote of the specific patch [16:11] and Review is the overall status of the merge request [16:12] so doing *both* is actually reasonable [16:12] vote (deprecated: use review) [16:12] vila: where is the help? [16:12] https://help.launchpad.net/Code/Review [16:13]