| seiflotfy | hey gus | 01:03 |
|---|---|---|
| seiflotfy | guys | 01:03 |
| seiflotfy | :) | 01:03 |
| seiflotfy | I have been thinking of a way to maybe enhance launchpad experience | 01:04 |
| seiflotfy | Using Zeitgeist as a backend in Launchpad will allow users to have a personal timeline of their activities regarding themselves or specific project. This will allow easier trackeing of when things were done commited and view a chronicle of the project in terms of all (blueprints/bugs/etc..) mashed together. | 01:04 |
| seiflotfy | Basically what we can provide is a timeline per project/team/individual | 01:04 |
| seiflotfy | I think I can get it done | 01:07 |
| seiflotfy | imagine a persoal journal for each developer | 01:07 |
| seiflotfy | poolie, ? | 01:08 |
| seiflotfy | sorry | 01:09 |
| seiflotfy | back | 01:10 |
| seiflotfy | poolie, did i miss something or is it still silent in here | 01:10 |
| poolie | sorry, phone | 01:12 |
| poolie | i think it would be a superb idea | 01:12 |
| poolie | the big question istm is how, technically, we will get activity data from lp into zeitgeist | 01:12 |
| seiflotfy | well it has to be hooked into launchpad | 01:13 |
| seiflotfy | :) | 01:13 |
| seiflotfy | basically if anything happens on launchpad it has to be forwarded to the zeitgeist running on the server | 01:13 |
| seiflotfy | so its basically hooking up into launchpad and listneing ot activities | 01:16 |
| poolie | right, that's the key thing | 01:17 |
| poolie | actually, i should really have sent you to #launchpad-dev, not here :) | 01:18 |
| poolie | do you mind? | 01:18 |
| seiflotfy | nope | 01:19 |
| seiflotfy | not at all | 01:19 |
| _habnabit | So I'm getting an odd error when checking out a bzr branch, but only on windows. | 01:26 |
| _habnabit | bzr 2.2.1, I get an error about 'checkout/limbo/new-3' already existing every time. | 01:27 |
| _habnabit | Across three different machines. | 01:27 |
| _habnabit | Pulling over ssh from a UNIX machine, if that matters. | 01:27 |
| _habnabit | I can pastebin the exact error. | 01:27 |
| === seiflotfy is now known as seiflotfy|sleepi | ||
| === Ursinha-bbl is now known as Ursinha-afk | ||
| poolie | _habnabit: hm, please search for an existing bug, or file a new one? | 06:59 |
| _habnabit | poolie, whoops, I forgot to mention I resolved it. | 06:59 |
| poolie | oh, what was it? | 06:59 |
| _habnabit | Windows was choking on the filename '. ' | 06:59 |
| _habnabit | svn did it too, back when we used svn. That's how I recognized the problem! | 07:00 |
| vila | hi all | 07:23 |
| peitschie | evenin vila :) | 07:25 |
| vila | peitschie: ;) | 07:25 |
| poolie | hi vila; now i have to run | 07:29 |
| poolie | vila, are you on the udd list? you should be | 07:29 |
| vila | poolie: hello, bye, any news about pqm ? | 07:30 |
| poolie | what about it? | 07:30 |
| vila | I think so | 07:30 |
| vila | I just upgraded and had to reboot, will look at my mail backlog now, any topic in particular ? | 07:30 |
| poolie | you'll see it :) i just sent a bit mail | 07:30 |
| poolie | is something wrong with pqm? | 07:30 |
| vila | the upgrade to testtools-0.9.6 went wrong leading to no subunit | 07:31 |
| vila | i.e. no more landing | 07:31 |
| vila | jam was trying to follow yesterday when I EODed, I was just wondering if you heard about it | 07:32 |
| poolie | i hadn't even heard that | 07:33 |
| poolie | tell the list? chase a losa | 07:33 |
| poolie | i haven't tried to land anything today | 07:33 |
| poolie | more's the pity | 07:33 |
| vila | oh, it's under losa's control, re-building the needed bits was taking a long time and mthaddon also EODed before it was done, so I don't know where it's at but I will ;) | 07:34 |
| poolie | k, please send a mail letting us know one way or the other | 07:34 |
| vila | k | 07:34 |
| vila | poolie: so, yes, I'm subscribed to udd, got your 'udd at uds-n' yesterday | 07:36 |
| vila | poolie: and I'm a big fan of the UDD stakeholders meeting minutes for a while ;) | 07:36 |
| GaryvdM | Morning all. | 08:41 |
| GaryvdM | Bla - I missed poolie. | 08:41 |
| * jelmer waves to Gary | 08:46 | |
| GaryvdM | Hi jelmer | 08:53 |
| vila | GaryvdM: hey ! | 10:37 |
| * jelmer hugs GaryvdM | 10:42 | |
| GaryvdM | :-) | 10:42 |
| * GaryvdM is not sure why | 10:42 | |
| jelmer | GaryvdM: I noticed your last MP when I was reading my email. | 10:45 |
| GaryvdM | Ah :-) | 10:45 |
| vila | +1 | 10:47 |
| vila | GaryvdM: I saw your loggerhead poc the day *after* you mentioned it and was never able to congratulate. Now is the time: very well done ;) | 10:48 |
| GaryvdM | vila: thanks | 10:50 |
| vila | maxb: ping | 14:02 |
| vila | maxb: we are upgrading testtools/subunit on pqm for bzr | 14:02 |
| vila | maxb: we used the packages from the stable bzr PPA | 14:02 |
| vila | maxb: it turned out that we also needed python-central-debhelper-sequence-addon provided by the https://launchpad.net/~bzr/+archive/builddeps PPA | 14:03 |
| vila | maxb: so far, so good, except that subunit-stats is nowhere to be found now, does this ring a bell ? | 14:03 |
| soren | Is there a way I can trick two branches into having a common ancestry? | 14:15 |
| soren | Use case: | 14:15 |
| soren | I have a project which has a number of series, each with their own branch. | 14:15 |
| soren | I want to put my packaging code (which should apply cleanly to any of these branches) in a separate branch which has nothing but the packaging (contained in a debian/ directory). | 14:16 |
| soren | Just creating a new repo doesn't work, because it'll complain about lack of common ancestry. | 14:17 |
| maxb | vila: Hello | 14:18 |
| soren | I thought I was being clever, and tried "bzr branch -r 0 <one of the upstream branches> packaging" hoping that would give me a branch with a common ancestor (namely some sort of fictional 0th commit) | 14:18 |
| maxb | vila: You should only need python-central-debhelper-sequence-addon to build the package, and only on hardy. | 14:18 |
| maxb | Is the bzr PQM machine still lagging behind? I thought most of the datacentre wa on lucid now | 14:19 |
| vila | maxb: seems like it was required to install subunit :-< | 14:19 |
| maxb | wtf?! | 14:19 |
| vila | +1 | 14:19 |
| * maxb fires up a quick cowbuilder chroot | 14:19 | |
| vila | maxb: we need python-2.4 there to ensure compatibility, it's gone in lucid AFAIK | 14:20 |
| maxb | vila: meh. ok | 14:21 |
| maxb | vila: I'm still confused, I just ran 'apt-get install python-testtools subunit' in a hardy chroot, WITHOUT bzr/builddeps, and it installed fine | 14:22 |
| maxb | Or, it is because the l o s a s want to rebuild the packages in their own archive? | 14:23 |
| vila | maxb: exactly | 14:23 |
| maxb | Ah, well that's entirely different then. | 14:23 |
| maxb | I wish they could be a little more trusting. It's not like PPAs aren't a secured build environment already | 14:23 |
| vila | +1 :-} | 14:24 |
| vila | well, I can understand them too :-/ | 14:24 |
| vila | maxb: well, when I said exactly I may not have been correct, I don't really know if they copy the packages or if they rebuild them | 14:26 |
| vila | maxb: python-central-debhelper-sequence-addon is from you right ? Can you refresh my memory ? It's a workaround about python-central or ? | 14:28 |
| maxb | It's a backport of a single file that was added to python-central after hardy | 14:29 |
| vila | ok | 14:29 |
| maxb | in fact | 14:29 |
| maxb | python-central-debhelper-sequence-addon (0.6.8~bazaar1~hardy1) hardy; urgency=low | 14:30 |
| maxb | * This package takes the python-central debhelper sequence file from | 14:30 |
| maxb | python-central 0.6.8 and repackages it for installation on hardy, whose | 14:30 |
| maxb | python-central ships no debhelper sequence file. | 14:30 |
| maxb | -- Max Bowsher <maxb@f2s.com> Wed, 01 Sep 2010 02:05:46 +0100 | 14:30 |
| vila | hence the value of commit messages :) | 14:31 |
| vila | or changelogs | 14:31 |
| maxb | I mainly did it that way because it seemed nicer than rebuilding a core infrastructural package like python-central just to provide an additional file | 14:33 |
| vila | maxb: which sounds perfectly reasonable | 14:34 |
| vila | maxb: what I don't understand is why (and where) we lost subunit-stats | 14:35 |
| maxb | What is subunit-stats? A binary package that is supposed to be there but is not? | 14:35 |
| vila | maxb: when upgrading subunit | 14:35 |
| vila | it's a script provided by subunit | 14:35 |
| maxb | uh, it exists in *my* package | 14:35 |
| * vila cries | 14:36 | |
| maxb | vila: Do you have (read-only) shell access to the PQM machine? | 14:37 |
| vila | maxb: can I ping you back once my losa is back (he said biab less than an hour ago) | 14:37 |
| GaryvdM | soren : You can do bzr merge -r 0.. ../packing_branch | 14:37 |
| vila | maxb: mwhahahahahahaha | 14:37 |
| vila | maxb: does this answer the question ? >-/ | 14:37 |
| soren | GaryvdM: Yeah, but that's terrible. | 14:37 |
| maxb | Not entirely :-) | 14:37 |
| GaryvdM | soren: Or use bzr join | 14:37 |
| soren | GaryvdM: I have to tell everyone else to do that, not all tools support it (bzr-builder, for one doesn't). | 14:38 |
| GaryvdM | soren: Why? | 14:38 |
| vila | maxb: my access to pqm is: send submissions, see new revisions on bzr branches when all goes well, see no email when something fail because my ISP, most of the times, consider pqm email as spam | 14:38 |
| GaryvdM | Ok - Sorry, I'm not familiar with bzr-builder. | 14:38 |
| vila | maxb: oh, and http://pqm.bazaar-vcs.org/ of course | 14:39 |
| maxb | Hrm. If there's one thing I think Canonical does poorly, it's this iron curtain between developers and admins | 14:39 |
| soren | GaryvdM: Mostly it's because I shouldn't have to. | 14:40 |
| fullermd | Well, somebody has to keep vila in his place... | 14:40 |
| maxb | Sometimes it just has to be, like where LP is storing proprietary data, but on the bzr PQM machine !? | 14:40 |
| vila | well, as long as things works well, they are doing a great job, pqm is the only exception this far | 14:40 |
| soren | GaryvdM: Most people want to do this because they want to avoid conflicts between identical files. | 14:40 |
| vila | maxb: if I was an admin I would be quite worried to let devs play around with production servers too :) | 14:41 |
| soren | GaryvdM: I understand why that happens, and I'm fine with that. I just want to be able to merge two trees that have no files in common. | 14:41 |
| vila | maxb: may be the problem here is that we shouldn't use a production server for pqm.... | 14:41 |
| maxb | vila: I love working in a small (division of a) company. I'm a dev, but I have root@ the production servers for my app | 14:41 |
| soren | GaryvdM: ..and I'm actually lucky enough that I get to start one of these from scratch, so I thought I could create the common ancestry this way. | 14:41 |
| vila | maxb: who is the official root then ? | 14:42 |
| fullermd | Yeah. It's nice being the dev AND the admin. I'd go nuts trying to work any other way... | 14:42 |
| vila | maxb: as in: who is blamed when things go horribly wrong ? | 14:43 |
| vila | fullermd: I am slowly going nuts on this problem :( | 14:43 |
| vila | I see fingers all around... | 14:43 |
| fullermd | Sounds like a waste of time. Why not go nuts quickly? Then you have more time to enjoy it. | 14:43 |
| maxb | vila: Whoever broke it :-) | 14:44 |
| vila | maxb: Ha ! Easy, if you already know *who* :D | 14:44 |
| vila | fullermd: hehe, thanks, feeling better already :D | 14:44 |
| fullermd | That's easy to find out. Just take everyone with root, and lock them in a room with a couple bricks. Whoever makes it out under their own power is innocent. | 14:45 |
| vila | fullermd: yeah, all in the same room, quite tricky in a distributed company :-P | 14:46 |
| fullermd | That just means they need bigger bricks :p | 14:47 |
| soren | Does bzr's data model simply not support this or is it just not possible with the current UI? | 14:48 |
| vila | soren: #ubuntu-devel should get you better answers, they do that routinely AIUI | 14:52 |
| vila | soren: you *can* merge your packaging branch into all your series branches and from there merge the changes in the packaging branches | 14:53 |
| vila | but you can't keep them separate and still ask them to have a common ancestry | 14:54 |
| maxb | soren: Why do you need a common ancestry at all? | 14:55 |
| soren | vila: it's just silly that if I had known from the start that I wanted to do this, I could have created an emtpy revision as my r1, and branch from that. | 14:55 |
| soren | maxb: In short: To be able to merge them without having to specify a base revision. | 14:56 |
| soren | maxb: I explained the use case 40 minutes ago in this channel. | 14:56 |
| maxb | Why do you need to do that? (bzr-builder now supports nest-part for embedding a debian directory) | 14:56 |
| soren | maxb: For a couple of reasons, it's more convenient to have the debian/ directory in the bzr repo (and not just the contents of it). | 14:57 |
| maxb | Agreed. nest-part was created to allow that layout | 14:57 |
| soren | maxb: Er? | 14:58 |
| * soren looks at code | 14:58 | |
| maxb | nest-part allows you to instruct bzr-builder to take the debian directory from your branch and place it into the upstream branch, without it ending up at debian/debian/ | 14:58 |
| soren | maxb: Oh, cool. | 14:59 |
| soren | maxb: That solves the recipe problem, at least. | 14:59 |
| soren | maxb: It's just annoying that I have to tell people to do special things to merge this stuff. | 14:59 |
| soren | maxb: Especially since a lot of these people are git fanatics, and they get all excited and annoying when these quirks come up. | 15:00 |
| * maxb attempts to think how this would work in git | 15:00 | |
| * maxb fails | 15:00 | |
| soren | I don't know. I don't really care. :) | 15:00 |
| Tak | blargh, I don't know what it is about git that fanaticizes people | 15:02 |
| soren | But it's so fast!!!!1!!!!eleven!!! | 15:03 |
| mthaddon | vila: howdy - so what do we need to discuss? | 15:03 |
| vila | mthaddon: hehe, where did subunit-stats go ? | 15:04 |
| mthaddon | vila: how can I help answer that? | 15:05 |
| vila | mthaddon: it's part of subunit and that;s what you installed right ? maxb built it and found subunit-stats in his hardy chroot | 15:05 |
| mthaddon | maxb: in which file? | 15:05 |
| maxb | mthaddon: In the 'subunit' binary package | 15:05 |
| maxb | Could you check 'dpkg -L subunit' ? | 15:06 |
| mthaddon | maxb: we have python-subunit installed, not subunit | 15:06 |
| maxb | Ah. You should also have subunit installed, to provide the command line entry points | 15:06 |
| mthaddon | hookay... | 15:06 |
| * mthaddon suggests there really should be a bzr-pqm-dependencies package, but feels like he's suggested that before | 15:07 | |
| mthaddon | and presumably we'll need the version of subunit from the same PPA? | 15:07 |
| vila | mthaddon: that's where it's get interesting since the stable bzr PPA provides subunit not python-subunit, so where did you get the later ? | 15:09 |
| mthaddon | hmm, interesting - in any case, have subunit ready to install now, one sec | 15:11 |
| vila | mthaddon: +1 on bzr-pqm-dependencies package, but isn't it already covered by the PPAs ? | 15:13 |
| mthaddon | vila: er, how? | 15:13 |
| vila | they provides all the needed packages no ? | 15:13 |
| mthaddon | vila: a dependencies package defines all the specific packages and versions - we don't install directly from PPAs | 15:14 |
| mthaddon | vila: subunit has now been installed | 15:14 |
| vila | mthaddon: how did you use the PPA there ? | 15:15 |
| mthaddon | vila: I'm not sure I understand the question | 15:16 |
| vila | :) | 15:16 |
| vila | You asked me for PPAs but then you say you don't install from them, then what bit do you use ? | 15:16 |
| vila | mthaddon: submission set | 15:16 |
| vila | sent | 15:16 |
| mthaddon | vila: we backport from the PPA, we don't install directly from them, so having packages in a PPA is only part of the puzzle | 15:17 |
| vila | what means backport here ? | 15:18 |
| vila | You install and repackage ? | 15:18 |
| mthaddon | vila: having a dependencies package means you can define exactly which packages need to be installed and what versions, and we know as long as we satisfy that everything will work rather than having to ask about each individual package | 15:18 |
| mthaddon | we download the source package from the PPA, verify it, build it and upload it to the admin repos | 15:19 |
| vila | ha right, stupid, you can get the source from the ppa | 15:19 |
| vila | so if we had this package we can just update it and ask you to update | 15:20 |
| mthaddon | yep | 15:21 |
| vila | shudder | 15:21 |
| vila | it's kind of chicken -and-egg problem, *I* don't know precisely what is used *today* on pqm | 15:21 |
| vila | but probably enough to give it a try | 15:22 |
| vila | except I have no idea how to write such a package :D | 15:22 |
| vila | echo Depends: bzr, subunit, python-testtools > sudo make-me-a-package | 15:23 |
| mthaddon | the way to determine if it's correct would be to create a clean install, install the dependencies package, run the test suite, and see what it needs | 15:25 |
| mthaddon | should be fairly easy to do | 15:25 |
| mthaddon | and we have a ton of dependencies packages that we maintain for other projects, so if you need an example that's easy enough to provide | 15:26 |
| vila | mthaddon: deal, you've got my email ? | 15:26 |
| vila | mthaddon: I'm sure I won't be able to build a perfect pqm clone but I should be able to mimick the real one close enough (minus email handling, chroot, web report and so on ;) | 15:29 |
| mthaddon | vila: you don't need to do a pqm clone at all - just a chroot to run the test suite | 15:29 |
| mthaddon | vila: or a vm or whatever | 15:30 |
| vila | mthaddon: my crystal ball knows less than you (and I trust you) so it's reporting grey areas, so I will *assume* that running the test suite will be enough but I already have an hardy VM and by *default* python-2.5 is used not python-2.4, such details are so easily missed... | 15:33 |
| mthaddon | vila: see https://edge.launchpad.net/~launchpad/+archive/ppa - launchpad-dependencies for an example | 15:33 |
| vila | perfect | 15:33 |
| mthaddon | vila: you'd need to run the same command we run for PQM - "LANG=en_GB.utf8 make check PYTHON=python2.4" | 15:34 |
| vila | en_GB.utf8 ! Of course ! | 15:35 |
| mgz | ooh, vila has won in the battle against pqm? | 15:52 |
| mgz | should I merge up my branches? | 15:52 |
| vila | mgz: no, and first you should mthaddon :D | 15:53 |
| vila | mgz: I have a test submission running, please don't fill up the queue (yet) :F | 15:54 |
| mgz | +thank? +eat? +marry? | 15:54 |
| vila | :D | 15:54 |
| vila | marry | 15:54 |
| vila | err no, thank | 15:54 |
| vila | stupid random mouse events doing copy paste now ? What next ? | 15:54 |
| mgz | a giant lwn thread! | 15:55 |
| fullermd | Iguana invasion? | 15:55 |
| === orospakr` is now known as orospakr | ||
| GaryvdM | Hi jam | 16:14 |
| jam | morning GaryvdM | 16:15 |
| GaryvdM | I want to talk to you about bug 153787 | 16:15 |
| ubot5 | Launchpad bug 153787 in Bazaar "annotation is slow in 2a and pack repositories (affected: 0, heat: 3)" [High,Confirmed] https://launchpad.net/bugs/153787 | 16:15 |
| jam | k | 16:17 |
| GaryvdM | I think it would be better to for me to work on a iterative gui annotate. | 16:17 |
| GaryvdM | So I guess I'm going to need to add api to the Annotator classes. | 16:18 |
| GaryvdM | And plumbing api to the tree objects | 16:19 |
| jam | I think that is the route I would go | 16:19 |
| jam | note that it turns a lot of the guts of Annotator on its head | 16:20 |
| jam | so its a non-trivial change | 16:20 |
| jam | I would actually expect in the short-term for annotation to get quite a bit slower, though the tradeoff is that you'll get initial results faster | 16:20 |
| jam | command-line annotate would get slower, though | 16:20 |
| GaryvdM | Oh - ok. I've read some of the code, but not enough to understand why. | 16:21 |
| GaryvdM | I hope that is not the case. | 16:21 |
| jam | annotation currently is based around start at the original, and build up to the current | 16:21 |
| jam | and it knows when you can release what texts, etc | 16:21 |
| jam | based on whether anything needs that in the future | 16:21 |
| jam | (simple refcounting, really) | 16:21 |
| GaryvdM | Ok - usefull to know | 16:22 |
| jam | lots of other differences... | 16:22 |
| jam | for example, if you annotate in reverse, can you then save an intermediate step? | 16:22 |
| jam | or will reverse annotating break caching? | 16:22 |
| jam | will the api depend on incremental updates, what happens if you have a cache and can answer the whole thing right away? | 16:23 |
| jam | (just make sure that sending more information than a single step is reasonable, and it should be fine) | 16:23 |
| GaryvdM | Ok | 16:23 |
| jam | annotating forward, you 'save' each step along the way before you're ready to do the next step | 16:23 |
| jam | annotating in reverse, I think you would only tend to save "this is what I know about so far" | 16:23 |
| jam | has some benefits | 16:23 |
| jam | potentially, you could change the diff matching code to know to not care about certain regions because they "already match" | 16:24 |
| jam | but that would be a pretty major change, too | 16:24 |
| GaryvdM | Ok. | 16:24 |
| GaryvdM | Thanks - Lots of usefull info to think about. | 16:25 |
| jam | I think the first thing is to just design an api that can talk about it the way you want | 16:26 |
| jam | and then to validate an actual step-by-step produce this | 16:26 |
| jam | without worrying about too much caching, etc | 16:26 |
| jam | and then see what you get | 16:26 |
| GaryvdM | Ok | 16:26 |
| jam | also, we may need a new "get_record_stream" verb | 16:26 |
| jam | we currently have "topological" | 16:26 |
| jam | but this will want "reverse_topological" | 16:26 |
| jam | which is *close* to "groupcompress" order, and maybe a good enough approximation, as long as your code could handle things not 100% in order | 16:27 |
| GaryvdM | jam: Where would that need to be implemented? VersionFile implementations? | 16:27 |
| GaryvdM | reverse_topological ^ | 16:28 |
| === Guest52674 is now known as jelmer | ||
| jam | GaryvdM: something like that, yes. | 16:28 |
| jam | As mentioned, punt for now, though | 16:29 |
| jam | especially since "groupcompress" order is close enough | 16:29 |
| GaryvdM | jam: did you start on caching code? | 16:30 |
| jam | GaryvdM: I was working on refactoring PackCollection to make it easier to define an arbitrary cache | 16:31 |
| jam | but that hasn't fully panned out | 16:31 |
| GaryvdM | Ok | 16:32 |
| GaryvdM | jam: Thanks for all the info. Let me now try digest all of it :-) | 16:32 |
| GaryvdM | And the code. | 16:32 |
| jam | vila: your code has landed! Does that mean pqm is working again/ | 16:35 |
| jam | ? | 16:35 |
| hrw | hi | 16:35 |
| vila | jam: yeah ! Yes. Hi :) | 16:35 |
| GaryvdM | jam: Thanks for the merge review. | 16:36 |
| vila | jam: I just followed up on ML, you're too fast :D | 16:36 |
| hrw | http://hrw.pastebin.com/erWV8eRM is what I got with bzr-fastexport - any ideas what is wrong? | 16:36 |
| GaryvdM | hrw: My initial *guess* is that you maybe have a old version of python-fastimport. | 16:38 |
| hrw | GaryvdM: python-fastimport 0.9.0~bzr293-1, bzr-fastimport 0.9.0+bzr279-1 | 16:39 |
| hrw | GaryvdM: natty packages | 16:39 |
| GaryvdM | Ok | 16:39 |
| hrw | bzr 2.3.0-beta2 | 16:40 |
| hrw | GaryvdM: I do not know - maybe they should match | 16:42 |
| hrw | hi zyga | 16:42 |
| zyga | hrw, hi | 16:43 |
| zyga | hrw, ask :) | 16:43 |
| GaryvdM | hrw: The bzr rev numbers? I dough it. | 16:43 |
| hrw | zyga: if you want... http://hrw.pastebin.com/erWV8eRM is what I got with bzr-fastexport - any ideas what is wrong? | 16:43 |
| GaryvdM | *doubt | 16:43 |
| zyga | hrw, from the top of my head, either bzr or git/python wrapper version mismatch | 16:44 |
| hrw | GaryvdM: I think I found. need to check a bit more first | 16:46 |
| hrw | rev279 moved lot of code to python-fastimport from bzr-fastimport | 16:47 |
| GaryvdM | hrw: I think you may have manually installed a version to /usr/lib/python2.6/dist-packages/bzrlib/plugins/ | 16:47 |
| * zyga has ath9k issues again : | 16:49 | |
| GaryvdM | The file that the error occurs in no longer exists (bzr_exporter.py) | 16:49 |
| hrw | GaryvdM: http://hrw.pastebin.com/scwJcFU1 | 16:49 |
| GaryvdM | Sorry - That's is where apt-get put it | 16:50 |
| hrw | I am not too familiar with python-support/central and how they handle | 16:52 |
| GaryvdM | Yes - Sorry - I was way off | 16:52 |
| zyga | hrw python-support does some things but essentially puts the source in /usr/share/pyshared and byte-compiled version in some other place, per installed and compatible interpreter | 16:55 |
| hrw | fixed | 16:57 |
| GaryvdM | hrw: It seems like it is fixed in rev 282 of bzr-fastimport. | 16:57 |
| GaryvdM | hrw: how? | 16:58 |
| hrw | GaryvdM: r282 fixed problem indeed but one more left | 16:59 |
| hrw | ah. second is fixed in r384 | 16:59 |
| hrw | 284 | 16:59 |
| hrw | GaryvdM: from fastimport import helpers as helpers2 | 16:59 |
| hrw | and then s/helpers.binary_stream/helpers2.binary_stream | 17:00 |
| hrw | and same with helpers.single_plural | 17:00 |
| hrw | ok, tomorrow will check bzr fast-import | 17:06 |
| === deryck is now known as deryck[lunch] | ||
| hrw | fixes from r282/284 allowed me to do "git bzr clone" - "git bzr push" fails in other way | 17:06 |
| hrw | have a nice rest of day | 17:09 |
| === hrw is now known as hrw|gone | ||
| GaryvdM | Bla - bzr-pipeline, locations.conf with appendpath policies, and bzr-pqm don't play nicely. | 17:18 |
| GaryvdM | Hmm - Not sure why, but my bzr-pqm sends duplicate mails. | 17:24 |
| vila | GaryvdM: yeah, just notice that, you were so missing pqm that you had to double submit ? :D | 17:27 |
| fullermd | Oh no, vila's talking to nobody again. Get the straitjacket... | 17:32 |
| vila | damn, missed the bear | 17:32 |
| vila | nooooo, not a typo for beer | 17:33 |
| mgz | rawr. | 17:44 |
| === deryck[lunch] is now known as deryck | ||
| === JFo is now known as JFo-food | ||
| jam | GaryvdM: I did a basic review of your loggraphviz branch. Please ignore the first email, it was sent before I finished the writeup. | 19:53 |
| GaryvdM | jam: ok - Thanks | 19:53 |
| jam | also, you don't have to take things I've said as "gospel". | 19:54 |
| jam | Its meant to be some feedback on how you have things structured, but I'd like it to be more of a conversation. | 19:54 |
| === JFo-food is now known as JFo | ||
| === Ursinha is now known as Ursinha-afk | ||
| === jelmer is now known as Guest67633 | ||
| poolie | hi jam | 20:53 |
| jam | hi poolie | 20:54 |
| jam | didn't expect to see you on Sat | 20:55 |
| jam | wait, still Fri for you, right? | 20:56 |
| poolie | yes, it is | 20:56 |
| poolie | pretty sure | 20:56 |
| poolie | how are things with you? | 20:58 |
| jam | poolie: pretty good. Still a bit unhappy with the lp-serve stuff | 20:59 |
| jam | I can't reproduce production locally to make sure I get everything working right | 20:59 |
| jam | but tom works on it at 3am my time | 20:59 |
| jam | so it is 1 incremental change every 24 hrs | 20:59 |
| poolie | yuk | 20:59 |
| jam | but, at least it is something | 20:59 |
| poolie | why can't we assign someone in your tz? | 20:59 |
| poolie | actually shall we take this to lp-dev? | 21:00 |
| jam | sure | 21:00 |
| jam | -dev or -ops | 21:00 |
| === Guest67633 is now known as jelmer | ||
| poolie | vila: still up? | 21:19 |
| GaryvdM | Hi poolie | 22:19 |
| peitschie | mornin all | 22:31 |
| GaryvdM | Hi peitschie | 22:31 |
| peitschie | hi GaryvdM :) | 22:31 |
| poolie | hi GaryvdM, peitschie | 22:51 |
| peitschie | hi poolie :) | 22:59 |
| szim90 | Hi. I've been deciding between version control systems (I'm a solo developer that has gotten sick of saving things as rev1,rev2, etc). I've been reading up on the options, and I've narrowed it down to git and bzr. I wanted to ask, are the advantages mentioned on "Why Switch to Bazaar" still valid if I'm comparing a stand alone bzr install to a stand alone git install (speed and efficiency, etc)? Also, does bazaar have anything like svn's missing | 23:29 |
| dash | szim90: anything like svn's what? | 23:31 |
| maxb | For a solo developer, the choice between git and bzr will mainly rest on which philsophy and UI you prefer | 23:31 |
| szim90 | dash: svn's obliterate feature (it's something they say they have been working on for ever - it enable you to undo a commit completely, so if you accidentally included proprietary information, or (in my case), a 120mb binary, you can remove it without taking down the entire database and filtering manually). | 23:33 |
| exarkun | If you're like most normal human beings, you'll probably prefer bzr's UI though, at least while you're climbing the learning curve. | 23:34 |
| exarkun | (but gosh git is fast) | 23:34 |
| szim90 | maxb: I suppose I can test the UIs, but how would you describe the differences in philosophy. | 23:34 |
| maxb | Well, one interesting point is that Bazaar tracks the identity of files - so if you rename/move one, it stores that directly. | 23:35 |
| dash | szim90: right, bzr doesn't have that either | 23:35 |
| maxb | Whereas git tracks content, and guesses file moves based on seeing blocks of content move from one file to another | 23:35 |
| dash | szim90: like exarkun, i think git's user interface is more than a little confusing. :) | 23:35 |
| maxb | Me three. | 23:36 |
| szim90 | Well, since it's more for personal use, less confusing is definitely good! Regarding files, though, I remember reading that git trees are stored as data in .git and as data themselves (so when you clone, you then have to check out your own database to regen files). Does bzr work like this, or is it more like svn where files act like real files? | 23:37 |
| maxb | szim90: Erm, I'm afraid I understand git and svn and bzr really quite well, but I really don't understand your question. | 23:38 |
| szim90 | Fair enough, I really could have worded that better. What I meant was, I was told that if I wanted to copy a git tree (like a local directory with project data), the copy action wouldn't copy files, just the database. So I would have to checkout files after making a copy. | 23:40 |
| maxb | That depends on what you mean by 'copy' | 23:43 |
| maxb | Obviously if you copy a git or bzr tree with OS tools, you end up with the same files in the destination as the source. | 23:44 |
| maxb | It's possible what was meant was that if you push a git or bzr tree over the git or bzr wire protocols, that does not create a working tree on the server | 23:45 |
| szim90 | yes. That's what I wanted to check. My concern is that if I transfer a bzr tree to another server over ssh (something I read bzr was capable of doing), and the other system did not have bzr, then I would be stuck without a working tree on the server unless I transfered the files manually. | 23:47 |
| maxb | well, yes? | 23:48 |
| dash | szim90: sure. for that you want to use tar or rsync or something | 23:48 |
| dash | there's an 'rspush' bzr plugin that will do that. | 23:49 |
| mwhudson | or bzr upload, for a different kind of use case | 23:50 |
| dash | that one i haven't seen | 23:51 |
| szim90 | Perfect! Thanks. I just need to make sure the work is accessible in the event I end up on a work station that isn't mine. I believe that answers all my questions. Thanks you for all of your help; I'll try bzr out when I get back to my system. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!