| mgz | lifeless: if you kick up in te next few hours and want to look at some subunit things I'll be around | 00:01 |
|---|---|---|
| lifeless | hi | 00:01 |
| lifeless | I'm here | 00:01 |
| lifeless | trunk subunit and testtools are, AFAICT, ready for releases | 00:01 |
| lifeless | Damn, I wanted to grab tres | 00:01 |
| mgz | we didn't explictly change subunit to use the unicode path though right? just relied on the __str__ behaviour now giving utf-8 | 00:08 |
| lifeless | subunit depends on unicide exceptions no | 00:12 |
| lifeless | w | 00:12 |
| lifeless | if someone has it fail, we can say 'your exception isn't serialisable safely, see testtools for helpers, or hey, use testtools | 00:13 |
| johnjosephbachir | hey folks. a developer in my team has been using a branch bound to the server (IE, only using checkout, update, and commit), but also often uses the --local flag on commit and then commits to the server in a batch. she recently experienced a situation where she is missing some local commits, and can't find them in the repo OR her local code. she suspects that this is because she did a pull at some point in bettween local commits and server commits | 00:39 |
| johnjosephbachir | how can we start investigating what happened? i suspect this code is hiding out in one of the "hidden" branches that bazaar keeps around... i can't remember the name of that concept | 00:40 |
| johnjosephbachir | i suppose this is a mailing list -grade question | 00:48 |
| johnjosephbachir | fwiw, seems like i had the same problem as this guy http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx | 01:14 |
| spiv | johnjosephbachir: sounds strange | 01:16 |
| spiv | johnjosephbachir: it would be good to have a bug report with as many details as possible | 01:16 |
| johnjosephbachir | alas i probably don't have the time to do that | 01:16 |
| === mnepton is now known as mneptok | ||
| lifeless | morn morn | 01:17 |
| mgz | ah, lifeless back again | 01:26 |
| mgz | see my name in lights on planet debian, thanks ;) | 01:26 |
| johnjosephbachir | spiv: thanks-- code saved! | 01:28 |
| lifeless | mgz: :) | 01:38 |
| lifeless | mgz: and on planet.python.org | 01:38 |
| spiv | johnjosephbachir: great! | 01:38 |
| mgz | so, my subunit question boils down to if we want to something before release about: | 01:38 |
| mgz | http://bazaar.launchpad.net/~subunit/subunit/trunk/revision/125/python/subunit/__init__.py | 01:38 |
| mgz | your check-and-mention testtools suggestion sounds fine to me | 01:38 |
| poolie | hello mgz, spiv, lifeless | 01:38 |
| mgz | something like getattr(self, "_exc_info_to_unicode", None), then fall back to self._exc_info_to_string and complain if it's not ascii | 01:38 |
| mgz | hey poolie | 01:38 |
| lifeless | mgz: we could derive from testtools | 01:38 |
| mgz | is a goal to avoid an explict testtools depedency though? | 01:38 |
| lifeless | no | 01:38 |
| lifeless | it has an explicit one already | 01:38 |
| mgz | okay, in which case, just using the testtools class and maybe a version check would do | 01:38 |
| lifeless | -garh | 01:39 |
| lifeless | mgz: see my last commit to testtools :P | 01:41 |
| mgz | ha! | 01:42 |
| mgz | my fault too, didn't get as far as testing attempt 2 on py2k | 01:43 |
| mgz | *3 | 01:43 |
| aaron01 | I'm trying to use bzr import on a tarball, but I get a 'tree is malformed' error. Any ideas? | 01:49 |
| mgz | maybe something like: http://paste.ubuntu.com/458088/ | 01:51 |
| lifeless | mgz: sorry I had already pushed :P | 01:59 |
| mgz | ah! I'll pull. | 01:59 |
| lifeless | aaron01: please file a bug? Not sure what is wrong there. | 01:59 |
| aaron01 | Seems like adding a top level dir (that will be stripped) fixes the problem | 02:00 |
| aaron01 | but now getting it trying to import that dir into another branch :( | 02:00 |
| aaron01 | s/it/the same error | 02:00 |
| poolie | spiv does bug 600636 | 02:00 |
| ubot5 | Launchpad bug 600636 in Bazaar "bzr ci crashes after a bzr break-lock (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/600636 | 02:00 |
| poolie | look to you like just another issue of a connection drop causing "too many concurrent requests" | 02:00 |
| poolie | it does to me | 02:01 |
| jam | lifeless, poolie: do you know why when submitting a bug with bzr, you get the option to set the priority, etc? | 02:01 |
| jam | I don't see that for Meliae, or Loggerhead, or fastimport or any other project, and I miss it | 02:01 |
| mgz | okay, yup, your rev is a less borked version of the same | 02:01 |
| jam | anyway, back to family time, just curious if it was an option that needs setting somewhere | 02:01 |
| poolie | jam it's something to do with permissions | 02:03 |
| poolie | i'm not sure which thing controls | 02:03 |
| poolie | it | 02:03 |
| poolie | perhaps whether you're in the bug control team | 02:03 |
| poolie | ask in #launcphad | 02:04 |
| spiv | poolie: oh wow | 02:04 |
| spiv | poolie: the commit code path was meant to be fixed ages ago. Interesting! | 02:04 |
| poolie | mm? | 02:04 |
| spiv | It does seem plausible that a connection drop is involved. | 02:05 |
| spiv | Hmm, likely even. | 02:05 |
| poolie | there is a message about it | 02:05 |
| spiv | Oh right. | 02:06 |
| lifeless | jam: I think its driver permission | 02:07 |
| lifeless | most things don't have driver set | 02:07 |
| mkanat | poolie: Hey hey, do you have a second? | 04:32 |
| poolie | hi, i do | 04:33 |
| mkanat | poolie: Great, let me remember what I needed to chat with you about.... | 04:33 |
| mkanat | poolie: Oh, right. So, it sounds a bit from the discussion with Francis and the way things are gong on the list that I am in fact actually sort of going to end up owning loggerhead. Is that right? | 04:34 |
| lifeless | \o/ | 04:34 |
| mkanat | poolie: I mean, with oversight from you and the bzr team. | 04:34 |
| poolie | that sounds good to me if it's ok withy ou | 04:34 |
| mkanat | poolie: Yeah, it's totally okay with me, but it will probably require an adjustment in the way that the contract works. | 04:34 |
| mkanat | poolie: Should I discuss that with you first and then Francis, or should Jolie just discuss it with Francis? | 04:36 |
| poolie | with me first | 04:37 |
| poolie | it's up to you and jolie which of you wants to be involved from your side | 04:37 |
| poolie | this is because it's expanding the scope of your work? | 04:37 |
| poolie | let's talk in private | 04:37 |
| mkanat | Okay. | 04:37 |
| lifeless | poolie: I have a request; please document in doc/developers/testing.txt how to make bzr selftest run on a ramdisk. | 04:47 |
| lifeless | poolie: I think many folk would benefit. | 04:47 |
| lifeless | I can file that as a bug if you would like. | 04:48 |
| poolie | no i'll just do it | 04:50 |
| lifeless | thanks! | 04:52 |
| lifeless | poolie: http://pastebin.com/rULLkF29 | 07:17 |
| lifeless | vila: --config please, not --conf | 07:24 |
| lifeless | --conf is a strange abbreviation | 07:25 |
| lifeless | c = config.LockableConfig(lambda : location) | 07:25 |
| lifeless | reads really strangely | 07:25 |
| lifeless | perhaps the LockableConfig constructor should be different | 07:25 |
| lifeless | vila: I *really* wish you would not mix changes to imports with test changes | 07:27 |
| lifeless | vila: it makes the patch about 4 times harder to review. | 07:27 |
| vila | lifeless: I don't want to break the chain of constructors, I can add a def get_filename if you prefer | 07:27 |
| lifeless | vila: its like a massive whitespace change *just because* | 07:28 |
| lifeless | vila: and as far as I can tell no actual changes to many tests. | 07:28 |
| lifeless | vila: so I'm going to push this back to you | 07:29 |
| vila | lifeless: yeah, jam complains about that too, but we won't get the import problem addressed until 1) we all stop importing symbols, 2) we fix all remaining wrong imports | 07:29 |
| lifeless | get me a diff that shows the *actual* test changes, and I'll happily review it. | 07:29 |
| lifeless | vila: be tolerant of what you accept, and strict in what you output - wonderful IETF principle. | 07:29 |
| lifeless | vila: it applies here - accept difference in files you are editing. Make what you write be up to scratch. | 07:30 |
| vila | lifeless: this one goes both ways :) That was my reply to jam :-D | 07:30 |
| lifeless | vila: I don't think you're considering the impact on the reviewer enough. | 07:30 |
| lifeless | We're here to think about the change, about what it is meant to accomplish, and we're having to go line by line through noise. | 07:30 |
| vila | I do, but the alternative is to postpone these fixes endlessly | 07:30 |
| lifeless | +1 | 07:30 |
| lifeless | vila: 'the import problem' is approximately 0% of our bugs. | 07:32 |
| lifeless | vila: a bad review can easily let a new bug in, or fail to see a structural issue. | 07:32 |
| lifeless | vila: I really want you to think about the relative costs and merits here. | 07:32 |
| poolie | vila i think lifeless has a point there | 07:33 |
| vila | I really wish to feel less alone to realize that our actual tests serve as examples, get copy/pasted and decrease the overall quality which as an impact on our productivity because it makes them harder to modify :-( | 07:34 |
| poolie | i think i agree with you on that too :) | 07:35 |
| poolie | does importing the module make much difference in tests? | 07:36 |
| poolie | presumably we don't care much about laziness? | 07:36 |
| poolie | or is it just for the sake of consistency and examples? | 07:36 |
| lifeless | vila: I really don't see that the changes you're making make stuff easier or harder to modify. | 07:37 |
| lifeless | Just different. | 07:37 |
| lifeless | not importing symbols has a specific benefit when we want to use lazy_import, but that does not apply to tests [perhaps it should, but the general import in tests is TestCase*, which can't be lazy imported anyway) | 07:38 |
| vila | being consistent makes it easier to move code from one file to another or even inside the same file sometimes | 07:41 |
| lifeless | I don't like doing 'from bzrlib import trace' in tests, because in tests you normally want a test object of the class, and that can't be called trace, so it has to be 'from bzrlib import trace as _mod_trace', and thats ugly. | 07:42 |
| vila | not being consistent means you never know where a symbol is coming from and in this particular case prefixing with the module makes it 4 times easier to read | 07:42 |
| vila | lifeless: <1% of the cases | 07:43 |
| lifeless | Look, there are two things here. | 07:44 |
| lifeless | a) when we do cleanups | 07:44 |
| lifeless | b) whether they are better or worse. | 07:44 |
| lifeless | Put (b) to the side; I'm tired, have a different opinion anyway, and *I was not complaining about b before*. | 07:44 |
| lifeless | I, and John, are both complaining about mixing code changes with cleanups-to-code. | 07:45 |
| lifeless | if everytime you touch a module, you want to put in a separate branch to clean it up, it would not take much more-or-less of your time | 07:46 |
| lifeless | it could be reviewed totally separately to the *actual thing* you are working on. | 07:46 |
| lifeless | and your colleagues wouldn't be feeling that reviewing your changes is hard | 07:47 |
| Outlander | hi | 07:52 |
| Outlander | what's the best way to convert cvs repo to bzr? appears to be a few different ways? | 07:52 |
| vila | lifeless: 1) I got vaccines yesterday and that makes me grumpy 2) I've made separate branches in the past for cleanups and that raised discussions anyway so I grew tired of doing that on top of feeling alone cleaning this up 3) the import thing sounds like spurious spaces changes, yet, reviews are either a) not pushed back when they introduce them b) pushed back when they are VWS | 07:55 |
| vila | the end result is that spaces are still there and the problem is not addressed | 07:55 |
| maxb | Outlander: what are the ways? I only know of cvs2bzr | 07:56 |
| vila | the imports are more important than spaces and there has been associated problems with them (I encounter one when trying to monkey-patch transport.get_transport, another one was people were importing symbols already imported from another module which broke when the symbol went to a different module or were fixed to not being imported as a symbol) | 07:57 |
| lifeless | on whitespace - when it gets in the way of review, it gets pushback from me; when it doesn't, it doesn't. | 07:58 |
| lifeless | the changes here are big fraction of the total patch. | 07:58 |
| lifeless | its an 800 line patch, for a 200 line change, or something like that. | 07:59 |
| * vila tells his vaccines that they don't have to make it grumpy and come in the way to progress | 07:59 | |
| vila | lifeless: that's unfair, please check | 07:59 |
| lifeless | I did | 07:59 |
| lifeless | 822 lines of diff | 08:00 |
| vila | 1) s/file/infile/ trivial to filter on reading | 08:00 |
| lifeless | 542->669 are the actual new tests (I think, my eyes are glazing over so I may be missing other semantic changes) | 08:00 |
| vila | add 426-> 448 | 08:01 |
| lifeless | and 300 lines at the start; so 420/822 | 08:01 |
| lifeless | ok, 440/822 | 08:01 |
| lifeless | and thats exactly my point | 08:01 |
| lifeless | in all the excess I couldn't see an important part of the change. | 08:01 |
| vila | so, basically, you're saying that you should not cleanup, but you did so in many proposals and I supported that because it's part of keeping the code in good health, 324->333 for example is not required but the cleanup version make it easier to see what is happening here (and avoid useless calls) | 08:04 |
| spiv | He's saying: consider the audience (which is good advice for any kind of writing) | 08:05 |
| vila | So where is the limit on cleanups ? | 08:05 |
| lifeless | There is a balance; I may have gotten it wrong in the past, and for that I'm sorry. | 08:05 |
| vila | I'm sorry too but that doesn't address the problem :) Let's put emotions aside and focus on solutions | 08:06 |
| spiv | If you make a diff that seems unnecessarily hard for a reviewer to review, expect them to be a bit grumpy about it. | 08:06 |
| vila | yup, I was expecting that. I was hoping that people were rejoicing about cleanups progressing instead of staling though :) | 08:07 |
| spiv | So either try to make easier-to-review diffs, or perhaps take other steps to ease the burden, e.g. point out the lines of the diff with the interesting changes. | 08:07 |
| vila | I (and I think others) have been daunted in many occasions... | 08:08 |
| lifeless | vila: There are two sorts of cleanups here: code clarity ones, and 'import style'. The former I rejoice at, the latter are entirely mechanical, and have caused bugs in the paste. I do not rejoice at those. | 08:08 |
| spiv | There's no fixed limit, it really depends on the details of each patch. | 08:08 |
| vila | which bugs ? | 08:08 |
| lifeless | we've had import cleanups break due to shadowed names | 08:09 |
| lifeless | they are not risk free. | 08:09 |
| vila | true, | 08:09 |
| lifeless | They are also not reviewer time free. | 08:09 |
| spiv | (e.g. a 90% cleanups patch might be fine if the total patch is only 10 lines long :) | 08:09 |
| vila | they are not time free for me either, but some tests are so unclear that I spend time deciphering them too | 08:10 |
| lifeless | I'm saying that the cost and benefit need to be weighed; neither side is 0, and neither side is aleph-0 | 08:11 |
| lifeless | or aleph-1 | 08:11 |
| vila | on the overall, I consider that importing symbols is easier to *write* but harder to *read* and leads to more symbols staying around after they are not being used | 08:11 |
| vila | and since code is more often read than written, the weight is more important too | 08:12 |
| lifeless | vila: I don't see why symbols that aren't used is a maintenance problem; what does it make non-trivial that is trivial otherwise ? | 08:12 |
| vila | review is *part* of the readers but not the only part | 08:12 |
| lifeless | (I like a lean import list btw, don't get me wrong) | 08:12 |
| vila | false positives when grepping or even thinking about the module | 08:12 |
| lifeless | vila: something you can do in cases like this is filter the diff | 08:12 |
| lifeless | and only show the bits that are relevant | 08:13 |
| lifeless | andrew has done that in the past and its very nice | 08:13 |
| vila | lifeless: ha, nice one | 08:13 |
| lifeless | vila: but really, it all comes down to what has been said before | 08:13 |
| lifeless | consider what the people you ask to review are going to be reading. | 08:13 |
| lifeless | you know what a long repetitive patch is like to review. | 08:14 |
| vila | the problem with that is that we tend to *never* address some problems | 08:15 |
| vila | and we also said before that we are supposed to clean up things when we modify close enough parts | 08:15 |
| lifeless | I've got nothing more to offer. | 08:16 |
| lifeless | I'm sad. | 08:16 |
| vila | so, hmm, looks like I will get back to the two branches approach but there was some concerns about polluting the active review queue with such cleanups too | 08:17 |
| vila | and landing them without review was also frowned upon | 08:17 |
| lifeless | I think that that concern is a reflection of this | 08:17 |
| spiv | vila: so, my opinion is that opportunistic cleanups of nearby code is fine, but not at the cost of significantly worse diffs | 08:17 |
| vila | lifeless: I don't want to make you sad because I | 08:17 |
| vila | lifeless: I don't want to make you sad because I'm cleaning things up which should make you happy, that's counter-productive :) | 08:18 |
| spiv | vila: If it e.g. makes a smallish diff large and repetitive I'd rather get two separate diffs. | 08:18 |
| vila | so, how about a cleanup branch as a pre-requisite that gets automatically approved if not vetoed when the main branch is approved ? | 08:19 |
| spiv | Um, | 08:19 |
| vila | more work, but I'm ready to do it if it means we progress here | 08:20 |
| spiv | Perhaps that's ok, although it seems like a solution to a problem we don't have yet? | 08:20 |
| spiv | Is it really that hard to get approval for cleanup-only branches? | 08:20 |
| vila | we have a problem: our code base is not consistent | 08:20 |
| spiv | I haven't found that to be the case, but I also have not tried to land a large one recently. | 08:20 |
| spiv | To be clear: a pre-req branch sounds fine to me | 08:21 |
| spiv | It's the "automatically approved" part that I'm unsure about. | 08:21 |
| spiv | Also, I think we still have the notion that an unreviewed branch can "time out" and just be landed, although we don't exercise it very often. | 08:22 |
| spiv | Which would seem to cover that case (but I would hope we still do not exercise it very often). | 08:22 |
| vila | spiv: I think that's the crux of the problem: do we want cleanups, do we want to review them ? | 08:28 |
| spiv | Yes, and yes. | 08:30 |
| spiv | In my opinion :) | 08:30 |
| lifeless | I might let poolie have his office back. | 08:31 |
| vila | then it boils down to not mixing them up with actual fixes | 08:31 |
| spiv | The review will often be easy: read the explanation in the cover letter, and then eyeball the diff to feel secure that it is fine. | 08:31 |
| spiv | Right. | 08:31 |
| lifeless | vila: thats all I asked for | 08:32 |
| vila | lifeless: good, I'll try harder then | 08:33 |
| vila | lifeless: and sorry for starting grumpy on this subject | 08:40 |
| mneptok | FINISH HIM! | 08:44 |
| mneptok | (sorry. couldn't resist.) | 08:44 |
| spm | we hadn't noticed :-) | 08:45 |
| mneptok | i love you, too :) | 08:45 |
| spm | mneptok: so how's the new job going since you abandoned us all? | 08:45 |
| lifeless | mneptok: cavemen in mountain fortresses shouldn't throw spears. | 08:48 |
| mneptok | spm: it goes well. busy as hell. long days. but quite rewarding. | 08:49 |
| spm | excellent! | 08:49 |
| mneptok | lifeless: i'm touched you noticed my brow-ridge. | 08:49 |
| spm | touché! | 08:50 |
| lifeless | mneptok: I've seen the photos | 08:50 |
| lifeless | I went blind. | 08:50 |
| lifeless | :) | 08:50 |
| mneptok | lifeless: you know, i recently got another photo from the same day the "mnep the gigolo" photo was taken. this one onvolves a camisole, a top hat, and clown shoes. | 08:51 |
| lifeless | _LOL_ | 08:51 |
| mneptok | oh, and grandma underwear | 08:52 |
| lifeless | this is a family rated channel | 08:52 |
| mneptok | grandma's part of the family. | 08:52 |
| mneptok | and until i finish chewing through this leash, so am i. ;) | 08:53 |
| mneptok | /m/m lifeless http://mneptok.com/kvf-clownshoes.jpg | 08:55 |
| mneptok | gah | 08:55 |
| mneptok | tab complete fail | 08:55 |
| mneptok | ah well, don't click that if you're under 18 or value your sanity | 08:55 |
| spm | I've menepolo'd before. how bad could this be..... | 08:56 |
| spm | AAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaa | 08:56 |
| * spm reaffirms the desire to NOT click on any menptok.com urls to images again | 08:57 | |
| mneptok | am i not hot? | 08:58 |
| spm | um... | 08:59 |
| mneptok | 01:45 < mneptok> i love you, too :) | 09:00 |
| spm | hahahaha | 09:00 |
| * mneptok rm's before Google decides to index that | 09:06 | |
| spm | Google. Knows. All. Google. Sees. All. | 09:08 |
| poolie | that's exactly what stephenconroy needs to save us from | 09:09 |
| poolie | apparently | 09:09 |
| mneptok | Bing knows and sees all, but the Executive Oversight Committee For Strategic Use Of Internet Data And Applicability For Increased Market Penetration can't get the data on their Zunes. | 09:11 |
| spm | EOCFSUOIDAAFIMP ? | 09:12 |
| mneptok | gesundheit | 09:12 |
| spm | thank you | 09:13 |
| === FryGuy_ is now known as FryGuy- | ||
| === lifeless_ is now known as lifeless | ||
| === lifeless_ is now known as lifeless | ||
| lifeless | poolie_: your _ is showing. | 10:51 |
| poolie_ | heh | 10:57 |
| poolie_ | as nethack says "you are being punished" | 10:57 |
| poolie_ | i think that's actually a _o | 10:58 |
| lifeless | yah ball n chain | 11:06 |
| === lifeless_ is now known as lifeless | ||
| jave | hello | 11:34 |
| === lifeless_ is now known as lifeless | ||
| === lifeless_ is now known as lifeless | ||
| jave | I'm trying to set up an Hudson instance to build emacs from bzr | 12:19 |
| jave | the Hudson bzr plugni tries to do this: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk /var/lib/hudson/jobs/emacs-trunk/workspace | 12:19 |
| jave | but its really slow | 12:19 |
| jelmer | jave, is there any reason it needs the full history | 12:20 |
| lifeless | jave: do 'bzr init-repo /var/lib/hudson/jobs | 12:20 |
| jave | well, I want it to be compatible with the hudson-bzr plugin, will it work if I do it by hand? | 12:21 |
| lifeless | yes | 12:21 |
| jave | lifeless: stuff that has nothing to do with bzr lies in /var/lib/hudson/jobs | 12:21 |
| lifeless | jave: you're right | 12:22 |
| lifeless | add --no-trees to the command | 12:22 |
| jave | hmm ok | 12:22 |
| lifeless | thought that may cause it to not work | 12:22 |
| jave | ok | 12:22 |
| lifeless | I'd really just do what I initially suggested | 12:22 |
| jave | ok, but what happens if I have different jobs with different bzr urls? | 12:23 |
| jave | I think I will need special workspace configuration for hudson | 12:27 |
| lifeless | no | 12:27 |
| lifeless | honestly | 12:27 |
| lifeless | just init-repo at the jobs level | 12:27 |
| lifeless | its what everyone does. | 12:27 |
| jave | ok | 12:30 |
| === khmarbaise_ is now known as khmarbaise | ||
| === lifeless_ is now known as lifeless | ||
| * bialix waves at GaryvdM | 14:28 | |
| GaryvdM | Hi bialix | 14:29 |
| bialix | Hey Gary! | 14:29 |
| bialix | Thank you for doing release | 14:29 |
| GaryvdM | Sure - Want it to get into the win installers | 14:30 |
| bialix | yeah :-) | 14:30 |
| bialix | how's footbal 'raound you? | 14:30 |
| bialix | how's football around you? | 14:30 |
| GaryvdM | Ah - cool. I don't watch it much | 14:31 |
| GaryvdM | Do you watch it? | 14:31 |
| bialix | GaryvdM: sometimes. last weeks was a crunch for me :-/ | 14:32 |
| bialix | GaryvdM: I'm planning to be on vacation in second half of July. And we need to release 0.19 final till August for Maverick. It means I have only 2 weeks for any QBzr development | 14:35 |
| bialix | GaryvdM: do you have any specific things in mind that I should look at? | 14:36 |
| GaryvdM | bialix: I'm also planing on taking a weeks leave soon. | 14:36 |
| GaryvdM | bialix: It would be cool if they were in sync | 14:37 |
| bialix | so maybe we should release 0.19 final till our vacations? | 14:37 |
| GaryvdM | bialix: I want to try get at least qcat and qdiff to have a toolbar like qannotate | 14:37 |
| GaryvdM | for 0.19 | 14:38 |
| bialix | hmmm | 14:38 |
| bialix | yep, it would be cool | 14:38 |
| bialix | I will try to look at qlog labels again | 14:38 |
| bialix | we have one special case here: bzr qlog colo: | 14:38 |
| GaryvdM | I've been chipping away at the threads branch. | 14:39 |
| bialix | I want to see labels as colo:trunk, today it's shown as colo:/trunk | 14:39 |
| bialix | chip away? what do you mean? | 14:39 |
| GaryvdM | bialix: It's a saying - If you want to cut through a log, you chip away at it with a axe | 14:41 |
| GaryvdM | bialix: work on it in small chunks.. | 14:42 |
| bialix | that means you have slow progress, correct? | 14:44 |
| GaryvdM | bialix: slow, but steady | 14:45 |
| jam | morning GaryvdM, bialix, and vila | 14:46 |
| vila | mornign jam | 14:46 |
| GaryvdM | Hi jam | 14:46 |
| bialix | heya jam! and bonjour vila! | 14:46 |
| vila | bialix: privet :) | 14:46 |
| bialix | :-D | 14:46 |
| vila | bialix: brasil - netherlands should be a nice one ;-) | 14:47 |
| GaryvdM | Hey vila | 14:47 |
| bialix | vila: yep, I've heard comments and prognosis | 14:47 |
| GaryvdM | jam: lp:~garyvdm/bzr-windows-installers/maybe | 14:48 |
| GaryvdM | jam: I committed rev 119 with --author "John ... - I hope you don't mind | 14:48 |
| GaryvdM | jam: Please could you do a quick review of rev 120 | 14:49 |
| * vila feel depressed, 2.1.0 and 2.1.1 have a test failure: bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures does that ring anyone bell ? | 14:49 | |
| vila | and 2.1.2 too | 14:50 |
| GaryvdM | jam: I'm now stuck with a can't find zlib.h build error. Maybe I need to adjust so env var. | 14:51 |
| jam | GaryvdM: well, for 2.2 we shouldn't need it at all | 14:51 |
| jam | maybe setup.py needs updating? | 14:51 |
| jam | or something is importing it that shouldn't be | 14:51 |
| jam | I thought mgz tracked those down | 14:51 |
| jam | vila: I haven't seen it before | 14:52 |
| vila | jam: me neither 8-( | 14:52 |
| vila | add 2.2 | 14:52 |
| GaryvdM | jam: building _chk_map_pyx.c | 14:52 |
| jam | GaryvdM: other than not needing zlib.h, the original goal was that the build script would download zlib and put it in the path | 14:53 |
| vila | jam: pass in trunk at least (which kind of rules out a weird setup here) | 14:54 |
| jam | GaryvdM: so the issue | 14:54 |
| jam | is again that igc's new code doesn't grab a tag | 14:54 |
| jam | it grabs the latest in a branch | 14:54 |
| jam | and lp:bzr/2.2 hasn't been updated | 14:55 |
| GaryvdM | http://pastebin.org/375070 | 14:55 |
| jam | so it is still trying to build old code | 14:55 |
| GaryvdM | jam: Ah - let me try build bzr.dev | 14:55 |
| jam | GaryvdM: _chk_map_pyx.pyx has "cdef extern from 'zlib.h':" | 14:55 |
| jam | which shouldn't be in 2.2b3 | 14:55 |
| jam | GaryvdM: it looks like we need to do more direct work on ian's code | 14:55 |
| jam | and possibly get ahold of him to determine what he had in mind | 14:56 |
| jam | vila: does it fail when tested in isolation (and succeed in bzr.dev in the same case)? | 14:56 |
| vila | yup: ./bzr selftest -s bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures --no-plugins | 14:56 |
| vila | with extensions compiled in all cases (but that shouldn't be relevant) | 14:57 |
| jam | fails here, too.... | 15:00 |
| jam | makes me think it is a test-tools issue | 15:00 |
| vila | jam: forget it, sorry for raising it, unless pqm yelles at you , yeah, ne too | 15:00 |
| jam | vila: len(result.failures) == 1 | 15:01 |
| jam | I have the feeling one testtools considered something a Fail | 15:01 |
| jam | and one considered it an Error | 15:01 |
| vila | definitely raises a bell now that you mention it | 15:01 |
| jam | so I would say the test should become something like | 15:01 |
| jam | assertEqual(1, len(result.errors) + len(result.failures)) | 15:01 |
| jam | with a big: | 15:01 |
| jam | # Testtools sometimes considered this an Error, and sometimes a Failure | 15:02 |
| jam | # so make sure to trap for bothe | 15:02 |
| jam | vila: I seem to remember being worried that relying on a 3rd party tool for the test suite would cause spurious failures and lock-step versioning issues | 15:02 |
| vila | I'm pretty sure lifeless did a patch very close to that | 15:02 |
| jam | total_failures = result.errors + result.failures | 15:03 |
| jam | if self._lock_check_thorough: | 15:03 |
| jam | self.assertLength(1, total_failures) | 15:03 |
| jam | yep | 15:03 |
| jam | in bzr.dev | 15:03 |
| jam | albeit without the snarky comment against testtools | 15:03 |
| vila | hmm, I think I asked for a comment, whatever the content was :) But fater the landing | 15:04 |
| vila | after | 15:04 |
| vila | anyway, we know how to fix it, back to regular schedule | 15:05 |
| jam | vila: feedback on https://code.launchpad.net/~vila/bzr/525571-minimal-lock-bazaar-conf-files-2.1/+merge/29086 | 15:14 |
| * vila holds his breath... | 15:19 | |
| chaosaddict | anyone know what might cause this error message when doing a bzr fast-import? | 15:24 |
| chaosaddict | "bzr: ERROR: The file id "TREE_ROOT" is not present in the tree <bzrlib.inventory.CHKInventory object at 0xa2a610c>." | 15:24 |
| jam | vila: sent to the list | 15:25 |
| jam | sorry, breathe again | 15:25 |
| vila | deep shudder | 15:26 |
| vila | jam: a = AtomicFile() ; a.write(data) ; a.commit() ; a.close() ? | 15:28 |
| jam | vila: well, a = AtomicFile(filename); but yeah, something like that | 15:33 |
| jam | IIRC LocalTransport uses AtomicFile for put() | 15:33 |
| jam | GaryvdM: what else is in the environment that you need to copy? (It seems ok, I just wanted to check) | 15:35 |
| jam | anyone know if the 2.1.2 installers are looking good? I'm thinking I should extract a nonadmin version | 15:37 |
| GaryvdM | jam: It was failing like this. http://pastebin.org/371858 | 15:38 |
| GaryvdM | jam: I thought it would be easy to just copy the env rather than play wack-a-mole | 15:39 |
| GaryvdM | *easier | 15:40 |
| jam | GaryvdM: so the concern is accidentally having an env var like CFLAGS suddenly change your build (and it starts working/failing surprisingly) | 15:40 |
| jam | however, I probably agree with you | 15:40 |
| jam | I'm fine with just copying | 15:41 |
| jam | given that everything else that builds just uses the existing env vars | 15:41 |
| jam | we just want to *add* ones for tbzr | 15:41 |
| GaryvdM | jam: ok | 15:41 |
| GaryvdM | jam: I think we could maybe extend Project, Plugin, and Application in bazaar_releases.py to include revision specs. | 15:48 |
| GaryvdM | jam How do we allow for differences in revision specs, with out duplicating all other details? | 15:49 |
| GaryvdM | jam: Maybe copy and modify? | 15:50 |
| jam | GaryvdM: what do you mean duplicating all the other details? | 15:50 |
| jam | Are you thinking to have the same code base do multiple builds? | 15:51 |
| GaryvdM | jam: Differences in plugin version between distributions | 15:51 |
| jam | traditionally we just had separate branches for this | 15:51 |
| jam | afaik that isn't planned | 15:51 |
| jam | but I could be wrong | 15:51 |
| jam | I also really don't know the plan for the distribution stuff | 15:51 |
| jam | Certainly I don't really want to debug why Mac OS X has plugin version x, but windows has version y | 15:52 |
| GaryvdM | jam: yes, you can currently do ./build.py bzr-dev or ./build.py bzr-2.2 or just ./build.py for both | 15:52 |
| jam | or even worse, Vista has X, Win7 has Y, and XP has Z | 15:52 |
| GaryvdM | jam in this context, distribution = bazaar major release series. | 15:52 |
| GaryvdM | 2.1, 2.2, dev | 15:53 |
| jam | bad name, then | 15:54 |
| jam | IMO | 15:54 |
| GaryvdM | jam: Agree - lets look a renaming it once we have everything else figured out. | 15:58 |
| jam | GaryvdM: so for that, I would even expect *what* plugins are bundled to be different | 15:58 |
| GaryvdM | "Series" ftw | 15:58 |
| GaryvdM | jam: yes | 15:59 |
| jam | and I would expect the versions to be different at least 50/50. | 15:59 |
| jam | since we have started working on stuff like stable qbzr releases, etc | 15:59 |
| GaryvdM | jam: For me but pdb is unusable with cygwin. I don't see a prompt. The prompt only shows after I've pressed a key. (I see the same thing with bzr uncommit) | 16:14 |
| GaryvdM | jam: Do you maybe know how to fix this? | 16:15 |
| jam | GaryvdM: I don't really know, something is weird on that machine | 16:15 |
| jam | I don't have problems at home | 16:16 |
| GaryvdM | :-| | 16:16 |
| vila | jam: fix with AtomicFile pushed | 16:23 |
| * GaryvdM off to find food. bbl | 16:29 | |
| === jamesh_ is now known as jamesh | ||
| jam | vila: do you still need the intermediate StringIO, rather than just using AtomicFile as the thing you write to? | 16:39 |
| vila | jam: no, fixed | 16:46 |
| jam | vila: approve | 16:46 |
| vila | jam: thanks | 16:46 |
| vila | *now* I will have to take care of test failure :-/ | 16:47 |
| GaryvdM | Yhea - I don't get zlib err on bzr-dev. | 17:06 |
| GaryvdM | I now get this error: http://pastebin.org/375504 | 17:07 |
| GaryvdM | jam: ^ Any ideas? | 17:08 |
| chaosaddict | I'm new to Bazaar, but it seems like it might be useful to be able to use the Bazaar Explorer to get a file at an arbitrary revision number. | 17:09 |
| GaryvdM | chosaddict: Like bzr revert foo -r x | 17:10 |
| GaryvdM | chaosaddict: That was recently added to qlog. | 17:10 |
| GaryvdM | (Bazaar Explorer uses qlog...) | 17:11 |
| chaosaddict | oh cool, thanks. | 17:11 |
| mgz | garyvdm: I think I remember a list message about having to remove the py3k port bits of pyqt | 17:28 |
| GaryvdM | Hi mgz | 17:28 |
| mgz | yeah, by jam, so he's probably the right person to ask. | 17:29 |
| * jam hides | 17:29 | |
| jam | ugh. that terrible stuff | 17:30 |
| jam | I ran into it, did something which seemed to fix it, it broke again, tried something else, etc, etc. | 17:30 |
| jam | GaryvdM: we have this: excludes.append('PyQt4.uic.port_v3') in bzr.dev setup.py | 17:30 |
| jam | which is the only thing that could approximately work | 17:31 |
| GaryvdM | mgz: I can't find the mail. What is the subject? | 17:31 |
| jam | but I ran in to all sorts of hell | 17:31 |
| jam | leaving it out caused one failure, putting it in caused another | 17:31 |
| GaryvdM | Err | 17:31 |
| jam | Check the version of PyQt as well | 17:31 |
| jam | PyQt4.QtCore.qVersion() says 4.6.1 | 17:32 |
| mgz | it's in the middle of Robert's "Python 3" thread, but what jam is saying now will probably help you more | 17:33 |
| jam | QtCore.PYQT_VERSION_STR says 4.7 | 17:33 |
| jam | so it seems to be PyQt4 (4.7) which wraps Qt 4.6.1 | 17:33 |
| GaryvdM | I think that is the qt version. The pyqt version is 4.7 | 17:33 |
| GaryvdM | Er you faster than me | 17:33 |
| jam | this was one-of-those-things that made me stick with python2.5 | 17:33 |
| jam | GaryvdM: the easier solution is to delete that directory from PyQt4 | 17:35 |
| jam | note questions like this: http://www.mentby.com/albert-cervera-i-areny/not-packaging-portv3-into-26-installer.html | 17:35 |
| jam | which are exactly my problem, but no answers | 17:35 |
| GaryvdM | jam: Please can we try moving the file out. You need to do. (admin) | 17:37 |
| jam | GaryvdM: sure, I have to relog | 17:38 |
| jam | though I thought I set the perms to be 'bzr' == Full Control | 17:38 |
| jam | did you check? | 17:38 |
| GaryvdM | No - let me try | 17:39 |
| GaryvdM | jam: Nope - I cant | 17:41 |
| GaryvdM | jam: We could maybe try exclued PyQt4.uic - let me check I we use it | 17:43 |
| GaryvdM | *if | 17:43 |
| jam | GaryvdM: I think we need it | 17:44 |
| GaryvdM | jam: looking at the code, we only use it as a dev tool, in extras/build_ui.py, in both qbzr and bzr-explorer. | 17:45 |
| GaryvdM | jam: The results are commited, so it is not even needed at build | 17:45 |
| mgz | can you exclude build_ui.py from the packaging then? | 17:46 |
| GaryvdM | Is it even included | 17:46 |
| jam | GaryvdM: py2exe is bundling it, which is why we are having the failure | 17:47 |
| jam | GaryvdM: try it now, I edited out the troublesome line | 17:52 |
| GaryvdM | ok | 17:52 |
| GaryvdM | jam: In which file? | 17:52 |
| jam | PyQt4/uic/__init__.py | 17:53 |
| GaryvdM | ok | 17:53 |
| cebesius | i think i might have ruined my development branch when i did a bzr pull --overwrite. is there a way to back that out somehow? i tried revert but that didn't seem to have any effect. | 18:03 |
| GaryvdM | cebesius: Look at bzr heads --all | 18:03 |
| GaryvdM | cebesius: See if you can find the revision in there. | 18:04 |
| cebesius | bzr: ERROR: unknown command "heads" | 18:04 |
| GaryvdM | cebesius: Ah - you need the bzrtools plugin | 18:04 |
| GaryvdM | cebesius: What os? | 18:05 |
| cebesius | ok thanks. sorry i apologize for the noobery | 18:05 |
| cebesius | ubuntu | 18:05 |
| cebesius | sudo apt-get install bzrtools ? | 18:05 |
| GaryvdM | yes | 18:05 |
| cebesius | i see the branch nick for my development branch. at the end of the HEAD: line, it says (dead) | 18:07 |
| GaryvdM | cebesius: ok - now you can do bzr pull . -r <revid> --overwrite | 18:08 |
| GaryvdM | cebesius: You will then have diverged branches, and will need to do a merge in one of them | 18:09 |
| GaryvdM | cebesius: you can also do bzr merge . -r <revid> | 18:09 |
| cebesius | GaryvdM: that just took care of it. thanks! | 18:11 |
| GaryvdM | jam: wack-a-mole time: http://pastebin.org/375740 | 18:11 |
| GaryvdM | cebesius: Glad I could help. | 18:12 |
| GaryvdM | jam: Don't you want to try give me permission to that dir. | 18:12 |
| jam | GaryvdM: I think I did | 18:12 |
| jam | I did try again | 18:12 |
| GaryvdM | jam: ok - let me try access | 18:13 |
| jam | so there are other entries according to grep, let me grab them | 18:13 |
| GaryvdM | jam: I can edit now. | 18:14 |
| GaryvdM | jam: It's building \o/ | 18:15 |
| jam | k, I hacked out a few more files | 18:16 |
| jam | Compiler/qtproxies.py, objcreator.py pyuic.py and __init__.py are all touched | 18:16 |
| GaryvdM | jam: setup.py py2exe succeeded. Now running whole script. | 18:17 |
| GaryvdM | jam: If I edit something in any of the existing build branches, I get this error: http://pastebin.org/375786 | 18:22 |
| jam | mgz: so what is your thought on the -OO issue with user-installed plugins? Should we just back out the change? Should we just push harder on getting plugins fixed? | 18:22 |
| jam | GaryvdM: you're not allowed to edit that way | 18:22 |
| jam | by design | 18:22 |
| GaryvdM | jam: note that the change I made was in bzr/setup.py, note in qbzr as the error indicates | 18:22 |
| jam | we want to build from committed code | 18:22 |
| jam | the qbzr-en.po stuff, I only see when that is actually regenerated | 18:23 |
| mgz | well, we have to either fix bug 600803 or backout the setup change for the moment | 18:23 |
| ubot5 | Launchpad bug 600803 in Bazaar Windows Installers "Plugin pyo files may be ignored and recreated from source (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/600803 | 18:23 |
| jam | mgz: ugh, timezone issues? | 18:24 |
| mgz | the bug will want fixing anyway, and it might still be best to backout the installer change for this release | 18:24 |
| jam | what is your TZ? | 18:24 |
| mgz | BST currently. | 18:24 |
| mgz | GMT+1 | 18:24 |
| mgz | but it's when the installer is used that matters I think. | 18:24 |
| mgz | library.zip isn't affected because though the zip is time shifted, the files inside get their stamps from the zip metadata | 18:25 |
| GaryvdM | jam: the error also happens if I run build.py installer (as as appose to bulid.py installer bzr.dev or bulid.py installer bzr-2.2.) But I guess that is something I can look at later... | 18:25 |
| jam | mgz: it looks like the build host is Pacific Time UTC-7 | 18:25 |
| jam | you know what... | 18:25 |
| jam | timestamp == Unix seconds from epoch.. Do we adjust for TZ or not | 18:25 |
| jam | always been a bit wonky on Windows, IIRC | 18:25 |
| jam | GaryvdM: I thought the qbzr stuff was because we weren't building a snapshot with newly generated .po files, but I could be wrong | 18:26 |
| mgz | well, currently I wonder if the problem is actually our code or in nsis or whatever we use | 18:26 |
| jam | mgz: where do you get the magic from? (what bytes) | 18:26 |
| mgz | inside the pyo files - but it's being compared to the mtime of the py files | 18:26 |
| GaryvdM | jam: yes - I think the error report incorrectly reports the project. | 18:26 |
| jam | mgz: sure, but where in the pyo | 18:27 |
| jam | so I can compare | 18:27 |
| mgz | look at the first 8 bytes of the pyo files, first four are the magic, next four are little endian int_4 stamp | 18:27 |
| GaryvdM | maybe I'm wrong | 18:27 |
| mgz | so, if nsis is packing the files as localtime, and unpacking as localtime, that would break for anyone not in the same timezone as where the installer is created | 18:28 |
| mgz | either that, or py_compile is borked. | 18:28 |
| jam | mgz: they match here | 18:29 |
| jam | os.lstat('commands.py').st_mtime == 1278013301.0 | 18:29 |
| mgz | what's your timezone? | 18:30 |
| jam | struct.unpack('<i', open('commands.pyo', 'rb').read(8)[4]) == (1278013301,) | 18:30 |
| jam | well not that exactly but you get the idea | 18:30 |
| jam | TZ == UTC-7 I believe | 18:30 |
| jam | (mine is -5, but build host is on Amazon EC2) | 18:30 |
| jam | so it could be NSIS | 18:31 |
| jam | mgz: what platform are you on? | 18:31 |
| mgz | Xp | 18:31 |
| jam | you know what, I can just set the TZ for that machine to UTC, who cares, right? | 18:32 |
| jam | let me try that | 18:32 |
| GaryvdM | jam: Please let me know when that is done | 18:32 |
| mgz | worth a go. | 18:33 |
| jam | GaryvdM: done | 18:33 |
| GaryvdM | jam thanks | 18:33 |
| mgz | might not work, but is easy to see if it does. | 18:33 |
| jam | note, though, that this is on the old-windows-installers stuff | 18:33 |
| jam | GaryvdM: and I'm being lazy and building as admin, since I don't want to relog | 18:33 |
| GaryvdM | jam: I don't think that that would affect anything. | 18:35 |
| GaryvdM | building as admin... | 18:36 |
| jam | GaryvdM: well, it screws up perms for the rest of us | 18:37 |
| jam | and is generally something I like to avoid | 18:37 |
| jam | (consider running make as root) | 18:37 |
| jam | just a 'hygiene' thing | 18:37 |
| === mwhudson_ is now known as mwhudson | ||
| mgz | okay, bad news, don't think changing builder to gmt will help | 18:38 |
| mgz | just checked the before and after stamps on 2.2b3 which I just installed (as in, in the summer, not the winter) | 18:38 |
| mgz | and it's 8 hours out. | 18:38 |
| jam | mgz: so you're saying that changing *your* timezone affected it? | 18:41 |
| jam | the build is just about done | 18:42 |
| mgz | I'm saying when my timezone changed one hour, the difference also changed an hour, which suggests my localtime matters, as well as the build slave's | 18:45 |
| mgz | ie, it's doing localtime(a)->localtime(b) not localtime(a)->gmt | 18:45 |
| GaryvdM | bla - wack-a-mole: http://pastebin.org/375882 | 18:45 |
| mgz | hm, so, it's either looking in the wrong place for the c runtime libraries, or they should be being copied there and they aren't | 18:46 |
| mgz | not sure that's much help to you gary | 18:47 |
| GaryvdM | http://pastebin.org/375893 - yhea - they are not there | 18:47 |
| GaryvdM | So close, but yet so far... | 18:48 |
| GaryvdM | jam: I'm stuck. http://pastebin.org/375882 Any ideas? | 19:11 |
| jam | GaryvdM: if you look at build.py (or bazaar_releases.py) it mentions looking for where the msvcrt runtime redistributable stuff is | 19:19 |
| jam | let me check | 19:19 |
| jam | GaryvdM: DEFAULT_MSVC_REDIST_DIR | 19:19 |
| jam | I see 3 msvc* dlls there | 19:20 |
| jam | and build.py has a check if "self.python.find(26)" (which IMO is a bad check), then it tries to copy the msvcr90.dll over | 19:21 |
| GaryvdM | jam: Ah - there is msvcr90.dll in build-win32\release\bzr | 19:23 |
| GaryvdM | jam: Ah - there is msvcr90.dll in build-win32\release\bzr-dev\win32_bzr.exe\Microsoft.VC90.CRT | 19:23 |
| GaryvdM | So it is copying into a subdir | 19:24 |
| jam | sounds like it might be the wrong place | 19:24 |
| GaryvdM | ah - see comment in bulid.py line 408 | 19:25 |
| GaryvdM | I'm going to modify that. | 19:26 |
| GaryvdM | I cant' belive it. It built!!!! \o/ !!!! | 19:33 |
| GaryvdM | http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~garyvdm-setup.exe | 19:39 |
| GaryvdM | mgz, jam ^ | 19:39 |
| GaryvdM | Installed. bzr-explorer works, but I got this error: http://imagebin.org/103818 | 19:54 |
| jam | GaryvdM: strange, bundling "" certainly seems wrong :) | 20:09 |
| GaryvdM | jam: I only get it when tbzr is selected | 20:09 |
| GaryvdM | jam | 20:09 |
| GaryvdM | jam: And toverlays is not getting installed. | 20:10 |
| GaryvdM | So I think thats related | 20:10 |
| jam | GaryvdM: maybe we are setting the env var incorrectly, or not getting it passed into the right part of the build | 20:11 |
| jam | you might check the iss file | 20:11 |
| GaryvdM | jam: I'm also getting a Unable to import library 'launchpadlib' error | 20:11 |
| jam | GaryvdM: I believe there was a "pipeline depends on launchpadlib so lets back out pipeline" maybe there is another on elike it? | 20:12 |
| GaryvdM | jam: I'm going to send a mail to the ml, and then go home. I'll try again. | 20:12 |
| GaryvdM | jam | 20:12 |
| jam | k | 20:12 |
| GaryvdM | jam: I'm really happy though that I got it to build. Thanks for all the help. | 20:13 |
| jam | GaryvdM: isn't it already like 10pm there? | 20:13 |
| GaryvdM | 9pm - thats still early :-) | 20:13 |
| GaryvdM | The last 3 nights I was in bed after 1am... | 20:13 |
| GaryvdM | :-p | 20:14 |
| GaryvdM | jam: And I need to add the ability to specify a revision spec for everything.... | 20:15 |
| GaryvdM | jam: Thanks alot for all the help. | 20:30 |
| GaryvdM | Good night all. | 20:30 |
| jam | night GaryvdM | 20:30 |
| mgz | thanks for doing all this jam and gone-gary | 20:55 |
| mgz | I'll give your installers a try here when I cool down a bit. | 20:55 |
| mgz | http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint <- perl... surely using bzrlib would be easier (if not shorter) | 21:02 |
| mgz | throwaway scripts are done in what you're familar with I guess | 21:02 |
| jam | mgz: yeah, you could do a lot with bzrlib and just extract the raw texts in an optimal order | 21:07 |
| jam | its a fairly sizeable branch | 21:08 |
| === mwhudson_ is now known as mwhudson | ||
| jam | mgz: so I was wrong, it seems to be strictly dependent on the number of files in a given directory., my perl fu is pretty weak, and there is some ... interesting... syntax | 21:38 |
| GaryvdM | Wow Brazil out... | 21:49 |
| jam | GaryvdM: unexpected | 21:49 |
| GaryvdM | Uruguay and Ghana in overtime... | 21:50 |
| jam | mgz: my version: http://paste.ubuntu.com/458491/ | 22:09 |
| jam | takes about 20s to iterate 540 revs | 22:09 |
| jam | I could probably do better if I got down into some hardcore details | 22:10 |
| jam | but my graph looks just like his :) | 22:10 |
| mgz | ah, much better after bath, still hot though | 23:15 |
| lifeless | :> | 23:16 |
| mgz | jam: that's really neat. making a proper commandline tool of it is dedication | 23:16 |
| lifeless | of what ? | 23:17 |
| mgz | ah, I linked this earlier: http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint | 23:18 |
| mgz | and jam answered my "would be better with bzrlib" by... doing a pretty (non-perl) version | 23:19 |
| mgz | interesting just to see how much of the internals you need to understand to write a short script like that not going through the command line ui | 23:20 |
| mgz | okay, tested the tz installer, and indeed the bug is still there, the stamp is now an hour out | 23:31 |
| mgz | I'll try and find some nsis docs I think. | 23:32 |
| mgz | http://sourceforge.net/tracker/index.php?func=detail&aid=2581469&group_id=22049&atid=373085 | 23:35 |
| mgz | probably that. | 23:35 |
| ubot5 | Error: <Bugtracker.plugin.Sourceforge instance at 0x2364bd8> bug 2581469 not found | 23:35 |
| lifeless | -lol- | 23:36 |
| mgz | hey, it tried! | 23:37 |
| mgz | hm, how did I do that link-to-upstream-bug thing in launchpad before? does it need a launchpad project registered as well as the sourceforge one? | 23:38 |
| lifeless | 'affects project', paste url. | 23:38 |
| mgz | ...doesn't seem to like that | 23:39 |
| mkanat | No subtrees yet, right? | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
