| spiv | mgz: ooh: IntegrityError: update or delete on table "bugwatch" violates foreign key constraint "bugwatchactivity_bug_watch_fkey" on table "bugwatchactivity" | 00:03 |
|---|---|---|
| mgz | spiv: does that need a bug filing against something or is there one already? | 00:12 |
| mgz | https://bugs.launchpad.net/malone/+bugs?field.searchtext=IntegrityError | 00:13 |
| mgz | nothing similar looking there. | 00:13 |
| spiv | I *think* the malone team will take care of that for you, I'm pretty sure the OOPS reports are routinely analysed and turned into bugs. | 00:13 |
| spiv | But there's no harm in filing a bug with the OOPS ID | 00:14 |
| spiv | It might even speed the process. | 00:14 |
| poolie | hi mgz | 01:05 |
| mgz | hey poolie. | 01:05 |
| mgz | hm, some dupe finder on file does something useful for once and turns up bug 575911 | 01:11 |
| ubot5 | Launchpad bug 575911 in Launchpad Bugs "Trying to delete a bug watch results in a non-OOPSing IntegrityError (affected: 2, heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/575911 | 01:11 |
| mgz | I'm guessing the fix wasn't intended to make it an OOPSing IntegrityError | 01:11 |
| poolie | haha | 01:42 |
| poolie | hi spiv, how are you? | 02:13 |
| spiv | poolie: pretty good. About to submit a merge proposal for bug 309682, then I was thinking of starting on the HPSS request jam's shallow branch mail talked about. | 02:29 |
| ubot5 | Launchpad bug 309682 in Bazaar "tags are copied but their revisions may not be (affected: 0, heat: 8)" [Low,In progress] https://launchpad.net/bugs/309682 | 02:29 |
| spiv | poolie: so, doing better than the Australian cricket team :) | 02:30 |
| poolie | hahaha | 02:58 |
| poolie | spiv that sounds good to fix | 03:10 |
| poolie | i'm a bit tired and struggling through my mail and todo list | 03:10 |
| poolie | i might stop it and try some easy bugs soon | 03:10 |
| spiv | Hmm, as usual, reviewing my diff before I'm about to submit it I think “I could add more tests...” | 03:18 |
| poolie | heh, i didn't think about spiv and cricket until just now :) | 03:19 |
| abentley | spiv: Since you're patch pilot and you like incremental diffs: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197 | 03:47 |
| spiv | heh | 03:48 |
| spiv | actually that was last week, vila needs to update /topic I guess... | 03:48 |
| spiv | But sure, I can take a look. | 03:48 |
| spiv | I wonder a little about changing the behaviour in a stable branch | 03:49 |
| spiv | Even if it better behaviour. | 03:49 |
| abentley | spiv: Well, that's fair. | 03:49 |
| abentley | spiv: But it's buggy behaviour, too. | 03:50 |
| abentley | spiv: It causes iter_changes to report bogus data. | 03:50 |
| abentley | spiv: We can resumit it for lp:bzr if you think that's best. | 03:51 |
| poolie | thanks for proposing that, abentley | 03:52 |
| spiv | Buggy behaviour that was codified in tests... so buggy in a way that perhaps isn't immediately obvious, so it does seem pretty plausible some plugin might be depending on it, even accidentally. | 03:52 |
| poolie | spiv, who is pp now? | 03:52 |
| poolie | and i wonder if you should send a brief report? | 03:52 |
| spiv | I'm really unsure how large the risk is here. | 03:52 |
| spiv | It's an "unknown unknown", I guess ;) | 03:52 |
| spiv | poolie: vila I think, and good point... | 03:52 |
| abentley | poolie: np. | 03:52 |
| spiv | abentley: if landing in lp:bzr is good enough for Launchpad to benefit from the fix, then my inclination is to do that, just to be conservative with our stable releases. | 03:53 |
| abentley | spiv: Okay, I'll retarget it to lp:bzr, and then we'll spin a bzr-2.2.2-launchpad-1 for ourselves. | 03:53 |
| abentley | spiv: It's not, but we can diverge until we get on the 2.3 series. | 03:54 |
| spiv | *nod*, well, it at least helps a bit to have an approved patch to backport to your diverged 2.2. | 03:54 |
| abentley | spiv: true. | 03:55 |
| poolie | the general plan was to have lp run bzr 2.2 releases, until we get to 2.3rc or the last beta | 03:56 |
| poolie | i'll read it too | 03:56 |
| abentley | spiv, poolie: resubmitted as https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42203 | 03:56 |
| poolie | i'd really rather not have lp run its own branch if we can avoid it | 03:58 |
| abentley | spiv, poolie: And resubmitted once more, because 2.2 has unmerged revisions: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42204 | 03:59 |
| poolie | abentley, i'm so glad you added resubmit&retarget | 04:00 |
| abentley | poolie: Cool. | 04:00 |
| abentley | poolie, spiv: I can do a more conservative fix to 2.2 if I adjust the is_executable callsite. Then it would only affect PreviewTree._comparison_data. | 04:02 |
| === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.2 has is out <http://bit.ly/bzr222rn> (rm vila) | ||
| poolie | spiv did you want to tweak anything in https://code.launchpad.net/~eric97/bzr/fix-merge-docs/+merge/40671 | 04:08 |
| spiv | poolie: no, it looked good to go except for the contributor agreement | 04:09 |
| dmuir | is branching supposed to be fairly immediate? | 04:21 |
| dmuir | or am I missing something in my setup? | 04:21 |
| bob2 | is that an LP question? or are you branching locally? | 04:22 |
| dmuir | I've got a shared repo, with a svn mirror in a branch called mainline | 04:22 |
| dmuir | branching locally | 04:22 |
| dmuir | when I do `bzr branch mainline new-feature`, it seems to sit there for several seconds | 04:23 |
| dmuir | Yes, a few seconds isn't killing me... but this is for repos with fewer than 1000 revs | 04:24 |
| dmuir | hmm, maybe it's just a caching issue | 04:26 |
| dmuir | when I make multiple branches, it goes pretty quick | 04:26 |
| poolie | dmuir: it could be a disk cache thing? | 04:44 |
| poolie | do you get a progress bar? | 04:44 |
| dmuir | yeah, with a counter of some sort x/y with x increasing until it reaches y | 04:45 |
| poolie | and what text? | 04:45 |
| dmuir | build phase: adding file contents | 04:47 |
| spiv | Ah, that's possibly related to #607298 | 04:49 |
| spiv | bug 607298 | 04:49 |
| ubot5 | Launchpad bug 607298 in Bazaar "Slow branch creation with cold disk cache (affected: 1, heat: 3)" [Medium,Fix released] https://launchpad.net/bugs/607298 | 04:49 |
| spiv | Which is fixed in the 2.3 branch, but wasn't in 2.2 | 04:49 |
| dmuir | ah, cool | 04:50 |
| dmuir | something weird though. when I branched bzr.dev, it was immediate, even though I hadn't made a branch in that repo in over a month | 04:51 |
| dmuir | oh, never mind | 04:57 |
| dmuir | the branch I had for bzr was a no-trees branch | 04:57 |
| dmuir | when's 2.3 due? | 04:58 |
| dmuir | trying to remember what the release cylce was... | 04:59 |
| dmuir | oh, I think I found it | 04:59 |
| dmuir | http://doc.bazaar.canonical.com/developers/cycle.html | 04:59 |
| poolie | dmuir: roughly february | 05:07 |
| dmuir | cool, looking forward to it :-) | 05:07 |
| lifeless | poolie: spiv: testtools now has some list/load-test functionality, you may be able to delete some more code from bzr | 05:46 |
| poolie | great | 05:47 |
| mkanat | poolie: Hey. | 06:01 |
| dmuir | eol rules are still only global right? | 06:55 |
| dmuir | I've got a situation where when I make changes to a file checked out from an svn repo, the whole file gets marked as modified, even though I've only changed one line. I'm assuming that an EOL conversion is to blame | 06:57 |
| dmuir | does bazaar apply any automatic conversions or is "exact" the default? | 06:58 |
| dmuir | spoke too soon. manual says exact is the default | 06:58 |
| dmuir | so maybe it's my ide that's done the conversion... | 06:59 |
| fullermd | It's not unheard of for editors to do line ending conversions. IDE's are probably another step more likely than plain-old-editors. | 06:59 |
| dmuir | ah, I think I've found the culprit | 07:00 |
| dmuir | I think it's from doing a conflict resolution with meld | 07:01 |
| vila | hi all | 07:05 |
| spm | hey vila! | 07:06 |
| vila | ha ! New kernel, reboots all over the place incoming | 07:06 |
| vila | spm: hey ! | 07:06 |
| dmuir | I'm full of questions today.... what's the quickest way to revert files matching a pattern? | 07:29 |
| dmuir | `bzr revert */_notes` does work | 07:31 |
| dmuir | d'oh, I mean *doesn't* work | 07:38 |
| mkanat | dmuir: ls -d1 */_notes | xargs bzr revert ? | 08:10 |
| mkanat | dmuir: That's just off the top of my head. | 08:10 |
| dmuir | mkanat: I'm getting: ls: cannot access */_notes: No such file or directory | 08:12 |
| mkanat | dmuir: Then you have no such file or directory? | 08:12 |
| dmuir | ah, good point :-) | 08:12 |
| mkanat | :-) | 08:13 |
| dmuir | they're files that have been deleted | 08:13 |
| mkanat | Ahh. I dunnow, then. | 08:13 |
| dmuir | I guess I need to use bzr ls | 08:13 |
| dmuir | wohoo! | 08:16 |
| dmuir | bzr status | grep _notes | xargs bzr revert | 08:16 |
| mkanat | Ah, cool. :-) | 08:16 |
| mkanat | Good idea. | 08:16 |
| dmuir | thanks for pointing out xargs, didn't know about that one | 08:16 |
| mkanat | dmuir: Welcome. :-) | 08:18 |
| Tiriel | Hi! | 09:12 |
| Tiriel | I'm new to bazaar, and I read on the website that it has some limitations with XML and binary files | 09:12 |
| Tiriel | How bad is this? because these are mainly the kind of files I'll be working with | 09:12 |
| mkanat | Tiriel: Where on the website does it say that? | 09:13 |
| mkanat | Tiriel: The only limitations that I can think of are that working with enormous binary files can be slow and use a lot of RAM. | 09:14 |
| Tiriel | well, let me check | 09:14 |
| Tiriel | I'm pretty sure I just read it, but I can't remember where | 09:14 |
| Tiriel | Ah! here http://wiki.bazaar.canonical.com/TheBigPicture | 09:16 |
| Tiriel | " It is less effective with tree-structured data (e.g. XML), and is most limited in dealing with opaque binary files (e.g. Microsoft Word documents)." | 09:16 |
| spiv | Tiriel: well, the builtin merge is designed to work well with text files | 09:19 |
| spiv | Tiriel: that's what that's referring to | 09:19 |
| spiv | Tiriel: e.g. if you use "bzr merge" and the two branches have both changed the same MS Word document, bzr will only be able to say "there are conflicting changes, here are the different versions of the file, it's up to you to resolve that" | 09:20 |
| Tiriel | Oh! is that it?, I don't think that will be much of a problem then | 09:21 |
| Tiriel | see, the plan is to do some translation work, so I don't think there will be a lot of merging | 09:21 |
| spiv | (and bzr allows plugins to extend its merge capabilities, so if you have tools that can help with automatic merging you can quite likely hook them into bzr with a plugin) | 09:22 |
| Tiriel | that's also good to know | 09:22 |
| Tiriel | I was fearing this issue would be a major stopper | 09:23 |
| peitschie_ | Tiriel: sorry to butt in (i only just joined)... are you wondering about bzr merge capabilities on xml docs? | 09:24 |
| Tiriel | Well, it boiled down to it, I was asking about the broader limitations of bzr when dealing with XML and binaries | 09:25 |
| Tiriel | all insight is appreciated | 09:25 |
| peitschie_ | sounds good :) | 09:26 |
| peitschie_ | just wanted to chip in that most xml merges I've done seem to be going well | 09:26 |
| spiv | Tiriel: I suggest just trying it out: it's very quick and easy to make a branch of some files, commit a few revisions, etc. | 09:26 |
| Tiriel | Well, I'm on the research stage atm, I haven't deployed anything just yet | 09:26 |
| Tiriel | I'm trying to figure out which tool suits best, and bazaar looks very good, but I was concerned about this since XML will take most of the work | 09:28 |
| peitschie_ | tiriel: r u expecting to do merging on the binaries at all? | 09:28 |
| Tiriel | not really | 09:28 |
| Tiriel | in fact I'm not expecting to do much merging at all | 09:28 |
| Tiriel | but you never know... | 09:28 |
| peitschie_ | tiriel: cool. with the xml things, does everyone use a tool when editing it btw? i.e., the format will b consistent across edits? | 09:29 |
| Tiriel | yes, I plan to stablish a standard slang | 09:29 |
| Tiriel | as I said this is all in the planning stage, nothing is sure just yet | 09:30 |
| peitschie_ | tiriel: that will serve well :). As I mentioned earlier, we've been running an 18month old project on bzr (migrated onto bzr about 8months ago) and so far have found xml merging quite nice... once we established everyone using tabs! | 09:30 |
| Tiriel | nice, that leaves me at ease. | 09:31 |
| Tiriel | On a totally different matter, is it possible to have some HTML code or something to pull the latest version of a file in bazaar and display it on a webpage | 09:32 |
| Tiriel | I don't really need the details, I just want to know if it's possible | 09:32 |
| peitschie_ | bzr upload plugin? | 09:32 |
| mkanat | Tiriel: Depending on what you need, you could just use loggerhead. | 09:32 |
| peitschie_ | that is helpful to push via ftp or similar | 09:32 |
| Tiriel | I really don't know what I need right now :( | 09:34 |
| Tiriel | I was thinking that I may want a website where the contents are grabbed from whatever is in bazaar | 09:35 |
| Tiriel | i.e. looking for the files in bazaar instead of /htdocs or whatever | 09:35 |
| Tiriel | maybe it is as easy as serving bazaar through apache and have the website look in there? | 09:36 |
| peitschie_ | i'd b looking t bzr upload + cron job 4 that personally :) | 09:37 |
| Tiriel | as in pushing the head of bazaar's repo to the website with cron? | 09:38 |
| peitschie_ | yup | 09:38 |
| Tiriel | Why would pushing from bazaar be better than pulling from the website? | 09:39 |
| Tiriel | not saying that pulling is better, just trying to understand your approach | 09:40 |
| peitschie_ | brb :) | 09:41 |
| mkanat | Tiriel: Pushing wouldn't require a lot of work from bzr on every web hit. | 09:46 |
| mkanat | Tiriel: If you're talking about grabbing a file from a repo on every hit, that is. | 09:46 |
| Tiriel | Very good point, I hadn't thought of that | 09:46 |
| Tiriel | Also, by pushing we can control wich versions get published on the site! | 09:47 |
| Tiriel | and it is less coupled. WTF was I thinking! | 09:50 |
| Tiriel | Ok, I'm going to get some fresh air and settle the ideas, thanks to all | 09:53 |
| peitschie_ | tiriel: pretty much my reasons match mkanat... less work to push it every once in a while than pull every web hit | 10:04 |
| Tiriel | yup, pushing does look like a much better idea, I hadn't thought it through | 10:07 |
| mkanat | Heyyy folks. :-) I need a review for this loggerhead merge: https://code.launchpad.net/~mkanat/loggerhead/view-default/+merge/42222 | 10:27 |
| vila | maxb: qbzr and bzr-explorer needs to be upgraded in bzr/proposed right ? | 10:30 |
| maxb | ideally, yes | 10:37 |
| maxb | mkanat: Hi. The NEWS file on loggerhead trunk is incorrect, the top entry is under th 1.18 heading, but it actually only happened on trunk | 10:38 |
| mkanat | maxb: Oh yeah? Lemme go look. | 10:39 |
| mkanat | maxb: Ohhhh, you're right. | 10:40 |
| mkanat | maxb: Fix Committed. | 10:41 |
| maxb | thanks :-) | 10:42 |
| mkanat | NEWS also needs some serious updates for dev. | 10:43 |
| vila | ghaaa, is there a way to explore the ubuntu package branches ? | 13:02 |
| jml | code.launchpad.net/ubuntu? | 13:02 |
| vila | bzr info goes into a 'Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored' dance when tried against a non-existing one :-/ | 13:03 |
| * vila kisses jml | 13:04 | |
| vila | ...almost : https://code.launchpad.net/ubuntu/hardy/qbzr | 13:04 |
| jml | vila: https://code.launchpad.net/ubuntu/+source/qbzr | 13:09 |
| vila | jml: haaaaa :) | 13:09 |
| vila | thanks :D | 13:09 |
| vila | https://code.launchpad.net/ubuntu/+source/qbzr/+branches is the one I was after, pfew | 13:10 |
| vila | makes sense | 13:10 |
| johnf | Tricky questions around merges. I've been asked to compile some stats on the lines of code changed every day for a code base. | 13:23 |
| johnf | The metric I've chosen at the moment is just using a diff -c on each commit and pushing that through diffstat | 13:24 |
| johnf | this tree is semi complex with lots of feature branches etc. | 13:24 |
| johnf | which diverge and then remerge | 13:25 |
| johnf | so for standard commits I think this is fine. But what about a commit that is a merge. Am I going to end up double counting changes? | 13:25 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann is now known as oubiwann_ | ||
| vila | johnf: a commit including a merge will produce a diff against its left parent, so it will summarize all the diffs in the right parent(s) *and* whatever modifications made to resolve the conflicts | 13:27 |
| === oubiwann is now known as oubiwann_ | ||
| vila | it really depends on how you want to interpret the resulting stats and whether you drill down into the merges... | 13:29 |
| johnf | vila: yeah not the simplest task I've ever been given. | 13:30 |
| vila | johnf: if you don't use append_revions_only then it becomes even more.... interesting | 13:30 |
| johnf | At the moment I'm tempted to ignore the merge revisions in my stats and assume that conflict changes were small | 13:32 |
| vila | one could argue that a merge commit is more work than a regular one though... | 13:34 |
| johnf | vila: Yeah agree but I don't see any easy way to avoid the double counting | 13:35 |
| vila | may be you shouldn't avoid it | 13:35 |
| vila | that's why I said it depends on what you want to interpret, I'm not sure the raw numbers are meaningful, but how they evolve over time may be more meaningful | 13:36 |
| vila | maxb, jelmer: qbzr and bzr-explorer should be upgraded in debian first or can we update the bzr/proposed ppa directly ? | 13:55 |
| vila | both debian and the ppas are at qbzr-0.19.2-1 and we want 0.19.3 and for bzr-explorer that's 1.1.0 /1.1.2 | 13:57 |
| jelmer | vila: hi | 13:59 |
| vila | jelmer: hey :) | 13:59 |
| jelmer | vila: it'd be nice to upgrade debian first, but it's not necessary | 13:59 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.2 is out <http://bit.ly/bzr222rn> (rm vila) | ||
| === zyga is now known as zyga-sick | ||
| vila | maxb: so, should we start the SRU with bug #659590 or do you still have pending changes regarding running the tests during build (or not) ? | 14:51 |
| ubot5 | Launchpad bug 659590 in bzr (Ubuntu) "dput sftp upload hangs after all files successfully uploaded (affected: 1, heat: 72)" [Undecided,New] https://launchpad.net/bugs/659590 | 14:51 |
| maxb | vila: I have pending changes | 14:52 |
| maxb | Hmm | 14:52 |
| maxb | Except | 14:52 |
| vila | maxb: ok, so we shouldn't copy the package from proposed to stable either right ? | 14:52 |
| vila | maxb: no pressure, just trying to know where we are | 14:53 |
| maxb | If we are now decided to *not* run the testsuite on the official buildd, the unresolved discussion between me and jelmer on how to run it does not matter. | 14:53 |
| maxb | Thus, I should back out the "run testsuite during build" changes from the sru branch | 14:53 |
| maxb | On the matter of the bzr/proposed package, I regard that as OK to promote | 14:54 |
| vila | maxb: that's how I read the reply from pitti regarding MRE/SRU: run the tests after installation | 14:54 |
| maxb | The indecision remains only on the manner of how to run tests during build | 14:54 |
| vila | maxb: ok, so I just copy the bzr one and qbzr and bzr-explorer will be upgraded later | 14:54 |
| maxb | works for me | 14:55 |
| vila | maxb: where is that defined ? (running the tests) | 14:55 |
| vila | maxb: I've branch'ed all the relevant ones (hopefully) | 14:55 |
| maxb | On the SRU: We still have an issue that to technically comply with the SRU procedure we need 2.3b4 in natty first. (You aren't supposed to fix things in maverick until you've fixed them in natty) | 14:55 |
| vila | grrr, I will get this right on day, I willl ! | 14:57 |
| vila | ok, so that's postponed until 2.3b4, I'll add a bug task there...meh how ? | 14:59 |
| vila | ha, right, the other url | 14:59 |
| === zyga is now known as zyga-bed | ||
| maxb | lp:~maxb/ubuntu/maverick/bzr/sru is now updated to remove the "run tests during build" changes, rendering it a straight merge of the new upstream version only | 15:02 |
| maxb | <vila> maxb, jelmer: qbzr and bzr-explorer should be upgraded in debian first or can we update the bzr/proposed ppa directly ? | 15:02 |
| maxb | Whoops, missed that | 15:02 |
| vila | maxb: so this sru branch should now be merged into the maverick package branch and from there in the others ? | 15:03 |
| maxb | What do you mean by maverick package branch? | 15:03 |
| vila | lp:ubuntu/maverick/bzr/bzr-ppa | 15:03 |
| jelmer | vila: it'd be nice to upgrade debian first, but it's not necessary | 15:03 |
| maxb | vila: There is no need, I have already merged 2.2.2 there. | 15:04 |
| vila | jelmer: but *how* should I do that ? (If I even can) | 15:04 |
| maxb | jelmer|vila: Updating Debian first is convenient for those packages without a PPA packaging branch - I have a script (which I really need to publish somewhere) for one-line PPAizing and uploading of the debian.dsc | 15:05 |
| * vila 's head spins | 15:05 | |
| vila | maxb: so this sru branch will only be needed when we want to create the bzr package in maverick-proposed ? | 15:06 |
| maxb | It does not help that we are currently having two interleaved conversations :-) | 15:06 |
| vila | :) | 15:06 |
| maxb | OK, so my sru branch is where I have been preparing the source that I eventually want uploaded to maverick-proposed | 15:07 |
| maxb | To further confound matters, it does NOT share ancestry with lp:ubuntu/maverick/bzr | 15:07 |
| vila | yeah, I'm mixing that with the ppas, hence my confusion | 15:07 |
| vila | ha, branching it right now | 15:07 |
| maxb | This is because the Debian packaging branch is sane and manually maintained, and based on bzr.dev, but the "official" ubuntu packaging branches are a parallel import by the automated UDD importer | 15:08 |
| maxb | So, my recommendation is to ignore the existence of the UDD imported branches for bzr, for now | 15:09 |
| vila | ...or use them to fix the parallel imports bugs | 15:09 |
| * vila ducks | 15:09 | |
| jam | morning all | 15:13 |
| vila | jam: hey ! | 15:13 |
| mgz | hm, stopped snowing again. | 15:16 |
| jam | vila: can you wait 10s and then say my name again, my audio pings don't seem to be working. | 15:18 |
| mgz | jam: you got any insight on bug 680935? | 15:19 |
| ubot5 | Launchpad bug 680935 in Bazaar "repository on flash bzr pack error (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/680935 | 15:19 |
| jam | well, that worked | 15:19 |
| vila | jam: say what ? | 15:19 |
| vila | :D | 15:19 |
| jam | mgz: my line numbers are slightly off, but that looks to be a line like: | 15:20 |
| jam | self._content = zlib.decompress(z_content) | 15:20 |
| jam | I don't see how we can use the zlib interface any differently than that. | 15:21 |
| jam | looking at the faq, it would hint that a buffer is too small or too large. | 15:21 |
| mgz | yeah, also my thought, would be a python bug. | 15:21 |
| vila | mgz: hello ! | 15:21 |
| jam | For example, 'z_content' could be empty | 15:21 |
| jam | or it may decompress to something larger than the default buffer size | 15:21 |
| mgz | or just corruption of some interesting sort. | 15:21 |
| vila | maxb: so the parallel import is about .bzrignore and the debian dir but the others ? | 15:22 |
| jam | mgz: zlib.decompress('') does, indeed, give that error, though. | 15:22 |
| jam | not that I would specifically understand why we would get '' here | 15:22 |
| mgz | hey vila! | 15:22 |
| vila | jam,mgz: lifeless remotely diagnosed a *memory* hardware issue with beuno a couple of.. weeks ago, I'm not sure the message was exactly the same though, may be they remember better than me | 15:23 |
| jam | vila: IIRC, that was different data corruption, but the data on disk seemed fine. There were 3 bit errors in memory from what poolie said, which would be an indication of how ECC mem would fail to find it. | 15:24 |
| mgz | we generally get zlib errors from on-disk corruption, but normally not this one. | 15:24 |
| jam | (ecc can often fix 1, find 2, but would fail >=3) | 15:25 |
| weigon | if I have a workingdir instance, how can I find out what shared repo it is from ? | 15:25 |
| weigon | ... using bzrlib | 15:25 |
| jam | weigon: bzr info? tree.branch.repository? | 15:25 |
| jam | tree.branch.repository.base ? | 15:25 |
| mgz | anyway, what would we need to progress on that bug? a copy of the repo? | 15:27 |
| maxb | vila: Um, no the parallel import is about the entire upstream source being imported as historyless tarballs, not derived from bzr.dev | 15:31 |
| weigon | jam: yep, thanks | 15:34 |
| vila | maxb: I don't get it. If I do 'bzr log --show-ids -v -l1 bzr' in both branches (sru and bzr-ppa), I have the same file-ids | 15:41 |
| maxb | vila: Correct | 15:41 |
| maxb | Now do it in lp:ubuntu/maverick/bzr and see the difference | 15:41 |
| vila | parallel import is about having different file-ids for the same paths AIUI | 15:42 |
| maxb | Yes | 15:42 |
| vila | oh | 15:42 |
| vila | ouch | 15:44 |
| vila | maxb: ok, I won't look at that today then :-/ | 15:45 |
| maxb | vila: Sorry, what? | 15:45 |
| maxb | AFAIK the next job is making 2.3b4 land in natty | 15:46 |
| maxb | not anything to do with the branches | 15:46 |
| vila | maxb: right, I was referring to the parallel import bugs :) | 15:46 |
| vila | maxb: 2.3b4 is next Thursday | 15:47 |
| maxb | ok, that's not too bad | 15:47 |
| === beuno is now known as beuno-lunch | ||
| abentley | jam, do you still feel you need info on https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197? Do you want me to make a more conservative change? | 16:44 |
| RenatoSilva | does the last part of revid (like xirl6fr0zipbof4h) is a unique identifier? | 16:56 |
| RenatoSilva | I want to add binaries to the branch with namestelling what exact revision they match | 16:57 |
| maxb | That was quite impatient | 17:02 |
| vila | :) | 17:02 |
| === beuno-lunch is now known as beuno | ||
| jam | abentley: there are a couple of bits. I mostly was hoping to get discussion from others about what is "stable api". But also, I'm not sure whether None isn't more accurate a term for executable on symlinks and directories | 17:48 |
| jam | from what I can see, WT and RT both return None | 17:48 |
| jam | and PreviewTree returns what is in the basis tree | 17:48 |
| jam | MemoryTree is the only one that always returns IE.executable, which defaults to Falso | 17:48 |
| jam | False | 17:48 |
| abentley | jam, no, it's only RT according to the per-tree tests I introduced. | 17:48 |
| jam | abentley: your branch also changed WT | 17:49 |
| jam | at least, WT_4 | 17:49 |
| abentley | jam, My branch also changed DirStateRevisionTree. | 17:49 |
| jam | ah | 17:49 |
| abentley | jam, None is also inconsistent with our other APIs. | 17:50 |
| jam | right, WT.is_executable returns bool(<is_file> and S_IEXEC) | 17:50 |
| jam | abentley: the fact that most directories have the X bit set, but are "False" for executable seemed odd to me | 17:50 |
| abentley | jam, RT._comparison_data says False, not None for RT. | 17:51 |
| abentley | jam, On directories, that bit means they can be searched. It doesn't mean that they're executable. | 17:51 |
| abentley | jam, IMO, directories and symlinks are never, themselves, executable, because they're not files, and you can't execute things that aren't files. | 17:52 |
| vila | abentley, jam: I'm very tempted to say that if dirs and symlinks are never executable, then executable should not even been *defined* for them, we don't define symlink target for files or directories either. But since that would be far more invasive to get there, I think None is more precise than False to convey "never" | 17:58 |
| vila | s/been/be/ ? | 17:58 |
| jam | vila: that was sort of my feeling as well. that said, False does seem a bit more consistent with the current implementations. | 18:17 |
| jam | the fact that IE.executable is defaulted do False, etc | 18:17 |
| abentley | vila: I don't see value in having a tri-value where a boolean will do. There is only one answer to the question "can this be executed"? And there's no value I can see to a programmer, expecially since None is not clearly distinct from False. | 18:53 |
| vila | there is a value is using None to mean: this make no sense | 18:55 |
| vila | using False implies True is valid | 18:55 |
| abentley | vila: What is the value? How will this aid my bzrlib programming? And does the value offset the cost of having to deal with a third potential return value, and the inability to treat the value as a boolean? | 18:57 |
| vila | I don't see the value in having a boolean where none is needed either, at least 'None' carries this | 18:57 |
| vila | It helps to see None more than to see False as you could then realize that is_executable shouldn't be defined for a dir or a symlink whereas a newcomer may wonder: 'Wait, it's False, when will it be True ?' | 18:58 |
| vila | And *that* AIUI is why executability changes were wrongly triggered | 18:59 |
| abentley | vila: I am saying boolean values are easier for calling code to deal with. They can be used in conditionals directly. They can be serialized using standard machinery. | 19:00 |
| abentley | When were executability changes wrongly triggered? do you mean in the incremental diffs? | 19:01 |
| vila | wow, wow, what are you talking about here ? All the code exist to handle this *today* no ? | 19:01 |
| vila | isn't it what the bug you're fixing about ? | 19:01 |
| abentley | vila: No, I think a lot of the code that exists today treats it as a boolean, and mostly gets away with it. | 19:02 |
| abentley | vila: The PreviewTree code treated it as a boolean, and that's the cause of the incremental diff problems. | 19:03 |
| vila | so all is left to decide is whether None is better than False because we won't un-implement is_executable for dirs and symlinks | 19:03 |
| vila | then why not teach this code that is_executable can be None ? | 19:04 |
| abentley | vila: Because a) it's the wrong value b) implementing that decision everywhere would be a lot of code and API changes. | 19:05 |
| vila | I can understand that it's *easier* to fix it the way you did, but saying that False == None is a bit... different | 19:06 |
| abentley | vila: who's saying False == None? | 19:06 |
| vila | you | 19:06 |
| vila | executable is never defined for dirs/symlinks, you implement it as False | 19:07 |
| abentley | vila: Most assuredly not. If I tell you that a directory is executable, is that a true statement or a false statement? | 19:07 |
| vila | MU :D | 19:07 |
| abentley | vila: No, it's not MU. Even if you argue that the state of a directory's executability is undefined, my statement is false. | 19:08 |
| vila | well, if you agree that your statement is false, then all is well :) | 19:09 |
| abentley | vila: Indeed, because that means that directories are not executable, and the answer to the question "is this directory executable" is "false". | 19:09 |
| abentley | vila: It's not a question of "has the executability of this directory been toggled to the False state", it's a question of "can this directory be executed". | 19:12 |
| abentley | vila: In any case, I hold that a two-value system is less complicated than a three-value system, and therefore in the absence of clear evidence that a three-value system provides a superior API, I believe we should opt for a two-value system. | 19:14 |
| vila | ha ! That's more convincing, between a zero values (no implementation for dirs/symlinks), 2 or 3 values, then yes, the 2 values being less expensive than the 0 one, let's do that ! | 19:19 |
| abentley | vila: yay! | 19:20 |
| sqwishy | In bazaar, is there a nice way to destroy the history of a file without making your branch messed up and incompatible? | 19:55 |
| dash | sqwishy: first, build a time machine | 19:56 |
| sqwishy | dash: Do you know which channel I could go to to get help with that? | 19:56 |
| dash | sqwishy: there was a time traveler convention at MIT, 7 May 2005 | 19:57 |
| dash | sqwishy: you might try there/then | 19:57 |
| dash | sqwishy: anyway no, you can't change history | 19:57 |
| dash | (unless you do it the hard way) | 19:57 |
| jelmer | well, technically bazaar supports having a file without history | 20:05 |
| jelmer | in other words, the history would still exist.. the repository just would just forget about it | 20:05 |
| jelmer | (note that this is different from changing history, which is not possible) | 20:06 |
| poolie | hi all | 21:00 |
| poolie | hi jam? | 21:02 |
| jam | hi poolie | 21:06 |
| poolie | hi there | 21:09 |
| poolie | vila is just talking to me, then we could talk if you like | 21:09 |
| jam | vila: go to bed :) | 21:10 |
| vila | jam: hehe, soon soon | 21:11 |
| === zyga-sick is now known as zyga | ||
| poolie | vila, so shall we do 2.3b4 this week? | 21:27 |
| vila | given that we need to do that to comply with the SRU policy that will allow us to release 2.2.2 into maverick-proposed, yes :D | 21:28 |
| vila | also, 'rmadison bzr' says that natty only got 2.3b2 so there is something to be done there too | 21:30 |
| poolie | work out where it's stalling | 21:30 |
| vila | jam: by the way, did you see bug #683307, I wonder if there is an lp bug there (I haven't checked but it's weird to have another mx recursion depth ) | 21:32 |
| ubot5 | Launchpad bug 683307 in Bazaar "Bazaar crashes on push (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/683307 | 21:32 |
| jam | vila: that is stacking-on-self-causes infinite recursion | 21:33 |
| poolie | i thought so | 21:33 |
| jam | I've seen 3 of those in the last couple of days, not sure why | 21:33 |
| vila | jam: that's my point, especially since for the previous two ones you found an almost empty branch.conf on lp | 21:34 |
| vila | jam: if the third has the same file... | 21:34 |
| jam | vila: there isn't really a reason to have anything else there. | 21:34 |
| jam | I don't know if people are renaming | 21:34 |
| jam | or creating the dev focus first | 21:34 |
| jam | or we have a regression with the "don't stack on self if self is the default target" | 21:35 |
| poolie | that's possible | 21:35 |
| poolie | we should trap this and give a sensible warning | 21:35 |
| vila | poolie: regarding bug #583667, I think we're not on the same page, I mentioned BZR_LP_XMLRPC_URL only for xmlrpc usages, | 21:37 |
| ubot5 | Launchpad bug 583667 in Bazaar 2.3 "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 10)" [High,Confirmed] https://launchpad.net/bugs/583667 | 21:37 |
| vila | I should clarify that it doesn't apply to launchpadlib for which there is no env var | 21:37 |
| vila | poolie: would this address your concerns ? | 21:38 |
| poolie | if setting that variable will fix older clients (including older lplib) then that's fine | 21:38 |
| poolie | hm, scratch that | 21:38 |
| poolie | i think putting this in the bzr news is the wrong place | 21:39 |
| poolie | perhaps we should put a post on blog.l.n, or append to that post | 21:39 |
| jam | vila: interesting, tart-sleepymate is correct, but the branch it is stacked on is broken | 21:39 |
| jam | http://bazaar.launchpad.net/~sleepynate/tart/tart-sleepynate/.bzr/branch/branch.conf | 21:39 |
| jam | http://bazaar.launchpad.net/~andreesie/tart/vanilla/.bzr/branch/branch.conf | 21:39 |
| poolie | saying, for bzr, you need to either upgrade to 2.0.8, 2.1.x, etc | 21:40 |
| jam | vila: I wonder if the +branch/ change to bzr+ssh is confusing us | 21:40 |
| poolie | or, set BZR_LP_XMLRPC_URL | 21:40 |
| jam | so that we see the stacking location as +branch/tart at one point, but end up setting it to ~/andreesie/tart/vanilla at another point | 21:40 |
| poolie | and we need to check whether setting that will fix all interactions with lp, or only lp: urls | 21:40 |
| jam | thumper: ^^ some questions about your changes to the lp: resolution stuff | 21:40 |
| poolie | lifeless: ^^ | 21:40 |
| lifeless | hmm? | 21:41 |
| jam | lifeless: I think poolie is pointing you to the BZR_LP_XMLRPC_URL stuff | 21:41 |
| lifeless | whats that for? | 21:41 |
| lifeless | users have no use case for controlling the end point; only launchpad developers testing new XMLRPC releases need to do that. | 21:42 |
| poolie | lifeless: vila's proposal had a description of how to reconfigure old bzr releases assuming you won't or can't upgrade | 21:42 |
| poolie | even to a bugfix release from the same series | 21:43 |
| poolie | which is a bit of an edge case | 21:43 |
| lifeless | we're not going to remove edge until it has no users | 21:43 |
| lifeless | the goal is to drive the userbase to zero as quickly as possible. | 21:43 |
| poolie | right | 21:43 |
| vila | poolie: right, either they upgrade and they don't care or they don't and they can't read the NEWS | 21:43 |
| lifeless | s/no/very very few/ | 21:43 |
| poolie | vila, that's my point | 21:43 |
| vila | poolie: re-phrasing to make sure I got it ;) | 21:44 |
| poolie | if there are folks who won't upgrade, we'll keep supporting them until their hardware dies or whatever | 21:44 |
| vila | who's 'we' here ? | 21:44 |
| vila | edge.lp.net | 21:44 |
| poolie | yes | 21:45 |
| poolie | we=Robert :) | 21:45 |
| vila | if edge disappears they'll come to us (bzr), we say them: upgrade, they say: we can't, we say: try BZR_LP_XMLRPC_URL, they say: doesn't work, we: upgrade, you're dooned | 21:45 |
| vila | doomed | 21:45 |
| vila | So there is still a slight chance that they try to read the NEWS for the bzr they can't upgrade to and find the the warning there | 21:46 |
| vila | which was my original intent when putting it there | 21:47 |
| vila | but that's not satisfying | 21:47 |
| AdamDV | How can I see the previous versions of a file from the CLI? | 21:47 |
| poolie | AdamDV: `bzr cat -r -1 FILE`, etc | 21:48 |
| vila | bzr cat <file> -r-1 | 21:48 |
| AdamDV | alright | 21:48 |
| vila | poolie: shouldn't we just wait for lplib and lp.net to come up with a solution ? That's where people will fail after all | 21:50 |
| poolie | vila, let's just not document what people using older clients should do in the news file | 21:51 |
| vila | wfm | 21:51 |
| poolie | if lp isn't going to pull the plug it's not urgent | 21:51 |
| poolie | jam, so how are things with you? | 21:51 |
| jam | poolie: moving along pretty well here. | 21:55 |
| spiv | jam: good morning | 21:56 |
| jam | one very odd thing I just discovered. peak memory during "bzr pack" if you already have an optimal pack is much higher than peak memory when you don't. I wonder if we are reading in the entire old pack file to compute the md5sum... | 21:56 |
| jam | hi spiv | 21:56 |
| jam | spiv: I wanted to ask you about https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42078 | 21:56 |
| spiv | jam: Today I'm planning to work on the hpss request you suggested in your shallow branching mail. | 21:57 |
| jam | it says you changed the description, but it doesn't show a delta | 21:57 |
| jam | I was wondering what the different was | 21:57 |
| spiv | I typoed the bug number | 21:57 |
| jam | bbiab, my son is asking for me | 21:57 |
| spiv | So, nothing significant :) | 21:57 |
| poolie | hi there spiv | 21:58 |
| CardinalFang | Hi. Is anyone else running Natty right now? I'd like an independent test of something. | 22:40 |
| CardinalFang | Namely, I want to know if there's a problem with plugin "bzr-builddeb". | 22:43 |
| CardinalFang | $ bzr branch lp:debian/python-couchdb 0.8-0u1; cd 0.8-0u1; bzr import-upstream 0.8 http://pypi.python.org/packages/source/C/CouchDB/CouchDB-0.8.tar.gz | 22:44 |
| CardinalFang | At crash location, there's a comment mentioning spiv's tags-copied-but-no-revisions bug, but I think it's not related. | 22:49 |
| maxb | CardinalFang: Not running natty. Will maverick + tip of bzr-builddeb do? | 22:50 |
| spiv | CardinalFang: pastebin the crash maybe? | 22:51 |
| CardinalFang | maxb, I don't know. If you get AttributeError ^, you'd know. | 22:51 |
| CardinalFang | spiv, I shouldn't have woken you. I've decided your bug isn't related at all. | 22:52 |
| spiv | CardinalFang: also, see if "bzr tags" in that branch reports ? rather than revnos | 22:52 |
| spiv | (in the local branch) | 22:52 |
| maxb | bzr: ERROR: [Errno 2] No such file or directory: u'http://pypi.python.org/packages/source/C/CouchDB/CouchDB-0.8.tar.gz' | 22:52 |
| maxb | for me | 22:52 |
| spiv | CardinalFang: well, even if it isn't that bug, seeing the traceback will help us figure out what the bug is :) | 22:53 |
| maxb | CardinalFang: No AttributeError here when I download the file locally. However, this sounds vaguely like a bug recently fixed in trunk | 22:53 |
| CardinalFang | stack trace: http://pastebin.ubuntu.com/538464/ | 22:54 |
| CardinalFang | spiv, all tags have revnos. | 22:54 |
| spiv | Ok, that rules out the tag bug. | 22:54 |
| CardinalFang | bzr = 2.3.0~beta2-1; brz-builddeb = 2.6ubuntu1 | 22:55 |
| spiv | CardinalFang: I'm guessing it's because bzr-builddeb is looking for an upstream branch, but doesn't know of one... | 22:56 |
| spiv | It's worth filing a bug on bzr-builddeb, I think. | 22:58 |
| maxb | No, it's fixed in trunk r485 | 22:58 |
| spiv | maxb: ah! | 22:58 |
| spiv | maxb: heh, my local copy of trunk was at 484 :) | 22:58 |
| * CardinalFang looks for bzr nightlies. | 22:58 | |
| maxb | bzr branch lp:bzr-builddeb :-) | 22:59 |
| spiv | There's also https://launchpad.net/~bzr-nightly-ppa/+archive | 22:59 |
| spiv | Oh, actually, that's not the PPA I was thinking of.. | 23:00 |
| spiv | https://launchpad.net/~jelmer/+archive/bzr-dailies is the one I was thinking of. | 23:00 |
| CardinalFang | Rock. | 23:01 |
| maxb | no, that's obsolete too | 23:06 |
| maxb | You want https://launchpad.net/~bzr/+archive/daily | 23:06 |
| maxb | (spiv, CardinalFang) | 23:07 |
| spiv | maxb: heh | 23:09 |
| CardinalFang | maxb, spiv, thank you very much. I owe you a beer. | 23:10 |
| spiv | maxb: Hmm, I guess the link to bzr-nightly-ppa on https://launchpad.net/bzr should be replaced with that, then? | 23:10 |
| peitschie | mornin all :) | 23:10 |
| poolie | hi there | 23:10 |
| abentley | poolie: I discussed the branch with jam, but things got derailed into a discussion over what the philosophically-correct return value is when calling is_executable on a directory. | 23:12 |
| poolie | oh, ok | 23:13 |
| poolie | False vs None vs error? | 23:13 |
| abentley | poolie: False vs None. | 23:13 |
| abentley | poolie: I think False is correct, but I think consistency is the most important consideration. | 23:15 |
| abentley | poolie: And False is also consistent with other Tree types and other RevisionTree APIs. Changing it all to None would be a big change. | 23:16 |
| maxb | spiv: Based on the utter deadness of where it currently points, I've just gone ahead and updated it right now | 23:16 |
| james_w | thanks maxb | 23:17 |
| spiv | maxb: thanks :) | 23:18 |
| poolie | abentley: so is it stuck? would you like another review? | 23:20 |
| abentley | poolie: So landing in 2.2 is stuck. Another review would be helpful. | 23:21 |
| abentley | poolie: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197 | 23:21 |
| poolie | that one, or the one that supersedes it? | 23:22 |
| abentley | poolie: That one. The one that supsersedes it is for trunk. | 23:22 |
| poolie | thanks for the incremental diffs btw | 23:23 |
| abentley | poolie: You're welcome. | 23:23 |
| jelmer | hi James, Poolie, Spiv, Aaron, Max | 23:25 |
| jelmer | spiv: My daily builds are mostly living under ~bzr now | 23:25 |
| jelmer | nevermind, I see Max already mentioned that | 23:25 |
| poolie | :) | 23:26 |
| james_w | hi jelmer | 23:26 |
| abentley | jelmer: Hi. | 23:27 |
| poolie | abentley: what was the old behaviour? | 23:29 |
| poolie | oh, None? | 23:29 |
| abentley | poolie: yes. | 23:29 |
| poolie | fairly obviously | 23:29 |
| mkanat | Hey hey. Anybody available to do a review on a loggerhead merge proposal? | 23:35 |
| mkanat | https://code.launchpad.net/~mkanat/loggerhead/view-default/+merge/42222 | 23:36 |
| mkanat | thumper: Would you be the person to talk to about that, now? :-) | 23:36 |
| maxb | jelmer: Hi, a question. Why are the bzr daily recipes using version numbers like 1.4.0~bzr{revno}~ppa{revno:packaging}+{revno:debian} ? The ordering of {revno:packaging} and {revno:debian} is inverted to what feels natural to me? | 23:45 |
| poolie | hi mkanat | 23:45 |
| mkanat | Hey poolie! :-) | 23:46 |
| poolie | maxb: i agree | 23:46 |
| poolie | abentley: i replied; on the whole it seems like a good change but some testing wbn | 23:46 |
| poolie | perhaps we should do that within hudson | 23:46 |
| poolie | or just manually | 23:46 |
| abentley | poolie: What kind of testing do you have in mind? | 23:49 |
| thumper | mkanat: hmm | 23:50 |
| thumper | mkanat: I'm not entirely sure | 23:50 |
| thumper | mkanat: poke poolie :) | 23:51 |
| mkanat | thumper: Hahaha, okay. :-) | 23:51 |
| mkanat | poolie: So, any thoughts on who can do my loggerhead review there? | 23:52 |
| mkanat | poolie: Or do you just want me to check it in w/o review? (Not sure how comfortable I am about that, although I have tested it.) | 23:52 |
| poolie | i probably could | 23:52 |
| abentley | poolie: In the cover letter I said "This branch fixes RevisionTree.is_executable to treat directories and symlinks the same way as other Tree implementations-- to return False rather than None." Was that not a clear enough statement? | 23:53 |
| poolie | sorry, you did | 23:53 |
| poolie | perhaps it is worth mentioning in news though | 23:54 |
| poolie | is this going to systematically change what's returned by iter_changes in non-test cases? | 23:54 |
| poolie | mkanat: shall we discuss it in #launchpad-dev? | 23:55 |
| mkanat | poolie: Sure, I'm there now. | 23:55 |
| abentley | poolie: I believe only PreviewTree, because only PreviewTree can use RevisionTree.is_executable in its it only changes iter_changes when it involves PreviewTree, because only PreviewTree uses is_executable to implement Tree._comparison_data. | 23:57 |
| abentley | poolie: I believe only PreviewTree, because only PreviewTree can use RevisionTree.is_executable in its _comparison_data implementation. | 23:58 |
| abentley | So only iter_changes on PreviewTrees should be affected. | 23:58 |
| poolie | so i'd comfortably +1 it now if you could run the tests of the relevant plugins | 23:59 |
| poolie | that might be a bit annoying if the test suites are not obviously clean to start with though | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!