| soren | --overwrite :) | 00:00 |
|---|---|---|
| spiv | Woah, jam's change to resolve lp:foo locally stops automatic stacking from working | 00:17 |
| spiv | https://bugs.launchpad.net/bzr/+bug/741375 filed | 00:25 |
| ubot5 | Ubuntu bug 741375 in Bazaar "r5736 to resolve lp:foo URLs locally prevents automatic stacking of new branches pushed to Launchpad" [Critical,Confirmed] | 00:25 |
| lifeless | is lp bug I think | 01:00 |
| lifeless | spiv: ^ | 01:00 |
| spiv | lifeless: maybe! I agree it's a server-side bug, but not sure if it's in bzr or lp | 01:02 |
| lifeless | spiv: if lp isn't sending the hint to bzr, its lp | 01:02 |
| spiv | Perhaps that's enough reason to add lp to the bug, I certainly don't mind if you do | 01:03 |
| lifeless | done :) | 01:03 |
| spiv | Ta :) | 01:03 |
| mwhudson | er | 01:17 |
| mwhudson | oh right, i bet we don't do the magic we need to at +branch/~user/product, just at ~user/product | 01:17 |
| * mwhudson looks at launchpad's translatePath, grumbles | 01:26 | |
| mwhudson | oh no, it's not as silly as i feared | 01:27 |
| mr-russ-work | What the deal with the patch manager spelling my name wrong. | 02:45 |
| mr-russ-work | spiv: can you correct the spelling of my name? | 02:46 |
| poolie | thanks for the bug love spiv | 02:52 |
| poolie | i think i got us to 0 new yesterday | 02:52 |
| spiv | mr-russ-work: oop! | 02:59 |
| spiv | mr-russ-work: oops! | 02:59 |
| spiv | mr-russ-work: that would be my fault :( | 02:59 |
| spiv | mr-russ-work: I can add a new commit on top with a message like "Correction: r5739 was contributed by Russell Smith." Hmm, I should add a release-notes entry about the change too, I could do that in the same commit | 03:02 |
| mr-russ-work | thanks. | 03:04 |
| mr-russ-work | Otherwise, I'm happy that landed merged for 2.4. | 03:06 |
| spiv | mr-russ-work: ok, new commit on its way to PQM | 03:07 |
| spiv | Me too! | 03:07 |
| === psynaptic is now known as psynaptic|away | ||
| jam | spiv: did you track down anything with the bug? | 06:22 |
| jam | I have some ideas, but I don't want to overlap too much | 06:22 |
| spiv | jam: not yet | 06:40 |
| poolie | hi jam | 07:40 |
| poolie | jam do you know off hand if we include the inum in the dirstate hash? | 07:40 |
| lifeless | inode? pretty sure not | 07:50 |
| lifeless | poolie: return _encode(_pack('>LLLLLL', st.st_size, int(st.st_mtime), | 07:51 |
| lifeless | int(st.st_ctime), st.st_dev, st.st_ino & 0xFFFFFFFF, | 07:51 |
| lifeless | st.st_mode))[:-1] | 07:51 |
| poolie | so yes | 07:54 |
| vila | hi all ! | 07:56 |
| jam | poolie: if you mean inode, then yes | 08:11 |
| jam | st.st_ino | 08:11 |
| jam | poolie: we've talked about not including st_dev or st_ino | 08:12 |
| jam | we just never changed anything | 08:12 |
| poolie | yep | 08:38 |
| poolie | hi vila | 08:38 |
| vila | hey poolie ;) | 08:38 |
| jam | poolie: I think a lot of that was stuck in the "next dirstate revamp" | 08:39 |
| jam | where we also wanted to get away from base64 | 08:39 |
| jam | in favor of just %X, etc. | 08:39 |
| poolie | right | 08:40 |
| poolie | some of them, like ctime, could be done incrementally | 08:40 |
| jam | poolie: I think we wanted to switch to max(ctime, mtime) | 08:40 |
| jam | partially because ctime means something completely different on Windows | 08:41 |
| jam | and partially because it seemed silly to always check 2 times, when of course only one will ever win | 08:41 |
| poolie | i think ctime there is creation time | 08:45 |
| poolie | using the latest would still be invalidated by hardlinking | 08:45 |
| poolie | which updates the ctime | 08:45 |
| jam | poolie: on Windows ctime == creation, on Linux ctime == last time metadata was updated. | 08:45 |
| poolie | right :) | 08:45 |
| jam | anyway, the point is that our check is (if mtime > X or ctime > X) | 08:46 |
| jam | we can just do (if max(mtime, ctime) > X) | 08:46 |
| jam | and then we can store 1 less field per file | 08:46 |
| poolie | yes, that would be equivalent, but it wouldn't fix the bug abentley just mentioned | 08:47 |
| === hunger_ is now known as hunger | ||
| jam | poolie: it isn't in my traceback here, is it on a different channel? | 08:47 |
| poolie | https://bugs.edge.launchpad.net/bzr/+bug/741515 | 08:48 |
| ubot5 | Ubuntu bug 741515 in Bazaar "dirstate validator includes ctime" [Medium,Confirmed] | 08:48 |
| jam | poolie: so certainly there is the idea of do we need "mtime != old_mtime or ctime != old_ctime", it is a question of worth, though. | 08:49 |
| jam | If someone does tricks with hard-linking, we can ask them to do "touch" as well | 08:49 |
| jam | I though hard-linking updated ctime | 08:50 |
| jam | and I should correct myself. ATM I believe we do check if mtime == cached_mtime, and just have a (if now - mtime < 1s, don't cache) | 08:50 |
| jam | certainly we expect a change today to be noticed by 'bzr status' tomorrow | 08:51 |
| poolie | one of us is confused | 08:51 |
| poolie | hard linking does update ctime | 08:51 |
| jam | #1, I don't know the bug you are mentioning | 08:52 |
| jam | you said "yes, that would be equivalent, but it wouldn't fix the bug abentley just mentioned" | 08:52 |
| poolie | ah ok | 08:52 |
| jam | I don't know what that bug is | 08:52 |
| poolie | i just filed it based on aaron's comment in the big colo thread | 08:52 |
| poolie | which was essentially that 'bzr branch --hardlink' has the substantial drawback that | 08:52 |
| poolie | the next operation in each of the trees will need to rescan them | 08:53 |
| poolie | since making the hardlinks invalidates the dirstate | 08:53 |
| jam | poolie: well, there is already a bug, that the "bzr branch" target already needs to rescan the tree. But I see your point. You only created a new hardlink on the source, and now it needs to be rescanned. | 08:54 |
| jam | I don't think we can ignore ctime, though | 08:54 |
| jam | because that is how you see 'chmod' changes. | 08:54 |
| jam | you could say "only look at ctime for mode info, and only mtime for content' | 08:54 |
| jam | but I think that is just getting spun around | 08:54 |
| jam | too many rules makes it hard to predict behavior | 08:54 |
| poolie | well | 08:55 |
| poolie | checking the mode is as cheap as checking the timestamp | 08:55 |
| poolie | there is no point cachingi t | 08:55 |
| poolie | i agree we don't want too many rules though | 08:56 |
| jam | poolie: the issue is how much stuff do you want to put into the "is this changed" function | 08:57 |
| jam | I think we do some filtering at a fairly low level | 08:58 |
| jam | but yes, we don't need to use ctime to check mode | 08:58 |
| poolie | i think it would be sufficient to just cut ctime out, which would make it simpler | 08:58 |
| poolie | but, i only marked it Medium importance | 08:59 |
| poolie | thanks for grabbing the lpurl thing | 09:04 |
| poolie | even if it hit a snag | 09:04 |
| poolie | i'd been meaning to try that forever | 09:04 |
| jam | poolie: well, since it isn't on our side, it is tricky :) | 09:04 |
| jam | but yes | 09:04 |
| jam | I was surprised to see it be >1s on my machine here | 09:04 |
| jam | because of the ssl handshake now | 09:05 |
| poolie | >1s going to lp.dev? | 09:05 |
| jam | I'm not sure when we switched to https://xmlrpc | 09:05 |
| jam | but it certainly shows up in the logs | 09:05 |
| jam | doing "bzr push lp:" has *2* handshakes | 09:05 |
| poolie | why? | 09:06 |
| jam | poolie: we ssl handshake to https://xmlrpc then SSH handshake with bzr+ssh | 09:12 |
| poolie | oh, ssl and ssh | 09:16 |
| poolie | i thought you meant two on ssl | 09:16 |
| jam | no, just 2 handshakes that each take 1+s to complete before we can send a few bytes of actual content | 09:31 |
| === psynaptic|away is now known as psynaptic | ||
| jam | poolie: are you going to be around? It seems you should be off frolicking in the sunshine right now? | 09:43 |
| jam | Just some thoughts about the lp: stuff I wanted to run by you | 09:43 |
| poolie | not much 9pm suntime at this time of year | 09:44 |
| poolie | indeed not at any time of year in sydney | 09:44 |
| poolie | so go for it | 09:44 |
| poolie | S is away this week and next | 09:44 |
| poolie | i was trying to decide if i was hungry | 09:44 |
| jam | poolie: :) I know the feeling | 09:48 |
| jam | poolie: I'm trying to work out how much validation we should do in the local resolution | 09:48 |
| jam | right now, I'm thinking that if the url doesn't conform to exactly what I think it should, then I just punt and tell it to resolve against LP to give a proper error | 09:48 |
| poolie | that sounds pretty good | 09:49 |
| poolie | you mean you fall back to the existing behaviour? | 09:50 |
| poolie | i think it would be good to make sure eventually that the exact same behaviour the xml service gives you is also available over ssh | 09:50 |
| poolie | but obviously that requires server changes | 09:50 |
| poolie | i'm just writing to elliot about who should do bfbip and when | 09:50 |
| poolie | it seems like lp is pretty queued up; we _could_ but i don't know if that would be a good idea | 09:51 |
| jam | poolie: yeah, lp teams do seem pretty "fully booked" | 09:55 |
| poolie | yeah, and even for the things they have taken on, they seem to run long | 09:55 |
| jam | poolie: Right now I'm doing some validation of what I get from XMLRPC vs what I get doing it myself | 09:55 |
| poolie | as does everybody, probably | 09:55 |
| jam | poolie: projects generally scale to the time you have allotted them, + some percent :) | 09:55 |
| jam | It is rare that there isn't *something* more that you could do if given the time | 09:56 |
| jam | poolie: so for lp: resolution, the only thing I see right now, is that XMLRPC validates the 'distribution' part | 09:56 |
| jam | for "~jameinel/ubuntu/XXX/bzr/foo" Iget "No such distribution series" from XMLRPC | 09:57 |
| poolie | oh, the distroseries, not the distribution | 09:57 |
| jam | If I do a bunch of other permutations, I get errors that are obvious | 09:57 |
| poolie | so if you just mechanically map it, you'll just get 'not found' or 'permission denied' from ssh? | 09:57 |
| jam | poolie: probably, I haven't actually tried on all of them | 09:57 |
| jam | note that you can do (today) | 09:57 |
| jam | bzr info lp:ubuntu/foo/bar/baz/bing/blah | 09:57 |
| jam | and it will resolve to +branch... | 09:58 |
| jam | and then give "no such branch" | 09:58 |
| jam | it is only if you add a ~user that it tries to validate the URL as much | 09:58 |
| poolie | so, i would be inclined to just mechanically locally transform them to bzr+ssh://..../+branch/$1 | 09:58 |
| poolie | and then treat anything where that does not behave well as an lp bug in lp-serve | 09:58 |
| poolie | unless it goes horribly wrong | 09:58 |
| jam | lp:~jameinel/ubuntu/natty/bzr/foo/bar | 09:58 |
| jam | also resolves | 09:59 |
| poolie | validation at the xml server is redundant | 09:59 |
| poolie | what was the bug about stacking? | 09:59 |
| jam | poolie: sure, I think it meant to be about giving the user nicer error messages | 09:59 |
| jam | poolie: the stacking bug is that there isn't a bzr control dir in +branch/~user/project/.bzr | 09:59 |
| jam | so it dosen't tell +branch/~user/project/branch/ to stack | 10:00 |
| jam | there *is* one in the virtual ~user/project/.bzr | 10:00 |
| poolie | huh | 10:00 |
| poolie | what is there? | 10:00 |
| poolie | is it more like a redirect, or an alias? | 10:00 |
| jam | poolie: just a .bzr/config I think, with a message "you should stack on DEV_FOCUS" | 10:00 |
| jam | poolie: so when bzr searches up to see if there is a containing repo/etc, it sees the config telling it "this is how you want to act" | 10:00 |
| maxb | A control.conf, no? | 10:01 |
| jam | I'm sure it is a virtual folder as well, and could just be added to +branch/~user/project/ | 10:01 |
| jam | maxb: probably | 10:01 |
| jam | poolie: but *we* should be careful and compatible with the existing code for now (IMO) | 10:01 |
| maxb | found error:Internal check failed: revno does not match len(mainline) 48 != -1 | 10:02 |
| maxb | Um, yay, I seem to have managed a branch with a ghost on the mainline, though some stacking weirdness | 10:02 |
| jam | poolie: from what I can tell with XMLRPC, if you have ~user, then it tries to map to bzr+ssh://bazaar.launchpad.net/~user... and if you don't, then it maps to bzr+ssh://bazaar.launchpad.net/+branch/$1 | 10:02 |
| maxb | Anything starting with ~user should be the full unique name of a branch. Anything not starting with a ~ starts with a pillar name and goes via the aliasing rules | 10:04 |
| poolie | no, i mean, how does +branch work | 10:04 |
| poolie | does it redirect you to the canonical name, or does it just present that content? | 10:04 |
| iqpi | hi guys, i am wondering about with is a greater solution for a project developement git or bzr? I think they are very similar in their basics. | 10:11 |
| iqpi | wich* | 10:11 |
| vila | iqpi: bzr. (Though if you ask in #git they may have a different opinion ;) | 10:12 |
| iqpi | vila: yes i know, but i want to know why, i don't find any complete information. | 10:14 |
| poolie | tell us a bit about your project | 10:14 |
| maxb | Your question is unanswerable due to being hopelessly broad | 10:14 |
| jam | poolie: it pretends it is the real branch | 10:14 |
| jam | poolie: it doesn't redirect, it is done in the VirtualFS mapping | 10:15 |
| jam | poolie: just as ~jameinel/bzr/branch actually maps somewhere on /host/00/12/34/56/ | 10:15 |
| jam | poolie: +branch/bzr maps to a similar /host/00/12/34/66 sort of real-world dir | 10:16 |
| iqpi | well my project is about to let use ffmpeg to linux users. Multimedia file codification under linux is a pain due we have very powerful tools such ffmpeg or mencoder, but they are fucking hard to use, even, with the frontends it is very difficult because you need to have a lot of knowledge about codecs, formats aspects ... so i am writting a program | script that allow linux users to do some common things with multimedia files, like convert from | 10:17 |
| iqpi | --title="LEEncoder"\ | 10:17 |
| iqpi | --text="Selecciona qué vídeo quieres silenciar" | 10:17 |
| iqpi | zenity --info \ | 10:17 |
| iqpi | --title="LEEncoder"\ | 10:17 |
| iqpi | --text="Selecciona qué vídeo quieres silenciar" | 10:17 |
| iqpi | sorry for the flood :S | 10:18 |
| iqpi | ...without any knowledge about codecs, bitrates formats, and so on. | 10:18 |
| vila | iqpi: there are many differences between git and bzr that may be relevant to give you a meaningful answer: number/size of dir/files, number of revisions, number of devs involved, shared server availability, control over the software used on the server, preferred workflows, etc | 10:19 |
| iqpi | size is just few kb, dir... in current branch just one dir with tree files. | 10:20 |
| vila | iqpi: then I think bzr will be easier to start with than git (based on feedback *we* hear, this-is-not-a-metric usual disclaimer applies) | 10:21 |
| poolie | agree | 10:21 |
| poolie | thanks for pushing the package importer vila | 10:22 |
| poolie | btw spm is working on the bzr upgrade there | 10:22 |
| poolie | i think the package is rebuilding | 10:22 |
| poolie | and i expect he will install it tomorrow | 10:22 |
| * vila humbly bows | 10:23 | |
| vila | poolie: \o/ 2.3.1 ? | 10:23 |
| poolie | not at all, thanks for the reminder | 10:23 |
| poolie | yes | 10:23 |
| poolie | so, generally speaking, we should still go through the ppa | 10:23 |
| iqpi | thank you vila =) I have already set up a svn repo, but i don't like the way that svn works, with just a branch | 10:23 |
| vila | poolie: ok, no worries, I have a backup plan 8) | 10:24 |
| iqpi | only just another question, could i set up a bzr repo with sourceforge? | 10:24 |
| * vila cp ~/src/bzr/trunk/bzrlib/config.py ~/src/udd/trunk/bzrconfig.py :-D | 10:24 | |
| vila | iqpi: http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar | 10:25 |
| vila | iqpi: they mention 1.10 though which is an oooooooold version (2.3.1 is the current stable) | 10:26 |
| iqpi | vila: i was just surfering that web, sorry for asking here before searching :S | 10:26 |
| vila | iqpi: alternatively if your project is FLOSS, launchpad.net is said to be very nice too ;) | 10:26 |
| iqpi | thank you vila for the advice, i will read about it, and yes it is a FLOSS project :D | 10:28 |
| vila | iqpi: https://launchpad.net/+tour | 10:28 |
| fullermd | That SF doc is oold. ping says they're running 2.0.3 (which is still oooold, but...) | 10:36 |
| poolie | ok | 10:44 |
| poolie | getting things done, yay | 10:44 |
| iqpi | wow, launchpad seems to be awesome 0.0 | 11:06 |
| jam | iqpi: we like it :) | 11:12 |
| jam | vila: care to do a quick review on: https://code.launchpad.net/~jameinel/bzr/2.3-three-part-resolution-stacking-741375/+merge/54677 | 11:13 |
| ubot5 | Error: Launchpad bug 2 not found | 11:13 |
| jam | ubot5: not every launchpad URL is a bug, you know | 11:13 |
| ubot5 | Error: I am only a bot, please don't think I'm intelligent :) | 11:13 |
| jam | I know you aren't :) | 11:13 |
| iqpi | I think this afternoon i will migrate my project from sourceforge to launchpad. Thanks for the info! | 11:13 |
| jam | vila: I'd like to plug the "lp:" urls don't stack bug quickly. | 11:13 |
| vila | jam: yeah, got that, but I first thought: Wtf, what kind of merge issue is he working on ? | 11:14 |
| vila | jam: the tests seem nicely extensive ! | 11:16 |
| jam | vila: after having the fallout, I made sure to expand test coverage a bit | 11:16 |
| jam | it is unfortunate that the real validation is only against LP itself | 11:16 |
| vila | jam: I can't say from reading the code, but: Are you reaching the real lp server there ? | 11:16 |
| jam | vila: in the tests? no | 11:17 |
| jam | Intentionally not (FakeResolution) | 11:17 |
| jam | -Dlaunchpad does | 11:17 |
| vila | jam: we already have issues with tests that reach lp, so you *could* add more as long as we have a feature (and even maybe some config/cmd-line option to control it) | 11:18 |
| vila | wow ! | 11:18 |
| vila | We do ? | 11:18 |
| jam | vila: you seem to be confusing yourself (and me) | 11:19 |
| vila | jam: what does '-Dlaunchpad' ? | 11:19 |
| jam | vila: bzr COMMAND -Dlaunchpad adds a debug flag | 11:19 |
| jam | one thing it does (now) is to always query the XMLRPC server, and print out the results | 11:19 |
| jam | vila: I wonder if I should also make it use the XMLRPC's response instead of the local one? | 11:20 |
| vila | oh, didn't notice you added it (should be documented in debug.py with the others then) | 11:21 |
| jam | vila: true | 11:21 |
| jam | will do now | 11:21 |
| vila | jam: ok, so my suggestion was to add a control flag so we can control whether or not the tests hits the real lp server (jelmer mentioned having to disable the lp plugin during builds otherwise) | 11:21 |
| jam | '-Dlaunchpad' already existed, but maybe not as documented? | 11:22 |
| jam | It is in a "plugin" | 11:22 |
| jam | so I imagine those don't usually get documented | 11:22 |
| jam | vila: do you want it anyway | 11:22 |
| jam | ? | 11:22 |
| vila | jam: then you can safely add more tests relying on that to make sure you correctly assert the lp behavior | 11:22 |
| vila | jam: your call, doesn't have to be part of this submission | 11:22 |
| jam | vila: they are going to be *slooow* like 1s for each XMLRPC call | 11:23 |
| jam | (which is why I wrote the code in the first place) | 11:23 |
| vila | AIUI we already have some | 11:23 |
| vila | jam: if we control them we can decide whether or not we want them on or off by default too, babune won't care to wait some more seconds | 11:23 |
| jam | vila: how about I submit a low-priority bug that we could add tests like that? | 11:24 |
| vila | trace.note is for both .bzr.log and display on stdout/stderr (can't remember) ? | 11:25 |
| jam | vila: yes | 11:25 |
| jam | mutter => only .bzr.log | 11:25 |
| jam | note => screen and log | 11:25 |
| vila | jam: wfm (bug), jelmer can then comment about the build issue | 11:25 |
| jam | warning => adds more warning info? | 11:25 |
| vila | hmm, isn't screen a bit too much there ? ... well, only once by resolution I guess so generally only one by bzr command ? | 11:26 |
| vila | jam: as long as you land on trunk, we'll have time to refine anyway, approved | 11:26 |
| jam | vila: if you are doing -Dlaunchpad to see if the resolution is correct, I assumed you wanted to *see* it. | 11:27 |
| vila | jam: there may be another bug against lp about the weird behavior there (I didn't follow closely your discussion with poolie, maybe you already filed one) | 11:27 |
| jam | I certainly should update NEWS about that, though | 11:27 |
| jam | vila: I think there is a bug in lp codehosting | 11:28 |
| vila | jam: meh, of course, sorry | 11:28 |
| jam | but at least we can have it lower priority | 11:28 |
| jam | since bzr won't be provoking it | 11:28 |
| vila | jam: just make sure to remove the duplicate qastaging entry | 11:28 |
| vila | jam: sorting them will wfm too (dunno how you ended it up with the dupe, but sorting may help in the future) | 11:30 |
| jam | vila: 2.3 doesn't have qastaging | 11:30 |
| jam | 2.4 does | 11:30 |
| jam | hence the dupe | 11:30 |
| vila | ha, hmm :-/ | 11:30 |
| jam | It seemed reasonable to land in 2.3 | 11:31 |
| jam | if we decide the rest of the patch can land in 2.3 | 11:31 |
| jam | so I went with it | 11:31 |
| jam | I also *really* wanted to test it | 11:31 |
| vila | good job there | 11:32 |
| jam | vila: bug #741633 fyi | 11:33 |
| ubot5 | Launchpad bug 741633 in Bazaar "Local lp: resolution could be tested against Launchpad" [Low,Confirmed] https://launchpad.net/bugs/741633 | 11:33 |
| jam | back in a bit, heading out for lunch | 11:58 |
| rhlee | hi guys, how do I use bzr shelve destroy ? | 12:20 |
| briandealwis | rhlee: I believe it just wipes out the changes rather than saving them as a shelf | 12:49 |
| rhlee | briandealwis: but how do I invoke it? | 12:50 |
| briandealwis | rhlee: so it's equiv to 'bzr shelve && bzr unshelve —delete-only' | 12:50 |
| briandealwis | rhlee: bzr shelve —destroy | 12:50 |
| briandealwis | ? | 12:50 |
| briandealwis | it'll prompt you just as a normal 'bzr shelve' | 12:50 |
| briandealwis | at least that was my experience using it yesterday :) | 12:51 |
| rhlee | oh I see now, it essentially does a revert | 12:52 |
| briandealwis | yeah, but a more selective revert — you can revert portions of a file | 12:52 |
| rhlee | briandealwis: ok got that now, I see the use case now, thanks | 12:53 |
| ScottK | Is it a bug or a feature that if you push after tagging, but no new revisions are present the only feedback is "No new revisions to push" and there's no indications that tags got pushed? | 12:55 |
| jam | ScottK: known bug, I believe | 12:55 |
| ScottK | OK. | 12:55 |
| jelmer | jam: is ~mgiuca/bzr/log-not-in-branch ready to land? | 13:10 |
| jam | jelmer: if it has a second approve, I think so | 13:13 |
| === psynaptic is now known as psynaptic|lunch | ||
| jelmer | jam: that can be arranged :) | 13:19 |
| vila | james_w: I think I addressed your comments on https://code.launchpad.net/~vila/udd/719888-log-config/+merge/54572 , can you review again (pretty please ;) ? | 13:27 |
| ubot5 | Ubuntu bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,In progress] | 13:27 |
| james_w | sure | 13:28 |
| james_w | vila, 150+# FIXME: We don't inherit from LockableConfig because we don't want to create a | 13:30 |
| james_w | is that really a FIXME? | 13:30 |
| vila | james_w: it's at least unclear what will be done in the long run so I prefer to have a FIXME deleted later than a bad design forgotten | 13:31 |
| james_w | vila, approved, thanks | 13:32 |
| vila | james_w: maybe it's too esoteric in this context, but the issue is that all *current* config files rely on having a .bzr handy to create a 'lock' dir there and I did realize that when creating this p-i specific config file | 13:33 |
| vila | james_w: thanks to you ! | 13:33 |
| vila | james_w: nothing wrong in the deployment plan from your pov ? | 13:33 |
| james_w | vila, nope | 13:34 |
| vila | cool. Now I need a losa to torture ;) | 13:34 |
| === psynaptic|lunch is now known as psynaptic | ||
| jelmer | jam, vila: do you know where the architecture guide lives? | 14:06 |
| vila | not precisely, I'd start searching in doc/developers | 14:08 |
| vila | jelmer: not sure it's a document per se, may be more about concepts spread across several files and referred to as such | 14:09 |
| === psynaptic is now known as psynaptic|away | ||
| vila | jelmer: in other words, you may have to start your own document on the topic ;) | 14:10 |
| jelmer | heh, ok | 14:10 |
| vila | jelmer: it's about the foreign stuff right ? | 14:10 |
| jelmer | vila: about colocated branches | 14:10 |
| vila | bah, forget me | 14:10 |
| jelmer | vila: with the work I've been doing recently, foreign branches are not a bad guess though ;) | 14:11 |
| jelmer | vila: it has some overlap, John Barstow was asking about colocated branches and bzr-tfs | 14:11 |
| vila | yeah, I'm sure you can even make a proposal with just documenting all the stuff you did there :-) | 14:12 |
| === psynaptic|away is now known as psynaptic | ||
| vila | jelmer: you know, mentioning it briefly in the what's new, a bit more in release notes and a big explanation in doc/developers ;) | 14:13 |
| vila | jelmer: semi-seriously, a brain dump *now* would be better than a more elaborate prose... in 6 months ;) | 14:13 |
| * vila will be well advised to the same for the package importer no ? | 14:14 | |
| vila | s/to/to do/ | 14:14 |
| jelmer | vila: you've never seen my prose. :-P | 14:14 |
| jelmer | but yeah, writing something up is probably a good idea | 14:14 |
| vila | jelmer: what ?? Isn't your name on at least one book ? :D | 14:15 |
| jelmer | vila: Heh, true. It's non-fiction though (or at least, it should be...) | 14:16 |
| * jelmer discovers he did write developer docs for his colocated branch work and forgot about it | 14:19 | |
| jelmer | jam: Any chance you could have another look at https://code.launchpad.net/~jelmer/bzr-gtk/vertical-layout/+merge/50446 ? | 14:36 |
| ubot5 | Ubuntu bug 50446 in ubiquity (Ubuntu) "GRUB not installed because of some reading error (dup-of: 47194)" [Undecided,New] | 14:36 |
| ubot5 | Ubuntu bug 47194 in ubiquity (Ubuntu) "qtparted seems to crash on some setups; deal with this better?" [Medium,Fix released] | 14:36 |
| jam | jelmer: I can look at it, but I can't say I fully understand what I'm looking for | 14:41 |
| jam | jelmer: looks broken | 14:45 |
| jam | it does move everything to the side as requested | 14:45 |
| jam | and that looks ok | 14:45 |
| jam | except after I do so | 14:45 |
| jam | I no longer see the actual information for a Revision | 14:45 |
| jam | when I select a new rev | 14:45 |
| jam | jelmer: If I change the setting, and restart, everything works ok | 14:46 |
| jam | but changing the setting breaks data updates | 14:46 |
| jelmer | jam: I'll have another look - thanks | 14:51 |
| jam | jelmer: what ubuntu mirror do you use? | 14:59 |
| jam | (I guess I get max bandwidth from archive.ubuntu.org directly, but figure I should play nice) | 14:59 |
| jelmer | jam: I'm using the trick mvo just published about | 15:00 |
| jelmer | deb mirror://mirrors.ubuntu.com/mirrors.txt natty-backports main restricted universe multiverse | 15:00 |
| jelmer | that's supposed to pick a local mirror | 15:00 |
| jam | jelmer: so it pics a random mirror? | 15:00 |
| jelmer | jam: yeah, though a random dutch mirror in my case | 15:01 |
| jam | jelmer: looks like it grabs your ip address and then builds it custom for you | 15:02 |
| jelmer | jam: yeah, it uses geoip | 15:02 |
| jam | the first entry is, indeed, a .nl | 15:02 |
| jam | from vila's machine, the first entry is a .fr | 15:02 |
| jam | nice trick | 15:02 |
| vila | I always use the main server at it seems to provide the most bandwidth ;) | 15:04 |
| jelmer | all of the .nl machines I have seen so far do up to 2Mb/s, which is the maximum I can get out of my internet connection too | 15:37 |
| === deryck is now known as deryck[lunch] | ||
| jam | jelmer: 2Mb or 2 MB ? | 15:42 |
| jam | big difference | 15:42 |
| jam | I get 870kB/s from archive.ubuntu.com, which is all the bandwidth the apartment has | 15:42 |
| jam | the new place is supposed to have 40Mb/s | 15:42 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| === Ursinha is now known as Ursinha-lunch | ||
| jelmer | hmm, my sound card driver is playing russian roulette with me :-/ | 17:11 |
| === psynaptic is now known as psynaptic|afk | ||
| jxself | www.gnu.org is currently mantained under CVS, and we'd like to move to Bazaar. This is my first attempt at the CVS -> Bazaar migration: http://dpaste.com/525282/ Suggestions? | 17:43 |
| jelmer | jxself: looks like bzr-cvsps-import wasn't updated for the latest version of bzrlib | 17:48 |
| jelmer | jxself: try lp:~jelmer/bzr-cvsps-import/avoid-note | 17:48 |
| jelmer | jxself: there's also cvs2bzr, which I guess is more commonly used | 17:52 |
| jxself | jelmer: Thank you. Will look into that shortly. | 17:55 |
| === Ursinha-lunch is now known as Ursinha | ||
| === psynaptic|afk is now known as psynaptic | ||
| === psynaptic is now known as psynaptic|away | ||
| jxself | jelmer: I've applied that. It now outputs Creating cvsps dump file: /home/jason/Desktop/www-bzr/staging/ROOT.dump. Should I expect that file to be growing? | 20:27 |
| jxself | It's not. | 20:28 |
| jxself | And current system load is reporting load average: 0.00, 0.02, 0.05 so I'm not sure that anything's actually happening.. | 20:29 |
| vila | jelmer: you probably should unload it, russian roulette is dangerous with loaded things ;) | 20:39 |
| === r0bby is now known as robbyoconnor | ||
| fullermd | vila: Yeah, but it's _boring_ if it's unloaded :p | 21:00 |
| === psynaptic|away is now known as psynaptic | ||
| knighthawk | there doesn't seem to be a rpm of bzr-svn for fedora. so I attempted to do a manual install | 21:47 |
| knighthawk | branched from lp find then ran make and make install | 21:48 |
| knighthawk | no errors. | 21:48 |
| knighthawk | but now when I try to run the testsuite I get | 21:48 |
| knighthawk | Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib64/python2.4/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1) | 21:48 |
| lifeless | you've grabbed trunk | 21:49 |
| lifeless | but trunk wants bzr 2.4 | 21:50 |
| lifeless | you either need to grab the bzr svn for bzr 2.1 | 21:50 |
| lifeless | or also grab bzr 2.4 | 21:50 |
| knighthawk | I'm thinking my life will be easier if I go with the bzr-svn for 2.1 but how do I get that? | 21:50 |
| knighthawk | bzr branch lp:bzr-svn2.1 ? | 21:51 |
| lifeless | I'm not sure offhand | 21:51 |
| lifeless | jelmer: ^? | 21:51 |
| knighthawk | 1.0.2 (works with Bazaar 2.0, 2.1) | 21:52 |
| knighthawk | so I'm thinking bzr branch bzr-svn1.0.2 | 21:52 |
| lifeless | there may be a 1.0.2 tag in your curremt bramcj | 21:54 |
| lifeless | *current branch* | 21:54 |
| lifeless | 'bzr revert 1.0.2' | 21:54 |
| lifeless | bah revert -r 1.0.2 | 21:55 |
| lifeless | knighthawk: what does 'bzr tags' show you / | 21:55 |
| lifeless | ? | 21:55 |
| AfC | -r tag: | 21:55 |
| lifeless | AfC: not needed | 21:56 |
| lifeless | AfC: if the rev isn't found, different providers are searched | 21:56 |
| lifeless | AfC: and a branch on rev 1 is very unlikely ;) | 21:56 |
| AfC | oh you're talking about revnos. I thought you were talking about a tag called 1.0.2 | 21:56 |
| AfC | lifeless: really? | 21:56 |
| lifeless | I am | 21:56 |
| AfC | oh | 21:56 |
| lifeless | might not be in bzr 2.1, but it was added quite a while ago | 21:57 |
| AfC | That's not very good. It means if you mistakenly type something that just happens to be a tag, you're going to get a successful operation that [unwittingly] does something vastly different that you expect | 21:57 |
| AfC | BAD | 21:57 |
| knighthawk | nice. I'll try that lifeless | 21:57 |
| AfC | [admittedly, it never occurred to me that someone would create tags that look like revnos] | 21:58 |
| knighthawk | okay I see a upstream-1.0.2 | 22:00 |
| knighthawk | a lot of release (but nothing that says 1.0.2) | 22:00 |
| lifeless | upstream-1.0.2 sounds good :) | 22:01 |
| knighthawk | and several bzr-svn (including one that says bzr-svn-1.0.2) | 22:01 |
| knighthawk | so 'bzr revert upstream-1.0.2' ? | 22:01 |
| knighthawk | bzr: ERROR: Path(s) are not versioned: upstream-1.0.2 | 22:02 |
| knighthawk | bzr revert -r bzr-svn-1.0.2 | 22:04 |
| knighthawk | worked | 22:04 |
| lifeless | knighthawk: bzr revert -r upstream-1.0.2 should have worked | 22:04 |
| lifeless | without the -r it thinks you're reverting a file/directory name | 22:05 |
| knighthawk | make and make install worked. | 22:05 |
| knighthawk | trying the testsuite now. | 22:05 |
| knighthawk | bzr: ERROR: No module named testtools | 22:08 |
| knighthawk | You may need to install this Python library separately. | 22:08 |
| knighthawk | no clue what the name of that package would be in Fedora | 22:08 |
| poolie | knighthawk, is there a search function? | 22:09 |
| poolie | if not you can get it from 'bzr branch lp:testtools' | 22:09 |
| poolie | hi all btw | 22:09 |
| knighthawk | I just googled and I think its called python-tools btw | 22:10 |
| knighthawk | hey poolie | 22:10 |
| knighthawk | no python-tools didn't help me any. | 22:10 |
| poolie | python-testtools maybe? | 22:13 |
| poolie | that's what it's called in debian/ubunut | 22:13 |
| poolie | *ubuntu | 22:13 |
| lifeless | knighthawk: http://pypi.python.org/pypi/testtools | 22:20 |
| poolie | that too | 22:27 |
| poolie | hi lifeless | 22:27 |
| knighthawk | thanks lifeless | 22:57 |
| jxself | www.gnu.org is currently mantained under CVS, and we'd like to move to Bazaar. This is my first attempt at the CVS -> Bazaar migration: http://dpaste.com/525282/. Applied patch suggested by jelmer: lp:~jelmer/bzr-cvsps-import/avoid-note. Appears to be hung. No CPU usage, and the staging/ROOT.dump file is empty. strace if anyone's interested: http://aws.bluehome.net/strace. Suggestions? | 22:58 |
| jelmer | lifeless, knighthawk: bzr-svn trunk works with bzr 2.3 and bzr.dev | 22:59 |
| knighthawk | okay until I can get the python test tools running if I can do a bzr svn-import would that be reasonable prof that its installed correctly? | 23:05 |
| poolie | knighthawk, yes | 23:08 |
| poolie | bzr selftest is intended more for developers than for proving it's installed correctly | 23:09 |
| poolie | hi jxself | 23:09 |
| poolie | jxself, your strace shows it's waiting for the cvsps subprocess, which is not itself traced | 23:10 |
| poolie | you can use strace -ff | 23:10 |
| poolie | please file a bug though, tagged affects-gnu | 23:10 |
| wgrant | Can someone please moderate my email to bazaar@? | 23:36 |
| * jelmer waves to wgrant, poolie | 23:50 | |
| wgrant | Morning jelmer. | 23:50 |
| jelmer | wgrant: IIRC at least jam and poolie are list moderators. Of course, you could always just subscribe :) | 23:51 |
| wgrant | jelmer: I probably should. | 23:51 |
| wgrant | Resent. Maybe it will work. | 23:53 |
| jelmer | wgrant: yep, it's shown up here | 23:54 |
| wgrant | Great, thanks. | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!