| jam | mwhudson: I'm back | 00:00 |
|---|---|---|
| mwhudson | jam: i hate twisted.conch | 00:01 |
| jam | I'll go handle make lint, and then ping you again | 00:01 |
| mwhudson | ok | 00:01 |
| jam | mwhudson: can't say as I'm a huge fan :) | 00:01 |
| jam | It doesn't seem terrible, but the adapter stuff is a bit "magical" for me, and the Interfaces would be interesting if they were actually a complete spec | 00:01 |
| mwhudson | it's inheritance graph is a bit wonky, and it blurs the distinction between protocol and transport in confusing ways | 00:04 |
| dOxxx | how would I print a stacktrace to the console so I can tell where a function is being called from? | 00:05 |
| dOxxx | ah nevermind, I think I found what I was looking for | 00:06 |
| jam | mwhudson: I think make lint is a bit overzealous. It seems to be finding a ton of stuff in files I didn't touch | 00:07 |
| jam | Is it meant to only run on the local branch modifications? | 00:07 |
| jam | (I saw it ask something about "bzr: pipes unknown command" | 00:07 |
| mwhudson | jam: yeah, it's meant to do a st -r submit: and do it on the files reported changed, i think | 00:07 |
| mwhudson | jam: so about the 'blocking' code you added to session.py | 00:08 |
| jam | (it seems to use "bzr info | sed..." to find the parent branch, but my parent is 'devel' but I've merged 'db-devel' and all hell has broken loose | 00:09 |
| mwhudson | jam: :( | 00:09 |
| mwhudson | jam: maybe just run pyflakes on the files you know you've changed | 00:09 |
| jam | bzr pull --remember ../lp-branches/db-devel seems to sort it out | 00:09 |
| mwhudson | ah ok | 00:10 |
| jam | still a lot of noise | 00:10 |
| jam | (Makefile: line exceeds 78 chars, about 20 times) | 00:10 |
| mwhudson | yeah, i saw that | 00:11 |
| mwhudson | i don't think we care | 00:11 |
| jam | and do we *really* want (foo, ) vs (foo,) ? | 00:11 |
| dOxxx | GaryvdM: any idea why run_app doesn't do the appropriate bzr executable substitution but relies on callers to do so? | 00:12 |
| mwhudson | gar, conch seems to conflate "a subprocess has been requested" with "a subprocess has been launched and is connected" | 00:12 |
| mwhudson | which is a very non-twistedy sort of thing | 00:12 |
| dOxxx | GaryvdM: this is in bzr-explorer, bug 656072 | 00:12 |
| ubot5 | Launchpad bug 656072 in Bazaar Explorer "explorer should invoke qbzr with same bzr (affected: 1, heat: 8)" [Undecided,In progress] https://launchpad.net/bugs/656072 | 00:12 |
| jam | mwhudson: well, instantiating Process means it has forked | 00:12 |
| * GaryvdM opens code | 00:12 | |
| dOxxx | GaryvdM: it seems like a logical DRY place to put it | 00:12 |
| mwhudson | jam: yeah, but it makes it hard for us to do the right thing in our execCommadn | 00:13 |
| jam | mwhudson: what do you consider "the right thing"? | 00:14 |
| jam | I guess I'm not sure where you think we shouldn't be blocking? Because of _spawn connecting to another service to request the fork? | 00:14 |
| mwhudson | jam: use twisted apis to do the communication with the forking service | 00:14 |
| jam | mwhudson: right. And what you're finding is that "spawnProcess" wasn't a deferred, so we can't build up a new deferred based on responding to the socket interaction | 00:15 |
| jam | Is that correct? | 00:15 |
| mwhudson | jam: something like that | 00:15 |
| mwhudson | well, it's not really "is a deferred", it's more that conch expects that by the time execCommand returns, it's ok to try to write data to the client | 00:16 |
| mwhudson | er | 00:16 |
| mwhudson | s/client/protocol/ | 00:16 |
| mwhudson | the thing is, there's _almost_ support in conch for doing the right thing | 00:16 |
| GaryvdM | dOxxx: I agree that that makes sense, but I'm not sure that is the cause of the bug. | 00:17 |
| dOxxx | GaryvdM: indirectly it is. the edit_config_file function which invokes qconfig doesn't do the bzr executable subsitution, thus it just executes "bzr qconfig" | 00:18 |
| GaryvdM | dOxxx: Where do we call run_app with out using _get_bzr_executable? | 00:18 |
| GaryvdM | Ah - ok | 00:18 |
| GaryvdM | I agree with you then | 00:18 |
| dOxxx | GaryvdM: and the bzr executable replacement is different at different call-sites. | 00:19 |
| dOxxx | GaryvdM: for example, the tool menu uses qrun --ui-mode sometimes | 00:19 |
| dOxxx | GaryvdM: hopefully I can make run_app handle all the cases | 00:20 |
| GaryvdM | So maybe instead of having to call run_app(['bzr', 'qconfig']) make it so you just do run_app(['qconfig']) | 00:21 |
| GaryvdM | DRY | 00:21 |
| GaryvdM | dOxxx: ^ | 00:21 |
| dOxxx | GaryvdM: the tools menu can be anything, not necessarily a bzr command | 00:22 |
| GaryvdM | Ah | 00:22 |
| GaryvdM | def run_bzr | 00:23 |
| GaryvdM | I don't actually know the BE code that well. | 00:23 |
| dOxxx | changing the way the app suites like qbzr are defined and executed, i.e. if I were to create a run_bzr_app funciton would be a somewhat disruptive change | 00:24 |
| dOxxx | I'm more inclined to make run_app more intelligent about replacing the executable | 00:24 |
| dOxxx | it's a more localized change | 00:24 |
| jam | mwhudson: (well, given that spawnProcess returns an IProcessTransport, but Process isn't one, and conch expects it to support .write() which isn't part of IProcessTransport anyway...) | 00:24 |
| GaryvdM | ok | 00:24 |
| dOxxx | I'll give it a shot and see how it goes | 00:24 |
| mwhudson | jam: whee | 00:25 |
| mwhudson | jam: it also turns out that twisted doesn't support connecting to a fifo | 00:25 |
| jam | mwhudson: I don't know where, but before I implemented "def write" it didn't work | 00:25 |
| mhall119 | bzr is giving me connection errors trying ot use launchpad | 00:25 |
| jam | mwhudson: it certainly does support it, read my code :) | 00:25 |
| mwhudson | jam: "in a non blocking way" | 00:26 |
| jam | mwhudson: it is non-blocking, using the "dataReady" stuff | 00:26 |
| mwhudson | jam: os.open isn't! | 00:26 |
| jam | mwhudson: it is selectable | 00:26 |
| mwhudson | jam: but the open syscall itself blocks, doesn't it? | 00:26 |
| jam | so while the specific read is blocking, it won't be requested until the file descriptor says it is ready | 00:27 |
| jam | you can supply O_NBLOCK, but yes, it is blocking | 00:27 |
| mhall119 | bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 111] Connection refused | 00:27 |
| mhall119 | anybody know what's going on with that? | 00:27 |
| jam | (and you can't use O_NBLOCK for writing or it raises an exception, and if you do use it for reading it will force all future reads to be non-blocking) | 00:27 |
| spiv | mhall119: http proxy issue of some sort | 00:28 |
| jam | mwhudson: how, in twisted, do you actually open a file without blocking? | 00:28 |
| mhall119 | oh nevermind, tried the command in a new terminal and it worked.... | 00:28 |
| jam | hi spiv, care to join the lovely twisted conversation? | 00:28 |
| mhall119 | thanks spiv, but have some env variables set wrong | 00:28 |
| mwhudson | jam: good question | 00:29 |
| mwhudson | i think you don't basically | 00:29 |
| spiv | jam: been reading along, but not much to add | 00:29 |
| jam | s/conversation/bashing/ whatever :) | 00:29 |
| spiv | Basically, mwhudson has been saying everything I would :) | 00:29 |
| spiv | Twisted in general has no support for non-blocking local disk IO | 00:29 |
| spiv | Because OSes generally don't support it, apart from "do it all in threads" | 00:30 |
| LeoNerd | Mostly because it doesn't fit the POSIX F_NONBLOCK etc.. model | 00:30 |
| poolie | hi spiv | 00:30 |
| LeoNerd | Most POSIXes do have an aio system but it's generally not integrated with the rest of the IO nonblock primatives (select et.al.) | 00:30 |
| LeoNerd | So it generally sucks | 00:30 |
| spiv | LeoNerd: ...and is typically just "do it all in threads" under the hood anyway ;) | 00:30 |
| LeoNerd | Er... | 00:30 |
| LeoNerd | AIO is a real in-kernel system | 00:30 |
| LeoNerd | Atleast, on Linux Solaris and *BSD | 00:31 |
| LeoNerd | (and if you can name any other non-dead POSIXalike still alive today probably that too) | 00:31 |
| spiv | Twisted programs generally assume that disk IO is "fast enough", which is often true for many use cases. If it's not, well, threads, sorry :( | 00:32 |
| mwhudson | jam: although these calls "block" in some sense, they're not very likely to block for a noticeable length of time | 00:32 |
| jam | spiv: so I should be doing "callInAThread(os.open)" ? :) | 00:32 |
| jam | mwhudson: well, if the remote process does something bad, they'll block forever | 00:33 |
| LeoNerd | What is it you are open()ing? | 00:33 |
| spiv | jam: sorry, I was off on a small tangent. This isn't disk IO IIUC? | 00:34 |
| LeoNerd | The problem is that most of this logic was thought through before things like NFS, CIFS, etc... started moving people's local-looking files to be not so local, and thus dependent on network latency just like anything else | 00:34 |
| dOxxx | GaryvdM: looks like that's fixed it | 00:34 |
| jam | spiv: it is connecting to the fifos for the newly spawned process | 00:34 |
| jam | so 'disk-ish' | 00:34 |
| jam | but open() will block until the other process has done the open() | 00:34 |
| GaryvdM | dOxxx: Cool ! | 00:35 |
| LeoNerd | That's what O_NONBLOCK is for, but also, why opening an on-disk pipe rather than calling pipe(2) ? | 00:35 |
| jam | so if the forking service dies in the middle, (after accepting and returning the path, but before the child process has forked and opened the fifos) then it would hang the Conch process indefinitely | 00:35 |
| spiv | To share the pipe with a pre-existing process. | 00:35 |
| dOxxx | GaryvdM: I'll remove the adhoc executable replacement at the run_app callsites except I think I'll leave the tool menu one alone since it does some extra funky stuff according to tool type | 00:35 |
| dOxxx | GaryvdM: and since it will then be passing a executable which is not 'bzr' to run_app, it will just pass through the executable replacement logic I've added | 00:36 |
| LeoNerd | Hrm.. Sharing ondisk pipes by more than one process each end doesn't sound too healthy; sounds like a recipe for mangled messages due to nonatomic write()s | 00:36 |
| jam | the child can't open them before reporting the path, because... it blocks | 00:36 |
| mwhudson | jam: but if the forking service dies, the conch process arguably becomes useless | 00:36 |
| jam | which is actually a way we get synchronization | 00:36 |
| jam | mwhudson: except for whatever processes are currently active, yes | 00:36 |
| jam | and if we implement fall-back-to-regular spawn | 00:37 |
| spiv | LeoNerd: *a* pre-existing process, not multiple :) | 00:37 |
| GaryvdM | dOxxx: is _do_open_tool == ' tool menu one' | 00:37 |
| mwhudson | jam: true | 00:37 |
| LeoNerd | Ahh | 00:37 |
| jam | which I asked spm if that was something we should be doing, but I haven't gotten a response yet | 00:37 |
| dOxxx | GaryvdM: yes :) | 00:37 |
| LeoNerd | Could you pass FDs over a UNIX socket? ;) | 00:37 |
| dOxxx | GaryvdM: just looking at it now, I think I might be able to adapt it to work with the modified run_app | 00:37 |
| dOxxx | GaryvdM: and still keep it's logic for using qrun | 00:37 |
| dOxxx | its* | 00:37 |
| spiv | LeoNerd: one bound to the filesystem? ;) | 00:38 |
| LeoNerd | Sure | 00:38 |
| LeoNerd | You can bind a UNIX socket to filesystem, then pass FDs across it | 00:38 |
| GaryvdM | dOxxx: Yes, it's not that funky. | 00:38 |
| LeoNerd | I'm surprised to this day there isn't a standard Linux service to do that anyway, so that e.g. ping could get an ICMP raw socket without having to bet setuid root... But now that's a complete tangent ;) | 00:38 |
| mwhudson | using sendmsg, right | 00:38 |
| spm | jam: yeah sorry; I'm not too good at 3am replies :-P | 00:39 |
| dOxxx | GaryvdM: funky logic preserved :) | 00:41 |
| maxb | LeoNerd: sysadmins around the world would curse you when they couldn't ping anything because their socketserver wasn't running :-) | 00:42 |
| LeoNerd | maxb: Admins around the world already curse that the LVM2 userland tools aren't in the initrd so they can't mount their rootfs on boot, or 10,000 other sorts of weird interdependencies anyway | 00:42 |
| LeoNerd | Personally I'd love not having to start a bunch of services as root just so they can bind() a port, thne drop privs. | 00:43 |
| LeoNerd | E.g. apache could run -as- wwwdata and obtain a port80 socket from the socketserver | 00:43 |
| jam | spm: lazy, lazy man :) | 00:43 |
| spm | something ilke that | 00:44 |
| jam | spm: I assumed you were in another time zone, just mentioning that it was a question in the queue, good to see you around, btw | 00:44 |
| spm | heh | 00:44 |
| jam | and thanks for participating in the discussion | 00:44 |
| spm | fwiw, we can use the makefile. i think some of the soyuz services start that way. generally the twisted stuff is "funky" so we have to control it betterer | 00:45 |
| spm | generally, you tell us "here guys, do THIS to make it go" and we'll make it happen | 00:46 |
| spm | monitoring and alerts is a fun topic. | 00:46 |
| jam | mwhudson: now make lint (cleaner) | 00:47 |
| mwhudson | jam: great | 00:47 |
| spm | Gist is: if you *need* a human to DO X to make it happy again; that's an alert state; if it's more "you should know about this" that's not. It may be a warning state; but oervwhelming us with essentially noise alerts is not a good thing™ | 00:47 |
| mwhudson | jam: the stuff in _sendMessageToService can definitely be done in a more twisted way | 00:48 |
| jam | mwhudson: it can, but in the end you want to block before returning.... | 00:48 |
| mwhudson | yeah | 00:48 |
| mwhudson | that, and conch's interference makes me think we should be optimistic and assume the blocking won't be for very long | 00:49 |
| jam | spm: well, there is a "functionality fallback activated, running at half-speed" alert that needs a human to fix it, and there is "fully dead" | 00:49 |
| jam | if you don't distinguish them | 00:49 |
| jam | then I won't bother trying to set it up :) | 00:49 |
| spm | ha. no that's actually useful in a "this is broken (AAAA); but it's broken here vs totally" separation | 00:50 |
| jam | spm: for a specific example, if the new service dies, we could fall back to the old code and it would be slower but working. But I don't want that state to remain for long, but "let the sysadmin do it when he wakes up" would most likely be fine | 00:51 |
| spm | eg. if lpnet4 dies; that's bad; but we have lpnet1-15; so in the list of priority AAA's; lpnet4 being dead can be dropped in priority to focus on something more critical. | 00:51 |
| poolie | LeoNerd: i agree about lvm2; in fact last time i tried a boot cd it wasn't there either | 00:51 |
| spm | jam: do you mean dies, as in we'd manually flip back to an older revno? or some smarts in the code? | 00:51 |
| spm | you seem to be impling code, but to be clear? | 00:52 |
| mwhudson | i guess it depends where and how it dies | 00:52 |
| jam | spm: currently both code paths exist, as part of a "feature flag rollout" | 00:52 |
| spm | Oh I see! | 00:52 |
| spm | mwhudson: :-) | 00:53 |
| jam | if the conch machine can't connect to the forking service, it could switch code | 00:53 |
| mwhudson | jam: heh, interesting: Under Linux, opening a FIFO for read and write will succeed both in blocking and non-blocking mode. POSIX leaves this behavior undefined. This can be used to open a FIFO for writing while there are no readers available. | 00:54 |
| jam | mwhudson: not in my testing | 00:55 |
| jam | at least the python one raises EAGAIN | 00:55 |
| mwhudson | oh really? | 00:55 |
| mwhudson | boo | 00:55 |
| jam | I can open for *reading* with O_NBLOCK and it succeeds (but sets the descriptor to non-blocking mode) | 00:55 |
| jam | writing will fail right away | 00:55 |
| mwhudson | bah | 00:56 |
| spiv | LeoNerd: sounds a bit like authbind, although I don't known which mechanism that actually uses. | 00:56 |
| mwhudson | it's somewhat crazy that there are (lots and lots of) syscalls that block that don't take timeouts | 00:56 |
| jam | I did spend a fair amount of time getting a handle on the various bits of this service in order to get it to work | 00:56 |
| mwhudson | jam: yeah, if i'm implying otherwise | 00:57 |
| jam | mwhudson: write(fd, 100MB) will block | 00:57 |
| jam | that certainly surprised me | 00:57 |
| jam | (I think I was testing with 1GB or so, and you can't even kill it, at least not with ^C) | 00:57 |
| mwhudson | jam: if fd is a pipe and the pipe buffer is full right? | 00:58 |
| jam | mwhudson: I'm not sure about with pipes for that one. that was for disk io | 00:58 |
| mmclark | quick question - I'm looking for the bzr equivalent to hg's "outgoing" and "incoming" commands, which tell you what changes would be pushed or pulled to/from another repo. Is there such a beast? | 00:58 |
| jam | but yes, write() to a pipe when the pipe is full will block, too | 00:58 |
| spiv | mmclark: 'bzr missing' | 00:59 |
| jam | spm: so how would we tell nagios about the difference? | 01:00 |
| mmclark | spiv: thanks much | 01:00 |
| jam | or how could I make that information available to you so you can do whatever you want with it | 01:00 |
| mwhudson | jam: did you consider doing the 'pass fds over the socket' trick? | 01:01 |
| jam | mwhudson: the most recent change was switching from a port socket to an AF_UNIX one, and you can't do the socket trick until then | 01:02 |
| jam | I'm not 100% sure what that would actually gain you | 01:02 |
| mwhudson | well, it would get you away from having a potentially blocking open | 01:02 |
| jam | mwhudson: I honestly think the hole is pretty small here. If we find it is serious, then we can do something about it. | 01:03 |
| jam | remember that the service has to be running successfully until the exact point and then fail | 01:03 |
| spiv | It leaves the FS a little tidier ;) | 01:03 |
| jam | which is possible | 01:03 |
| mwhudson | jam: right | 01:04 |
| mwhudson | jam: i think you should land the branch as is | 01:04 |
| jam | spiv: the fs stays tidy all the time, I delete everything fairly persistently (killing the master process and not connecting to the child you requested can trigger it, I guess) | 01:04 |
| mwhudson | and then if we need to improve we can | 01:04 |
| jam | mwhudson: well, I *do* need some help landing it, too | 01:05 |
| mwhudson | jam: oh ok | 01:05 |
| spm | jam: grab nagios-plugins* as a how did they do it starter; the gist is "we" predetermine that THIS is OK, THAT is WARN and everything else is CRITICAL. kinda thing. sometimes we want to adjust params. so eg, 0.5 secs was ok, but is now warn, and we crit on 0.1 sec response times. | 01:05 |
| spiv | jam: "delete quickly" is still inferior to "never put on FS" | 01:05 |
| jam | spiv: I thought the point in *nix was that everything was linked into the fs as a namespace | 01:06 |
| jam | I mean otherwise, what is up with /proc and /dev | 01:06 |
| jam | :) | 01:06 |
| spiv | jam: those at least tidy themselves ;) | 01:08 |
| jam | spiv: so does /tmp if you enable temp reaper, or let the master forker do it :) | 01:08 |
| jam | spm: are you someone who can make it so that when I create branches of lp-production-configs they are private? | 01:09 |
| jam | spm: and is nagios-plugins private as well? | 01:10 |
| spm | jam: they should private by default (lp-prod-configs) and nagios-plugins is the default ubuntu packages | 01:11 |
| jam | spm: they *should* but going to "code.edge.launchpad.net/lp-production-configs" tells me that by default the branches will be public | 01:12 |
| spm | gawd I hope not. | 01:13 |
| jam | for mwhudson I think it says private | 01:13 |
| jam | for *me* it said public | 01:13 |
| jam | yep | 01:13 |
| jam | still does | 01:13 |
| jam | (I can screen shot it for you if you like) | 01:13 |
| mwhudson | i'm surprised it's not a private only policy | 01:14 |
| mwhudson | in which case you wouldn't be allowed to make branches | 01:14 |
| jam | mwhudson: which would at least be better | 01:14 |
| spm | he's been manually subscribed. ?? | 01:14 |
| mwhudson | spm: to trunk? yes | 01:14 |
| jam | spm: I was manually subscribed to trunk | 01:14 |
| jam | I at least had the forethought to wonder, and mwh showed me where to look | 01:15 |
| mwhudson | jam: so to be clear, you'd like me to throw https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 at ec2 land? | 01:15 |
| spm | yeah. everyone else picks it up via ~launchpad | 01:15 |
| mwhudson | although i guess pqm is closing | 01:15 |
| jam | mwhudson: well "lp:~jameinel/launchpad/lp-service", and make sure it is targetting db-devel, but yes, please | 01:15 |
| mwhudson | jam: ok, i think we'll have to wait until after the rollout | 01:15 |
| jam | *sigh* since I was trying to get it in before... | 01:16 |
| mwhudson | (yay things getting in the way of development!) | 01:16 |
| jam | but at least we could land it into 'devel' at that point | 01:16 |
| mwhudson | jam: sorry | 01:16 |
| mwhudson | i think we want at least a few weeks of battering it on staging | 01:16 |
| jam | that's fine, but then again, that is what I was shooting for. | 01:16 |
| mwhudson | (though i'm not going to apologise too much, it's not like i'm in launchpad-code any more...) | 01:16 |
| jam | the flag should make it safe enough to deploy whenever | 01:16 |
| mwhudson | right | 01:16 |
| poolie | ok i'm going to try to set up a hottest100 bot | 01:21 |
| poolie | on a web page, that is, not here | 01:22 |
| jam | poolie: if I didn't know better, I would be really concerned | 01:22 |
| jam | that certainly *sounds* naughty | 01:23 |
| poolie | :) | 01:23 |
| lifeless | jam: in .au thats a collection of songs each year ;) | 01:25 |
| jbowtie | Looks like librsync can handle 25G binary diffs without eating all available memory. Maybe we should look at using it for very large files? | 01:49 |
| mwhudson | GaryvdM: thanks for the branch :-) | 01:54 |
| spiv | jbowtie: heh, I expect poolie knows a bit about librsync ;) | 01:54 |
| GaryvdM | mwhudson: :-) | 01:54 |
| poolie | jbowtie: that could be very good, i'd be happy to see about that | 01:54 |
| poolie | ah | 01:54 |
| poolie | there's no pure-python version but we could cope without that | 01:55 |
| poolie | it might also make committing new versions faster | 01:55 |
| poolie | it may compress less well than groupcompress... maybe... | 01:55 |
| poolie | a naive use might be worse | 01:55 |
| spiv | poolie: I'd guess it's at least partly "it depends"... | 01:56 |
| jbowtie | poolie: I think it should definitely be considered for anything over, say, 250MB - that's where we start potentially breaking. | 02:04 |
| poolie | it would be interesting to try a new repo format that way | 02:06 |
| jbowtie | And is compression really an issue? Usually very large binaries are already compressed as far as they can go. | 02:06 |
| poolie | the other alternative is to just store them loose or gzipped | 02:06 |
| poolie | well, there is that | 02:06 |
| poolie | but the question is, do these things change (a) basically never; (b) totally, with no similarity from one to the next or (c) incrementally | 02:06 |
| poolie | if the first, you might as well store them unpacked | 02:07 |
| poolie | and the second for that matter true | 02:07 |
| poolie | b is likely to be true if they're already binary-compressed | 02:07 |
| poolie | but isos or large databases are likely to be like c | 02:07 |
| poolie | and there you do want delta compression | 02:07 |
| jbowtie | Generally if they're in version control it's because you expect c. | 02:07 |
| poolie | istm that in principle you could groupcompress c | 02:08 |
| poolie | and the limits are in code, not the format or the basic design | 02:08 |
| poolie | but perhaps not | 02:08 |
| jbowtie | I don't know about b, there are a few fair compression formats that do most of the changes at the end of the file. | 02:09 |
| jbowtie | I'm looking at, say, game development, where all the art assets are massive binary files. And you want to diff and merge those alongside the code. | 02:11 |
| jbowtie | Right now you can't even check them in because you break the repository. | 02:11 |
| jbowtie | And the memory usage for, say, merging looks totally unrealistic. | 02:12 |
| jbowtie | You can kind of sidestep it for diff/merge if you dump to the filesystem, but commit ATM requires you to read in the entire file. | 02:13 |
| poolie | hm, but it really shouldn't | 02:31 |
| poolie | those apis are designed to deal with iterators of chunks | 02:31 |
| poolie | obviously this is not being perfectly followed at the moment, but it should be a matter of adjusting them, not huge changes | 02:31 |
| poolie | i'm off to get some lunch, biab | 02:35 |
| vadi2 | I upgraded to Ubuntu 10.10 and bzr gcommit fails to commit now: http://paste.pocoo.org/show/272521/ | 03:24 |
| vadi2 | Is there anything I can do? | 03:25 |
| spiv | vadi2: hmm | 03:27 |
| spiv | vadi2: that paste only shows warnings | 03:27 |
| spiv | What else happens, i.e. how does it fail? | 03:27 |
| vadi2 | It gives me a dialog of "Unknown error" when I try to press Commit | 03:27 |
| vadi2 | So the commit action fails. It doesn't crash or anything, dialog is still there, but the button is non-funtional | 03:28 |
| spiv | Hmm. | 03:29 |
| spiv | vadi2: using 0.99.0-1ubuntu1 of bzr-gtk? | 03:33 |
| vadi2 | uh huh | 03:33 |
| vadi2 | Installed: 0.99.0-1ubuntu1 | 03:33 |
| spiv | I can't reproduce here with bzr-gtk 0.99.0 and latest bzr 2.2 (I have bzr installed from the PPA, so I can't easily install that bzr-gtk package...) | 03:36 |
| spiv | I don't get the warning, and the commit Just Works. | 03:37 |
| spiv | Are there any tracebacks or other hints in ~/.bzr.log? | 03:37 |
| spiv | Does 'bzr --version' and 'bzr plugins -v' report what you expect for bzr and bzr-gtk? (i.e. right versions, and using the system-wide installs?) | 03:38 |
| vadi2 | that file is big | 03:40 |
| vadi2 | no particular errors related to this time though | 03:41 |
| vadi2 | http://paste.pocoo.org/show/272558/ | 03:41 |
| vadi2 | Both versions correspond to package versions | 03:41 |
| spiv | Thanks for the screencast | 03:44 |
| spiv | Hmm, I have a theory, I'll just test it. | 03:45 |
| vadi2 | Alright | 03:45 |
| spiv | Ok, got it. | 03:47 |
| spiv | Run 'bzr whoami' in the terminal | 03:47 |
| spiv | You haven't told bzr who you are, so it can't commit because it has no committer name to record in the commit. | 03:48 |
| vadi2 | I did do launchpad-login! | 03:48 |
| spiv | And so bzr raises an error, and bzr-gtk tries to display that error | 03:48 |
| spiv | But because the error includes something that looks a bit like gtk-specific markup it breaks. | 03:49 |
| vadi2 | Thanks, it worked now. I guess that could be polished. | 03:49 |
| spiv | So the warnings were relevant. | 03:49 |
| spiv | Yes, definitely. | 03:49 |
| spiv | I'll file two bugs | 03:49 |
| vadi2 | Thanks for your help | 03:49 |
| spiv | One on bzr-gtk's handling of this error | 03:49 |
| vadi2 | RIght | 03:49 |
| spiv | And another about the "I did do launchpad-login!" aspect: you had reason to expect that this was already sorted, and so we should clearly do better there | 03:50 |
| vadi2 | The other about whoami to be auto-set from launchpad-login if whoami isn't set yet? | 03:50 |
| spiv | Right | 03:50 |
| spiv | Well, auto-setting *might* be hard | 03:50 |
| spiv | It could in principle use your name + email address as set in Launcphad | 03:50 |
| vadi2 | Yeah | 03:51 |
| spiv | But I couldn't say off the top of my head if there's any impediments with the LP API | 03:51 |
| spiv | And it probably shouldn't auto-set if you've already set it manually | 03:51 |
| vadi2 | Of course. | 03:51 |
| spiv | ...but maybe it should warn if the LP info doesn't match the manual? | 03:51 |
| spiv | etc :) | 03:51 |
| spiv | So a few issues to think about to make it fully polished, but in principle it's a good idea and straightforward :) | 03:52 |
| spiv | Thanks very much for the report | 03:52 |
| vadi2 | Sure, and thanks again for helping. See you later | 03:53 |
| jbowtie | New sphinx template nearly ready -- http://imgur.com/kmLGQ.png | 03:56 |
| jbowtie | Just need to adjust the top navigation a bit and place the search box correctly. | 03:56 |
| spiv | jbowtie: looks nice, although it looks completely different to the main website. | 04:13 |
| jbowtie | spiv: In theory it will line up with the main website overhaul. | 04:14 |
| jbowtie | spiv: It will of course live in a branch until that lands. | 04:14 |
| spiv | *nod* | 04:15 |
| jbowtie | Right now I'm just basing it off the Ubuntu branding guidelines, colors will ahve to be adjusted to whatever we actually end up using. | 04:16 |
| * spiv -> lunch | 04:28 | |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| * poolie is going to fix the failures in his scriptrunner branch | 04:50 | |
| === Ursinha is now known as Ursinha-afk | ||
| poolie | does anyone here at the moment have experience with the trac plugin? | 05:42 |
| poolie | spiv, still here? | 06:32 |
| poolie | can anyone spot why https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/35386 would cause a failure in test_delta? | 06:35 |
| poolie | it seems totally unaffected | 06:35 |
| * spiv looks | 06:36 | |
| poolie | it seems like i must be mutating some global state but i really can't spot what it would be | 06:37 |
| poolie | it doesn't fail when only the affected tests are run alone | 06:37 |
| spiv | poolie: wow, must be something obscure | 06:38 |
| spiv | pastebin the failure? | 06:38 |
| vila | then you're not going to find the problem without some bisection (at least that's how I found the isolation problems myself) | 06:38 |
| * vila not there yet :) | 06:38 | |
| poolie | http://pastebin.ubuntu.com/508536/ | 06:39 |
| poolie | i just changed it to make that failure more obvious | 06:39 |
| poolie | so i guess something is making the changereporter give the wrong results | 06:40 |
| spiv | poolie: is_quiet I think is the likely suspct | 06:47 |
| poolie | i see it does default to using trace.note and that could easily be staying intercepted when it shouldn't be | 06:47 |
| poolie | something like that | 06:47 |
| spiv | poolie: In fact I think it's almost certainly that: | 06:47 |
| spiv | 1) because the only obvious behaviour change in your patch is to add -q to some calls | 06:47 |
| poolie | so this test should probably get the results back as lines | 06:47 |
| spiv | and 2) because bzrlib.trace._verbosity_level is a global | 06:48 |
| poolie | mm i think so too | 06:48 |
| spiv | oh, and 3) because report checks the global is_quiet() first :) | 06:48 |
| spiv | vila: no bisection needed :P | 06:48 |
| poolie | well spotted | 06:48 |
| poolie | that's a bit gross | 06:49 |
| spiv | Yeah. | 06:49 |
| spiv | The bandaid I guess is to make TestCase reset it to some default every time. | 06:49 |
| poolie | hm, so probably run_bzr should reset verbosity when it's done | 06:49 |
| poolie | eventually we should get rid of it | 06:49 |
| spiv | That's probably a good idea too. | 06:49 |
| poolie | and thereby stop delta relying on it | 06:49 |
| spiv | +1 for eventually get rid of it | 06:49 |
| poolie | bug 656694 | 06:56 |
| ubot5 | Launchpad bug 656694 in Bazaar "should delete global is_quiet/is_verbose (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/656694 | 06:56 |
| poolie | so just an overrideAttr on _verbosity_level in TestCase | 07:01 |
| vila | poolie: yup | 07:01 |
| poolie | probably run_bzr should be doing this too | 07:01 |
| poolie | it shouldn't carry over from one command in a script runner to another | 07:01 |
| spiv | Right. | 07:01 |
| spiv | Although probably each run through the run_bzr machinery would set it? | 07:02 |
| spiv | Yeah, Command.run_argv_aliases always calls trace.set_verbosity_level | 07:04 |
| spiv | Oh, ew. | 07:04 |
| spiv | Look at the _verbosity_level_callback in bzrlib/option.py | 07:04 |
| spiv | The level of quietness/verbosity might carry over between commands. | 07:06 |
| poolie | exactly, that's what i'm concerned about | 07:06 |
| spiv | I don't know that we ever treat -vv differently to -v (or -qq vs. -q) | 07:06 |
| poolie | i don't think so | 07:06 |
| poolie | some programs do of course but i don't think we ever have | 07:07 |
| spiv | But if we did, it's a clear problem :) | 07:07 |
| spiv | Plugins hypothetically could, I guess. | 07:07 |
| poolie | wow that is a bit of a messy | 07:07 |
| poolie | *mess | 07:07 |
| poolie | so, i think we should make sure it's reset after running a command | 07:07 |
| poolie | then i'll try to land this, then maybe delete it entirely | 07:07 |
| spiv | Anyway, to be strict, you have to deal with the global in bzrlib.option as well as bzrlib.trace | 07:07 |
| poolie | yuck | 07:09 |
| spiv | Yes, a lovely booby trap you tripped over there :( | 07:14 |
| vila | poolie: I was willing to freeze bzr-2.3b2 *today*, as planned, any reason you want to delay that to next week ? | 07:17 |
| vila | geez, where are my manners... | 07:18 |
| vila | Hello all ! | 07:18 |
| poolie | :) | 07:22 |
| poolie | we'll gradually defuse them | 07:22 |
| poolie | and stop laying them for ourselves | 07:22 |
| poolie | vila that's fine with me | 07:23 |
| poolie | spiv, i hope you're feeling better btw | 07:23 |
| vila | poolie: ok | 07:23 |
| poolie | vila i think as much as possible releases should not cause disturb development, and ongoing development should not disturb releases | 07:25 |
| vila | +2 | 07:26 |
| vila | poolie: you say that in general or in reaction to something recent ? | 07:26 |
| poolie | in general | 07:26 |
| vila | k | 07:26 |
| vila | worth writing done somewhere | 07:27 |
| poolie | not every project can actually do this but i think it's desirable to steer for it | 07:27 |
| poolie | and we actually get pretty close | 07:27 |
| vila | yup | 07:27 |
| vila | on both counts | 07:27 |
| poolie | you can add it to the RM docs while you're in there :) | 07:30 |
| vila | poolie: hehe, just did so with big XXXXX until I settle on where this goes | 07:30 |
| poolie | ok, https://code.edge.launchpad.net/~mbp/bzr/656694-verbosity/+merge/37933 removes the coupling | 07:33 |
| vila | poolie: please land | 07:36 |
| poolie | i really hope to get tarmac up soon so we don't need more than just approval in the ui | 07:37 |
| poolie | maybe next week | 07:37 |
| spiv | poolie: yes, finally | 07:47 |
| spiv | poolie: the only drug I needed today was caffeine, which doesn't require visiting a pharmacy :) | 07:47 |
| spiv | poolie: Also another +1 from me on your release philosophy | 07:48 |
| poolie | thanks | 07:48 |
| poolie | you don't want any more dependencies or blocking than you need | 07:49 |
| poolie | spiv would it be too crude in http-messages just to truncate in the unhtml thing? | 07:56 |
| spiv | poolie: I don't think so | 07:57 |
| spiv | Well, it's no cruder than what you're already doing :) | 07:57 |
| vila | poolie: fine with me (agreed with spiv, what you're doing is already crude) | 07:57 |
| poolie | would our http tests make it easy to test this? probably | 07:58 |
| spiv | Hopefully! | 07:58 |
| vila | poolie: If I need to debug from there, I will dive in the code and modify it to suit my needs, having a rough idea of what is already reported by the server is good | 07:58 |
| spiv | poolie: btw, seeing you add a tech-debt tag to a bug reminded me of this: http://compoundthinking.com/blog/index.php/2010/10/05/technical-debt-isnt-always-debt/ | 07:58 |
| spiv | (Not because of the specific bug, just because I thought it mildly interesting) | 07:59 |
| vila | poolie: I'm not sure the http tests ever tried to match the bodies, expect for the recorded ones | 07:59 |
| poolie | :) | 07:59 |
| poolie | i don't think 'debt' is a very good word for it | 07:59 |
| poolie | it's more like friction | 07:59 |
| vila | yeah, you should address them when they start itching too much | 08:01 |
| vila | spiv: did you start working on splitting NEWS ? | 08:05 |
| spiv | vila: yep | 08:06 |
| vila | spiv: oh, and did you see maverick turned blue on babune thanks to your paramiko package ? | 08:06 |
| spiv | vila: I did, thank you! | 08:06 |
| vila | spiv: great | 08:06 |
| spiv | vila: My NEWS split branch is probably 80% done, but it's just struck weekend-o'clock here. | 08:07 |
| vila | spiv: sure, no problem | 08:07 |
| vila | Also, I'll be patch pilot next week so expect me to ask for some reviews for *my* proposals :-D Consider this a gentle nudge already ;) | 08:10 |
| poolie | good idea | 08:10 |
| === 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: vila | Release Manager: vila | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 are official | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | lol | 08:11 |
| poolie | vila i feel like in test_http it's a bit hard to understand which parameters control each test | 08:21 |
| poolie | perhaps we should split it into per_http_client_impl tests | 08:22 |
| poolie | or maybe make the parameterization more clear in each test | 08:22 |
| vila | poolie: jam filed a bug about that | 08:22 |
| poolie | which would need some more infrastructure | 08:22 |
| poolie | mm https://bugs.edge.launchpad.net/bzr/+bug/597791 | 08:23 |
| ubot5 | Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 2)" [Wishlist,Confirmed] | 08:23 |
| vila | my gut feeling is that test classes should be able to parametrize in one of their methods.... but it kind of conflicts with the fixtures idea | 08:23 |
| spiv | vila: hehe, sure | 08:23 |
| vila | spiv: sure about the method of the conflict ? | 08:24 |
| vila | s/of/or/ | 08:24 |
| spiv | vila: about doing some reviews next week | 08:24 |
| vila | lol | 08:24 |
| spiv | vila: regarding test_http, I have a vague recollection that we had an extended discussion about that in a review thread already | 08:24 |
| spiv | vila: so probably we don't need to repeat that :) | 08:25 |
| vila | hmm, I remember many discussions but not precisely where they occur, anybody finding pointers about them should add them in the bug comments... | 08:27 |
| vila | I think I've spend far too much time in test_http to not be biased :) | 08:28 |
| vila | rhaaa, libsll update... reboot... | 08:28 |
| poolie | oh, this looks really good | 08:37 |
| spiv | poolie: the output of your patch? | 08:38 |
| poolie | no, my refactoring of test_http | 08:38 |
| spiv | Ah, that'll do :) | 08:38 |
| vila | poolie: yum | 08:38 |
| poolie | with the http errors i just hope for "better than nothing" :) | 08:39 |
| vila | poolie: hmm, on the paranoiac side, I'd make sure unhtml_roughly catch any exception and returns maybe_html (truncated) in this case | 08:53 |
| vila | about releasing from trunk: | 09:02 |
| vila | since I asked for a 2.3 branch on pqm too soon, I can now either: | 09:02 |
| vila | - ask a losa to pull/push overwrite from trunk for betas, or | 09:03 |
| vila | - release from trunk and create a lp:~bzr/bzr/2.3b2 for reference and forget about the lp:bzr/2.3 branch until the last beta | 09:04 |
| vila | thoughts ? | 09:04 |
| poolie | why would you even make a 2.3b2 branch? | 09:08 |
| poolie | wouldn't a tag be enough? | 09:08 |
| poolie | vila ,re the ssh failure, i may be a little out of date | 09:08 |
| poolie | on my branch | 09:08 |
| vila | ha, that would be a good news | 09:08 |
| poolie | but only a few days at most | 09:09 |
| poolie | did he just fix it? | 09:09 |
| vila | no, I'd say a week at least of not 2 | 09:09 |
| vila | if | 09:09 |
| vila | hmm, a tag on a revision not in the mainline, yeah, that should work | 09:10 |
| spiv | vila: btw lp:~spiv/bzr/split-NEWS is the work-in-progress, pushing the latest now | 09:16 |
| vila | spiv: great | 09:16 |
| poolie | so i'm heading towards having you just say, on a test | 09:20 |
| poolie | class | 09:20 |
| poolie | variations = [VaryByHttpClientImplementation()] | 09:21 |
| poolie | and that's enough | 09:21 |
| poolie | it's a pretty straightforward change from here, i think | 09:21 |
| vila | poolie: does it fly with multi-levels of parametrization in test_http ? | 09:23 |
| poolie | yes, you just list the ones you want and it multiplies them | 09:23 |
| vila | good | 09:23 |
| vila | there was a related bug on testtools I think... let me check | 09:24 |
| poolie | i might have filed it | 09:24 |
| poolie | test_http is in a nice spot of being quite ugly but in an organized way | 09:24 |
| poolie | so the cleanup is within reach | 09:24 |
| vila | hehe, yeah, that sounds like what my daughter is saying about her bedroom :) | 09:25 |
| poolie | :) | 09:27 |
| vila | I think it's a good example of code not updated to the latest standard because the main author didn't feel it was necessary :-) | 09:28 |
| vila | Which the other authors tend to disagree with :D | 09:28 |
| vila | can't find the bug on testtools... | 09:29 |
| poolie | :) | 09:29 |
| poolie | i may split this into testtools when i'm happy with ti | 09:29 |
| vila | poolie: don't rush :) We are already struggling with testtools updates... | 09:31 |
| vila | ha, https://bugs.edge.launchpad.net/testscenarios/+bug/393394 is the one I was thinking about | 09:32 |
| ubot5 | Launchpad bug 393394 in testscenarios "No way to assign bound methods to tests (affected: 1, heat: 0)" [Critical,Triaged] | 09:32 |
| vila | hmm, not clearly related though | 09:32 |
| poolie | critical? | 09:32 |
| vila | testscenarios | 09:33 |
| * mgz asks vila what the word 'bumbep' means | 10:23 | |
| vila | that's bumped with a 180 degrees rotation on the last letter because it makes many heads spin | 10:24 |
| mgz | ehehehe | 10:25 |
| poolie | mgz, hi | 10:26 |
| poolie | mgz, vila, let me know what you think of http://bazaar.launchpad.net/~mbp/bzr/597791-http-tests/annotate/head:/bzrlib/tests/test_variations.py | 10:26 |
| poolie | and http://bazaar.launchpad.net/~mbp/bzr/597791-http-tests/annotate/head:/bzrlib/tests/test_http.py | 10:26 |
| mgz | hey poolie. | 10:26 |
| poolie | if you like :) | 10:26 |
| poolie | and now, i think i can just delete load_tests from test_http | 10:27 |
| vila | assert(expected, actual) is preferred | 10:29 |
| vila | assertLength gives better feedback | 10:29 |
| vila | no comment on importing symbols :) | 10:30 |
| vila | the above remarks were for test_variations | 10:30 |
| vila | wow, test_http looks nice | 10:31 |
| poolie | it may be more lines but it's much more straightforward | 10:32 |
| poolie | and you could squash it if you wanted | 10:32 |
| vila | one comment though: how could a plugin reuse that ? | 10:32 |
| vila | squash ? | 10:32 |
| poolie | which bit? | 10:32 |
| mgz | the concept looks good to me. would you change scenarios methods into variations attributes, or is the latter intended just to be a simple way of handling the former? | 10:32 |
| poolie | i mean, you could take the variation lists and assign them to globals, then reference them from every test that needs them | 10:32 |
| poolie | mgz i'm not sure what you mean | 10:33 |
| spiv | poolie: looks interesting! But it's also time for dinner... | 10:33 |
| poolie | me too :) | 10:34 |
| vila | right, so variations can be reused and are declarative, very good | 10:34 |
| poolie | mgz i'd hope to clean up a lot of the existing load_tests into this | 10:34 |
| mgz | well, there are some tests in test_http which look like they'd work as SimpleVariation subclasses | 10:34 |
| poolie | ah, that's true | 10:34 |
| vila | now, the possible attribute values are still disconnected from the test classes... on the other hand, the scenarios are cleanly separated, easier to reused, still hard to extend | 10:35 |
| poolie | you could also have one that varies across a registry etc | 10:35 |
| poolie | vila, why hard to extend? | 10:35 |
| poolie | you're talking about where a plugin wants to get some existing tests applied to more scenarios? | 10:35 |
| poolie | i think in that case you should have a variation that goes over a registry or similar | 10:35 |
| vila | my remarks didn;t really apply to test_http but imagine tests that want to run against all type of repo/branch/wt | 10:36 |
| vila | or some plugin wanting to ensure it respects some API, so it want to inject itself in the scenarios | 10:36 |
| poolie | at the moment we have eg all_repository_format_scenarios() as a function | 10:36 |
| poolie | i would simply lift that into being VaryByRepositoryFormat.scenarios | 10:37 |
| poolie | you might not need to even change the code | 10:37 |
| ciss | hi, how can i export only those files that have been changed or added in a specific revision? | 10:37 |
| vila | could be, just raising the issue, not saying it's not addressed | 10:37 |
| poolie | for existing things where we have a per_repository directory it may not be worth changing it | 10:37 |
| vila | I'm thinking about plugins wanting to use a config registry for example (not yet implemented ;) | 10:38 |
| vila | or adding a new transport (though this case is already addressed in a ad-hoc way) | 10:39 |
| vila | or hook implementation that want to ensure they respect some API without clearly knowing what the API is | 10:39 |
| vila | and where is the 'variations' class attribute handled ? ha right multiply_tests_by_their_variations | 10:41 |
| vila | ha, right, so you don't inherit from the base class variations attribute right ? | 10:42 |
| vila | slight risk of errors... on the other hand you get the ability to change what the base class is proposing... | 10:44 |
| vila | I was thinking about a multiply_tests *method* instead of a multiply_tests_by_their_variations *function* but I never dug (digged ?)... | 10:46 |
| poolie | arguably it should be a test method | 10:46 |
| poolie | the unittest hierarchy is a bit strange | 10:47 |
| vila | yeah :-/ | 10:47 |
| poolie | eg the insistence on TestSuites not just lists, and that you should not dircectly construct a suite, but rather ask the loader | 10:47 |
| vila | well, a TestSuite is really a tree, *we* flatten them in many places... | 10:48 |
| poolie | right | 10:48 |
| vila | and the loader build many TestSuites automatically is the root cause I think | 10:48 |
| vila | building | 10:49 |
| vila | it fits pretty well with the --starting-with/load_tests design | 10:49 |
| vila | which want to be able to prune early instead of filtering after the fact | 10:49 |
| GaryvdM | Hi all. | 10:55 |
| vila | Hey GaryvdM | 10:55 |
| poolie | deletion of load_tests now pushed | 10:55 |
| GaryvdM | Is there a way to get BZR_TEST_PDB to break in the stack where the error was raised? | 10:56 |
| GaryvdM | not /testtools/testresult/real.py(423)addFailure() | 10:57 |
| vila | GaryvdM: mgz will answered this one quite precisely I'm sure :) | 10:58 |
| mgz | ehehe, pull bzr.dev Gary :) | 10:58 |
| * mgz marks bug 504070 fixed while he's at it | 10:59 | |
| ubot5 | Launchpad bug 504070 in testtools "testtools change broke BZR_TEST_PDB (affected: 1, heat: 7)" [Wishlist,Triaged] https://launchpad.net/bugs/504070 | 10:59 |
| GaryvdM | ok | 10:59 |
| spiv | ciss: hmm, not sure there's a convenient way, although the bzr-upload plugin presumably does something similar internally... | 11:05 |
| vila | ciss: what is your use case ? | 11:06 |
| Fuu | Anyone aware of research papers that discuss bazaar, or dvcs in general? | 11:16 |
| poolie | ok, good night all | 11:18 |
| kmdm | Hi all, just wondering how 'bzr shelve' works / where it stores the deltas... since I'm now getting "bzr: ERROR: Unknown record type: 'n'" when trying to unshelve and a search & replace I did might have touched those files so I might need to manually revert that... | 11:23 |
| mgz | kmdm: in .bzr/checkout/shelf | 11:29 |
| kmdm | mgz: perfect - thanks, fixing the replacement got my changeset back :) | 11:31 |
| GaryvdM | mgz: You rock. BZR_TEST_PDB Woking again. | 11:44 |
| mgz | cunning time machine use :) | 11:44 |
| txdv | does bzr have an equivalent to git's staging area? | 13:51 |
| txdv | lets say i modified 10 files but i want to commit only 6 modified files | 13:51 |
| kmdm | bzr shelve? | 13:52 |
| txdv | it shelves all changes | 13:53 |
| txdv | doesn't it? | 13:53 |
| kmdm | nope, you can give it a list of files... and it'll commit a subset of deltas from any file | 13:54 |
| txdv | i see | 13:55 |
| kmdm | err, s/commit/shelve/ | 13:55 |
| soren | txdv: You can also just specify the files you want to commit... "bzr commit foo.c python/bar.py ChangeLog otherstuff" or whatnot | 13:58 |
| txdv | hmm | 13:58 |
| txdv | i see | 13:58 |
| txdv | kthnx | 13:59 |
| kmdm | yea, and that xD | 13:59 |
| txdv | hm it would be awesome if i could specifiy the exact line numbers i want to commit | 14:00 |
| txdv | (or have a tool better suited for this kind of ction) | 14:00 |
| mgz | run `bzr shelve` and it'll interactively prompt you on diff hunks | 14:02 |
| txdv | o rly? do i have to select a proper tool for that? | 14:03 |
| soren | The 'y' and 'n' keys on your keyboard. | 14:03 |
| === Ursinha-afk is now known as Ursinha | ||
| txdv | i can't select it linewise | 14:09 |
| txdv | that what i was talking about | 14:09 |
| maxb | yes, it's only hunkwise | 14:10 |
| txdv | it would be awesome to have it linewise, git doesn't support it too | 14:10 |
| txdv | for once bzr would have a feature that git doesn't | 14:10 |
| mgz | even lines isn't really enough for breaking a change into two bits | 14:11 |
| mgz | quite often change one is editing some code and change two is reindenting it or something | 14:11 |
| mgz | at which point, you just need to use your text editor anyway | 14:12 |
| Glenjamin | not trying to start a fight here, but what's the advantage of splitting up commits like this? | 14:14 |
| mgz | retrospectively you mean? some people just work that way, start with a big mess, then tidy it up. | 14:15 |
| mgz | other people can manage little neat bits one at a time. | 14:16 |
| Glenjamin | well yes, but what is gained by splitting the commits restospectively? | 14:16 |
| mgz | it makes person of type #1 look like a person of type #2 :D | 14:16 |
| Glenjamin | it's fairly unlikely that you can untangle a finished product to a halfway-house that works | 14:16 |
| ddaa | it's sometimes important for code review | 14:17 |
| ddaa | then you usually want to move some of the changes to different branches | 14:17 |
| ddaa | so you can have one branch for "quick bug fixes" | 14:17 |
| ddaa | on for "stylistic cleanups" | 14:17 |
| ddaa | and one for the feature one was supposed to code in the first place | 14:17 |
| Glenjamin | that makes sense, i guess in my general work I know it'll be merging it all into trunk - so if I forgot to make my commits granular I live with it | 14:18 |
| Glenjamin | *it'll be me | 14:18 |
| rubbs | I've used shelf/splitting my commits for a couple of reasons. I try to commit when I have one complete "idea" done, but if, in getting that idea done, I had to work slightly on something else, it's nice to keep things insular | 14:19 |
| rubbs | also, I frequently get into a groove and bash out a lot of stuff, and then later realize that anyone else looking at my log would be really confused, so I break it down so it's easier for a third party to follow | 14:20 |
| rubbs | it basically allows people to show their line of thinking, so if a big thing lands people can understand what's going on. | 14:21 |
| Glenjamin | I guess i've mostly worked on either small fixes for open source, or closed source stuff where the log doesn't have to be perfect | 14:22 |
| === zyga is now known as zyga-lunch | ||
| Glenjamin | Can anyone explain to me what "bzr push" into Git repositories does not work, although it is possible to use "bzr dpush". means? | 15:03 |
| Glenjamin | I can push to git but i'll lose some information? | 15:03 |
| jelmer | Glenjamin: yes, you'll lose revision properties for example. | 15:04 |
| jelmer | as well as rename information | 15:04 |
| === zyga-lunch is now known as zyga | ||
| CcxCZ | is launchpad broken with py2.7? | 15:22 |
| CcxCZ | http://paste.pocoo.org/show/272702/ | 15:23 |
| mgz | fixed on trunk. | 15:23 |
| mgz | there are various issues with Python 2.7 on the current release version on bzr, you're better off staying with 2.6 | 15:23 |
| vila | CcxCZ: ... mgz was faster, I was going to say exactly that | 15:24 |
| achiang | hello, i have two branches that diverged from each other at some point. what's the best way to have branch B pick up branch A's changes? i'd like to review each change from A to make sure it's appropriate for B | 15:25 |
| mgz | `bzr merge --preview A` | 15:25 |
| achiang | thanks, i'll try that | 15:26 |
| vila | achiang: start by 'bzr missing' to see how they diverged, then 'cd B ; bzr merge A' will merge everything at once, | 15:26 |
| mgz | if it's a giant diff, you could merge each revision in turn. | 15:26 |
| vila | achiang: to limit what is merge do: 'bzr merge A -r<last_rev_to_merge> | 15:27 |
| vila | mgz: ok, I let you explain :) I need to release 2.3b2 | 15:27 |
| mgz | and remember you need to commit after merging and resolving any conflicts. | 15:27 |
| mgz | ack, already vila? | 15:27 |
| achiang | mgz: vila: thanks, much appreciated | 15:27 |
| mgz | we're not frozen after that are we? how many betas are planned? | 15:27 |
| vila | mgz: time-based releases suffer no delay :) What is ready is ready | 15:28 |
| vila | mgz: argh, saying it again, not release, freeze | 15:28 |
| mgz | I wasn't suggesting delay, just wondering where the time had gone | 15:28 |
| vila | in a bunch of little tasks all building up ;-P | 15:28 |
| mgz | okay, I need to leave shortly but will try and get through more of my todo list over the weekend | 15:29 |
| achiang | the merge went very nicely. it even merged binary files correctly. thanks again. | 15:33 |
| === 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 | Release Manager: vila | 2.3b2 is frozen, build the isntallers ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | GaryvdM: ping | 16:39 |
| vila | d0xxx: ping | 16:39 |
| GaryvdM | Hl vila | 16:40 |
| === Ursinha is now known as Ursinha-lunch | ||
| vila | GaryvdM: I just froze 2.3b2, I expect some plugins will need an update | 16:40 |
| GaryvdM | ok | 16:41 |
| vila | I've sent an mp for bzr-rewrite that has already landed and I've pushed a fix on bzr-gtk | 16:41 |
| vila | I don't have anymore info about the other plugins at this pont | 16:41 |
| vila | point | 16:41 |
| GaryvdM | Ok | 16:41 |
| vila | I'll pass around during the week-end to try to catch d0xxx and build the OSX 10.5 installer from what he'll told me | 16:42 |
| vila | I'm going to update http://wiki.bazaar.canonical.com/Releases/2.3b2 | 16:43 |
| GaryvdM | vila: It would be nice to make a ical of expected releases. I'll try do that soon... | 16:57 |
| vila | hmm, check that there isn't an existing one first | 16:57 |
| vila | istr that poolie created one long ago, may be for the sprints or something but it should already be public | 16:58 |
| vila | GaryvdM: ^ and that's a .... good idea ;) | 16:58 |
| * vila pfew I managed to mistype the F ... | 16:58 | |
| vila | GaryvdM: but let's add only a few dates there so we can adapt | 17:03 |
| === Ursinha-lunch is now known as Ursinha | ||
| === zyga is now known as zyga-gone | ||
| samgee | I've got a tree with a large tar.bz2 file in it. I made a bzr branch out of that tree and committed. Then I unpacked the tarball, deleted some files and repacked it. Then I did the second commit and tried to push it to a server. A few hours later the client seems to be hanging and the server reports a MemoryError: http://dpaste.com/255095/ | 19:26 |
| samgee | Anything I can do about this? | 19:26 |
| mgz | ideally, Don't Do That. you can use something like pristine tar and avoid versioning a giant binary blob | 19:29 |
| samgee | Ideally, indeed. Sadly, the situation is less than ideal. :) | 19:31 |
| dobey | how do i make an edit to an existing revision in bzr? like if i typoed --author argument or something? i'm having trouble finding documentation about how to do that | 19:51 |
| davidstrauss | We're running into this bug on the Drupal.org infrastructure repositories: https://bugs.launchpad.net/bzr/+bug/483388 | 19:57 |
| ubot5 | Launchpad bug 483388 in Bazaar "merge lies about lacking common ancestors when it has multiple choices (affected: 4, heat: 6)" [Medium,Confirmed] | 19:57 |
| davidstrauss | Can we manually fix the merge tracking data? | 19:57 |
| davidstrauss | vila, any idea ^^ | 20:02 |
| davidstrauss | poolie, do you have a minute to help me with a merge tracking issue that's blocking us on drupal.org? | 20:18 |
| vila | davidstrauss: I was afk and just pass around, try --weave or add a comment to the bug, if you have accessible branches that help reproduce the problem, you'll get better feedback | 20:18 |
| davidstrauss | vila, even when you use --weave, bzr still tries to find an LCA first | 20:19 |
| vila | davidstrauss: still a bit early for poolie: 6:19AM | 20:19 |
| davidstrauss | ah | 20:19 |
| vila | then add a reproducing recipe to the bug, this is hard to diagnose without actual data | 20:20 |
| davidstrauss | vila, is there a way for me to just force bzr to acknowledge two branches that are fully synched via merging? | 20:20 |
| vila | (for pretty high values of hard) | 20:20 |
| davidstrauss | vila, these branches aren't public, but we can give bzr people accesss | 20:20 |
| vila | if the merge doesn't succeed ? Hmm | 20:20 |
| davidstrauss | vila, i just want to cherry pick to consistency and then mark the branches as having no missing revisions versus each other | 20:21 |
| dash | davidstrauss: do 'bzr merge' and then use 'bzr revert .' | 20:21 |
| davidstrauss | dash, bzr merge fails | 20:22 |
| dash | that'll keep the merge but remove any changes. | 20:22 |
| dash | davidstrauss: what kind of fails, though | 20:22 |
| vila | well, if you cherry-pick in both branches then you've address your immediate problem no ? | 20:22 |
| davidstrauss | vila, yes, but that doesn't update any tracking data | 20:22 |
| davidstrauss | vila, nor does it mark the revisions as merges | 20:22 |
| davidstrauss | vila, i'm happy to cherry pick *once* to fix this, but i want merges to work properly from that point | 20:23 |
| vila | davidstrauss: right, we need to fix a bug for that no ? I'm just proposing a workaround to unblock you | 20:23 |
| vila | If we don't have a reproducing recipe this makes it harder to fox | 20:23 |
| vila | fix | 20:24 |
| vila | bah, last typo of the week | 20:24 |
| davidstrauss | vila, there's been a reproducing recipe on the LP bug for a very long time | 20:24 |
| vila | davidstrauss: you misread it, this is a case where there is no valid answer: the branches doesn't have a common ancestor | 20:25 |
| davidstrauss | vila, i've run into this bug on multiple projects at this point | 20:25 |
| davidstrauss | vila, that bug is for when they have two or more | 20:25 |
| vila | davidstrauss: I understand that but I can only repeat: give me a reproducing recipe among any of your multiple projects | 20:26 |
| davidstrauss | vila, and in the case of both projects i've had trouble with this on, it's been the same: multiple common ancestors | 20:26 |
| davidstrauss | vila, how is the description on that bug not a reproducing recipe? | 20:26 |
| vila | davidstrauss: sorry, as I said above I'm only passing around | 20:26 |
| davidstrauss | vila, the description on the bug includes a shell script that demonstrates this problem | 20:27 |
| vila | davidstrauss: if you want to help you later, give a reproducing recipe that, unlike the one in the bug report, have a common ancestor which is not NULL | 20:27 |
| davidstrauss | vila, i can give access to individuals to the actual branches | 20:27 |
| davidstrauss | vila, but i can't just make them public | 20:28 |
| vila | fine, put that in the bug comment | 20:28 |
| vila | there should also be some -Dmerge debug flag but I don't remember the details about what is output (but that may be something you can add to the bug report) | 20:29 |
| davidstrauss | vila, ok, done. thanks. | 20:29 |
| vila | oh, and mention which bzr version you're using too (and try trunk, just in case) | 20:30 |
| vila | davidstrauss: nm, thanks for providing the info | 20:30 |
| * vila off | 20:30 | |
| kklimonda | hey, I have a question about how to use bzr.. ok, how to use bzr in a specific way. I'm working on a branch of a library, adding some new features to it that I've discussed with the main developer. Now, I'd like to create a new branch based on this one to write some stuff I haven't yet discussed but what I need right now. The first branch is going to get merged, the second one may (or may not) but it | 23:15 |
| kklimonda | depends on the first one. How can I work on both branches in parallel, merging the first one into the second in a way that make it possible to present the second one for the merge at the later date if the idea is accepted? | 23:15 |
| mgz | are the things you're working on actually interdependant? | 23:18 |
| mgz | of not, just use two branches from the current trunk. | 23:18 |
| mgz | if they are, branch from your original branch rather than trunk, and if you commit something you need for your second branch, merge the first one back in again | 23:19 |
| kklimonda | mgz: how is launchpad's merge system interpret the second merge request? | 23:19 |
| kklimonda | how is it going to* | 23:19 |
| mgz | merge proposals have a "mark as dependent on another branch" thing you can use. | 23:20 |
| mgz | just paste the lp link of the first branch in there on the second merge proposal | 23:21 |
| kklimonda | mhm, makes sense. thanks | 23:21 |
| mgz | (and probably mention it in the description, as that can be a little easy for the maintainer to miss) | 23:21 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
