| jam | mgz: I think the current 'best fix' is to just catch the error and re-raise something that indicates what files are involved | 00:03 |
|---|---|---|
| jam | it may not be the final fix, but it at least progresses us to where users get informed that there is a problem with specific files | 00:04 |
| mgz | jam: unrelated question, what's the minimum cython version that should work? had issues with _simple_set_pyx.pyx on my old debian box. | 00:06 |
| jam | mgz: 0.11? I'm not really sure. pyrex 0.9.6 comes to mind | 00:07 |
| jam | I know 0.9.4 has bugs | 00:07 |
| mgz | hm, python-pyrex seems to be mispackaged on lenny though, and cython is only 0.9.8 | 00:08 |
| mgz | I'll leave it on the python versions till I get round to updating. | 00:09 |
| === mbarnett changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila) | ||
| kkrev | is --hardlink supposed to work on windows? 2.3 crashes here with that option: bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link' | 01:07 |
| jam | kkrev: no, it could probably be made to work, but it does not currently. | 01:08 |
| jam | mkanat, mwhudson: Are you guys around? I'm wondering if people are still getting the merge proposal emails for loggerhead. You don't have to do any reviews, but the team was changed to 'loggerhead-team', and I'm getting noisy bounces from a launchpad list | 01:11 |
| jam | so I want to make sure whether anyone is seeing the requests at all | 01:11 |
| === Ursinha is now known as Ursinha-afk | ||
| mkanat | jam: My contract with Canonical is unfortunately over. | 01:11 |
| mwhudson | jam: i've seen some of them | 01:11 |
| mkanat | jam: I have seen the emails, though. | 01:12 |
| jam | mkanat: no issue for me here, just making sure emails are getting out | 01:12 |
| jam | I didn't know if it was going dark because of the target change | 01:12 |
| poolie | jam, i suggest you request reviews from bzr people | 01:12 |
| poolie | and also get lp admins to repopulate that team appropriately | 01:12 |
| jam | poolie: I'm not really sure who should be in loggerhead-team, but I'm in ti | 01:13 |
| jam | it | 01:13 |
| jam | from the discussions, lp is supposed to be taking over the review process, and I'm a little unsure what the short-term plan is for the branch. | 01:14 |
| maxb | We need a timeline for merging 'experimental' into the new lp:loggerhead - in particular whether all of experimental will land at once, or if it's worth re-landing some of the smaller changes first | 01:14 |
| poolie | i got some of those bounces myself | 01:14 |
| poolie | there is a thread about it | 01:14 |
| jam | I know I've read robert's stuff, but he seems to indicate lp squads will actually do something, which has not really been my experience | 01:14 |
| jam | maxb: I'm starting with getting it up to the level of pqm | 01:14 |
| poolie | i don't think they are as proactive on reviews as we are | 01:14 |
| jam | reverting all the way to 422 takes out a fair amount of stuff, like even the view pages | 01:14 |
| poolie | and we could do better, at that | 01:14 |
| poolie | i did get your review mails | 01:15 |
| jam | poolie: sure. The question is, who is actually going to say something about the future of that branch? I have direct commit rights still, so I could just do it TM | 01:15 |
| poolie | you can certainly nag me or your other team mates | 01:15 |
| poolie | let's review them and commit | 01:16 |
| jam | poolie: there is still the 'experimental' branch issue, which needs oversite. Which robert had a rough proposal for, but needs someone actually doing the various bits. "watch production like a hawk after rollout", "try to load test on qastaging", etc. | 01:16 |
| jam | I'm willing to push a bit on it | 01:17 |
| jam | in the "get the stuff I did actually out to people" sense | 01:17 |
| jam | But though I know a bit about the process, it still always feels nebulous | 01:17 |
| jam | and certainly, nobody other than lifeless seems to notice anything, which seems to go against the point of his experiment | 01:18 |
| jam | poolie: for example, what do we do with the SocketException code. You reviewed it, but is that 'official' enough to land it? | 01:18 |
| jam | I investigated the HEAD returns BODY bug | 01:18 |
| jam | but it seems a general WSGI issue | 01:19 |
| jam | that is much bigger than "if REQUEST_METHOD == 'HEAD'" | 01:19 |
| jam | namely, you have to get all the headers correct, so the general recommendation | 01:19 |
| poolie | yeah i was a bit afraid robert would say "yes we'll maintain it; revert; <crickets>" | 01:19 |
| jam | is to do all the work, and at the top-most level strip the body | 01:19 |
| poolie | i think wsgi makes it easy to get HEAD wrong | 01:19 |
| poolie | mm | 01:19 |
| jam | poolie: did you see the link I posted to the bug? | 01:20 |
| poolie | well, that's a very general issue | 01:20 |
| poolie | i did | 01:20 |
| jam | http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html | 01:20 |
| poolie | if there are things that are expensive to compute and not mandatory to have present, we don't need to do them | 01:20 |
| jam | it basically says, because of how applications stack on eachother's content streams, it is very hard to get identical headers without actually doing all the work | 01:20 |
| poolie | true | 01:20 |
| jam | poolie: Content-Length is the biggest problem | 01:20 |
| jam | since, you can omit it, but if you aren't omitting it from the GET request, you're technically in violation | 01:21 |
| spiv | You don't have to return Content-Length for a HEAD request, though. | 01:21 |
| jam | and you have to have Content-Length to preserve Keep Alive, I believe | 01:21 |
| poolie | well | 01:21 |
| jam | spiv: correct. *but* the spec says the headers must be identical to the GET headers. | 01:21 |
| poolie | no, not for a head request, since there must be no body in it | 01:21 |
| poolie | mmm | 01:22 |
| jam | The quote he gave was: "The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. " | 01:22 |
| spiv | My guess is in practice it's fine to omit Content-Length; I'd check with lifeless | 01:22 |
| poolie | well, that's must vs should | 01:22 |
| poolie | i'm sure that's correct | 01:22 |
| poolie | anyhow, for dynamic resources | 01:22 |
| jam | "If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length" | 01:22 |
| poolie | there is no guarantee that the length you get from one HEAD is going to have any necessary relation to what you get from a later GET | 01:22 |
| jam | that makes Content-Length one of the things that should be preserved | 01:23 |
| jam | poolie: sure. | 01:23 |
| jam | but the question is, what is HEAD being used for? | 01:23 |
| poolie | in this case it's being used as "are you there"? | 01:23 |
| poolie | <turret voice> | 01:23 |
| jam | poolie: sure, I'd be fine just adding a HEAD_middleware that just omits the content bytes | 01:23 |
| poolie | so i do think it would be wrong to say "length=0" | 01:24 |
| jam | start_response is the call that writes the headers | 01:24 |
| jam | you can have it return a no-op write function | 01:24 |
| jam | and always yeild nothing, but consume the child apps | 01:24 |
| poolie | and i read that article as saying that wsgi's interface makes it very easy to get this wrong and end up with something saying the wrong length | 01:24 |
| poolie | anyhow, i think it's pretty obvious that returning a body on HEAD is a much worse violation of the rfc | 01:24 |
| spiv | I've seen servers that return bodies from HEAD cause weird breakage. | 01:25 |
| jam | poolie: sure | 01:25 |
| poolie | that is really not defensible | 01:25 |
| jam | Apache strips it for us in the public site | 01:25 |
| spiv | Because it understandably screws up pipelining | 01:25 |
| jam | I think it is broken for 'bzr serve --http' | 01:25 |
| spiv | So it's a pretty severe bug (and one that tends to cause breakage on subsequent requests that are otherwise bug-free) | 01:26 |
| poolie | if we started sending last-modified dates and especially if we started respecting if-modified-since it would probably be important that HEAD sends the correct date | 01:26 |
| poolie | and it's just thrashing the machine to no good purpose | 01:26 |
| jam | poolie: just confirmed that 'bzr serve --http' does it wrong | 01:26 |
| jam | poolie: I doubt *thrashing* is the word for something that is requested every 10s on a reasonably small branch | 01:27 |
| poolie | huh, i thought i tested that but perhaps not | 01:27 |
| poolie | ok, 'loading' | 01:27 |
| jam | poolie: when I first tested it with socket.recv() | 01:28 |
| jam | I got it wrong | 01:28 |
| jam | I did an initial recv() | 01:28 |
| jam | and it returned just the header line | 01:28 |
| jam | but that was becuase it was busy churning through the rest of the data | 01:28 |
| poolie | i think i tested it using curl, and probably curl discards any body sent from HEAD | 01:28 |
| jam | once it had been cached and up to date | 01:28 |
| jam | then recv() started returning the full content | 01:28 |
| spiv | jam: more or less load than ('x', 'y') vs. 'x:y' in hook registration? *wink* | 01:28 |
| poolie | :) | 01:28 |
| jam | spiv: significantly more | 01:28 |
| jam | but not a startup overhead | 01:28 |
| jam | :) | 01:29 |
| poolie | ok, so we'll agree that bug about head should be fixed? | 01:29 |
| poolie | spiv, how's bug 603395? | 01:29 |
| ubot5 | Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] https://launchpad.net/bugs/603395 | 01:29 |
| jam | poolie: I agree there is a bug that paste's HEAD handler doesn't strip the body, which I'll post a fix for in about 20 min | 01:30 |
| spiv | poolie: erk, closed the bug. The confusion was that the merge proposal state didn't record the fact that while one fix was rejected for 2.2 it was landed on 2.3 (trunk at the time) instead. | 01:34 |
| poolie | thanks jam; there's a bug number for that too | 01:36 |
| poolie | no, there isn't? | 01:36 |
| jam | poolie: the HEAD stuff? there isn't a separate bug AFAIK, just bug 701329 | 01:37 |
| ubot5 | Launchpad bug 701329 in Launchpad itself "loggerhead OOPS - error: [Errno 32] Broken pipe" [Critical,Triaged] https://launchpad.net/bugs/701329 | 01:37 |
| jam | but I can report one if you like | 01:37 |
| poolie | i just did, bug 716201 | 01:38 |
| ubot5 | Launchpad bug 716201 in loggerhead "loggerhead sends body content on HEAD request" [High,In progress] https://launchpad.net/bugs/716201 | 01:38 |
| === arjenAU2_ is now known as arjenAU | ||
| === oubiwann_ is now known as oubiwann | ||
| vila | hi all | 07:33 |
| * fullermd waves vila around. | 08:03 | |
| vila | fullermd: hey ! | 08:17 |
| vila | SGIBART and SIGTERM seem to behave differently regarding the children of the process receiving the signal, did that ring any bell ? | 08:18 |
| fullermd | No, SIGBELL is for ringing bells... | 08:18 |
| maxb | SIGABRT ? | 08:19 |
| vila | I couldn't find any answer to that with google :-/ | 08:19 |
| vila | yeah, SIG -9 | 08:19 |
| maxb | that's SIGKILL | 08:19 |
| fullermd | I'm pretty sure neither signal (or any signal...) does anything to processes other than the one you're hitting with it. It may _catch_ the signal and do something unspeakable to its kids, but that's nothing to do with the signal itself... | 08:20 |
| fullermd | And yeah, SIGABRT is 6. | 08:20 |
| * maxb believes the same | 08:20 | |
| vila | hmm, is it just that I mixed ABRT and KILL ?!?! | 08:21 |
| fullermd | Mixing anything with KILL has unpleasant side effects :p | 08:21 |
| vila | like zombies maybe ? ;D | 08:22 |
| maxb | KILL is uncatchable death; ABRT is catchable coredump-and-die | 08:23 |
| vila | damn damn damn, my google history confirms I've been climbing the SIGABRT tree, ctrl-alt-del | 08:23 |
| fullermd | No, that's SIGSQUIRRELYPCHISTORICALBAGGAGE :p | 08:26 |
| * vila notes: -9 != SIGABRT | 08:26 | |
| vila | ok, SIGKILL passed a test that SIGABRT didn't... weird | 08:29 |
| vila | so the test is spawning a 'sh -c yes' and killing the shell | 08:30 |
| vila | I've seen 'yes' staying alive... and detach from the test process | 08:30 |
| vila | s/detach/detached/ | 08:30 |
| fullermd | The shell may catch SIGABRT and kill its children. It doesn't have a chance with KILL. | 08:31 |
| vila | right, no change with KILL is clear, but how is 'yes' killed ? | 08:31 |
| vila | s/change/chance/ | 08:31 |
| vila | I call kill with the pid of the shell, no fancy group stuff or else | 08:32 |
| vila | anything else (gee tyops day) | 08:32 |
| fullermd | If I "sh -c yes", sh just exec's yes, it doesn't hang around to do anything. | 08:32 |
| vila | hmm, no, I'm pretty sure I had distinct processes | 08:34 |
| fullermd | I don't. | 08:34 |
| vila | the sh one being reported as defunct | 08:34 |
| fullermd | 45845 sh CALL execve(0x800c30378,0x800c30260,0x800c30270) | 08:34 |
| fullermd | 45845 sh NAMI "/usr/bin/yes" | 08:34 |
| fullermd | 45845 sh NAMI "/libexec/ld-elf.so.1" | 08:34 |
| fullermd | 45845 yes RET execve 0 | 08:34 |
| fullermd | (same pid that starts out the run as 'ktrace', exec's sh, exec's yes) | 08:34 |
| vila | right, looks like subprocess.Popen(...shell=True...) is not exactly sh -c yes then | 08:34 |
| vila | http://paste.ubuntu.com/565278/ | 08:37 |
| vila | *blinks* | 08:39 |
| vila | fullermd: *not* same pid even if 'sh -c yes' is clearly (or is it) what 'ps jef' displays... | 08:40 |
| jelmer | 'morning | 08:41 |
| fullermd | Defunct would mean it's a zombie. | 08:41 |
| vila | yup, and its children got reparent to 1 | 08:41 |
| fullermd | Which you'd expect. | 08:42 |
| vila | well, no, because 'yes' is still connected to its grand-parent process via pipes | 08:43 |
| vila | I managed to kill it when it reaches the 8GB mark one of the first times I debugged it ;) | 08:43 |
| fullermd | That doesn't matter. When the parent goes away, it parents right off to init. | 08:44 |
| vila | yup, understaood | 08:44 |
| vila | but what I don't get is why this occurs with ABRT but not KILL | 08:44 |
| vila | may be I should just forget about that, I shouldn't use ABRT anyway | 08:44 |
| fullermd | There are some things man was not meant to enquire into... | 08:45 |
| vila | after all, the bug I'm after is about a children clogging the pipes, leading to a parent hang. 8GB collected is good enough proof that the parent is not hanging anymore (even if I can only reproduce it manually) | 08:46 |
| vila | fullermd, maxb: Thanks for the teddy-bearing, ABRT != KILL | 08:49 |
| vila | jelmer: hey ! Are you feeling better ? | 08:54 |
| jelmer | vila: hey | 09:09 |
| jelmer | vila: good enough to work.. perhaps I'll stick to easier things today | 09:10 |
| vila | jelmer: it's amazing how this flu is spreading... I'm not feeling that good myself but I thought I should blame my gf which is getting back to work today | 09:10 |
| vila | and now spiv got one too... | 09:11 |
| jelmer | and jam's son | 09:11 |
| vila | indeed ! poolie ! watch out ! :) | 09:15 |
| jelmer | :) | 09:18 |
| thrope | is it possible to use bazaar with a samba share on os x? | 09:21 |
| thrope | looks like there is an open bug | 09:22 |
| thrope | but I wondered if anyone knew a workaround | 09:22 |
| thrope | the bugs been open for 4 years | 09:22 |
| jelmer | thrope: which bug? | 09:22 |
| thrope | https://bugs.launchpad.net/bzr/+bug/31006 | 09:22 |
| jelmer | thrope: are you sure it's a samba server on the other end, not a windows machine? | 09:23 |
| thrope | yes | 09:23 |
| thrope | its a ubuntu server | 09:23 |
| jelmer | at least newer versions of samba should support os locking I think | 09:23 |
| thrope | 10.10 fresh install | 09:24 |
| jelmer | probably mac os x that doesn't support os locks over smb then :-/ | 09:24 |
| jelmer | yep | 09:24 |
| thrope | ah ok - my apologies, I guess not really a bazaar bug then | 09:26 |
| thrope | but it would be nice to be able to do it | 09:26 |
| vila | thrope: don't forget to meeto the bug (#98836 in this case, 31006 is a duplicate) | 09:26 |
| vila | thrope: it's on the TODO list, but not high enough yet :-/ | 09:26 |
| jelmer | thrope: it's fundamentally a mac os X bug, but that bzr bug you linked to would work around the mac os X bug | 09:26 |
| thrope | ok got it | 09:27 |
| thrope | do you think smbfs over fuse would have the same problem? | 09:28 |
| thrope | rather than the os x built in one | 09:28 |
| jelmer | the fusesmb homepage doesn't say anything about locking, but I'm not sure | 09:29 |
| fullermd | vila: Well, don't sneeze in my direction! | 09:54 |
| * vila aims... | 09:55 | |
| === Ursinha-afk is now known as Ursinha | ||
| maxb | Is anyone else finding bzr's new behaviour of dumping the full plugin list to stderr when a traceback occurs to be somewhat annoying? | 11:57 |
| maxb | Since the traceback disappears off screen | 11:57 |
| Tak | is that new? | 11:57 |
| fullermd | I can't say I've noticed it, but I don't think it would bug me that much... the traceback is already way offscreen anyway. | 11:58 |
| maxb | Why is it already way offscreen? before the plugin list was added, there were only a few lines after it | 11:59 |
| fullermd | I'm pretty sure those "few" lines were already half a term full. There's only 25 lines to work with... | 11:59 |
| fullermd | And the traceback itself is often 20 or so frames deep, with 2 lines per frame, so it couldn't fit even by itself. | 12:00 |
| fullermd | But that's what scrollback is for anyway. | 12:01 |
| maxb | fullermd: But, the exception is at the bottom of the traceback, and formerly there were only 9 lines after it. So, you got to see the exception. | 12:06 |
| maxb | Now, you don't | 12:06 |
| * fullermd shrugs. | 12:06 | |
| vila | maxb: IIRC the idea was to output only the plugins that are potentially out-of-date API-wise | 12:06 |
| fullermd | I always remember having to scroll back to figure out what was going on anyway. It's not something that happens to me often either way. | 12:06 |
| vila | I don't remember the intent was to display *all* plugins | 12:06 |
| maxb | Somewhere along the way it turned into a full `bzr plugins` output | 12:06 |
| vila | worth filing a bug then, I don't see what value is added by displaying perfectly fine and probably unrelated plugins | 12:07 |
| maxb | I have sidestepped the issue for now by adding bzrlib.crash._format_plugin_list = lambda: '*elided*' to ~/.bazaar/plugins/maxb.py :-) | 12:07 |
| asabil | statik, ping ? | 12:15 |
| vila | shudder | 12:16 |
| maxb | you don't like my hack, vila? | 12:16 |
| vila | thread is a python module (use discouraged in favour of threading), I forgot about that when creating bzrlib.thread | 12:16 |
| maxb | ohdear | 12:17 |
| vila | maxb: oh no ! As long as a bug if filed so we don't forget your valid point | 12:17 |
| vila | so I need to find a new name... safethread sounds a bit pretentious catchingexceptionthread a bit long... | 12:17 |
| vila | threadeling ? | 12:18 |
| vila | cethread ? | 12:18 |
| maxb | Or, you could declare that you're looking forward to the future where relative imports are explicit only :-) | 12:19 |
| vila | vade retro satanas ;D | 12:19 |
| vila | I'll go with cethreads for now and see what reviewers think | 12:20 |
| vila | doh ! rm bzrlib/thread.pyc, I hate that one | 12:21 |
| vila | eeerk ! plugin list !!! | 12:22 |
| vila | maxb: gee, now I see your point :-} | 12:22 |
| maxb | ha :-) | 12:22 |
| vila | it's ~120 lines here 8-} | 12:23 |
| vila | fullermd: *4* lines by plugin | 12:23 |
| vila | I'm so used to scrollback on exceptions that I didn't notice earlier | 12:25 |
| maxb | filed bug 716389 | 12:28 |
| ubot5 | Launchpad bug 716389 in Bazaar "In-terminal crash report is far too long, containing full `bzr plugins` output" [Undecided,New] https://launchpad.net/bugs/716389 | 12:28 |
| vila | thanks ! | 12:29 |
| fullermd | It's all about choosing where to apply pressure, see... | 12:30 |
| fullermd | If we make the crash report painful enough, we create pressure to make sure things don't crash :p | 12:31 |
| vila | maxb: metoo'ed | 12:31 |
| vila | hehe, the original intent was to point people to their outdated plugins *before* they file a bug against bzr | 12:32 |
| maxb | fullermd: In that case we need an "I'm a developer just show me a traceback" debug flag | 12:32 |
| vila | well, I'm a lazy dev , running plugins from their trunk and I often forgot to update them in a timely manner ;) | 12:33 |
| vila | hmm, it's even worse than that, I use a mix of plugins installed in the system libraries and some in ~/.bazaar/plugins (which is a farm link to add to the fun ;) | 12:34 |
| vila | anyway, 120 > 84 and I have no plan for a 30" screen yet | 12:35 |
| fullermd | I do. I totally do. | 12:35 |
| fullermd | Now, _budget_ for a 30" screen, that's another matter... | 12:35 |
| vila | stop spending that much in ECC and raids ;-D | 12:54 |
| quicksilver | afternoon all. | 12:54 |
| quicksilver | can loggerhead do a diff between two branches, like bzr merge --preview? | 12:55 |
| fullermd | Pfft. If I did that, bzr would crash and I'd never be able to read _anything_ on my terminal :p | 12:58 |
| Tak | something in the lp stack is doing it... | 12:59 |
| quicksilver | warnocked! | 13:24 |
| quicksilver | no loggerhead experts? | 13:24 |
| maxb | No, loggerhead cannot | 13:25 |
| quicksilver | maxb: thanks. | 13:26 |
| quicksilver | shame ... | 13:26 |
| quicksilver | it's nice to be able to review code before deciding to merge, and it's nice to be able to paste around links that other people can use to review possible merges. | 13:27 |
| jam | vila: yeah, my son finally doesn't have a fever, though he threw up this morning. | 13:29 |
| jam | vila: so be careful. I've had large swaths of people I know hit by feeling sick | 13:30 |
| vila | jam: :-/ Such a nice way to start the day :-/ | 13:30 |
| quicksilver | maxb: OK, I think I can merge from trunk into the feature branch, and then persaude loggerhead to show me the diff between the head of the feature branch and the recently merged trunk revision (which is a dotted revision number) | 13:30 |
| quicksilver | maxb: does that sound plausible | 13:30 |
| vila | right, so I should blame you for Valentine's flu then :-D | 13:30 |
| quicksilver | unfortunately I'm bitten by https://bugs.launchpad.net/loggerhead/+bug/602600 so I need to upgrade loggerhead. | 13:30 |
| vila | quicksilver: check with jam, loggerhead's trunk is not anymore what it used to be | 13:31 |
| === lionel__ is now known as lionel | ||
| quicksilver | vila: in my description I wasn't talking about loggerhead's trunk | 13:32 |
| quicksilver | I was talking about my own repositories trunk :) | 13:32 |
| jam | quicksilver: lp:loggerhead recently reverted to an old old revision | 13:32 |
| jam | which doesn't include the history-db code, and thus couldn't be affected by bug 602600 | 13:32 |
| ubot5 | Launchpad bug 602600 in loggerhead "Error on dotted revisions" [High,Fix released] https://launchpad.net/bugs/602600 | 13:32 |
| vila | quicksilver: sry, I got confused, but are you talking about lp's loggerhead or an instance you're running yourself ? | 13:33 |
| jam | however, lp:~loggerhead-team/loggerhead/experimental has all the updates | 13:33 |
| quicksilver | vila: I didn't say that, so the confusion is of my making, sorry. | 13:33 |
| quicksilver | vila: we have a local loggerhead install. | 13:33 |
| quicksilver | jam: did lp rollback for a good reason? Should I avoid upgrading my local install to 1.18? | 13:33 |
| vila | jam meets quicksilver, quicksilver meets jam, I'm sure you have interesting bits to share ;) | 13:34 |
| vila | jam: should I answer that while you take a deep breath ? | 13:35 |
| jam | quicksilver: loggerhead hasn't had a strong maintainer in a while. lifeless wanted the launchpad-team to take over maintenance, but basically wanted to roll back to the point where loggerhead has been deployed in production | 13:36 |
| jam | I'm slowly pushing to get things back up to where it was | 13:37 |
| quicksilver | ah. scary. | 13:37 |
| vila | quicksilver: not for you unless your instance can receive the same kind of load as lp | 13:37 |
| jam | quicksilver: loggerhead's old trunk (now "experimental") seems very stable for most installs, but what Launchpad needs as a giant codehosting site is a bit different | 13:37 |
| quicksilver | we've been running the debian package of "1.17+bzr424-1" | 13:37 |
| vila | quicksilver: I meant, not scary for you | 13:37 |
| quicksilver | I see. | 13:37 |
| quicksilver | yes, we only have a handful of users. | 13:37 |
| quicksilver | we just want repo browsing + diffs | 13:38 |
| quicksilver | mostly diffs, actually. We paste the urls into our automatic commit emails. | 13:38 |
| jam | quicksilver: I think the experimental stuff will have some very big long-term gains, which is why I'm pushing it, but it potentially regresses some immediate concerns. | 13:38 |
| * quicksilver nods | 13:38 | |
| quicksilver | it's been fine for us, until I wanted to generate a URL for what git people call a "pull request" | 13:38 |
| quicksilver | and discovered that I couldn't do that. | 13:38 |
| quicksilver | I could make a throwaway branch and actually do the merge in that and use that as a URL, I guess. | 13:39 |
| jam | quicksilver: isn't that just "please merge my tip"? I don't see exactly what you are wanting out of the pull request | 13:40 |
| jam | or is it that they want "pull" to work, rather than "merge"? | 13:40 |
| quicksilver | jam: I want them to be able to examine the diff before they do it. | 13:40 |
| quicksilver | for code review. | 13:40 |
| quicksilver | obviously they can run bzr merge --preview locally | 13:40 |
| Tak | yeah, people want the nice merge request interface like launchpad | 13:40 |
| quicksilver | I just wanted a URL which contained the output of bzr merge --preview | 13:40 |
| quicksilver | and looking nice. | 13:41 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.0 is officially out ! (rm vila) | ||
| jam | quicksilver: sure. We use launchpad merge proposals for that, but it doesn't cover people just using loggerhead | 13:41 |
| * quicksilver nods | 13:41 | |
| quicksilver | I think I'll do the throwaway branch thing | 13:41 |
| jam | quicksilver: I think it would be reasonable to add a feature/bug request on loggerhead for a merge --preview type view | 13:42 |
| jam | I don't know who would actually get around to coding it, but it does seem like something you should be able to get from loggerhead | 13:42 |
| quicksilver | jam: well the other alternative would have been to actually commit the reverse merge | 13:42 |
| quicksilver | (which is quite common practice anyway, to resolve conflicts before merging) | 13:42 |
| quicksilver | then I would have a 'dotted revision' to diff against. | 13:42 |
| quicksilver | which loggerhead ought to be able to do - but see the bug above :) | 13:43 |
| jam | quicksilver: well, you could always show the diff vs the "ancestor:" but loggerhead should make that available, rather than you having to do it yourself | 13:43 |
| jam | and merge --preview exists because you can get conflicts while merging | 13:44 |
| * quicksilver nods | 13:44 | |
| jam | vs "diff -r ancestor:" which will never show a conflict | 13:44 |
| quicksilver | I don't think I know what ancestor: means. | 13:44 |
| jam | quicksilver: try "bzr diff -r ancestor:../other-branch" | 13:44 |
| jam | it finds the most recent common ancestor of this branch and other-branch | 13:45 |
| quicksilver | ah, handy. | 13:45 |
| jam | so 'bzr diff -r ancestor:../other/branch" shows you what is new in your current branch, vs the ancestor of the othe rbranch | 13:45 |
| quicksilver | I normally dig manually through the output of bzr log -n0 and copy-paste the ancestor revno :) | 13:45 |
| jam | so you don't see the changes in trunk being removed in your branch | 13:45 |
| jam | quicksilver: bzr log -n0 -r ancestor:../other/branch should show you what rev it is :) | 13:46 |
| * quicksilver nods | 13:46 | |
| quicksilver | getting software right is hard. | 13:47 |
| quicksilver | I can't even understand how we managed to install the squeeze deb of loggerhead when we're only running lenny on this machine. | 13:51 |
| maxb | heh :-) | 13:51 |
| quicksilver | each rabbithole leads to a door which opens into a deeper rabbithole | 13:51 |
| quicksilver | I don't think uprading loggerhead is going to be the most time-efficient thing for me to do this afternoon. | 13:52 |
| maxb | quicksilver: tbh, I think for most people the best way to "install" loggerhead is probably just 'bzr branch lp:loggerhead' | 13:52 |
| maxb | and then upgrading is "bzr pull" | 13:53 |
| quicksilver | you may be right. | 13:53 |
| quicksilver | It looks like the debian package has no harsh dependencies | 13:53 |
| quicksilver | so I think someone just downloaded it from squeeze and dpkg -i'ed it by hand. | 13:54 |
| maxb | btw, of the package you are running, the only thing of importance that got removed from trunk was the initial landing of the history-db branch | 13:54 |
| maxb | Also, if you want to go to 1.18, 1.18 doesn't include anything that was removed from trunk | 13:55 |
| quicksilver | maxb: what odes the history-db branch do? | 13:55 |
| maxb | It's jam's big make-it-faster-by-caching-stuff project | 13:56 |
| shakaran | Hi, I need help for solve a conflict of type "Contents conflict in " I read the doc on http://doc.bazaar.canonical.com/bzr.0.92/en/user-guide/conflicts.html | 14:02 |
| shakaran | so, I am using bzr mv as: | 14:02 |
| shakaran | bzr mv Connection.java.OTHER Connection.java | 14:02 |
| shakaran | bzr: ERROR: Could not move Connection.java.OTHER => Connection.java: src/ea/doma | 14:02 |
| shakaran | in/Connection.java is already versioned. | 14:02 |
| shakaran | then, how should I proceed? The right file is .OTHER | 14:03 |
| shakaran | I know take-other option, but I need how to make with bzr mv | 14:03 |
| shakaran | some help? | 14:08 |
| maxb | shakaran: The particular documentation URL one you pasted is a very old one - bzr 0.92 is positively ancient | 14:10 |
| maxb | As for the error, it sounds like you may want "bzr rm file; bzr mv file.OTHER file" | 14:10 |
| shakaran | maxb: I search http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/conflicts.html but it have 404 | 14:11 |
| quicksilver | I don't think so. | 14:11 |
| quicksilver | the .OTHER file is not versioned. | 14:11 |
| quicksilver | I think you just want normal "mv" | 14:11 |
| quicksilver | mv foo.OTHER foo | 14:11 |
| quicksilver | 'chooses' the .OTHER as the version you want for foo. | 14:11 |
| maxb | http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/conflict-types-help.html | 14:12 |
| maxb | quicksilver: No, the .OTHER file *is* versioned | 14:12 |
| shakaran | I did: | 14:13 |
| shakaran | bzr rm Connection.java | 14:14 |
| shakaran | deleted src/ea/domain/Connection.java | 14:14 |
| shakaran | bzr mv Connection.java.OTHER Connection.java | 14:14 |
| shakaran | src/ea/domain/Connection.java.OTHER => src/ea/domain/Connection.java | 14:14 |
| === Ursinha is now known as Ursinha-afk | ||
| shakaran | but, now the Connection.java file is not added, so I need a bzr add Connection.java ? | 14:14 |
| === Ursinha-afk is now known as Ursinha | ||
| maxb | erm. That's not what I expected at all :-/ | 14:14 |
| maxb | shakaran: I don't suppose these branches are public? | 14:15 |
| fullermd | If bzr mv mv'd it, it IS versioned. | 14:15 |
| fullermd | See your stat output. | 14:15 |
| LeoNerd | 'bzr mv' also has special logic; if it can't find the OLD file and the NEW file already exists, it presumes you are telling it about a 'mv' you already did | 14:16 |
| shakaran | ok, I use bzr explorer on windows (it take a 20 second on refresh the folder with the icon) it is added | 14:16 |
| shakaran | https://code.launchpad.net/~shakaran/ea/angel it is my public branch | 14:16 |
| === oubiwann is now known as oubiwann_ | ||
| latexer | Anybody encountered a bug on windows with "JUNCTIONS" (on win7 here) causing bzr to error out? | 15:14 |
| latexer | I'm using a tool that automatically creates a junction, and i would like to treat it as a regular folder so the contents of the folder pointed to get added/committed... suggestions? | 15:15 |
| squall | @latexer what error, or thing, happens when you do this? Are junctions like hard links, I forget, or do they work like mounts? | 15:31 |
| latexer | squall: let me pull it up exactly. I believe the tool is using windows vista & newer "junctions" which work like soft links to files/directories. | 15:34 |
| squall | uhuh ok. junctions were available on xp too and so on, but there were never any tools to manipulate them.. viz: http://technet.microsoft.com/en-us/sysinternals/bb896768 | 15:35 |
| latexer | squall: the initial "bzr add" attempt just says "bzr: ERROR: [Error 3] The system cannot find the path specified: u'C:/Users/pete.johanson/dev/repo/mainline/wraps/openwrap\\*.*' | 15:35 |
| latexer | where the "openwrap" portion of that path is the junction. | 15:36 |
| squall | okay and that opwnwrap points somewhere else on your disk then. | 15:37 |
| latexer | squall: correct. | 15:37 |
| squall | and openwrap points to a bzr tree. and "repo" is a repository I guess. | 15:37 |
| latexer | And looking, I think actually the ideal situation for me would be if the "JUNCTION" details (what path it points to) would be the thing committed. (I believe the same way symlinks are handled on *nix) | 15:38 |
| latexer | repo is an initialized repository, "mainline" is a branch I've created. | 15:38 |
| latexer | the junction wraps/openwrap points to wraps/_cache/openwrap-1.0.0.50386209/ | 15:38 |
| latexer | (hopefully that's clear) | 15:39 |
| squall | hmm. There probably is a bug about symlinks not working on windows already. As for what you're seeing, it probably should work I guess. | 15:39 |
| latexer | yeah, I found https://bugs.launchpad.net/bzr/+bug/81689 which seems to somewhat discuss the issue. | 15:40 |
| latexer | (that bug talks about checkouts, but I think fundamentally it's addressing the same thing) | 15:40 |
| squall | There is this I find on wikipedia "Windows Vista supports a new symbolic link capability that replaces junction points in Windows 2000 and Windows XP. They are designed to aid in migration and application compatibility with UNIX operating systems" | 15:41 |
| squall | have you tried this new symlink stuff? | 15:41 |
| latexer | that's the thing... the openwrap utility/tool is the one creating this junction/link, I don't really have control of it... | 15:41 |
| jam | quicksilver: actually, history-db is "change from caching and always accesessing the entire history", to "cache the history in a way that we can access just the recent stuff quickly" | 15:41 |
| latexer | i mean, I could fiddle with it, but I was hoping to not have to potentially muck with the openwrap internals. | 15:42 |
| squall | yeah I see. I just wondered if it's actually creating a "junction" or a "symlink" type of thing. I guess a junction. | 15:42 |
| quicksilver | jam: *nod* | 15:43 |
| latexer | squall: "dir" from cmd shows it as a <JUNCTION>, so I would guess it's a junction, not a symlink. | 15:43 |
| squall | right, okay. | 15:43 |
| squall | yes well, anyway it appears that bzr doesn't like them. that is the answer for now. We may need a new bug on this I am not sure I'll look in a minute. Perhaps you could try the "new" symlink approach by changing this "openwrap". It depends if you can do that or not. | 15:46 |
| latexer | yeah, can't hurt to try. | 15:46 |
| squall | See, these junctions/symlinks have never been polular on windows at all. Probably becuase there are programs that fail to work correctly with them. | 15:46 |
| latexer | ya, makes sense. | 15:47 |
| squall | I'll look around the launchpad to see if there is a bug already. | 15:47 |
| latexer | squall: thanks. | 15:47 |
| squall | hmm there doesn't appear to be any mention of junctions. Although this problem might be related to other symlink bugs, it's hard to say. | 15:53 |
| squall | @latexer I think perhaps it might be worth adding a bug about that anyway - and perhaps if if can demonstrate the problem without needing a repository. if that's possible, to make it easier to reproduce. | 15:54 |
| latexer | squall: hrm... the openwrap author just sent me a tweet mentioning a way to make it not use junctions/symlinks and instead do copies from the cache. | 15:55 |
| latexer | squall: so I may be able to work around the issue with the tool itself. | 15:55 |
| squall | yeah that's sounds good. | 15:55 |
| squall | Do you fancy filing a bug at launchpad about junctions. I would only I've got no windows around at the moment, so its hard for me to check. | 15:56 |
| Lo-lan-do | Hi all :-) | 16:00 |
| jelmer | hey Lo-lan-do | 16:01 |
| Lo-lan-do | Question for jelmer: I see activity is starting up again on bzr-git these days… is support for roundtripping somewhere on the TODO-list? | 16:01 |
| latexer | squall: can do. | 16:02 |
| squall | Cheers, may as well if you have the time. I might take a quick look. Although I've not looked at bzr for a while now. | 16:03 |
| jelmer | Lo-lan-do: yeah, it's on the list of things to work on | 16:06 |
| jelmer | I have a better idea of how to do it now after talking to some of the git devs | 16:06 |
| Lo-lan-do | jelmer: Cool. That's going to help relieve the tension we're starting to feel in FusionForge. | 16:06 |
| Lo-lan-do | Feel free to poke me if you need a tester :-) | 16:07 |
| jelmer | Lo-lan-do: will do, thanks :) | 16:07 |
| jelmer | I guess you're already subscribed to the bug ? | 16:07 |
| Lo-lan-do | Not as far as I know | 16:08 |
| Lo-lan-do | Ah, found it. | 16:11 |
| latexer | squall: https://bugs.launchpad.net/bzr/+bug/716507 | 16:11 |
| rjek | Hi. I have a bzr branch that I migrated from svn many moons ago. When I use it now, I get this warning: "Fetching into experimental format RepositoryFormatKnitPack3(). This format may be unreliable or change in the future without an upgrade path." | 16:13 |
| rjek | So what's the /current/ upgrade path, and how do I move to something supported? | 16:13 |
| squall | @rjek well I don't really know. But you could try running bzr upgrade on it. I would make a backup/copy of the repository first, though. | 16:16 |
| cbz | if you haven't used any subtrees you can just do bzr upgrade --2a | 16:16 |
| rjek | I don't believe I've used nested trees, but bzr upgrade say"bzr: ERROR: Cannot convert from format RepositoryFormatKnitPack3() to format RepositoryFormat2a(). Does not support nested trees" | 16:19 |
| fullermd | Yeah, you have to end run around it. | 16:19 |
| rjek | Can I check to see if nested trees have sneaked in somehow? | 16:19 |
| fullermd | Try init'ing a fresh 2a branch, and pull'ing into it. | 16:20 |
| rjek | fullermd: That appears to do the trick, ta. | 16:21 |
| === deryck is now known as deryck[lunch] | ||
| fullermd | Technically, it shouldn't work. But technically, upgrade should check whether you're using the nested tree capability before complaining about how you'll lose it. | 16:21 |
| fullermd | So two wrongs DO make a right :) | 16:22 |
| * rjek grins. | 16:22 | |
| * rjek now writes a script to automatically upgrade and archive a whole imperial buttload of branches. | 16:22 | |
| vila | fullermd: by the way, did you start upgrading *your* branches ? | 16:28 |
| === beuno is now known as beuno-lunch | ||
| fullermd | Not 'till I get caught up on sleep. | 16:30 |
| fullermd | So we may wait 'till bzr 3.8 or so for it... | 16:30 |
| vila | indeed ;) | 16:30 |
| vila | jelmer: b-d 2.5 ? I thought the *package* has already reached 2.6, what am I missing *again* :) | 16:31 |
| jelmer | vila: I think I'm missing some context :) | 16:32 |
| vila | jelmer: reno 515 on bzr-buildeb trunk | 16:32 |
| jelmer | vila: we're at 2.5.1 according to changelog | 16:33 |
| vila | Lo-lan-do: your fqdn is hilarious :D | 16:33 |
| vila | *blink* | 16:34 |
| Lo-lan-do | Is it? | 16:34 |
| fullermd | Maybe he just tpyo'd it in his mind... | 16:34 |
| vila | jelmer: nvm, I could swear I saw 2.6 | 16:34 |
| vila | lol, yeah, that should be it | 16:35 |
| vila | Lo-lan-do: well, at least to me mirexpress.internal.placard sounds quite fun :) | 16:35 |
| Lo-lan-do | It comes from a long tradition of hostnames that match "mir". | 16:36 |
| vila | Lo-lan-do: but maybe I'm misinterpreting, as you can see above my mind play tricks on me ... | 16:36 |
| vila | Lo-lan-do: mireille, mirabelle, miroir-mon-beau-miroir ? | 16:36 |
| Lo-lan-do | monbomiroir is the server that does backups. | 16:37 |
| Lo-lan-do | mirabelle is my current printer. | 16:37 |
| vila | yes ! 2 out of 3 :) | 16:37 |
| * fullermd always liked 'Mireille'... | 16:37 | |
| Lo-lan-do | I don't think I ever used mireille. But I've had casimir, clodomir, minimir (my first laptop), miramax (the one used as a media center to play DVDs), mirific, dynamir, miracle, mokomir, mirador, mirenboite and prismirale (a plug computer) | 16:39 |
| Lo-lan-do | Oh, and mircouleur, too, for a printer :-) | 16:39 |
| Lo-lan-do | (And I could go on with the list of past, current and future names :-) | 16:40 |
| fullermd | Mirabile dictu ;p | 16:40 |
| vila | lol@mircouleur :) So I was on the right joke track with mirexpress... | 16:41 |
| vila | prismirale goes over my head though... | 16:41 |
| fullermd | I wonder if I've ever had a machine with 'mir' in the name... can't offhand think of one. | 16:41 |
| Lo-lan-do | vila: Plug computer. "prise murale". Ahaha. | 16:42 |
| vila | my current trend is on tools you can find in a bazaar: screw, scythe, saw, axe.. | 16:43 |
| vila | Lo-lan-do: !!! | 16:43 |
| Lo-lan-do | I'm not claiming it actually is funny, just that I find it so. | 16:43 |
| vila | Lo-lan-do: wfm :) | 16:43 |
| fullermd | All my systems (except my workstation) get named after mythologically significant constellations. | 16:43 |
| vila | the first real "root" guy I met used islands from a map in his desk, vanuatu, tahiti, quite colorful... | 16:44 |
| fullermd | Laptop is pegasus. An old dual-pentium was hydra. A file server in a hyuge case was hercules. Matched pair of diskless workstations were cepheus and cassiopeia... | 16:45 |
| fullermd | There's a 386 in the closet that, if it still boots, will come up calling itself musca | 16:46 |
| fullermd | Our business systems are named after herbs. We're about to (loooong overdue) retire rosemary. | 16:48 |
| achiang | how can i switch the view of my local tree to a tag? or is that not the bzr way to do it? | 16:50 |
| fullermd | You can use update to pivot the working tree around. Or pull to mess with the branch. | 16:51 |
| achiang | hm, ok. thanks | 16:54 |
| achiang | i guess what i want to do is fork an upstream branch at a certain revision | 16:55 |
| achiang | and push it to my own place in launchpad | 16:56 |
| fullermd | In that case, you'd probably want to use "branch -r" when you first create your branch. | 16:56 |
| achiang | so, maybe what i need to do is bzr clone the upstream to my local drive; figure out what tag/revspec i want, bzr branch -r and create a new local branch from that, hackhackhack, then commit and push? | 16:57 |
| fullermd | Well, you could use pull to reset the head of the branch once you have it, via a "bzr pull --overwrite -rX ." (don't miss the trailing period) | 16:58 |
| achiang | hm... does that allow me to keep all the upstream objects around, and merge my changes more easily if i want to? | 16:59 |
| achiang | sorry, i don't know a lot of bzr terminology, maybe "objects" isn't the right word | 16:59 |
| achiang | --overwrite seems scary and confusing, based on reading the man page | 17:00 |
| achiang | i actually can't figure out the difference between pull and clone/branch | 17:01 |
| fullermd | Generally speaking, branch is for making a new branch; pull is for updating an existing branch. | 17:03 |
| fullermd | (in this case, we're using pull to "update" to an old revision, but that's just a special sorta case) | 17:04 |
| === beuno-lunch is now known as beuno | ||
| fullermd | vila: Mmph. I wish upgrade would shaddup about the metadir :( | 17:38 |
| vila | repro recipe please ! | 17:38 |
| fullermd | Well. Run it :p | 17:38 |
| fullermd | SUMMARY: 6 upgrades attempted, 5 succeeded, 1 failed | 17:39 |
| fullermd | bzr: ERROR: The branch format Meta directory format 1 is already at the | 17:39 |
| fullermd | most recent format. | 17:39 |
| vila | I know I've seen it and thought the same but could never remember how | 17:39 |
| vila | hmmpf | 17:39 |
| === deryck[lunch] is now known as deryck | ||
| fullermd | Ah hah... | 17:48 |
| fullermd | bug 716560 | 17:53 |
| ubot5 | Launchpad bug 716560 in Bazaar "recursive upgrade sometimes tries to upgrade metadir, giving an error" [Undecided,New] https://launchpad.net/bugs/716560 | 17:53 |
| fullermd | With script. Getting rid of trees is the trick; a branch with a tree doesn't bother screwing with the metadir format, but without it it does. | 17:53 |
| fullermd | vila: ^^ (that took a little fiddling) | 17:56 |
| vila | fullermd: thanks | 17:56 |
| fullermd | Pretty wacky. | 17:57 |
| fullermd | Note that it _doesn't_ error if we use pack-0.92 (which has an older branch format). So going from 1.9 with no working tree, the individual branches would have nothing to upgrade; that's the case where they apparently try the metadir. If there's a wt or branch format that's upgrade-able, it just does it and moves on. | 17:58 |
| * fullermd should add that to the bug... | 18:00 | |
| jam | vila: when the bug was a common problem, you hit it whenever you tried to upgrade something that was the newest format | 18:00 |
| jam | vila: and we still do | 18:00 |
| jam | go to a fully up-to-date branch and run "bzr upgrade" | 18:00 |
| jam | It certainly tells me that the Metadir is up-to-date, rather than the branch or repo, etc. | 18:01 |
| vila | jam: could be, but istm I still encounter it from time to time when I come across old branches in the basement... | 18:01 |
| vila | jam: yeah, that may be what happen here, update branch, update tree, oops, no tree, bad fallback, etc | 18:01 |
| jam | vila: the bug is that it says it is an *error*, rather than just saying "already up to date" without "bzr: ERROR" | 18:02 |
| vila | yup, worse, it's an error the user has no control over since the branch needed to be upgraded and was successfully upgraded (I think I haven;t look in details) fullermd can confirm my guess maybe | 18:03 |
| vila | fullermd: see my comment in bug #716560 for a new 2.3 command (and sorry for the lack of ``for`` ;) | 18:29 |
| ubot5 | Launchpad bug 716560 in Bazaar "recursive upgrade sometimes tries to upgrade metadir, giving an error" [Undecided,New] https://launchpad.net/bugs/716560 | 18:29 |
| jelmer | jam: are you still hacking on reusable packs infrastructure? | 18:30 |
| vila | fullermd: and try without ``--null-output`` for additional fun :-D | 18:30 |
| jam | jelmer: it is still around, but I haven't been hacking on it | 18:31 |
| jelmer | jam: ah, ok - thanks | 18:32 |
| * maxb scratches head - I'm *in* a bzr branch, but bzr is trying to open the svn working copy several directory levels above?! | 18:32 | |
| jelmer | maxb: does the branch have a repository? | 18:32 |
| maxb | yes, it's standalone | 18:32 |
| maxb | ah, but it's a brand new branch, with no revisions | 18:33 |
| jelmer | yuk | 18:33 |
| maxb | oh, sorry | 18:33 |
| maxb | False alarm, I ended up with a .svn dir I didn't know about | 18:34 |
| vila | I'm nearly off, just wanting to mention that I made good progress on the p-i regarding bugs #589532 and #589523 (and thanks to the reporters for providing tyop-proof numbers, really mister boss mens, I appreciate) (with tests) and that I have a good hunch on the log file spamming | 18:35 |
| ubot5 | Launchpad bug 589532 in Ubuntu Distributed Development "imports hang from time to time when talking to the mass importer" [Critical,In progress] https://launchpad.net/bugs/589532 | 18:35 |
| ubot5 | Launchpad bug 589523 in Ubuntu Distributed Development "mass importer doesn't handle hung-inactive processes" [Critical,In progress] https://launchpad.net/bugs/589523 | 18:35 |
| vila | Seriously, aren't those guys just great or what ? | 18:36 |
| fullermd | Once upon a time, I had two phone lines, whose numbers differed by two digits being transposed. It was great fun :p | 18:36 |
| maxb | Was there a recent change causing API version requirement violations to be warnings rather than errors? Because I vaguely remember that discussion, but I can't find the change. | 19:19 |
| maxb | jelmer: When you said "The API requirements should no longer be strict - they should just cause warnings rather than be strict errors." what were you referring to? Plugins still fail to load for me if they violate requirements | 19:22 |
| jelmer | maxb: poolie was working on that, I though it had already landed | 19:22 |
| jam | jelmer: poolie made it so they would not show errors, but would just log that it is failing, and not import them | 19:49 |
| jam | so now you have to do "bzr plugins" to see the failures | 19:49 |
| jam | I think the next step he wanted to do was to make it so that they would still import | 19:49 |
| jam | and we would just have that info when there was a crash, etc. | 19:49 |
| jelmer | ah | 19:56 |
| vila | jelmer: This was discussed at Dallas, I thought you were involved ? They may have been some variations... | 20:01 |
| jelmer | vila: I was, but not aware of how much of it was implemented | 20:01 |
| vila | maxb: it's the same modification that display the plugins after the traceback | 20:02 |
| vila | small review queue, post-release effect | 20:03 |
| poolie | hi arjenAU, spiv, jelmer | 22:14 |
| jelmer | hi poolie, spiv, arjenAU | 22:14 |
| poolie | :) | 22:15 |
| arjenAU | hiyas | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!