| dOxxx | hey poolie | 00:06 |
|---|---|---|
| dOxxx | I'm contemplating getting tagged versions of pyqt and sip from their mercurial repo instea. | 00:06 |
| dOxxx | except of course they only have sip in the repo and not pyqt itself | 00:07 |
| dOxxx | /facepalm | 00:07 |
| jam | thumper: just passing by, I may be around in about 3-4 hours, though | 00:21 |
| thumper | jam: can we chat tomorrow? | 00:21 |
| jam | thumper: sure | 00:21 |
| thumper | jam: I'd like to talk about your thoughts on branch revisions :) | 00:21 |
| jam | sure | 00:21 |
| thumper | jam: as in the LP table | 00:21 |
| jam | though what time? | 00:21 |
| thumper | can you do 22:00 UTC? | 00:21 |
| thumper | or perhaps half an your earlier? | 00:21 |
| jam | 5pm is usually when I stop, extra important tomorrow because my wife is out of town | 00:21 |
| jam | 22:00 = 5pm | 00:22 |
| thumper | ah | 00:22 |
| jam | 02:00 or so might be better | 00:22 |
| jam | 21:30 would work | 00:22 |
| jam | gotta go | 00:22 |
| thumper | ok | 00:22 |
| spiv | Good morning. | 00:59 |
| dOxxx | howdy spiv | 01:07 |
| spiv | Hey dOxxx, haven't noticed you around for a while. Probably you've just been awake in more sensible timezones ;) | 01:21 |
| dOxxx | spiv: I'm not normally on IRC :) | 01:21 |
| dOxxx | I'm doing the Mac installers right now and vila suggested we talk about them on IRC | 01:22 |
| dOxxx | but I guess his timezone is not compatible | 01:22 |
| spiv | He's in Europe, typically he'll be online in about 5.5 hours from now. | 01:36 |
| dOxxx | spiv: Hmmm... awkward. | 01:38 |
| poolie | hi spiv | 01:52 |
| dlee | When I'm about to try something I think might be a bad idea that could be hard to reverse, I tend to copy .bzr somewhere so I can restore it if I make a mess. Is it safe to do that for a branch under a shared repo, without also copying/restoring the shared repo itself? | 03:25 |
| dlee | I sorta have this 6 meg .bzr branch under a 3 gig shared repo. :) | 03:26 |
| spiv | It's safe to do that. | 03:28 |
| dlee | Really good news for this project! | 03:29 |
| dash | dlee: but you can also use bzr revert and bzr uncommit :) | 03:34 |
| spiv | dash: well, assuming the operation being tried is a commit, or a pull that adds one new mainline revision (with the old tip as the lefthand parent). | 03:38 |
| dlee | Learning how to manage a multiperson bzr workflow at the far end of a large svn repo... lots of syncing that confuses me if I make a wrong step. | 03:48 |
| === Ursinha is now known as Ursinha-afk | ||
| poolie | thanks for the ascii mode patch spiv | 05:14 |
| ovnicraft | hi folks i am searching something like this http://bit.ly/aF2hqw anyone knows about? | 05:15 |
| ovnicraft | plugin for diff with Ooo files | 05:15 |
| poolie | i think you want 'bzr diff --using "oodiff -u"' | 05:16 |
| poolie | then you might want to define a bzr command alias to run that | 05:16 |
| ovnicraft | in another hand i want to know is tortoisebzr will be support on linux? | 05:21 |
| ovnicraft | poolie, i dont know why initially linux is not supported | 05:22 |
| ovnicraft | poolie, this is great https://edge.launchpad.net/bzr-oodif | 05:23 |
| poolie | ovnicraft: tbzr is very windows-specific | 05:39 |
| poolie | there's some bzr nautilus integration | 05:39 |
| poolie | i think in bzr-gtk | 05:39 |
| poolie | but 'bzr explorer' is a better option there | 05:39 |
| ovnicraft | btw is not too important i can live with stdout | 05:39 |
| ovnicraft | but i am really interested in bzr-oodiff | 05:40 |
| ovnicraft | and great foudn it | 05:40 |
| ovnicraft | found* | 05:40 |
| === mnepton is now known as mneptok | ||
| jbowtie | We have file-specific merge hooks; do we not have file-specific diff hooks? | 05:50 |
| jbowtie | I'm thinking I might propose a blueprint for handling diff and merge of various free software "binary" formats. | 05:52 |
| poolie | good idea | 05:53 |
| spiv | +1 | 05:55 |
| jbowtie | Then you hire me so I actually have time to implement it, right? ;) | 05:56 |
| * jbowtie did not put subtlety on his CV | 05:58 | |
| fullermd | Subtlety? I think I heard of that once... | 05:59 |
| vila | hi all ! | 07:19 |
| fullermd | Again? Didn't you just say that yesterday? | 07:33 |
| vila | yup, mummy told me I should do that every time I meet people, so they smile just a bit more everyday :-D | 07:34 |
| fullermd | Remember, it takes more muscles to frown than it does to smile. But it doesn't take ANY muscles to just sit there with a dumb look on your face! | 07:35 |
| vila | Yeah, but it doesn't make you richer whereas smiles are supposed to make everybody richer... The trick is to find a way to get some of *their* richness there... | 07:49 |
| poolie | hi there vila | 08:06 |
| vila | poolie: hey ! | 08:07 |
| poolie | hi there | 08:31 |
| GungaDin | is there a way to uncommit a list of commit and reapply them at the end of the history ? | 08:35 |
| spiv | Uncommit only works on commits from the end of history. But perhaps you are looking for rebase, from the bzr-rewrite plugin? | 08:36 |
| maxb | Although, that'll only work if the list of commits is a side-chain in the revision graph | 08:37 |
| maxb | There's no way to splice commits out without rewriting everything that comes after the change | 08:37 |
| GungaDin | we've made a mistake: we have branch B1 and branch B2 - both were branched of V1 & V2 (different branches, corresponding to different versions of the codebase). B2 was merged into B1 and updates of V1 are merged through to B1 every now and then... | 08:38 |
| maxb | ouch | 08:38 |
| GungaDin | now that we want to merged B1 into something else we get a criss cross merge... | 08:38 |
| GungaDin | and it's a mess. | 08:38 |
| GungaDin | the thing is that the updates from V1 are in mutually exclusive directories to the rest of the commits. | 08:39 |
| poolie | you want rewrite then | 08:39 |
| GungaDin | what will that do? | 08:40 |
| poolie | that will let you hoist out the good bits of your history, leaving behind the stuff you shouldn't have merged | 08:40 |
| GungaDin | and what will happen with the bits of the history I take out? | 08:41 |
| poolie | bzr-rewrite produces a new branch, and in that branch they will never have been merged | 08:42 |
| vila | spiv: here we are http://babune.ladeuil.net:24842/view/selftest-all-platforms/job/selftest-jaunty/lastFailedBuild/testReport/junit/bzrlib.tests.test_transport/TestSSHConnections/test_bzr_connect_to_bzr_ssh/ | 08:48 |
| GungaDin | how do I enable these plugins? | 08:48 |
| spiv | vila: huh, it wants me to login... | 08:50 |
| spiv | Is that new? | 08:50 |
| vila | argh | 08:50 |
| spiv | GungaDin: if installing from source, typically by placing them into (or symlinking them into) ~/.bazaar/plugins/, or else by installing it as a system-wide Python package. | 08:52 |
| vila | spiv: yes, new, I'm trying to allow some users to run jobs and ... that seems to have restricted anonymous access :-/ | 08:53 |
| spiv | vila: :( | 08:53 |
| vila | spiv: since you will be part of these users, you may as well create a login until I fix the problem | 08:53 |
| spiv | Ok | 08:54 |
| spiv | vila: I don't suppose Hudson has OpenID support? ;) | 08:54 |
| fullermd | I read that as "since you will be part of the problem, [...] until I fix these users" :p | 08:54 |
| vila | spiv: hehe, I haven't see that (nor searched either ;) | 08:54 |
| vila | spiv: fortunately I have all relevant config files under bzr as yesterday evening *I* couldn't login anymore at one point... | 08:55 |
| vila | and I had to revert to a working config | 08:55 |
| vila | one click and boom :-/ | 08:56 |
| GungaDin | installed bzrtools on my fedora.. but bzr rebase isn't accepted | 08:56 |
| spiv | Wow, apparently I got the first two captchas wrong. | 08:56 |
| fullermd | vila: Doesn't that infringe some Amazon patent? :p | 08:56 |
| vila | fullermd: you think I can sue Amazon for damages ? | 08:56 |
| fullermd | GungaDin: It's not part of bzrtools... look for 'bzr-rewrite' | 08:56 |
| spiv | GungaDin: bzrtools is a different plugin. | 08:56 |
| spiv | GungaDin: the plugin you want is called 'bzr-rewrite' | 08:56 |
| fullermd | vila: I think it's the other way around... they sue you for doing something with one click. | 08:57 |
| spiv | vila: "spiv is missing the Read permission" | 08:57 |
| spiv | vila: for the front page | 08:57 |
| spiv | (and the log in question) | 08:57 |
| vila | try again ? | 08:59 |
| spiv | Ok, I can view them now. | 09:00 |
| vila | and try again without login too, it seems to be fixed (I just love when I fix things without knowing why...) | 09:00 |
| spiv | vila: that's a really intruiging log | 09:00 |
| spiv | vila: bah, I don't want to have to re-enter my password :P | 09:01 |
| vila | nvm, I tried from another host, seems good | 09:01 |
| spiv | It appears to allow anon read access. | 09:02 |
| vila | that's the idea | 09:02 |
| vila | spiv: a possible explanation can be: the client try to use the socket before the hand-shake with the server has been done | 09:12 |
| vila | spiv: jam fixed a similar issue with the sftp test server | 09:12 |
| vila | spiv: most of the time the hand-shake happens quickly enough but it sometimes takes a bit more time | 09:13 |
| vila | spiv: did this match ? | 09:13 |
| GungaDin | is it possbile to find where a criss cross originates? | 09:14 |
| spiv | vila: the log implies otherwise, but of course in the presence of threads the impression of sequential events it gives is likely to be a lie.... | 09:15 |
| spiv | GungaDin: a visualisation tool like 'bzr qlog' or 'bzr viz' ('qbzr' or 'bzr-gtk' plugins, respectively), may help. | 09:15 |
| GungaDin | there are tons of commits... | 09:15 |
| spiv | I suppose there should be an option to get merge to report which revisions were involved. | 09:15 |
| * spiv -> dinner | 09:16 | |
| === ddaa1 is now known as ddaa | ||
| === spike_ is now known as spikeWRK | ||
| === zyga is now known as zyga-airport | ||
| lifeless | vila: I have a thought for you about this coding style thing. | 11:02 |
| lifeless | vila: Two thoughts. | 11:02 |
| vila | lifeless: I'm sure about that and I'm happy you share them :) | 11:03 |
| lifeless | vila: firstly, I think you may be proposing a *surrogate* metric. That is it itself doesn't indicate anything good or bad, but perhaps its often correlated with actual good/bad things. | 11:03 |
| vila | lifeless: I don't want to start a holy war but I suspect there are more problems than it appears behind this subject and I'd rellay like to understand them | 11:03 |
| lifeless | I don't like surrogate metrics because they are *follow* they don't *lead*. | 11:04 |
| lifeless | Fixing the metric doesn't make things good. | 11:04 |
| lifeless | it took me a while to understand this, (and when I did I did a big about face on my opinions in coding standards) | 11:05 |
| lifeless | Secondly, I wonder if you've taken the time to deeply listen to what Andrew Martin and I are saying about how we find code more readable when done clearly on a case by case basis rather than being strongly-mandated. | 11:06 |
| lifeless | I feel like you're brushing us off a bit. | 11:06 |
| vila | ha, sorry about that, certainly not my intent | 11:07 |
| lifeless | no worries | 11:08 |
| lifeless | like I say, just a couple of thoughts. | 11:08 |
| lifeless | The one about surrogates is the key one. | 11:08 |
| vila | I came to this proposal mostly by applying it previously on the assumption that they were an agreement and specifically to address bugs in the first place | 11:08 |
| Glenjamin | when you say coding standards, do you mean something like PEP8? | 11:09 |
| vila | and I still feel there is a relative vagueness about how we handle the overall bzrlib namespace and I'm still not comfortable about that | 11:09 |
| lifeless | yes; bzr builds its standards on pep8 | 11:09 |
| lifeless | vila: I don't know quite what you mean there | 11:13 |
| vila | as poolie commented, my intent was to *discuss* the policy and I expect to at least understand why people agree with it in certain cases but not others | 11:13 |
| lifeless | vila: Well, do you understand why I don't agree with it *at all* ? | 11:13 |
| vila | no | 11:13 |
| vila | 'warning' for example, I never know which one we're calling | 11:14 |
| lifeless | I think you're specifying something best left unspecified. | 11:14 |
| vila | that won't help talk about it :) | 11:15 |
| vila | names spaces are an important concept, how to use it is worth discussing no ? | 11:15 |
| lifeless | vila: we already do. | 11:16 |
| vila | 'from module import *' while allowed is not the best example of use | 11:16 |
| lifeless | vila: we could a little more in terms of where we put htings. | 11:16 |
| lifeless | vila: but you're not really talking about namespaces, more about scopes. | 11:17 |
| lifeless | vila: I dunno, the rules you're proposing would drive me batty. | 11:17 |
| vila | yes, name spaces are all about defining scopes to partition the global name space | 11:17 |
| vila | lifeless: hehe, right, some aliasing related bugs indeed drove me nuts ;) | 11:18 |
| vila | not to mention the spurious failures ending with illegal use of scope replacer... | 11:19 |
| vila | lifeless: I realize the proposed rules put a small burden on the writer, but the write *knows* clearly when he use a symbol from which module it comes, and *this* information is not passed to the reader, I think that's the crux of my concern | 11:20 |
| lifeless | vila: what concerns me is: | 11:21 |
| lifeless | - the reduction in flexability | 11:21 |
| lifeless | - the reduction in readability | 11:21 |
| lifeless | - the reduction in performance [small but exists] | 11:21 |
| vila | I don't understand how this reduce flexibility | 11:22 |
| vila | ha ! Finally someone mentions the performance ;) | 11:22 |
| lifeless | when you say 'do it X way', you exclude all 'non-X' ways | 11:22 |
| lifeless | thats less flexible. | 11:23 |
| neaj | erm, i'm sorry to show my oar in, but could someone help me with a simple 'bzr init' ? | 11:23 |
| neaj | jean@klippie:~/tmp$ mkdir screnum ; cd screnum ; bzr init | 11:23 |
| neaj | bzr: ERROR: '/home/jean' is not a working copy | 11:23 |
| lifeless | neaj: interesting | 11:23 |
| lifeless | neaj: `which bzr` ? | 11:23 |
| neaj | looking in .bzr.log, the traceback dies on File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/format.py", line 196, in _open | 11:24 |
| lifeless | neaj: oh | 11:24 |
| neaj | what's it messing about with svn for? | 11:24 |
| neaj | this is bzr on ubuntu 10.04 | 11:24 |
| lifeless | you can do 'bzr --no-plugins init' to avoid that; please do file a bug on https://launchpad.net/bzr-svn | 11:24 |
| neaj | will do :-) | 11:25 |
| vila | lifeless: well, one way or another you refer to a symbol. There are only two ways (excluding the ones we don't use and we don't use a lot of alias) | 11:25 |
| lifeless | neaj: you have bzr-svn, the bzr svn integration layer installed. | 11:25 |
| neaj | hehe, that dies with bzr: ERROR: No repository present: "file:///home/jean/tmp/screnum/ | 11:25 |
| lifeless | neaj: your previous failure left you with half-a-dir | 11:26 |
| neaj | yes, i want to make local branches of svn repos also | 11:26 |
| neaj | ah OK, i'll clean up and restart | 11:26 |
| lifeless | vila: sure, but when you specify you're making a global assertion...globals are bad ;) | 11:26 |
| neaj | Created a standalone tree (format: 2a) <-- yay, thank you very much | 11:26 |
| lifeless | neaj: my pleasure | 11:26 |
| vila | lifeless: 'from module import symbol' is more global than 'module.symbol' at the module (the one doing the import ;) level | 11:28 |
| lifeless | removing the authors choice is more global than that | 11:28 |
| lifeless | so you need a very strong justification to do that. | 11:28 |
| vila | lifeless: does it fly both ways ? Can *I* use module.symbol because I find it more readable ? | 11:29 |
| Glenjamin | the rule you're suggesting is to disallow from module import symbol? | 11:29 |
| lifeless | vila: I need to sleep; If its still going around tomorrow, I might ask you to argue my case, and see if that helps. | 11:29 |
| vila | lifeless: ok | 11:30 |
| lifeless | vila: If its clearer sure; mass patches forcing it one way or the other would just be noise and regarded as such, I think, reading martins comment ('flip flop..') | 11:30 |
| vila | Glenjamin: yes, see https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 comments welcome (whatever your opinion is of course) | 11:31 |
| Glenjamin | I can see the justification, but knee-jerk is that its a bit restrictive | 11:31 |
| vila | lifeless: sure | 11:31 |
| vila | lifeless, Glenjamin : I thought I made this clear with: "Moving from the ``from <module> import symbol`` style is a work in progress, submissions should avoid using it for new code but should not either includes huge cleanups that obscure the purpose of the proposal. When in doubt, use the ``<module>.symbol`` without modifying the ``from <module> import symbol`` part. | 11:34 |
| lifeless | vila: you need consensus that it *is* a work in progress. | 11:35 |
| lifeless | vila: that is sorely lacking. | 11:35 |
| * lifeless goes to bed. Gnight. | 11:35 | |
| Glenjamin | I;m unlikely to start doing any major hacking bzr, but my inclination would be that this is more guideline than rule territory. | 11:36 |
| neaj | Looks like it's a regression: https://bugs.launchpad.net/bzr-svn/+bug/182140 | 11:37 |
| ubot5` | Launchpad bug 182140 in Bazaar Subversion Plugin "bzr-svn interferes with bzr operation (affected: 1, heat: 10)" [Undecided,Fix released] | 11:37 |
| Glenjamin | neaj, can you get the bzr and bzr-svn version from "bzr version" and "bzr plugins" | 11:38 |
| neaj | posted on the issue | 11:38 |
| Glenjamin | if you try adding the bzr ppa, you can get newer versions of both. | 11:39 |
| Glenjamin | which will probably let you use it, although not really fix the underlying problem | 11:39 |
| neaj | it was fixed on 0.4.9 but it's biting me on 1.0.2, so i don't think new-ness is the problem. | 11:39 |
| Glenjamin | is it possible to bind a branch to two locations? | 11:55 |
| Glenjamin | i'm using colo (which does lightweight checkouts), but I want the branches mirrored onto my central server | 11:55 |
| Glenjamin | presumably a lightweight checkout of a bound branch doesn't propagate commits up | 11:59 |
| jbowtie | What is the scenario where I'd actually use bzr add --file-ids-from? | 12:04 |
| Glenjamin | help provides an example, sounds pretty obscure | 12:07 |
| Glenjamin | "This option is rarely needed but can be useful when adding the same logical file into two branches that will be merged later (without showing the two different adds as a conflict). It is also useful when merging another project into a subdirectory of this one." | 12:07 |
| jbowtie | It is obscure, I'm trying to find a more useful way to say that in order to fix #505086 | 12:10 |
| Glenjamin | bug 505085 (making myself a link) | 12:11 |
| ubot5` | Launchpad bug 505085 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon extensive disk usage (affected: 11, heat: 62)" [Undecided,Confirmed] https://launchpad.net/bugs/505085 | 12:11 |
| jbowtie | No, bug 505086 | 12:11 |
| ubot5` | Launchpad bug 505086 in Bazaar "[doc] bzr add help mentions but doesn't explain file ids (affected: 1, heat: 0)" [Low,Confirmed] https://launchpad.net/bugs/505086 | 12:11 |
| Glenjamin | oh, whoops | 12:11 |
| Glenjamin | oh right, i see | 12:12 |
| Glenjamin | something like --same-files-as=TREE | 12:13 |
| jbowtie | I need to sleep on it, I'll have another look at it in the morning. | 12:21 |
| knittl | what is the last number in a bzr file_id? | 12:28 |
| knittl | filename-timestamp-random-X | 12:28 |
| knittl | what's X? | 12:28 |
| Glenjamin | looks like an incrementing number to me | 12:29 |
| knittl | Glenjamin: incrementing when? | 12:30 |
| Glenjamin | at a guess, when the file changes. | 12:30 |
| maxb | knittl: technically, the whole fileid is an opaque string | 12:30 |
| knittl | and why? using those 16 byte randomness + timestamp make it pretty unique | 12:30 |
| knittl | Glenjamin: that would mean the file id changes all the time | 12:31 |
| knittl | maxb: yes, but that string has to be generated first | 12:31 |
| maxb | knittl: imagine committing 5 files called README.txt in the same commit | 12:31 |
| Glenjamin | i was about to say that, looking at my inventory i have file_ids of an entirely different format | 12:31 |
| maxb | in different directories | 12:31 |
| Glenjamin | it's probably just an enumerator per-commit then. | 12:32 |
| spiv | It's a guaranteed (within reasonable limits of probability) unique ID. | 12:32 |
| knittl | so start_bzr.bat in bzr.dev exists 9 times? | 12:32 |
| spiv | The exact way it is generated is unimportant for basically every use I can think of. | 12:32 |
| * maxb points to bzrlib.generate_ids.gen_file_id if you REALLY care | 12:32 | |
| maxb | But you really shouldn't care | 12:33 |
| knittl | i do care, otherwise i wouldn't ask | 12:33 |
| spiv | It is implemented a) to meet that constraint, b) in a way that is reasonable performant and convenient to implement. | 12:33 |
| spiv | But design-wise the details don't matter. | 12:33 |
| knittl | maxb: ok, i.ll look at that function | 12:33 |
| spiv | knittl: why? | 12:33 |
| knittl | spiv: because i do. i'm not writing code to work with bzr file ids | 12:34 |
| Glenjamin | for example, bzr-svn imported file_ids appear to be svn-revno@random:full_path | 12:34 |
| knittl | i simply need to know. is that so much to ask? | 12:34 |
| maxb | knittl: Not at all, but we want to make sure you don't mistakenly build semantics on top of something that has none | 12:34 |
| spiv | knittl: Well, it's just that it frankly sounds like a waste of your time | 12:34 |
| maxb | Glenjamin: s/random/svn-repository-uuid/ | 12:35 |
| Glenjamin | yeah, i just got that :) | 12:35 |
| knittl | spiv: writing a thesis is not wasting my time | 12:35 |
| Glenjamin | when i noticed they were all the same | 12:35 |
| spiv | knittl: ah! | 12:35 |
| spiv | knittl: what are you writing a thesis on, if you don't mind saying? | 12:35 |
| Glenjamin | all week you've been asking obscure questions, you could have said why! | 12:35 |
| knittl | maxb: i don't … but i'm describing bzr's internals and defaults | 12:35 |
| knittl | spiv: dvcs | 12:35 |
| knittl | Glenjamin: well, the answers should be the same regardless of my reasons? | 12:36 |
| Glenjamin | yes, but the willingness to provide answers is higher if the answerer understands the justification | 12:36 |
| knittl | … | 12:36 |
| spiv | nittl: Just DVCS in general? I wouldn't have thought the exact details of our default file-id generation in current versions of bzr aren't really very interesting for a thesis... | 12:36 |
| maxb | Also, the answerer can tailor the answer to the purpose being asked | 12:36 |
| spiv | But it's possible I'm missing some aspect of it that you find particularly interesting. | 12:37 |
| knittl | spiv: dvcs (bzr git hg), inner workings, storage model, object model, storage formats, performance | 12:37 |
| knittl | so it matters a lot how bzr generates ids | 12:37 |
| Glenjamin | i'm intrigued as to what comparison metric you can apply to something like the file ids | 12:37 |
| spiv | Right: I'm saying these details aren't relevant to any of those things you just listed, unless "inner workings" encompasses arbitrary implementation details. | 12:38 |
| knittl | Glenjamin: nothing to compare with file ids, but it's good to know | 12:38 |
| spiv | Or at least, that I'd be surprised to find they are. | 12:38 |
| knittl | spiv: i simply do that, it's important for me and my paper. ok? | 12:39 |
| spiv | In terms of storage model, these are restrictions on what forms a valid ID (for files, and revisions). | 12:39 |
| spiv | s/these/there/ | 12:39 |
| Glenjamin | knittl: if you haven't already seen it, http://video2010.scottishrubyconference.com/show_video/11/0 is an excellent presentation on git's workings | 12:39 |
| spiv | e.g. it's a valid UTF-8 string | 12:39 |
| knittl | Glenjamin: git and hg chapters have been finished a long time | 12:40 |
| maxb | It sounds to me like knittl is following the "Understand (almost) everything, then write about the interesting bits" approach | 12:40 |
| knittl | please don't tell me how to write _my_ paper | 12:41 |
| spiv | knittl: I don't mean to tell you how to write your paper | 12:41 |
| knittl | answer my questions that i have – and might sound weird to you – and everything will be fine | 12:41 |
| maxb | knittl: Easy there, we're just interested | 12:42 |
| spiv | knittl: I do hope I'm able to give you some guidance on what I, as one of the developers, consider to be the key design aspects vs. uninteresting implementation details, though. | 12:42 |
| knittl | maxb: the impression i have is different, i only get told what not to do with bzr and what is unimportant | 12:42 |
| spiv | knittl: which is not to say I'll be 100% right :) | 12:43 |
| knittl | i'm mostly interested in implementation details | 12:43 |
| spiv | knittl: also, you ought to be aware that you're the first person to be asking these questions for the sake of it. We're much more used to helping people *do* things with our tool and code | 12:43 |
| knittl | anyways. if the last number in a default file id is incrementing, why is it 9 for start_bzr.bat? | 12:43 |
| spiv | knittl: so naturally our reactions so far have been oriented towards that | 12:44 |
| knittl | spiv: i thought i was clear, everytime i asked something, that i'm interested in it, because i'm interested, and not because i want to build tools on top of bazaar or write extensions to it | 12:44 |
| maxb | knittl: When someone asks about details which are deliberately unspecified, there is a natural caution to make sure they are not attempting to interpret semantics that don't exist. Once you explain that your reasons, that caution is allayed. | 12:44 |
| knittl | ok | 12:45 |
| spiv | I'd expect it increments for every file added in a single 'bzr add' call (in the default implementation), because that is the simplest way to implement it to meet the constraints. | 12:45 |
| knittl | sounds better than the last weeks | 12:45 |
| spiv | knittl: so far everyone, even you, that has asked questions, has wanted to achieve *something*, not just asking to understand for the sake of it :) | 12:45 |
| spiv | knittl: I'm glad to know your goal, it will help me answer your questions better I think. | 12:46 |
| maxb | The design interesting bit about file-ids is simply: (something derived from file basename) + (something unique) | 12:46 |
| knittl | i want to achieve understanding | 12:46 |
| maxb | Actually, now I'm curious. Why do we put something derived from the file basename in there? | 12:46 |
| spiv | knittl: understanding in a specific context, though. | 12:47 |
| knittl | maxb: yes. filename in lowercase ascii, 20 chars, first period removed. timestamp in YYYYMMDDhhmmss. random 16 byte string. X | 12:47 |
| spiv | knittl: I can debate these semantics with your endlessly if you like, or you can trust me that I have much better idea of where your questions are coming from now. | 12:47 |
| spiv | knittl: just like you want us to trust you ;) | 12:47 |
| knittl | spiv: ok. bzr add file1 file2 file3. bzr commit will create: file1-time-random-1, file2-time-random-2, file3-time-random-3? | 12:47 |
| spiv | knittl: bzr add creates the file IDs, not commit. | 12:48 |
| maxb | knittl: probably. I don't care. Why do you? | 12:48 |
| knittl | spiv: ok. so bzr 'un-add' removes them again? or leaves them as stale ids? | 12:48 |
| fullermd | maxb: I'd imagine because it's easy to grab, somewhat unique, and just-because-it's-opaque-doesn't-mean-it-can't-look-good. | 12:48 |
| spiv | knittl: How to put this? If they're never committed, then they're never committed. | 12:49 |
| knittl | spiv: yes, but they are created on add (at least the string) | 12:49 |
| maxb | fullermd: A debugging aid. That makes sense. I vaguely recall something about it helping sort like content into groupcompress blocks also? | 12:49 |
| spiv | knittl: and recorded in the working tree metadata | 12:49 |
| knittl | ok | 12:50 |
| spiv | Just like renames via 'bzr mv', or merge revisions from 'bzr merge', etc. | 12:50 |
| knittl | yeah. dirstate (same name as hg) | 12:51 |
| knittl | i'll write and come back | 12:51 |
| knittl | i hope you remember the reason for my questions :D | 12:51 |
| spiv | maxb: actually, IIRC the file-id being based on basename only isn't especially good for groupcompress, or something like that. | 12:51 |
| spiv | knittl: don't worry, you've been quite memorable :) | 12:51 |
| knittl | spiv: haha. | 12:52 |
| spiv | Happy writing! | 12:52 |
| knittl | spiv: on an unrelated note, what about my cat-signature branch? | 12:52 |
| knittl | still no tests | 12:52 |
| spiv | knittl: is there a merge proposal or bug for it? | 12:52 |
| knittl | couldn't wrapp my mind about it, because i need to access bzr.dev to have something to test regressing against | 12:53 |
| spiv | knittl: it seems like a reasonable addition (as a hidden command) | 12:53 |
| spiv | knittl: ah, no | 12:53 |
| Glenjamin | the justification in the docstring for gen_file_id seems to be based on the assumption that the file_id will be used in the filesystem | 12:53 |
| knittl | no bug, and no proposal yet | 12:53 |
| spiv | knittl: tests shouldn't assume that bzr.dev exists, it's perfectly possible to create the test data you need in the test | 12:53 |
| fullermd | Glenjamin: They were, in knit and earlier formats, where each file had its own [set of] file[s] in the repo. | 12:54 |
| knittl | spiv: well, the test would need to create a new revision, sign that revision (with a key which is then stored within the test), then cat it, then verify it | 12:54 |
| Glenjamin | makes sense | 12:54 |
| spiv | knittl: that's more than necessary | 12:54 |
| spiv | knittl: you just need a test that shows cat-revision outputs the signature content for the specified revision | 12:55 |
| spiv | knittl: there's no need for the test to generate that signature on the fly first, it can be pre-canned | 12:55 |
| knittl | spiv: yes. but to get the contents i'm just calling my code | 12:55 |
| knittl | or what do you mean? | 12:55 |
| spiv | I'm sure the existing tests for signatures should already have examples | 12:55 |
| knittl | couldn't find any signature tests, maybe i was looking in the wrong places | 12:56 |
| Glenjamin | you only need to prove that if you store some text as a signature, that cat-signature outputs it | 12:56 |
| spiv | knittl: I mean: use the bzrlib APIs to create a precise signature record in the database | 12:56 |
| spiv | knittl: and then assert that cat-signature emits exact output (with that content) | 12:56 |
| spiv | You don't need to generate the signature during the test execution, it can be a literal, predefined string in the test code. | 12:57 |
| spiv | Consider what you are trying to test: | 12:57 |
| knittl | hm, i'll look. brb | 12:57 |
| spiv | * not that bzr can generate signatures | 12:57 |
| spiv | * not that bzr can generate revisions | 12:57 |
| spiv | * but that cat-signature will retrieve and display whatever content it finds for a revision | 12:58 |
| spiv | (we do of course want those other things to be tested, but that's the job of other, already written, parts of the test suite) | 12:59 |
| spiv | (overly broad tests obscure intent and make tests slower than necessary, among other drawbacks) | 13:00 |
| * spiv -> zzz | 13:01 | |
| jml | what do the cool kids use for bzr / emacs integration these days? | 13:06 |
| knittl | how can i run a bzr command inside a test? | 13:13 |
| Kinnison | jml: I use a shell :-) | 13:13 |
| jml | That doesn't count. | 13:15 |
| Kinnison | Bah | 13:15 |
| jml | Although I'm sure you are one cool kid, that's not integration. | 13:15 |
| * Kinnison treats his entire desktop environment as the integration layer :-) | 13:15 | |
| jml | At least not for my purposes. | 13:15 |
| spiv | knittl: http://doc.bazaar.canonical.com/latest/developers/testing.html | 13:19 |
| knittl | spiv: go to bed :P | 13:19 |
| neaj | is there a standard way of selectively committing chunks from a file? | 13:20 |
| maxb | interactive shelve to first remove what you don't want to commit | 13:22 |
| jml | there ought to be an interactive commit option though | 13:22 |
| jml | particularly since there's an interactive merge | 13:22 |
| neaj | maxb: thanks! | 13:24 |
| fullermd | Somebody wrote a 'record' plugin once that did that I think. Dunno if it really worked, or still does. | 13:25 |
| jml | it ought to be in bzr if shelf is. | 13:26 |
| maxb | The term 'record' is woefully overused | 13:30 |
| maxb | I wish loom called its command record-loom at least | 13:30 |
| fullermd | I imagine it was chosen to call out to 'darcs record' | 13:31 |
| fullermd | (since that does the same interactive type stuff) | 13:31 |
| jml | "bzr commit -i". There, I've solved the naming problem. | 13:31 |
| === Ursinha-afk is now known as Ursinha | ||
| knittl | can someone help me write that blackbox test? | 14:06 |
| knittl | please :) | 14:06 |
| jam | morning all | 15:07 |
| jam | knittl: what test? | 15:07 |
| knittl | hi jam | 15:07 |
| knittl | tests for cat-signature | 15:07 |
| knittl | i can create one for cat-signature -r0 easily (no output xD) | 15:08 |
| Glenjamin | is it useful for me to say i think it should be called show-signature ? | 15:08 |
| jam | knittl: you can look for bzrlib/tests/blackbox/test_cat.py and copy that file to test_cat_signature.py | 15:08 |
| knittl | Glenjamin: hahaha | 15:08 |
| knittl | jam: i believe i copied cat_revision | 15:08 |
| jam | knittl: same thing, sounds fine | 15:09 |
| jam | do you have the code somewhere you want me to look at? | 15:09 |
| jam | basically it would be something like: | 15:09 |
| jam | just a sec | 15:09 |
| knittl | Glenjamin: https://code.launchpad.net/~knittl/bzr/cat-signature look at the history (r5432 and r5433) | 15:09 |
| knittl | jam: well, i need a signature to validate against | 15:09 |
| jam | there would be two ways to do it, IMO, one is to use the "run_script" method | 15:09 |
| knittl | i think jam told me to name it "cat-signature" :] | 15:09 |
| jam | knittl: you need a signature, but it doesn't have to be valid or gpg signed :) | 15:09 |
| Glenjamin | knittl: you'll need to track down the commit code which signs, and see how it adds the signature to the revision | 15:10 |
| knittl | my best name would be print-signature, because it prints to the terminal | 15:10 |
| Glenjamin | and just do the last bit | 15:10 |
| jam | knittl: I think an alias is reasonable, but it is more consistent to call it cat-sig | 15:10 |
| Glenjamin | is cat-revision new? | 15:10 |
| knittl | jam: not signed? hm, ok | 15:10 |
| jam | knittl: there are a couple of options here, let me look at the gpg code for a sec | 15:11 |
| knittl | jam: i use run_script to test "test_cat_signature_no_signature" | 15:11 |
| knittl | jam: ok | 15:11 |
| knittl | appreciate it | 15:11 |
| jam | knittl: if you wanted to exercise more of the stack, you could set the config var "gpg_signing_command" to something custom, and then we should grab that and use it to "sign" the revision on commit. | 15:12 |
| jam | however, it may be easier to just force it | 15:12 |
| knittl | begin pseudo-signed content? | 15:12 |
| knittl | (test_re_sign.py) | 15:13 |
| jam | knittl: right that is probably the easiest way, just fudge the signing strategy, and assert the content matches what you want | 15:13 |
| jam | then you don't have to worry about having gpg on the test machine, etc. | 15:14 |
| knittl | ok, i'll try | 15:14 |
| knittl | jam: yes, that was my real problem :D | 15:14 |
| knittl | not having gpg or having the same key everywhere | 15:14 |
| jam | knittl: so in a test, you can use the monkey-patch command, then add "branch.get_config().set_user_option('create_signatures', 'always')" | 15:15 |
| jam | and then "tree.commit()" should generate a signature | 15:15 |
| jam | which you can check with "tree.branch.repository.get_signature_text()" | 15:15 |
| knittl | jam: i also want to test the output for 'no signature' (empty output | 15:15 |
| Glenjamin | imo you shouldn't worry about the signing process at all - you should just directly add some signature content to a revision | 15:15 |
| jam | knittl: sure, commit 1 without setting create-sig and once with | 15:15 |
| knittl | isn't there an option to commit? | 15:16 |
| knittl | BzrDir.create_standalone_workingtree('.').commit(…) | 15:17 |
| jam | knittl: not directly, only via config var | 15:17 |
| knittl | ok | 15:17 |
| knittl | hrm. i created two revisions, but cat-signature is empty for revid:B as well (the signed one) | 15:21 |
| knittl | first, set_user_option(always) then monkey_patch_gpg, then wt.commit | 15:21 |
| Glenjamin | how confident are you that the test is broken, and the command isn't? | 15:25 |
| knittl | 100 % | 15:27 |
| Glenjamin | knittl: i'd do away with the gpg bit, since your command doesn't do anything with it. just use repository.add_signature_text(revision_id, signature) | 15:28 |
| knittl | ha! it's working :) | 15:28 |
| knittl | http://paste2.org/p/1000141 | 15:32 |
| Glenjamin | hrm | 15:34 |
| Glenjamin | you're testing that a command which calls get_signature_text returns the value of get_signature_text | 15:35 |
| knittl | yes. i said that in the beginning | 15:35 |
| knittl | tell me how i can test that command without calling get_signature_text | 15:36 |
| Glenjamin | you have to explicitly set the signature content | 15:36 |
| jam | knittl: the revision-id is known, the signing strategy is known, just put the content into the output | 15:36 |
| Glenjamin | using repository.add_signature_text | 15:36 |
| jam | --- BEGIN PSUEDO-... | 15:36 |
| Glenjamin | or that | 15:36 |
| knittl | ok, just a min | 15:36 |
| jam | knittl: I do agree with Glenjamin that 'add_signature_text' exercises less of the stack, and makes it more focused on what you want to be testing, namely cat-revision. | 15:39 |
| jam | However, a few more thoughts: | 15:39 |
| jam | 1) the return code from 'cat-signature -r NO-SIG' should probably be nonzero | 15:39 |
| knittl | sha1 changes everytime | 15:39 |
| knittl | how can i set the return-code? | 15:39 |
| jam | knittl: all right, because the testament changes | 15:39 |
| knittl | haha, just found another bug | 15:39 |
| jam | knittl: in cmd_cat_signature.run() return an integer | 15:39 |
| knittl | gotta fux that | 15:39 |
| knittl | * fix | 15:40 |
| Glenjamin | write the testcase which reproduces it first :p | 15:40 |
| knittl | Glenjamin: the bug? | 15:40 |
| knittl | easy: bzr cat-revision -r0 | 15:40 |
| knittl | jam: return 1? or are there constants like EXIT_FAILURE? | 15:41 |
| jam | knittl: I would honestly consider that passing -r0 is a BzrCommandError('invalid revision supplied') | 15:41 |
| jam | return 1 is ok | 15:41 |
| jam | we use 3 for unhandled exception, I don't remember exactly where it is documented. | 15:41 |
| jam | but it isn't with constants | 15:41 |
| knittl | jam: if it is bzrcommanderror, then my last bugfix was wrong | 15:42 |
| Glenjamin | cat-revision has an unhandled exception with -r0 :) | 15:43 |
| knittl | Glenjamin: yes, i'm going to fix that | 15:43 |
| jam | Glenjamin: -r0 => revision_id = None | 15:43 |
| knittl | after having this test figured out | 15:43 |
| jam | which is often not handled all that well :) | 15:43 |
| jam | (though maybe it is revision_id= 'null:' ?) | 15:43 |
| Glenjamin | so takes_options = ["revision"] decodes into a revision_id? | 15:44 |
| knittl | entries(self): if self.root is not None: descend(self.root, u'') | 15:44 |
| knittl | is how i fixed the last bug for -r0 | 15:44 |
| jam | Glenjamin: it decodes into a RevisionSpec which can then be decoded further by applying it to a branch | 15:47 |
| jam | I don't remember if 0 is special cased or not | 15:47 |
| knittl | no, it's not | 15:48 |
| knittl | wt.branch.repository.add_signature_text('B', 'dummy signature') | 15:48 |
| knittl | AttributeError: 'NoneType' object has no attribute 'add_bytes_record' | 15:49 |
| knittl | i guess it takes a signature object, not a string? | 15:49 |
| jam | knittl: you'll need a wt.branch.repository.lock_write(), and wt.branch.repository.start_write_group() before you can call add_signature_text() | 15:49 |
| jam | and some othe bits | 15:50 |
| cheater | hi | 15:50 |
| knittl | oh. | 15:50 |
| jam | (commit_write_group()) | 15:50 |
| cheater | i am thinking of using bzr | 15:50 |
| cheater | how difficult is it to migrate from cvs? | 15:50 |
| jam | cheater: difficulty is generally expressed in how hard you swear at cvs :) | 15:50 |
| dash | cheater: no more difficult than anything else, probably | 15:50 |
| Glenjamin | cheater: in terms of technical setup, or usability? | 15:51 |
| cheater | let's consider both options | 15:51 |
| jam | it depends on what kind of fidelity you want from the conversion given that CVS's understanding of history is not particularly accurate across the whole project | 15:51 |
| Glenjamin | well, bazaar's commandset is pretty much understandable to anyone who's used svn (and thus cvs). I haven't really encountered many instances where commands have the same name and do something surprising | 15:52 |
| cheater | what sort of different "fidelity" can i get jam? | 15:52 |
| cheater | Glenjamin: ok | 15:52 |
| cheater | so that's 'usability' i guess | 15:52 |
| cheater | we're not integrating cvs with anything | 15:52 |
| cheater | which is good because that falls away | 15:52 |
| jam | cheater: If you have used cvs in a 'basic' capacity, probably pretty good. The problem is that cvs is a bit limited, so people add a lot of hacks on top of it (like copying ,v files, etc) | 15:52 |
| knittl | jam: isn't there something more complete to add signature text? | 15:52 |
| cheater | what are ,v files? | 15:53 |
| cheater | but yes | 15:53 |
| Glenjamin | knittl: that's the highest up command which doesn't use gpg | 15:53 |
| cheater | i cannot guarrantee it but i don't think they were using any cvs hacks at ALL | 15:53 |
| cheater | just the usual stuff, branches, and merges | 15:53 |
| cheater | that's all tbh | 15:53 |
| jam | knittl: take a peak at cmd_re_sign, there is 'repository.sign_revision()' passing in a signing strategy, but it still requires a write lock and a write group to write into | 15:54 |
| jam | cheater: ,v is the data storage of cvs | 15:54 |
| jam | foo.c,v is the history of the 'foo.c' file | 15:54 |
| cheater | no, i'm almost certain they were not doing that. | 15:54 |
| jam | stored on the cvs server | 15:54 |
| jam | cheater: (it also depends if you want ongoing conversion, or one time conversion, or...) | 15:54 |
| jam | the short answer is that you can look into | 15:55 |
| Glenjamin | sign_revision calls store_revision_signature which calls add_signature_text | 15:55 |
| cheater | one time conversion | 15:55 |
| jam | cvs2bzr my_project my_project.fi; bzr fast-import my_project.fi, though there is more documentation than that available | 15:55 |
| cheater | mhm | 15:55 |
| Glenjamin | do you intend to replace the company's central repository with something bazaar based? | 15:55 |
| cheater | will it be best to convert straight from cvs to bzr? | 15:56 |
| cheater | or say from cvs to svn to bzr? | 15:56 |
| jam | cheater: http://cvs2svn.tigris.org/cvs2bzr.html | 15:56 |
| maxb | cheater: The cvs2svn project (of which I'm a commiter) also supports targetting bzr. It is mature and many people have stared at its output, so the fidelity should be good | 15:56 |
| jam | basically, the code that was used to go cvs => svn was then updated to target bzr | 15:56 |
| knittl | this test is complicated -.- | 15:56 |
| cheater | ok | 15:57 |
| fullermd | You don't have to paint very far outside (or even outside) the lines in CVS to make some very tricky to deduce/convert history. Only way to know, really, is to try. | 15:57 |
| maxb | I have two recommendations: 1) Use the tip of trunk of cvs2svn/bzr. 2) Use bzr qlog to examine the results | 15:58 |
| fullermd | There was a whole lotta headscratching in Postgres in their just-completed CVS->git conversion. | 15:58 |
| cheater | can it take very long to do that? | 15:58 |
| cheater | maxb: i don't know what "use the tip of the trunk" means | 15:58 |
| Glenjamin | depends how big your history is :) | 15:58 |
| cheater | about 10 years | 15:59 |
| cheater | but the code in itself is only about 500 000 lines now | 15:59 |
| cheater | i am guessing that shouldn't take much longer than 2-3 hours? | 16:01 |
| fullermd | The number of revisions (which will be guesswork short of trying it) or the size of the repo would be good ballparking figures. | 16:01 |
| cheater | i can tell you the size of the checkout | 16:02 |
| cheater | not sure if i have access to the repo | 16:02 |
| cheater | not sure how to get the "number of revisions" either | 16:02 |
| knittl | AttributeError: 'TestCatSignature' object has no attribute 'add_cleanup' <- what's this? | 16:02 |
| fullermd | 10 years old... a commit a day? A hundred commits a day? | 16:02 |
| cheater | 1-2 commits | 16:02 |
| cheater | it's really mostly been 1-3 devs | 16:03 |
| cheater | fluctuating in size | 16:03 |
| fullermd | OK, so that's only a few thousand revs. | 16:03 |
| cheater | the team was fluctuating in size, that is. the devs were fluctuating in size, too, though :D | 16:03 |
| Glenjamin | knittl: somewhere along the line something is trying to add a cleanup callback | 16:03 |
| knittl | Glenjamin: yes, i did | 16:03 |
| knittl | trying to add that write lock stuff | 16:03 |
| Glenjamin | ah | 16:04 |
| Glenjamin | i assume you copied it from a command | 16:04 |
| Glenjamin | which has add_cleanup, the testcases probably have an equivalent | 16:04 |
| knittl | yep | 16:04 |
| fullermd | If it takes 2 seconds per rev to convert, you can convert 3600 revs in 2 hours. On a reasonably sized tree, that's probably an upper bound (and I wouldn't be shocked if it were a VERY upper bound) on the time/rev. | 16:05 |
| === deryck is now known as deryck[lunch] | ||
| fullermd | Seems to me the last tree I converted was pretty small, maybe 3, 400 revs, and took something like a minute? | 16:06 |
| knittl | Glenjamin: it's passing the tests, but i'm unsure if the way i lock the repository is the right one | 16:07 |
| knittl | simply doing b.repository.lock_write(); b.repository.start_write_group() | 16:07 |
| knittl | hrm. is write_group just a very bad name for 'transaction'? | 16:08 |
| knittl | jam, Glenjamin: http://paste2.org/p/1000182 | 16:09 |
| knittl | hm. can probably remove the gpg lie | 16:09 |
| knittl | * line | 16:09 |
| knittl | how can i test exitcode? | 16:10 |
| Glenjamin | knittl: the commend on line 32 is now incorrect. if you add the lock stuff into the try: and put an ensure: block which releases the lock | 16:10 |
| knittl | what's ensure? | 16:11 |
| Glenjamin | sorry, ruby | 16:11 |
| Glenjamin | rescue | 16:11 |
| knittl | well 'signed' = 'has a (dummy) signature' | 16:11 |
| Glenjamin | no, finally | 16:11 |
| Glenjamin | i mean a finally block. | 16:11 |
| knittl | what's the else: block for try/except? | 16:12 |
| Glenjamin | else is "run this if there's no exceptions" | 16:12 |
| cheater | knittl: so what do you think, how much should that take to convert? | 16:12 |
| cheater | knittl: just ballpark :) | 16:12 |
| cheater | erm | 16:13 |
| knittl | Glenjamin: so, i could just put it after the thing that throws the exception? (for that oneliner) | 16:13 |
| cheater | *fullermd :)) | 16:13 |
| cheater | sorry! | 16:13 |
| knittl | cheater: don't know, i don't use bazaar | 16:13 |
| cheater | (wow, it IS hot in this office today) | 16:13 |
| cheater | knittl: heheh yeah | 16:13 |
| fullermd | cheater: Well, hard to say without more numbers on the size. But I'd guess you'd have headroom at hours. | 16:13 |
| knittl | cheater: no, i'm serious – i don't use bazaar for my own personal work | 16:13 |
| fullermd | I'd just grab it and try an initial run to see. | 16:14 |
| fullermd | Assume it'll be a throwaway, so you don't need to worry too much about getting trunk cvs2bzr and tweaking configs and all that, just a first blush to see how long it takes and how well it converts. | 16:14 |
| knittl | Glenjamin: i can only create a writegroup after locking the repo. so i'd have two nested try blocks? | 16:15 |
| knittl | Glenjamin: also, else: makes no sense for me. if i don't run into an exception, it could simply be the last statement inside try? | 16:15 |
| Glenjamin | knittl: http://paste2.org/p/1000188 | 16:16 |
| Glenjamin | the else block isn't subject to the except | 16:16 |
| knittl | Glenjamin: to what then? | 16:16 |
| knittl | and hm. start_write group is outside of try in cmd_revsign | 16:16 |
| Glenjamin | hrm | 16:17 |
| Glenjamin | they're probably right | 16:17 |
| Glenjamin | but the finally is the bit you need | 16:17 |
| Glenjamin | i don't do much python stuff | 16:17 |
| knittl | works either way (inside or outside) | 16:17 |
| knittl | Glenjamin: can you try explaining the else: part? | 16:17 |
| Odd_Bloke | knittl: Are you looking for a specific explanation, or just information about try, except, else? | 16:19 |
| Glenjamin | its for statements which shouldn't be caught by the except, but should happen before finally | 16:19 |
| Glenjamin | (had to read the bit in the manual a few times to get it myself) | 16:19 |
| knittl | Odd_Bloke: just found it in the docs. exceptions from else: will not be caught | 16:19 |
| knittl | ok, i think the tests are finally passing | 16:20 |
| knittl | (again xD) | 16:20 |
| knittl | how can i test exit status? | 16:21 |
| knittl | i'd just use $? but i guess that's not the pythonic way xD | 16:23 |
| Glenjamin | i think you can do something with 2> in the script runner thingy | 16:24 |
| Glenjamin | or you might have to use the blackbox command runner thing | 16:24 |
| knittl | run_bzr | 16:24 |
| knittl | ah. found an assignment | 16:24 |
| knittl | out,err = self.run_bzr | 16:24 |
| knittl | but i'd like to also check output | 16:28 |
| knittl | ideas? | 16:30 |
| knittl | (without running the command twice) | 16:30 |
| Glenjamin | presumably there are some existing tests which do this? | 16:30 |
| knittl | ah, i'm stupid. run_bzr returns output | 16:31 |
| knittl | which should be empty | 16:31 |
| Odd_Bloke | knittl: Yeah, it'll be in 'out'. | 16:31 |
| knittl | hmm. output does not match | 16:36 |
| knittl | but when i call it from the command line it returns with 1 | 16:36 |
| knittl | what? | 16:37 |
| knittl | oooh, run_bzr asserts against 0 | 16:37 |
| knittl | can i circumvent that? | 16:37 |
| knittl | retcode… | 16:40 |
| knittl | finallyx | 16:45 |
| knittl | s/x/ …/ | 16:45 |
| knittl | http://paste2.org/p/1000221 | 16:46 |
| knittl | https://code.launchpad.net/~knittl/bzr/cat-signature more comments? | 16:54 |
| === deryck[lunch] is now known as deryck | ||
| jam | knittl: things should be indented 4 spaces (no tabs) | 17:01 |
| knittl | 4? | 17:01 |
| jam | and it should be "retcode=1" not "retcode = 1" | 17:01 |
| knittl | ok | 17:01 |
| jam | knittl: everything else in bzrlib is 4 spaces | 17:02 |
| knittl | cat_signature was not … | 17:02 |
| jam | knittl: ... because you wrote it? | 17:03 |
| knittl | probably ^^ | 17:03 |
| jam | (it should be fixed) | 17:03 |
| knittl | in the next series | 17:04 |
| jam | anyway the test seems ok | 17:04 |
| knittl | pushed a new version (--overwrite) | 17:05 |
| knittl | 5 commits in total | 17:06 |
| === Ursinha is now known as Ursinha-lunch | ||
| knittl | jam: should i make a merge proposal? | 17:14 |
| jam | knittl: yep | 17:15 |
| knittl | who wants to fix -r0? or should i go on and fix its symptoms? | 17:16 |
| knittl | hm. cat_revision raises an exception … which in turn makes bzr crash | 17:19 |
| knittl | ehm | 17:24 |
| === beuno is now known as beuno-lunch | ||
| vila | jam: ping, any news about the windows installer ? | 18:35 |
| === maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| maxb | (just tidying some dodgy spacing) | 18:39 |
| === beuno-lunch is now known as beuno | ||
| vila | maxb: what is missing for the plugins you listed in your mail ? | 18:44 |
| maxb | That list was generated purely based on the deb Depends criteria. *Assuming* that was correct, they need a new release compatible with bzr 2.3 | 18:45 |
| vila | maxb: ok | 18:46 |
| vila | We haven't bumped the minimum API for 2.3 though, so that may not be needed | 18:47 |
| maxb | When will we know whether 2.3 will contain a bzrlib api bump? | 18:48 |
| vila | maxb: well, when it happens ;) But as far as 2.3b1 is concerned, it won't | 18:49 |
| maxb | Maybe we should rebuild the packages just marking them as working with 2.3, and hope | 18:50 |
| vila | maxb: yup, that's also what betas are for here, generally the API problems are encountered by people running from source | 18:51 |
| jam | vila: Gary was working on it, but I haven't heard since | 19:11 |
| jam | vila: why do we need the test suite to run as root ? (Versus just having selftest say "sorry fool, no running as root") | 19:11 |
| vila | jam: because that's how the buildds works ? | 19:11 |
| vila | jam: bug #644015 | 19:12 |
| ubot5` | Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite (affected: 1, heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/644015 | 19:12 |
| vila | jam: was there any pending problem (last you heard) ? | 19:14 |
| jam | vila: you mean running as root? Just that it is usually a bad thing to do. but I've approved your patch | 19:16 |
| knittl | jam: i already fixed the 4 spaces problem | 19:17 |
| jam | knittl: well, you hadn't pushed that up yet, or LP hasn't seen it | 19:17 |
| knittl | i have pushed | 19:17 |
| jam | but with the minor tweaks, i think its ready | 19:17 |
| knittl | but i only realized after merge-proposal | 19:17 |
| vila | jam: yes, running as root, this makes sense to build packages... especially when you need to installl dependencies | 19:17 |
| knittl | also, why empty lines? i tried to mimic code from other functions | 19:18 |
| jam | vila: sudo works pretty well to install dependencies, without running arbitrary code as root. I'm not saying I'm going to change what their doing | 19:18 |
| jam | knittl: most have the style I specified, if they don't, it is a bug | 19:18 |
| jam | s/bug/should be fixed/ | 19:18 |
| knittl | http://bazaar.launchpad.net/~knittl/bzr/cat-signature/revision/5438 here's the whitespace fix. but i'll add some newlines and push again | 19:19 |
| jam | knittl: it is just our style guide, we're pretty consistent on it, though you may have found some exceptions | 19:19 |
| vila | jam: sure, I was a bit scared about the test failures at one point as implying lock would not work anymore but the tests were only testing weird setup errors | 19:19 |
| vila | jam: sudo query for the password, this should run unattended | 19:20 |
| jam | vila: you can set up sudo to not require it. Anyway, I'm not saying we should fix the buildd code. If it is the way it is, then it is the way it is. | 19:20 |
| jam | buildds run as vms that get wiped per install anyway | 19:21 |
| jam | (and yes, if you have auto sudo upcast it could still do arbitrary things, but you can limit what it has access to) | 19:21 |
| knittl | jam: pushed | 19:23 |
| dOxxx | good afternoon... | 19:26 |
| vila | dOxxx: Hey ! | 19:29 |
| dOxxx | vila: heya. working from home so I'm not firewalled from IRC ;) | 19:30 |
| vila | dOxxx: I tested the mac installer | 19:30 |
| dOxxx | vila: thanks :) | 19:30 |
| vila | only slight tests as I did it on a mac where I barely have an account but I ran bzr explorer, branch bzr, run qlog | 19:31 |
| dOxxx | vila: I think that's probably good enough. Any problems (that I can fix) should be pretty obvious. | 19:32 |
| dOxxx | vila: I was wondering if we could try building the installer on your 10.5 Mac? | 19:32 |
| vila | dOxxx: just a sec, booting it | 19:33 |
| vila | dOxxx: ok, where do I start ? I have a running setup for bzr from source (including gcc/pyrex but no paramiko) | 19:35 |
| vila | weird, why don't I have paramiko... >-/ | 19:35 |
| dOxxx | vila: you'll need the Qt Cocoa framework, Packages app and MacTex installed. | 19:36 |
| vila | dOxxx: hmpf | 19:36 |
| dOxxx | vila: MacTex is a monster | 19:36 |
| vila | dOxxx: is this documented somewhere ? | 19:37 |
| vila | dOxxx: well, it was years ago ;) Or was it OzTeX ? | 19:37 |
| dOxxx | the project page for the installers https://launchpad.net/bzr-mac-installers has a brief rundown | 19:37 |
| dOxxx | the README in the actual installer project has links | 19:38 |
| dOxxx | I should update the project blurb... | 19:38 |
| dOxxx | so, start off with "bzr branch lp:bzr-mac-installers/2.2" | 19:38 |
| vila | done with branching | 19:41 |
| dOxxx | have a look at the README in there, it should have the URLs you can download the dependencies from | 19:42 |
| dOxxx | although I think I have subsequently switched to Qt 4.6.3... | 19:43 |
| dOxxx | so use http://get.qt.nokia.com/qt/source/qt-mac-cocoa-opensource-4.6.3.dmg instead | 19:43 |
| vila | dOxxx: still pyrex-0.9.8.5 ? | 19:44 |
| vila | there is a maxtex2010, should I stick with 2009 ? | 19:45 |
| vila | mactex | 19:45 |
| === Ursinha-lunch is now known as Ursinha | ||
| dOxxx | vila: As far as I know newer pyrex versions interacted badly with bzr. Try the MacTex2010, it probably won't break... | 19:46 |
| dOxxx | vila: if there is a newer pyrex that is known to work with bzr, then use that. | 19:47 |
| dOxxx | just let me know what the version is so I can update the doc :) | 19:47 |
| vila | dOxxx: I'm updating the README as I download ;) | 19:47 |
| dOxxx | ok cool :) | 19:47 |
| vila | fetch-externals is unrelated right ? | 19:47 |
| vila | ouch, still 1h47 to download qt :-/ | 19:48 |
| dOxxx | yeah, those dependencies are nasty | 19:52 |
| dOxxx | fetch-externals downloads all the plugins and packages that are compiled during the install | 19:52 |
| dOxxx | so once you have qt, mactex, packages, etc. installed, you run "python fetch-externals.py -p" to download the specific versions of plugins and packages the config requires | 19:53 |
| dOxxx | then "python build.py" will compile everything into local build directories and then builds the installer package and disk image | 19:53 |
| vila | dOxxx: I have a python-2.6 here, but I can't remember if it's the default version or the default provided one ? | 19:54 |
| dOxxx | python 2.5 is the default for 10.5 | 19:54 |
| vila | dOxxx: and that's it ? I just have to sign/upload the result ? | 19:54 |
| dOxxx | yes | 19:54 |
| vila | dOxxx: great | 19:54 |
| dOxxx | it takes a while to compile, which is mostly pyqt's fault. | 19:55 |
| dOxxx | it's about 30m on my wife's macbook pro | 19:55 |
| vila | dOxxx: ouch the macbook air will suffer | 19:55 |
| dOxxx | well, it's newer than mine so maybe, maybe not | 19:56 |
| vila | dOxxx: will paramiko be taken into account by fetch-externals ? | 19:57 |
| dOxxx | yes | 19:58 |
| dOxxx | config.py lists all the stuff it downloads | 19:58 |
| dOxxx | beware, config.py is a UTF-8 file with non-US characters in it (Japanese and Russion doc file names) so be careful if you edit | 19:59 |
| vila | dOxxx: ok, seems fine here | 20:00 |
| vila | dOxxx: how do you install pyrex ? | 20:00 |
| dOxxx | pyrex needs to be installed by you for the system default python | 20:01 |
| dobey | anyone have any idea, why if i commit 3 revisions to a branch, trying to fetch revno 3 would fail? | 20:02 |
| dobey | http://pastebin.ubuntu.com/499279/ | 20:02 |
| fullermd | How are you trying to do that fetch? | 20:03 |
| vila | dOxxx: done | 20:03 |
| fullermd | I suspect you're calling an API that isn't expecting a revno. | 20:04 |
| vadi2 | How can I search across -all- revisions of a text file that is tracked by bzr? | 20:04 |
| dOxxx | vila: I guess you're still downloading Qt and MacTex? | 20:04 |
| dobey | fullermd: merge() | 20:05 |
| vila | d0still dowloading qt, installing MaxTeX | 20:05 |
| vila | meh | 20:05 |
| vila | dOxxx: still dowloading qt, installing MaxTeX | 20:05 |
| vila | dOxxx: ghaa, approaching disk space limits... | 20:06 |
| vila | quick quick what can I kill | 20:06 |
| dobey | fullermd: or more specifically WorkingTree.merge_from_branch() it seems | 20:07 |
| dobey | fullermd: i'm trying to write unit tests for a part of tarmac that is untested with unit tests, but which does work with live branches (as i've been using it for many months now) | 20:08 |
| fullermd | dobey: Well, I'm not authority on the API. I just suspect you're at far too low a level for it to accept revno's. You'll probably need to manually parse that to a revid (or maybe a revision object of some sort? I have no idea...) | 20:09 |
| dOxxx | vila: yeah sorry about that. tex is stupid big. | 20:09 |
| vila | dobey: if you're writing tests you can force the revids, easier to reuse then | 20:10 |
| dobey | fullermd: nah, it accepts revnos. because that's what we've been passing in, with the live runs | 20:10 |
| dOxxx | vila: I just remembered another dependency that I forgot to add to the README... Sphinx. :P | 20:10 |
| vila | dOxxx: hehe, yeah, I blame *you* for TeX size :-D | 20:10 |
| dOxxx | vila: ;_; | 20:10 |
| vila | dOxxx: sphinx... which version ? | 20:10 |
| vila | dOxxx: 1.0.4 ? | 20:12 |
| vila | dOxxx: 1.0.4 installing.... grabbing docutils, jinja, kitchen sink and pygments | 20:16 |
| dOxxx | vila: apparently I had 0.6.4 installed | 20:17 |
| vila | dOxxx: hmm, will see | 20:17 |
| dOxxx | I don't have a download tarball so I must have used easy_install | 20:18 |
| vila | dOxxx: for 2.5 ? | 20:19 |
| vila | I have it for 2.6 but not for 2.5 here... | 20:19 |
| vila | dOxxx: still 43 minutes to go for qt | 20:21 |
| vila | dOxxx: this is so last century dl speed ;) | 20:21 |
| dOxxx | haha | 20:22 |
| dOxxx | is easy_install a 2.6 thing? | 20:22 |
| vila | dOxxx: could be, I vaguely remember having upgraded to 2.6 for it | 20:25 |
| vila | dOxxx: have you built the 2.3b1 installer ? | 20:28 |
| vila | dOxxx: well, I mean, is there any difference for the 2.3b1/10.5 installer | 20:29 |
| dOxxx | vila: yes, I'll upload now. also have the 2.1.3 installer done. | 20:29 |
| vila | dOxxx: cool | 20:30 |
| dOxxx | 2.3b1 I build using tip versions of all the plugins | 20:31 |
| dOxxx | hmm upload is making remote desktop to work computer somewhat laggy :P | 20:32 |
| dOxxx | vila: 2.3b1 and 2.1.3 uploaded | 20:39 |
| vila | dOxxx: excellent | 20:40 |
| dOxxx | vila: release pages updated. formatting is a little wonky though, I don't grok the wiki formatting language yet | 20:41 |
| vila | dOxxx: don't worry, 1) the content is more important, 2) I can fix it later | 20:42 |
| jml | guys | 20:42 |
| jml | can you please implement a visual AST-based diff for bzr? | 20:42 |
| jml | that'd be great, thanks. | 20:42 |
| jml | bye. | 20:42 |
| dobey | oh bzrlib, she is a harsh mistress | 20:44 |
| vila | dOxxx: but once it's uploaded, just mention it in the 'DONE' section instead of the 'IN PROGRESS' one | 20:44 |
| vila | dOxxx: look at the 2.2.1 page, I've updated it | 20:45 |
| vila | dOxxx: I even broke the formatting :) | 20:45 |
| vila | dOxxx: fixed :) | 20:45 |
| dobey | lifeless: can you see anything obviously meaningful in http://pastebin.ubuntu.com/499279/ as to why bzrlib would tell me that revision 3 doesn't exist, when it was just committed? | 20:49 |
| dOxxx | vila: well I've put it in the in progress section because the 10.5 installers aren't done yet but I suppose I could separate them | 20:50 |
| dOxxx | vila: I'll update the other pages | 20:50 |
| vila | dOxxx: yup, that's what I did for 2.2.1 | 20:50 |
| vila | dOxxx: thanks | 20:50 |
| lifeless | dobey: not without context | 20:50 |
| lifeless | dobey: you might, for instance, have a read locked repo already which won't see new info until you refresh/unlock-readlock it | 20:51 |
| dobey | hmm | 20:52 |
| dOxxx | vila: release pages updated | 20:54 |
| vila | dOxxx: perfect | 20:56 |
| dobey | lifeless: hm, is_locked() is saying it's not locked | 20:56 |
| vila | dOxxx: installing Qt... | 21:12 |
| dOxxx | vila: woot woot | 21:15 |
| vila | dOxxx: fetch-externals: no module named bzrlib ;) | 21:17 |
| dOxxx | hmm... I suppose I should mention that it requires bzr installed too? :) | 21:17 |
| vila | any version ? | 21:17 |
| dOxxx | yeah whatever works to fetch the branches required | 21:17 |
| vila | k | 21:18 |
| dOxxx | I started originally with 2.0 | 21:18 |
| vila | dOxxx: seems ok with trunk :) | 21:20 |
| vila | dOxxx: you should use doc.bazaar.canonical.com instead of doc.bazaar-vcs.org though | 21:21 |
| dOxxx | where? | 21:22 |
| vila | dOxxx: dunno, saw the urls pass in the output | 21:24 |
| vila | dOxxx: for the pdfs ? | 21:24 |
| dOxxx | vila: oh, yeah, if you're using the -d option on fetch-externals.py, you don't need to since they're now built using sphinx. I need to remove that option from fetch-externals. | 21:25 |
| vila | dOxxx: no urgency but if the redirection is ever broken in the future | 21:25 |
| vila | dOxxx: hehe, I'm fllowing the README :) | 21:25 |
| vila | following | 21:26 |
| dOxxx | vila: good on you sir. it is I who is the forgetful slacker that has not updated it. | 21:26 |
| vila | dOxxx: hehe, don' t worry, any more hints before I run build.py ? | 21:26 |
| dOxxx | vila: my only exuse is that sphinx support was the thing I was experimenting with most recently, so it isn't "final" | 21:26 |
| dOxxx | um... | 21:26 |
| dOxxx | so, you have the Packages app installed? | 21:27 |
| vila | dOxxx: yes | 21:27 |
| dOxxx | then I think you're good to go. | 21:28 |
| vila | dOxxx: MacTeX, qt, sphinx, pyrex | 21:28 |
| vila | fire | 21:28 |
| vila | dOxxx: I should say that I'm impressed, things have gone pretty smoothly (bar qt download ;) | 21:29 |
| vila | sphinx runnign | 21:30 |
| vila | hmm, errors and warnings there :-/ | 21:31 |
| dOxxx | dang | 21:31 |
| vila | weird, this doesn't seem to stop it | 21:31 |
| dOxxx | >_>b | 21:32 |
| vila | ha, may be new with sphinx-1.0.4... | 21:32 |
| dOxxx | I honestly don't recall if there are errors and warnings during the sphinx phase when I build it using 0.6.4. I just start it and then go do something else for 30 minutes, come back, curse at the error that occurred after 5 minutes, fix it, rinse repeat. | 21:33 |
| vila | dOxxx: is says build succeeded | 21:34 |
| vila | ha, pdflatex not found :-( | 21:34 |
| vila | dOxxx: do I need something in my PATH for MacTeX ? | 21:35 |
| vila | dOxxx: /usr/texbin ? | 21:37 |
| vila | dOxxx: works better | 21:39 |
| vila | dOxxx: don't forget that we haven't yet officially switched to sphinx, so report any bugs you encounter there | 21:39 |
| vila | dOxxx: hihi Overfull \hbox, I had almost forgotten that one :) | 21:41 |
| vila | dOxxx: compiling SIP, what's that ? :D | 21:41 |
| vila | dOxxx: pyqt now | 21:42 |
| dobey | how can i make lp:foo point at file:///blah/blah/blah/tmpdir-bzrblahblah/branch instead of giving me the 'invalid protocol' error, through bzrlib? | 21:43 |
| dOxxx | dOxxx: hmm... I think I did encounter some path issue with finding pdflatex | 21:50 |
| dOxxx | err right talking to myself again | 21:50 |
| dOxxx | vila: Hopefully I can change the build script to deal with the path issue | 21:50 |
| dOxxx | vila: looks like I made symlinks in /usr/local/bin. I hadn't noticed /usr/texbin. That's a much better solution. :) | 21:51 |
| vila | dOxxx: pure luck ;) | 21:52 |
| vila | dOxxx: it's mentioned in the What is Installed.pdf for MacTeX... err no, I *mistyped* /usr/tex instead of /usr/local/tex and found it ;) | 21:54 |
| * vila kills one more chicken | 21:54 | |
| DanielCordeiro | Hi, I'm having a little problem with bzr and I would like your help. :) *Sometimes* I'm getting an "bzr: ERROR: [Errno 5] Input/output error" that doesn't allow me to do even basic operations such as "status". | 21:57 |
| dash | are you using nfs? | 21:57 |
| DanielCordeiro | Yes. | 21:57 |
| dash | well, that's why | 21:57 |
| DanielCordeiro | :( | 21:57 |
| DanielCordeiro | It is supposed to not work when using NFS? | 21:57 |
| dash | i think it's _supposed_ to work, but it doesn't | 21:58 |
| DanielCordeiro | :) | 21:58 |
| DanielCordeiro | It is strange. I always used bzr in a NFS filesystem and never had any problem. | 21:59 |
| dOxxx | vila: are you fixing this in build.py or should I? | 21:59 |
| vila | dOxxx: please do, it's still running here, I just did export PATH=$PATH:/usr/texbin and mentioned it in the README | 22:00 |
| DanielCordeiro | Is this problem documented anywhere or is there any workaround? | 22:01 |
| dOxxx | ok | 22:01 |
| dash | there's a bug open for it | 22:01 |
| DanielCordeiro | I have submitted a bug report also, I will update it and tell that I'm using NFS. :P | 22:02 |
| dash | https://bugs.launchpad.net/bzr/+bug/137387 | 22:02 |
| ubot5` | Launchpad bug 137387 in Bazaar "close or truncate of os-locked file gives EIO on some NFSv4 servers (dup-of: 98836)" [Low,Incomplete] | 22:02 |
| ubot5` | Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed] | 22:02 |
| dOxxx | vila: btw, the way I've been trying to manage the branches for the installer is that tool changes, like fixing this pdflatex thing are usually made on trunk and merged to the different branches, and changes to the config.py for a particular version are made on the corresponding branch. | 22:02 |
| dOxxx | vila: although that does usually have some trouble with conflicts merging from trunk due to its own config.py changes | 22:03 |
| vila | dOxxx: that seems to be the good workflow... but you can also try to do such a fix in the lowest branch and merge up instead, that should create *less* conflicts | 22:07 |
| vila | dOxxx: kind of daggyfix, you fix the bug at its first occurrence (the oldest branch) | 22:07 |
| vila | dOxxx: bzr should then recognize some changes as already taken into account and merge only the new ones | 22:08 |
| dOxxx | vila: how do I avoid the branch config.py changes merging into trunk's? | 22:09 |
| DanielCordeiro | Thanks for the link to the bug report, dash. | 22:09 |
| knittl | knitpack != format 2a? | 22:10 |
| fullermd | Correct. | 22:10 |
| vila | dOxxx: you can't at the first merge, but the subsequent merges should respect what you decided at the first merge | 22:10 |
| knittl | k, thanks | 22:11 |
| knittl | does anybody have an bzr-svn project at hand? | 22:11 |
| knittl | oh wait. i have myself | 22:11 |
| knittl | :d | 22:11 |
| vila | dOxxx: should I expect the same amount of time to create the other installers or are there some components reused ? | 22:16 |
| dOxxx | vila: there is no re-use of components between branches of the installer except what you installed by hand | 22:18 |
| vila | dOxxx: ok, makes sense, was just trying to estimate if I will be able to build another one before falling asleep... | 22:19 |
| dOxxx | vila: so if you want to build 2.3b1, you'll need to get the 2.3 branch and do the fetch-externals & build thing again | 22:19 |
| dOxxx | vila: theoretically, you should be able to "python fetch-externals.py -p && python build.py" in the branch and let it run | 22:20 |
| vila | dOxxx: yup | 22:20 |
| vila | dOxxx: qt just finished compiling | 22:20 |
| dOxxx | vila: ooh ouch | 22:20 |
| vila | hu ho compile error in subvertpy | 22:21 |
| dOxxx | vila: yeah I get errors and warnings from sphinx too | 22:21 |
| dOxxx | vila: hmmm | 22:21 |
| dOxxx | vila: then I guess that subvertpy 0.7.3.1 still doesn't include the correct fix. | 22:21 |
| vila | dOxxx: meh, but you were able to compile it for 10.6 right ? | 22:22 |
| dOxxx | yes, it's specifically a problem with svn 1.5 that's installed on OSX 10.5 | 22:22 |
| vila | http://paste.ubuntu.com/499341 | 22:23 |
| dOxxx | vila: try changing the subvertpy block in config.py to this: http://pastebin.com/dmkxtfNe | 22:24 |
| vila | dOxxx: I didn't install svn at all should I ? | 22:24 |
| dOxxx | oh hmm | 22:24 |
| dOxxx | no | 22:24 |
| dOxxx | it's already installed | 22:24 |
| dOxxx | that's a different error | 22:24 |
| dOxxx | from what I recall | 22:24 |
| dOxxx | try using the config block I pasted above | 22:24 |
| dOxxx | that uses the specific revision that jelmer fixed the bug in for me | 22:24 |
| dOxxx | there may be other changes since then which are included in 0.7.3.1 that are breaking it | 22:25 |
| dOxxx | you'll need to use "python fetch-externals.py -p" after you've changed the config | 22:25 |
| vila | ok, done, I had to ctrl-C the build, any problem with at ? | 22:26 |
| dOxxx | nope | 22:26 |
| vila | k | 22:26 |
| dOxxx | just run build.py again | 22:26 |
| dOxxx | it used to start from scratch but that was such a pain in the ass, I made it preserve the build results and added an explicit clean command | 22:27 |
| vila | it seems to re-run a lot of sphinx related stuff though ;) | 22:28 |
| vila | but as long as it doesn't recompile qt, I'll be happy :) | 22:29 |
| vila | dOxxx: hmm, back to fetch-externals, I previously missed the 'branch' part (manual copy/paste doesn't work well ;-/) | 22:32 |
| dOxxx | vila: did fetch-externals not give you an error message the first time? | 22:33 |
| vila | dOxxx: it says: revno mismatch in subvertpy, expected 2219 but was 103 | 22:33 |
| vila | dOxxx: no it didn't | 22:33 |
| dOxxx | vila: uh, add the -u option to fetch-externals. | 22:33 |
| dOxxx | vila: fetch-externals could do with some smarts about when and what it needs to update/download. :( | 22:33 |
| vila | argh, not a branch %2bBranch, blah blah, propably need an already resolved url | 22:34 |
| dOxxx | that used to work, I don't know what it doesn't anymore | 22:34 |
| dOxxx | I think lp:subvertpy used to redirect to jelmer's repo on samba.org but not anymore | 22:35 |
| dOxxx | I ran into the same problem yesterday and I had to use the samba http URL directly | 22:35 |
| vila | dOxxx: or a lp bug | 22:35 |
| dOxxx | vila: I've updated lp:bzr-mac-installers/trunk to add /usr/texbin to the PATH in build.py so that sphinx can find pdflatex. I'm going to merge it across to the other branches now. | 22:37 |
| vila | dOxxx: works with the http@samba url | 22:38 |
| dOxxx | k | 22:38 |
| Crshman_ | How can I tell who made what change in a bzr diff? | 22:42 |
| dash | Crshman_: 'bzr blame' | 22:43 |
| Crshman_ | what about removed lines that are no longer in the file? | 22:43 |
| vila | dOxxx: woohoo build succeeded ! | 22:46 |
| dOxxx | vila: awesome! | 22:46 |
| vila | dOxxx: congrats for all your hard work ! | 22:46 |
| dOxxx | vila: but now does the installed product work? ;) | 22:47 |
| vila | trying | 22:47 |
| dOxxx | vila: btw I've merged the pdflatex PATH fix into 2.2 and 2.3 branches, the 2.1 branch is somewhat out of date so there's a lot more to merge. I'm somewhat reluctant to do that now until we decide that we need an installer for 2.1 | 22:48 |
| vila | dOxxx: I'm fine with no installers for 2.1.3 and 2.0.6 but I thought you already did one ? | 22:49 |
| dOxxx | yeah, it uses the downloaded pdf docs | 22:49 |
| * maxb wonders whether we *really* need a special postinst script in our PPA packages to tidy up after broken bzr-beta-ppa packages in the 1.6rc era | 22:49 | |
| maxb | poolie: You around? ^^^ | 22:49 |
| vila | dOxxx: by the way, it would be nice if we can create some shortcut to launch bzr-explorer *without* needing access to Terminal... | 22:51 |
| dOxxx | vila: it would. that needs a .app bundle, and I think there's a bug on the bzr-mac-installers lp project with one that somebody assembled. I just haven't investigated any further to see what's necessary to integrate it into the installer build. | 22:53 |
| vila | maxb: I don't think we still need them except for very old releases for people doing a very late upgrade ??? | 22:53 |
| dOxxx | vila: I think it also suffers from a problem where there might be password prompts in the console when using bzr-explorer but that wouldn't be visible with a .app bundle | 22:54 |
| vila | dOxxx: I don't think so, the only remaining case that I can think of is related to ssh on windows but that shouldn't be a problem on OSX, the provided ssh agent (wait it *is* provided right ?) works quite well for me | 22:55 |
| vila | dOxxx: I had to switch to a different user to test, *my* setup can't use the just-installed bzr without to much tweaks | 22:56 |
| vila | dOxxx: works | 22:58 |
| dOxxx | vila: it works? woohoo! | 22:58 |
| maxb | vila: The key thing here is that the bug was only in 1.6beta packages ever, so presumably only ever from the bzr-beta-ppa | 22:58 |
| vila | maxb: then shoot | 22:59 |
| vila | dOxxx: so I should rename the img and sign it right ? | 23:02 |
| vila | dOxxx: or is there a script for that ? | 23:02 |
| dOxxx | no script for that. rename it to include "OSX-10.5" in the name like I've done for the 10.6 images | 23:06 |
| dOxxx | then gpg -ba to sign it | 23:06 |
| vila | dOxxx: I need so start my Ubuntu vm for that :-) :-/ | 23:07 |
| vila | or copy it elsewhere instead | 23:07 |
| dOxxx | vila: ah bummer | 23:07 |
| dOxxx | vila: I plan to make the build produce the correct dmg filename according to the OS version | 23:08 |
| dOxxx | vila: however I don't think I can help you with the signing problem :) | 23:08 |
| vila | done :) | 23:08 |
| poolie_ | hello vila! | 23:08 |
| vila | poolie_: hey ! | 23:08 |
| poolie_ | you're up late | 23:08 |
| vila | poolie_: no no, you don't have to go back to sleep :) | 23:08 |
| poolie_ | :) | 23:09 |
| vila | poolie_: yeah, helping dOxxx building the OSX 10.5 installers | 23:09 |
| dOxxx | with vila able to build the 10.5 installers, we can probably get them done pretty soon after the source release, barring any problems with plugin versions. | 23:11 |
| vila | dOxxx: uploading | 23:12 |
| maxb | *right*, finally finished unpicking the status of the ppa hardy branch | 23:13 |
| vila | maxb: targeting the bzr-beta-ppa right ? | 23:15 |
| vila | maxb: will there be a point that we can reuse for the 2.0.6 SRU ? | 23:15 |
| vila | dOxxx: pushed a branch with my tweaks, do you want a merge proposal or will you just pick the rights bits ? | 23:17 |
| dOxxx | vila: ehh I'll just merge it myself, what's the branch name? | 23:17 |
| knittl | is there something like an inventory_id? | 23:17 |
| vila | dOxxx: lp:~vila/bzr-mac-installers/tweaks-for-10.5 | 23:18 |
| dOxxx | and that was for 2.2? | 23:18 |
| vila | dOxxx: yes | 23:18 |
| dOxxx | k | 23:18 |
| vila | dOxxx: sry, I jsut realized I should have specified that in the branch name, on the other hand... there is some history in this branch anyway :-D | 23:18 |
| dOxxx | vila: yeah no worries. I'll also merge the appropriate stuff into the 2.3 branch too so that you can build that without futzing. | 23:19 |
| vila | dOxxx: so, for the 2.3 branch, f-e -d -u ? | 23:19 |
| dOxxx | for 2.3 you shouldn't need the -d option, it will just build docs using sphinx | 23:19 |
| vila | dOxxx: oh, ok, I should wait then ? | 23:19 |
| dOxxx | yeah go to bed, we can finish this tomorrow :) | 23:19 |
| vila | errr, I meant -p -u | 23:19 |
| vila | yeah, babune just started eating all the PC CPU anyway ;) | 23:20 |
| dOxxx | nomnomnom? | 23:20 |
| vila | perfmeter for the 4procs/8threads close to 100% yeah, nomnom :) | 23:21 |
| dOxxx | haha | 23:23 |
| vila | dOxxx: one last thing: config.py is really nice, what would be even nicer is a way to output some summary of which versions are used for all the compoenents | 23:24 |
| vila | dOxxx: bzr plugins won't be as precise as what you allow there | 23:24 |
| vila | dOxxx: I don't have a clear definition of what I want but something that will allow us to quickly check/compare the various releases across the platforms | 23:25 |
| dOxxx | vila: I think I understand. I'll give it some though. | 23:25 |
| dOxxx | thought* | 23:25 |
| vila | dOxxx: cool, thanks | 23:25 |
| vila | poolie_: before I quit | 23:26 |
| poolie_ | sure | 23:27 |
| vila | poolie_: I fixed some more bugs on the SRU paths, but I still haven't nominated the bugs (see my mail) | 23:27 |
| poolie_ | that's great, thanks | 23:27 |
| knittl | http://wiki.bazaar.canonical.com/BazaarFormats this page is long outdated, rigtht? no format2a … | 23:28 |
| vila | poolie_: if you could shepard the SRU a bit (at least the maverick one, I think we have more time for the others), that would be nice | 23:28 |
| poolie_ | knittl, probably, deletede | 23:34 |
| poolie_ | vila, ok, sure | 23:34 |
| poolie_ | i'll do the nominations today | 23:34 |
| poolie_ | thanks for pushing on the bugs | 23:34 |
| poolie_ | thanks too for posting about the namespace convention | 23:34 |
| vila | poolie_: great thanks, see my mail, the urls are there ;) | 23:34 |
| knittl | poolie_: deleting does not do any good | 23:35 |
| vila | poolie_: well, not the easiest subject to start open my mouth it seems, rest assured that my intentions were friendly and accept my apologies if I hurted anyone | 23:35 |
| knittl | i've followed many dead links inside the wiki and only got mad at it | 23:35 |
| poolie_ | i deleted it | 23:35 |
| poolie_ | :( | 23:35 |
| poolie_ | vila, i don't think anyone is hurt | 23:36 |
| poolie_ | i hope you're not | 23:36 |
| poolie_ | knittl, in general i'd rather have docs in the docs tree | 23:36 |
| poolie_ | if there are broken links let's clear them up, either in the wiki or by pointing to docs | 23:36 |
| poolie_ | vila, we're just trying to find the best solution together | 23:37 |
| knittl | poolie_: well, that sounds like adding a hint to visit some other site might be a good idea | 23:37 |
| knittl | not to confuse users | 23:38 |
| poolie_ | knittl, where were you looking to end up on this page | 23:38 |
| poolie_ | hi sidnei | 23:38 |
| sidnei | hi! | 23:38 |
| knittl | poolie_: i don't know, found it somewhere, maybe in the wiki, maybe on google | 23:38 |
| knittl | was still in my bookmarks | 23:38 |
| === sidnei is now known as sidnei-dinner | ||
| fullermd | Mmph. Is there a good reason 'tags' doesn't accept a branch as an arg? | 23:40 |
| knittl | that wiki reads like legacy information anyways | 23:40 |
| poolie_ | as i say we're mostly putting docs in to doc.bazaar.canonical.com | 23:40 |
| poolie_ | the wiki could do with a good scrub to remove old information | 23:41 |
| knittl | put a banner on top of every page: this wiki is outdated, please see docs.blah for current docs | 23:42 |
| poolie_ | hm, good idea | 23:46 |
| poolie_ | there are a few pages that are meant to live in the wiki | 23:46 |
| fullermd | Urg. If the pages are really outdated, they otter just be deleted, not enheadered... | 23:47 |
| poolie_ | right | 23:48 |
| knittl | it's lost information though. no historic record | 23:49 |
| knittl | i don't know where to look for past formats now | 23:49 |
| poolie_ | well, i think they'll still be documented in the in-tree docs | 23:49 |
| poolie_ | the docs for our previous releases are available on the doc web site | 23:49 |
| poolie_ | and the wiki is presumably in webarchive.org if you really want to see what we said about formats 2 years ago | 23:50 |
| fullermd | And the wiki still stores the history anyway, neh? | 23:50 |
| knittl | fullermd: not if the page was deleted | 23:51 |
| knittl | and i'm going to bed now. good night! | 23:51 |
| fullermd | Really? | 23:51 |
| * fullermd adds another to his list of reasons wikis are bogus... | 23:51 | |
| fullermd | Wiki: Just like a VCS, but dumber! | 23:52 |
| mwhudson | wikkid!!! | 23:52 |
| mkanat | ISTR some people making a wiki based on a VCS. | 23:52 |
| mkanat | Would be possible if your VCS was fast enough. | 23:52 |
| knittl | fullermd: yes, it's pretty much like a CVS ,v file. if you delete it, history is gone too | 23:53 |
| fullermd | Well, sure, but you don't delete RCS files (unless you intend to have that effect), you just Attic'ize 'em. | 23:54 |
| cheater99 | hi | 23:58 |
| cheater99 | i am thinking about using bzr or git or hg for my new project | 23:58 |
| cheater99 | what should i be using? | 23:58 |
| cheater99 | also: why is bzr better than git? | 23:58 |
| dash | bzr. duh. | 23:58 |
| fullermd | bzr. Or git. Or hg. | 23:58 |
| mkanat | cheater99: There are some things that I like about bzr more than git. | 23:59 |
| dash | cheater99: less crazy UI, more flexible, actually updates svn mergeinfo when interacting with svn :) | 23:59 |
| mkanat | cheater99: I like the fact that it explicitly supports directory and file renames. | 23:59 |
| mkanat | cheater99: Also, I like the fact that it works well on Windows and is easy to install there. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!