[00:09] <poolie> Noldorin_, if you want to get in, change something, and get it landed, that's what i'd recommend
[00:09] <Noldorin_> fair enough
[00:10] <poolie> i will help you (in #launchpad-dev) get it running and do the change
[00:10] <Noldorin_> poolie, was thinking back to that little Downloads type suggestions we discussed :-)
[00:10] <Noldorin_> poolie, ah yes, sorry i forget i'm in #bzr sometimes!
[00:10] <Noldorin_> yeah i'd appreciate that
[00:10] <Noldorin_> perhaps later this week, else after Christmas
[00:19] <Noldorin_> poolie, okay, catch you later :-)
[00:19] <Noldorin_> *heads off to sleep*
[06:01] <meoblast001> hi
[06:02] <meoblast001> i set up a personal directory for each user on my server to maintain personal branches... is it possible to maintain multiple branches this way, or would a new directory have to be made for each branch?
[06:11] <roryy> what's the style guide for splitting operands of + over a line; is it "foo = bar + \\n    quux" or foo = \\n bar + quux" or "foo = (bar + \n quux)" or something else?
[06:13] <poolie> roryy, for patches to bzr?
[06:13] <roryy> poolie: yebo
[06:13] <poolie> any of them is acceptable
[06:13] <roryy> poolie: i mean, yes
[06:13] <poolie> i tend to us ethe second
[06:13] <poolie> what were you going to do?
[06:13] <roryy> erm, i had the first
[06:14] <roryy> i quite like the last, actually, cos emacs understands it
[06:14] <roryy> but i'll use the second :)
[06:18] <poolie> that's also fine
[07:28] <vila> hi all !
[07:54] <poolie> hi there vila, how's it going?
[07:54] <vila> good, how about you ?
[07:55] <poolie> good
[07:55] <poolie> catching up on some reading and trying to write up some stuff about piloting
[08:04] <poolie> jelmer, mgz, hi?
[08:04] <jelmer> hi poolie
[08:05] <poolie> hi there
[08:05]  * jelmer grabs his gear
[08:06] <mgz> morning!
[08:06] <jelmer> yo!
[08:07] <poolie> ready to mumble?
[08:08] <mgz> yup
[08:08] <mgz> nearly awake too :)
[08:09] <poolie> vila, hi?
[08:10] <vila> yup
[08:13] <tsdgeos> hi, is it possible to rewrite the history in bazaar? i did a commit with a wrong merge and i'd like to make as if that commit was never wrong
[08:14]  * tsdgeos finds http://wiki.bazaar.canonical.com/Rewrite
[08:16]  * tsdgeos gets a no revisions to rebase
[08:17] <jelmer> tsdgeos: you can "bzr uncommit"
[08:18] <tsdgeos> unfortunately my wrong merge is not my last commit
[08:18] <tsdgeos> i did a few more before realizing the mistake
[08:18] <tsdgeos> can i uncommit multiple times?
[08:23]  * tsdgeos tries
[08:24] <tsdgeos> ahhh, yes you can
[09:26] <hypnocat> i just tried:   bzr branch lp:ikarus ikarus
[09:26] <hypnocat> and bzr downloaded over 300 MB before i interrupted it
[09:27] <hypnocat> ikarus is a scheme compiler:  https://launchpad.net/ikarus/
[09:28] <hypnocat> the tar.gz snapshot is less than 4 MB, so i don't see how a bzr branch could possibly be downloading over 300 MB of data
[09:29] <hypnocat> something must be wrong..
[09:52] <mgz> hypnocat: have you done `bzr launchpad-login` and set up an ssh key?
[09:52] <hypnocat> nope
[09:54] <mgz> also launchpad has a note on the branch page that it's not been able to access upstream since May
[09:56] <jelmer> hypnocat: perhaps it's got some big files in its history that have since been removed?
[09:57] <hypnocat> strange
[09:57] <mgz> 670776334 Mar 25  2008 3ceaf52ea0e9019a6387927841b360a2.pack
[09:57] <hypnocat> btw, if i interrupt the bzr branch with control-c, where are the temporary files stored?
[09:58] <hypnocat> wow.. 670 MB.. glad i stopped it at around 300
[09:59] <mgz> not all of that is nessersarily referenced history
[09:59] <jelmer> hypnocat: it removes the files if it interrupts
[09:59] <hypnocat> great, thanks
[09:59] <mgz> so, using bzr+ssh to access may well avoid the issue
[10:00] <mgz> otherwise you could grab N revs at a time to see where things start going wrong
[10:01] <jelmer> mgz: I'm not sure there is much to debug, it's just a very large branch
[10:03] <mgz> and pretty dead.
[10:05] <jelmer> it's got some checked in binaries; if those have been updated over time, that would probably explain the size of the branch
[10:19] <mgz> remind me to build py3k over lunch
[10:37] <mgz> roryy is a hero, I see why he was having problems with test_dirstate
[13:09] <caravel> hello all, I've read again about shared repos and stacked branches, not sure what I should go for -- could you please advise ? :
[13:09] <caravel> the idea is to have one trunk and some "contrib" branch that would be ideally stacked (?)
[13:10] <fullermd_> I'd just ignore stacked branches.
[13:10] <caravel> oh :)
[13:11] <caravel> the idea is that teamA would work on trunk, while teamB would punctually post suggestions on contrib
[13:11] <fullermd_> Using a repo shared between the two branches will save you disk space and IO.  It won't [shouldn't] make any difference semantically to having the two branches standalone.
[13:11] <fullermd_> (this assuming of course that the branches get merged a lot.  If they actually just diverge, you don't save much)
[13:12] <caravel> they'd get merged all the time
[13:14] <caravel> there's one thing I don't quite get : say I setup such shared repo on some bzr+ssh space, with 2 branches in it (trunk and contrib). Then on each local PC we should also setup a shared repo, and bzr branch/push each (trunk and contrib), right ?
[13:16] <fullermd_> That's a setup.  Bear in mind that everythin'gs independent; you can have the two branches sharing a repo on the server, but standalone on the clients, or vice versa, or any combination.
[13:16] <fullermd_> Aside from creating the repo in the first place, you only ever interact at the branch level; using/not a shared repo happens internally.
[13:20] <fullermd_> And you can take two standalone branches and switch them (in-place) to sharing a repo.  And vice versa.  So, don't overthink yourself into paralysis on that question.
[13:22] <caravel> fullermd_: yes, I see, still it's a little paralising :)
[13:24] <caravel> One of ours teamA members would update his respective trunk and contrib from srv, merge and commit to local trunk, then push to srv trunk. As per pulling trunck changes into contrib, should that be done server side typically ?
[13:26] <caravel> (or should that be typically teamB members duty, to pull new changes from trunk and merge them into contrib in a manual manner ?)
[13:27] <caravel> (teamB is supposed to oversee teamA and eventually fix/contribute)
[13:28] <caravel> (but NOT commit to trunk)
[14:06] <caravel> fullermd_: sorry to buzz you, I missed to quote you in my replies - could you please confirm ?
[14:17] <vila> jelmer: can you remind me of the plan for 'bzr branches' in bzr core vs the one in bzrtools ?
[14:18] <vila> jelmer: I had a test failing and was quite surprised that the culprit was bzrtools (related to colo)
[14:18] <jelmer> vila: IIRC the plan is to have the one in bzrtools removed at some point
[14:18] <vila> good
[14:20] <mgz> speaking of bzrtools, I've got a bug fix that needs review, bugging abentley is the way forward?
[14:34] <jelmer> mgz: yep
[16:16] <mgz> has anyone done coverage stuff to go with selftest?
[16:18] <vila> mgz: not really, there is a bzr option that can be used
[16:18] <vila> mgz: I've used it here and there but never for the whole test suite
[16:18] <mgz> I'm reasonably sure the code roryy's bug fix in isn't exercised at all by bt.test_dirstate
[16:19] <vila> --coverage=DIRNAME
[16:22] <mgz> oddly using '=' there breaks, need space
[16:22] <mgz> otherwise looks promising, thanks vila
[16:22] <vila> crap, copied it from 'bzr help selftest'
[16:24] <mgz> global option parsing is a bit of a mixed bag :)
[16:26] <vila> ;)
[16:28] <mgz> looks good... is there a basic description of the output format anywhere?
[16:28] <vila> dunno, from memory, each line is prefixed with the number of executions
[16:29] <mgz> and the >>>>>> markers?
[16:29] <mgz> dead code?
[16:29] <mgz> *uncovered
[16:29] <vila> yes, as far as I remember, not sure if it's this marker or no marker at all
[16:35] <caravel> side question : would anyone know how to get the fancy tortoisebzr icons working correctly on a virtualbox drive (xp guest) ?
[16:38] <mgz> okay, this is pretty neat.
[16:41] <mgz> forgot how useful this was for informing testing.
[18:48] <kees> hola. I'm curious why I can't create a branch-for-merging of lp:ubuntu-security-tools. I tried pushing as lp:~kees/ubuntu-security-tools/update and it fails.
[18:51] <jelmer> kees: hi
[18:51] <jelmer> kees: how does it fail?
[19:04] <caravel> would anyone know how to get the fancy tortoisebzr icons working correctly on a virtualbox drive (xp guest) ?
[19:06] <caravel> (i.e. it would work from c: drive, but it doesn't for eg d: vbox share)
[19:06] <mgz> caravel: you might be best posting to the list about it, or just filing a bug. the main tortoisebzr guys are japanese and not on irc
[19:08] <caravel> mgz: ok, thanks for your answer anyway
[19:09] <mgz> I don't see any reason apart from a packaging bug or something weirder that they wouldn't appear on a different drive
[19:11] <caravel> mgz: such share is seen by the OS as some kind of a network drive -- do these icons work fine with a "local" repo located in a standard samba share ? I guess nobody uses such a setup (apart from a vbox share, maybe), hence why
[19:11] <caravel> (no samba to test here)
[19:14] <caravel> they probably restricted the feature to true "local" drives (as seen by the OS). Same limitations happens for eg. ActivePerl install (localisation fails), or OCX registration (refused) etc
[19:17] <mgz> may even be deliberate, if it would be bad perf over network drives... could also be easy enough to override locally, if you know the right magic
[19:17] <caravel> mgz: right -- that's my guess indeed. Unfortunately (for me) some network shares should not suffer since they have perf "very close to local" !
[19:18] <caravel> As per the magic, I've seeeeearched for it quite a few times, hence my question here :) Any suggestion welcome
[19:19] <caravel> (I really really can't afford to stick these data within the vdi here, hence I'll have to do without icons ^^)
[19:20]  * caravel is going away for a little while
[19:23] <mgz> will branch lp:tortoisebzr and have a quick grep for you
[19:28] <mgz> looks like you may be able to set the config option 'icon_overlays.include_path', see also doc/preferences.txt and tbzr.conf under your bzr home directory
[19:30] <mgz> 'context_menu.include_path', 'queried_drives.remote', and 'queried_drives_cmenu.remote' may also be of interest to you
[19:40] <kees> jelmer: bzr: ERROR: Permission denied: "~kees/ubuntu-security-tools/updates/": : You cannot create branches in "~kees/ubuntu-security-tools"
[19:44] <wgz> kees: you (hilariously) appear not to be a member of ~ubuntu-security
[19:45] <wgz> why that should prevent you creating a branch in your own namespace I know not, but it feels more like a launchpad... security... feature than a bzr bug
[19:46] <kees> wgz: right, I'm not in that group any more, but it's still ~ME/PROJECT/NAME ... why would that not work?
[19:46] <kees> wgz: and it's a public branch...
[19:48] <jelmer> kees: something is tripping up the logic in Launchpad for branch mapping
[19:49] <jelmer> kees: it'll error out with PermissionDenied if you try to push to something that it does not consider a branch
[19:49] <jelmer> it's not necessarily actually related to permissions
[19:51] <jelmer> kees: I can reproduce it
[19:51] <jelmer> bzr: ERROR: Permission denied: "~jelmer/ubuntu-security-tools/update/": : You cannot create branches in "~jelmer/ubuntu-security-tools"
[19:51] <kees> well, at least I'm not crazy. ;)
[19:52] <james_w> is there a branch privacy policy in place on that project?
[19:54] <kees> I don't think so. There was a private branch at one time, but that was a separate, iiuc.
[19:54] <kees> jelmer, james_w: jdstrand has access to look at the project settings. is there anything he should look at?
[19:55] <jdstrand> I may need some hand-holding
[19:57] <james_w> I'm not sure where to look to find out unfortunately
[19:57] <kees> jdstrand: there was a private branch once on that project, can you see if there are any weird settings hidden in there?
[19:58] <jdstrand> kees: sure, where would I look for them?
[19:59]  * jdstrand still has security-tools-private.abandoned laying around
[19:59] <kees> jdstrand: I'm not really sure; I don't have the buttons any more. check https://launchpad.net/ubuntu-security-tools and see what admin toggles there?
[19:59] <kees> s/there/there are/
[20:00] <james_w> webops ping, would you look at the branch security policy on https://launchpad.net/ubuntu-security-tools for us please?
[20:00] <kees> and then check https://code.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk for stuff? I'm really not sure.
[20:00] <kees> jdstrand: if nothing jumps out, don't worry about it. :P
[20:00] <jdstrand> nothing interesting in ubuntu-security-tools/+edit
[20:00] <thedac> james_w: sure
[20:00]  * thedac waves at kees
[20:00] <kees> heya thedac! :)
[20:01] <kees> thedac: we missed you at the quilting. :)
[20:01] <thedac> good to see you. Yeah, I am the only one in my tz
[20:01] <kees> true, true.
[20:01] <jdstrand> kees: poking around I don't see anything...
[20:02] <thedac> james_w: default is forbidden and private for the ubuntu security team
[20:02] <thedac> what am I looking for in https://code.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk?
[20:03] <thedac> oh, maybe that wasn't for me
[20:03] <james_w> jdstrand, kees: do you want it changed to be a fully public project now?
[20:03] <kees> thedac: sorry, yeah, confusing. that was for jdstrand
[20:03] <jdstrand> ~ubuntu-security/ubuntu-security-tools/trunk/+edit tells me the 'Keep branch confidential' is unchecked
[20:03] <kees> lp:~ubuntu-security/ubuntu-security-tools/private-trunk should probably stay private
[20:04] <jdstrand> I don't know what that is...
[20:04] <kees> it's ancient and abandoned
[20:04] <jdstrand> kees: was that the saved old one?
[20:04] <kees> yeah
[20:04] <kees> if it's breaking u-s-t maybe we should eliminate it?
[20:04] <jdstrand> I'm cool with deleting it if needed
[20:04] <jdstrand> like I said, I have a local branch of that. I can push it somewhere I guess
[20:04] <thedac> kees: jdstrand let me know if I need to change privacy settings on any of these branches
[20:05] <james_w> so it sounds like you want the defaults changing, but keeping that one branch private?
[20:05] <kees> thedac: the problem seems to be that while ~ubuntu-security/ubuntu-security-tools/trunk is public, I can't create branches of it.
[20:05] <kees> james_w: if possible, yeah
[20:06] <jdstrand> that would work for me as well
[20:06] <james_w> thedac, do you know if changing the policy will change existing branches?
[20:06] <thedac> james_w: it will not.
[20:06] <jdstrand> ubuntu-security-tools/private-trunk/+edit is marked 'Keep branch confidential'
[20:06] <james_w> thedac, ok, so it sounds like we'd like the default changed please
[20:07] <james_w> thedac, public for everyone, no-one forbidden
[20:07] <thedac> james_w: ok, I will change that
[20:08] <james_w> thedac, probably also worth checking the bug policy as well?
[20:08] <jdstrand> it isn't setup for bugs yet, if that makes a difference
[20:09] <thedac> ok, default branch visibility is fully public now
[20:09] <thedac> checking on default bug setting
[20:09] <james_w> jdstrand, ah, ok
[20:09]  * jdstrand confirms private-trunk is still private, and it is
[20:09] <thedac> jdstrand: bug default is public
[20:10] <jdstrand> cool
[20:10] <thedac> I have also confirmed that ~ubuntu-security/ubuntu-security-tools/trunk is public. So if that is still not working for kees I can see if there is an LP dev around to question
[20:10] <james_w> kees, you should be able to push now?
[20:10] <jdstrand> (that is what I would have expected if I/we set that up in the future)
[20:10] <kees> james_w: let me check, one moment...
[20:12] <kees> \o/
[20:12] <kees> thanks everyone! :)
[20:13] <james_w> thanks thedac
[20:13] <kees> jdstrand: and if you have a moment, can you merge my 1 character test-change? ;)
[20:13] <jdstrand> kees: sure
[20:13] <thedac> james_w: kees: great.
[20:18] <jdstrand> kees: done
[20:23] <kees> jdstrand: sweet
[20:23] <kees> alrighty, thanks again folks.
[21:10] <caravel> mgz thanks ! ...if you ever read this irc log ^^
[21:10] <caravel> night all
[21:10] <wgz> it worked?
[21:11] <caravel> nothing worked, just read your comments :) took note, will try somthing tomorrow
[21:11] <wgz> cool.
[21:14] <caravel> yes, you see, no solution but just looking into my little issue, did deserve my thanks :) night
[22:09] <poolie> hi all
[22:36] <Noldorin_> hi poolie
[22:36] <Noldorin_> how's it going?
[23:03] <wgz> I'm going to merge roryy's branch unless anyone else wants to look over it quickly
[23:06] <jelmer> 'morning poolie, Noldorin_
[23:06] <jelmer> wgz: go for it
[23:08] <poolie> hi there
[23:08] <poolie> it's pretty good
[23:13] <Noldorin_> hi jelmer
[23:13] <Noldorin_> jelmer, i thought you were Dutch? ;-)
[23:13] <Noldorin_> it's not morning there heh
[23:13] <poolie> where are you, Noldorin_, north america?
[23:14] <Noldorin_> nay
[23:14] <Noldorin_> England.
[23:15] <Noldorin_> poolie, USA yourself?
[23:18] <poolie> Sydney
[23:19] <Noldorin_> oh right
[23:19] <Noldorin_> poolie, sorry. i knew it was somewhere English-speaking and not my time-zone, that's all!
[23:21] <Noldorin_> jelmer, i think you're taunting me with all the updates except on my most desperate one ;-)
[23:21] <Noldorin_> all the bug updates*
[23:44] <jelmer> Noldorin_: heh
[23:45] <jelmer> Noldorin_: there are plenty of other bug reports apart from yours that I haven't touched yet either.. :)
[23:45] <Noldorin_> jelmer, i know, i kid :-) it's just the ones i receive email notifications for heh...
[23:49]  * wgz subscribes Noldorin to ~jelmer
[23:49] <wgz> you will drown in email!
[23:50] <Noldorin_> heh
[23:51] <BlindWolf8> Hi all. I have a clien who is getting this error:
[23:52] <BlindWolf8> bzr: ERROR: Permission denied: "<OUR_DIR>/.bzr/checkout/lock/held/info": [Errno 13] Permission denied
[23:52] <BlindWolf8> I am not sure how to solve this
[23:52] <BlindWolf8> He is on a Windows box
[23:53] <wgz> BlindWolf8: get the full traceback from .bzr.log (run `bzr version` to find out where)
[23:53] <wgz> it will also have other things we need like what version he's running and if bzr-explorer etc are involved
[23:54] <Noldorin_> poolie, btw, do i have any other option for testing Launchpad other than my own Ubuntu VM?
[23:54] <wgz> Noldorin: that'll just be way the easiest option
[23:54] <BlindWolf8> Thanks. Once I have the log file, where would you like it?
[23:54] <wgz> poolie was trying to save you pain by suggesting that
[23:54] <wgz> !pastebin
[23:55] <Noldorin_> wgz, i'm annoyingly using an SSD drive with no space left on it
[23:55] <Noldorin_> :-(
[23:55] <wgz> heh, you won't be able to get launchpad either then, it's not small :)
[23:56] <Noldorin_> bugger
[23:56] <Noldorin_> wgz, someone just give me access to a VPS with it on heh? :-)
[23:56] <wgz> Noldorin: I can suggest you bugs to work on if you're eager, you tend to find things that are way to hard
[23:56] <Noldorin_> heh
[23:57] <Noldorin_> wgz, i discussed a simple one with poolie not long ago. adding additional content types to downloads :-)
[23:57] <Noldorin_> wgz, but sure, feel free to... once i have an instance set up heh
[23:58] <wgz> bzr is nice and easy to work on :-"
[23:59] <Noldorin_> wgz, oh sorry, i read it as launchpad :-P
[23:59] <Noldorin_> i always blend them into one heh
[23:59] <Noldorin_> i suppose it's because i use both together so frequently...
[23:59] <BlindWolf8> Here ya go: http://paste.ubuntu.com/776942/