[00:50] <poolie> hi all
[00:51] <wgz> ack, I need to be in bed if I'm gonna make tomorrow morning
[00:51] <poolie> sleep well :)
[00:52] <wgz> night!
[05:51] <poolie> lifeless, did you see http://giovanni.bajo.it/2011/09/golomb-coded-sets/
[06:15] <lifeless> poolie: interesting!
[06:22] <poolie> it's a very elegant series of steps
[06:27] <lifeless> indeed
[06:28] <poolie> i'd like to have a chat with you some time this week
[06:29] <AuroraBorealis> https://bugs.launchpad.net/bzr/+bug/847388 i believe this bug is 'solved', but i dunno how to confirm it (that it works on windows/mac)
[06:30] <poolie> AuroraBorealis, solved how?
[06:30] <poolie> we pass the option, or we give it a tty, or  gpg stopped complaining?
[06:30] <AuroraBorealis> my 'change' in that branch is literally just adding --no-tty to the gpg arguments
[06:30] <lifeless> poolie: sure, that would be great. At 1730 my time we start operation cynthia-has-to-go-to-bed, but other than that I'm free whenever my google calendar thinks I'm free
[06:31] <poolie> oh you're mark?
[06:31] <AuroraBorealis> that makes it so it WORKs on ubuntu (which was the only OS that had problems), and it still works as intended on mac/windows
[06:31] <AuroraBorealis> yeah. i should probably use that name here xD
[06:31] <poolie> if you want to only land it on trunk i think you can just put it in
[06:31] <poolie> if it's intended for 2.5 we have to be quite careful
[06:32] <AuroraBorealis> i dunno how to 'put it in' or if its indended for 2.5
[06:33] <AuroraBorealis> it pretty much makes bazaar explorer unusable if you are signing commits (since you can't commit with it)
[06:36] <poolie> so you're prettysure that has no (harmful) effect on windows?
[06:36] <poolie> i don't expect it would
[06:36] <AuroraBorealis> i tried it
[06:36] <poolie> oh, great
[06:37] <AuroraBorealis> i just downloaded my branch and ran the bzr python file, tried creating a repo and commiting with the signing
[06:37] <poolie> ok so you should just click 'propose for merging' on https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix
[06:38] <poolie> and choose lp:bzr/2.5 as the target
[06:38] <AuroraBorealis> i mean i 'hope' it worked, it commited and didnt say any errors, i dont think there is a way yet to actualy verify the signatures =P
[06:39] <AuroraBorealis> ~bzr-pqm/bzr/2.5 that it?
[06:39] <poolie> that's it
[06:39] <poolie> yes, http://doc.bazaar.canonical.com/beta/en/user-reference/verify-signatures-help.html
[06:40] <AuroraBorealis> hmm needs some weird package installed on windows
[06:41] <AuroraBorealis> i'll try it later
[06:41] <poolie> ok
[06:41] <poolie> i would be reluctant to put it in after the last beta unless it was well tested across platforms
[06:41] <poolie> really only windows is a concern though
[06:41] <poolie> mm
[06:44] <poolie> lifeless, ok, 12nz tomorrow?
[06:44] <lifeless> sure
[07:39] <mgz> morning all!
[07:41] <vila> morning mgz et al.
[07:42] <poolie> hi mgz, hi vila
[07:42] <poolie> mgz i replied on https://bugs.launchpad.net/bzr/+bug/851834
[07:43] <mgz> poolie: thanks
[07:55] <poolie> i'm not sure it will help but that's what i'd try next
[07:57] <wgz> is the kind of thing I was after
[08:02] <poolie> wgz,  then you can open the pcap file in wireshark
[08:02] <poolie> with which jelmer is an expert
[08:03] <wgz> the use of jelmer is also something I'm in favour of
[08:06] <jelmer> *ahem* :)
[09:17] <vila> jelmer: so, re-reading http://docs.python.org/library/ssl.html?highlight=cert_optional#ssl.CERT_OPTIONAL
[09:17] <vila> jelmer: certificates will be required from the other side, i.e. required from the server by the client
[09:17] <vila> jelmer: that's about the server certificate not about the client root certificates
[09:18] <jelmer> vila: ah, ok
[09:18] <jelmer> vila: so I guess we'll need a new option after all
[09:19] <vila> well, a new value for the option will do in the interim
[09:19] <vila> what I want to avoid is people setting it in their config file and don't use the default when we change it
[09:19] <vila> s/I want/I'd like/ ;)
[09:34] <mgz> something as dumb as ssl.cert_reqs default being 'none' on win and osx and 'required' otherwise would be okay for now
[09:56] <farblue> morning everyone :) We are evaluating switching from svn to an alternative vcs and can't find any info on whether bzr has support for something similar to svn's --record-only as a way to prevent a commit being merged down from branch to trunk
[09:58] <Peng> What's --record-only?
[09:58] <farblue> it is used during a merge to mark the merge as having been done but without actually applying the patch
[09:59] <farblue> for instance, we have a release branch and trunk and we might have made a change on the release branch we don't want in trunk (a bug that's been fixed as part of larger changes in trunk but then patched in the release branch quickly to prevent problems)
[09:59] <farblue> we want to merge the release branch back to trunk to prevent regressions but we don't want that particular commit to be merged back
[10:00] <Peng> You can bzr merge it and then do "bzr revert ." -- note the period -- to throw out the physical changes but leave the merge metadata.
[10:00] <poolie> thanks Peng
[10:00] <poolie> night all
[10:01] <farblue> ok, that's a reasonable option
[10:01] <farblue> a little less intuitive than the --record-only svn option but at least there is a way :)
[10:02] <farblue> any other ideas? any plugins that might help?
[10:02] <farblue> Just gathering support for bzr over other options you see :) Need to put forward a good case :)
[10:09] <poolie> farblue, that's how it's done at the moment
[10:09] <poolie> mm
[10:09] <vila> mgz: works for me, will file a mp doing that
[10:09] <poolie> you could fairly easily patch bzr to add a --record-only if you want
[10:09] <farblue> good point :)
[10:10] <farblue> I see the alternative way to do it might be to add a metadata tag of some sort to the commit so that when anyone tries to merge it it just updates the merge tracking and doesn't apply the patch
[10:11] <farblue> anyhow, thanks :D
[10:39] <LarstiQ> vila: do you have any numbers for how much an improvement the config caching is?
[10:40] <vila> LarstiQ: I will have them shortly for the whole test suite but you can look at the impact on the hpss calls in the revision I recently landed
[10:40] <vila> ghaa, unity 2D has some rough edges :-/
[10:41] <mgz> sharp edges, being a planar surface I'd expect.
[10:42] <vila> hehe
[10:42] <LarstiQ> vila: ah right. About 1 to 2 less hpss calls in 10 places
[10:43] <vila> LarstiQ: roughly the actual implementation does: to get an option value: read/parse the config file[s] where the option can be defined, to set an option: read/write the config file
[10:44] <LarstiQ> mgz: ah hmm, but the regularity of the edge might be pretty bad
[10:44] <LarstiQ> vila: and within a lock it will only read once?
[10:45] <vila> LarstiQ: the new implementation will read each file once and cache its content, modifications are cached and flushed when the lock is released, read the file (for concurrent updates), write it
[10:45] <vila> LarstiQ: almost yes
[10:45] <vila> LarstiQ: that is, without modifications, it's read only once
[10:46] <vila> LarstiQ: if there is at least one modification, it needs to be read again (to protect potential modifications made by other processes) and write once
[10:46] <LarstiQ> vila: right.  So then we'd expect more benefit on longer lived operations
[10:46]  * LarstiQ nods
[10:47] <vila> LarstiQ: the main target is to allow reading once for all options (the fallouts are in the tricky update process that requires a lock)
[10:47] <LarstiQ> aye
[10:49] <vila> hmm, in fact the unity 2D model when switching wrokspaces is in some way *better* than the 3D one: all desktop are presented with all windows 'exposed' so when you switch to a different workspace you can directly select the windows you're interested in
[10:49] <vila> it's worse if the windows you're interested in is already visible of course...
[10:50] <vila> mgz, jelmer: https://code.launchpad.net/~vila/bzr/929179-default-ssl-certs/+merge/93177 is up for review
[10:50] <vila> mgz: may be you should include that for the 2.5b6 windows installers and get them out of the door :)
[10:51] <vila> mgz: also see bug #932647 for more info I gathered on the windows native calls
[11:07] <farblue> hi again :)
[11:08] <farblue> a quick question about revision numbers - I understand the incrementing number and the . separated numbers for branches
[11:08] <farblue> but are these global for the repo or are they specific to my copy of the repo?
[11:09] <farblue> e.g. if i refer to revision 1234 will it be the same revision as rev 1234 on a colleague's machine?
[11:10] <quicksilver> if they're looking at the same branch
[11:10] <quicksilver> then they'll have the same numbers.
[11:10] <farblue> I'm assuming 'trunk' here as there are no dots in the number
[11:10] <quicksilver> if you like revision numbers (we do!) then you will want to make sure you don't "push" onto one of your main trees
[11:10] <quicksilver> ...from a different branch
[11:11] <quicksilver> pushing from a different branch can pivot the revision numbers.
[11:11] <quicksilver> instead, merge + commit into the branch and keep your revnos monotonic.
[11:11] <farblue> so you mean we should merge our work onto the 'trunk' and then push trunk?
[11:11] <quicksilver> if you are working on separate branches, yes.
[11:11] <quicksilver> if you are just working directly on trunk it doesn't matter.
[11:12] <farblue> ok
[11:12] <quicksilver> if you *are* working directly on trunk then I recommend a 'bound branch'
[11:12] <quicksilver> that makes it harder to get it wrong.
[11:12] <quicksilver> (all your commits go upstream immediately and it complains if you're out of date)
[11:13] <quicksilver> (1) small fixes directly on trunk, use a bound branch (2) feature development in separate branches, eventually merged into trunk
[11:13] <quicksilver> is the workflow we use.
[11:13] <LarstiQ> farblue: you can also set the `append_only` option on trunk
[11:13] <farblue> Currently we use SVN and are looking at alternatives as part of evaluating whether SVN still does what we need. From what I understand so far, we can have bound trunk and bound branches just like svn's way of doing things then we can start to make use of local, unbound branches for local work
[11:14] <farblue> append_only means it won't re-shuffle the revisions, I gather
[11:14]  * LarstiQ nods
[11:14] <quicksilver> yes although nothing to stop you also periodically publishing those "local" branches to a central server for mutual code review etc.
[11:14] <quicksilver> (under a different name from trunk, clearly!)
[11:15] <quicksilver> LarstiQ: thanks, I didn't know about that one.
[11:15] <farblue> cool :)
[11:15] <LarstiQ> `append_revisions_only` is the correct name according to `bzr help configuration`
[11:17] <farblue> We refer to revision numbers quite a lot in tickets, in redmine etc. and changing those to manual tags or long sha1 hashes doesn't appeal :)
[11:18] <quicksilver> agree farblue
[11:18] <quicksilver> so do we
[11:18] <quicksilver> also redmine^Wchiliproject's repo viewer gets confused if revision numbers change.
[11:19] <quicksilver> LarstiQ: will it also forbid the occasionally bzr push --overwrite where we really *do* need to change history?
[11:20] <LarstiQ> quicksilver: yes
[11:20] <mgz> yes, but you can flip the config, push, and flip it back
[11:20] <quicksilver> nod
[11:20] <quicksilver> thanks
[12:08] <jelmer> vila: did your RangeFile.read patch land?
[12:09] <vila> I think so
[12:09] <vila> jelmer: found another case where it's not enough ?
[12:10] <jelmer> vila: yeah
[12:11] <vila> :-/
[12:11] <jelmer> I guess you've only fixed it for the size=-1 case?
[12:11] <vila> details ?
[12:11] <vila> well, I was testing with an import that used size=16384 or something, may be I didn't run it against the last version
[12:12] <jelmer> I'm calling read(1024) on a RangeFile returned by HttpTransport_urllib.get()
[12:12] <vila> and ?
[12:12] <vila> I mean, how does it fail ?
[12:12] <jelmer> bzr: ERROR: Invalid range access in http://xwax.org/devel/xwax.git/objects/21/6e47cb4d38615f2e3cb306912fc495e0bdc713 at 2: Can't read 1024 bytes across range (0, 157)
[12:12]  * vila blinks
[12:13] <vila> the error is supposed to be raised by a different code path
[12:13] <vila> so either you're not using the right bzrlib or ... something is broken in the whole file detection (which seems weird since it's based on the 200 error code...)
[12:14] <jelmer> ah, yeah
[12:14] <jelmer> vila: sorry, pebkac
[12:14] <jelmer> I'm indeed using an older bzr version
[12:15] <vila> no worries, better safe than sorry
[12:16]  * vila re-runs his test for good measure, blaming unity 2D for making it harder to work with multiple workspaces ;)
[12:23] <farblue> Can anyone tell me whether bar has support or a plugin to support token locking or binary (unmergable) content? Subversion has locks, for instance.
[12:23] <farblue> bzr* (autocorrect fail)
[12:24] <farblue> to help prevent 2 people working on a binary asset at the same time
[12:29] <wgz> https://lists.ubuntu.com/archives/bazaar/2008q4/050125.html
[12:29] <wgz> https://lists.ubuntu.com/archives/bazaar/2010q1/067494.html
[12:32] <farblue> interesting
[12:33] <farblue> does it work? anyone using it?
[12:53] <Riddell> congratulations jelmer
[12:56] <jelmer> Riddell: thanks, what for ? :)
[12:57] <Riddell> jelmer: the canonical spotlight award!
[13:00] <mgz> hey, there's a prize and everything. go jelmer.
[13:01] <jml> +1
[13:01] <jelmer> wow, thanks! :) I hadn't seen the email yet
[13:30] <GRiD> congrats jelmer
[15:18] <vila> cong... ha, I'm late, anyway, just saw it, congrats jelmer ;)
[15:20]  * quicksilver doesn't know what that is, but congrats jelmer anyway :)
[15:21] <vila> quicksilver:hehe, sry, he got some company internal award for being our... dude ;)
[15:22] <quicksilver> jelmer++ # dude
[15:23] <jelmer> heh, thanks vila, quicksilver :)
[15:50] <mgz> I think we ought to make congratulate jelmer day a regular thing
[15:50] <mgz> makes a nice change from why haven't fixed my pet bug yet jelmer days
[15:51] <vila> mgz: +1
[16:30] <vila> jelmer: looks like my review got lost on https://code.launchpad.net/~jelmer/bzr/2a-repo-supports-nested-trees/+merge/89919, dunno what happened, just re-did it
[16:36] <jelmer> vila: merci bien !
[16:45] <farblue> hi all :)
[16:47] <farblue> does anyone have experience of dealing with 'vendor branches' in bzr?
[16:48] <vila> farblue: we are GPL hackers, we don't sell anything, all branches are free ;)
[16:48] <farblue> lol
[16:49] <vila> farblue: joke aside, all branches are equal except when social conventions apply
[16:49] <vila> so a 'vendor branch' is just a branch and how you interact with it depends on your workflow
[16:49] <farblue> ok, let me rephrase: dealing with developing on top of a third-party source code for which you only see the release versions
[16:50] <vila> you can maintain a vendor branch with its own set of changes and still merge regularly from trunk
[16:50] <vila> oh, you mean the release versions are not under version control at all and you get only tarballs ?
[16:51] <farblue> yep
[16:51] <farblue> currently we spend ages in svn applying the new source over the top of our 'vendor branch'
[16:51] <farblue> and it's a pain
[16:51] <farblue> of course, once done we can merge the changes into trunk and all is rather easier
[16:52] <farblue> but that initial application of the new source dump over the top of our 'vendor branch' is a real pain
[16:52] <vila> yup, the crucial point is to track the releases in a bzr branch that share history with *your* stuff
[16:52] <farblue> anyone got experience of how well bzr handles this?
[16:53] <farblue> yeah, I mean once we've updated the vendor branch in svn things do work well enough but that initial application of the new vendor code release to the vendor branch working copy is horrible
[16:53] <farblue> just wondering whether life would be easier when using bzr
[16:53] <vila> pretty well as long as you can avoid your 'parallel import' nemesis
[16:53] <farblue> parallel import?
[16:54] <vila> bzr tracks renames by assigning a file-id when a file is first added
[16:55] <vila> there is a catch: if the same file is added independently, it gets a different file-id (it is imported in parallel)
[16:55] <farblue> right
[16:56] <farblue> so, like with svn, if a file is renamed we need to go hunting for it and tell bzr that, in fact, this new file isn't new but a rename (i.e. apply the rename first to the old file before then replacing it with the updated version)
[16:56] <vila> if you already have a branch with your stuff, create a new branch from that, untar the upstream source, commit
[16:57] <farblue> won't that then mark the incoming changes from upstream as 'newer' than our changes?
[16:57] <vila> well, ideally you start from the upstream source and create a branch for your stuff avoiding the issue, the trick above is for catching up
[16:58] <vila> 'newer' depends on when you merge this upstream branch into your trunk
[16:58] <vila> if you maintain the upstream branch separately and always untar there, things will become clearer in the long term
[16:59] <vila> farblue: the best way to understand is to try and look at the result with 'bzr qlog trunk upstream' to see how the branches are related,  when they merge each other, etc
[17:00] <farblue> in svn we have a branch for the upstream and then that is merged to trunk. We then develop on trunk (well, feature branches but whatever), making our changes as needed. We do our releases as you usually would etc. For a new upstream release we update the vendor branch to the latest version and then merge this set of updates into trunk, resolving the few conflicts we might have.
[17:00] <farblue> does this basically sound the same as how you'd do it in bzr?
[17:00] <vila> yup
[17:01] <farblue> fine, ok :) For us it is step one - "updating the vendor branch to the latest version" that is the painful bit :(
[17:01] <vila> the caveat is about *starting* the upstream branch
[17:01] <vila> really ?
[17:02] <farblue> well, the projects we are basing our code on tend to get refactored quite often and not released frequently so we have very large differences between upstream releases
[17:02] <vila> ha
[17:02] <farblue> a real pain actually
[17:03] <vila> well, it's hard to get VCS benefits if upstream doesn't use VCS...
[17:03] <farblue> hmm
[17:03] <vila> are you sure you can't access their VCS repo ?
[17:03] <farblue> well, for Roundcube we are considering it but they've also got better at releasing more frequently
[17:04] <farblue> for other projects there is no public vas available
[17:04] <vila> java code ?
[17:04] <farblue> php
[17:05] <vila> the only tricky part should be renames, unless you're talking about changes to code that is moved from one file to another
[17:05] <vila> file/dir renames I mean
[17:06] <farblue> well the worst situation for svn is where a file we have modified is renamed / moved in the upstream project
[17:06] <LarstiQ> farblue: unpack into vendor branch, and then some combination of bzr add/bzr mv --auto/after?
[17:07] <farblue> what's the --auto/after stuff?
[17:07] <vila> guess the renames :)
[17:07] <LarstiQ> farblue: I'd need to try out the workflow, but I think `unpack; bzr mv --auto; bzr add`
[17:08] <farblue> guess the renames? cool :) Even if there has been a percentage of the source changed within the renamed file?
[17:08] <vila> farblue: or more precisely: guess the renames based on the content
[17:08] <LarstiQ> farblue: `bzr help mv`  doesn't elaborate too much, but --auto tries to guess renames
[17:08] <vila> farblue: yup
[17:08] <farblue> very useful :)
[17:08] <vila> that could fail if the changes are too broad of course
[17:09] <farblue> in many cases it's just a case of a folder having been renamed or similar but svn still hates this
[17:09] <vila> but you can focus on those after most of the trivial ones have been handled
[17:09] <farblue> yes, the ability to attempt to guess at renames is very useful
[17:09] <vila> I'm not sure --auto handle dir renames but bzr will track them happily
[17:10] <farblue> sounding good :)
[17:11] <vila> basically, if you don't have the VCS history, you have to provide the minimal missing bits
[17:11] <farblue> yeah
[17:12] <farblue> now I originally considered whether stacked branches would work in this situation and I'm interested to understand why this hasn't been suggested :)
[17:12] <vila> stacking is for repos more than for branches, avoid ti if you can ;)
[17:13] <farblue> ok
[17:13] <vila> s/ti/it/
[17:13] <farblue> sounds like the advice I give to people enquiring about svn:externals :)
[17:13] <GrueMaster> Hey.  Semi-noob question.  I have a tree that I maintain on launchpad, and a merge request.  The proposed merge was created by a user that used the source tarball (sans .bzr) and checked into a new tree with changes.  What is the easiest way to merge his changes.  My tree has diverged a little with other changes, but I think I can revert back to a common ancestor.
[17:14] <vila> well, stacking repos was originally designed to handle access rights, where the feature branches are not allowed to add their revisions to the trunk repo (used by the trunk branch)
[17:14] <vila> GrueMaster: url for the mp ?
[17:14] <farblue> vila: yeah, I read that and wondered whether that could apply to a readonly upstream project
[17:15] <GrueMaster> https://code.launchpad.net/~skydiver38/win32-image-writer/md5/+merge/88565
[17:16] <vila> farblue: have a look at what a 'parallel import' can cause :-/
[17:16] <GrueMaster> I also have a local copy of his branch.  I do most of my work in Linux.
[17:16] <vila> GrueMaster: simpler answer: ask the submitter to start from your branch
[17:17] <GrueMaster> I've suggested that a few times now.  Apparently Windows devs don't work well with cmdline tools.  :P
[17:17] <vila> GrueMaster: oh, we have a GUI for them :)
[17:18] <GrueMaster> I know, I have it on my VM of XP.
[17:18] <vila> GrueMaster: it's even available in the all-in-one installer for windows at .. ok
[17:18] <vila> so, more involved answer: pain
[17:18] <GrueMaster> Doesn't help the current situation.
[17:18] <farblue> in the situation where upstream do have a vcs in, say, subversion, what would be the recommended approach? Can you create a 'vendor branch' based on the svn release branch and then 'switch' to the new release and merge the changes?
[17:19] <vila> farblue: use bzr-svn
[17:19] <mgz> GrueMaster: make a new local branch at the revision he got the tarball from,
[17:19] <vila> GrueMaster: ok, so the semi-easy answer is to get the proposed branch, copy the files (excluding .bzr) to a copy of your trunk
[17:19] <mgz> get the diff from launchpad and apply it
[17:20] <GrueMaster> And manual diff?  ugh
[17:20] <farblue> so you use bzr-svn to create a 'pull' from, say, release branch 1.0 of the upstream project - what  is the process when they release  version 1.1 on a new release branch or tag?
[17:20] <GrueMaster> grmbl.
[17:20] <mgz> do `bzr commit --author {that guy}` ...
[17:20] <vila> farblue: 'bzr pull'
[17:20] <GrueMaster> That part I know.  I do that whenever someone just sends a patch.
[17:20] <vila> farblue: or 'bzr pull -rtag:<tag>'
[17:21] <mgz> then merge
[17:21] <farblue> ok, so that pulls the latest from upstream.  then what? merge as normal?
[17:21] <vila> yup
[17:21] <mgz> GrueMaster: you should just be able to get his branch, and copy over the changes if you don't want fiddle with patches
[17:21] <mgz> the trick is knowing what his rev 1 corresponds to in your real branch
[17:22] <GrueMaster> Since he made changes first before adding them to a new tree, the entire project looks like a diff.
[17:22] <farblue> vila: thanks :D very interesting that it works for cross-vcs
[17:22] <vila> the tricky part is to make sure you use the correct file-ids or you'll fall into the same kind of issues GrueMaster is facing
[17:22] <mgz> sure, but if you ignore the fact he created a branch at all
[17:22] <GrueMaster> Commit 1 baseline is therefore already a diff.
[17:22] <mgz> and just copy across the tree
[17:22] <vila> farblue: yeah, many thanks to jelmer for that ;)
[17:23] <farblue> quite! and the same for git and hg?
[17:23] <mgz> presumably he started from some tag or other you released
[17:24] <vila> farblue: yup, bzr-hg is still beta, but bzr-svn and bzr-git are used in production
[17:24] <farblue> cool :)
[17:24] <farblue> thanks for all your help :)
[17:24] <GrueMaster> So, you are saying make a separate branch from my tree with the starting point before his change, then just copy his files over the top?  I'll give that a try.
[17:24] <mgz> yup.
[17:25] <vila> LarstiQ: because I didn't forget, config numbers: https://pastebin.canonical.com/60280/
[17:26] <vila> LarstiQ: based on the config hooks triggered for the corresponding actions (load -> read file, save -> write file, the other should self-explanatory)
[17:27] <vila> LarstiQ: the numbers don't match as the changes were introduced along the way (as well as new options), but the overall picture is still relevant
[17:28] <vila> LarstiQ: oh, and that's from running: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork -Econfig_stats --subunit on all revisions and then using ./tools/subunit-sum
[17:29]  * vila face palms, wrong paste site
[17:29] <vila> http://paste.ubuntu.com/843296/
[17:31] <vila> LarstiQ: instructions to reproduce: http://paste.ubuntu.com/843297/ but be aware I've been catching up when you ask this morning and only had to process ~80 revs (and it just finished ;-p)
[17:43] <LarstiQ> vila: so a 700k drop in old_config.load for a 50k gain in new_config.load, not bad!
[17:43] <vila> yup, and that's without caching 'bazaar.conf' and 'locations.conf'
[17:45] <LarstiQ> vila: an increase of 250k gets though seems quite high?
[17:46] <vila> LarstiQ: if there are new gets, it means we're using more options ;)
[17:46] <vila> the point is to make get cheap, not to reduce its usage
[17:49] <LarstiQ> vila: fair enough :)
[17:49] <LarstiQ> vila: is it easy to find out where they come from?
[17:50] <vila> but 250k more for 20.000 tests still is weird, there is probably something worth investigating
[17:50] <vila> probably by making the hooks collect the option/file names
[21:51] <friedrich> hello
[21:52] <friedrich> I am trying to learn about bazaar, but I don't understand shared repos yet: How do i reconstruct if I deleted all folders and files within a shared repo, except the ".bzr" in the top-level ?
[21:53] <bob2> you can't
[21:54] <friedrich> but the .bzr in the top-level holds all information (guessing from the file size)
[21:55] <bob2> it holds much of the information
[21:55] <bob2> but the dirs you deleted hold the branch pointers
[21:55] <bob2> afair
[21:55] <friedrich> hm, ok
[21:57] <fullermd> You may be able to reconstruct much of it by poking around in 'heads'.
[21:58] <fullermd> If you don't have a lot of dead heads in your repo (deleted branches, uncommits, etc), it could be fairly easy.
[21:58] <bob2> true
[21:58] <fullermd> You've lost any branch config (remembered locations, frex), but you should be able to find the revs at least.
[21:58] <bob2> helpfully will even have branch names in bzr
[21:59] <friedrich> don't worry, it was just some test data, while trying to understand bzr
[21:59] <bob2> friedrich, so .bzr in the repo root holds all the rev data, the 'branch directories' mostly just tell bzr which rev in the repo is the head of that branch
[21:59] <friedrich> coming from monotone or fossil-scm I thought that there would be some easy way to reconstruct
[22:00] <bob2> deleting those dirs is explicitly throwing data away
[22:02] <fullermd> The shared repo is basically a big bucket full of revisions.  No real order or structure.
[22:02] <abentley> jelmer: I would like automatic nicknames to use the Branch.name for colocated branches.  Does that make sense to you?
[22:02] <fullermd> The branch dir is what says "these revs are mine", plus some ancillary bits like the saved push/pull/etc locations, possibly a nickname, and more rarely various other stuff.
[22:03] <fullermd> There's a 'heads' command in bzrtools that will dig through the repo and tell you what 'head' revisions are in there, which are likely to have been the heads of branches.  With that you can make a new branch with that head.
[22:03] <fullermd> So the history of the branch can be recovered (well, it's already there; made accessible anyway).
[22:04] <fullermd> If you've got a lot of dead heads (like you'd get from uncommit, or abandoning and deleting a branch), it might take some work to dig out the ones you care about from the noise.
[22:04] <fullermd> And if you had branches whose revs aren't heads (had descendents), you'd have to pretty much know what they are to get them back.
[22:05] <friedrich> ok, I will check out bzrtools - thanks
[22:06] <abentley> friedrich: If you do have a lot of dead heads, --by-date will show what's most recent.
[22:26] <poolie> hi all
[22:28] <abentley> poolie: hi.
[22:29] <poolie> hi there
[22:29] <poolie> thanks for nc:
[22:30] <abentley> poolie: no problem.  It was so trivial I nearly didn't announce it.
[22:30] <poolie> i was going to say maybe you should just merge it
[22:30] <poolie> but, perhaps defaulting to the bzrdir of . is a bit too weird to support
[22:32] <abentley> poolie: So I guess if you have a lightweight checkout of a colocated branch, nc: should refer to the bzrdir of the referenced branch.
[22:33] <abentley> poolie: using the current bzrdir reflects a (not entirely crazy) assumption that your lightweight checkout is colocated with the colocated branches.
[22:33] <poolie> right
[22:33] <poolie> anyhow if you wanted to merge it, perhaps with a note in the help that it's experimental, that would be ok with me
[22:33] <poolie> maybe make it x-nc:
[22:34] <abentley> poolie: I thought the plan was to get other commands respecting colocated branches shortly, so that nc would not be useful for long.  But if you want it in core, I can do that.
[22:37] <poolie> i think, generally, if there's a small and not harmful interim improvement, it's better to merge it than to count on the real fix arriving soon
[22:41] <abentley> poolie: Do we have a user-facing term for Branch.name?
[22:41] <poolie> i'm not sure
[22:41] <poolie> not 'branch name'?
[22:45] <abentley> poolie: I dunno, I just thought it might not be specific enough-- could refer to the basename of the branch or is nickname.  But I've come up with some verbiage I like.  I'll post the merge proposal in a minute.
[22:46] <poolie> mm
[22:46] <poolie> well, we should be consistent about it, and put it in a comment next to branch.name, and in overview.txt
[22:46] <poolie> i agree that may be a bit generic
[22:49] <abentley> poolie: Does vila's new stuff give us a way of substituting the branch nick or branch name in config files the way we used to do with appendpath?
[22:49] <poolie> yes
[22:49] <poolie> it may require some amount of glue to make it available there
[22:49] <poolie> *small amount, hopefully
[22:55] <abentley> poolie: I can't find any documentation.  Has it landed yet?
[22:58] <poolie> looking
[23:00] <poolie> so it is landed, in Config.expand_options, etc
[23:01] <poolie> it doesn't look very documented though
[23:04] <poolie> i'll mail him
[23:05] <poolie> abentley, i think the short story is that you need to define a config variable for the thing you want to insert, with a default method that calculates the right value
[23:05] <poolie> then you can just expand that with {foo} inside other values
[23:06] <abentley> poolie: The default method is provided in Bazaar?
[23:07] <poolie> you declare and register an Option object, and its default= constructor parameter is a callable
[23:07] <poolie> hm
[23:07] <poolie> it seems like it ought to be called with some context
[23:12]  * abentley is kinda surprised that nickname isn't already registered.
[23:13] <lifeless> poolie: hi
[23:13] <poolie> hi there
[23:13] <poolie> should have pung
[23:13] <poolie> how about now?
[23:14] <lifeless> sure
[23:14] <lifeless> me being online and all :P
[23:27] <abentley> poolie: This is what I was doing: https://code.launchpad.net/~abentley/bzr/name-nick/+merge/93319


[04:23] <alkisg> Good morning
[04:23] <HedgeMage> hi :)
[04:25] <stgraber> oh, it's already this late ? ;)
[04:28] <HedgeMage> yes, sadly it is
[04:28] <HedgeMage> (creeping up on midnight here)
[04:30] <alkisg> stgraber: do I have 1 hour before you tag ltsp? I think that "tasksel failed because aptitude returned 100" is a file descriptor problem, and actually means "aptitude returned 100% completed", so I'm just now testing ltsp-build-client to see if it's safe to ignore it at least for now...
[04:31] <stgraber> alkisg: you have a bit more than that, I did a lot of changes today in ltsp-trunk and ldm-trunk, so I'll wait until tomorrow (late morning / early afternoon) to tag + upload
[04:31] <alkisg> Ah, perfect :)
[04:31] <stgraber> I merged that nbd-proxy bit and implemented some initial caching for ltsp_config + some other stuff I had laying around
[04:32] <alkisg> stgraber: what's the easiest way for me to test your commits?
[04:32] <alkisg> I.e. to make a local ubuntu package out of the bzr branch?
[04:32] <stgraber> alkisg: I have an updated ltsp in my PPA (bzr snapshot), I can update it with what's currently in trunk so you can easily test it
[04:32] <stgraber> give me 2 minutes
[04:33] <alkisg> Merci :)
[04:33] <stgraber> sorry, don't know the greek for no problem ;)
[04:33] <alkisg> :D (or if you could tell me how you do the bzr => ubuntu package thing, I can do it on my own here...)
[04:34] <stgraber> I usually use mkdst (that tool we use to tag/release ltsp) to build me a new tarball, then rename it to mention it's a snapshot and include the bzr revision and make sure the version number is lower than the next upstream version
[04:35] <crimsun> ok, seed time
[04:35] <alkisg> Thanks, I'll put "learn how mkdst works" in my TODO list :)
[04:35] <stgraber> so, for the one I'm doing, it's: ltsp_5.1.99~bzr1517.orig.tar.gz
[04:35] <crimsun> (now that I've closed 76 bugs with the latest upload)
[04:35] <alkisg> crimsun: hi, will we see that libsdl-pulse inclusion any time soon?
[04:36] <stgraber> crimsun: that's a lot of bugs :)
[04:36] <alkisg> wow, 76 bugs, yeah...
[04:36] <crimsun> alkisg: that's the seed thing mentioned above
[04:36]  * alkisg dances :)
[04:37] <stgraber> alkisg: new snapshot build for ltsp, uploaded.
[04:37] <stgraber> alkisg: I'll do one for ldm too or you'll have some issue getting to ldm
[04:37]  * alkisg thinks Lucid will be the best Ubuntu version ever :)
[04:37] <alkisg> stgraber: the nbd-client patch I reported? don't worry I have a local patch for it here...
[04:38] <alkisg> *bug
[04:38] <stgraber> alkisg: not only that, nbd-proxy makes nbd-client connect to localhost, so it's introducing a lot of other issues ;)
[04:39] <alkisg> Oooh ok, waiting for your ppa upload then
[04:41] <stgraber> uploaded
[04:42] <stgraber> alkisg: you should have both built in an hour or so, the builders seem a bit slower now than they were this afternoon
[04:43] <stgraber> alkisg: I also uploaded a new ltspfs but this one was uploaded directly to archive, not to my PPA (it's an actual release, not a snapshot)
[04:43] <alkisg> Btw, here's what I'll be commiting in a few hours. It has "TODOs" in it, but I think it works better than the last version. I'll debug those in the next few days.
[04:43] <alkisg> http://ltsp.pastebin.com/m20e9470
[04:44] <alkisg> stgraber: ok, I'll be trying all those in the next few hours
[04:44] <stgraber> are you sure your tasksel works correctly "
[04:44] <stgraber> ?
[04:44] <alkisg> I'm testing as we speak
[04:45] <stgraber> I'd have done: chroot $ROOT "tasksel install $desktop || true"
[04:45] <alkisg> Ooops
[04:45] <alkisg> dammit
[04:46] <stgraber> also, AFAIK that APT_GET_OPTS isn't actually part of apt's environment, it's something we usually append to an apt-get command and I don't see one in your script, not sure it's actually doing anything ;)
[04:46] <alkisg> I was fiddling with tty handling a while ago, and I saw tasksel's gui (whiptail) going to 100%, and right after that "aptitude failed (100)"
[04:46] <alkisg> So I'm beginning to think it's a descriptor/return value interpretation problem
[04:46] <stgraber> and IIRC I actually have a plugin writting a file in /etc/apt/conf.d/ to do the same as --no-install-recommends, so you may want to get rid of it too
[04:47] <alkisg> APT_GET_OPTS is used later on to write the "recommends" stuff to apt.conf.d
[04:47] <alkisg> So I remove "recommends" to prevent it from being written to apt.conf.d
[04:47] <stgraber> oh, interesting, I forgot I actually checked for that variable before writting apt.conf.d ;)
[04:47] <alkisg> :)
[04:48] <stgraber> btw, that same chroot fix also applies to the last chroot call
[04:48] <stgraber> the || true should be in the chrooted command, not outside
[04:48] <alkisg> It's not really useful in the script, it's only useful for updates later on
[04:48] <alkisg> Does it make any difference?
[04:48] <stgraber> chroot $ROOT "gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --set --type list --list-type string /apps/panel/global/disabled_applets \"[OAFIID:GNOME_FastUserSwitchApplet,OAFIID:GNOME_IndicatorApplet]\" || true"
[04:49] <stgraber> well, with: "chroot $ROOT something || true", if $ROOT doesn't exist or chroot isn't installed (for some unlikely examples), it won't complain
[04:49] <alkisg> In any case I'll try to change that to a gconf file, and put it in the correct dir
[04:50] <stgraber> whereas with 'chroot $ROOT "something || true"', you'll still get the most important errors but ignore the return code of the command called inside it
[04:50] <stgraber> for your debconf issue, it's actually quite simple to workaround I guess
[04:50] <alkisg> Well sure but it'd be weird for chroot to return an error there, if it was working in all the lines above
[04:50]  * alkisg is all ears... :)
[04:51] <stgraber> we're using the Passthrough backend which uses that fd that you are getting error for to report status to the debian-installer (at least it was the idea)
[04:51] <stgraber> you could set it to NonInterractive for the fat client part and that won't use any fd
[04:51] <alkisg> :)
[04:52] <alkisg> stgraber: finished succesfully - but it was unable to unmount /proc, and that got me a lot of squashfs compression errors (file in use etc)
[04:52] <alkisg> I also got that when I tried the version of the script that's currently in bzr
[04:52] <stgraber> OLD_DEBIAN_FRONTEND=$DEBIAN_FRONTEND
[04:53] <stgraber> DEBIAN_FRONTEND=noninteractive
[04:53] <stgraber> tasksel blah
[04:53] <alkisg> Thanks, got it :)
[04:53] <stgraber> DEBIAN_FRONTEND=$OLD_DEBIAN_FRONTEND
[04:53] <alkisg> Can I force umount -l /proc there temporarily, until I properly debug it in the next days?
[04:53] <stgraber> alkisg: check for running process inside the chroot
[04:54] <stgraber> alkisg: something must have start a process during the installation of some package and that's what blocking /proc
[04:54] <stgraber> if you kill that process, you'll be able to unmount /proc
[04:54] <alkisg> I think `sudo lsof /opt/ltsp/i386/proc` is giving me the server's processes... !!!
[04:54] <stgraber> sure
[04:54] <alkisg> How else would I check to see what's running inside the chroot?
[04:54] <stgraber>  /proc and /opt/ltps/i386/proc are exactly the same thing ;)
[04:55] <stgraber> ps aux and look at the start time
[04:55] <stgraber> it's usually the easiest
[04:55] <alkisg> Ah. /me feels silly :)
[04:55] <alkisg> notify-osd it is
[04:56] <alkisg> Hmm, no, looking....
[04:59] <alkisg> I actually don't have any such process running. Maybe it's some daemon that's being reused from some program in the chroot?
[05:00] <stgraber> it shouldn't anyway, you can do a "umount -l" on it, it'll solve your squashfs issue
[05:00] <alkisg> OK, so temporarily I'm going to umount -l && remount it, with a # TODO to properly solve it later
[05:14] <stgraber> going for some sleep, last night was really short due to that livedvd issue ;) see you all in 7-8 hours.
[05:15] <alkisg> goodnight :)
[05:30] <alkisg> !info gimp lucid
[12:29] <ma3x> hello
[12:29] <ma3x> i installed ubuntu and edubuntu as extra. can i make the distro edubuntu or at least how can ichange the splash screen to edubuntu
[12:32] <ma3x> helloooooo
[13:11] <highvoltage> stgraber: good morning to you
[13:11] <highvoltage> stgraber: did yesterday's image become the alpha 2 or do I need to do another sync?
[13:12] <alkisg> highvoltage: I'm having problems to find a *correct* way to prevent gdm from being installed while keeping everything else in place. Is it a problem if it gets installed instead, but of course while keeping ldm as the default display manager?
[13:13] <alkisg> (i.e. `echo "/usr/sbin/ldm" > $ROOT/etc/X11/default-display-manager` before installing ubuntu-desktop)
[13:14] <stgraber> highvoltage: it became the alpha-2
[13:49] <highvoltage> alkisg: I wonder whether ldm could get a Provides field so that it provides GDM and KDM (that should solve it on Kubuntu too then, if it's installed before the desktop main metapackage)
[13:49] <alkisg> highvoltage: I don't think it's a bad idea to make ldm able to work beside gdm
[13:49] <highvoltage> stgraber: yay!
[13:49] <alkisg> It could also be used in the future in standalone workstations
[13:50] <stgraber> alkisg: I suspect your LTSP boot didn't work, right ?
[13:50] <alkisg> E.g. I setup ubuntu normally, then install ldm, and I have something like a fat client but with centralized administration...
[13:50] <stgraber> alkisg: I just found this bug in my current package: http://pastebin.com/f7b8424bd
[13:50] <alkisg> stgraber: it works but only when I manually install the needed packages
[13:51] <alkisg> Ah, ok, I used IPAPPEND 3 to bypass this
[13:51] <alkisg> Thanks
[13:52] <alkisg> highvoltage: I think with a small patch in ltsp_config, the client should be able to boot even with gdm installed
[13:52] <alkisg> And gdm won't start if it sees '/usr/sbin/ldm' in /etc/X11/default-display-manager
[13:52]  * alkisg tries all these...
[14:06] <alkisg> highvoltage: Yup, with a 2 lines-patch in ltsp_config, now ldm works fine for me with gdm also installed in the chroot
[14:06] <alkisg> highvoltage: could you tell me about the other "blacklisted" packages in your fat client script?
[14:06] <alkisg> (I mean, why they were blacklisted?)
[14:13] <alkisg> Supposedly, the correct way to install ubuntu-desktop is with `tasksel install ubuntu-desktop`. I tried that, but I ended up with a chroot without e.g. lspci, which broke many xorg scripts.
[14:13] <alkisg> Should I try `tasksel install ubuntu-desktop` AND apt-get install ubuntu-standard?
[14:13] <alkisg> Or should I just do `apt-get install ubuntu-desktop` and get on with it? :)
[14:43] <sbalneav> Morning all
[14:44] <stgraber> hey sbalneav
[14:45] <stgraber> alkisg: that's fixed in the new package, I depend on lspci
[14:45] <stgraber> alkisg: the reason why it didn't work is that it was dropped from ubuntu-minimal and so was dropped from the chroot
[14:45] <alkisg> Ah, ok
[14:46] <alkisg> stgraber: I'm trying to do this: apt-get install ubuntu-standard ubuntu-desktop
[14:46] <alkisg> (or any other user defined desktop)
[14:46] <alkisg> I.e. I assume that fat == those packages only...
[14:47] <alkisg> And I only left those in the blacklisted packages: etwork-manager modemmanager ubufox apport jockey-common
[14:54] <mhall119|work> what is ldm?
[14:55] <alkisg> The LTSP display manager
[14:56] <sbalneav> mhall119|work: The bit that manages the login process for thin clients
[14:57] <mhall119|work> ah, cool
[14:57] <mhall119|work> thought it was maybe an lxde display manager
[14:57] <mhall119|work> highvoltage: I've been reading about how to customize the new GDM and XSplash
[14:58] <mhall119|work> it doesn't look too hard, but it's not nearly an flexible as the old GDM and USplash
[15:43] <alkisg> ...almost ...there :)
[17:07] <alkisg> stgraber: I commited the modified script, could you ping me when you upload a new ltsp version to Ubuntu, so that I can test again from scratch?
[17:09] <stgraber> alkisg: ok
[17:09] <alkisg> ty
[18:59] <sbalneav> alkisg: Two months ago you couldn't even spell "Upstream Free Software Developer", and today you is one :)
[19:00] <sbalneav> \o/ for alkisg
[19:01] <alkisg> And who was the one that almost "pushed" me upstream? Thanks to sbalneav!!! :)
[19:02] <alkisg> sbalneav: but really, I've been a floss developer for decades. Just in assembly/Delphi, away from Linux :)
[19:06] <sbalneav> Well, I think being made a member of upstream is, if nothing else, a recognition of skill, and dedication.
[19:07] <sbalneav> One of the things I've always loved about Free Software is, it's one of the true meritocracies in the world.
[19:07] <sbalneav> You were making a significant contribution.
[19:07] <sbalneav> You *should* be recognized.
[19:08] <alkisg> Yup, being part of a good upstream project is a new experience for me, and a very good one
[19:08] <alkisg> Thank you guys for accepting me :)
[19:08]  * alkisg has to leave the keyboard again because his daughter needs to play ikariam :P :D
[19:49] <stgraber> alkisg: I have two guys here debugging an issue with nbd-proxy, I expect to tag + upload once it's fixed.
[19:49] <alkisg> stgraber: np, thanks, what's nbd-proxy all about? what will it solve?
[19:50] <alkisg> Will clients need more ram for it?
[19:50] <stgraber> no they won't
[19:50] <stgraber> it's just something that makes sure you'll never get any squashfs or input/output error
[19:51] <alkisg> Cool :)
[19:51] <stgraber> it's handling the NBD reconnect in place of the current nbd kernel module and does a lot more checks
[19:51] <stgraber> I actually am testing it by doing a checksum of all files in the chroot while killing the server once every second ;)
[19:52] <alkisg> Wow!!!
[19:52] <alkisg> Sounds rock solid indeed :)
[19:52] <stgraber> haven't seen any dataloss or corruption yet but I sometimes have a process hanging and forcing me to reboot
[19:52] <stgraber> so that's what's being fixed now
[19:52] <stgraber> (something about sending a byte too much when reconnecting, leading to squashfs crashing ;))
[19:54] <alkisg> So is that also included in the initramfs, completely replacing the kernel module?
[20:03] <mgariepy> sbalneav, ping
[21:22] <alkisg> sync -zthhP rsync://cdimage.ubuntu.com/edubuntu/releases/10.04/alpha-2/lucid-dvd-amd64.iso ./lucid-dvd-amd64.iso
[21:22] <alkisg> @ERROR: Unknown module 'edubuntu'
[21:22] <alkisg> rsync error: error starting client-server protocol (code 5) at main.c(1521) [receiver=3.0.6]
[21:22] <alkisg> How can I rsync to see if what I have is == alpha 2?
[21:30] <alkisg> Hmmm pitivi recommends hal...


[03:27] <Unit193> Not sure it matters to anyone all that much, but SwissBot is a single network bot and it's leaving for Libera very shortly.
[04:30] <guiverc> :(   it'll get lonely soon


[00:25] <spoleeba> is there a way to logout and relogin as a different user using a cmdline tool?
[00:25] <spoleeba> u1sdtool doesn't seem to have the option to change users
[00:32] <spoleeba> ah...delete the key in the keyring and it will let me relogin...
[10:42] <jo-erlend> yes, I'm seeing more people having problems with sync conflicts when working on LibreOffice documents directly on a synced folders. It's probably because of autosave. There really should be some tools to handle conflicts so that it doesn't feel so scary. Is there a bug report on that? Also, if it's feasible, would it be appropriate to deactivate sync while LibreOffice is running?
[10:44] <jo-erlend> the best option would be if LibreOffice would notify Ubuntu One of autosaves so that it could handle it appropriately, I think, but that's probably difficult.
[11:38] <duanedesign> jo-erlend: I think their was a fix for this. So I am not sure if that fix is backported. Also would be interesting to know what version people are having these conflicts  on.
[11:38] <duanedesign> But definetly that is annoying and shouhld not be happening
[13:32] <jo-erlend> duanedesign, I don't think it's possible to avoid all kinds of conflicts, but it is possible to provide an easy way to handle them.
[14:12] <Dephenom> right, so I have purchased an album in Banshee from the UbuntuOne Music Store, on my downloads page in Banshee it is still saying "queued", and on one.ubuntu.com/files, the album is not even showing up. Is there anything I need to do to get the album onto my computer?
[14:29] <duanedesign> hello Dephenom
[14:29] <Dephenom> hi duanedesign
[14:30] <duanedesign> Dephenom: if you want to msg me the email for your account I can take a look at it
[14:31] <Dephenom> just pmed it to you duanedesign, thanks
[15:05] <n2diy> Last night I setup my Ubuntu One account, and installed the software via synaptic, 14 hours later, my 3 gig of files are still syncing, I think I have a problem? I'm running Xubuntu 10.10.
[16:08] <duanedesign> n2diy: If you run this command  what do you get:   u1sdtool -s
[18:40] <jo-erlend> does anyone know why desktopcouch sync doesn't come back up?
[18:42] <jo-erlend> I think it's a little worrying that Ubuntu One can just disappear for months without a word of explanation or when to expect it to be back in service.
[20:36] <n2diy> duanedesign, command not found, looks like I need to install the ubuntuone-client package, thanks.
[20:40] <n2diy> duanedesign, but, ubuntuone-client is already installed, do I need the tools package too?
[20:47] <n2diy> duanedesign, for giggles, I used the upload file commands from the website, and I did transfer a file.
[22:38]  * Dephenom sighs