| mtaylor | lifeless: around? | 00:23 |
|---|---|---|
| lifeless | mtaylor: sure am | 00:27 |
| lifeless | mtaylor: what can I do for you? | 00:28 |
| mtaylor | lifeless: well... I'm going to get to have yet another launchpad/bzr vs. git/github discussion | 00:29 |
| * mtaylor jumps up and down with excitement | 00:29 | |
| mtaylor | lifeless: and as part of prepping for it, it has been asked about the feasibility of us keeping things in launchpad but letting the devs continue to use git/github and syncing them | 00:30 |
| mtaylor | lifeless: I think this is a terrible idea, mind you | 00:30 |
| mtaylor | as the bug/blueprint/merge request integration is one of the main things we're gaining from launchpad and I believe we'd lose that that way ... | 00:30 |
| mtaylor | lifeless: but - I was wondering if you had any advice/pointers on where I should start looking/poking to be able to give real and specific feedback about that (would be easier if I used github for any reason I imagine) | 00:31 |
| lifeless | uhm | 00:34 |
| lifeless | is it a valid summary to say | 00:35 |
| lifeless | 'some people want to keep working on github using git' | 00:35 |
| mtaylor | yes | 00:35 |
| lifeless | 'team leads want the work tracking / planning features launchpad offer' | 00:35 |
| mtaylor | yes | 00:35 |
| lifeless | is there more to it than that ? | 00:35 |
| mtaylor | nope | 00:35 |
| lifeless | ok | 00:35 |
| lifeless | one way | 00:35 |
| lifeless | trunk on lp | 00:35 |
| lifeless | feature branchces on lp | 00:35 |
| lifeless | merge proposals on lp | 00:36 |
| lifeless | have your well known branches - trunk, releases - mirrored to git | 00:36 |
| lifeless | and hell, sourceforge and the hg site too | 00:36 |
| lifeless | using bzr-* plugins and cron | 00:36 |
| mtaylor | (there's an hg site?) | 00:36 |
| mtaylor | k | 00:36 |
| lifeless | then say in your project docs | 00:36 |
| lifeless | 'launchpad is official, launchpad is great. But if you have muscle memory of $other vcs, see x, y, z and you can work on that site for *code management only*' | 00:37 |
| lifeless | make the $other site pages point to launchpad with ambiguity | 00:37 |
| mtaylor | ok. that all seems sensible... | 00:38 |
| lifeless | and document how the dev in question can generate a branch on launchpad (again, push with the bzr-* plugin to launchpad) | 00:38 |
| lifeless | for merges etc | 00:38 |
| lifeless | I suggest doing multiple sites because your center of gravity will be less a battle of two things and more a common-reference point - its a social angle on it | 00:38 |
| mtaylor | given the way git arranges branches - does bzr-git pushing to a branch on launchpad do what I expect? | 00:38 |
| mtaylor | mmm. very good point | 00:38 |
| lifeless | mtaylor: bitbucket.org is the hg one | 00:39 |
| lifeless | mtaylor: now, the git folk may say 'we don't care about hg/svn we wanna bikket gnar gnar gnar' | 00:39 |
| lifeless | mtaylor: I would then ask - so if its not about acessability for non bzr users, what is it about ? :) | 00:40 |
| mtaylor | lifeless: I, in fact, assure you they will say exactly that | 00:40 |
| mkanat | There's another hg one, too. | 00:41 |
| === oubiwann is now known as oubiwann-away | ||
| mtaylor | jelmer: bzr: ERROR: exceptions.KeyError: 'No such TDB entry' | 01:24 |
| jelmer | mtaylor: When? | 01:25 |
| mtaylor | jelmer: I was trying to bzr dpush a bzr branch to an empty git repo on github | 01:26 |
| mtaylor | jelmer: I'm using head of lp:dulwich and head of lp:bzr-git | 01:26 |
| mtaylor | jelmer: it seemed to be happening right after it finished updating the git map | 01:26 |
| jelmer | mtaylor, does your repository perhaps contain ghosts? | 01:29 |
| jelmer | mtaylor: it might also be a regression in the dpush code which is being refactored at the moment so we can support roundtripping. I would recommend sticking with the releases for the time being. | 01:30 |
| mtaylor | jelmer: ah ok | 01:30 |
| mtaylor | jelmer: the version in lucid broke in a different way so I just grabbed trunk | 01:31 |
| mtaylor | jelmer: I'll try a recent release | 01:31 |
| mtaylor | jelmer: well, that's certianly creating a different amount of things in the git map | 01:32 |
| mtaylor | jelmer: trying 0.5.1 | 01:33 |
| jelmer | mtaylor, if you can still reproduce some issue with 0.5.1, please file a bug | 01:38 |
| jelmer | I'm off to get some sleep, back in ~7h :-) | 01:38 |
| mtaylor | jelmer: will do | 01:38 |
| mtaylor | jelmer: thanks | 01:38 |
| poolie | mkanat: hi, are you around? | 01:39 |
| mkanat | poolie: I am! | 01:39 |
| poolie | are you still working on loggerhead? | 01:40 |
| poolie | if so, i think we should be more in touch | 01:40 |
| mkanat | poolie: Yeah, I'm still doing stability stuff. | 01:40 |
| mkanat | poolie: Yeah, I think that's a good idea. :-) | 01:40 |
| poolie | are you working with anyone else on it? | 01:40 |
| mkanat | poolie: Well, I get people to review my patches now and again. | 01:40 |
| mkanat | poolie: Usually Peng or mwhudson. | 01:41 |
| poolie | oh that's good | 01:41 |
| poolie | but sometimes you just commit to trunk? | 01:41 |
| mkanat | poolie: No, I don't have privs. | 01:41 |
| mkanat | poolie: So all my merge proposals get reviewed. | 01:41 |
| poolie | (i'm not trying to give you a hard time, just to understand) | 01:41 |
| poolie | ah ok | 01:41 |
| mkanat | poolie: Which is probably good, at this point. | 01:41 |
| poolie | istm you probably should be a committer though? | 01:41 |
| poolie | even if you still ask for reviews first | 01:42 |
| mkanat | poolie: Possibly, yeah. | 01:42 |
| mkanat | poolie: Sometimes it's not too clear when the proposal is "reviewed enough" to check in, though. | 01:42 |
| poolie | yeah | 01:42 |
| poolie | but you can just say "is this reviewed enough yet?" until people give a clear answer | 01:43 |
| poolie | i had a couple of other ideas | 01:43 |
| poolie | one would be to post an occasional short note to the bzr list about what you're doing | 01:43 |
| mkanat | poolie: That'd be good. I should probably subscribe to that list. :-) | 01:43 |
| poolie | :) | 01:43 |
| poolie | even if you just skim it, it would be a good idea | 01:44 |
| mkanat | poolie: FYI, right now what I'm doing is tracking down a memory leak, but meliae is breaking on my platform and jam and I haven't figured it out yet. | 01:44 |
| poolie | of course you don't need to recapitulate every patch but just an idea of the general area might help | 01:44 |
| poolie | yes he said so | 01:44 |
| poolie | that might also be reasonable to post about | 01:44 |
| mkanat | poolie: http://wiki.bazaar.canonical.com/BzrDevelopment mentions the word "mailing list" several times but has no link to it. | 01:45 |
| poolie | jam knows the most about meliae but the build problems might ring a bell for someone else | 01:45 |
| poolie | heh, really | 01:45 |
| poolie | we can fix that | 01:45 |
| poolie | that page is pretty old | 01:49 |
| poolie | better now, mkanat? | 01:49 |
| poolie | how did you get to that page? | 01:49 |
| mkanat | poolie: Hahaha, better! | 01:49 |
| poolie | we could adjust the links to it | 01:49 |
| mkanat | poolie: google "bzr developers mailing list" | 01:49 |
| lifeless | thumper: so this revno is wrong bug | 01:51 |
| mkanat | poolie: Okay, I've subscribed to the mailing list. | 01:51 |
| lifeless | thumper: is it on lp-code ? | 01:51 |
| poolie | mkanat: so the final thing was, perhaps you should be more in touch with the LOSAs? | 02:09 |
| mkanat | poolie: Yeah, that would be great. | 02:09 |
| * spm waves hi to mkanat | 02:10 | |
| mkanat | Hey spm. :-) | 02:10 |
| poolie | yay :) | 02:10 |
| mkanat | poolie: Well, I'm in touch with spm. | 02:10 |
| poolie | spm, mkanat is working on loggerhead | 02:10 |
| mkanat | poolie: But he's not always around. | 02:10 |
| poolie | oh ok | 02:10 |
| poolie | mkanat: are you in the us? but you normally work evenings on this? | 02:10 |
| mkanat | poolie: I am in the US. My schedule varies a fair amount. | 02:10 |
| mkanat | poolie: I'm in California. | 02:10 |
| poolie | ok | 02:11 |
| poolie | there are a couple of people in the US | 02:11 |
| poolie | mbarnett and . um | 02:11 |
| mkanat | poolie: But I'd say generally I'm working between 9am and 11pm. | 02:11 |
| spm | mkanat: have you been introduced to the other losas? mthaddon, Chex and mbarnett? Chex and mbarnett are roughly in your TZ. | 02:11 |
| poolie | oh chex | 02:11 |
| mkanat | spm: I haven't, no. | 02:11 |
| mkanat | spm: I think what would be ideal is if you guys basically considered me the contact for loggerhead stability. | 02:11 |
| poolie | so i think it would be nice if there was a conversation here about | 02:11 |
| poolie | pain points, getting new versions rolled out | 02:12 |
| poolie | getting you debug data from our deployment | 02:12 |
| poolie | what else? | 02:12 |
| spm | mkanat: scary: https://edge.launchpad.net/~canonical-losas/+mugshots | 02:12 |
| mkanat | spm: Ah ha! :-) | 02:12 |
| spm | poolie: we auto rollout lp-loggerhead, as distinct from 'loggerhead' every day if a new version is available? that's been in place for some time. ?? | 02:13 |
| mkanat | Hmm, I thought I had a picture on launchpad.... | 02:13 |
| mkanat | spm: I think at some point there's going to have to be a conversation about making a stabler branch of loggerhead that you guys can use, though. | 02:13 |
| poolie | mb is particularly scary | 02:13 |
| spm | mkanat: I can abuse my powa and give you an ... unsuitable one :-) | 02:14 |
| mkanat | spm: lol. | 02:14 |
| mkanat | spm: No, I have one, I'll go grab it and upload it. | 02:14 |
| poolie | it's been years since i've seen the goatse guy | 02:14 |
| spm | ..... | 02:14 |
| mkanat | Oh, I do have a mugshot. | 02:14 |
| poolie | is there any suitable list where all these people could talk? | 02:15 |
| mkanat | But I can't find the URL in the Wall Of Text. | 02:15 |
| poolie | maybe it's enough to just have mail to losas@ plus max and me... | 02:15 |
| mkanat | poolie: I imagine we're all on the bzr list, no? | 02:16 |
| spm | would we need tim involved? or is this no longer in his baliwack? | 02:16 |
| poolie | i don't know if the losas are | 02:16 |
| spm | what poolie said | 02:16 |
| poolie | probably it is | 02:16 |
| mkanat | Maybe there should just be a loggerhead list. | 02:16 |
| poolie | it's a bit between the cracks | 02:16 |
| poolie | arguably lp-dev would be better | 02:16 |
| spm | +1 | 02:16 |
| poolie | that's public, and fairly low traffic | 02:16 |
| poolie | and the losas should be subscribed | 02:16 |
| poolie | and i would like to see it have a bit more traffic | 02:17 |
| spm | max, fwiw, lp-loggerhead is *vastly* more stable these days. the few occaisons I've been alerted in recent weeks, it's typically fixed itself before I could get much done beyond basic "is it really/still down?" | 02:18 |
| poolie | spm, mkanat, what do you think? | 02:18 |
| mkanat | spm: That's pretty good! :-) | 02:18 |
| poolie | i'd like to see it give a better message when it does fail | 02:18 |
| mtaylor | anybody know - if I'm doing a bzr-git dpush --- if I abort it after updating git map during generating git objects - will it have to do the git map all over again when I restart it? | 02:18 |
| mkanat | poolie: Yeah, lp-dev would work. | 02:18 |
| poolie | ideally with an oops-like identifier that can go into a bug report | 02:18 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=like | 02:18 |
| * poolie pets the bot | 02:19 | |
| spm | poolie: yah, lp-dev is fine by me | 02:19 |
| poolie | spm the losas do all read it? | 02:19 |
| spm | "no comment" ;-) | 02:19 |
| spm | we are subscribed. reading implies... other things. | 02:19 |
| poolie | i won't even bother asking about "understand" then :) | 02:20 |
| spm | heh | 02:20 |
| spm | I'd suggest it's a case of 'keep an eye on', vs read every thread. Most discussions therein are more at the code layer and only rarely touch on operational concerns. So that would tend to define the scheduling it gets in our attention span. | 02:21 |
| poolie | that's fine | 02:22 |
| poolie | so if the subject is clear, you'll read it | 02:22 |
| poolie | that's what i though | 02:22 |
| poolie | *thought | 02:22 |
| poolie | so mkanat perhaps you would be kind enough to post a thread saying what you're up to and soliciting feedback from losas | 02:23 |
| poolie | how do things get into lp-loggerhead? | 02:23 |
| spm | not speaking for the others; but yes for me. Some persons who reply at top levels in a thread will also garner my attention. But that's a personal info filter. | 02:23 |
| spm | poolie: thumper is probably best placed to answer that? or mwh if he's around. | 02:24 |
| mkanat | poolie: Mostly by somebody asking, I think. | 02:24 |
| mkanat | poolie: I think the trouble with loggerhead is that it has a great UI, but until recently it had massive, fundamental architectural problems. | 02:25 |
| poolie | like you, if you think you've fixed something? | 02:25 |
| poolie | mm | 02:25 |
| mkanat | poolie: Yeah. | 02:25 |
| poolie | also there is a project towards having an edge/beta loggerhead | 02:25 |
| poolie | i'd like to know where that's up to | 02:25 |
| mkanat | poolie: Well, that's basically what you're running in production. | 02:25 |
| mkanat | poolie: Which is the problem. | 02:25 |
| mkanat | poolie: Or at least, one of the problems. | 02:26 |
| spm | production being edge, in this specific case? yes. | 02:26 |
| poolie | i mean, a place by which new code can be exposed to realistic load | 02:26 |
| poolie | and then something that updates more solwly | 02:26 |
| mkanat | spm: Well, lp-loggerhead pretty much contains loggerhead trunk. | 02:26 |
| mkanat | poolie: Oh, yes. | 02:27 |
| spm | mkanat: kk, I'd assumed as much; but wasn't aware of the fine print - if any | 02:27 |
| mkanat | poolie: That is definitely something we should have. | 02:27 |
| spm | poolie: that's RT:38985 fwiw; apologies there - looks like it was languishing from not being correctly tagged (by us). | 02:34 |
| poolie | oh ok i was wondering about that | 02:35 |
| poolie | spm so you can look at that as making edge faster-moving, or lpnet slower-moving, or both | 02:35 |
| poolie | at any rate getting a bit away from one-size fits all | 02:36 |
| poolie | i guess to prioritize this it would be useful to know | 02:36 |
| spm | when in doubt, raise it with tom/francis. we do try real hard to pay attention to the priorities, so please do actively manage those :-) | 02:36 |
| spm | ha. snap. :-) | 02:36 |
| poolie | - how often do rollouts cause problems? | 02:36 |
| poolie | does mkanat or anyone else wish to roll out any faster? | 02:36 |
| mkanat | No, definitely not. | 02:36 |
| poolie | if we did roll out faster, would the feedback data get back to mkanat? | 02:36 |
| poolie | "definitely not" want to go faster? | 02:37 |
| lifeless | I'd like to be able to rollout every time that there is a fix :) | 02:37 |
| mkanat | poolie: Right, definitely not want to go faster, at the moment, because it's trunk. | 02:37 |
| spm | I'm not aware of any cases of a rollout causing problems - having said that, I don't we actually have too many either. so... :-/ | 02:37 |
| mkanat | lifeless: Right, but to do that, we need two branches. | 02:37 |
| GradysGhost | Is this a bad time/room to ask for help? Is there a better room for that? It appears I'm interrupting something. | 02:37 |
| mkanat | lifeless: We need an actually stable branch of loggerhead, preferably one with better test coverage on load issues. | 02:37 |
| mtaylor | lifeless: generating git objects 2867/11230 | 02:38 |
| mtaylor | lifeless: perhaps I should have picked something other than drizzle to use as a test case :) | 02:38 |
| mkanat | GradysGhost: This channel is fine. | 02:38 |
| spm | given our current setup tho - if a rollout breaks; we can/do revert - I think automatically even for simple "it no responds correctly" | 02:38 |
| spm | GradysGhost: go for it. we can always /ignore you ;-) | 02:38 |
| GradysGhost | heh. True. | 02:38 |
| lifeless | mkanat: seems like you are well on the way to heaven | 02:39 |
| mkanat | lifeless: lol | 02:39 |
| GradysGhost | Okay, so I'm trying to set up bzr on my server so that only myself and a friend can commit changes to the working product. Forgive me, but this is the first time I've ever worked with any kind of revision control system, so my terminology may not be correct. | 02:39 |
| mkanat | GradysGhost: That's fine. :-) Is it a Unix system? | 02:40 |
| mkanat | Or *nix, I guess I should say. | 02:41 |
| GradysGhost | I've set up a Bazaar repository at /opt/bazaar/repository. I've started bzr with `bzr serve --directory=/opt/bazaar/repository` and that appears to be working. It is Linux Mint Helena. | 02:41 |
| GradysGhost | I intentionally left off the --allow-write parameter since that appears to allow global writing. | 02:41 |
| GradysGhost | The process is running as root. | 02:41 |
| mkanat | GradysGhost: Okay. You just use basic *nix permissions to control who can write to the directory, and then you allow SSH access to your server from user accounts. | 02:41 |
| GradysGhost | That's what I'm getting to. | 02:41 |
| GradysGhost | It looks like everything should be in order, but it's still failing. | 02:42 |
| GradysGhost | So I added a group and put my own user account into that group, then I recursively set the group ownership on the repo to that group. | 02:42 |
| GradysGhost | Perms are 775 on all files, including the .bzr control directory. | 02:43 |
| GradysGhost | So I do this: `bzr push --create-prefix bzr_ssh://ryan@localhost/path/to/branch` | 02:43 |
| GradysGhost | And I get an error: bzr: ERROR: Permission denied: "earthcrash/client/": : [Errno 13] Permission denied: '/earthcrash' | 02:43 |
| spm | poolie: as an aid to clarity. what is the .. governance (I guess) of loggerhead vs lp-loggerhead these days? aiui, lh is a stock oss project - that just happens to have large numbers of lp devs working on it, vs lp-lh which is the blessed version of same that we actually run with. ? | 02:43 |
| lifeless | GradysGhost: you have to yse --allow-write, or the server won't permit *any writes* | 02:44 |
| GradysGhost | Okay. I'll try that. That doesn't allow global write perms for anybody? | 02:44 |
| lifeless | GradysGhost: it does | 02:44 |
| GradysGhost | As long as world perms lack write? | 02:44 |
| lifeless | GradysGhost: we recommend using the server with bzr+ssh or bzr+http if you wish to have people writing. | 02:44 |
| GradysGhost | I have SSH installed. What kind of config do I need to do to make it bzr+ssh only, disallowing write access to anyone without a valid account and auth? | 02:45 |
| GradysGhost | SSH does work; I've been using it on this config for at least a year. | 02:45 |
| GradysGhost | Well, at least 6 months. | 02:45 |
| lifeless | GradysGhost: you are already setup then; just use bzr+ssh urls on your client machines. | 02:47 |
| lifeless | GradysGhost: there is no need to have a continually running server | 02:47 |
| lifeless | as the ssh server will start bzr when a bzr+ssh client connects. | 02:47 |
| GradysGhost | Okay. I gotcha. I was under the understanding that I still needed to have bzr running in server mode. | 02:47 |
| GradysGhost | That's very cool. I was unclear on that. | 02:47 |
| GradysGhost | I will try it out. Thanks for the help, lifeless. | 02:47 |
| poolie | hi spiv? | 02:50 |
| mkanat | spm: lp-loggerhead has a bunch of modifications to loggerhead. | 02:59 |
| mkanat | spm: Mostly about the environment that it runs in--Paste changes, and so on. | 02:59 |
| mkanat | spm: It also represents the whole package that runs on launchpad, including any plugins, I believe. | 02:59 |
| spm | mkanat: oki. so we do very much have a separate blessed version. I guess - who is the blessor in the usual case. ? | 03:00 |
| mkanat | spm: It used to be mwhudson. | 03:00 |
| mkanat | spm: The thing is, the loggerhead that's in lp-loggerhead is pretty much stock loggerhead. | 03:00 |
| mkanat | spm: There are just a bunch of additional files. | 03:00 |
| mkanat | spm: I suppose Peng also handles lp-loggerhead. | 03:01 |
| mkanat | spm: It's probably a bit up in the air. Maybe thumper? | 03:01 |
| mkanat | Anyhow, I'm out for the night. :-) | 03:02 |
| mkanat | Later, folks! | 03:02 |
| lifeless | it might be nice to factor those differences out | 03:02 |
| spm | possibly. the question has come up in similar terms regarding lp as a whole. because we're dealing with prod code, and confidentiality of protected code (etc), we need a Canonical person to give the nod that X is ok to go into prod. | 03:02 |
| lifeless | into a non-merged change so just config changes | 03:02 |
| lifeless | then we could more easily experiment | 03:02 |
| mkanat | lifeless: I agree completely. | 03:02 |
| lifeless | mkanat: if you have time available in the contract, that would be good to do, then. | 03:03 |
| mkanat | lifeless: Yeah, it's something I could talk to Francis about. | 03:03 |
| thumper | lifeless, mkanat: hi, what's up | 03:04 |
| thumper | ? | 03:04 |
| lifeless | mkanat: please do :) | 03:04 |
| mkanat | thumper: Oh, nothing. Was just wondering if you were in charge of the launchpad-loggerhead branch now. | 03:05 |
| lifeless | thumper: just chewing over loggerhead - it came up on the bzr list | 03:05 |
| thumper | the launchpad-loggerhead branch has been merged into launchpad proper | 03:05 |
| mkanat | poolie, lifeless: Can you send me an email or something to remind me to do all the things we talked about just now? | 03:05 |
| mkanat | I'd do it myself but I have to run. | 03:05 |
| lifeless | thumper: nothing in particular on de agenda; see the backlog for nitty details | 03:05 |
| thumper | as of a few months ago | 03:05 |
| mkanat | thumper: Oh! | 03:05 |
| mkanat | So that's done. | 03:05 |
| lifeless | cool | 03:05 |
| lifeless | thumper: you really should give Guido his time machine back. | 03:06 |
| mkanat | Anyhow, I do have to go. | 03:06 |
| lifeless | thumper: I hear he needs it to make Python3 nice. | 03:06 |
| spm | night max! | 03:06 |
| mkanat | Later! | 03:06 |
| mkanat | lifeless: HAHAHAHAHAHA. | 03:06 |
| lifeless | mkanat: ciao | 03:06 |
| thumper | mkanat: ttfn | 03:06 |
| mkanat | Later. :-) | 03:06 |
| thumper | lifeless: perhaps just fixing up strings and WSGI | 03:06 |
| thumper | lifeless: which I hear is a bit of poo | 03:06 |
| lifeless | its a bit contentious | 03:07 |
| lifeless | email too is in trouble | 03:07 |
| thumper | really? | 03:07 |
| thumper | damn | 03:07 |
| lifeless | thread today about a use case where its - I think - 18 times slower. Or something, I skimmed it. | 03:07 |
| thumper | I don't really follow py-dev | 03:07 |
| thumper | lifeless: about the last revision bug, I really think it is a bzr bug | 03:08 |
| thumper | lifeless: as it happened locally on the guys machine | 03:08 |
| thumper | lifeless: his local reconcile fixed it, but push --overwrite didn't update LP | 03:08 |
| poolie | spm: good question about governance | 04:10 |
| poolie | i'll be the canonical manager and mkanat is the technical lead | 04:10 |
| spm | ahh, excellent. good to know. ta. | 04:10 |
| lifeless | thumper: ok let me look for a bug | 04:10 |
| poolie | iow if you have bugs talk to mkanat, if he doesn't answer talk to me :) | 04:11 |
| spm | ha, kk, will do. | 04:11 |
| lifeless | thumper: ok, no open bugs I can see. Please change the product to bzr and gimme th enumber again. | 04:14 |
| lifeless | thumper: or just gimme the number and I'll do it all | 04:14 |
| thumper | lifeless: ok, let me look | 04:15 |
| thumper | https://bugs.launchpad.net/bugs/599492 | 04:15 |
| ubot5 | Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,Incomplete] | 04:15 |
| lifeless | thumper: there are two bugs here but neither in lp-code. | 04:20 |
| thumper | I thought so | 04:20 |
| lifeless | As for the branhc in question | 04:22 |
| lifeless | just reconcile it | 04:22 |
| lifeless | on lp, if you could | 04:22 |
| poolie | spiv bug 599670 is the one i alluded to on the phone | 04:40 |
| ubot5 | Launchpad bug 599670 in Bazaar "ValueError: absent factory in _stream_to_byte_stream during push (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/599670 | 04:40 |
| * spiv looks | 04:50 | |
| mtaylor | dude. this bzr-git dpush has been running for 3.5 hours | 04:54 |
| lifeless | mtaylor: dpush will be rebasing your local history | 04:55 |
| lifeless | mtaylor: you probably didn't want dpush. | 04:55 |
| lifeless | mtaylor: I like to think the D stands for 'do not want' | 04:55 |
| mtaylor | lifeless: well, it said that push wasn't supported | 04:56 |
| lifeless | mtaylor: >< | 04:56 |
| lifeless | mtaylor: I'm really serious, its going to be stripping all your local history down to zip, and rewriting it as a import from the git representation | 04:56 |
| mtaylor | lifeless: so I should cntrl-c this | 04:56 |
| lifeless | mtaylor: depends, do you value your life with other drizzle devs? | 04:57 |
| mtaylor | lifeless: :) | 04:57 |
| lifeless | I'd use bzr fast-export || git fast-import | 04:57 |
| lifeless | for maintaining the git mirror | 04:57 |
| mtaylor | lifeless: ah. | 04:57 |
| lifeless | dpush is pretty bad, because you can't simultaneously do it to hg and svn | 04:57 |
| lifeless | (the code quality is ok, its the concept that hurts) | 04:58 |
| mtaylor | lifeless: ok... I guess I should learn about fast-export | 04:58 |
| mtaylor | lifeless: sigh | 05:02 |
| mtaylor | fatal: Path libmysql/libmysql.c not in branch | 05:03 |
| mtaylor | lifeless: why do I get the feeling this is going to be fun | 05:03 |
| lifeless | mtaylor: FSVO painful ? | 05:08 |
| mtaylor | lifeless: yup | 05:08 |
| mtaylor | lifeless: I'm guessing this has to do with bzr tracking renames and git not so much doing that | 05:09 |
| lifeless | fast-export can include renames | 05:09 |
| lifeless | FTW | 05:09 |
| mtaylor | yup. so that doesn't work | 05:13 |
| lifeless | file bugs | 05:14 |
| lifeless | and tell your git fanboy devs to suck it up ? | 05:14 |
| mtaylor | lifeless: should I file bugs against git or bzr? | 05:14 |
| lifeless | mtaylor: which process blew up | 05:14 |
| mtaylor | lifeless: I'm guessing git, since it's the one that crashed | 05:14 |
| lifeless | check the stream did include the file creation and rename | 05:15 |
| lifeless | but yes, I suspect so | 05:15 |
| mtaylor | lifeless: M 644 inline libmysql/libmysql.c shows up in the stream | 05:18 |
| lifeless | looks sensible to me | 05:19 |
| lifeless | is the fail on a rename of that? | 05:19 |
| mtaylor | yes | 05:19 |
| lifeless | sounds like a boog to me | 05:19 |
| mtaylor | well, it would be great if there was a report-a-bug link on the git website. | 05:20 |
| mtaylor | lemme go ask in #git | 05:20 |
| lifeless | ... | 05:21 |
| lifeless | I need a hallway check | 05:22 |
| lifeless | what would you expect 'before:thread:foo' to resolve to ? | 05:22 |
| lifeless | [this is open to the floow] | 05:22 |
| poolie | i don't know | 05:23 |
| poolie | where would i find help about the meaning of 'before:'? | 05:23 |
| lifeless | bzr help revspec | 05:23 |
| mtaylor | lifeless: I'd expect it to resolve to the thread before foo? | 05:23 |
| lifeless | sorry | 05:23 |
| lifeless | revisionspec | 05:23 |
| poolie | i thought that was it but it doesn't work | 05:24 |
| mtaylor | lifeless: oh - hrm | 05:24 |
| lifeless | mtaylor: great, thats what I was hoping someone would say. | 05:24 |
| poolie | i would have thought the penultimate revision in foo | 05:24 |
| lifeless | and thats the other answer | 05:24 |
| poolie | however saying "the thread under foo" would be useful | 05:24 |
| mtaylor | lifeless: before == parent of the revision - thread: is tip of a loom | 05:25 |
| poolie | but i'd expect that to have a different name | 05:25 |
| lifeless | ok | 05:25 |
| lifeless | that was the tension being considered in a bug | 05:25 |
| lifeless | I'll go with below | 05:25 |
| mtaylor | lifeless: so - parent of the tip of the loom | 05:25 |
| lifeless | below:tread:foo | 05:25 |
| lifeless | so you can say | 05:25 |
| lifeless | before:below:thread:foo | 05:25 |
| spiv | lifeless: +1 for below: | 05:28 |
| * poolie is putting 2.1.2 into the ppa | 05:29 | |
| lifeless | \o/ | 05:30 |
| poolie | me too | 05:30 |
| poolie | :qa | 05:30 |
| lifeless | ZZ? | 05:31 |
| poolie | so what's the right way to bring in upstream changes from another branch, using builddeb? | 05:31 |
| poolie | just plain merge? | 05:31 |
| mtaylor | poolie: that's what I do | 05:32 |
| poolie | ah http://jameswestby.net/bzr/builddeb/user_manual/normal.html answers pretty well | 05:32 |
| poolie | merge-upstream with the tarball and the upstream branch | 05:32 |
| lifeless | yes | 05:34 |
| lifeless | poke me if it blows up - it may | 05:35 |
| lifeless | you may need an import-upstream first, depending on the packaging state. | 05:35 |
| lifeless | I've been improving this recently. | 05:35 |
| poolie | is there a special Command attribute for example help? | 05:39 |
| lifeless | vs the main prose? | 05:39 |
| poolie | yes, and no, there isn't | 05:39 |
| poolie | only a todo wishing for one :) | 05:39 |
| lifeless | Not currently, that might be nice; probably wants to be a list or dict or something. | 05:40 |
| poolie | spiv if you wanted you could post an rfc on how to clean up merge | 06:34 |
| poolie | or talk to vila perhaps | 06:34 |
| poolie | the strasbourgeouis teddybeaor | 06:34 |
| spm | having a brain blank moment here. bzr push to remote server. now have a dir with .bzr in it - how do I expand that to have the various versioned files in that same dir? I thought bzr up would do that, but "bzr: ERROR: No WorkingTree exists for..." ? | 06:41 |
| spiv | spm: 'bzr co .' in the server | 06:46 |
| spm | argh. thanks spiv. | 06:47 |
| spiv | Or perhaps 'bzr co SOME-OTHER-DIR' if you'd like to keep the history and the tree-on-disk separate :) | 06:47 |
| spm | heh, not really. someones +junk that I've pulled locally. pushed to where it needs to be run. so... carefactor :-) | 06:47 |
| spiv | Or perhaps just use the bzr-upload plugin in the first place. | 06:47 |
| spm | pish tish :-) | 06:48 |
| spiv | Having a working tree on a remote branch you 'bzr push' to is a bit of an attractive nuisance because the tree won't get updated automatically. | 06:48 |
| spiv | So it's often an sign that you want to be doing something a bit different. | 06:49 |
| spm | technically in this case? purty much. scp would have worked better. but bzr push is so *easy*.... ;-) | 06:49 |
| lifeless | spm: have you tried bzr upload ? | 07:17 |
| lifeless | spm: its the bomb | 07:17 |
| spm | I have not. or ... perhaps not in quite a while at any rate. | 07:17 |
| vila | hi all | 07:23 |
| poolie | hi vila | 07:23 |
| vila | lifeless: when a config file is saved for the first time, the config dir didn't exist so it needs to be created and the first point where this is required is when the lock is taken | 07:29 |
| lifeless | vila: we used to have code that did that already, but I don't see it being deleted. | 07:29 |
| lifeless | vila: if its not being deleted, we now have code duplication. | 07:29 |
| vila | I removed some duplications laready, I may have missed some though | 07:30 |
| vila | lifeless: | 07:32 |
| vila | grrr | 07:32 |
| vila | lifeless: "This seems like a case where two threads would be nice" as in loom threads ? | 07:32 |
| lifeless | yes | 07:32 |
| vila | I was very tempted :) | 07:32 |
| vila | oh, wrong _write_config_file citation, when the IniConfig class is used (no lock there) then the point where ensure_config_dir_exists is required is when we want to *create* the config file in this dir | 07:34 |
| vila | lifeless: this call has been added to *remove* code duplication in the various set_user_option() calls | 07:35 |
| lifeless | vila: I'm concerned that this will make bzr worse than it was about creating/checking dirs. | 07:36 |
| vila | lifeless: no worse than before since these calls were already there | 07:36 |
| lifeless | ok | 07:37 |
| poolie | which "this" makes it worse? | 07:41 |
| vila | ensure_config_dir_exists() | 07:41 |
| vila | lifeless: "Also see my ordering suggestion " the threads ? | 07:48 |
| vila | lifeless: "may help you not to need this at all", what is 'this' ? | 07:48 |
| lifeless | ordering of break lock checks | 07:54 |
| lifeless | this is your exception | 07:54 |
| lifeless | the subject of the paragraph | 07:54 |
| vila | I can't break a lock if there is no lock dir | 07:55 |
| lifeless | yes | 07:56 |
| lifeless | I get that; I feel like you haven't really thought about the suggestions I've made. I'm sure thats just me though. | 07:56 |
| lifeless | What can I do to help you understand my suggestions? | 07:56 |
| vila | lifeless: hmm, tweak my code and run the tests ? -s bt.test_config -s bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home -s bb.test_break_lock.TestConfigBreakLock are the ones I have in my history and should cover most of the edge cases I encountered | 08:03 |
| vila | a point easy to miss is that the config dir doesn't exist in *many* cases (especially during the tests) and we have a surprising number of cases where we read or set one variable | 08:04 |
| vila | I certainly need to better explain why and how I fixed the bug (I completely forgot to post the COVER file I had prepared...) | 08:06 |
| poolie | bzr 2.1.2 for dapper just sent to the ppa | 08:08 |
| poolie | i think | 08:08 |
| lifeless | poolie: Cool | 08:11 |
| poolie | i think | 08:11 |
| poolie | there's a few minutes lag | 08:11 |
| poolie | it's always a bit "did that happen or not?" | 08:11 |
| lifeless | vila: I trust that the code and tests work. I'm talking about the design and structure of the patch, not the red/green tests passing component. | 08:11 |
| lifeless | vila: meet me halfway :) | 08:11 |
| lifeless | vila: As far as I can tell you've made 'bzr break-lock (remote url) much slower. | 08:13 |
| vila | lifeless: As always, you know I'd love to do that, show me where ! :) I'm adding docstrings and a better cover letter, let's talk about the result or give me more precise indications | 08:13 |
| lifeless | vila: Tell me more about the bits of the review that confuse you | 08:13 |
| vila | much ? config files are always local (well the ones we're talking about here) | 08:13 |
| lifeless | vila: but your code *looks* for the config file first. | 08:14 |
| lifeless | vila: rather than looking for the bzrdir first. | 08:14 |
| lifeless | vila: unless I misunderstand it, which is possible. | 08:14 |
| vila | if I look at the bzrdir first I can't say if it succeeded or failed and whether I should try the config ones | 08:14 |
| lifeless | vila: then lets solve the UI problem differently. | 08:14 |
| vila | hehe, I punted on that after trying :) | 08:15 |
| lifeless | How about '--config' as an option to break-lock | 08:15 |
| lifeless | bzr break-lock --config | 08:15 |
| lifeless | which will DTRT on windows, doesn't need people to know where the config is. | 08:15 |
| vila | if that's the only remaining point of disagreement I can see why :) | 08:15 |
| lifeless | vila: I don't recall the full review offhand. | 08:16 |
| vila | it won't address the 'bzr break-lock' just do the right thing, thanks, I hate copy/pasting :) | 08:16 |
| lifeless | vila: but if you think that with that you can complete the review changes easily, why thats great. | 08:16 |
| vila | I *can* go further and change the way break_lock works for all cases but that's definitely more work that I thought was necessary | 08:17 |
| lifeless | vila: I don't think that 'bzr break-lock' needs to be magic: its a recovery tool used when things are interrupted by flaky networks or crashes. | 08:17 |
| lifeless | vila: I think a simple if config: config-path else: bzrdir-path will be easy, give a nice UI. | 08:17 |
| vila | well, it *is* magic today, *I* *never* specify location (nor had to) | 08:17 |
| lifeless | vila: most users have to most of the time they use it. | 08:18 |
| lifeless | IME | 08:18 |
| lifeless | I know this because we give out the wrong URL for lp branches today and they turn up here a lot :) | 08:18 |
| vila | good enough then, the bug is pretty hard to encounter I think so recovering from it will remain exceptional | 08:18 |
| vila | but that's exactly where using 'bzr break-lock' without arguments *does* the Right Thing ;) | 08:19 |
| lifeless | vila: I'm really not convinced by this | 08:20 |
| vila | and even when you give a location, there are a lot of magic (checkout, master branch, branch and repo from wt, you name it) | 08:20 |
| lifeless | vila: Here is what I see: | 08:20 |
| lifeless | - you have an ambiguous exception (type doesn't match what the caller cares about all that well) | 08:20 |
| vila | true | 08:21 |
| vila | it's tailored for the specific need | 08:21 |
| vila | that's not ideal | 08:21 |
| lifeless | - you add a VFS probe that isn't needed when the URL is a remote URL, and we want to *remove* those across the code base, VFS is deprecated. | 08:21 |
| lifeless | - Users are already following documentation to get to this command, so there is no particular need to have it be magic | 08:21 |
| lifeless | - Its possible for the magic to be very wrong. What if they have ~/.bazaar/ under bzr controll ? | 08:22 |
| vila | meh for last point, --config is ok for the previous ones | 08:22 |
| lifeless | vila: I don't know what you mean by that sentence. | 08:23 |
| vila | what's the problem with having .bazaar versioned ? | 08:23 |
| lifeless | bzr init ~/.bazaar | 08:23 |
| lifeless | bzr commit ~/.bazaar -m "This cannot be break-locked" | 08:23 |
| vila | lifeless: I think --config being required to break config locks is a good solution that addresses the points (minus the last one I don't understand) | 08:23 |
| lifeless | vila: ok, thank you. I thought you were still arguing for magic. | 08:24 |
| vila | no no | 08:24 |
| vila | I *tried* to respect the magic, if I don't have to... I won't :) | 08:24 |
| vila | but I still don't get why you can't break lock in ~/.bazaar if it's versioned ? Are you arguing that people will version control the lock files ? | 08:25 |
| vila | huh ? Did anybody knows what the 'show' parameter to cmd_break_lock.run() has been supposed to mean ? It's not used... | 08:28 |
| vila | show == dry-run ? | 08:29 |
| lifeless | vila: it shows whether there is a held lock, or used to. | 08:32 |
| lifeless | vila: say ~/.bazaar is versioned | 08:32 |
| lifeless | vila: and magic is present | 08:32 |
| lifeless | vila: now, say that the machine crashes while the working tree's lock is held. | 08:32 |
| vila | it won't break the wt lock | 08:33 |
| lifeless | vila: and to make it really obvious, say that the config dir lock is also held - e.g. bzr-svn had kicked in and was updating stuff. | 08:33 |
| lifeless | vila: right. | 08:33 |
| vila | lifeless: nice catch | 08:33 |
| lifeless | vila: and there wouldn't be any way to make it break it either. | 08:33 |
| * lifeless takes a bow | 08:33 | |
| lifeless | when designing magic | 08:33 |
| lifeless | think *really really* paranoid. | 08:33 |
| vila | there is a way: run break-lock twoce, hard to discover though | 08:33 |
| vila | twice | 08:33 |
| lifeless | I'm not sure that would work, would it ? | 08:35 |
| lifeless | because it would find the config lock that isn't held, and stop | 08:35 |
| vila | eeerk | 08:36 |
| vila | err, no, there are tests covering that | 08:36 |
| vila | damn, the tests are wrong | 08:36 |
| lifeless | vila: anyway, --config avoids this, and is simpler to talk about I think. | 08:37 |
| vila | +8000 | 08:37 |
| lifeless | so lets do that, and you can buy me a beer for finding your bug, at the epic :) | 08:37 |
| vila | hehe | 08:37 |
| poolie | Value "bzr+ssh://bazaar.launchpad.net/~bzr/bzr/packaging-dapper/" is masked by "lp:~mbp/bzr/packaging-dapper" from locations.conf | 08:46 |
| poolie | were we going to change that? | 08:46 |
| lifeless | yes | 08:46 |
| lifeless | I hate that. | 08:46 |
| lifeless | I was going to do a spike, I ran out of tuits. | 08:46 |
| lifeless | bbiab, food n stuff time. | 08:57 |
| poolie | GaryvdM: hi there | 09:03 |
| poolie | GaryvdM: we do have a vm with the developer tools | 09:03 |
| poolie | it's on ec2 and currently shut down | 09:03 |
| poolie | i can start it back up for you | 09:03 |
| poolie | vila, did we once have a copy of configobj and then later remove it? | 09:16 |
| poolie | it seems like that breaks dapper support | 09:16 |
| vila | poolie: this doesn't ring a bell, we updated it several times but I don't remember *replacing* it (aka changing the file-id) | 09:22 |
| vila | IMBW | 09:22 |
| poolie | i think it was deleted in the packaging branch | 09:22 |
| poolie | incorrectly, if you want the branch to work on dapper | 09:22 |
| GaryvdM | Hi poolie. | 09:26 |
| GaryvdM | I can't do it now. I can do it this evening. | 09:26 |
| jelmer | poolie: I removed it in the Debian packaging | 09:28 |
| GaryvdM | And I merge the debian branch into all the packing-* branches. Opps | 09:29 |
| GaryvdM | *merged | 09:29 |
| CaMason | I've done a `bzr pull --overwrite` and there are text conflicts. How can I ask bazaar to just overwrite those conflicts with the versions in the repo? | 09:34 |
| GaryvdM | poolie: I'll ask jam for access this evening. | 09:34 |
| lathiat | CaMason: bzr revert <file> | 09:38 |
| vila | CaMason: resolve --take-other should address that but if you encounter conflicts here it means you have uncommitted changes in which case you ought to check that you really want to get rid of them, so 'bzr revert' may be better suited | 09:39 |
| CaMason | I effectively want to switch to a different branch, losing all changes / commits / working tree changes | 09:39 |
| vila | bzr revert then | 09:39 |
| spiv | I suppose there could be an argument for adding a 'bzr switch --revert' flag for that use-case. | 09:43 |
| lifeless | ? | 09:43 |
| spiv | lifeless: <CaMason> I effectively want to switch to a different branch, losing all changes / commits / working tree changes | 09:44 |
| lifeless | related to 'I want to shelve them all' | 09:44 |
| spiv | lifeless: (they did a pull --overwrite, and got conflicts.) | 09:44 |
| lifeless | I think I'd like it if we added a shelve, and that gets close while covering more use cases | 09:44 |
| spiv | Perhaps, this was just a quick idea before I disappear for dinner etc :) | 09:45 |
| * spiv -> dinner etc | 09:45 | |
| lifeless | sure | 09:45 |
| lifeless | same | 09:45 |
| lifeless | well, have eaten, I mean it was also a quick idea | 09:46 |
| CaMason | back | 09:54 |
| CaMason | ok, so it's just a case of bzr revert, and deleting some of the *.moved files? | 09:54 |
| CaMason | I know this is a broken workflow... it's a messy environment I've been having to work with | 09:56 |
| lifeless | bzr revert | 09:56 |
| lifeless | bzr resolve --take-other | 09:56 |
| lifeless | or so | 09:56 |
| CaMason | I do believe `bzr resolve --take-other` said that the argument didn't exist. Sec.. | 09:56 |
| CaMason | "ERROR: no such option: --take-other" | 09:57 |
| lifeless | ah thats in a newer bzr | 09:57 |
| lifeless | so: | 09:57 |
| lifeless | bzr resolve | 09:57 |
| lifeless | remove any .moved files | 09:57 |
| lifeless | sorry | 09:57 |
| lifeless | revert | 09:57 |
| lifeless | then remove .moved files | 09:57 |
| lifeless | then resolve --all | 09:57 |
| CaMason | ok thank yoyu | 10:00 |
| === oubiwann-away is now known as oubiwann | ||
| parthm | i am trying to use assertRaises in a really simple test case. but it seems the the exception is not being handled by assertRaises. Am i doing something wrong? http://pastebin.com/aATNseAC | 14:19 |
| lifeless | I haven't looked at the pastebin | 14:19 |
| lifeless | but the usual gotcha | 14:19 |
| lifeless | is that you are calling your function | 14:20 |
| lifeless | which means that assertRaises hasn't actually started running yet | 14:20 |
| parthm | no. i checked that "self.assertRaises(errors.InvalidPattern, p.match, 'foo')" | 14:20 |
| lifeless | you have to use assertRaises like addCleanup - you give it something to call. | 14:20 |
| lifeless | ok | 14:20 |
| lifeless | hmm, I will look - sec | 14:20 |
| lifeless | see how it is in __getattr__ | 14:21 |
| lifeless | its the lazy thing tripping you up | 14:21 |
| lifeless | define a lambda | 14:21 |
| lifeless | assertRaises(InvalidPattern, lambda:p.match('foo')) | 14:21 |
| lifeless | you'll want a comment noting why this is needed. | 14:21 |
| parthm | yup. that worked. thanks :) ... i will add the comment. | 14:22 |
| === nlisgo_ is now known as nlisgo | ||
| mkanat | thumper: So, are you managing loggerhead development now? | 14:50 |
| mkanat | jam: ping | 14:57 |
| jam | morning mkanat, haven't seen you around this early before :) | 14:59 |
| mkanat | jam: Yeah, I'm up early. :-) | 14:59 |
| jam | GaryvdM: are you around? | 14:59 |
| jam | mkanat: what TZ are you in? | 14:59 |
| mkanat | jam: America/Los_Angeles | 14:59 |
| mkanat | jam: Do you have a few moments to help me figure out what's up with meliae on my system? | 15:00 |
| GaryvdM | Hi jam | 15:01 |
| jam | yeah, it will be maybe 10 min, but then I'll be able to work with both of you :) | 15:01 |
| GaryvdM | jam: I'm done at work to :-) | 15:01 |
| mkanat | jam: Okay. :-) | 15:01 |
| GaryvdM | Cool | 15:02 |
| jam | hi mkanat | 15:34 |
| mkanat | Hey jam. Good timing. :-) | 15:34 |
| jam | mkanat: so, first off, grab my meliae branch at lp:///~jameinel/meliae/skip_static_type_traverse_bug_586122 | 15:35 |
| jam | which I think you have | 15:35 |
| jam | but I wanted to make sure | 15:35 |
| mkanat | jam: Yeah, I do have it. | 15:35 |
| mkanat | Tree is up to date at revision 143 of branch bzr+ssh://bazaar.launchpad.net/~jameinel/meliae/skip_static_type_traverse_bug_586122 | 15:36 |
| jam | k, run python setup.py build_ext -i && python run_tests.py | 15:36 |
| jam | and see if it builds and then runs the tests successfully | 15:36 |
| mkanat | Ah, I get a bunch of test failures. | 15:37 |
| mkanat | I'll pastebin them. | 15:37 |
| mkanat | Let me start with a fresh checkout first, though. | 15:38 |
| mkanat | jam: http://pastie.org/1025109 | 15:42 |
| jam | so to start with the 'get_memory' not implemented is something I should probably implement, but shouldn't be an issue here. | 15:44 |
| jam | The bigger one is the 'intset' failures | 15:44 |
| jam | self.assertEqual(10000, len(iset)) AssertionError: 10000 != 259 | 15:44 |
| jam | says that I added 10k items, but now we are only seeing 259 in the set | 15:45 |
| mkanat | jam: If you need it, I can get you a shell on my machine. | 15:45 |
| jam | mkanat: I might, this is probably specific to 64-bit or something | 15:46 |
| mkanat | That seems likely. Or having something to do with my compiler flags. | 15:47 |
| mkanat | (Which are just the default compiler flags that Python is built with on Fedora, FWIW.) | 15:47 |
| mkanat | jam: If you need it, just email me your ssh key and whatever username you want. | 15:47 |
| jam | well it is IDSet that is failing, which is especially suspect since you're on 64-bit | 15:47 |
| * mkanat nods. | 15:48 | |
| jam | mkanat: sent | 15:52 |
| GaryvdM | jam: I'm reading docs atm. | 16:03 |
| jam | mkanat: any ideas why "long myint; myint = 0x08; myint <<= 60, wouldn't end up with 0x8000000000000000" ? would it be a signed issue? | 16:34 |
| mkanat | jam: I really haven't done much C development in years, so it's hard to say. | 16:35 |
| jam | mkanat: it was my formatting. | 16:37 |
| mkanat | jam: Ah, okay. | 16:37 |
| jam | I was printing using %x but needed %lx | 16:37 |
| mkanat | Ah, okay. That's surprising, I'd expect that to Just Work on 64-bit architectures. | 16:38 |
| maxb | %x is specified as taking an int quantity | 16:43 |
| maxb | common 64-bit architectures are LP64, i.e. ints are still 32 bits | 16:44 |
| jam | yeha | 16:48 |
| jam | yeah | 16:48 |
| mkanat | Yeah. Further proof that C is not really a high-level language. | 16:53 |
| * mkanat shrugs. | 16:53 | |
| jam | mkanat: so no luck tracking it down yet, but still working on it, had some dead ends because of stuff like that | 17:08 |
| mkanat | jam: Okay. | 17:08 |
| === deryck is now known as deryck[lunch] | ||
| === Adys_ is now known as Adys | ||
| Phoenixz | Question.. Someone really borked up a merge, committed those changes, made a push to a centralized repo, we did a pull from there.. Now we have quite a mess.. Can I somehow undo this commit he made and have it undone in all repositories? | 17:47 |
| Phoenixz | I tried uncommit in my local repo, but when I do a pull from the central repo, I get that very same revision back again.. | 17:47 |
| GaryvdM | Phoenixz: You can do either: | 17:48 |
| GaryvdM | bzr push --overwrite, but then everyone else needs to do bzr pull --overwrite | 17:49 |
| GaryvdM | or | 17:49 |
| GaryvdM | bzr revert -r -2 && bzr commit "Revert stuff up..." | 17:49 |
| GaryvdM | and push | 17:49 |
| Phoenixz | GaryvdM: ah, a brz revert -r will revert a specific commit, and then store those changes so with a pull / push everyone will recieve that revert? | 17:50 |
| GaryvdM | The second option will show in the history. | 17:50 |
| GaryvdM | Phoenixz: Yes , after you do a commit | 17:50 |
| Phoenixz | GaryvdM: excelent. Thanks! | 17:51 |
| GaryvdM | Phoenixz: Hmm - maybe that is not the best option | 17:52 |
| Phoenixz | GaryvdM: what would be better? | 17:52 |
| Phoenixz | GaryvdM: Im also considdering the push --overwrite.. that way, there is no garbage in the history.. | 17:53 |
| GaryvdM | Phoenixz: because then bzr will think that the branch he was trying to merge, is succussfully merged, which it is not. | 17:53 |
| GaryvdM | Phoenixz: If you do uncommit & push --overwrite then it will not think that it is merged | 17:54 |
| Phoenixz | ok | 17:54 |
| GaryvdM | Phoenixz: just make sure to tell everyone that is gonig to pull about this. | 17:54 |
| Phoenixz | GaryvdM: that won't be a problem, I'll go for the uncommit and push --overwrite | 17:58 |
| GaryvdM | Ok | 17:58 |
| === deryck[lunch] is now known as deryck | ||
| mkanat | So, the best migrator for CVS right now is cscvs, yes? | 18:39 |
| mkanat | I guess I should be asking jml or mwhudson, per the "top contributors"? | 18:40 |
| jam | I would actually say cvs2svn (which has cvs2bzr in the suite) | 19:07 |
| jam | mkanat: ^^ | 19:08 |
| jam | It is what I've been using | 19:08 |
| jam | cscvs is probably the most robust in some senses, but requires much more effort to get working | 19:08 |
| mkanat | Okay. Yeah, we just need to migrate a single branch, once. | 19:08 |
| chaosaddict | when importing into bazaar, has anyone else run into problems with latin-1 encoded filenames or files? | 19:13 |
| SpamapS | so I want to use bzr-builder with a tarball from an upstream, do I have to first import the tarball into a bzr branch, then run my recipe? | 19:17 |
| james_w | hi SpamapS | 19:26 |
| james_w | SpamapS: you would, yes, but bzr-builder isn't going to be particularly interesting with a single upstream tarball. What is it you wish to accomplish? | 19:26 |
| SpamapS | james_w: just wanted to maintain the packaging in my own branch without all the upstream source | 19:29 |
| james_w | SpamapS: well, you're wrong, but even so, that is supported in bzr-builddeb, see "merge mode" :-) | 19:30 |
| SpamapS | wrong? | 19:30 |
| SpamapS | or misguided? | 19:30 |
| james_w | http://jameswestby.net/bzr/builddeb/user_manual/merge.html | 19:31 |
| SpamapS | I don't think I actually suggested any sort of solution, just a desire.. so not sure how I can be wrong. | 19:31 |
| james_w | SpamapS: yeah, sorry, misguided | 19:31 |
| SpamapS | Well enlighten me | 19:32 |
| james_w | SpamapS: I was only trying to be funny though, it's perfectly supported, just not my choice | 19:32 |
| SpamapS | I'm totally new and have no preconceptions about large scale package maintenance, so now is the time to set me in the right direction. | 19:32 |
| james_w | I just think it is more useful to have all the code to hand, and to be able to track their co-evolution, which helps as things start to get trickier. | 19:33 |
| SpamapS | yeah I'm seeing that actually | 19:34 |
| SpamapS | its actually quite annoying having the packaging in its own branch | 19:34 |
| james_w | I agree that it's not so nice having the extra data carried around that is in some ways redundant, and for simple things having a more focused view of just the packaging can be useful | 19:34 |
| SpamapS | but I got the idea that people were doing that on a regular basis | 19:34 |
| james_w | yeah, if you are upstream then you can ship the packaging in your branch, but even then people will still tend to want to modify it, as packaging that works across all releases of all (.deb-based) distributions is going to be rare. | 19:35 |
| SpamapS | vendors have been doing that for .spec files for a long time | 19:36 |
| mtaylor | SpamapS: I was just telling you yesterday about keeping the branch and packaging in the same branch... | 19:46 |
| mtaylor | SpamapS: you may find http://rbtcollins.wordpress.com/2009/12/19/debianising-with-bzr-builddeb/ interesting | 19:48 |
| mtaylor | SpamapS: that's the process I use | 19:48 |
| SpamapS | mtaylor: right I still hadn't chewed through that process yet | 19:49 |
| SpamapS | no better time than now I guess | 19:49 |
| mtaylor | SpamapS: I promise - once you do, you'll like it | 19:49 |
| mneptok | mtaylor sounds like a drug dealer. | 19:51 |
| mtaylor | mneptok: I _am_ a drug dealer | 19:51 |
| mtaylor | mneptok: but sssssh | 19:51 |
| mneptok | "Try it ince, you'll love it. Your first taste is free." | 19:51 |
| mneptok | *once | 19:51 |
| SpamapS | mtaylor: so I never bzr add debian, right? | 19:52 |
| mtaylor | SpamapS: nope. doing the import-dsc step will do that for you | 19:52 |
| mtaylor | SpamapS: also, be sure to look at the bzr mark-uploaded command once you upload packages to the repo | 19:53 |
| mtaylor | SpamapS: that way you can get the fine folks over in #launchpad to make the UDD listings for your package actually use your packaging branch | 19:53 |
| SpamapS | weird | 19:54 |
| SpamapS | so I bzr added debian so I could use bzr-buildpackage .. and then it won't let me bzr revert debian | 19:54 |
| SpamapS | oh wait no, it just won't delete it | 19:55 |
| SpamapS | silly build artifacts | 19:55 |
| mtaylor | SpamapS: oh - also, this is going to be weird with gearman-interface since the upstream tarball doesn't match the upstream bzr... | 19:55 |
| mtaylor | SpamapS: I should perhaps come up with a better plan for how gearman-interface source works... | 19:56 |
| ssylvan | Does bzr have a way to create a local branch in the same working tree (to avoid having to re-configure apps that make assumptions about paths etc.)? | 19:57 |
| SpamapS | mtaylor: I think it works ok | 19:58 |
| mtaylor | ssylvan: yes, but it's not particularly easy or exposed in the UI directly quite yet ... co-located branches is the thing you're wanting here | 19:58 |
| SpamapS | mtaylor: I'm settled on producing source packages for each language rather than trying to let the main one build them all | 19:59 |
| ssylvan | mtaylor: thanks | 19:59 |
| SpamapS | mtaylor: the complexity of the latter overrides its pure-correctness | 19:59 |
| mtaylor | ssylvan: although I'd love to be an asshole for a moment and suggest that any app that makes assumptions about paths is broken in some way ;) | 19:59 |
| mtaylor | SpamapS: indeed... I'm just saying that robert's process I pasted in above assumes that the tarball is some reflection of the branch | 19:59 |
| mtaylor | ssylvan: the write up on the work to implement it is at http://doc.bazaar.canonical.com/developers/colocated-branches.html | 20:00 |
| ssylvan | mtaylor: Well every IDE I've used will make assumptions about where to find various libraries, headers etc. It'll be based on environment variables, sure, but I'd rather not have to update all of them just to work on some separate feature in its own branch real quick... | 20:01 |
| mtaylor | ssylvan: indeed. | 20:02 |
| mtaylor | ssylvan: it's a flaw/bug in every IDE - but it is the case :) | 20:02 |
| mtaylor | ssylvan: ah - this might be helpful at the moment: | 20:02 |
| mtaylor | http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html | 20:02 |
| mtaylor | ssylvan: I have not used it myself, so I can't vouch for it | 20:02 |
| SpamapS | mtaylor: ah .. true.. but I think it will be "ok" in this case, because I imported your pypi tarball | 20:03 |
| SpamapS | ugh and now i just realized I pushed to ~me/gearman-interface instead of ~me/+junk .. | 20:03 |
| mtaylor | SpamapS: right - but that's what I was saying, robert's workflow starts with a branch of upstream and imports the tarball on top of it (which means you can pull in changes from upstream really easily) | 20:04 |
| mtaylor | SpamapS: but, of course, the way you are doing it will totally work | 20:05 |
| SpamapS | mtaylor: yeah ... and I'm done maintaining packaging separate from upstream. all the debian tools want to work on ./debian not ./ | 20:05 |
| SpamapS | yay! "Start in 4 hours" ... yesterday it was 23 | 20:06 |
| ssylvan | mtaylor: well, not sure it's a flaw. It needs to know where to find stuff somehow, and not everything can be kept in the same repository, so relative paths are out. | 20:07 |
| andresj | Hello, I want to use the push-and-update plugin on a project, but I don't want it to interfere with other projects. Is there a way I can install it somewhere else from ~/.bazaar, or to enable it on a per-repository basis? | 20:07 |
| mtaylor | ssylvan: I strongly dislike that IDEs often skip the configure step in favor of 700 configuratoin dialogs, which leads to exactly your problem. if IDEs had better integration with existing build system instead of inventing their own, it wouldn't be nearly as much of an issue | 20:10 |
| ssylvan | The build system still needs to know where to find each component, and if working on a feature for one of those components changes the path then I can't quickly switch without having to somehow reconfigure the build settings which is annoying. | 20:11 |
| mtaylor | ssylvan: I'm a bit of a snob for build systems that know how to discover dependencies and do not require a dev to spend time setting up a tree to be sueful | 20:11 |
| mtaylor | ssylvan: right. but that's why I'm saying it's a flaw in the IDE design. I do not have this problem in any of the build systems for any of the projects I work on... it is a totally solvable problem, it's just that the IDE designers choose to not care about it enough to fix it | 20:12 |
| mtaylor | ssylvan: it's certainly not the fault of the users of the IDE | 20:13 |
| mtaylor | and with that off-topic rant (apologies) ... I will now go get lunch. :) | 20:14 |
| ssylvan | ssylvan: I don't think it's a flaw at all. When the compiler needs to find a header or the linker needs to find a lib it NEEDS to know where those are located, regardless of IDE. So the build system will have a depedecy on a path, or an environment variable. If I do a quick branch for a small feature, changing the path, I don't want to have to modify the build configuration... I *could* but it's just unecessary hassle which just leads to me not | 20:15 |
| ssylvan | that was for mtaylor, not myself obviously | 20:16 |
| ssylvan | Anyway, the solution is to be able to easily create quick local branches that are located on the same path and you can switch between them quickly. That way any config files relying on that path will not need to be updated. | 20:17 |
| mtaylor | ssylvan: totally... that is certain a solution ... but another solution is just running ./configure in the new branch - I think your solution of co-located branches is an important one to have... | 20:18 |
| mtaylor | ssylvan: I just think that it is _also_ a deficiency in many IDEs that I cannot choose to take the other solution | 20:18 |
| ssylvan | mtaylor: You'd still need to modify the configure script to tell it that you want branch B not A. Also, the problem is that ./configure may not be quite as fast as you'd hope... We have dozens and dozens of complicated dependencies and external applications and even though it really is automatic to switch my path around (I just need to change one file) it takes a long time to go through and verify all of that.. | 20:20 |
| GaryvdM | jelmer: I'm tryng to build windows installers. The build script is trying to download http://subversion.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip , which no longer exists. I am struggling to fine alternatives. Could you give me any pointers on where to look? | 20:46 |
| GaryvdM | *find | 20:47 |
| jam | GaryvdM: well, after some chasing I did find: http://www.collab.net/downloads/subversion/ | 21:51 |
| jam | but those look like runtime and not developer stuff | 21:51 |
| jam | GaryvdM: and I just followed your link, and it gave me a download | 21:52 |
| jam | looking here: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11129&expandFolder=11129&folderID=0 | 21:54 |
| jam | 1.6.6 is the latest uplead | 21:54 |
| jam | upload | 21:54 |
| jam | although subversion.apache.org says there is a 1.6.12 | 21:54 |
| GaryvdM | Thats odd I could not access it just now... | 22:01 |
| GaryvdM | jam: they were maybe doing maintenance.. | 22:02 |
| GaryvdM | jam: we may need to look a building the latest in the future. | 22:03 |
| jam | GaryvdM: I'd *really* like to avoid setting up a subversion build stack if we can avoid it | 22:10 |
| jam | somehow saying: "if you want to build the windows installers, first set up a subversion development environment" really doesn't sound right | 22:11 |
| GaryvdM | Yes | 22:11 |
| GaryvdM | jam: http://pastebin.org/368612 - It seem that the server requires cookies. | 22:18 |
| jam | I thought we had something a while back about passing the username + password (for anonymous access) in the url | 22:19 |
| GaryvdM | If I clear my cookies, and got to http://www.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip, I get redirected to http://subversion.tigris.org/servlets/ProjectDocumentDownload?documentID=46880, and then back to ttp://www.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip, which does not happen if I don't clear my cookies. | 22:20 |
| jam | For example: http://guest:password@tortoisesvn.tigris.org/svn/... | 22:20 |
| jam | hmmm | 22:21 |
| jam | I really don't know hexagonit well. Perhaps sidnei (da silva) will show up sometime and we can ask him | 22:21 |
| awilkins | jam: Shouldn't you just be able to use the older windows dev pack for builds and bundle the latest libs? The API won't have changed? | 22:22 |
| jam | he was the one who did a lot of the work | 22:22 |
| jam | awilkins: well, who has the latest libs ? Extract it from the installers? | 22:22 |
| jam | (this is supposed to be a mostly-automatic build process) | 22:22 |
| awilkins | Humph | 22:22 |
| jam | awilkins: http://subversion.apache.org/packages.html#windows talks about full builds and links to http://www.collab.net/downloads/subversion/ | 22:23 |
| awilkins | They had bundles which were just archives the last I looked but reading up you may be having trouble auto-downloading them | 22:23 |
| jam | that has source code and executables | 22:23 |
| jam | but I don't see any developer builds | 22:23 |
| jam | and now requires a login to proceed | 22:24 |
| awilkins | Darn, used to know where they were when they were on tigris.org | 22:24 |
| GaryvdM | jam: Right now I don't have a good answer, so I think I should carry on without bzr-svn, and come back to it later | 22:24 |
| jam | awilkins: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11129&expandFolder=11129&folderID=11129 | 22:24 |
| jam | which is where we are getting them from | 22:24 |
| jam | which only has 1.6.6 | 22:24 |
| jam | and is causing problems for us to automate the download | 22:24 |
| jam | seems to work fine in a browser | 22:24 |
| jam | but not in hexagonit (buildout) | 22:24 |
| jam | GaryvdM: sure, though we would be a bit hard pressed to have an official build without them | 22:25 |
| awilkins | jam: wget seems to grab them OK | 22:25 |
| jam | I think one option is to download them manually into build-win32/downloads | 22:25 |
| lifeless | cache it on lp? | 22:26 |
| * jelmer waves | 22:26 | |
| jam | awilkins: I think wget saves cookies, and python's httplib does not | 22:26 |
| GaryvdM | jam: sure | 22:26 |
| GaryvdM | Hi lifeless, jelmer | 22:26 |
| jelmer | GaryvdM: you're having trouble getting a particular feature of bzr-svn to work? | 22:26 |
| GaryvdM | jelmer: I'm trying to build windows installers | 22:27 |
| jelmer | GaryvdM, ahh | 22:27 |
| jam | lifeless: lp:python-six | 22:29 |
| lifeless | yah | 22:29 |
| lifeless | thanks for that ref | 22:29 |
| jam | jelmer: I'd like to do a new release of meliae, I don't quite remember what the process was last time | 22:30 |
| lifeless | I think we rather drained the topic dry for now at least though | 22:30 |
| jam | sure | 22:30 |
| jam | I sent it mostly for you | 22:30 |
| jam | since you were poking at py3 | 22:30 |
| lifeless | thank you :) | 22:31 |
| jelmer | jam: When you've got a tarball out let me know and I'll upload to Debian/Ubuntu. | 22:31 |
| GaryvdM | jam: I'm getting this error: http://pastebin.org/368639 | 22:40 |
| GaryvdM | jam: I think we just need to install sphinx-builld | 22:40 |
| GaryvdM | easy_install -U Sphinx | 22:40 |
| jam | GaryvdM: 1.0b2 installed | 22:43 |
| GaryvdM | jam: thanks | 22:43 |
| jelmer | jml: hi | 22:57 |
| mkanat | I'm guessing that bzr-fastimport trunk is stable enough for use? | 23:02 |
| jelmer | mkanat, yeah, I think so | 23:04 |
| mkanat | Okay. | 23:04 |
| jam | jelmer: https://edge.launchpad.net/meliae/0.2/0.2.1rc1 | 23:14 |
| jam | 0.2.1rc1 tarball has been uploaded | 23:14 |
| jelmer | \o/ | 23:15 |
| jml | jelmer, hello | 23:23 |
| jelmer | jml: You had a nice introduction to getting started with the launchpad API somewhere, is available somewhere publicly? | 23:26 |
| jml | jelmer, yeah, it's on my blog | 23:30 |
| jml | jelmer, http://code.mumak.net/2010/03/launchpadlib-gotchas.html is the final part and links back to the first two parts | 23:31 |
| jelmer | jml: Thanks! | 23:33 |
| poolie | hi all | 23:35 |
| poolie | hi jelmer, garyvdm | 23:35 |
| poolie | mkanat, jam | 23:35 |
| mkanat | Hey poolie. :-) | 23:35 |
| jelmer | g'morning poolie | 23:35 |
| GaryvdM | Hi poolie | 23:35 |
| poolie | happy new australian financial year :) | 23:35 |
| GaryvdM | jam: I'm going home now. Should I shutdown? | 23:46 |
| poolie | GaryvdM: oh did john start up the ec2 vm for you? | 23:46 |
| GaryvdM | poolie: Yes - and I've been working on building the installer | 23:47 |
| GaryvdM | Using igc's scripts | 23:47 |
| GaryvdM | jam: I've keep notes an pushed changes to lp, so it's ok if d is trashed. | 23:50 |
| poolie | way to go | 23:50 |
| GaryvdM | Night all | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!