| abentley | lifeless, would you mind reviewing this? https://code.edge.launchpad.net/~abentley/bzr/unbreak-merge/+merge/19556 | 00:00 |
|---|---|---|
| lifeless | ok, when it has a diff :) | 00:01 |
| lifeless | abentley: perhaps it should try for the tree config and fall back to the branch config after that ? | 00:01 |
| lifeless | abentley: rather than not permitting tree level configs? | 00:01 |
| abentley | lifeless, it was never trying for the tree config. | 00:02 |
| lifeless | abentley: ah! then its trivially ok, JFDI | 00:02 |
| lifeless | abentley: you seem to have unrelated stuff in the diff | 00:03 |
| abentley | lifeless, yeah, weird. | 00:03 |
| lifeless | pages of it :). I suspect 2.0 -> trunk, or something ? | 00:03 |
| lifeless | anyway, the intent of the change you describe is fine. | 00:03 |
| lifeless | +1 | 00:04 |
| abentley | lifeless, Ah, I proposed it against 2.0 instead of 2.1 as I intended. | 00:04 |
| === maxb_ is now known as maxb | ||
| mkanat | mwhudson: The format of loggerhead/1.17 needs to be updated: | 00:18 |
| mkanat | bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/.bzr/) | 00:18 |
| mkanat | is not compatible with | 00:18 |
| mkanat | KnitPackRepository('bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/1.17/.bzr/repository/') | 00:18 |
| mkanat | different serializers | 00:18 |
| mkanat | Or Peng, if you're around and mwhudson isn't, I suppose. | 00:18 |
| justdave | I got that trying to check it out over http, too, fwiw | 00:19 |
| lifeless | its upgrading now | 00:19 |
| mkanat | Yeah, I think it's because one is stacked on the other. | 00:19 |
| lifeless | https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17 | 00:19 |
| mkanat | lifeless: Thanks. :-) | 00:19 |
| lifeless | there is a clicky clicky button in the webui | 00:19 |
| mkanat | Ahh. :-) | 00:20 |
| lifeless | mwhudson: is that button in the API now ? | 00:20 |
| mwhudson | lifeless: no idea | 00:22 |
| lifeless | mkanat: is upgraded | 00:36 |
| mkanat | lifeless: Thanks! :-) | 00:36 |
| mkanat | justdave: ^^^ | 00:36 |
| justdave | does it need to mirror out or something? still getting the error | 00:37 |
| justdave | proxy cache on bazaar.launchpad.net needs flushing I suppose | 00:46 |
| lifeless | there isn't one | 00:46 |
| lifeless | there is however a mirrored copy | 00:46 |
| lifeless | I'm poking, gimme a sec | 00:47 |
| lifeless | upgrade didn't seem to do much | 00:50 |
| poolie | oh hi spiv | 00:51 |
| lifeless | rockstar: where do upgrades get logged ? | 01:12 |
| lifeless | rockstar: trying to upgrade https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17, it doesn't seem to be actually, well, /doing/ anything. | 01:13 |
| lifeless | mwhudson: thumper: ^ perhaps you know | 01:13 |
| mwhudson | lifeless: i don't know anything off hand | 01:14 |
| thumper | hmm... | 01:14 |
| thumper | well | 01:14 |
| thumper | if we had abentley's job console, we'd be able to see something there | 01:14 |
| thumper | for now we just need to do db queries | 01:14 |
| lifeless | ! | 01:15 |
| thumper | as in "ask a losa" | 01:15 |
| thumper | which we can't do | 01:15 |
| lifeless | I would have thought it would log like imports to, to somewere about the branch | 01:15 |
| thumper | we do | 01:15 |
| thumper | but the logs are synced daily | 01:15 |
| lifeless | that would let any user get an idea ;) | 01:15 |
| thumper | unless you ask a losa | 01:15 |
| lifeless | that doesn't sound like the import system | 01:15 |
| thumper | it isn't like the import system | 01:15 |
| lifeless | thats ok; I'm just trying to be clearer about my comment 'I would have thought...' | 01:16 |
| thumper | lifeless: noted | 01:17 |
| lifeless | mbarnett: are you around? | 01:18 |
| lifeless | thumper: should I file a bug that upgrade output isn't visible on the branch | 01:18 |
| thumper | lifeless: yes please | 01:18 |
| lifeless | mbarnett: around? | 01:47 |
| lifeless | mbarnett: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17 isn't upgrading properly, we need a log looked at | 01:47 |
| igc | morning all | 01:54 |
| igc | hi poolie | 01:54 |
| lifeless | igc: just! | 01:54 |
| igc | lifeless: well I did some work in the morning 11 hours ago so it's morning #2 for me :-) | 01:55 |
| poolie | hello igc | 01:56 |
| lifeless | igc: :) | 01:56 |
| poolie | i'm so glad parthm liked that | 01:56 |
| * spiv -> lunch | 02:08 | |
| poolie | spiv/igc/lifeless: i'd like to turn off --verbose in 'make check' so that pqm failures are not so ridiculously long | 02:11 |
| poolie | https://code.launchpad.net/~mbp/bzr/trivial/+merge/19567 | 02:17 |
| lifeless | poolie: it might be nicer just to turn subunit on | 02:20 |
| lifeless | poolie: and let it run the entire test suite, so you get all the failures at once | 02:20 |
| poolie | nicer, but harder :) | 02:20 |
| lifeless | the bug about this has a suggested recipe | 02:20 |
| poolie | bet you can't do it in one character | 02:21 |
| lifeless | so you shouldn't need to think hard ;) | 02:21 |
| lifeless | poolie: bet I can't either | 02:21 |
| poolie | but aside from that, yes | 02:21 |
| poolie | so it would send the whole subunit output? | 02:21 |
| poolie | it sounds good | 02:21 |
| poolie | especially with tribunal | 02:21 |
| lifeless | yes | 02:21 |
| poolie | but it will kind of suck for people wanting to just look at the mail | 02:21 |
| lifeless | so do xml test reports | 02:24 |
| lifeless | which other projects do by default | 02:24 |
| poolie | if we could send mail with a short failure in the body and the subunit in the attachment that would be sweet | 02:25 |
| lifeless | poolie: file a bug - I'm not about to do that immediately, but it certainly sounds nice. | 02:26 |
| lifeless | in fact, I'd want all the failures in the body | 02:26 |
| poolie | hm | 02:30 |
| poolie | actually this could be mostly in subunit generally | 02:30 |
| lifeless | sure. | 02:31 |
| lifeless | anyhow, as I say the recipe has been hammered out for you | 02:31 |
| lifeless | 'the'- 'a' recipe that should work | 02:31 |
| poolie | this is "how to run --subunit and have pqm still have teeth?" | 02:32 |
| lifeless | yes | 02:32 |
| lifeless | once we're doing that reliably I'll happily change PQM to go 'oh look subunit, I'll have teeth no matter what'. | 02:32 |
| lifeless | but its harder to deploy pqm changes, so I don't want to do that willynilly | 02:32 |
| lifeless | poolie: small present for you (apt) | 02:56 |
| poolie | ? | 02:57 |
| lifeless | bug 22354 | 02:57 |
| ubottu | Launchpad bug 22354 in apt "apt-cache doesn't differentiate sources that share protocol, host, release and archive name" [High,Confirmed] https://launchpad.net/bugs/22354 | 02:57 |
| poolie | oh yay | 02:57 |
| === eugeneoden_ is now known as eugeneoden | ||
| abentley | straw poll: It's currently possible to commit a revision whose tree has no root, but this isn't well-supported. Should we forbid committing rootless trees or fix the support? | 03:05 |
| lifeless | abentley: do you mean a root of TREE_ROOT, or actually no root ? | 03:06 |
| abentley | lifeless, no root, like the null: tree. | 03:06 |
| lifeless | abentley: I thought that no root at all wasn't support; and that TREE_ROOT was dependent on the repo | 03:06 |
| lifeless | abentley: and presumably no content either? | 03:06 |
| abentley | lifeless, no content either. | 03:07 |
| abentley | lifeless, it's possible to do when committing a TreeTransform or using the CommitBuilder directly. | 03:07 |
| lifeless | abentley: I'm surprised. I can see a theoretical argument to permit it, but I'm fairly sure it would provoke a lot of bug reports from code assuming things have /some sort/ of root. | 03:08 |
| lifeless | my poll response: forbid | 03:08 |
| lifeless | unless you have a need for it, in which case - talk on | 03:08 |
| abentley | lifeless, I don't need it. | 03:09 |
| abentley | lifeless, the possible problems with forbid are: | 03:10 |
| abentley | lifeless, 1. if there are such commits in the wild already (I have no data) | 03:10 |
| abentley | lifeless, 2. If there's a risk that it will happen in the future, despite us forbidding it in a given codepath. | 03:11 |
| abentley | lifeless, end of list. | 03:12 |
| lifeless | so, for 1 I'd expect that from custom code, not general use - as it has to be totally empty. I think its near-zero probability. | 03:12 |
| lifeless | as for 2, well, we do what we can. | 03:12 |
| abentley | poolie, in your review, you say "I would like to see the actual code changed to be 'propose' not 'submit'.". This means changing class and module names, etc? | 03:17 |
| poolie | yes | 03:17 |
| abentley | poolie, this is an underhanded scheme to make me write some tests, isn't it? | 03:20 |
| poolie | :) | 03:20 |
| spiv | poolie: regarding turning off --verbose in make check, it hasn't really bothered me greatly, so I'm pretty neutral on the idea. I agree that it would be nice to get the failure(s?) in the body and the complete log as an attachment. | 04:04 |
| === eugeneoden__ is now known as eugeneoden | ||
| poolie | spiv, ok, | 04:05 |
| spiv | poolie: with some test suites it can be helpful to have a "I'm running test X now" log in case one test hangs, but historically that hasn't been much of a problem for bzr. | 04:05 |
| lifeless | spiv: pqm does that | 04:05 |
| lifeless | spiv: for subunit, now. | 04:05 |
| spiv | lifeless: right, but that's not turned on (etc etc) | 04:05 |
| poolie | true | 04:05 |
| lifeless | Gotta run; later. Ring or SMS if you want me. | 04:06 |
| spiv | (I see you just had this discussion, I don't mean to make you go in circles!) | 04:06 |
| poolie | hi igc? | 04:09 |
| abentley | poolie, it would have been nice if you had raised the canonical_url thing earlier in the process. | 04:15 |
| poolie | sorry | 04:15 |
| poolie | just because it's better to get the whole review in one go? | 04:16 |
| abentley | poolie, I think that replace('api', '') is a much worse idea than replace('https://api.', 'https://code.') | 04:16 |
| abentley | poolie, because "api" can easily appear anywhere in the URL, while "https://api" is really unlikely to appear anywhere other than the front. | 04:17 |
| poolie | i know | 04:17 |
| poolie | otoh this function won't work for bugs | 04:17 |
| abentley | poolie, because I feel like either I do it the wrong way to get it merged, or I have to do another round. | 04:17 |
| igc | hi poolie | 04:17 |
| poolie | anyhow it's gross that this is not provided by lplib | 04:17 |
| poolie | well, it's negotiable | 04:18 |
| poolie | let's look | 04:18 |
| poolie | it's time to get this merged | 04:18 |
| abentley | poolie, rationale for removing the https:// ? | 04:18 |
| poolie | i keeping wanting to use it :) | 04:18 |
| poolie | actually | 04:19 |
| poolie | never mind about the replacement | 04:19 |
| poolie | i would kind of like you to point to the bug, and to think about changing the name | 04:19 |
| poolie | either expression is kludgy and mine isn't especially better | 04:19 |
| abentley | poolie, the name in the Launchpad codebase is 'canonical_url', which is why I used that name. | 04:19 |
| poolie | oh ok | 04:19 |
| poolie | fair enough | 04:19 |
| poolie | note that i'm using replace(x,y,1) which is maybe more robust against the term /beta/ turning up later in the url | 04:20 |
| poolie | i don't know if that will actually happen | 04:20 |
| abentley | poolie, canonical_url is not exposed over the API because it's a function, and functions don't exist in our REST API. | 04:20 |
| poolie | right | 04:21 |
| poolie | but perhaps it should be in lplib? | 04:21 |
| poolie | or for that matter it could be an object property? | 04:21 |
| poolie | as it is, variations of this code are copy-and-pasted into every lp api client | 04:21 |
| poolie | spiv, to follow up from before | 04:21 |
| abentley | poolie, this should definitely be provided elsewhere, ideally through the REST API directly. | 04:22 |
| abentley | poolie, and making it an object property would be a reasonable way of doing that. | 04:23 |
| poolie | spiv, http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html#backports discusses the use of bugtasks for backports | 04:23 |
| poolie | patches welcome | 04:23 |
| poolie | and that page is just impossible to find :/ | 04:23 |
| poolie | igc, is anything still needed on escudero or did the cron job run ok? | 04:23 |
| spiv | poolie: ah right, I did find that eventually actually, but not before mailing you | 04:23 |
| poolie | abentley: ok so feel free to merge without changing that | 04:23 |
| abentley | poolie, but that wouldn't be a 1:1 reflection of the native API. | 04:23 |
| igc | poolie: the cron job kicked in thanks | 04:24 |
| poolie | what is 'that'? | 04:24 |
| igc | poolie: we still need a bzr.2.2 directory as requested by jam | 04:24 |
| igc | and for those files you emailed me about to be deleted | 04:24 |
| abentley | poolie, providing the URL as an object property on all REST API objects. | 04:24 |
| igc | poolie: I don't seem to have permissions to do any of that | 04:24 |
| poolie | igc, ok | 04:26 |
| poolie | abentley: ok, well, i hope it gets solved somehow | 04:26 |
| poolie | igc: i want to unfold the 'enhancing bazaar' section in http://doc.bazaar.canonical.com/bzr.dev/developers/ | 04:26 |
| poolie | it's too hard to guess where the bug guidelines would be | 04:27 |
| igc | poolie: fine with me. Go for it! | 04:31 |
| * igc lunch | 04:31 | |
| poolie | igc, new page is nice, go for it | 04:37 |
| igc | poolie: thanks | 04:37 |
| poolie | spiv, what do you think of my suggestion at the bottom of https://bugs.edge.launchpad.net/bzr/+bug/376388 | 04:48 |
| ubottu | Ubuntu bug 376388 in etckeeper "~/.bazaar created owned by root (when run under sudo)" [Medium,Confirmed] | 04:49 |
| spiv | poolie: hmm | 04:50 |
| spiv | poolie: now is the time in the 2.2 cycle to try that sort of idea out :) | 04:50 |
| poolie | i was going to suggest parthm try it | 04:51 |
| parthm | Hi poolie. I just saw your comment "backport to 2.0 sent to pqm" and didn't understand it. (on https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483) | 04:51 |
| spiv | poolie: I guess the most obvious failure mode is "directory writeable by me, but not owned by a user I can chown to" | 04:51 |
| poolie | hey | 04:51 |
| poolie | i mean, i cherrypicked your fixes onto a branch of 2.0 | 04:51 |
| poolie | and have sent it for automatic testing | 04:51 |
| parthm | poolie: is this about porting the backup.bzr perms? I have that against 2.0. Was waiting for the final merge in trunk so that any additional changes can also be put in. | 04:52 |
| parthm | Oh cool. Then I won't bother. | 04:53 |
| poolie | yeah, it's ok | 04:53 |
| poolie | generally speaking it's easier to do the review and merge against the older branch first | 04:53 |
| poolie | and then we can merge it forward | 04:53 |
| spiv | poolie: for the case of writing to a file/dir in $HOME, I think your suggestion is good... I haven't thought of any likely scenarios where it will be worse than the status quo | 04:54 |
| parthm | Yes. I was thinking of merging 369501_2.0_ver_on_bzr_cmd forward to 2.1 and 2.2. | 04:54 |
| spiv | We typically tend to just merge all of 2.0 into 2.1 periodically (and 2.1 into 2.2, etc) | 04:55 |
| parthm | Oh OK. Then should I just let that be for now? | 04:56 |
| parthm | That sounds like a good idea. | 04:56 |
| poolie | you can just let that be for now | 04:56 |
| parthm | OK. I had a question regarding fixing of bugs. Is there a policy on deciding if the bug should be fixed againt 2.0, 2.1 or trunk? | 04:58 |
| igc | poolie: the site upgrade has been merged now. I'm not sure how often the cron job runs but it will hopefully be live soon | 05:03 |
| igc | poolie: I'll grab some lunch, reply to some support Qs and then take a look at templating next. Getting rid of manual updates will be good I think | 05:05 |
| spiv | parthm: there's a little bit about it at http://doc.bazaar.canonical.com/bzr.dev/developers/cycle.html#bug-work (and the "Feature and Performance Work" section too) | 05:07 |
| spiv | parthm: we probably should have a more formal description somewhere, I think maybe poolie has sent one to the list at some point? | 05:08 |
| spiv | parthm: roughly speaking, the safer and more valuable a bug fix is, the more likely we are to accept it into stable branches | 05:08 |
| fullermd | Speaking of docs, is there some good way to make random sweeping statements about parts of them needing skilled work? | 05:09 |
| parthm | Thanks spiv. I will go through the docs and also see if I find something on the list. | 05:09 |
| spiv | So a fix for a very rarely hit bug that has a significant chance of other regressions, we wouldn't accept that for 2.0. | 05:13 |
| spiv | But a small, obviously correct fix for something pretty visible we would. | 05:14 |
| spiv | fullermd: "good" in what sense? In the sense that people won't be offended, or in the sense that saying it will cause the docs to be improved? :) | 05:15 |
| fullermd | Well, the former is nice (though in this case, I doubt anybody who'd be offended would still be around :p), but the latter was more what I was thinking. | 05:15 |
| spiv | (And they aren't necessarily mutually exclusive options, of course) | 05:16 |
| spiv | I'd talk to igc about that, then. | 05:16 |
| fullermd | I could mention it here, and have it disappear. Mail the list, probably ditto. File a bug, it ends up being one of those overly-fuzzy "X could be improved" sorts of things... | 05:16 |
| spiv | He seems to be pretty good at building enthusiasm for that sort of work in a way that causes stuff to happen. | 05:17 |
| fullermd | And more importantly, why am I being disturbingly general when I have something specific in mind? | 05:18 |
| fullermd | The "Performance Roadmap" needs rewriting. Big chunks of it talk about things we'd like to evaluate based on 0.16 for use in a possible pack-ish format. This doesn't seem important to have prominent in our docs. | 05:18 |
| abentley | fullermd, I'd consider that a historical document at this point. | 05:19 |
| fullermd | Well, there's still some good stuff in it about minimal-work evaluation of various commands too, so it doesn't (at first glance anyway) seem like a "OK, we can just discard this now". | 05:19 |
| fullermd | But making it up-to-date useful is pretty skilled labor, so it's not low-hanging stuff. | 05:20 |
| spiv | fullermd: I'd say that's possibly a specific-enough issue for a bug report | 05:20 |
| abentley | fullermd, some of that will be out of date too, as we've gained more experience and implemented different things. | 05:20 |
| fullermd | Yah. Hm. I guess I'll put it on my list to try drawing up a few specific slices on it and file something. | 05:21 |
| fullermd | See, this is why I avoid reading docs. It just leads to more work :p | 05:21 |
| spiv | For that matter, the "Bazaar Release Cycles" doc needs to be updated; it's still written as a proposal, when it's now fact. | 05:22 |
| poolie | fullermd: it's true it's out of date but | 05:33 |
| poolie | it's real audience know tha | 05:33 |
| poolie | you can put up a patch that deletes stuff you're pretty sure is obsolete | 05:34 |
| poolie | a lot of it is | 05:34 |
| poolie | i share your doubts about the value of bug reports like that | 05:34 |
| poolie | vague ones | 05:34 |
| fullermd | Yeah, it's tricky. I know enough to believe there are parts of it that are still useful going forward, but not to be sure which parts qualify (and those that do need updating too). | 05:36 |
| fullermd | It probably ends up being not so much even "clean out obsolete", as "take useful bits and make a differently targetted article around them" :| | 05:36 |
| spiv | Right. | 05:37 |
| fullermd | Y'know, to occupy all that spare time everybody has going to waste. | 05:37 |
| spiv | I mean, in its current state it's barely useful at all; I know I haven't referred to that doc for ages, even though as a developer I am in the target audience for it. | 05:37 |
| poolie | right | 05:39 |
| poolie | i'd welcome someone being a bit deletionist there | 05:39 |
| poolie | we can always get it back if we remember something was useful | 05:39 |
| spiv | Agreed | 05:45 |
| poolie | igc, blah, the doc/www directory is root-owned | 05:46 |
| igc | poolie: yep ;-( | 05:46 |
| spiv | Another idea: Twisted IIRC has a 'historical' directory in their docs for docs that aren't worthless but are also nowhere near current. | 05:47 |
| poolie | yeah | 05:47 |
| poolie | we'll have them on the web in old branches though | 05:47 |
| poolie | fullermd: so if you're keen, delete away | 05:47 |
| poolie | igc i'll file an rt | 05:48 |
| fullermd | Oh, I don't have a dog in it at all :) | 05:49 |
| fullermd | Just struck me as worth mentioning while it was in my brain. | 05:49 |
| poolie | igc: rt sent | 06:06 |
| poolie | parthm: https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483 bounced | 06:08 |
| parthm | poolie: I am not quite sure what to make of the error. On my system it appears the sftp tests were skipped. | 06:11 |
| parthm | 19 tests skipped | 06:11 |
| parthm | bzrlib.tests.blackbox.test_upgrade.SFTPTests.test_upgrade_url is leaking threads among 9 leaking tests. | 06:11 |
| parthm | Is this against 2.0? | 06:12 |
| poolie | well this was actually an ftp test | 06:12 |
| poolie | but they might be skipped because you need an external library to run them | 06:12 |
| parthm | poolie: These tests were skipped for me (FTPServerFeature). Installing medusa right now. | 06:21 |
| poolie | cool | 06:21 |
| poolie | igc, perms are fixed | 06:30 |
| poolie | so i now removed the thing i asked you about | 06:30 |
| igc | poolie: thanks | 06:30 |
| poolie | just fixing the links to 2.0 docs | 06:32 |
| parthm | poolie: Its seems the higher perm bits were causing the problem. masking with 0777 fixes this. ie. "target.mkdir('.', stat.st_mode & 0777)" in copy_tree | 06:39 |
| poolie | cool | 06:39 |
| poolie | well spotted | 06:39 |
| poolie | i've got to go now but i'll have a look tomorrow | 06:40 |
| parthm | OK. Good day. Will push the changes. | 06:41 |
| * igc diinner | 08:12 | |
| bialix | heya! | 08:13 |
| bialix | hi, I have a question about teams and bugs, anybody here? | 08:16 |
| Peng | I'm here, but I doubt I know the answer. | 08:17 |
| bialix | np, poolie helped me already on #launchpad | 08:19 |
| Peng | :D | 08:19 |
| Peng | I was right, I didn't know the answer to that question. :D | 08:19 |
| bialix | but you know answers on many others, I'm sure | 08:24 |
| Peng | :) | 08:24 |
| mvo | hm, bzr merge gives me a pretty confusing error message: http://paste.ubuntu.com/378919/ - am I doing something wrong or is bzr in lucid just not handling this correctly? | 08:54 |
| Peng | Even "bzr log -r 98 lp:~lifeless/ubuntu/lucid/apt/bug-22354" fails. Perhaps the branch is screwed up? | 08:58 |
| mvo | thanks peng, I guess lifeless needs to check, I imported the patch via a download now | 09:16 |
| spiv | mvo: I would suspect a damaged branch | 09:35 |
| spiv | mvo: perhaps try branching it locally, and using that copy | 09:36 |
| spiv | mvo: and if the local copy fails, try 'bzr reconcile' on it | 09:36 |
| spiv | mvo: (and please do file a bug) | 09:36 |
| mvo | spiv: thanks, reported as #523703 | 09:39 |
| mvo | spiv: branching locally makes it all work it seems | 09:40 |
| === Wellark1 is now known as Wellark | ||
| === bigjools is now known as bigjools-lunch | ||
| slestak | good morning. Can I discuss a use case with someone before I set this repo up. We have a src license for our ERP system, so we do our own enhancements and modifications. This code is not repackaged. The code is in 3 main dirs, one of which is a vendor branch. | 13:27 |
| slestak | the number packages to trac are 1121, 278, and 5359. The dir with 1121 is the most active | 13:28 |
| slestak | for the 1121 and 278 dirs, we have a prod bracnh and test branch | 13:29 |
| slestak | i am trying to decide between one repo with 5 dirs or 5 repos | 13:30 |
| slestak | any advice is appreaciated | 13:30 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === bigjools-lunch is now known as bigjools | ||
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === froosch_ is now known as froosch | ||
| === beuno-lunch is now known as beuno | ||
| === deryck is now known as deryck[lunch] | ||
| davidstrauss | How does the Bazaar project itself merge changes into multiple stable branches? | 17:42 |
| rubbs | slestak: I know this is a little late, but if you still need help I might be able to give you some advice to your question | 17:43 |
| rubbs | davidstrauss: I'm not sure what you're asking. Are you asking how they merge branches into multiple "versions" of bzr? Like if a fix affects 2.0 and 2.1, how do they get the fix into both? | 17:44 |
| davidstrauss | rubbs: exactly | 17:44 |
| davidstrauss | rubbs: You know, without pulling other 2.0 or 2.1 changes into either. | 17:45 |
| rubbs | I'm not a dev with commit access, so I don't know for sure, but my guess is that they keep the originating branch open and merge it in multiple branches. For example: fix_branch is merged into 2.0 and that fix_branch is kept around and then merged into 2.1. When you merge a branch in, you don't automatically lose that branch. | 17:47 |
| rubbs | but I'm not sure if that's exactly how they do it, since I don't do it myself ;) | 17:47 |
| davidstrauss | rubbs: but if someone branches from 2.1 and writes a fix on it, merging that branch into 2.0 will pull all the missing 2.1 changes, too | 17:49 |
| rubbs | ah, good point. | 17:50 |
| rubbs | unless they export the changes as patches and apply those patches in manually. | 17:50 |
| rubbs | honestly I don't know | 17:50 |
| davidstrauss | rubbs: but that's not a merge :-/ | 17:51 |
| Tak | davidstrauss: you can merge specific revision ranges | 17:51 |
| davidstrauss | Tak: I'm trying to avoid cherry picking, which isn't tracked. | 17:51 |
| fullermd | No, bzr just always completely merges branches upward. | 17:56 |
| luks | davidstrauss: the usual approach is to do it the other way around | 18:11 |
| luks | do fixes based on older revisions and merge them to all the necessary branches | 18:11 |
| === deryck[lunch] is now known as deryck | ||
| luks | you've probably seen it before, but this page nicely explains an extreme variant of this - http://www.monotone.ca/wiki/DaggyFixes/ | 18:13 |
| smmalmansoori | hi all, I just installed bazaar and would like to change the location where it looks for the configuration files (by default in /home/username/.bazaar), could anyone help me please? | 18:20 |
| Kinnison | Why do you wish to change that? | 18:21 |
| smmalmansoori | because i installed bazaar in a usb, so i'd prefer if the config files are in the usb too | 18:22 |
| Kinnison | You can set BZR_HOME in your environment to point at the USB stick I suppose | 18:23 |
| Kinnison | but you'll have to always do that | 18:23 |
| Kinnison | alternatively you try changing bzrlib/config.py on the stick (specifically config_dir()) | 18:23 |
| === radoe_ is now known as radoe | ||
| smmalmansoori | i see, i'll give the config.py option a try then, thanx :) | 18:24 |
| smmalmansoori | Thanks alot Kinnison! worked like a charm :D | 18:38 |
| jam | james_w: are you still around? | 18:40 |
| jam | I was wondering if you had a response to https://bugs.edge.launchpad.net/udd/+bug/508251/comments/3 | 18:40 |
| ubottu | Ubuntu bug 508251 in udd "Failure to import when decoding changelog authors" [Medium,Confirmed] | 18:40 |
| james_w | hi jam | 18:41 |
| jam | I've found the error for gnome-panel | 18:41 |
| jam | which is iso-8859-1 data in the changelog portion | 18:41 |
| jam | while we are searching for "[AUTHOR NAME]" sections. | 18:42 |
| jam | I posted some possible fixes | 18:42 |
| jam | and wondered which you would like to see me implement | 18:42 |
| james_w | jam: thanks for the analysis | 19:02 |
| james_w | jam: I'm not sure what the best would be | 19:02 |
| james_w | jam: we have to decode at some point, but deferring could work. | 19:02 |
| james_w | jam: perhaps try: decode('utf-8') except: try: decode('iso-8859-1') except: pass | 19:03 |
| jam | james_w: right, I was thinking to do the double try as well | 19:05 |
| jam | james_w: do you think it is reasonable to just do the regex match on the 8-bit string first? | 19:06 |
| james_w | and then deferring to after we at least find [ ] would save some effort | 19:06 |
| jam | right | 19:06 |
| james_w | I think so | 19:06 |
| james_w | I think there might be a reason that it is that way | 19:06 |
| james_w | not necessarily a correct reason, but... | 19:06 |
| jam | I think the idea was to handle re.UNICODE | 19:08 |
| jam | but that would only matter if you were using '\w' | 19:08 |
| anddam | hello | 19:08 |
| jam | rather than [^\]] | 19:08 |
| anddam | regex? | 19:08 |
| jam | hi anddam | 19:08 |
| jam | james_w: ^^ | 19:09 |
| anddam | hi there | 19:09 |
| james_w | jam: sounds about right | 19:09 |
| anddam | I'm not used to distributed VCS, can I import from a mercurial repository using bazaar? | 19:09 |
| james_w | jam: I think it might have been to UnicodeDecodeError using re.match on 8-bit strings | 19:09 |
| jam | anddam: there is a 'bzr-hg' plugin which should let you convert | 19:10 |
| anddam | jam: is it a bazaar plugin? | 19:13 |
| jam | anddam: yes | 19:13 |
| jam | lp:bzr-hg | 19:13 |
| jam | you'll need to have mercurial installed as wlel | 19:13 |
| jam | well | 19:13 |
| anddam | jam: so to me it'd be transparent, wouldn't it? | 19:14 |
| anddam | I'm trying to pick up one in the triad and Google project hosting is something to consider | 19:15 |
| jam | anddam: I don't think bzr-hg makes it as transparent as we would prefer | 19:15 |
| jam | I don't think it yet supports 'round-tripping' | 19:16 |
| anddam | thanks, I'll check out | 19:16 |
| jam | (pull from hg, commit in a bzr branch; push back to hg; pull back to bzr) | 19:16 |
| jam | it probably will eventually | 19:16 |
| jam | james_w: would you like to see a trace.mutter (or warning?) if we have to trigger the fallback? | 19:19 |
| james_w | why not? | 19:19 |
| jam | just wondering if it is helpful or just noise | 19:19 |
| jam | and wondering whether mutter or warning is appropriate | 19:19 |
| james_w | I'd say mutter it | 19:24 |
| james_w | though it probably is just noise | 19:24 |
| anddam | bye | 19:36 |
| === salgado is now known as salgado-afk | ||
| mtaylor | bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-368'), ('unversioned executability', 'new-367')] | 20:24 |
| mtaylor | sigh | 20:24 |
| slestak | rubbs: hi, ty for seeing my previous request. I would like to discuss it if you have maybe 10 minutes. | 20:25 |
| rubbs | sure, I'll be in and out, but I'll always respond within a few minutes at most | 20:26 |
| rubbs | just a sec while I re-read what you were asking again. | 20:26 |
| rubbs | ok, I remember my question now. Do any or all of these projects share similar code and/or history? | 20:27 |
| slestak | it is one project, with code divided in 3 dirs | 20:27 |
| slestak | 2 of the dirs have a PROD and TEST label | 20:28 |
| slestak | the 3rd dir is a vendor branch | 20:28 |
| slestak | so that can be taggeed every now and then if we ugrade | 20:28 |
| rubbs | ah, I c. so you have the Vender, testing and production branches, but they are all based off of the same "core" code right? | 20:28 |
| slestak | yes | 20:28 |
| slestak | what I am afraif of if I set this repo to track too many targets, it will be slow for every operation | 20:29 |
| slestak | that is why I was thinking about maybe 3 or 5 repos. | 20:29 |
| rubbs | then I would suggest doing a shared repo because they are going to share most of the same history. for the most part other operations won't be affected too much. | 20:29 |
| slestak | that would make sense, the code is all one erp app | 20:30 |
| rubbs | the advantage of having them all under the same repo (with different branches) is saving disk space and merges etc between branches would go pretty quickly | 20:30 |
| slestak | yes. now. at the beginning, I am the only person motivated to use scm | 20:31 |
| slestak | i think that will be ok, I think for a time I will just have commit statements liek "Scale is workign on the website, isse 456" | 20:31 |
| slestak | hopefully without all the type, but not likely | 20:31 |
| slestak | typos! | 20:31 |
| rubbs | haha | 20:31 |
| rubbs | I do it all the tie | 20:32 |
| rubbs | time* | 20:32 |
| rubbs | haha | 20:32 |
| rubbs | not intended ^ | 20:32 |
| slestak | i joke all the time i need a speel checker | 20:32 |
| rubbs | heh... me too. | 20:32 |
| rubbs | but as far as your question goes, I can't really see much of a downside to setting up a shared-repo. | 20:33 |
| lifeless | mtaylor: file a bug | 20:33 |
| mtaylor | lifeless: ok. | 20:34 |
| slestak | is it sane or advisable to simplify the dir structure with symlinks and version the symlinks? i.e. instead of versioning /ud/JM/USER-FORMS and /ud/TEST/USER-FORMS. I would version /usr/local/src/ud/L-USER-FORMS and /usr/local/src/ud/T-USER-FORMS. ther eare more that I would add. but i think bring them together under one dir and prefix them with their role? | 20:36 |
| rubbs | not sure to be honest. I havne't really used symlinks much, however I know that some do. Bzr will work with symlinks. One thing to remember though is that windows can't really handle symlinks so you won't be able to have a windows user checkout a branch. | 20:38 |
| slestak | oh, that could be a problem | 20:39 |
| slestak | this code is edited locally. it must be built on the aix box, so very rarely will you have it on your workstation (besides me editing with netrw, but that doesnt coaunt.) | 20:39 |
| poolie | hello all | 20:40 |
| rubbs | yeah, most people don't think about that :(. If you were in a completely UNIX environment, that wouldn't be so bad, but windows doesn't seem to like to play nice with symlinks ;) | 20:40 |
| rubbs | hello poolie | 20:40 |
| rubbs | slestak: I would still advice against symlinks even if you are just editing on a windows machine. | 20:40 |
| slestak | ok | 20:40 |
| rubbs | mostly because it will be hard to checkout/branch your code to your local machine. | 20:40 |
| slestak | so if these have a common root of /ud, the bzr repo will live in /ud/.bzr? what if I want to pull in one dir that is outside that tree? | 20:41 |
| rubbs | I'm not sure I understand taht question. I'm guessing you mean what do you want to do if you want to verson a directory outside of that root? | 20:43 |
| slestak | yes, correct | 20:43 |
| rubbs | that I'm not sure about to be honest. | 20:44 |
| slestak | k. ty for you help. like someone else told me in here, just do it. | 20:44 |
| rubbs | haha | 20:44 |
| rubbs | always keep a backup | 20:44 |
| slestak | get into analysis paralysis designing scm layout | 20:44 |
| slestak | whats that. | 20:44 |
| slestak | j/k | 20:44 |
| rubbs | ha | 20:44 |
| rubbs | it took me a few tries before I got everything down right on my end too, but once I got it, it was totally worth it | 20:45 |
| slestak | once you decided to reset, how did you blow out the existing repo? that info isnt google-able | 20:45 |
| slestak | removeing .bzr doesnt seem to do it | 20:45 |
| === Adys_ is now known as Adys | ||
| lifeless | slestak: if you have a 'shared repo' then there will be a .bzr for the repo *and* for each branch | 20:46 |
| slestak | thats right. i will read the fine manual again before proceeding | 20:47 |
| rubbs | sorry, phone, but looks like lifeless took care of you. | 20:50 |
| thrashold | Can anyone explain the difference between bzr branch and bzr checkout? | 20:56 |
| luks | bzr checkout == bzr branch && bzr bind (more or less) | 20:56 |
| thrashold | Thanks | 20:57 |
| fullermd | Branch gives you a new branch. Checkout gives you a new working tree on the existing branch. | 20:58 |
| rubbs | branch will give you a directory containing a clone of all the history from the parent branch. A checkout will only give you a working tree (no history) of the revision specified (defaults to the HEAD). | 20:59 |
| luks | rubbs: that's lightweight checkout | 21:00 |
| thrashold | Which one I want if I want to work on the said branch and push changes? | 21:00 |
| fullermd | If you want to work independently of the existing branch, you need a new branch to work on, hence `branch`. | 21:00 |
| luks | use bzr branch unless you know you need something else | 21:01 |
| thrashold | I don't want to work independently | 21:01 |
| thrashold | OK, I'll rephrase my question | 21:01 |
| thrashold | If I just pushed a branch, is the local branch binded (a checkout) or not | 21:02 |
| rubbs | luks: ok, thanks for clearing that up for me. so heavy weight checkouts also have history, but are just bound to the parent location? | 21:02 |
| fullermd | No. | 21:02 |
| soren | If a bzr upgrade of a launchpad branch fails, how can I get access to the backup? | 21:05 |
| maxb | soren: via sftp | 21:06 |
| soren | maxb: What's the trick? | 21:06 |
| soren | sftp://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.11/backup.bzr/ does not work. | 21:06 |
| soren | (i.e. "bzr branch sftp://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.11/backup.bzr/" doesn't work) | 21:07 |
| maxb | Oh, no, you can't get it via bzr | 21:07 |
| maxb | it has to be plain sftp using a sftp client | 21:07 |
| maxb | However, for a launchpad branch, it might be easiest to just pull the public copy, which shouldn't have been replaced with a broken copy afaik | 21:09 |
| maxb | oh, or perhaps it has, here | 21:09 |
| soren | maxb: The web ui certainly looks quite upset. | 21:10 |
| soren | and bzr branch does not enjoy it either: bzr: ERROR: The branch lp:vmbuilder/0.11 has no revision None. | 21:10 |
| maxb | soren: So, I'd probably use sshfs to mount the directory over sftp, and copy the backup.bzr using cp or even nautilus. That's because I don't know of any sftp clients I like | 21:10 |
| rubbs | filezilla isn't too bad | 21:12 |
| poolie | lftp is good | 21:12 |
| soren | poolie: Does it have a recursive GET? | 21:13 |
| poolie | soren, all you need is | 21:13 |
| poolie | mv .bzr .bzr.broken | 21:13 |
| poolie | mv backup.bzr .bzr | 21:13 |
| soren | Heh.. That's true. | 21:13 |
| poolie | but actually, it does have recursive get/put, under the mirror command | 21:13 |
| soren | poolie: How do I trick launchpad into rescanning the branch? | 21:14 |
| poolie | another option is hitchhiker, which uses bzr's transport layer | 21:14 |
| poolie | hm | 21:14 |
| poolie | that i don't know | 21:14 |
| soren | poolie: Never mind. I'll be pushing to the branch in a second anyway, so that'll probably trigger something. | 21:14 |
| soren | poolie: I was just curious. | 21:14 |
| maxb | You need to do any operation which locks it | 21:14 |
| soren | poolie: Access failed: Permission denied: "Cannot create '.bzr.broken'. Only Bazaar branches are allowed." | 21:15 |
| maxb | LP is special - use .backup.bzr instead | 21:15 |
| soren | maxb: Same. Access failed: Permission denied: "Cannot create '.backup.bzr'. Only Bazaar branches are allowed." | 21:15 |
| maxb | oh, sorry, I mean .bzr.backup | 21:16 |
| poolie | we really should make it easier to roll back | 21:16 |
| poolie | soren: ok the crash is due to a known | 21:16 |
| poolie | bug | 21:16 |
| soren | poolie: Well, that's good. | 21:16 |
| poolie | from where did you install the version you're running? | 21:16 |
| soren | lucid, I think? | 21:17 |
| poolie | urk | 21:17 |
| poolie | i'll target it to lucid | 21:17 |
| soren | Hm.. I /may/ have pulled it from Debian. | 21:18 |
| poolie | ok 2.1.0-1 is now in lucid, and it has a fix for this. | 21:18 |
| soren | Ok, so what do I do? Mirror the backup branch to my local box, and do a bzr push --overwrite? | 21:19 |
| soren | It seems a big hammer, but not sure what else to do. | 21:19 |
| poolie | let's just ask an admin to fix it on lp | 21:20 |
| maxb | soren: mv .bzr .bzr.backup; mv backup.bzr .bzr | 21:20 |
| thrashold | If I just branch, I can't do just 'bzr push'. What should I do to be able to do that? | 21:21 |
| maxb | thrashold: bzr push :parent the first time, to tell bzr that this branch should push back to where it was branched from | 21:21 |
| thrashold | maxb: Thanks, I see | 21:21 |
| soren | maxb: That's what I tried above. | 21:21 |
| soren | I think. | 21:22 |
| soren | maxb: No, that's new: Access failed: No such file: u'/srv/bazaar.launchpad.net/push-branches/00/03/db/7b/.bzr.backup': [Errno 2] No such file or directory | 21:23 |
| poolie | soren this is really https://bugs.edge.launchpad.net/bzr/+bug/317732 | 21:23 |
| ubottu | Ubuntu bug 317732 in bzr "hard to do anything with backup.bzr on a remote filesystem after upgrade" [High,Confirmed] | 21:23 |
| soren | poolie: What's hitchhiker? | 21:25 |
| poolie | http://packages.ubuntu.com/lucid/hitchhiker | 21:26 |
| soren | Oh. | 21:26 |
| jelmer | oh neat, I didn't know Jaari had packaged hitchhiker | 21:28 |
| rubbs | sounds like an intersting package. | 21:30 |
| rubbs | something that could come in handy... | 21:30 |
| maxb | ftr, the most lightweight "Launchpad, please remirror my branch" incantation that I have found is: | 21:34 |
| maxb | python -c 'from bzrlib.branch import Branch as B; b = B.open("bzr+ssh://bazaar.launchpad.net/~maxb/+junk/wibble"); b.lock_write(); b.unlock()' | 21:34 |
| poolie | it is good | 21:34 |
| lifeless | maxb: there is an API call to say 'mirror now' | 21:39 |
| lifeless | maxb: or so I'm told. | 21:39 |
| spiv | I'm pretty sure there is, yeah. | 21:42 |
| jelmer | lp-shell should support -c | 21:42 |
| jelmer | but it's basically: | 21:42 |
| jelmer | lp-shell | 21:42 |
| spiv | Although it's possible that an SSH handshake and branch lock/unlock operation is more lightweight than the LP api ;) | 21:42 |
| jelmer | lp.people["jelmer"].getBranches()[0].requestMirror() | 21:43 |
| * maxb is siding with spiv, unless you can write a shorter python -c '....' using launchpadlib :-) | 21:43 | |
| jam | james_w: If you are around: https://code.edge.launchpad.net/~jameinel/bzr-builddeb/unicode-author-508251/+merge/19662 | 22:17 |
| jam | hi poolie and lifeless | 22:17 |
| poolie | hello jam | 22:17 |
| poolie | lifeless/jam: do we have a monkeypatch-helper in selftest/ | 22:25 |
| lifeless | yes | 22:25 |
| lifeless | two or more I think | 22:25 |
| lifeless | there is or was one called 'patch' in the lp plugin tests | 22:25 |
| lifeless | and vila put another one together recently - check the changelog | 22:25 |
| jam | poolie: self.overrideAttr | 22:26 |
| poolie | got it, thanks | 22:27 |
| spiv | Oh, that's right. | 22:27 |
| spiv | Thanks for the reminder, that's useful :) | 22:27 |
| poolie | i'll add it to the testing guide | 22:28 |
| spiv | What's the purpose of overrideAttr allowing the 'new' param to be optional? | 22:33 |
| poolie | to set it to null? | 22:35 |
| spiv | poolie: apparently not! | 22:36 |
| poolie | oh, maybe to protect it against being modified later in the test? | 22:36 |
| lifeless | so, I argued for a version that can permit deletes etc | 22:37 |
| lifeless | jam and vila felt it was yagni; so you should consider this a useful tool but not the last word | 22:37 |
| spiv | lifeless: I think that would be potentially nice too | 22:38 |
| spiv | lifeless: but I also agree that it might be a yagni | 22:38 |
| lifeless | sure, I mean it was not needed at the time | 22:39 |
| spiv | poolie: if it's just to protect against later modifications (and that is all I can see it being useful for), I don't think it's terribly clear or convenient. | 22:39 |
| jam | spiv: there are times when you want to set up an attribute to override, say in setUp() | 22:39 |
| jam | but you don't know the actual value | 22:39 |
| jam | until the test itself runs | 22:39 |
| jam | we had specific use cases | 22:40 |
| spiv | jam: self.overrideAttr(obj, 'attr') isn't much easier or clearer than self.addCleanup(setattr, obj, 'attr', obj.attr) | 22:40 |
| spiv | jam: I'll grant that it is a bit easier, but to me it's much less clear. | 22:40 |
| jam | spiv: you typed "attr" and "obj" twice, which gets ugly when it wraps over several lines | 22:40 |
| spiv | (And the docstring fails to explain this aspect clearly too) | 22:41 |
| jam | since the attributes are often not "attr" but "thisIsMyAttributeWhichYouAreOverriding" | 22:41 |
| spiv | Sure. | 22:41 |
| spiv | I'm not arguing against having a helper for this | 22:41 |
| jam | spiv: so once you understand what "overrideAttr" is, it turns into significantly clearer code (at least as we found when applying it to the test suite) | 22:42 |
| spiv | I'm just arguing that overrideAttr as it is now is not clear enough to be that helper. | 22:42 |
| spiv | I'd prefer a separate "self.preserveAttr" or something | 22:42 |
| jam | spiv: I think it falls into bikeshedding on name | 22:42 |
| jam | etc | 22:42 |
| spiv | And require overrideAttr to have 3 args. | 22:43 |
| spiv | It's definitely a bit bikesheddy :) | 22:43 |
| jam | spiv: I can see your point, we weren't 100% happy with the name, patches welcome :) | 22:43 |
| spiv | But it's not the *name* I mind, precisely. | 22:43 |
| poolie | i'll mention it in the guide and add a doc about that | 22:43 |
| poolie | it should mention monkeys so you can grep for them | 22:44 |
| lifeless | jelmer: please 'merge + commit', not 'push' when landing things in trunks. | 22:48 |
| lifeless | jelmer: or series branches. | 22:48 |
| jelmer | lifeless: ok | 22:49 |
| jelmer | lifeless, oh, you're getting spammed with mainline commits? | 22:49 |
| lifeless | jelmer: I love having the detail available, but each trunk commit should be tests passing, intact, correct copyright etc. | 22:49 |
| lifeless | jelmer: the spam I don't mind; the left-hand-ancestry having unapproved tree-states I do mind. | 22:49 |
| jelmer | lifeless, should I push --overwrite ? | 22:50 |
| lifeless | jelmer: no | 22:50 |
| lifeless | jelmer: I've done two merges, regrouping trunk appropriately. | 22:50 |
| jelmer | k | 22:50 |
| lifeless | lossless, you can just pull | 22:50 |
| poolie | jam, i'd almost say we should roll back to the last version that did work correctly | 22:51 |
| lifeless | jelmer: I keep a checkout of trunk, for the things I'm landing stuff in, so I can do the merge + commit very easily; I encourage you to do the same. | 22:52 |
| jam | wow, trying to build the package branch for gnome-panel has so far downloaded 700MB of data | 22:59 |
| igc | morning | 23:01 |
| BrianBatchelder | I'm seeing a lot of "No handlers could be found for logger "bzr"" in my apache error log. I'm running the smart server. Question - where is the server log supposed to be? In the root of the apache user? There is a log there, and it updates fine if I run a bzr command as the apache user, but doesn't seem to update when the smart server is used. Thanks. | 23:04 |
| spiv | BrianBatchelder: I guess your apache<->bzr glue isn't configuring bzr's builtin logging | 23:06 |
| BrianBatchelder | I think I'm using the standard setup for bzr+http. | 23:07 |
| mkanat | spiv: Yeah, I see that error too, actually, on Mozilla's bzr server, when doing checkouts over SSH. | 23:07 |
| mkanat | (Actually, when doing any command over SSH.) | 23:07 |
| BrianBatchelder | I wonder if there is something missing from the "bzr-smart.py" script. It's pretty basic. | 23:08 |
| spiv | BrianBatchelder: you have a file somewhere that does "from bzrlib.transport.http import wsgi", and then something like "wsgi.make_app(..., enable_logging=True)"? | 23:08 |
| spiv | BrianBatchelder: pastebin your bzr-smart.py script? | 23:09 |
| BrianBatchelder | Wait, not "enable_logging=True" | 23:09 |
| BrianBatchelder | Let me look at bzrlib.transport.http.wsgi | 23:09 |
| spiv | See the examples in http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html | 23:09 |
| BrianBatchelder | Ah, I see. Don't have either of those last two lines. Perhaps they came into existence in a bzr rev beyond the one we first installed. | 23:11 |
| lifeless | jam: vfs fetching? | 23:12 |
| jam | lifeless: downloading orig.tar.gz for every version that uses it | 23:13 |
| jam | regardless if it was downloaded before | 23:13 |
| lifeless | hah. oops. | 23:13 |
| spiv | BrianBatchelder: yeah, could be | 23:13 |
| jam | lifeless: https://bugs.edge.launchpad.net/udd/+bug/524123 | 23:14 |
| ubottu | Ubuntu bug 524123 in udd "import_package re-downloads files multiple times" [Undecided,New] | 23:14 |
| jam | Comments on it would be appreciated | 23:14 |
| jam | in case I misunderstand something | 23:14 |
| jam | the full url is different | 23:14 |
| jam | because it is based on a different upstream import | 23:14 |
| lifeless | hmm | 23:14 |
| jam | but the filename is the same each time | 23:14 |
| jam | sorry, not upstream | 23:14 |
| lifeless | so the orig tarball can differ between ubuntu and debian | 23:14 |
| lifeless | but not within ubuntu or within debian | 23:15 |
| jam | but "...ubuntu1" "...ubuntu2" etc | 23:15 |
| jam | anyway, time for me to go | 23:15 |
| lifeless | a cache by hash would be safe | 23:15 |
| BrianBatchelder | spiv: It seems to default to "True", and yet, sill no logging. Or, at least, VERY sparse logging. Or I can't find the right log. | 23:15 |
| BrianBatchelder | I'm wondering if I need to set BZR_LOG in my apache environment. | 23:26 |
| Kamping_Kaiser | are subvertpy questions on or off topic in here? | 23:29 |
| spiv | BrianBatchelder: yeah, you may need to set BZR_LOG | 23:32 |
| spiv | Kamping_Kaiser: it's probably more on-topic here than anywhere else | 23:32 |
| poolie | igc, how are you getting the 'latest blogs' onto the page? manually? | 23:32 |
| spiv | BrianBatchelder: but the 'no handlers' warning suggests the log file isn't being opened successfully, IIRC | 23:32 |
| spiv | BrianBatchelder: which bzr version? | 23:33 |
| BrianBatchelder | 1.17 | 23:33 |
| igc | poolie: yes. I'm looking into generating those links as we speak | 23:33 |
| spiv | BrianBatchelder: Ah ok. I'd try 2.1; I think there's been some improvements to the way bzr reports problems with logging. | 23:33 |
| spiv | BrianBatchelder: so, 2.1 probably won't fix the problem, but IIRC it will give a more informative warning | 23:34 |
| BrianBatchelder | I'm planning on doing the upgrade at some point, but I'll need to stage it with the users. Thanks for the info | 23:35 |
| spiv | BrianBatchelder: I expect bzr is trying to open ~/.bzr.log, which might not be something that works depending on how your apache runs | 23:35 |
| spiv | BrianBatchelder: but overriding BZR_LOG in your environment should fix that | 23:35 |
| Kamping_Kaiser | spiv: i just noticed that despite the subvertpy packaging depending on libsvn >= 1.6, its still trying to build with 1.5, so i guess my question is a packaging bug for jelmer rather thena real question | 23:35 |
| spiv | BrianBatchelder: another option could be to pass enable_logging=False in your script, and then calling the logging setup stuff directly the way you need it | 23:36 |
| BrianBatchelder | If I login as the apache user, bzr logs just fine to "/var/www/.bzr.log". But logging in is certainly different than loading apache. | 23:36 |
| BrianBatchelder | spiv: I'll take a look at the 1.17 code and see if I can do that. | 23:36 |
| spiv | BrianBatchelder: I'd suggest just reading the source to wsgi.make_app and bzrlib/trace.py if you do that | 23:36 |
| BrianBatchelder | That's where I've been looking. | 23:37 |
| spiv | BrianBatchelder: sorry I don't remember enough details off the top of my head to be more helpful :/ | 23:37 |
| BrianBatchelder | This is off the top of your head? I'm impressed! | 23:37 |
| jelmer | Kamping_Kaiser: ? | 23:41 |
| jelmer | Kamping_Kaiser: subvertpy can build with svn >= 1.4 | 23:41 |
| jelmer | Kamping_Kaiser, in your case it probably built against 1.6 | 23:41 |
| jelmer | but there's no dependencies other than >= 1.4 in the packaging | 23:41 |
| Kamping_Kaiser | jelmer: odd. its bombing out. http://paste.debian.net/60441/ "NotImplementedError: Subversion 1.5 does not provide svn_string_from_stream(). | 23:42 |
| Kamping_Kaiser | " | 23:42 |
| Kamping_Kaiser | jelmer: attempting to build the package from testing on stable | 23:42 |
| spiv | BrianBatchelder: well, I wrote the bzr http smart server code, but it's been a while :) | 23:44 |
| BrianBatchelder | spiv: oh, man, glad I didn't flame the smart server code! ;-) | 23:45 |
| jelmer | Kamping_Kaiser, oh | 23:46 |
| jelmer | Kamping_Kaiser, we should probably disable that test | 23:47 |
| spiv | BrianBatchelder: :) | 23:48 |
| spiv | BrianBatchelder: don't worry, I already know that its logging is crummy :/ | 23:49 |
| Kamping_Kaiser | jelmer: how would i do that on the package, simply delete the test file? | 23:49 |
| jelmer | Kamping_Kaiser: just the test itself | 23:50 |
| Kamping_Kaiser | jelmer: removing the test makes it build, thanks :) | 23:56 |
| Kamping_Kaiser | hm, python 2.4 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!