| mwhudson | how big is bzr.dev in 2a format? | 00:03 |
|---|---|---|
| wgrant | mwhudson: Around 40MB here. | 00:03 |
| mwhudson | hm, i wonder why getting lp:bzr has transferred 60 odd megs then | 00:04 |
| wgrant | The copy I grabbed a few days ago was badly packed. | 00:05 |
| mwhudson | oh | 00:05 |
| lifeless | mwhudson: lp is running 1.17 | 00:16 |
| lifeless | mwhudson: additional data added to it will not be packing well | 00:17 |
| lifeless | though we did pack the mirror repo | 00:17 |
| mwhudson | ah ok | 00:18 |
| lifeless | loggerhead is odd >< | 00:18 |
| lifeless | I just managed to get a redirect to the branch id space | 00:19 |
| lifeless | http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/?C=S;O=D | 00:19 |
| lifeless | mwhudson: ^ | 00:19 |
| lifeless | mwhudson: are you branching clean, to a existing-but-empty repo, or to an existing populated repo ? | 00:20 |
| mwhudson | lifeless: former | 00:20 |
| mwhudson | well, past tense now, it finished | 00:20 |
| lifeless | totally clean | 00:20 |
| lifeless | hmm | 00:20 |
| lifeless | mwhudson: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/?C=S;O=D | 00:20 |
| lifeless | look at the link to 'parent directory' | 00:21 |
| mwhudson | lifeless: yay apache | 00:21 |
| lifeless | so there is about 38MB on disk | 00:21 |
| lifeless | I suspect wire protocol shenanigans | 00:21 |
| lifeless | I'll file a bug | 00:22 |
| mwhudson | lifeless: so finally looking at https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279, i think a tab has crept in perhaps? | 00:26 |
| lifeless | its possible; my vim setup on this machine isn't == my laptop | 00:27 |
| lifeless | it passes test :P | 00:27 |
| mwhudson | yeah, pack_repo.py:2101 | 00:27 |
| mwhudson | it looked like a syntax error in meld... | 00:27 |
| lifeless | mwhudson: I just tried the same fetch you did | 00:27 |
| lifeless | 41MB | 00:28 |
| lifeless | which is tolerable | 00:28 |
| mwhudson | lifeless: strange | 00:28 |
| lifeless | what URL did you branch from ? | 00:28 |
| mwhudson | lp:bzr | 00:28 |
| lifeless | are you logged in? | 00:28 |
| mwhudson | yes, it was certainly bzr+ssh | 00:28 |
| mwhudson | hm 1.18dev locally, maybe quite old | 00:29 |
| lifeless | please upgrade and repeat | 00:30 |
| lifeless | other than that tab, its ok ? | 00:30 |
| thumper | mwhudson: rinse and repeat :) | 00:31 |
| mwhudson | lifeless: well, i'm lacking some context about some things | 00:31 |
| mwhudson | lifeless: in particular, i'm not really sure what the test is testing | 00:31 |
| mwhudson | lifeless: it seems like the test is assuming that adding 10 revisions is enough to trigger an autopack | 00:32 |
| mwhudson | lifeless: will the test start failing if that ceases to be the case? | 00:32 |
| lifeless | yes, as the comment says :) | 00:32 |
| lifeless | no, it won't; I could add a check that checks it did do an autopack | 00:32 |
| lifeless | OTOH that feels like diminishing returns to me: changing the algorithm for autopack requires substantial test checking anyway | 00:33 |
| * mwhudson uninstalls plugins at random until apt will upgrade bzr | 00:33 | |
| rar | upgrade_guide/data_migration is confusing me - is the only way to upgrade my bzr (which is a shared repo with several branches) by creating a new shared repo in 2a format? I ran upgrade the other day and it seemed to be working, but died in a power failure and haven't tried again yet | 00:34 |
| lifeless | poolie: ping | 00:35 |
| lifeless | rar: if you had a power failure you probably have a partially upgraded repo | 00:36 |
| lifeless | you'll want to mv .bzr bzr.failedupgrade | 00:36 |
| mwhudson | lifeless: yes, otherwise looks ok to me, but maybe you should get poolie to look at it now he's awake :) | 00:36 |
| lifeless | mv backup.bzr .bzr | 00:36 |
| lifeless | and upgrade again | 00:36 |
| rar | I did that, but I'm reading the doc first this time | 00:36 |
| rar | and the doc seems to say what I did was wrong. | 00:36 |
| rar | "To migrate branches in a shared repository: ... Create a fresh shared repository in the new format (2a or later)." | 00:37 |
| lifeless | rar: I've got no idea why it says that | 00:37 |
| lifeless | rar: its certainly not how I upgraded all my shared repositories; I' | 00:38 |
| lifeless | ll chat to the upgrade guide author about that later today | 00:38 |
| * lifeless times out on the ping | 00:38 | |
| rar | okay, I'll do what I did last time then... including ^Cing out of the check by the look of it, it's not moved for half an hour or so | 00:40 |
| jelmer | SamB: that should also already work | 00:50 |
| jelmer | lifeless: hey | 00:50 |
| jelmer | lifeless: subunit review is on my radar | 00:50 |
| lifeless | jelmer: thanks; its actually the perl stuff I wanted to ping you about | 00:56 |
| spiv | lifeless: update that branch to 2a, you mean? | 01:02 |
| spiv | lifeless: I have, but there's an LP bug :( | 01:03 |
| spiv | lifeless: bug 424136 | 01:03 |
| ubottu | Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Confirmed] https://launchpad.net/bugs/424136 | 01:03 |
| mwhudson | ah right, i should look at that today | 01:05 |
| spiv | mwhudson: yes please! | 01:05 |
| mwhudson | gah | 01:13 |
| igc | morning | 01:13 |
| mwhudson | lifeless: i ran that fetch again, but failed to monitor how much it transferred | 01:13 |
| lifeless | :P | 01:14 |
| lifeless | h ighc | 01:24 |
| lifeless | hi igc | 01:24 |
| lifeless | rar: igc wrote the upgrade guide :) | 01:24 |
| lifeless | igc: why does the upgrade guide say noty to upgrade shared repos inplace? | 01:24 |
| igc | lifeless: hi | 01:27 |
| * igc looks | 01:27 | |
| rar | I'm looking at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/doc/en/upgrade-guide/data_migration.txt#L128 | 01:27 |
| rar | (or rather the same thing in the last 1.9 change, but it's the same text) | 01:28 |
| igc | rar: the latestdoc is http://doc.bazaar-vcs.org/bzr.2.0rc2-html/en/upgrade-guide/index.html | 01:29 |
| igc | rar: which bit exactly are you asking about? | 01:29 |
| rar | I want to get the latest copy of bzr.dev and am confused about thr right way of doing this. Robert's email to the list and the upgrade guide seem to say slightly different things. | 01:31 |
| rar | http://doc.bazaar-vcs.org/bzr.2.0rc2-html/en/upgrade-guide/index.html#migrating-local-branches-after-a-central-trunk-has-migrated <- this is the right section to be reading for the like-bzr.dev case, right? | 01:33 |
| igc | rar: yes | 01:39 |
| igc | rar: so poolie and lifeless have migrated bzr.dev to 2a now | 01:40 |
| igc | rar: so you don't need to migrate the trunk yourself - just grab the migrated one into a new shared repo | 01:41 |
| igc | rar: and pull your branches across as the guide says | 01:41 |
| igc | rar: I've just did exactly this last Friday for some branches and I'm pulling/merging others across today | 01:42 |
| rar | but, that means downloading some large number of bytes from the internet? then... re-branching all my branches into a new directory? | 01:43 |
| igc | rar: 2a compresses data pretty well - my .bzr/repository/packs directory for bzr itself is 34M | 01:45 |
| rar | does running upgrade in the shared repo root not have the same effect? | 01:45 |
| igc | rar: it should, though I suspect running upgrade will be a lot slower than just grabbing the converted branch for many users | 01:46 |
| igc | rar: how's your internet connectivity? | 01:46 |
| rar | bad at certain times of day, but you may be right that redownloading is a quicker process than running upgrade | 01:47 |
| lifeless | spiv: can you mail me a bundle against 2.0 of your branch please | 01:49 |
| rar | looking at each branch seemed like a lot of manual steps I was trying to avoid though (have now gone through them all anyway) | 01:50 |
| rar | there's a doc patch from two years ago that I really should have finished... | 01:51 |
| lifeless | jelmer: hi, was a phone call sorry. | 01:52 |
| igc | rar: to give you some benchmark, I also tried doing a local upgrade of my old shared repo holding bzr.dev last week - it took 83 minutes | 01:52 |
| lifeless | jelmer: doing the reviews would be great. Finishing your perl stuff to install appropriately so that users can use it - better! | 01:52 |
| igc | rar: that's on a i7 920 desktop with 6G of RAM and 1TB of disk | 01:53 |
| lifeless | igc: fast-import; I hit 6G of memory for the netbeans import; jam suggested it might be holding full file texts or something ... | 01:53 |
| igc | rar: grabbing the converted bzr.dev is a lot quicker than that for me at least | 01:54 |
| lifeless | igc: worth documenting 'easy but slow', 'fast but manual' | 01:55 |
| igc | lifeless: the source was hg right? if so, fast-import itself isn't holding fulltexts beyond the time taken to do a given commit | 01:56 |
| igc | lifeless: how many revisions do it get loaded? It will checkpoint a pack every 10k | 01:57 |
| igc | lifeless: so restarting will start frm the last 10k boundary fwiw | 01:57 |
| igc | s/do/did/ | 01:57 |
| spiv | lifeless: sure | 01:58 |
| spiv | lifeless: oh, or pull it from lp:~spiv/bzr/insert-stream-check-chk-root-again | 01:58 |
| spiv | lifeless: where is where I repushed to for PQM's sake. | 01:58 |
| poolie | spiv, igc, hello | 02:05 |
| igc | hi poolie | 02:05 |
| poolie | igc, i was planning to look at bug 385879 today | 02:06 |
| ubottu | Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,Fix committed] https://launchpad.net/bugs/385879 | 02:06 |
| poolie | i see there was already a long thread with robert | 02:06 |
| igc | lifeless: is check on a branch in a shared repo meant to check all branches in the repo? | 02:06 |
| igc | poolie: thanks - I was really hoping that would reach the top of your list today | 02:06 |
| poolie | should i take that bug from you? | 02:06 |
| igc | poolie: yes please | 02:07 |
| poolie | also can i suggest you put the bug number in your branch name? | 02:07 |
| igc | ok | 02:07 |
| poolie | in future that is | 02:07 |
| poolie | how's the packaging stuff? it looks like the chm help was welcome | 02:07 |
| igc | poolie: a patch for pdf and chm docs has been put up | 02:08 |
| poolie | that was a good idea to actually distribute the built files | 02:08 |
| poolie | no one would test them if you just put up a patch | 02:08 |
| igc | poolie: the main issue is pulling out the foreign language stuff which is kind of part of that other doc packaging bug | 02:08 |
| === thumper is now known as thumper-afk | ||
| spiv | lifeless: I see PQM now tries to give % progress, do we need to add --subunit to 'make check' to make it work? | 02:09 |
| igc | poolie: and I now have a local vista install with 30G to do some serious Windows development/testing (instead of an XP partition with 0.5G spare) | 02:09 |
| spiv | poolie: good morning. | 02:09 |
| poolie | hi spiv | 02:10 |
| lifeless | spiv: yes | 02:10 |
| lifeless | spiv: but we need to check the subunit dep is in the chroot | 02:10 |
| lifeless | spm: ^ | 02:10 |
| lifeless | I've mailed the sysadmins back on the same ticket that got pqm upgraded | 02:10 |
| lifeless | igc: hmm, re: check one branch in a repo - bug I think | 02:11 |
| lifeless | unless you're at the root of the repo | 02:12 |
| lifeless | igc: 133K revs | 02:12 |
| lifeless | igc: it died ~65K, I killed it and removed the output, I thought it was not resumable as there were no branch objects etc | 02:12 |
| igc | lifeless: branches only get created at the very end after it works out the heads in the repo | 02:13 |
| lifeless | igc: sure I figured that | 02:13 |
| lifeless | didn't realise you could resume though | 02:13 |
| lifeless | anyhow, it was very unhappy :P | 02:14 |
| igc | :-( | 02:14 |
| lifeless | I have a 6G pymemory dump file | 02:14 |
| lifeless | and the 129GB input stream | 02:14 |
| igc | you can gzip that input stream btw and fast-import will still accept it | 02:14 |
| lifeless | yup, its doing that at the moment ;P | 02:15 |
| lifeless | it may take a bit :) :) | 02:15 |
| igc | lifeless: it will :-) | 02:15 |
| lifeless | so, no thoughts about what blew up the memory ? | 02:15 |
| lifeless | and when you say resumable, what file stores the resume data? | 02:16 |
| igc | Not yet sorry. I need to focus on core stuff and the Windows installer early this week so I can't look into fastimport stuff till the weekend probably | 02:16 |
| igc | there's a .bzr/repository created | 02:16 |
| igc | it just looks in there, takes the count of revision and skips ahead in the input stream that much, complete with some sanity checking | 02:17 |
| lifeless | meep lol | 02:17 |
| lifeless | so running it in an existing repo == 'interesting' ? | 02:17 |
| lifeless | brb | 02:18 |
| igc | lifeless: the input stream and repo need to match exactly fwiw | 02:18 |
| spm | lifeless: not in the chroot, no | 02:20 |
| poolie | spiv, how's stuff? | 02:27 |
| spiv | poolie: good, my chk-root check is finally going to land on 2.0 after some snafus like bug 424136 on Friday. | 02:33 |
| ubottu | Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,In progress] https://launchpad.net/bugs/424136 | 02:33 |
| poolie | ok | 02:33 |
| poolie | and is that the end of that series of bugs? | 02:34 |
| spiv | And I have a branch that does checking for all relevant chk pages, which seems to be working and passing a relevant test. | 02:34 |
| spiv | This is a bit of a "how long is a piece of string" bug, you can always do more integrity checking... but checking for chk records and checking for the text records referenced by those would be sensible end, I think. | 02:36 |
| spiv | Next time someone pokes at this and 'bzr check' they can hopefully unify some of the code between those two places. | 02:37 |
| lifeless | spm: I can haz | 02:37 |
| spm | lifeless: sure, but I dno't have privs to do so. Super urgent? | 02:38 |
| lifeless | spm: not super. | 02:38 |
| spm | the rt is still with tom, he should be able to update with one of the handy gsas overnight. | 02:39 |
| poolie | ok, so please do make separate linked bugs for each section of that string | 02:39 |
| lifeless | spm: please cancel the current bzr pqm job | 02:51 |
| spm | oki | 02:51 |
| lifeless | thanks | 02:53 |
| spm | is done | 02:53 |
| lifeless | jml: you were asking what my subunit/pqm patch looked like | 03:19 |
| lifeless | jml: http://pqm.bazaar-vcs.org/ shows it in stub form - we don't have subunit in the pqm chroot yet | 03:19 |
| jml | lifeless, cool. | 03:20 |
| lifeless | igc: what sort of compression ratio do you expect out of gz on .fi's? | 03:25 |
| igc | lifeless: 5-10X better typically | 03:26 |
| igc | at a guess | 03:26 |
| lifeless | thanks | 03:26 |
| igc | lifeless: as a guide, some gzipped sizes ... firefox 3.5: 1.7G, kernel: 2.6G, mysql-server 5.1: 7.3G | 03:32 |
| lifeless | -rw-r--r-- 1 robertc robertc 129G 2009-09-03 21:43 /home/robertc/source/release67.fi | 03:34 |
| lifeless | -rw------- 1 robertc robertc 23G 2009-09-07 12:34 /home/robertc/source/release67.fi.gz | 03:34 |
| lifeless | still going :P | 03:34 |
| poolie | lifeless: i suggest we ask about series etc on the launchpad list next | 03:44 |
| lifeless | poolie: ok :) | 03:44 |
| poolie | see also #launchpad now | 03:45 |
| lifeless | am there ;) | 03:49 |
| lifeless | poolie: this seems to be orthogonal to milestones, yes? | 03:52 |
| lifeless | poolie: I want to fix the inconsistent docs while its in my head; Ideally I'd only touch them once.. | 03:53 |
| poolie | k | 03:54 |
| poolie | incremental changes are fine | 03:54 |
| poolie | i think we should say "bugs that will block a release should be targeted to the relevant release" | 03:54 |
| poolie | i don't want to rename milestones | 03:55 |
| poolie | iow things that should block us doing the next rc should go into 2.0rc2 | 03:55 |
| poolie | i'm not sure this is ideal | 03:55 |
| poolie | it means there's no single "watch this space" url | 03:55 |
| poolie | :/ | 03:55 |
| lifeless | the only people it doesn't serve are those that want a 'watch this space url' | 03:55 |
| lifeless | In myinitial analysis I didn't consider them at all | 03:55 |
| lifeless | I'm fine with them losing out for now | 03:55 |
| poolie | mm | 03:55 |
| poolie | it's probably ok | 03:55 |
| === timchen119 is now known as nasloc__ | ||
| poolie | it needs some analysis of "what do they want"? | 03:56 |
| poolie | A: a line sloping down to the right :) | 03:56 |
| lifeless | Its a good question | 03:56 |
| poolie | if it's "are we in ..trouble" then +critical is probably better | 03:57 |
| poolie | if it's "are you moving" then the changed or inprogress bugs list may be better | 03:57 |
| poolie | meh | 03:57 |
| lifeless | it could be 'will they hit the release date' | 03:57 |
| lifeless | which critical is [problematic] proxy for | 03:57 |
| poolie | mm | 03:58 |
| poolie | so "will they hit it" is interesting wrt milestones because | 03:59 |
| poolie | it's not so much "how much more for 2.0rc2" but "how many more rcs before final" | 03:59 |
| lifeless | if we don't do rc's when there are blocking bugs, its 'how lnog till the rc' | 03:59 |
| lifeless | its thorny | 04:00 |
| lifeless | poolie: so, if we're going to generally avoid renaming milestones, should we rename 2.0 to 2.0rc2 | 04:08 |
| lifeless | e.g. undo part of the changes I did | 04:09 |
| lifeless | spiv: igc: have you found that a submit branch of lp:bzr/2.0 works ? | 04:12 |
| lifeless | or is that hopeful speculation in the dev docs ? | 04:12 |
| lifeless | poolie: ^ | 04:13 |
| poolie | lifeless: it seems to work for me but i'm not sure i did it since the upgrade | 04:14 |
| poolie | > merge http://bazaar.launchpad.net/~mbp/bzr/prepare-2.0 http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 | 04:14 |
| lifeless | so the http url there | 04:14 |
| poolie | at 7pm friday | 04:14 |
| lifeless | is what I think we should document, at least until I fix the pqm location aliases support bug | 04:15 |
| igc | lifeless: I'm using the http url as well | 04:15 |
| poolie | wfm | 04:16 |
| poolie | by which i mean, that's fine with me | 04:16 |
| lifeless | submitting the merge:-> (Error ID: OOPS-1346ED42) | 04:19 |
| ubottu | https://lp-oops.canonical.com/oops.py/?oopsid=1346ED42 | 04:19 |
| poolie | lifeless: what do you mean by submitting? | 04:23 |
| lifeless | poolie: was just random mumbling about lp timeouts :) | 04:23 |
| poolie | oh, registering the mp? | 04:23 |
| lifeless | yes | 04:23 |
| lifeless | did you just think I was sending it pqm? | 04:24 |
| lifeless | :_ | 04:24 |
| lifeless | :) | 04:24 |
| poolie | at first i thought pqm might have got an oops hook | 04:24 |
| lifeless | hmm, I guess my comment was ambiguous | 04:24 |
| lifeless | I'm merging 2.0 to trunk now | 04:24 |
| lifeless | spiv: has 423506 landed in 2.0 ? | 04:25 |
| lifeless | spiv: if so, please put bug numbers in the pqm message, it helps. | 04:28 |
| lifeless | poolie: https://bugs.edge.launchpad.net/bzr/+bug/406687 | 04:32 |
| ubottu | Ubuntu bug 406687 in bzr/2.0 "insert_stream doesn't check references are satisfied" [Critical,In progress] | 04:32 |
| lifeless | If we're on the same page, that bug's metadata will be appropriate for both of us | 04:32 |
| lifeless | blocking the next 2.0 release; to be fixed on both 2.0 and trunk. | 04:33 |
| poolie | looks good to me | 04:33 |
| lifeless | this isn't actually a change at all from our docs :) | 04:36 |
| lifeless | but I've tried to make doing this /clearer/ by reading the docs with a fresh eye | 04:36 |
| lifeless | poolie: I'd like to rename 2.0 back to 2.0rc2 in light of your desire to avoid renaming at release times. | 04:37 |
| lifeless | poolie: unless you think you're going to change your mind it seems trivially right to me to make the current metadata match our process | 04:37 |
| lifeless | https://edge.launchpad.net/bzr/+milestone/2.0 three bugs left :) | 04:39 |
| poolie | i'd sit on it and see if other people reply to that thread | 04:39 |
| poolie | i'm not really happy with any of these options | 04:39 |
| poolie | i do want to give people a 'watch this space' link and to have one myself :/ | 04:40 |
| lifeless | personally I think renaming is the least of all evils | 04:40 |
| lifeless | I've filed a bug about the misleading activity log | 04:40 |
| lifeless | and a few others today :) | 04:41 |
| lifeless | igc: rev props with no value | 04:44 |
| lifeless | igc: I commented on the bug; I think None should be illegal; things like fast import should choose either "" or no-property: the core can't really make that choice. | 04:44 |
| igc | lifeless: fast-import fold None to '' currently iirc | 04:45 |
| lifeless | igc: ok; what does your patch do then? (I saw it go by, but haven't read it yet) | 04:46 |
| igc | lifeless: may patch just fixes the error msg so key and value come out in the right place in the msg | 04:46 |
| igc | s/may/my/ | 04:46 |
| lifeless | igc: cool | 04:46 |
| lifeless | igc: I'll let this fast import run for a bit, and see if it does better once it starts swapping | 04:47 |
| lifeless | igc: if I can offer a performance hint | 04:47 |
| igc | lifeless: sure but best in a bug report so I don't forget it | 04:48 |
| lifeless | igc: if you use the stream in purely streaming mode, running gunzip -c in a subprocess would let you get two cores working at imports from .gz files | 04:48 |
| igc | right | 04:48 |
| lifeless | I don't know if you do though | 04:49 |
| igc | it's multi-pass by default now so no | 04:49 |
| lifeless | well | 04:49 |
| lifeless | multipass is one thing | 04:49 |
| lifeless | forward-only is orthogonal | 04:49 |
| lifeless | do you seek at all within a pass? | 04:50 |
| igc | no, only when the first pass completes | 04:50 |
| lifeless | and if you seek, do you seek backwards ? | 04:50 |
| igc | seek(0) | 04:50 |
| lifeless | I'll file a bug then, you can do this | 04:50 |
| lifeless | bzr-fastimport is the project, righyt? | 04:50 |
| igc | yep | 04:51 |
| lifeless | sent | 04:52 |
| igc | thanks | 04:52 |
| lifeless | my pleasure | 04:52 |
| lifeless | I know you like to squeeze speed out :) | 04:52 |
| * lifeless is off to finish paying for a sofa | 04:53 | |
| lifeless | on the mobile if folk need me | 04:53 |
| * igc lunch | 05:00 | |
| lifeless | poolie: PQM looks happy; I'm EODing modulo emergencies. I might touch base with you around 5 to tee up tomorrow's release-related plans. | 05:09 |
| poolie | i don't mind but i still boggle at how early your work day is | 05:13 |
| poolie | anyhow, jolly good | 05:13 |
| === thumper-afk is now known as thumper | ||
| poolie | lifeless: http://bzr.pastebin.com/d7e16641f -- i'm not complaning about the change but the way launchpad presents this is a bit suboptimal | 05:16 |
| vila | hi all | 06:57 |
| === thumper is now known as thumper-afk | ||
| lifeless | poolie: re: that pastebin; its partly an artifact of an originally-mis-organised bug, one task not two; the bzr.dev task with a milestone on 2.0 etc. | 07:07 |
| lifeless | hi vila | 07:12 |
| poolie | hi vila | 08:11 |
| vila | hey ! | 08:11 |
| poolie | vila, regarding bug handling | 08:19 |
| poolie | your mail was pretty thoughtful | 08:19 |
| poolie | i was going to reply and then i asked myself, "are we just making a big issue out of a small one?" | 08:20 |
| vila | poolie: feel fre to disagree, there are various ways to address the problems | 08:20 |
| vila | I just express my POV as it was clear in my head :) | 08:20 |
| vila | I can adapt to anything we decide to do :) | 08:21 |
| vila | poolie: I mean, in the end, if I (and/or others) really feels like assigning new milestones to make them more precise, the RM don't have to do it... | 08:26 |
| lifeless | poolie: https://bugs.edge.launchpad.net/bzr/+milestone/2.0 | 08:42 |
| poolie | mm? | 08:42 |
| lifeless | poolie: tomorrow, I'll likely be waking up early again :( | 08:43 |
| lifeless | and I have a half day combined w/that | 08:43 |
| lifeless | so I'm thinking I might just look at non targeted bugs / polish / etc | 08:43 |
| poolie | that sounds good | 08:43 |
| lifeless | the three remaining bugs are all either assigned or in progress and not really parallisale | 08:43 |
| poolie | maybe nontargeted critical bugs | 08:44 |
| lifeless | that sort of thing yes | 08:44 |
| poolie | lifeless/vila: i'm wondering if the recent stuff about how to handle release blocker bugs is in fact, um, "bad", for lack of a better word | 08:44 |
| lifeless | I have a couple of itches queued up too, that I'd like to do. | 08:44 |
| poolie | given that we generally want to just do time based releases with no-brainer release management and no slips | 08:44 |
| poolie | perhaps we are making too much of a process for something that should be discouraged | 08:45 |
| lifeless | details are easier to bikeshed on :) | 08:45 |
| poolie | of course handling rare events well or systematically is still worthwhile | 08:45 |
| vila | poolie: well, 2a as default raised many critical bugs, *that's* unsual | 08:46 |
| lifeless | poolie: I don't think we've been talking about blocker bugs a lot; my focus has been on the event-of-the-release and what people can look at later; in general. | 08:46 |
| lifeless | poolie: though perhaps you mean further back like a week+ ago? | 08:46 |
| vila | poolie: the most important for me is to have a clear bug <-> milestone relationship | 08:47 |
| vila | and 2.0 blurry things a bit to my taste, it won't matter /at all/ in a couple of months | 08:47 |
| poolie | mm | 08:48 |
| poolie | > the most important for me is to have a clear bug <-> milestone relationship | 08:48 |
| poolie | looking forward or looking backwards? | 08:48 |
| poolie | looking backward, i agree completely | 08:48 |
| poolie | looking forward, i question it | 08:48 |
| poolie | it seems like it can mean | 08:49 |
| vila | looking backwards | 08:49 |
| poolie | 1- we will slip (or seriously consider slipping) the release if this is not fixed; if bugs ever get into this state it is a kind of failure | 08:49 |
| poolie | 2- we want to do this next; in other words its a proxy for finer-grained sorting | 08:49 |
| poolie | 3- we expect it will be done in time for this milestone but if it's not it's ok | 08:50 |
| vila | looking backwards *only* in fact | 08:50 |
| vila | for forward, yes, I was a fan of 3 but was out-voted, I still like 2, I agree that 1 should remain the exception | 08:51 |
| poolie | 4- we've estimated X amount of bugs can be done for this milestone and managers will judge us on whether we hit that or not | 08:52 |
| poolie | i think lp used to do some combination of all of these | 08:52 |
| vila | On the overall I now weakly think that milestone should be set either for nomination by users (to mean I'd like this) and strongly think only devs should use them to say: fix released there | 08:52 |
| vila | 4 is called in French: 'Tendre le baton pour se faire battre', | 08:53 |
| vila | in English that would be... given a mean to someone to harm you | 08:53 |
| vila | with the idea that it only works that way and not in the intended way | 08:54 |
| poolie | i think 4 is poor because you are using something unreliable (estimation) to measure something probably more consistent (productivity) | 08:54 |
| vila | and if it can't be reliably related to what you really did, you are sure to lose | 08:55 |
| vila | i.e. any necessary work not tracked via a bug is essentially invisible not matter how important it is | 08:55 |
| poolie | i'd rather assess progress by looking backwards at the most recent release, or at the timeline of recently fixed bugs | 08:55 |
| vila | s/not/no/ | 08:55 |
| poolie | right | 08:55 |
| poolie | anyhow | 08:55 |
| poolie | are there more uses? | 08:56 |
| poolie | i think 1 is the most useful, and the only one that really needs targeting | 08:56 |
| poolie | i think 2 is better done by inprogress | 08:56 |
| vila | do you mean 3 for inprogress instead ? | 08:57 |
| vila | I feel that way, I don't mark several bugs inprogress, only one at atime | 08:58 |
| vila | and most often I just forget :-/ | 08:58 |
| vila | so it's confirmed -> assigned to me -> fix committed | 08:58 |
| vila | That makes me want to file a lp bug about private/public *user-managed* bug lists | 08:59 |
| poolie | it'd be good | 08:59 |
| vila | tags are not an answer for that and there is disagreement about using assigned to me (plus the later is limited) | 09:00 |
| poolie | so | 09:00 |
| wgrant | There was a discussion about a "bug bag" concept at UDS Jaunty for just that purpose. | 09:00 |
| wgrant | But it never eventuated. | 09:00 |
| poolie | i think it's important we be very clear about #1 | 09:00 |
| poolie | very important | 09:00 |
| poolie | you don't want the rm shipping something known to have bugs we shouldn't fix yet | 09:00 |
| poolie | the rest of them, don't necessarily matter a lot, | 09:01 |
| poolie | because they're not grounds for communication | 09:01 |
| poolie | it's just about what each individual developer (or subset of developers) is going to do next | 09:01 |
| vila | you mean critical should always have the closest milestone assigned, right ? | 09:01 |
| vila | wgrant: bugs were filed for it ? | 09:02 |
| poolie | i'm not sure | 09:02 |
| poolie | i'm still openminded about whether 1 should be targeted or critical or both | 09:02 |
| vila | mm | 09:03 |
| lifeless | I think 1 is very important | 09:03 |
| wgrant | vila: There are bugs around for that, yes. | 09:03 |
| lifeless | I prefer targetting for it, because its a clear single bit; we can target because of impact, or political desire | 09:03 |
| lifeless | and its not conflated. | 09:03 |
| vila | critical is the red-button to me, targeted/nominated sounds more like wishes (very subjective and personal view here, not what I think we are doing that) | 09:04 |
| poolie | conflation is a good word | 09:04 |
| poolie | i think there should be some way to look at a bug and definitely tell if it's in that category or not | 09:05 |
| vila | lifeless: but do you mean that any targeted bug should block a release ? Or only critical ones, the other needing to be retargeted ? | 09:05 |
| poolie | at the moment there are critical non-blocker bugs, and targeted non-blocker bugs | 09:05 |
| poolie | that means that neither defines that category | 09:05 |
| vila | critical non blocker ? 8-/ Example ? | 09:05 |
| poolie | i guess you could say that if *both* are set the bug is in category 1 | 09:05 |
| poolie | vila: https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed | 09:05 |
| lifeless | vila: targeted should block. | 09:06 |
| lifeless | vila: thats what our docs say :) | 09:06 |
| lifeless | poolie: we have targeted non-blockers? | 09:06 |
| vila | lifeless: you mean with the patch I'm reviewing ? ;-P | 09:06 |
| lifeless | vila: I mean in trunk, right now. | 09:07 |
| lifeless | vila: my patch just removes some redundant conditionals from the language. | 09:07 |
| vila | lifeless: right, I wasn't at the right page :) | 09:08 |
| vila | wgrant: thanks | 09:08 |
| poolie | i am not convinced bug 421789 or bug 385879 should be blockers | 09:09 |
| ubottu | Launchpad bug 421789 in bzr/2.0 "Windows installer should include explorer, qbzr, chm help, etc" [High,In progress] https://launchpad.net/bugs/421789 | 09:09 |
| ubottu | Launchpad bug 385879 in bzr/2.0 "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 | 09:09 |
| lifeless | poolie: then I think you/we should decide. And if they aren't take them out of the list. | 09:15 |
| lifeless | poolie: My vote, FWIW is with you, on both of them. | 09:16 |
| poolie | on taking them out? or it's just an undirected proxy vote? :-) | 09:16 |
| lifeless | I think the installer one is arguable, but the EOL filter is likely jkust the iceberg tip, so I'd rather not make a big noise on content filtering in 2.0 | 09:17 |
| lifeless | save that for 2.0.1 or so | 09:17 |
| poolie | that's what i was saying this morning, i suspect there will be multiple moles | 09:17 |
| lifeless | its neither ready yet, nor clearly in cooee | 09:17 |
| lifeless | poolie: yes, I agreed with you this morning, and I still do :) | 09:18 |
| vila | lifeless: please have a look at my comments before landing lp:~lifeless/bzr/docs | 09:19 |
| lifeless | vila: I'm waiting on poolie specifically on that one; there is a parallel list discussion | 09:20 |
| lifeless | and he's expressed an interest ;P | 09:20 |
| poolie | lifeless/vila: re 1.18 do you agree we should announce what we have or start a 1.18.1 or both? | 09:20 |
| vila | both but more importantly any :) | 09:21 |
| lifeless | poolie: 1,18 is the new style release right? simultaneous builds ready on N platforms... | 09:21 |
| poolie | right | 09:21 |
| lifeless | poolie: if it meets the criteria you established, DoIt | 09:21 |
| poolie | and a long delay before it's announced, apparently | 09:21 |
| lifeless | if it doesn't, red button, debug the process. | 09:21 |
| lifeless | I have no particular view on 1.18.1 | 09:22 |
| poolie | so with your changes to the docs | 09:22 |
| lifeless | there weren't any brown bags in 1.18.0 that are not also in 1.16 and 1.17 that I know of | 09:22 |
| vila | 1.18 is already used *today* it just miss the announcement | 09:22 |
| * igc dinner | 09:24 | |
| vila | spiv: Are you you still around ? | 09:32 |
| poolie | ok, i'll announce it too | 09:33 |
| igc | poolie: given there's agreement to take the Windows installer out of the core, bug 421789 not a blocker | 09:34 |
| ubottu | Launchpad bug 421789 in bzr/2.0 "Windows installer should include explorer, qbzr, chm help, etc" [High,In progress] https://launchpad.net/bugs/421789 | 09:34 |
| poolie | cool | 09:34 |
| poolie | i still think it's a good one to work on now | 09:35 |
| poolie | just not a blocker | 09:35 |
| igc | the bit which is core-related though is the doc changes supporting chm | 09:35 |
| igc | poolie: I've split out the Russian, Spanish and developer docs today so searching is chm files works as expected | 09:36 |
| poolie | nice one | 09:36 |
| igc | s/is/in/ | 09:36 |
| poolie | is there an mp for that, or is there going to be one? | 09:36 |
| igc | I'm just typing up the mp now | 09:36 |
| lifeless | + line = client_sock.recv(50) | 09:44 |
| lifeless | vila: - thats not a line | 09:44 |
| lifeless | call it chunks or something | 09:44 |
| lifeless | also, I'm fairly sure that code already exists in smart/ somewhere; would be good to reuse. | 09:44 |
| vila | lifeless: already uncommitted, I know, I agree, it's controversial and I want feedback on *why* it's even needed anyway | 09:44 |
| vila | I'm separating the controversial parts from the good ones and will make two submissions | 09:45 |
| vila | lifeless: but thanks for caring :-D | 09:45 |
| lifeless | vila: btw, I taught buildbot about subunit in the weekend | 09:46 |
| lifeless | http://buildbot.net/trac/ticket/610 | 09:46 |
| vila | lifeless: hehe, excellent ! | 09:47 |
| vila | lifeless: you just want to make my switch to hudson harder or what ? :-D | 09:49 |
| igc | poolie: https://code.edge.launchpad.net/~ian-clatworthy/bzr/doc-site-per-language/+merge/11287 | 09:49 |
| lifeless | vila: :P I don't have an opinion on hudson vs buildbot, tbh. | 09:49 |
| vila | lifeless: currently I'd love better reporting, hudson seems better there | 09:50 |
| vila | but it's low priority against having more coverage in my book | 09:50 |
| vila | lifeless: so back to your remark about line = client_sock.recv(50), | 09:58 |
| vila | I called it line because it appears that even if all the bytes should be available a split occurs on the '\n' | 09:58 |
| vila | that's not a proper fix, I'd like to understand why it's needed on FreeBSD and not on Linux, where the hell is that difference coming ? | 09:59 |
| vila | That's why the commit message want to express :-D | 10:00 |
| vila | That's whay the commit message want to express :-D | 10:00 |
| vila | That's what the commit message want to express :-D | 10:00 |
| vila | damn | 10:00 |
| === quicksil1er is now known as quicksilver | ||
| === thumper-afk is now known as thumper | ||
| lifeless | vila: its probably just socket buffer timing on that box/os | 10:07 |
| lifeless | vila: its strictly correct to do what you do | 10:07 |
| vila | lifeless: with the server socket closed 2 lines above ??? | 10:07 |
| lifeless | yes | 10:07 |
| lifeless | well | 10:08 |
| lifeless | reading from the client side when the server is closed is impossible if the server was shutdown properly | 10:08 |
| poolie | spiv, https://answers.edge.launchpad.net/bzr/+question/81139 shows the hpss session is apparently hanging in "byte part read" of a get_stream call | 10:08 |
| poolie | does that mean anything to you? | 10:08 |
| lifeless | you actually have to shutdown(rd); client.recv(); client shutdown(); server.shutdown etc | 10:08 |
| vila | yeah, well, I don't mind, I'm just surprised, if I get confirmation that it's expected, I have learned a new bit :) | 10:09 |
| vila | you confirmed, I'm happy :) | 10:09 |
| lifeless | vila: I haven't read the full code of the test | 10:09 |
| vila | by the way, I search recv_all but not at the right place first :) | 10:10 |
| lifeless | perhaps the socket is set nonblocking or something | 10:10 |
| vila | I changed it in the submission I'm doing right now | 10:10 |
| vila | I suspect fullermd will have a look at my patches and hopefully will provide some hint | 10:10 |
| wgrant | Is there a source of bzrs for Lenny that is less ancient than backports.org? | 10:11 |
| vila | I think LarstiQ said this week-end that Lenny isn't supported anymore ? | 10:12 |
| wgrant | That seems unlikely -- it's the current stable release, and had a point release yesterday. | 10:13 |
| vila | wgrant: right :-) My ignorance is just showing off then | 10:16 |
| * wgrant just uses the Hardy nightly instead. | 10:18 | |
| vila | wgrant: wow, in fact LarstiQ was not only talking about etch but was also wrong about it not being supported :) | 10:18 |
| wgrant | vila: etch is barely supported. | 10:19 |
| wgrant | Well, it has a few months to live. | 10:20 |
| vila | Sep 06 18:21:46 <Lo-lan-do>LarstiQ: Etch *is* supported by Debian. | 10:20 |
| vila | Sep 06 18:22:29 <Lo-lan-do>At least until 2010-02-14 or Squeeze releases, whichever comes first. | 10:20 |
| wgrant | Right. | 10:20 |
| gour | pygi: ping | 10:34 |
| vila | BAM ! http://en.expreview.com/2009/09/04/ocz-spruces-up-its-z-drive-ssds.html#more-5073 | 10:48 |
| vila | Now, that's performance :-D In the 1GB/s range for both read and write... | 10:49 |
| spiv | poolie: hmm, to me that means we probably have a bug causing the trace file to be buffered :( | 10:49 |
| vila | A bit pricey, but that can only go down... | 10:49 |
| poolie | heh, :) | 10:49 |
| spiv | poolie: I've added a comment/information request to it. | 10:49 |
| poolie | vila: did you get my bazaar-announce list? | 10:52 |
| vila | poolie: yup | 10:53 |
| poolie | great, thanks | 10:53 |
| === vila is now known as vila-lunch | ||
| poolie | vila/bialix: silly question maybe but what happens in windows if you run bzr commit with no -m ? | 10:58 |
| poolie | it runs wordpad apparently | 11:01 |
| rar | notepad for me. | 11:10 |
| hno | Is it possible to convert an existing set of branches to a pipeline? | 11:18 |
| hno | using a shared repository btw. | 11:19 |
| hno | to be exact I have some so far independent branches that I want to pull together as a pipeline as there starts to be dependencies.. | 11:22 |
| hno | and making them into a pipeline seems like it would make my life easier. | 11:23 |
| LarstiQ | vila-lunch: Lenny is current stable, etch is oldstable | 11:38 |
| hno | figured out the pipeline by editing branch.conf by hand... seems not supported by the pipeline plugin yet. | 11:44 |
| === vila-lunch is now known as vila | ||
| vila | hno: file a bug, I don't use pipeline myself but it sounds like a feature that should be supported | 11:46 |
| === mvo is now known as drhorrible | ||
| === drhorrible is now known as mvo | ||
| lifeless | igc: | 12:15 |
| lifeless | bzr fast-import ../release67.fi.gz | 12:15 |
| lifeless | bzr: ERROR: exceptions.TypeError: __init__() got an unexpected keyword argument 'track_new_keys' | 12:15 |
| lifeless | gnight | 12:15 |
| visik71 | are there plans to support git push inside bzr ? | 12:37 |
| jelmer | visik71: eventually | 12:37 |
| === visik71 is now known as visik7 | ||
| jelmer | visik71: but the problem is we need to store bzr metadata in git somehow | 12:37 |
| jelmer | and haven't really come across anything that is suitable | 12:37 |
| visik7 | jelmer: could you use the same method used for svn ? | 12:38 |
| jelmer | visik7: git doesn't have revision properties or file properties | 12:38 |
| jelmer | so the only real alternative is to add that data at the end of the commit message :-/ | 12:38 |
| visik7 | really bad | 12:39 |
| jelmer | visik7: dpush already works, thoug | 12:39 |
| jelmer | h | 12:39 |
| visik7 | with what drawbacks ? | 12:40 |
| jelmer | it doesn't push the actual revision but a derivative of that revision | 12:41 |
| jelmer | e.g. bzr revision properties are lost (since they can't be represented in git) | 12:41 |
| visik7 | indeed I dunno what a revision properties is :) | 12:43 |
| visik7 | does bzr git plugin support authentication ? | 13:05 |
| t0mm13b | and I cannot push as I get the message that I have insufficient permissions | 13:05 |
| bialix | hi poolie, are you summon me up? | 13:05 |
| === Pilky_ is now known as Pilky | ||
| bialix | poolie: if this question still active: on Windows XP notepad will be launched; on Vista/Windows 7 -- I dunno what's default there, either notepad or wordpad | 13:06 |
| bialix | bonjour vila | 13:06 |
| vila | hi bialix ! | 13:06 |
| bialix | :-) | 13:06 |
| bialix | it's a pleasure for me to say you "bonjour" | 13:07 |
| vila | :D | 13:07 |
| bialix | how's 2.0 going? | 13:08 |
| vila | fine, 1.18 has been announced though :-) | 13:08 |
| bialix | people finally gets 1.18 announce, wow! | 13:08 |
| === vila changed the topic of #bzr to: Bazaar version control system | bzr.dev is in 2a format | 1.18 final released | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| bialix | I see there is 2.1 milestone in lp | 13:09 |
| visik7 | my workflow: bzr branch git://github.com/visik7/django-counter.git --> hack hack --> commit --> bzr dpush got a bzr: ERROR: No push location known or specified. so I issue the following command: bzr dpush git://github.com/visik7/django-counter.git --->> bzr: ERROR: <<- this without any significant error messages | 13:23 |
| hno | Argh.. my attempt in turning two branches into a pipeline did not work out.. somehow bzr pump merged the changes in both directions making them all the same.. | 13:29 |
| jelmer | visik7: I doubt you can push over git:// | 13:29 |
| jelmer | visik7: you need to push over git+ssh | 13:29 |
| visik7 | jelmer: I dunno if github supports it | 13:29 |
| jelmer | visik7: github doesn't support upshing over git://, only over git+ssh:// | 13:30 |
| visik7 | oh | 13:30 |
| visik7 | jelmer: mmm I'm pretty sure my rsa public is right but I got a Permission denied (publickey). | 13:45 |
| visik7 | bzr: ERROR: | 13:45 |
| vila | fullermd: ping | 13:50 |
| jelmer | visik7: what's the URL you're using? | 13:51 |
| visik7 | bzr dpush -v git+ssh://github.com/visik7/django-counter.git | 13:51 |
| jelmer | you need something like: | 13:51 |
| jelmer | git+ssh://git@github.com/visik7/django-counter.git | 13:51 |
| visik7 | oh | 13:52 |
| === mrevell is now known as mrevell-lunch | ||
| visik7 | jelmer: I think I can't get dpush | 13:53 |
| visik7 | bzr: ERROR: LocalGitBranch('file:///Users/visi/Documents/workspace/django-counter/', 'HEAD') and RemoteGitBranch('git+ssh://git@github.com/visik7/django-counter.git', 'HEAD') are in the same VCS, lossy push not necessary. Please use regular push. | 13:53 |
| visik7 | and obviously a normal push returns an error like this bzr: ERROR: This operation is not supported by the Git smart server protocol. | 13:54 |
| visik7 | (obviously) | 13:54 |
| visik7 | ops maybe I miss something | 13:55 |
| jelmer | is your local branch using git as well? | 13:55 |
| jelmer | if your local branch is git you should be able to push | 13:55 |
| jelmer | (git to git push works, bzr to git push does not) | 13:55 |
| visik7 | yes yes | 13:55 |
| visik7 | I've moth a clone with git and a branch with bzr | 13:56 |
| visik7 | s/moth/both | 13:56 |
| jelmer | if you push from the git clone, use "bzr push". if you push from the bzr branch, use "bzr dpush" | 13:57 |
| visik7 | so I can use the bzr command inside a git repo ? | 13:57 |
| jelmer | yes | 13:58 |
| visik7 | so I could clone with git and work with bzr ? | 13:58 |
| jelmer | yeah, *in theory* | 13:58 |
| jelmer | it should all work and I'm using it but there are some rough edges | 13:59 |
| jelmer | if you come across any, please let me know | 13:59 |
| eLBati | hi all... http://pastebin.com/m1ed6769e | 14:19 |
| eLBati | I am behind proxy | 14:19 |
| luks | does bzr know about it? | 14:22 |
| eLBati | uhm | 14:23 |
| eLBati | "whoami" knows | 14:24 |
| luks | whoami doesn't do any network operation | 14:24 |
| eLBati | what should I set? | 14:24 |
| luks | the http_proxy environment variable | 14:24 |
| luks | or maybe https_proxy | 14:24 |
| eLBati | http_proxy is correctly set | 14:25 |
| eLBati | ah sorry | 14:25 |
| luks | anyway, you don't really need launchpad-login | 14:25 |
| eLBati | luks: I didnt understand your first question | 14:25 |
| luks | I was asking whether bzr knows that you are being a proxy | 14:26 |
| eLBati | right, I set http_proxy | 14:26 |
| eLBati | bzr branch works | 14:26 |
| luks | I'd expect https to use https_proxy | 14:26 |
| luks | but I might be wrong | 14:26 |
| eLBati | uhm | 14:27 |
| CameronP | Cool 1.18 released | 14:27 |
| luks | maybe it wouldn't work - https://bugs.launchpad.net/bzr/+bug/190209 | 14:27 |
| ubottu | Ubuntu bug 190209 in bzr "launchpad plugin xmlrpc does not use $http_proxy (branching lp: uris does not use system http proxy) (dup-of: 186920)" [Medium,Confirmed] | 14:27 |
| ubottu | Ubuntu bug 186920 in python "bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls" [Unknown,Confirmed] | 14:27 |
| luks | but as I said, you don't need launchpad-login | 14:27 |
| luks | just use absolute LP urls | 14:28 |
| luks | or set launchpad_username in ~/.bazaar/bazaar.conf | 14:28 |
| eLBati | don't I need login to commit? | 14:29 |
| luks | launchpad-login just sets the launchpad_username configuration variable | 14:29 |
| luks | but it tries to be smart and want to verify the the account is correct | 14:29 |
| luks | (but fails, because it can't use a proxy) | 14:29 |
| CameronP | Hi All - what does the bzr non-admin setup file have missing (windows) | 14:30 |
| === mrevell-lunch is now known as mrevell | ||
| eLBati | it could be useful | 14:30 |
| eLBati | anyway, I'll have to use proxy | 14:30 |
| eLBati | so it could be a significant test | 14:30 |
| luks | normal bzr operations will use the proxy | 14:30 |
| luks | but the launchpad plugin doesn't | 14:30 |
| luks | but you can push only over bzr+ssh to launchpad, which you can't easily proxy | 14:31 |
| luks | so if you can't connect to port 22, pushing won't work | 14:31 |
| eLBati | oops | 14:32 |
| eLBati | damned corporate proxy | 14:33 |
| * awilkins also hates corporate proxies | 14:50 | |
| * CameronP loves corporate proxies when you can add an exception for your own pc ;) | 14:53 | |
| hno | many corporate proxies do allow port 22.these days.. | 15:25 |
| lvh | hi | 15:31 |
| awilkins | hno: We had to ask for special permission to get through the firewall... now they want us to whitelist all the servers we connect to | 15:31 |
| lvh | I've checked out two branches from twisted: bzr branch lp:twisted bzr branch lp:~lvh/twisted/positioning | 15:31 |
| lvh | I'd like them to live in the same directory | 15:31 |
| lvh | is it safe to just mv them? | 15:31 |
| lvh | And by same directory, I mean something like twisted/trunk and twisted/positioning. | 15:32 |
| awilkins | lvh: Yes | 15:32 |
| lvh | okay, awesome thanks | 15:32 |
| lvh | is it possible to get them to share files? | 15:32 |
| awilkins | lvh: You may want to instead. | 15:33 |
| awilkins | bzr init-repo twisted | 15:33 |
| awilkins | bzr branch trunk twisted/trunk | 15:33 |
| awilkins | bzr branch positioning twisted/positioning | 15:33 |
| lvh | awilkins: Awesome! Thank you :-) | 15:33 |
| awilkins | You may have to pick a more modern repo format than the default for optimal performance | 15:33 |
| lvh | except: different rich-root support | 15:33 |
| lvh | The init did Shared repository with trees (format: pack-0.92) | 15:34 |
| awilkins | bzr init-repo --1.14-rich-root | 15:34 |
| awilkins | Or --2a | 15:34 |
| lvh | Okay. I thought the new recommended fancy format was 2a? | 15:34 |
| lvh | Aha! :-) | 15:34 |
| awilkins | The format the original branch is in is probably best | 15:34 |
| luks | otherwise it has to convert, which might be very slow | 15:35 |
| luks | especially for non rich-root => rich-root formats | 15:35 |
| lvh | luks: Once, or every time I commit/push? | 15:35 |
| luks | every time you pull | 15:35 |
| luks | or ush | 15:35 |
| awilkins | Hell, anything => 2a seems slow to me | 15:35 |
| luks | *push | 15:35 |
| luks | use the same format as lp:twisted | 15:36 |
| lvh | Branch format: Branch format 7 | 15:36 |
| lvh | Repository format: Packs 6 rich-root (uses btree indexes, requires bzr 1.9) | 15:36 |
| lvh | That's lp:twisted, and mine is identical. | 15:36 |
| lvh | my branch, I mean. | 15:36 |
| awilkins | I have some SVN converts with big revisions that just make the memory explode and die when you try to conver to 2a (in the past, not tried it recently, past performance is not an indicator of future etc.etc) | 15:36 |
| lvh | so, --1.9-rich-root | 15:37 |
| lvh | ? | 15:37 |
| jelmer | awilkins: there have been a lot of improvements to 2a recently, I would suggest trying again | 15:37 |
| lvh | so the right thing to do would be to use 1.9 now and ask the maintainer nicely to convert to 2a? | 15:38 |
| awilkins | lvh: You can use 1.14, the repo format is the same | 15:39 |
| awilkins | lvh: Tis just the local working copy stuff that differs | 15:39 |
| * awilkins hopes he isn't talking too much out of his secondary orifice | 15:40 | |
| lvh | we'll find out quickly :p | 15:40 |
| lvh | appears to work :-D thanks awilkins | 15:41 |
| hno | awilkins: Have you tried doing a CONNECT server:22 HTTP/1.1 request via the corporate HTTP proxy? | 16:36 |
| awilkins | hno: My problems are mostly to do with authentication | 16:37 |
| awilkins | hno: And it being ISA server (*spit*) | 16:37 |
| CaMason | Hi guys. Is it possible for me to grab a copy of a single file at a particular revision? | 16:44 |
| CaMason | I want to save it elsewhere so I can send it to someone | 16:44 |
| awilkins | CaMason: bzr cat <file> -r <rev> > that.file | 16:44 |
| CaMason | great thanks | 16:44 |
| fullermd | vila: Blargle. Who dares disturb the great and powerful Oz? | 17:45 |
| vila | fullermd: sorry forget you were on holiday :) | 17:45 |
| vila | So, I sent a couple of patches to have a full test suite passing cleanly on FreeBSD and would appreciate your feedback there | 17:46 |
| vila | https://code.edge.launchpad.net/~vila/bzr/controversial/+merge/11295 and https://code.edge.launchpad.net/~vila/bzr/freebsd-regressions/+merge/11291 | 17:47 |
| fullermd | Oh? Nifty. You tracked down what was causing those bizarre "Revision not present" things? | 17:47 |
| vila | That doesn't ring a bell >-/ | 17:47 |
| fullermd | Ruh roh. | 17:48 |
| fullermd | I got 80 some of 'em, plus a few of the later failures that sounded like they may be expressions of the same thing. | 17:49 |
| vila | That's with bzr.dev... dunno if that changes something | 17:49 |
| vila | fullermd: --parallel=fork works nicely with the right python packages installed | 17:50 |
| vila | ok, reading your june mail again, I realize I started with far less failures/errors than you reported... | 17:51 |
| fullermd | What python are you running? | 17:52 |
| vila | may be you can try again with my two patches above ? | 17:52 |
| vila | err, the default one :-) | 17:52 |
| vila | 2,5,4 | 17:52 |
| vila | 2.5.4 sry | 17:52 |
| fullermd | Hm. 'k. I'm running 2.6.x on my workstation, where those came from. | 17:53 |
| fullermd | But at least once upon a time, I could dupe them on a box with 2.5. Picking one at random didn't right now, though... | 17:53 |
| fullermd | Heh. Of course, I don't fail some of the ones you do, since I AM in wheel ;p | 17:54 |
| vila | hmm, I'd be suprised by that kind of failures due to python, but highly interested anyway | 17:54 |
| vila | damn I'm sure I had some other questions but they escape me right now :-/ | 17:55 |
| vila | HA ! | 17:55 |
| vila | bzr reguires GNU make, right ? | 17:56 |
| Kinnison | Is it not python setuptools? | 17:56 |
| vila | to build the extensions | 17:56 |
| vila | oh.... | 17:56 |
| Kinnison | $(PYTHON) setup.py build_ext -i $(PYTHON_BUILDFLAGS) | 17:56 |
| Kinnison | is what the makefile runs when you build extensions | 17:57 |
| Kinnison | so roughly python setup.py build_ext -i | 17:57 |
| Kinnison | and that's it | 17:57 |
| vila | Kinnison: excellent idea... are you using FreeBSD ? | 17:57 |
| fullermd | The Makefile for bzr is a GNU Makefile, yeah. | 17:57 |
| vila | fullermd: but only for one ifdef /else/endif | 17:57 |
| fullermd | But usually, by the time you install 2 or 3 ports, you hit one that needs gmake anyway, so it's pretty much always around. | 17:57 |
| Kinnison | vila: God no. I have taste. | 17:57 |
| Kinnison | :-) | 17:58 |
| * fullermd . o O ( Plan 9? ) | 17:58 | |
| vila | fullermd: if you know how to get rid of that I see no reason to *not* be compatible | 17:58 |
| * Kinnison has wrestled with FreeBSD too often to use it by choice. | 17:58 | |
| vila | oh no please, I'm trying to collaborate here :) | 17:58 |
| fullermd | Not easily. BSD make has very different syntax for it. You'd pretty much have to find a way to rewrite around the conditions. | 17:59 |
| Kinnison | Couldn't we just call the makefile Makefile.gnu | 17:59 |
| Kinnison | ? | 17:59 |
| Kinnison | then it'd be clear | 17:59 |
| vila | FWIW, I setup a VM with FreeBSD and the experience wasn't that bad compared to say... installing Solaris 10 ? | 17:59 |
| fullermd | Or alternately, build one Makefile format from the other. | 17:59 |
| Kinnison | vila: Oh, the initial setup wasn't painful. It was then trying to do useful stuff with it which hurt | 17:59 |
| fullermd | (I've done that; I have projects with a prototype Makefile, and awk scripts to generate bmake and gmake files from it) | 17:59 |
| fullermd | Kinnison: GNUmakefile is [one of] the names that gmake checks and others don't. | 17:59 |
| vila | fullermd: ok, thanks, that was the answer I wanted, I'm sure we can get rid of that though | 18:00 |
| fullermd | But I doubt it's worth putting any effort into. | 18:00 |
| fullermd | Only really matters to people working with the source tree, and you can pretty well assume anybody doing that has GNU make. | 18:00 |
| vila | next one: I use export VAR=value in my buildbot makefiles, that too, is GNUMake specific and allows one to, duh, export variables to the spawned shells | 18:01 |
| vila | I use that to force and control the environment my slaves run under, how do you do that ? | 18:01 |
| fullermd | Not sure... export is sh syntax, not make AFAIK. | 18:01 |
| fullermd | There's a bright line between make vars and env vars, except when there's not. It's one of the real mind-twisting grump-inducers of working with make. | 18:02 |
| vila | I thought so too, until I needed a way to impose PATH in the Makefile instead of the crontab (which sucks) | 18:02 |
| vila | yeah, I never needed that before and was happy with make inheriting shell vars | 18:03 |
| vila | but PATH... | 18:03 |
| fullermd | There's a way to override the shell, so you could presumably wrap an env(1) around it. But that sounds hacky, and probably acts very differently between make's. | 18:04 |
| vila | ok, I'll stick with gmake then... the hack is then limited to: ln -s `which gmake` $HOME/bin/make ; export PATH=$HOME/bin:$PATH :-} | 18:06 |
| vila | How about being an heretic ? :-D | 18:06 |
| vila | fullermd: don't hit me ! It's only for the slave ! Not even for my .bashrc I promise ! :) | 18:07 |
| fullermd | Why not just call 'gmake' instead of 'make'? That link should be present on every platform. | 18:07 |
| fullermd | (except those without GNU make, but that's a problem anyway) | 18:07 |
| vila | yes and no, *I* searched for gmake by instinct, but it doesn't make sense on a GNU/xxx system ... | 18:08 |
| vila | fullermd: that is, in an ideal world I agree with you, I should use gmake, practically, the hack above is easier since only one slave needs it... | 18:09 |
| fullermd | How so? You want GNU make, gmake is how you call GNU make. I'm pretty sure any system with GNU make has it accessible there... | 18:09 |
| vila | accesible as make, yes | 18:09 |
| fullermd | As gmake | 18:09 |
| vila | but neither linux nor OSX as gmake ... | 18:10 |
| fullermd | Sure it is. I see it on Redhat and (a very old) Slackware, for instance. | 18:10 |
| vila | and I'm pretty sure stock Solaris hasn't it either (though when you install it it's as gmake) | 18:10 |
| vila | sry, I meant Ubuntu | 18:10 |
| fullermd | Oh. Well, who cares about weird niche systems like that? ;p | 18:11 |
| vila | OSX you mean ? :D | 18:11 |
| fullermd | Sure, that too O:-) | 18:11 |
| vila | anyway, thanks fullermd for the quick and clear answers (again), | 18:12 |
| fullermd | Have you run the 2a conversion of your bzr branches? | 18:13 |
| vila | one last thing: the botnet now includes a FreeBSD slave | 18:13 |
| vila | fullermd: they are in 2a yes | 18:13 |
| fullermd | Ah, 'k. I haven't yet, so it'll probably be a little while before I can try out those merges. | 18:14 |
| vila | as is their base branch | 18:14 |
| vila | shallow feedback by looking at the diffs welcome too :) | 18:14 |
| vila | fullermd: one last thing ! | 18:15 |
| vila | sys.platform.startswith('freebsd') is the correct way to test for freebsd right ? | 18:15 |
| fullermd | Ah, that's a python question; beyond my ken. | 18:15 |
| vila | but isn't that a bit... unfriendly for the others BSDs ? | 18:16 |
| fullermd | But AFAIK they're all "freebsdX", and nothing else would be, so it's probably a good enough trigger. | 18:16 |
| fullermd | Well, for things that would need to hit on them too, it would mean chaining more if conditions, yeah. | 18:16 |
| vila | ok, may be you know who to ask that question though ? | 18:16 |
| fullermd | I dunno if there's some way to ask for "BSD family", if that's really meaningful (or what it means; is OS X BSD family? Well...) | 18:17 |
| maxb | Hmm. I did "bzr pack" and my repository got larger. There is a lot of stuff in obsolete_packs. How does that get cleaned? | 18:17 |
| fullermd | It sounds more a python question than an OS one; I'm not sure how sys gets its information. | 18:17 |
| vila | maxb: at your next commit/pull/ any write operation to the repository | 18:18 |
| fullermd | maxb: They're deleted next time an [auto]pack runs. Or you can delete them manually if you trust that your FS has the new stuff committed to platter. | 18:18 |
| vila | maxb: fullermd says it better than me :) | 18:18 |
| vila | fullermd: ok, let's start with freebsd and we'll see how it goes, so far it's only in a couple of tests and in osutils to get the number of CPUs, so really no big deal | 18:20 |
| fullermd | Yah. We may not QUITE be at the final release of bzr ever yet, so there's time to adjust later :) | 18:21 |
| vila | 1.18 is out though :) | 18:23 |
| * vila EODing | 18:23 | |
| fullermd | Yeah, that's why I updated the port like 2 weeks ago... | 18:24 |
| === khmarbaise__ is now known as khmarbaise | ||
| lifeless | moin | 20:02 |
| Kmos | there is a way to get replaces files by M after an bzr revert ? | 20:08 |
| Kmos | *replaced | 20:09 |
| lifeless | what do you mean? | 20:09 |
| Kmos | I've modified some files in directory A | 20:10 |
| Kmos | I've removed directory B | 20:10 |
| Kmos | and done an revert | 20:10 |
| Kmos | to get files from B back | 20:10 |
| Kmos | and it also replaced the A ones | 20:10 |
| lifeless | oh ok | 20:10 |
| lifeless | I'll just look up the backup rules | 20:11 |
| lifeless | but in future do 'bzr revert B' and it won't touch A | 20:11 |
| Kmos | thanks for the tip | 20:11 |
| Kmos | i know it does backups.. but bzr help revert only shows how to not backup | 20:11 |
| lifeless | I think they get called .~1~ | 20:12 |
| lifeless | have a look for A/*~* | 20:12 |
| Kmos | yep, that's it | 20:12 |
| Kmos | thank you very much =) | 20:12 |
| lifeless | my pleasure, great way to start a morning :) | 20:13 |
| Kmos | :) | 20:13 |
| Kmos | here is more end of the day =P | 20:13 |
| igc | igc | 20:34 |
| igc | morning | 20:34 |
| lifeless | hi igc | 20:40 |
| lifeless | can't sleep? | 20:40 |
| igc | lifeless: early night last night for a change | 20:46 |
| lifeless | igc: \o/ | 20:46 |
| lifeless | how is the health | 20:46 |
| igc | lifeless: getting better each week | 20:46 |
| fullermd | You know how the saying goes... early to bed and early to rise, and you'll be groggy when everybody else is wide awake :p | 20:47 |
| igc | fulermd: precisely! | 20:47 |
| igc | fullermd ^ | 20:48 |
| igc | clearly it's early for me | 20:48 |
| fullermd | 's what you get for going to bed before the sun comes up. | 20:49 |
| lifeless | fullermd: have to; sunlight is fatal :P | 20:50 |
| fullermd | That's a myth. It's perfectly safe in small doses. | 20:51 |
| fullermd | Say, 10 minutes a year. | 20:51 |
| fullermd | (not all at once of course...) | 21:01 |
| AnAnt | Hello, is there a way to cherrypick a revision from one branch into another branch ? | 21:03 |
| lifeless | AnAnt: bzr merge -c revno | 21:09 |
| AnAnt | lifeless: I see, thanks | 21:11 |
| === _SamB_ is now known as SamB | ||
| * igc food | 21:42 | |
| lifeless | igc: hi | 21:44 |
| lifeless | when you get back; fast-import, and your two patches, I'd like to help as I can on them | 21:44 |
| igc | thanks lifeless - that would be great | 22:10 |
| igc | lifeless: I'll be a little longer though ... | 22:10 |
| igc | getting kids ready for school | 22:10 |
| patx | can bzr or git or even svn have static-http options like hg does "hg clone static-http://example" | 22:16 |
| lifeless | patx: bzr branch http://foo/ will work without a server - using the plain files on disk. | 22:23 |
| patx | ok ty | 22:23 |
| lifeless | patx: it attempts to find a smart server but falls back gracefully. | 22:23 |
| Goundy | Guys I'm just wondering, someone knows some irc bot or a website offering a irc bot that report bazaar commits into a channel ? | 22:32 |
| lifeless | yup | 22:38 |
| lifeless | you can use cia | 22:38 |
| Goundy | lifeless ow ? CIA works only for svn no ? | 22:38 |
| lifeless | and | 22:38 |
| lifeless | http://radix.twistedmatrix.com/2007/02/bzr-and-commit-messages-and-irc-bots.html | 22:38 |
| lifeless | bzr-cia is a plugin for bzr | 22:39 |
| lifeless | that tells cia about commits | 22:39 |
| Goundy | lifeless ow interesting, thank you | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!