[00:03] <mwhudson> how big is bzr.dev in 2a format?
[00:03] <wgrant> mwhudson: Around 40MB here.
[00:04] <mwhudson> hm, i wonder why getting lp:bzr has transferred 60 odd megs then
[00:05] <wgrant> The copy I grabbed a few days ago was badly packed.
[00:05] <mwhudson> oh
[00:16] <lifeless> mwhudson: lp is running 1.17
[00:17] <lifeless> mwhudson: additional data added to it will not be packing well
[00:17] <lifeless> though we did pack the mirror repo
[00:18] <mwhudson> ah ok
[00:18] <lifeless> loggerhead is odd ><
[00:19] <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:20] <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:21] <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:22] <lifeless> I'll file a bug
[00:26] <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:27] <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:28] <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:29] <mwhudson> hm 1.18dev locally, maybe quite old
[00:30] <lifeless> please upgrade and repeat
[00:30] <lifeless> other than that tab, its ok ?
[00:31] <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:32] <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:33] <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:34] <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:35] <lifeless> poolie: ping
[00:36] <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:37] <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:38] <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:40] <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:50] <jelmer> SamB: that should also already work
[00:50] <jelmer> lifeless: hey
[00:50] <jelmer> lifeless: subunit review is on my radar
[00:56] <lifeless> jelmer: thanks; its actually the perl stuff I wanted to ping you about
[01:02] <spiv> lifeless: update that branch to 2a, you mean?
[01:03] <spiv> lifeless: I have, but there's an LP bug :(
[01:03] <spiv> lifeless: bug 424136
[01:05] <mwhudson> ah right, i should look at that today
[01:05] <spiv> mwhudson: yes please!
[01:13] <mwhudson> gah
[01:13] <igc> morning
[01:13] <mwhudson> lifeless: i ran that fetch again, but failed to monitor how much it transferred
[01:14] <lifeless> :P
[01:24] <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:27] <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:28] <rar> (or rather the same thing in the last 1.9 change, but it's the same text)
[01:29] <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:31] <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:33] <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:39] <igc> rar: yes
[01:40] <igc> rar: so poolie and lifeless have migrated bzr.dev to 2a now
[01:41] <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:42] <igc> rar: I've just did exactly this last Friday for some branches and I'm pulling/merging others across today
[01:43] <rar> but, that means downloading some large number of bytes from the internet? then... re-branching all my branches into a new directory?
[01:45] <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:46] <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:47] <rar> bad at certain times of day, but you may be right that redownloading is a quicker process than running upgrade
[01:49] <lifeless> spiv: can you mail me a bundle against 2.0 of your branch please
[01:50] <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:51] <rar> there's a doc patch from two years ago that I really should have finished...
[01:52] <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:53] <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:54] <igc> rar: grabbing the converted bzr.dev is a lot quicker than that for me at least
[01:55] <lifeless> igc: worth documenting 'easy but slow', 'fast but manual'
[01:56] <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:57] <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:58] <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.
[02:05] <poolie> spiv, igc, hello
[02:05] <igc> hi poolie
[02:06] <poolie> igc, i was planning to look at bug 385879 today
[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:07] <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:08] <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:09] <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:10] <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:11] <lifeless> igc: hmm, re: check one branch in a repo - bug I think
[02:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <lifeless> brb
[02:18] <igc> lifeless: the input stream and repo need to match exactly fwiw
[02:20] <spm> lifeless: not in the chroot, no
[02:27] <poolie> spiv, how's stuff?
[02:33] <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] <poolie> ok
[02:34] <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:36] <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:37] <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:38] <spm> lifeless: sure, but I dno't have privs to do so. Super urgent?
[02:38] <lifeless> spm: not super.
[02:39] <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:51] <lifeless> spm: please cancel the current bzr pqm job
[02:51] <spm> oki
[02:53] <lifeless> thanks
[02:53] <spm> is done
[03:19] <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:20] <jml> lifeless, cool.
[03:25] <lifeless> igc: what sort of compression ratio do you expect out of gz on .fi's?
[03:26] <igc> lifeless: 5-10X better typically
[03:26] <igc> at a guess
[03:26] <lifeless> thanks
[03:32] <igc> lifeless: as a guide, some gzipped sizes ... firefox 3.5: 1.7G, kernel: 2.6G, mysql-server 5.1: 7.3G
[03:34] <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:44] <poolie> lifeless: i suggest we ask about series etc on the launchpad list next
[03:44] <lifeless> poolie: ok :)
[03:45] <poolie> see also #launchpad now
[03:49] <lifeless> am there ;)
[03:52] <lifeless> poolie: this seems to be orthogonal to milestones, yes?
[03:53] <lifeless> poolie: I want to fix the inconsistent docs while its in my head; Ideally I'd only touch them once..
[03:54] <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:55] <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:56] <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:57] <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:58] <poolie> mm
[03:59] <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'
[04:00] <lifeless> its thorny
[04:08] <lifeless> poolie: so, if we're going to generally avoid renaming milestones, should we rename 2.0 to 2.0rc2
[04:09] <lifeless> e.g. undo part of the changes I did
[04:12] <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:13] <lifeless> poolie: ^
[04:14] <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:15] <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:16] <poolie> wfm
[04:16] <poolie> by which i mean, that's fine with me
[04:19] <lifeless> submitting the merge:-> (Error ID: OOPS-1346ED42)
[04:23] <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:24] <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:25] <lifeless> spiv: has 423506 landed in 2.0 ?
[04:28] <lifeless> spiv: if so, please put bug numbers in the pqm message, it helps.
[04:32] <lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+bug/406687
[04:32] <lifeless> If we're on the same page, that bug's metadata will be appropriate for both of us
[04:33] <lifeless> blocking the next 2.0 release; to be fixed on both 2.0 and trunk.
[04:33] <poolie> looks good to me
[04:36] <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:37] <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:39] <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:40] <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:41] <lifeless> and a few others today :)
[04:44] <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:45] <igc> lifeless: fast-import fold None to '' currently iirc
[04:46] <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:47] <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:48] <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:49] <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:50] <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:51] <igc> yep
[04:52] <lifeless> sent
[04:52] <igc> thanks
[04:52] <lifeless> my pleasure
[04:52] <lifeless> I know you like to squeeze speed out :)
[04:53]  * lifeless is off to finish paying for a sofa
[04:53] <lifeless> on the mobile if folk need me
[05:00]  * igc lunch
[05:09] <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:13] <poolie> i don't mind but i still boggle at how early your work day is
[05:13] <poolie> anyhow, jolly good
[05:16] <poolie> lifeless: http://bzr.pastebin.com/d7e16641f -- i'm not complaning about the change but the way launchpad presents this is a bit suboptimal
[06:57] <vila> hi all
[07:07] <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:12] <lifeless> hi vila
[08:11] <poolie> hi vila
[08:11] <vila> hey !
[08:19] <poolie> vila, regarding bug handling
[08:19] <poolie> your mail was pretty thoughtful
[08:20] <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:21] <vila> I can adapt to anything we decide to do :)
[08:26] <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:42] <lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+milestone/2.0
[08:42] <poolie> mm?
[08:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <vila> do you mean 3 for inprogress instead ?
[08:58] <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:59] <vila> That makes me want to file a lp bug about private/public *user-managed* bug lists
[08:59] <poolie> it'd be good
[09:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <lifeless> vila: I mean in trunk, right now.
[09:07] <lifeless> vila: my patch just removes some redundant conditionals from the language.
[09:08] <vila> lifeless: right, I wasn't at the right page :)
[09:08] <vila> wgrant: thanks
[09:09] <poolie> i am not convinced bug 421789 or bug 385879 should be blockers
[09:15] <lifeless> poolie: then I think you/we should decide. And if they aren't take them out of the list.
[09:16] <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:17] <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:18] <lifeless> poolie: yes, I agreed with you this morning, and I still do :)
[09:19] <vila> lifeless: please have a look at my comments before landing lp:~lifeless/bzr/docs
[09:20] <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:21] <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:22] <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:24]  * igc dinner
[09:32] <vila> spiv: Are you you still around ?
[09:33] <poolie> ok, i'll announce it too
[09:34] <igc> poolie: given there's agreement to take the Windows installer out of the core, bug 421789 not a blocker
[09:34] <poolie> cool
[09:35] <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:36] <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:44] <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:45] <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:46] <lifeless> vila: btw, I taught buildbot about subunit in the weekend
[09:46] <lifeless> http://buildbot.net/trac/ticket/610
[09:47] <vila> lifeless: hehe, excellent !
[09:49] <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:50] <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:58] <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:59] <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 ?
[10:00] <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:07] <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:08] <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:09] <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:10] <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:11] <wgrant> Is there a source of bzrs for Lenny that is less ancient than backports.org?
[10:12] <vila> I think LarstiQ said this week-end that Lenny isn't supported anymore ?
[10:13] <wgrant> That seems unlikely -- it's the current stable release, and had a point release yesterday.
[10:16] <vila> wgrant: right :-) My ignorance is just showing off then
[10:18]  * 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:19] <wgrant> vila: etch is barely supported.
[10:20] <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:34] <gour> pygi: ping
[10:48] <vila> BAM ! http://en.expreview.com/2009/09/04/ocz-spruces-up-its-z-drive-ssds.html#more-5073
[10:49] <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:52] <poolie> vila: did you get my bazaar-announce list?
[10:53] <vila> poolie: yup
[10:53] <poolie> great, thanks
[10:58] <poolie> vila/bialix: silly question maybe but what happens in windows if you run bzr commit with no -m ?
[11:01] <poolie> it runs wordpad apparently
[11:10] <rar> notepad for me.
[11:18] <hno> Is it possible to convert an existing set of branches to a pipeline?
[11:19] <hno> using a shared repository btw.
[11:22] <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:23] <hno> and making them into a pipeline seems like it would make my life easier.
[11:38] <LarstiQ> vila-lunch: Lenny is current stable, etch is oldstable
[11:44] <hno> figured out the pipeline by editing branch.conf by hand... seems not supported by the pipeline plugin yet.
[11:46] <vila> hno: file a bug, I don't use pipeline myself but it sounds like a feature that should be supported
[12:15] <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:37] <visik71> are there plans to support git push inside bzr ?
[12:37] <jelmer> visik71: eventually
[12:37] <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:38] <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:39] <visik7> really bad
[12:39] <jelmer> visik7: dpush already works, thoug
[12:39] <jelmer> h
[12:40] <visik7> with what drawbacks ?
[12:41] <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:43] <visik7> indeed I dunno what a revision properties is :)
[13:05] <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:06] <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:07] <bialix> it's a pleasure for me to say you "bonjour"
[13:07] <vila> :D
[13:08] <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:09] <bialix> I see there is 2.1 milestone in lp
[13:23] <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:29] <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:30] <jelmer> visik7: github doesn't support upshing over git://, only over git+ssh://
[13:30] <visik7> oh
[13:45] <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:50] <vila> fullermd: ping
[13:51] <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><EMAIL_ADDRESS>[13:52] <visik7> oh
[13:53] <visik7> jelmer: I think I can't get dpush
[13:53] <visik7> bzr: ERROR: LocalGitBranch('file:///Users/visi/Documents/workspace/django-counter/', 'HEAD') and<EMAIL_ADDRESS>'HEAD') are in the same VCS, lossy push not necessary. Please use regular push.
[13:54] <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:55] <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:56] <visik7> I've moth a clone with git and a branch with bzr
[13:56] <visik7> s/moth/both
[13:57] <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:58] <jelmer> yes
[13:58] <visik7> so I could clone with git and work with bzr ?
[13:58] <jelmer> yeah, *in theory*
[13:59] <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
[14:19] <eLBati> hi all... http://pastebin.com/m1ed6769e
[14:19] <eLBati> I am behind proxy
[14:22] <luks> does bzr know about it?
[14:23] <eLBati> uhm
[14:24] <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:25] <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:26] <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:27] <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] <luks> but as I said, you don't need launchpad-login
[14:28] <luks> just use absolute LP urls
[14:28] <luks> or set launchpad_username in ~/.bazaar/bazaar.conf
[14:29] <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:30] <CameronP> Hi All - what does the bzr non-admin setup file have missing (windows)
[14:30] <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:31] <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:32] <eLBati> oops
[14:33] <eLBati> damned corporate proxy
[14:50]  * awilkins also hates corporate proxies
[14:53]  * CameronP loves corporate proxies when you can add an exception for your own pc ;)
[15:25] <hno> many corporate proxies do allow port 22.these days..
[15:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <lvh> so the right thing to do would be to use 1.9 now and ask the maintainer nicely to convert to 2a?
[15:39] <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:40]  * awilkins hopes he isn't talking too much out of his secondary orifice
[15:40] <lvh> we'll find out quickly :p
[15:41] <lvh> appears to work :-D thanks awilkins
[16:36] <hno> awilkins: Have you tried doing a CONNECT server:22 HTTP/1.1 request via the corporate HTTP proxy?
[16:37] <awilkins> hno: My problems are mostly to do with authentication
[16:37] <awilkins> hno: And it being ISA server (*spit*)
[16:44] <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
[17:45] <fullermd> vila: Blargle.  Who dares disturb the great and powerful Oz?
[17:45] <vila> fullermd: sorry forget you were on holiday :)
[17:46] <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:47] <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:48] <fullermd> Ruh roh.
[17:49] <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:50] <vila> fullermd: --parallel=fork works nicely with the right python packages installed
[17:51] <vila> ok, reading your june mail again, I realize I started with far less failures/errors than you reported...
[17:52] <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:53] <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:54] <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:55] <vila> damn I'm sure I had some other questions but they escape me right now :-/
[17:55] <vila> HA !
[17:56] <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:57] <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:58] <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:59] <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.
[18:00] <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:01] <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:02] <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:03] <vila> yeah, I never needed that before and was happy with make inheriting shell vars
[18:03] <vila> but PATH...
[18:04] <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:06] <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:07] <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:08] <vila> yes and no, *I* searched for gmake by instinct, but it doesn't make sense on a GNU/xxx system ...
[18:09] <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:10] <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:11] <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:12] <vila> anyway, thanks fullermd for the quick and clear answers (again),
[18:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:20] <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:21] <fullermd> Yah.  We may not QUITE be at the final release of bzr ever yet, so there's time to adjust later  :)
[18:23] <vila> 1.18 is out though :)
[18:23]  * vila EODing
[18:24] <fullermd> Yeah, that's why I updated the port like 2 weeks ago...
[20:02] <lifeless> moin
[20:08] <Kmos> there is a way to get replaces files by M after an bzr revert ?
[20:09] <Kmos> *replaced
[20:09] <lifeless> what do you mean?
[20:10] <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:11] <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:12] <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:13] <lifeless> my pleasure, great way to start a morning :)
[20:13] <Kmos> :)
[20:13] <Kmos> here is more end of the day =P
[20:34] <igc> igc
[20:34] <igc> morning
[20:40] <lifeless> hi igc
[20:40] <lifeless> can't sleep?
[20:46] <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:47] <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:48] <igc> fullermd ^
[20:48] <igc> clearly it's early for me
[20:49] <fullermd> 's what you get for going to bed before the sun comes up.
[20:50] <lifeless> fullermd: have to; sunlight is fatal :P
[20:51] <fullermd> That's a myth.  It's perfectly safe in small doses.
[20:51] <fullermd> Say, 10 minutes a year.
[21:01] <fullermd> (not all at once of course...)
[21:03] <AnAnt> Hello, is there a way to cherrypick a revision from one branch into another branch ?
[21:09] <lifeless> AnAnt: bzr merge -c revno
[21:11] <AnAnt> lifeless: I see, thanks
[21:42]  * igc food
[21:44] <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
[22:10] <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:16] <patx> can bzr or git or even svn have static-http options like hg does "hg clone static-http://example"
[22:23] <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:32] <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:38] <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:39] <lifeless> bzr-cia is a plugin for bzr
[22:39] <lifeless> that tells cia about commits
[22:39] <Goundy> lifeless ow interesting, thank you


[01:45] !dmwaters:*! Hi all, that split was a rotation server that was taken out for maintenence. that wasn't the planned maintenence, but we know what the problem was.:)
[02:22] !dmwaters:*! One more split for that rotation server that's not in rotation right now folks
[01:08] <mdz> tko: bazaar offers us a lot over git; it's well integrated with launchpad, easier to learn and use, more robust
[01:09] <mdz> tko: what do you have in mind which would make git attractive?  anything other than being faster?
[01:10] <mdz> bazaar seems much more featureful
[01:17] <asac> mdz: git rebase is pretty handy
[01:18] <mdz> asac: what does that do?
[01:18] <mdz> reading http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html, that sounds like what bzr does by default, automatically
[01:19] <mdz> if you have local changes and do a merge
[01:19] <mdz> oh, it's talking about commits, not local changes
[01:19] <asac> yes ... you can rebase
[01:19] <asac> its pretty handy if you have committed changes that are not yet ready for upstream inclusion
[01:20] <asac> e.g. if you upstream branch moves ahead you end up with with distinct patches for your features
[01:20] <asac> you can probably do it with bzr as well ... but there is not a single command that does that for you imo.
[01:21] <mdz> right
[01:21] <asac> e.g. for me its pretty nice to keep clean patches against mozilla code base
[01:21] <mdz> I'm not aware of one, though it's something which could be done easily as a plugin
[01:22] <asac> nice thing is that a rebase detects if you already cherry-picked some  commit from parent branch
[01:23] <mdz> asac: you import mozilla into git?
[01:23] <asac> somehow :) ... i import new upstream releases manually (e.g. checkins are not preserved)
[01:23] <mdz> what happens if you rebase, and then someone who has merged from your branch tries to merge again?
[01:24] <mdz> but your commits have disappeared
[01:24] <asac> you should not rebase on published branches
[01:24] <mdz> :-)
[01:24] <mdz> all branches should be published
[01:24] <mdz> I think the bazaar answer to the general use case is looms
[01:25] <mdz> that will give you a similar result but in a clean and mergeable way
[01:25] <lool> mdz: I suppose you saw keithp's post on the robustness of the storage?
[01:25] <mdz> lool: no
[01:25] <mdz> url?
[01:26] <lool> I think it's http://keithp.com/blog/Repository_Formats_Matter.html
[01:26] <asac> mdz: i will look at looms :)
[01:33] <mdz> lool: I don't know enough about bzr's storage model to know how it compares on those specific points
[01:34] <asac> mdz: i really like bzr ... i am just unhappy that we didn't get the mozilla deal :(
[01:38] (Mithrandir/#ubuntu-mobile) we have the offline repo access, the private branches and the distributed backups just fine, but we rewrite the object files, and don't really do compression
[01:38] (Mithrandir/#ubuntu-mobile) and we're much slower than git.
[01:39] <mdz> yes, I think every distributed VCS has those three principal advantages
[01:39] <mdz> I don't think we rewrite files, though we do append
[01:40] <mdz> Mithrandir: I'm pretty sure knits incorporate delta compression of some sort
[01:41] (Mithrandir/#ubuntu-mobile) ok
[01:41] <mdz> I admit I like the idea of git's batch compression, since it maps well to usage (the bulk of history is old and already compressed, new stuff can be packed up later)
[01:41] <mdz> it probably works well for small files
[01:43] <mdz> http://bazaar-vcs.org/HistoryHorizon is more interesting I think
[01:43] <mdz> it doesn't matter if the history is huge if you only get what you need
[02:24] <ferulo> agoliveira, mdz you lost me :)
[02:27] <agoliveira> ferulo: Hi Fernando. Lost you for what?
[02:27] <ferulo> conferences :)
[02:28] <agoliveira> Ah...
[04:18] !christel:*! Hi all. The PDPC Board and freenode staff wish to make it clear that Andrew Kirch, aka trelane, does not in any capacity speak for or represent freenode, the PDPC board, or any member thereof. Please disregard any rumours to the omtrary. Formal statement to follow on our website.
[04:20] !christel:*! oops. ssh lag got the better of me, omtrary is of course, christelsk for contrary! Sorry for the disturbance and have a great day.
[05:54] (tko/#ubuntu-mobile) mdz: speed is pretty much the immediately most obvious thing
[05:56] (tko/#ubuntu-mobile) mdz: granted I've been mostly using git-svn but there's just something that makes it feel better once you get over the learning curve
[06:54] (tko/#ubuntu-mobile) I think my feeling about bzr vs. git is about perception mostly. I gather they're mostly comparable in terms of features, but git is faster and it's used by kernel, X and cairo. other than launchpad I can't name a single project that would have picked bzr
[07:48] <ferulo> tko: telepathy stuff
[07:49] <ferulo> well, they mix darcs and bzr IIRC
[08:14] <adilson> I finished entering all the basic hildon components (from Tommi's list) into launchpad. I'll now go over the python bindings which I believe we are going to need anyway.


 neight <-- no no nono nonono no no no no no no.
[00:31] <h00k> I didn't sound that one out.
[00:31] <h00k> >.<
[00:33] <h00k> does that first part stay consistent? (the web gateway)
[00:33] <elky> yes
[00:33] <elky> that's the hash
[00:34] <h00k> okay, just making sure, I forget that part.
[00:36] <elky> * an8yearoldvagyna is now known as MiraclePenys <-- noted in #freenode
[00:37] <IdleOne> banned from #u
[00:39] <Jordan_U> Is Benkinooby (currently in #ubuntu) the same user as Benk_ (the user who was removed from #ubuntu for giving a mallicious command)? The nick is similar and Benkinooby said "lol" after Benk_'s removal.
[00:42] <IdleOne> Jordan_U: would need to check with staff to see if they are ban evading with that cloak
[00:44] <Jordan_U> IdleOne: There is no ban that I know of, and Benkinooby was in the channel before Benk_ was removed.
[00:44] <Jordan_U> No ban yet at least, I was planning to add a ban forward for the malicious command incident.
[00:45] <IdleOne> might be the same user and hopefully the removal knocked some sense into them
[00:45] <Jordan_U> The "lol" suggests otherwise :(
[00:45] <Jordan_U> I guess there isn't much to do about it at the moment though.
[05:02] <Tm_T> morning
[06:34] <Myrtti> what is KM0201 doing?
[06:34] <bazhang> PM helping jen?
[10:27] <vibhav> Am I unabnned
[10:28] <Tm_T> no, you're not
[10:28] <Tm_T> 1824.42 <+ikonia> vibhav: could you please leave this channel, and come back no sooner than 2 weeks
[10:29] <Tm_T> vibhav: I would kindly ask you to follow the request ikonia made yesterday
[10:35] <vibhav> Why?
[10:35] <vibhav> ikonia abuses his op powers
[10:36] <ikonia> not this again
[10:36] <vibhav> He does
[10:36] <ikonia> vibhav: you are currently ban evading in #ubuntu
[10:36] <ikonia> I've removed you
[10:36] <vibhav> Ok
[10:36] <vibhav> I was not ban evading
[10:37] <ikonia> vibhav: do you know you are banned in #ubuntu yes/no
[10:37] <ikonia> vibhav: I explained in detail the reason you where banned yesterday
[10:37] <vibhav> Yes
[10:37] <ikonia> so why did you join #ubuntu
[10:37] <vibhav> The reason was not approriate
[10:37] <vibhav> Xchat automatically joins #ubuntu
[10:37] <ikonia> vibhav: right, so you are ban evading, I'm informing you I've removed you
[10:37] <vibhav> Mute me
[10:38] <vibhav> so you are ban evading is a wrong sentence
[10:38] <ikonia> no, I've removed you as you are ban evading
[10:38] <ikonia> vibhav: either way, we'll discuss the ban in 2 weeks as I said yesterday
[10:38] <vibhav> Why
[10:38] <vibhav> ikonia make this clear - I read that complete guide and gave it to him
[10:39] <ikonia> for the reasons I explained yesterday which I don't want to re-cover pointlessly again
[10:39] <vibhav> Its not important for me to Use that guide
[10:40] <ikonia> it was important for you to have read it and understood it before giving it to people
[10:40] <ikonia> you'd been warned and banned for this behaviour before, you did it again, you got re-banned, it's that simple
[10:40] <ikonia> I'm not going to discuss it further
[10:40] <vibhav> I understood and read it
[10:40] <vibhav> Why
[10:40] <vibhav> just because you are Losing the argument?
[10:40] <vibhav> There is nothing Simple in it
[10:40] <ikonia> vibhav: 1.) I asked you clearly "have you read this guide"
[10:41] <ikonia> vibhav: you said "no"
[10:41] <ikonia> vibhav: I banned you
[10:41] <ikonia> vibhav: you then said "oh, I have read it"
[10:41] <Tm_T> vibhav: this argumentation has been done before, there is no reason to do it again
[10:41] <ikonia> vibhav: it's clearly obviously you had not read the guide as it was full of dead URLs and missing information
[10:41] <vibhav> YOU ASKED ME , THAT , HAVE YOU USED THIS GUIDE?
[10:41] <ikonia> vibhav: you had clearly not read the guide
[10:41] <vibhav> I had
[10:41] <ikonia> vibhav: typing it caps won't help
[10:41] <vibhav> i KNOW
[10:41] <vibhav> ikonia , You are not fit to be an op
[10:42] <ikonia> then don't do it
[10:42] <ikonia> vibhav: one of my responsabilities it to make sure the users of the channel do not get bad advice
[10:42] <Tm_T> !appeal > vibhav
[10:42] <ikonia> vibhav: you are providing bad advice on a regular basis
[10:42] <ikonia> vibhav: hence why this loop has re-occured
[10:42] <vibhav> That was not bad !
[10:42] <ikonia> vibhav: it was
[10:42] <vibhav> Do you know what is bad advice
[10:42] <ikonia> vibhav: it had incorrect information in it, and when I asked you about it, you had no idea of what it actually did
[10:43] <vibhav> thanks Tm_T
[10:43] <ikonia> vibhav: that means you're pushing advice which you don't know what it does to fix something
[10:43] <Tm_T> vibhav: for the record, I agree ikonia on this
[10:43] <vibhav> Why?
[10:43] <Tm_T> the very same argumentation ikonia has used
[10:43] <Tm_T> and I repeat: this argumentation has been done before, there is no reason to do it again
[10:43] <vibhav> "Mistakes can be made by both sides"
[10:43] <Tm_T> it won't lead to anywhere
[10:44] <vibhav> this was yours
[10:44] <Tm_T> vibhav: yes
[10:44] <Tm_T> vibhav: but there's two options on proceeding on this, being not exclucive on each other
[10:45] <vibhav> ikonia only knows how o critisize others
[10:45] <Tm_T> vibhav: please stop now
[10:45] <vibhav> criticize
[10:45] <vibhav> Why Stop
[10:45] <vibhav> Cant I defend for myself?
[10:45] <ikonia> vibhav: not at all, I often make mistakes and I'm corrected by others,
[10:46] <ikonia> vibhav: I also support other people, that's not critising them,
[10:46] <Tm_T> 1) you wait 2 weeks before re-entering this channel and try discuss matter then. 2) you proceed on the steps described in appeal process
[10:46] <vibhav> No you do not
[10:46] <Tm_T> vibhav: stop, this is not useful, this is not defending yourself, this is only wasting time
[10:46] <vibhav> No this is not
[10:47] <vibhav> Ops think too much of themselves
[10:47] <ikonia> I'll back out at this time and make sure the logs / comments are up to date
[10:47] <Tm_T> vibhav: then proceed on appeal process, no amount of discussion here now will change this
[10:47] <vibhav> Make this clear - I was not giving bad advice , I was offering suggestion
[10:48] <Tm_T> if he returns before two weeks, I will not give him time to try relaunching the conversation
[10:49] <ikonia> I only said two weeks in the hope that he may consider what he does this time
[10:49] <ikonia> keep unbanning him he just carrys on, if it's set a little longer, hey may consider it
[10:49] <Tm_T> indeed
[10:52] <Myrtti> might want to do an ip host ban?
[10:52] <Myrtti> since his client identifies after joining the channels
[10:52] <ikonia> I'm just looking at what happened with the cloak ban
[10:52] <Myrtti> his ident seems stable enough
[10:52] <Myrtti> nothing happened with it
[10:53] <ikonia> I saw him join as cloaked,
[10:53] <Myrtti> it just didn't kick in early enough
[10:53] <Myrtti> I didn't
[10:53] <ikonia> 11:27 -!- vibhav [~vibhav___@unaffiliated/vibhav] has joined #ubuntu
[10:53] <Myrtti> [13:27] ~~~vibhav<EMAIL_ADDRESS>has joined #ubuntu
[10:53] <Myrtti> [13:27] ~~~vibhav [~vibhav___@unaffiliated/vibhav] has joined #ubuntu
[10:54] <ikonia> ahhh
[10:54] <ikonia> the "has joined" bit is a bit confusing
[10:55] <Myrtti> same thing happened yesterday before the ban
[10:55] <Myrtti> [18:07] ~~~vibhav<EMAIL_ADDRESS>has joined #ubuntu
[10:55] <Myrtti> [18:07] ~~~vibhav [~vibhav___@unaffiliated/vibhav] has joined #ubuntu
[10:58] <Tm_T> "it's not ban evasion, it's autojoin" is explanation I cant take once, but not twice
[10:59] <Tm_T> and if people knows they're banned, and they leave channel rightaway after noticing they have joined a channel they shouldn't, I have no problem
[11:17] <ikonia> that one again
[11:18] <bazhang> yikes
[11:22] <bazhang> termaster is lars torben?
[11:23] <ikonia> I did wonder that
[11:23] <bazhang> yeppers
[11:23] <ikonia> are you certain ?
[11:23] <bazhang> the false PM accusations
[11:23] <ikonia> well, yes
[11:23] <bazhang> szal is honest, he is not
[11:23] <ikonia> and the isp
[11:23] <bazhang> true
[11:24] <bazhang> safe to unban the gateway I set ? the floodbot banned, and the user was klined (ie goodpoot)
[11:24] <ikonia> yup
[11:24] <bazhang> thanks
[11:26] <Termaster> why leave ?
[11:26] <Termaster> why banned ? ikonia
[11:27] <ikonia> Termaster: did I, or did I not warn you to drop the topic 2 times ?
[11:27] <Termaster> yes so i said, HE should stop that
[11:27] <Termaster> and he went on
[11:27] <ikonia> Termaster: he has not mentioned the pm after I aske dyou to stop it
[11:27] <ikonia> you continued
[11:27] <Termaster> no he wrote:
[11:27] <Termaster> "!ubuntu-es"
[11:27] <ikonia> that is nothing to do with a pm
[11:27] <ikonia> that is advising a user to join the channel #ubuntu-es
[11:28] <Termaster> yes but NOBODY speak espagne
[11:28] <Termaster> at that time
[11:28] <Termaster> or spanish or what
[11:28] <ikonia> 12:23 < Zankajo> #ubuntu-es
[11:28] <ikonia> he was trying to join the channel
[11:28] <ikonia> sazl explained how to join #ubuntu-es
[11:28] <Termaster> yes and that do not belong into the channel
[11:28] <ikonia> yes it did
[11:28] <Termaster> but it is a ubuntu channel
[11:28] <ikonia> Termaster: look - enough now
[11:29] <Termaster> and why is he allowed to tell lies ?
[11:29] <ikonia> he's not
[11:29] <Termaster> he said, i pmed him and faked it
[11:29] <ikonia> Termaster: if he did or not is hard to work out, hence why you where asked, and then told to drop the topic as no harm was done
[11:29] <ikonia> you've persisted in trying to pick a fight with him, you're banned
[11:30] <Termaster> i do not like it to tell lies
[11:30] <ikonia> ok, that's great
[11:30] <Termaster> and i think that is in the law punishable
[11:30] <ikonia> but it doesn't change what I've just said
[11:30] <ikonia> I'm not going through this time wasting process with you
[11:30] <Termaster> okay but why have you to ban me ?
[11:30] <Termaster> you can kick me and give me a second chance
[11:30] <bazhang> Termaster, he just told you.
[11:31] <ikonia> Termaster: because I told you 2 times (they where your chances) to drop it, you kept going, you got banned
[11:31] <Termaster> yes the second time were the kickn
[11:31] <Termaster> i think this channel very often bann
[11:31] <ikonia> that has no bearing on your situation
[11:31] <Termaster> okay and how long banned ?
[11:32] <Termaster> he provocated it
[11:32] <ikonia> Termaster: no - YOU did
[11:32] <Termaster> no
[11:32] <Termaster> i behaved good first
[11:32] <ikonia> you caused the problem, so you are banned
[11:32] <ikonia> come back in a weeks time
[11:33] <Termaster> no i saved the long and i will write to ubuntu team
[11:33] <ikonia> ok
[11:33] <Termaster> and to freenode to, i know the server owner
[11:33] <Tm_Tr> there's no excuse for bad behaviour
[11:33] <ikonia> in the mean time you will remain banned for a week at least
[11:33] <ikonia> Termaster: ok, please write your letter, in the mean time please leave this hcannel
[11:34] <ikonia> ok, I am now very confident that was LARS
[11:34] <bazhang> it was, without question
[11:34] <bazhang> now in +1
[11:35] <ikonia> he's gone
[11:35] <bazhang> whoops he quit
[11:35] <bazhang> * [Tabledancer] (~Tabledanc@p579065D7.dip.t-dialin.net): Tabledancer
[11:35] <ikonia> I'm sure he'll be back
[11:35] <ikonia> ahhh bang on time
[11:43] <jussi> Sir ikonia, may I have the pleasure of you reading and replying to my PM? :D
[11:44] <ikonia> you certainly may
[11:44] <ikonia> had I seen it I would have responded quicker
[11:44] <jussi> :)
[11:49] <bazhang> * [thetwo] (~thetwo@p579065D7.dip.t-dialin.net): thetwo
[11:49] <ikonia> ughhh
[11:50] <bazhang> lets let him speak first
[11:50] <bazhang> whoops
[11:50] <ikonia> nah
[11:50] <ikonia> lets not
[11:51] <thetwo> hello, i think, its unfair that i am banned
[11:51] <ikonia> do you
[11:51] <ikonia> why is that
[11:51] <thetwo> first i behaved very very good
[11:51] <ikonia> ok
[11:51] <thetwo> and then is stupid szal must told me:
[11:51] <thetwo> "!offtopic"
[11:51] <ikonia> thetwo: how about this
[11:51] <ikonia> thetwo: you didn't follow the rules
[11:51] <ikonia> thetwo: you got banned
[11:51] <ikonia> thetwo: you where told not to get in for a week
[11:52] <thetwo> no moment i ask why he is not banned
[11:52] <ikonia> thetwo: so I suggest you leave now,
[11:52] <ikonia> thetwo: he didn't break the rules
[11:52] <ikonia> he followed instructions
[11:52] <thetwo> he did a BIG libel
[11:52] <thetwo> he said things, and faked everything
[11:52] <ikonia> no
[11:52] <thetwo> and cant proove it
[11:52] <ikonia> tell you what, I've got a better idea
[11:52] <thetwo> okay i will go
[11:52] <thetwo> and complain
[11:53] <ikonia> I'm going to end this conversation and submit a complaint to your ISP
[11:53] <ikonia> I have the logs stamped and verified by Freenode, so I'll log a complaint too
[11:53] <thetwo> yes and what will do that ?
[11:53] <thetwo> i did not any illegally
[11:53] <ikonia> I'll let your ISP deal with that
[11:53] <thetwo> yes he will lought
[11:53] <ikonia> thetwo: you right your letter, and I'll right mine, lets end it there
[11:54] <ikonia> I will now complain as they should be able to tie him up with Lars and the original complaint I made
[11:54] <bazhang> kubuntu channel people are ignorant?
[11:54] <ikonia> in what way ?
[11:54] <bazhang> dean just entered saying that ^
[11:59] <ikonia> oh
[11:59] <ikonia> I didn't even see dean in #kubuntu
 some odd targeting of szal here
[12:03] <ikonia> just chance I think
[12:09] <bazhang> same exact issue with compiz, one that even the #compiz experts cannot re-create
 can anyone help me to find any contact info of partnership on ubuntu?
[12:27] <ikonia> ?
[12:27] <ikonia> (sorry not been following)
[12:27] <bazhang> just that, nothing else
[14:14] <jpds> bazhang: http://www.canonical.com/about-canonical/partnerships
[14:14] <Pici> jpds: The person said that no one has gotten back to him a week after asking something to the contact info on that page.
[14:15] <jpds> Is he still around?
[14:15] <jpds> Guess not.
[14:15] <Pici> No
[16:35] <IdleOne> ross` in #u might turn into a problem
[16:35]  * IdleOne steps away for a few
[18:23] <Pici> ikonia: encryption libraries are silly
[18:23] <ikonia> oh ?
[18:32] <Pici> handled.
[18:33] <ikonia> so I see
[18:40] <ikonia> can we setup a new rule, people who say "anyone?"  The ban szal mentioned was #41916
[21:50] <ikonia> I saw you delt with it, so went back to sleep
[21:50] <rww> wfm
[21:50] <ikonia> I also see 41928 and 41915
[23:30] <Corey> I turned +r off.
[23:30] <Corey> One user pasteflooding shouldn't cause that.