[00:12] <jam> sttng359: rm -rf .bzr ; bzr init-repo .; bzr svn-import $SVN ?
[00:12] <jam> a bit overzealous perhaps
[00:13] <sttng359> jam: will existing bzr branches made against my current broken branch still work against a fresh svn import or will it look like a new bazaar branch?
[01:37] <maxb> sttng359: I think there's a good chance they'll work fine, bzr-svn is supposed to be deterministic and repeatable. I'd say they'd definitely work, but I don't understand how your existing repository could be subtley broken in the way you describe
[01:46] <sttng359> maxb: well, it now looks like every branch I have under that shared repo believes the symlinks should be zero-length files and creating branches outside of that shared repo replicates that, but a fresh checkout using bzr from subversion correctly generates symlinks.
[01:47] <sttng359> I was using that originally to create a couple different test branches without cluttering up subversion, but I may have to recreate them all.
[02:25] <sttng359> nope, existing bazaar repos don't recognize my new checkout.
[02:26] <sttng359> maybe it has to do with using a 1.4 subversion server.
[02:36] <aaron01> I'm getting "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 50: ordinal not in range(128)" when trying to bzr import a tarball. However, if I import the extracted contents of the tarball it works fine. Ideas?
[02:38] <spiv> aaron01: sounds like a bug :/
[02:38] <spiv> aaron01: please file a bug report
[02:38] <spiv> Hmm.
[02:39] <spiv> Off the top of my head the tarball import code assumes all filenames are ascii, but the import from filesystem directory can use the system locale to guess filesystem encoding.
[02:40] <spiv> I'm not sure if tarballs store filenames as bytes or in a defined encoding.  I suspect bytes... but if so, we could add an option to allow you to explicitly specify the filename encoding.
[02:43] <fullermd> I'd be astonished by anything other than bytes, if for no other reason than that tar predates encodings.  Well, unless you count EBCDIC, maybe...
[02:46] <spiv> fullermd: well, there have been occasional extensions to the format IIRC, but yes.
[02:53] <sttng359> spiv: from what I understand, the USTAR format for filename is a byte field
[02:53] <sttng359> http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current
[02:53] <sttng359> does bazaar attempt to convert filenames to UTF-8 for storage?
[02:53] <fullermd> Wow, 8-current...
[03:01] <spiv> Well, they are unicode in bzr's storage model.  The implementation happens to be UTF-8 IIRC, but that detail isn't particularly relevant here.
[03:22] <aaron01> I think it might be helpful if the traceback would be more verbose about what file it is failing on
[03:35] <thumper> BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:0fe7e46a367f403f3a2e51af8fa78962cba9f8d3',)]
[03:35] <thumper> getting this with 2a merge directives
[03:36] <spiv> thumper: hmm
[03:37] <thumper> spiv: probably has stacking issues too
[03:37] <spiv> thumper: possibly the source repo needs the fix at https://bugs.edge.launchpad.net/bzr/+bug/613698 run on it
[03:37] <spiv> thumper: or possibly there's an issue specific to merge directives
[03:39] <thumper> spiv: bug 517126
[03:40] <spiv> thumper: any chance of those "more details" getting filled in? :)
[03:41] <spiv> thumper: like which branch?  or the contents of the merge directive?
[03:45] <thumper> spiv: possibly
[03:49]  * spiv -> lunch
[04:01] <AfC> Is there a "known" bug about Bazaar not expanding ~ in revision specs?
[04:02] <fullermd> bug 138787
[04:10] <AfC> fullermd: yeah, that seems like it
[04:11] <AfC> so annoying
[04:11] <AfC> fullermd: I'm not sure "user refs" is really the right label for it
[04:11] <AfC> to me it's "tilda" and "home dir[ectory]"
[04:12] <AfC> fullermd: can I suggest
[04:13] <AfC> "revision specs don't expand ~ or ~user in paths"
[04:13] <AfC> or such?
[04:18] <fullermd> Well, ideally I'd suggest "fix released"   :p
[04:18] <fullermd> 3 years in, it's hard to work up much expectation though.
[04:23] <AfC> be nice
[04:30] <AfC> fullermd: I commented your bug with our use case; perhaps that'll up its google juice.
[04:30] <AfC> Cheers
[07:34] <vila> hi all !
[12:34] <Kamping_Kaiser> hi all. i had a bzr branch <svn repo> drop out. is there a way to resume it? rerunning bzr branch or bzr up just error, in different ways
[12:34] <Kamping_Kaiser> i'd rather not redownload 1.8gb again :( (and still going)
[12:37] <maxb> Was the branch a standalone one or into a shared repo?
[12:37] <Kamping_Kaiser> standalone
[12:38] <maxb> Try running 'bzr heads --dead' in the partial branch
[12:40] <Kamping_Kaiser> ok. i'm just making a copy, i'll try it after that :)
[12:41] <maxb> Why are you making a copy?
[12:42] <Kamping_Kaiser> bzr: ERROR: unknown command "heads"
[12:42] <Kamping_Kaiser> because i can't afford to download 1.8 gb again, so i don't want to break a copy
[12:44] <maxb> Install bzrtools
[12:44] <Kamping_Kaiser> hm, i thought i had it. let me check
[12:44] <Kamping_Kaiser> thanks
[12:46] <Kamping_Kaiser> i don't have it, branching it atm
[12:50] <Kamping_Kaiser> maxb: got it, it removed a commit. do i resume by branching again?
[12:50] <maxb> uh?
[12:50] <maxb> 'bzr heads --dead' is a query command. it changes nothing
[12:51] <Kamping_Kaiser> ah, hehe. the svn commit message contained a coment about removing stuff. guess i confused them
[12:52] <maxb> ok, so bzr heads --dead showed one revision, the latest svn revision that actually got transferred
[12:53] <maxb> the question now is how to convince bzr to pick up where it left off
[12:53] <maxb> Does a .bzr/branch/ directory exist at all?
[12:54] <Kamping_Kaiser> no. there is a .bzr/branch-lock dir, but not branch
[12:55] <maxb> "bzr branch svnurl ." might work, if not we'll have to get more devious
[12:56] <Kamping_Kaiser> sadly, 'bzr: ERROR: Target directory "freeciv" already exists.'
[12:57] <maxb> Try adding --use-existing-dir
[12:58] <jelmer> 'bzr init && bzr pull <svn-url>' perhaps?
[12:58] <jelmer> maxb: I think that will still try to create the .bzr dir
[13:00] <Kamping_Kaiser> jelmer: thats trying to re-download it from scratch.
[13:02] <Kamping_Kaiser> maxb: that returns 'bzr: ERROR: Already a branch: "freeciv".'
[13:02] <Kamping_Kaiser> but trying to pull in the dir i get 'not a branch :/
[13:02] <maxb> I am not so sure, I think jelmer's command would work (run in the directory with the existing .bzr from the first try)
[13:04] <Kamping_Kaiser> hm
[13:04] <Kamping_Kaiser> wonder whats going on
[13:06] <maxb> Any opinions on how long I should wait for potential dissent before copying bzr/proposed to bzr/ppa ?
[13:10] <jelmer> maxb: I would be surprised if resume worked in a standalone branch
[13:10] <jelmer> maxb: it's a known bug that it doesn't :)
[13:10] <jelmer> maxb: Was the pyrex issue fixed?
[13:11] <maxb> yes
[13:11] <jelmer> in that case I'd say go for it
[13:11] <vila> maxb: did we get feedback from people testing bzr/proposed ?
[13:11] <jelmer> it's working here, and the only other thing I've heard from others is the pyrex issue
[13:11] <maxb> The only active feedback I'm aware of is the report of the pyrex issue
[13:12] <maxb> we have tested that the archive as a whole is installable
[13:12] <vila> maxb: then I agree with jelmer: go
[13:15] <Kamping_Kaiser> hm, perhaps jelmer was right. its only pulling 2000 revisions, so perhaps its pulling the remaining files
[13:22] <Kamping_Kaiser> wow... thank you maxb and jelmer, bzr is 'doing stuff' again :)
[13:24]  * maxb bites the bullet and executes lp-promote.py bzr/proposed bzr/ppa
[13:24] <bigjools> is the non-compiled extension thing fixed?
[13:25] <maxb> yes
[13:26] <bigjools> \o/
[13:26] <maxb> whee, look at all the little green cogs :-)
[13:31]  * vila notes: always add green cogs
[13:36] <Kamping_Kaiser> hm. bzr appears not to handle its terminal getting resized down very wel :/ (unless its my old version, which it could well be)
[13:43] <jml> sad
[13:46] <jelmer> jml: ?
[13:46] <jml> I just had to type this:
[13:46] <jml> bzr resolve src/zope/testing/testrunner/testrunner-ex src/zope/testing/testrunner/testrunner-ex-pp-lib src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4 src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4/products src/zope/testing/testrunner/testrunner-ex-pp-products src/zope/testing/testrunner/testrunner-ex-pp-products/more src/zope/testing/testrunner/testrunner-ex/sample1 src/zope/testing/testrunner/testrunner-ex/sample1/sample11 src/zope/testi
[13:46] <jml> r/testrunner-ex/sample1/sample13 src/zope/testing/testrunner/testrunner-ex/sample1/sampletests src/zope/testing/testrunner/testrunner-ex/sample2 src/zope/testing/testrunner/testrunner-ex/sample2/sample21 src/zope/testing/testrunner/testrunner-ex/sample2/sample22 src/zope/testing/testrunner/testrunner-ex/sample2/sample23 src/zope/testing/testrunner/testrunner-ex/sample2/sampletests src/zope/testing/testrunner/testrunner-ex/sample3 src/zope/testing/testrunner/
[13:46] <jml> x/sampletests
[13:46] <jelmer> ahh
[13:46] <jelmer> I was wondering whether you couldn't find your livejournal window :-P
[13:47] <jml> hah hah
[13:47] <vila> jml: were there all text conflicts ?
[13:48] <vila> jml: a bare 'bzr resolve' is supposed to resolve all "auto solvable" conflicts, but...
[13:49] <jml> vila, no text conflicts.
[13:49] <jelmer> jml: Or, bzr resolved --all?
[13:49] <jml> vila, this is the same old bug that I always complain about
[13:49] <vila> jelmer: vade retro satanas: never use that
[13:49] <jml> good grief
[13:49] <vila> jml: oh, the.pyc files ?
[13:49] <jml> I've never heard anyone say that in Latin
[13:49] <jml> vila, yes.
[13:50] <vila> jml: on top my conflicts TODO list... but ETOOMAYTODOLISTS
[13:50] <vila> jml: crystal ball predicting that it may be surface as soon as this week though...
[14:04] <vila> jml: oh, in the mean time, I think 'bzr clean-tree --detritus' helps
[14:04] <jml> vila, thanks.
[14:10] <Kamping_Kaiser> sheesh. bzr can hammer the cpu when it wants. guess its repacking 1.8gb of data though
[14:40] <kpettit> I'm new to bzr and trying to figure out the best way to do something.  I have a main code repository that tends to have different code for each customer.  I need to have a main default repository then one for each customer, trying to keep code in sync.  95% of the code stays the same.
[14:41] <kpettit> I'm trying to figure out the best way to set this up. So I can have in a directory  "main" directory then directories for "customerA" "customerB" etc.
[14:50] <maxb> It *sounds* like you want a "main" branch containing customer-agnostic code, each customer is a branch off main, main gets merged into customer branches when needed, but never the reverse
[14:51] <maxb> On the occasion that a change on a customer branch is deemed applicable for main it gets cherrypick-merged
[14:52] <rubbs> is there any documentation on cherrypick-merges? as kpettit's question is very similar to something we will need here.
[14:53] <kpettit> rubbs: I'll see if I can find anythning on that  http://wiki.bazaar.canonical.com/CherryPick  is the first thing that comes up.
[14:53] <rubbs> kpettit: thank you
[14:55] <kpettit> For my project it's a web html/css/js thing.  Everything is the same except a couple of custom css and js files.  I won't have those in the main repository, but I want to have them in each of the individual customer branches.  So I want to be able to update customer brances with latest default code and also keep seperate customer css/js custom files in their own repository.
[14:56] <maxb> A cherrypick merge is a merge of a specific changeset *not* an entire branch of history. Of particular importance is to note that Bazaar does not track cherrypick merges at all in its own metadata.
[14:57] <rubbs> maxb: good to know thank you.
[14:57] <rubbs> kpettit: sounds similar to us.
[14:59] <kpettit> so there isn't a good default way to do what we're wanting then I guess?
[15:05] <kpettit> rubbs: Check this out http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
[15:12] <jml> *sigh*
[15:12] <jml> Unable to load plugin 'pipeline'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1)
[15:18] <rubbs> kpettit: yes, I did know about shared repos, and I"m looking into stacked branches.
[15:18] <kpettit> that sounds promising.
[15:19] <rubbs> I've used bzr before, but always for personal stuff, so I never needed to know about many features, because I never needed them, but I'm having to (re)learn stuff for our company migration to bzr coming in a few months
[15:19] <rubbs> I'm trying to come up with a good migration plan
[15:19] <kpettit> basically doing the same here.  All on SVN right now, but it's painful and doesn't do stuff like this
[15:19] <rubbs> right
[15:20] <kpettit> If this idea works it'd be nice to apply the same thing to linux config files.  Where you have a default and branches for customizaitons and such.
[15:20] <rubbs> Right as I was hired, my boss was talking about starting to use branches and thinking about merging down the line. Luckily he listened to me when I told him that multiple merges with svn was awful
[15:21] <rubbs> kpettit: you may wish to look at etckeeper
[15:21] <rubbs> I'm working on a plan for that oo
[15:21] <rubbs> too*
[15:21] <rubbs> it can use hg,git, or bzr
[15:21] <kpettit> :)  I'll do what I can to avoid using cfengine
[15:21] <rubbs> heh
[15:22] <kpettit> etckeep is good for a individual system.  I was thinking for global where we have a default and clone to dozens/hundrends of systems then each of those have their own that can be checked in on a main system as seperate repositories.  Makes it easy to clone and develop individual custome systems that way
[15:24] <rubbs> right. I know a friend of mine is developing something that might fit your needs, but at this point it's not even up to alpha stage yet. He's going to call it Ranchero.
[15:24] <rubbs> I hope he gets something out soon.
[15:25] <kpettit> I'll keep my eyes out for it
[15:28] <rubbs> it could be a while, just a warning. He goes through spurts. Does a lot of work on it, then just lets it die for a while
[15:28] <kpettit> I'm the same way
[15:30] <rubbs> Am I correct in thinking that if you have a bound branch, unbind for a while, then rebind, that it will automatically sync revisions?
[15:30] <rubbs> at the bind?
[15:34] <rubbs> kpettit: not sure if you saw this, but it may help: http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/adv_merging.html
[15:36] <kpettit> thanks, reading...
[15:36] <kpettit> I got etckeeper as well.  The docs say it uses git by default but on ubuntu the default etckeeper package uses bzr which is cool with me
[15:37] <rubbs> same here, you also use ubuntu for prod servers?
[15:37] <kpettit> yes
[15:38] <kpettit> I'm using rackspacecloud and mainly ubuntu 10.04 images
[15:38] <kpettit> we do alot of windows stuff, but I try to ignore that as much as possible
[15:39] <rubbs> know that feeling well ;)
[15:41] <maxb> jml: hmm?
[15:41] <jml> maxb, I just had to add a ppa, no big deal, just another hurdle.
[15:42] <maxb> jml: ok, but what combination of ppas did you have that produced the error in the first place?
[15:42] <jml> maxb, Lucid & the pipeline branch.
[15:43] <jam> hi vila, thanks for the reviews
[15:43] <maxb> Oh, I see
[15:43] <maxb> jml: there's a lp:bzr-pipeline/2.1
[15:43] <jml> maxb, too late now :)
[15:43] <maxb> rubbs, kpettit: shared repositories and stacked branches are all about avoiding wasted diskspace - they have no bearing on your development workflow
[15:43] <vila> hi jam
[15:44] <kpettit> maxb: got ya.  Any suggestions?
[15:44] <jam> vila: 'saw' doesn't seem to have python-testtools installed. Did I do something wrong?
[15:44] <vila> jam: hmm, no, I use a private branch, let me check
[15:44] <rubbs> maxb: right, I knew that. I'm the systems guy here, so I have to keep that in mind too, and in a way it will impact workflow as permissions to the central server will impact if I need to do stacked vs shared.
[15:45] <maxb> kpettit: Is there any reason you want your customer specific stuff in a separate *repository*? What did you think of my initial suggesting regarding branches?
[15:45] <maxb> rubbs: Ah, yes, that's a factor. I'd be interested to know what you end up with, I'm attempting to set up a fledgling bzr environment at my workplace too, in the hopes of wooing them away from svn
[15:45] <rubbs> kpettit: you could keep things in a shared repo, and have separate branches for each client/customer.
[15:45] <jam> vila: I set something up using PYTHONPATH, but that is a bit clumsy
[15:46] <vila> jam: installing testtools and subunit
[15:46] <jam> vila: thansk
[15:46] <jam> thanks
[15:46] <rubbs> maxb: I'm still working on ideas, but if I come up with one, or at least come up with a preliminary plan I'll spam the mailing list. Maybe I can get some improvements on the ideas I have ;)
[15:46] <kpettit> maxb: you were right on what I want.  The main branch I want copied to child brances.  They child brances will have files that aren't in the main branch that need to be versioned but they will not need to commit from the child to main branch
[15:46] <maxb> Oh, whilst I have testtools and subunit-knowing folks here: should we be updating the ~bzr ppa to the latest upstream of those?
[15:47] <vila> damn, babune's xp slave is hosed :-/
[15:48] <jam> maxb: If you are willing to do the work, it would be great to get the updates :)
[15:48] <rubbs> kpettit: yeah, I would suggest a shared repo for you then, (or stacked if you want to limit commit access to certain branches) and just merge from the main, into the customer branches.
[15:48] <kpettit> maxb, rubbs: So I'm trying to figure out the best way to do that, shared repo's seem promosing but I'm still learning.
[15:48] <rubbs> LP uses stacked branches IIRC.
[15:49] <maxb> jam: work? what work? dget python-testtools/sid; for i in hardy jaunty karmic lucid; do bzrppa-backport -s -u bzr/proposed -D $i *.dsc; done
[15:49] <maxb> I really need to stick my handy scripts somewhere :-)
[15:49] <kpettit> rubbs: that sounds like the right way to go.  I've just setup some test for it so I'm going to play around and see if ti works like I'm expecting.
[15:50] <maxb> kpettit: the thing you need to understand is that shared repositories are merely a disk space / network io optimization. They don't affect the design of your workflow, really
[15:51] <kpettit> got ya.  But I can merge from a parent repository to a child one and not overwrite or mess up and files that child has that the parent doesn't?
[15:51] <rubbs> kpettit: what maxb just said, also adding that each branch will still be insular, by which I mean that even though you will be storing revisions in the same place, it will not automatically add revisions to branches you don't want them in
[15:52] <rubbs> kpettit: I think you're confusing branches and repositories.
[15:52] <kpettit> I might be
[15:52] <kpettit> <-- new at this
[15:52] <rubbs> branches are just an "order of revisions" in a sort of way. repos are just a place where revisions are stored.
[15:52] <maxb> repository == an on disk store of revisions, nothing more. branch == a pointer to a revision that is tip of the branch (and implicitly all its ancestors)
[15:53] <rubbs> by default (stand alone branch without a shared repo) a branch is it's own repository because the only revisions needed in that repo are the same as the ones on the branch.
[15:53] <rubbs> in a shared repository, you can have many different branches.
[15:53] <rubbs> revisions that are the same between branches are not duplicated.
[15:53] <maxb> s/ a branch is it's own repository / both branch and repository are co-located in the same .bzr directory /
[15:54] <rubbs> so if branch A has revisions 1,2,3 and branch B has 1,2,4 the shared repo will contain 1,2,3,4
[15:54] <rubbs> thanks for that clarification maxb
[15:55] <maxb> For clarity's sake, it's best to use a,b,c as placeholder names for revisions, since the integers can be confused with bzr revnos
[15:56] <rubbs> ah, I will do that in the future
[15:57] <kpettit> so if my child directories I want them to all keep a up to date copy of main set of code.  but I need them to have files that will never be in the main set of code and keep version info.  So if my parent is a "repository" are my childs of this branches or other repositories sense they will never commit back to the parent?
[16:05] <rubbs> best to think about repos as a bin to store all revisions in it. Each branch is just a list of revisions and their order. So in your case, you would make a shared repo, then put your "trunk" or "main" in it. Then you would make a branch, also in the same repo, for customerA.
[16:06] <rubbs> then when you wanted to get changes from the trunk into customerA you just do a "bzr merge trunk" while inside the customerA branch.
[16:06] <kpettit> got ya.  that's what I'm trying now.  thanks
[16:06] <rubbs> This will pull changes from trunk in, but will NOT put changes from customerA into trunk.
[16:07] <rbriggsatuiowa> is there anyway to pass a plugin directory to bzr?
[16:09] <vila> rbriggsatuiowa: there are several even :) see 'bzr help env-variables'
[16:10] <vila> rbriggsatuiowa: depending on your need you will use BZR_PLUGIN_PATH or BZR_PLUGINS_AT
[16:13] <rbriggsatuiowa> vila: bawesome - thanks
[16:21] <rubbs> is there any way to make a stacked-repo? By which I mean, if I want to have the trunk with read only permissions, can I create a shared repo for each user that is stacked off that main trunk?
[16:21] <rubbs> I'm looking for a roll your own poormans LP basically
[16:26] <jam> rubbs: stacking is done at the 'branch' level, not the repo level
[16:26] <jml> I'm trying to use pipelines to split up a big branch that I've already done a fair bit of work on.
[16:26] <jam> you *can* set up a default stacking policy
[16:26] <jml> never really used pipes in anger before
[16:27] <rubbs> jam: is there any docs on how to do that?
[16:27] <jam> jml: This is how I did it with regular branches, you could probably do something similar w/ pipelines
[16:27] <jam> http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
[16:27] <jam> I've never used bzr-pipeline myself
[16:27] <jml> I guess if this were a loom, I'd make a trunk thread...
[16:28] <jml> jam: thanks.
[16:28] <jam> rubbs: not that I specifically know of, but I'm poking around looking now
[16:28] <jam> jml: the key is abuse of 'bzr revert' and 'bzr merge' to maintain history, while still splitting out the content into simplified diffs
[16:29] <rubbs> jam: thanks, I'll keep an eye out for it too. I'm currently re-digesting the official docs
[16:29] <jml> jam: :)
[16:29] <vila> pfew, backups are a blessing...
[16:29] <jam> rubbs: the file is .bzr/control.conf
[16:29] <rubbs> jam: ah thanks. I'll take a look at it
[16:30] <jam> you can set 'default_stack_on = ...'
[16:30] <rubbs> is this per client? or on the server side
[16:30] <jam> rubbs: on the server side
[16:30] <rubbs> perfect. Thank you.
[16:31] <jam> basically, when creating a new branch we look up for a containing repo or just a .bzr directory
[16:31] <jam> if we find one with that set, then we'll create a stacked branch
[16:31] <jam> you probably could create shared repos for each user
[16:31] <jam> and just put "echo ../central-repo > .bzr/control.conf"
[16:31] <jam> obviously, you'll want to test it :)
[16:31] <jam> for the full commands:
[16:32] <rubbs> right. I have no intentions of putting this in place without some testing ;)
[16:32] <jam> bzr init-repo --no-trees central; bzr init-repo --no-trees user1; echo "../central" > user1/.bzr/control.conf
[16:32] <jam> although... I think a branch has to be stacked on another branch
[16:32] <jam> so probably
[16:32] <jam> echo "../central/trunk"
[16:33] <rubbs> great thanks, I'm copying that out for reference thank you.
[16:33] <jam> though you may also be able to do:
[16:33] <jam> echo -e "default_stack_on = ../central/trunk\ndefault_stack_on:policy=appendpath" depending on how you would use it
[16:34] <rubbs> sounds good. I have some reading to do now ;)
[16:39] <jam> rubbs: I don't know about a lot of reading, vs just experimenting :)
[16:40] <rubbs> haha, true. I'm looking into several things at once. Trying to build up a migration plan. I still have to teach all the devs how to use bzr as well, so i'm reading all the docs so I can try to choose the best workflow to teach to them.
[16:40] <rubbs> I was told not to give them too many choices on workflows or they are going to run into trouble
[16:41] <jam> rubbs: good advice
[16:41] <jam> One thing you can do is start of with the most simplistic model
[16:41] <jam> and they can adapt to something better as they are able
[16:41] <jam> I certainly have *my* preferred model, though
[16:42] <rubbs> right. I was thinking a happy medium between function and ease is bound branches, with their own server space. That way I can back it all up easy and they can have local stuff if needed.
[16:43] <rubbs> and I can help them along if they have any "customizations" to their workflow
[16:43] <vila> windows hates me, I swear, it's not the opposite
[16:43] <rubbs> I'm in the weird position of going from dev to sysadmin, so I actually know bzr from the dev side fairly well. It's all this being a repo admin that's new to me. ;)
[16:44] <jam> rubbs: :), we'll try to ease your pain
[16:44] <jam> vila: I still love you
[16:44] <jam> what's going on with the XP vm?
[16:45] <jam> bbiab
[16:45] <vila> jam: no idea, I restored a first backup (known to work), it was broken too, then I went for an older one and it works
[16:45] <vila> now, there was a vbox upgrade since then and at least one windows upgrade
[16:46] <vila> but failing to login makes it hard to debug anything :-/
[16:46] <vila> so I upgraded the vbox extensions on the older backup and I will cross my fingers when the xp update triggers...
[16:47] <jml> "bzr add-pipe --before foo" seems to make "foo" equivalent to the parent branch
[16:51] <jml> is "bzr merge -i" different from "bzr merge; bzr shelve" in any way other than negating the "y/n" choice?
[16:53] <vila> jml: that would greatly simplify the implementation :-P
[16:53] <vila> jml: sorry, no idea
[16:55] <jml> vila, ok. related question: how can I tell if the thing I'm about to commit looks like a merge to bzr?
[16:56] <vila> bzr st will mention pending merges
[16:57] <jml> vila, thanks :)
[16:57] <jml> so the answer is "yes"
[16:57] <jml> "bzr merge -i" forgets the merge
[16:57] <vila> 8-(
[16:58] <vila> oh, because it becomes a cherrypick probably
[16:58] <jml> yeah.
[16:59] <vila> jml: you're rewriting a too-big patch ?
[16:59] <jml> vila, indeed I am.
[16:59] <vila> I wish we had better tools for that...
[16:59] <jml> vila, not as much as I do right now :)
[17:00] <vila> jml: almost, I was finishing one yesterday (from a branch to a loom but interrupted during 3 weeks)
[17:00] <vila> the most annoying bit is that I always find a better way while rewriting those losing a base to compare...
[17:01] <vila> not that I can imagine tools to help here...
[17:01] <vila> jml: in the end, one command I often use anyway is: 'bzr merge --preview <old_result>'
[17:02] <vila> which set submit_branch in branch.conf unfortunately...
[17:14] <jml> I wish I knew how to stop receiving bzr review mail.
[17:21] <mgz> hey vila, do you have a branch up anywhere with all your leak bits that I can test locally?
[17:24] <vila> mgz: oh, I have several, I just put them up for review :)
[17:25] <mgz> I saw that, just wondering if for-babune or similar still has them all rolled up in one branch
[17:25] <vila> mgz: but lp:~vila/bzr/leaking-tests should contain everything
[17:25] <mgz> ta.
[17:26] <jam> jml: you're probably subscribed to the bzr.dev branch directly?
[17:26] <vila> mgz: there may still be some rough edges, but I'd like to get them landed first as they have been sitting there for far too long
[17:26] <jml> jam: no, not directly
[17:27] <jam> jml: are you in the bzr-core team?
[17:27] <jml> jam: I'm a member of bzr-core via canonical-bazaar
[17:27] <jml> jam: I wish to remain a member of canonical-bazaar.
[17:30] <jam> jml: then figure out how to design launchpad subscriptions so you can explicitly opt-out of stuff, I would like that ability myself :)
[17:30] <jam> or just set up your >/dev/null procmail filter
[17:30] <mgz> can you filter based on the message at the end?
[17:31] <mgz> I think merge proposals have that right, though bugs don't
[17:31] <jam> mgz: there are some launchpad specific headers you are supposed to use, but I haven't really figured them out
[17:31] <jam> like:
[17:31] <jam> X-Launchpad-Message-Rationale: Reviewer
[17:31] <jam> X-Launchpad-Project: bzr
[17:31] <mgz> yup, same mechanism.
[17:31] <jam> X-Launchpad-Notification-Type: code-review
[17:31] <jam> but there isn't one defining the *target* of the merge, which is weird
[17:32] <mgz> gmail just doesn't let me filter on anything but a few common headers
[17:32] <jam> it also doesn't tell you that "you are requested to review" because the group you are in was requested
[17:32] <jam> versus a direct request of me
[17:32] <jam> which is something I should file a bug on
[17:32] <mgz> ah, that's like the bugs bug then.
[17:32] <SpamapS> Somebody needs to extend IMAP to allow server side filters to be managed directly through IMAP.
[17:32] <jam> SpamapS: sieveshell
[17:33] <jml> fwiw, we're doing this atm: https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications
[17:33] <jam> from the Cyrus suite
[17:33] <mgz> the bugs header doesn't tell you if you're directly subscribed to the bug if you're a member of a group that'd get email anyway
[17:33] <SpamapS> there are tons of web interfaces
[17:33] <SpamapS> But its hard to get imap admins to enable them. ;)
[17:34] <mgz> merge proposals at least say something different when it's my merge proposal or one I'm reviewing
[17:34]  * SpamapS puts it on his todo list for crazy ideas. :)
[17:35] <jml> jam: btw, thanks for the heads up re testtools tags.
[17:36] <jam> jml: np, I was trying to figure out what versions I had from 'bzr log'
[17:36] <jml> jam: I hate having to reinvent release procedures for every single project :\
[17:37] <jam> jml: well, there are some common pieces. I know 'bzr-builddeb' hooks into the tag code so that "bzr tag" can take a default tag name of the last entry in debian/changelog
[17:37] <jam> It would be interesting to have a "bzr release" function, but so often there is a lot more than just 'export + tag"
[17:37] <jam> (changing the version strings, etc, etc)
[17:37] <jml> hooks, perhaps
[17:38] <jam> jml: yeah, there have certainly been hooks requested for 'bzr export'
[17:38] <jml> Twisted has a change-versions script used for its release
[17:38] <jml> (as well as build-news, which takes file-per-news-entry and turns it into an actual news file)
[17:39] <jml> I also never know which revision to tag.
[17:41] <jam> jml: approximate is better than nothing :)
[17:42] <jml> yeah, I know.
[17:42] <jml> but uncertainty is a paralytic.
[17:44] <jam> losa ping (about pqm)
[17:45] <jml> how do you undo "bzr tag"
[17:45] <mthaddon> jam: hi
[17:45] <jam> mthaddon: hey, I submitted some stuff to pqm yesterday, which should have failed, but I didn't get a failure email
[17:45] <dash> jml: bzr tag --delete?
[17:45] <jam> I can submit it again today, but I figured I'd try to figure out what went wrong first
[17:46] <jam> dash: yeah, but --delete doesn't propagate well now
[17:46] <jam> (for now)
[17:46] <jml> dash, thanks. I was looking for "untag"
[17:46] <bigjools> heh, bzr tag help didn't do what I expected :)
[17:46] <mthaddon> jam: but it didn't succeed either? what time?
[17:46] <jam> mthaddon: yesterday about 5 hours from now
[17:46] <jam> ~2200 utc
[17:49] <mthaddon> it's a little hard to tell - there's one at 21:39, one at 22:36
[17:49] <jam> mthaddon: the latter one is the one I care about
[17:49] <mthaddon> jam: https://pastebin.canonical.com/36209/
[17:50] <kpettit> I'm wanting to make bzr our standard VCS, but I have some .NET developers that use VisualStudio.  Are there any plugins and such that work with VisualStudio?  There was one on the 3rdParty page but it says discontinued and it's for a older version.
[17:50] <jam> mthaddon: I see some warnings, but no real indications of anything, can you try the other?
[17:51] <mthaddon> jam: https://pastebin.canonical.com/36210/
[17:51] <jam> mthaddon: well, that does help: smtplib.SMTPSenderRefused: (552, '5.3.4 Message size exceeds fixed limit'<EMAIL_ADDRESS>[17:52] <jam> though I don't know how to make it smaller...
[17:53] <jam> mthaddon: ok, I'm submitting again now. Is there any way to grab the content of the output email in case it fails again?
[17:53] <jam> (I think my smtp host restricts to <10MB, but that should be plenty for these emails)
[17:53] <mthaddon> only way would be to send it to a logfile instead of emailing it
[17:54] <mthaddon> but I think that's something PQM is doing rather than the cronjob that calls PQM if I recall correctly
[18:21] <rubbs> kpettit: not that I know of, I'm looking for something like that too
[18:21] <kpettit> rubbs: I'll let you know if I find anything.  Gotta make the Windows guys happy :)
[18:22] <rubbs> kpettit: ditto ;)
[18:48] <kpettit> I'm happy with my bzr setup now and moved it to a production server.  The branches work, but the share repository seems to cause issue.
[18:48] <kpettit> When I go to base directory and do bzr status I get "No Working Tree" and it's looking for a .bzr/checkout
[18:49] <kpettit> I can go to the individual branches and bzr status works fine there.  Not sure what to do, the origional one I copied from still works fine
[18:49] <beuno> kpettit, the shared repo does not have a working tree
[18:49] <beuno> status is for working trees
[18:50] <kpettit> ah ok.
[18:50] <kpettit> sorry
[18:52] <beuno> no need to apologize  :)
[18:52] <beuno> you can use "bzr info" if you want to be assured everything is fine
[18:53] <kpettit> ah wonderful.  thanks.  Just wanted to get my "it's ok" from it
[18:53] <kpettit> trying to see if trac works with it now
[18:57] <kpettit> woo hoo trac was cake to setup.  love it
[20:34] <yann2> hi
[20:37] <maxb> hi
[20:39] <yann2> is using paths like bzr+ssh supposed to work with bazaar explorer on windows? it seems to get very confused about it, works for some things, but sometimes it tries c:/bzr+ssh:// etc and fails
[20:46]  * maxb knows nothing about windows
[20:49] <maxb> james_w: Hi. lp:bzr-builder contains a plugins/builder symlink actually in the branch. Is it something you particularly want there? Because it confuses bzr multi-pull horribly.
[21:29] <james_w> maxb: it can go away once we can use BZR_PLUGINS_AT to run the tests. mutli-pull should be fixed as well of course :-)
[22:30] <Kaspi> hello
[22:52] <Kaspi> is there a way of using bazaar as subversion for beginers? I don't understand why I need to "commit" and then "send" or "push" or "merge" to make changes in the central branch for each dev
[22:53] <Kaspi> i was following this tutorial: http://doc.bazaar.canonical.com/bzr.2.1/en/mini-tutorial/index.html but I got really confused after getting several errors
[22:55] <Kaspi> why the "commit" doesn't really commit changes?
[23:00] <maxb> Commit does commit changes
[23:01] <maxb> I suggest you move up from the mini-tutorial to the full tutorial, and especially read the "How DVCS is different" section
[23:02] <jelmer> 'morning maxb
[23:02] <maxb> evening here :-)
[23:02] <jelmer> oh, here as well actually :-)
[23:02] <jelmer> maxb, Whereabouts are you based?
[23:03] <maxb> London
[23:03] <jelmer> I thought you were in Australasia for some reason.
[23:03] <maxb> haha, no
[23:03] <maxb> I love my ridiculously low ping time to launchpad :-)
[23:03] <maxb> ~ 5 ms
[23:09] <sttng359> hello
[23:10] <sttng359> I am having issues with files loosing their symlink status after certain operations
[23:10] <sttng359> This branch was imported originally with bzr-svn
[23:11] <sttng359> When I first did my checkout from svn, the files were symlinks
[23:11] <sttng359> I think did a remove-tree, and cloned the branch within a shared repo for actual work.
[23:12] <sttng359> I have since noticed that those symlinks are now zero-length files
[23:12] <sttng359> I did a checkout of the original branch and they are zero-lenth files as well.
[23:14] <maxb> This sounds nigh-impossible to debug unless there's a way someone can reproduce the failure mode locally... is the svn public?
[23:15] <sttng359> maxb: no, but I can create a public svn repo for testing
[23:16] <maxb> I guess we should first eliminate the obvious... there's no possibility of a filesystem that does not support symlinks being involved?
[23:18] <sttng359> nope, only a local Ext3 filesystem.
[23:18] <maxb> hmm
[23:18] <sttng359> This time I even used a file:// URL for subversion instead of https://
[23:19] <sttng359> is there a possibility bzr-svn is creating a symlink, but not marking it as a symlink in the repo?
[23:19] <maxb> jelmer: still around?
[23:19] <jelmer> sttng359, yes, there has been a bug like that in older versions of bzr-svn
[23:20] <jelmer> sttng359, but in that case the issue would turn up in the original import
[23:21]  * maxb is attempting to comprehend the purpose of loom's record command.... is it just so the overall loom state can be pushed and pulled?
[23:25] <Kaspi> maxb: hmm a better one
[23:27] <sttng359> jelmer: is bzr-svn-1.0.2 too old by any chance?
[23:27] <jelmer> sttng359, don't know, sorry
[23:27] <maxb> 1.0.3 is out, you might as well use it
[23:27] <sttng359> is there any difference between using co and a svn+https:// or file:// URL vs. svn-import?
[23:28] <jelmer> sttng359: I *think* it should be new enough
[23:28] <jelmer> sttng359, no, that doesn't matter
[23:28] <sttng359> It's only 1 version old
[23:28] <maxb> the difference between co and svn-import is whether you get one branch or all of them
[23:30] <Kaspi> maxb: is possible that bzr would "remember" password to a FTP or SFTP location?
[23:31] <maxb> Try this: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html
[23:31] <maxb> Basically you write the user and password into ~/.bazaar/authentication.conf
[23:33] <Kaspi> maxb: yeah.. thank you
[23:35] <yann2> are there any nice web frontends to bazaar, that allow to browse versions and diffs - and if possible do not require a db?
[23:35] <maxb> there is loggerhead, which is what you see on launchpad.net
[23:36] <maxb> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes
[23:37] <yann2> any demo somewhere?
[23:37] <maxb> the url I just gave
[23:37] <yann2> oh right :)
[23:37] <yann2> I'll give it a try thanks
[23:38] <maxb> I have yet to find a *good* web interface for browsing a collection of multiple bzr branches
[23:39] <thumper> jam: ping
[23:39] <yann2> this one does only one branch? I'll see what I can do
[23:39] <yann2> fairly new to VCS and am trying to set a whole dev system up :)
[23:42] <jam> thumper: I'm not really around now, I expect to go at any time for family stuff, but if its quick I'll help :)
[23:42] <thumper> jam: can I get you to email me tomorrow morning your time about the branch revision work that you started and where it is at now?
[23:44] <jam> thumper: basically hasn't progressed anywhere. We got the BranchRevision object to be Stormified (so that you can use a multi-column primary key), but haven't tracked that through into actually removing the columns
[23:45] <jam> also, I haven't done the sit-and-think-about-it to get something like bzr-history-db for your use cases
[23:45] <jam> most of which want a fast revision_id => branches mapping
[23:45] <jam> which isn't what bzr-history-db is about (yet)
[23:46]  * thumper nods
[23:47] <sttng359> ok, I think I have a better idea what's going on here.
[23:47] <sttng359> Not all symlinks are being reset in bazaar, only those with a bad history.
[23:49] <sttng359> TortoiseSVN on Windows does not deal with symlinks properly, instead it creates a text file with the contents of the link, and on check-in, drops the svn:special property, even if that file was not modified.
[23:49] <sttng359> A user in the past did a checkout of a portion of the tree and later a commit.
[23:50] <sttng359> I since had to delete those symlinks and re-add them as symlinks.
[23:50] <sttng359> Other symlinks outside of the portion that the Windows user checked out are still symlinks.


[15:38] <desrt> smspilla|z: ping
[15:42] <desrt> smspilla|z: i'm on my biannual gconf-kill
[15:42] <desrt> smspilla|z: any idea why compiz-gnome is still having a gconf depend?  according to seb the gsettings already landed


[09:41] <tomwardill> "failed shell_8 "
[09:41] <tomwardill> progress!
[10:58]  * tomwardill -> lunch and afk for errands
[11:53] <tomwardill> Did not anticipate quite such a queue.
[14:00] <tomwardill> wow, the LXC cli experience is ... something
[14:16] <tomwardill> perhaps unsuprisingly, there are no available guides for 'lxc in lxd'


[04:06] <Logan_> IdleOne: Thanks for that !classic factoid -  very helpful.
[04:21] <IdleOne> Logan_: welcome, it was suggested by a user.
[05:58] <MagicFab> howdy
[05:58] <MagicFab> just a quick note to inform anyone interested, I just registered #ubuntu-ht (Haiti)
[05:58] <MagicFab> cheers from Grand Goâve :)
[06:03] <IdleOne> He did a little more then that. MagicFab is currently in Haiti setting up a school with Ubuntu on donated computers.
[06:03] <IdleOne> https://picasaweb.google.com/magicfab/HaitiAvril2011#5601078711053429762
[06:03] <IdleOne> https://wiki.ubuntu.com/HaitianTeam
[06:08] <IdleOne> pleia2: sorry bout the ping but I just wanted to make sure you saw this. I thought it was Ubuntu news worthy ;)
[06:58] <m4v> that's so awesome
[07:08] <Logan_> agreed.


[19:43] <Soni> when should one add a system user?
[22:35] <teward> Soni: only if you're adding a user that has no user interface or interaction and pretty much is only used for a system service
[22:36] <tomreyn> Soni: most of the time for daemons / services / things not run by a human user
[22:36] <teward> ^^
[22:36] <Soni> ah, so something that should only exist in the context of systemd units = system user
[22:36] <teward> tomreyn: you and I both must be alive at the same hours lol
[22:36] <tomreyn> hehe
[22:36] <Soni> something we'll ssh into = non-system user?
[22:36] <teward> Soni: pretty much yes
[22:36] <teward> Soni: anything you SSH into is just a standard user
[22:36] <tomreyn> that was another funny coincident, teward
[22:36] <Soni> okay, that makes it easier
[22:37] <Soni> thanks!
[22:37] <teward> Soni: 'system' class of users should be reserved soluely for daemons and services and things that don't get human interaction
[22:37] <teward> yep
[22:37] <teward> case in point we have a custom listserv system at a job.  It operates on a SystemD timer under a system user called 'threader'
[22:37] <teward> said 'threader' is existing for the program base and execution of it.  Thank you SystemD :P
[22:42] <teward> but that's a system user, no login shell, etc.
[22:42] <teward> :)
[22:42] <teward> Soni: glad that made it easier to understand, sorry about the delay of getting you a reply
[22:42] <teward> (weekends are pretty dead xD)
[22:42] <teward> tomreyn: you sure about that?  :P
[22:48] <tomreyn> teward: if it wasn't a coincident, i must have been sitting just next to my enter key, watching the channel patiently for someone to respond, finally allowing me to send that pre-composed message.
[22:48] <teward> lol
[22:49] <tomreyn> you might characterize me as a little weird, but not that much. ;-)
[22:49] <teward> in terms of 'weird' i'm pretty high up on that scale :P
[22:49] <teward> so i mean
[22:49] <tomreyn> or maybe we're really just one person with two identities.
[22:50] <tomreyn> anyways, it was good chatting to the other side for a while. ;-)
[23:08] <teward> lol
[23:08] <teward> tomreyn: well i am in the shadows 24/7/365 so yeah 'the other side' xD
[23:08] <teward> in either case, alls good :)


[00:11] <yosefu> hi
[00:12] <yosefu> would you mind if i ask a few questions about sound settings?
[00:50] <stochastic> hey yosefu, what questions did you have?
[00:50] <yosefu> wow that's so nice!
[00:51] <yosefu> i was trying to get my sound back in 11.10
[00:51] <yosefu> aplay -l doesn't find any soundcard
[00:51] <stochastic> hmm, I don't know where to begin helping you on that problem
[00:51] <stochastic> do you know what your soundcard is?
[00:52] <yosefu> lshw -C multimedia gives me two
[00:52] <yosefu>   product: Manhattan HDMI Audio [Mobility Radeon HD 5000 Series]
[00:52] <yosefu>        vendor: ATI Technologies Inc
[00:53] <yosefu> product: 5 Series/3400 Series Chipset High Definition Audio
[00:53] <yosefu>        vendor: Intel Corporation
[00:54] <stochastic> okay so you're trying to get your onboard audio working again?  was it ever working?
[00:55] <yosefu> after installing
[00:55] <yosefu> however i did some tweak to get a midi keyboard working with zynaddsubfx
[00:56] <yosefu> and to get jack working, and so on... i might have messed it all
[00:56] <stochastic> hmm
[00:56] <yosefu> also tried an alsa upgrade script
[00:57] <stochastic> ohh, that could cause major troubles
[00:57] <yosefu> i guess
[00:58] <yosefu> maybe i should reinstall alsa from scratch
[00:59] <yosefu> or is there a way to restore the settings that come with the install?
[00:59]  * stochastic really doesn't have an answer for those questions
[01:01] <yosefu> :(
[01:02] <yosefu> where would you ask?
[01:06] <stochastic> maybe in #ubuntu
[01:06] <stochastic> maybe poke holstein and ask him
[01:06] <yosefu> wouldn't that annoy him?
[01:11] <stochastic> well I just did by typing his name directly, so you can leave your chat client open and wait for him to come back
[01:14] <yosefu> :)
[02:30] <virtu> hey holstein, how are you?
[03:09] <pitchoilcan> ITM
[03:28] <holstein> :/
[03:28] <holstein> i missed virtu
[03:29] <holstein> and yosefu


[14:07] <cmaloney> morning
[14:08] <Zimdale> Morning
[14:25] <cmaloney> 1001001
[14:27] <mrgoodcat> 73?
[14:35] <cmaloney> mrgoodcat: Yeah,
[18:20] <cmaloney> Good afternoon and all that.
[18:20] <cmaloney> It's 14:20
[18:50] <cmaloney> http://arstechnica.com/tech-policy/2016/05/suns-jonathan-schwartz-at-trial-java-was-free-android-had-no-licensing-problem/
[18:55] <mrgoodcat> my alexa came in today
[18:55] <cmaloney> nice!
[18:55] <cmaloney> I expect a fully dictated blog post on it by 5pm
[18:57] <mrgoodcat> haha
[18:57] <mrgoodcat> i wonder if i can dictate blog posts on it....
[19:05] <cmaloney> Man I <3 Jonathan Schwartz
[19:05] <cmaloney> Even if he pretty much handed the keys to Sun to Oracle he's still a class act
[19:08] <jrwren> really?
[19:08] <jrwren> I thought he was a jerk.
[19:29] <cmaloney> how so?
[19:52] <jrwren> he ran sun into the ground.
[19:53] <jrwren> sun was pretty evil with java even before teh oracle acquisition
[19:53] <jrwren> I probably don't know what I'm talking about.
[19:56] <cmaloney> jrwren: I don't think anything could have saved Sun at that point
[19:57] <cmaloney> Linux took over the cheap servers
[19:57] <cmaloney> Java was not something that could be monetized
[19:57] <cmaloney> Sun's market was middle-tier servers and that market was evaporating
[19:58] <cmaloney> That and the dot-com boom was pretty much done
[19:58] <cmaloney> so they got disrupted on several fronts
[19:58] <cmaloney> and then the recession happened
[19:59] <jrwren> hrm. could be.
[20:00] <jrwren> it had already happened and nothing could be done?
[20:00] <jrwren> still, seems like they could have done better seeing it coming, moving into something else, etc.
[20:00] <jrwren> Those T1000, T2000 servers were damned sweet.
[20:00] <cmaloney> I'm not sure you can point to one thing and say "This is where he fucked up, and here's what they could have fixed"
[20:00] <jrwren> still have more cores than most intel chips, and that was 10yrs ago!
[20:00] <cmaloney> BFD
[20:00] <jrwren> I can ;]
[20:00] <cmaloney> cores schmores.
[20:00] <jrwren> They sued MSFT. That was a mistake.
[20:01] <cmaloney> They won vs. MS
[20:01] <jrwren> Actually... I take it back, suing them was not a mistake.
[20:01] <jrwren> right.
[20:01] <cmaloney> and then MS created .NET
[20:01] <jrwren> and then MSFT... exactly
[20:01] <jrwren> they should have forced MSFT to give them their extensions and put them into Java 1.3
[20:01] <jrwren> but they didn't, cuz they are stupid.
[20:01] <cmaloney> That was a mistake
[20:01] <cmaloney> but it was also Gates /Ballmer era MSFT
[20:02] <cmaloney> so unlikely they would have cooperated
[20:02] <jrwren> yup
[20:02] <jrwren> still, they saw the changes, they could have implemented them themselves.
[20:02] <cmaloney> They'd sooner nuke the earth than cooperate
[20:02] <jrwren> and java would have been better for it.
[20:02] <cmaloney> True
[20:04] <cmaloney> Thing is Oracle is a more aggressive company
[20:04] <cmaloney> and has a "killer app" product
[20:04] <jrwren> yup
[20:04] <jrwren> its terrible.
[20:04] <jrwren> its sad.
[20:04] <cmaloney> Sun didn't have that
[20:04] <jrwren> i only want a better world.
[20:04] <cmaloney> Oh no doubt
[20:04] <jrwren> I think i was confusing Schwartz and McNealy
[20:04] <cmaloney> mcNealy was a jerk
[20:04] <jrwren> its McNealy and Barksdale who I find reprehensible
[20:05] <cmaloney> Schwartz was a nice guy
[20:05] <cmaloney> unfortunately he was a nice guy that got stood up to take the fall
[20:05] <cmaloney> but he's also a smart person
[20:06] <cmaloney> and the whole Oracle thing being blamed on him is (I think) not entirely accurate
[20:06] <cmaloney> The only saving grace is Sun had open licenses on the good bits
[20:07] <cmaloney> Virtualbox, OpenOffice, and  MySQL (yeah even MySQL)
[20:07] <jrwren> just how open, we shall see.
[20:07] <cmaloney> Jonathan's testimony is gold
[20:07] <jrwren> I saw your link. I didn't click.
[20:07] <cmaloney> Basically "Google was well within their rights. Oracle has no case"
[20:08] <cmaloney> Sun would have liked to work more closely with Google, but it didn't pan out
[20:08] <cmaloney> also: for a CEO he knew his shit.
[20:09] <cmaloney> I think Schwartz was not CEO material; more CIO material.
[20:09] <cmaloney> but I'm grateful that he was so loose with the licensing
[20:10] <cmaloney> in retrospect it's kind of like the Open Gaming License that Wizards of the Coast generated that made something like Paizo possible
[20:10] <cmaloney> (which was engineered by the people at Paizo who knew their days at WotC were numbered)
[20:16] <Scary_Guy> Oracle is a mistake, one gigantic mistake
[20:16] <cmaloney> dressed in a 3 piece suit with a grin and a firm handshake
[20:16] <Scary_Guy> "Oh Java, OpenOffice.Org, and MySQL are all free, let's start charging for those!"  Wooo, fragmentation!
[20:17] <cmaloney> I thought they had more trouble with outside contribution than charging
[20:17] <Scary_Guy> probably that too, but charging just pisses off GNU guys
[20:17] <cmaloney> Oh, other than the proprietary extensions to MySQL
[20:18] <cmaloney> https://www.reddit.com/r/linux/comments/2e2c1o/what_do_we_hate_oracle_for/
[20:18] <cmaloney> God bless Reddit for a breakdown of how to hate. ;)
[20:18] <Scary_Guy> you'd think it would be 8chan
[20:18] <cmaloney> That's just blind hate
[20:19] <Scary_Guy> true
[20:20] <Scary_Guy> also, fuck, how did I forget Solaris?
[20:21] <cmaloney> Everyone on non-Sun hardware forgot Solaris
[20:21] <Scary_Guy> good point
[20:21] <jrwren> i want to forget solaris
[20:21] <cmaloney> jrwren: Heh
[20:22] <cmaloney> Solaris was good when compared with HP-UX, OSF/1 AIX
[20:22] <cmaloney> insert and in there
[20:22] <Scary_Guy> that would be a fun 15 minute presentaiton: "Why Oracle sucks"
[20:22] <cmaloney> but that's like saying you're the nicest dressed person in hell
[20:25] <Scary_Guy> http://www.instructables.com/id/Raspberry-Pi-Water-Cooler/
[20:25] <jrwren> disagree.
[20:25] <jrwren> i prefered OSF/1
[20:30] <cmaloney> OSF/1 was decent. It had its moments
[20:31] <cmaloney> The version of UNIX that DEC had before OSF/1 was pretty terrible.
[20:31] <jrwren> ultrix
[20:31] <jrwren> yes, aweful
[20:31] <cmaloney> God
[20:31] <jrwren> then osf1 became tru64, which was actually very nice.
[20:31] <cmaloney> I purged that from memory
[20:31] <cmaloney> Only reason AIX isn't purged from memory is because
[20:31] <cmaloney> friends still use AIX
[20:32] <jrwren> the advfs in osf1, digitalunix and tru64 was like zfs or btrfs light.
[20:32] <jrwren> really nice.
[20:32] <cmaloney> Never got that far into it
[20:33] <jrwren> add a partition to a fs, fs instantly grows
[20:33] <jrwren> nothing to it.
[20:34] <cmaloney> Ah, nice.


[00:10] <Unit193> Pretty sure https://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/view/head:/slideshows/xubuntu/slides/02_support.html and https://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/view/head:/slideshows/xubuntu/slides/03_support-live.html need updated.
[09:39] <jphilips> I submitted the fix for the online docs in may https://github.com/Xubuntu/ubiquity-slideshow-xubuntu/pull/4
[09:39] <jphilips> fix for IRC was already merged https://github.com/Xubuntu/ubiquity-slideshow-xubuntu/pull/3
[09:49] <bluesabre> Technically, it's only half done. Since the slideshow code is owned by the ubuntu team, we have to submit a PR to the code Unit193 linked
[09:50] <bluesabre> I really just need to reach out and get added as a maintainer for that code
[09:50] <bluesabre> Otherwise, I think knome is the only one on the team that can push to it
[11:45] <knome> wut
[11:45] <knome> (:
[11:46] <knome> if you need changes to the slideshow, feel free to make merge requests on LP and assign me


[02:35] <pleia2> philipballew: not really re: phl
[02:59] <philipballew> pleia2, Nice! Thanks for the info though,
[03:00] <pleia2> it's also in the middle of nowhere, so not like you can wander around outside :)
[18:29] <MichaelPaoli> BerkeleyLUG - meeting starts soon - some of us have already arrived.  http://www.berkeleylug.com/
[18:29] <darthrobot`> Title: [Berkeley Linux Users Group]


[15:27] <OvenWerks> Eickmeyer: thank you for uploading controls...
[15:28] <Eickmeyer> OvenWerks: Quite welcome. :)
[15:29] <OvenWerks> Eickmeyer: if I can find a simple fix to the db problem that will come soon.
[15:29] <Eickmeyer> Sounds great. :)
[15:29] <OvenWerks> but I think it is going to be messy
[15:30] <Eickmeyer> Big changes are always messy.
[15:31]  * OvenWerks thinks he needs to create a controls or autojack lib
[15:31] <OvenWerks> I think there is some code that controls and autojack need to be able to share
[15:33] <Eickmeyer> Oh, probably. By the way, is there a way to start and stop jack from the command line? I'm thinking about writing a plasma widget that can do the basic start/restart and stop items right from the systray.
[15:33] <OvenWerks> Eickmeyer: you do not mean start and stop jack but tell autojack to do that?
[15:33] <Eickmeyer> Yeah.
[15:34] <Eickmeyer> Wouldn't be DE-agnostic, but it would be a start.
[15:34]  * OvenWerks gives a sigh of releif
[15:34] <Eickmeyer> haha
[15:34] <OvenWerks> there are two dbus commands
[15:35] <OvenWerks> hmmm and a rewrite of the config file to change JACK to true or false
[15:36] <Eickmeyer> That's easy.
[15:36] <OvenWerks> Yeah but I should change it so the config rewrite is not needed
[15:37] <OvenWerks> maybe not, the config rewrite is what makes the current state say over reboot
[15:37] <Eickmeyer> I was just about to say...
[15:37] <OvenWerks> I don't really want autojack doing that rewrite
[15:39] <Eickmeyer> Yeah. If there was a way of passing a command line to studio-controls itself to not launch a GUI but to do the dbus command, that would be amazing.
[15:39] <Eickmeyer> (and, of course, do the conf rewrite)
[15:39] <OvenWerks> There are really two ways to do this, have the systray applet send the signal controls normally would to autojack or have it send a signal to controls...
[15:40] <Eickmeyer> I think a signal to controls would be best, because then we're not having to reinvent the wheel.
[15:40] <OvenWerks> except controls may not be running
[15:40] <Eickmeyer> Right. Hence, a command-line parameter.
[15:41] <OvenWerks> really the thing to do would be like qjackctl where it keeps running but becomes the systray applet
[15:42] <OvenWerks> but that is not quick simple ;)
[15:43] <OvenWerks> Do you want this to be a part of controls or separate?
[15:43] <Eickmeyer> I was thinking separate. Something that just passes a command and sits in the plasma tray, therefore not taking up any additional resources.
[15:44] <Eickmeyer> Literally a plasma applet written in qml that basically acts as a plugin for Plasma.
[15:44] <Eickmeyer> See plasma-optimus. It's an applet I forked for Plasma to switch between NVIDIA and Intel graphics.
[15:45] <Eickmeyer> It simply sits there and runs a script, when called, but is not using additional resources because it runs as part of the plasma process.
[15:50] <OvenWerks> will that be written in pythom3?
[15:51] <OvenWerks> (changing the db is a python3 thing) anyway I am writing it to be cl
[15:51] <Eickmeyer> It would be written in qml.
[15:52] <Eickmeyer> Plasma does everything with qml.
[15:52]  * OvenWerks is not at all familiar with that
[15:52] <Eickmeyer> Well, that's where I come it.
[15:52] <Eickmeyer> *in
[15:52] <Eickmeyer> The only thing I'd need is a way to pass a command to studio-controls to do its thing. Not even an API, just a command-line parameter.
[15:53] <Eickmeyer> It can use bash in the backend to do that.
[15:54] <OvenWerks> I am writing a quick py3 utility right now. Controls sets up the GUI before it does anything else
[15:55] <OvenWerks> It would take more changes to controls to do the same
[15:58] <Eickmeyer> I see.
[16:52] <OvenWerks> Eickmeyer: Can I assume autojack has already been run? (That will at least create a config file of some sort)
[16:52] <Eickmeyer> OvenWerks: Yes.
[16:53] <OvenWerks> Eickmeyer: if this utility is run with no config file, it will error out (error 1)
[16:53] <Eickmeyer> Ah, good to know. Probably won't affect the applet.
[16:54] <Eickmeyer> I can catch the error though, and pop a dialog.
[16:54] <OvenWerks> Eickmeyer: I think that starting jack if studio_controls has never been run is probably not a good thing
[16:54] <Eickmeyer> Agreed.
[16:54] <OvenWerks> It will try to pick the best internal audio device it can find
[17:42] <OvenWerks> Eickmeyer: it would be possible to have autojack not create a config file on first run but fix an already created config so that controls would have to be run just to create a config
[17:42] <OvenWerks> Eickmeyer: but I thing that would be considered a new feature not a bugfix
[17:42] <Eickmeyer> That's correct, we'd have to backport not upload.
[17:43] <Eickmeyer> Unless it fixes something that's a little broken.
[17:45] <OvenWerks> Having a systray applet is already a new feature...
[17:45] <Eickmeyer> Yeah, that would have to be a backport.
[17:47] <OvenWerks> Eickmeyer: right now, autojack will not start jack untill controls runs anyway, so not broken. But if a systray applet goes around that and creates a problem, then this would be a fix to make the systray applet work.
[17:47] <Eickmeyer> Oh, pwedwxr.
[17:47] <Eickmeyer> *perfect
[17:47] <Eickmeyer> fingers on wrong keys. hehe
[19:01] <OvenWerks> And stack overflow goes paywall (sigh) No access without an account so we can sell your info.
[19:12] <Eickmeyer> Yikes. I hope askubuntu isn't affectdd.
[19:13] <Eickmeyer> *whew* it's not.
[19:34] <OvenWerks> Eickmeyer: http://www.ovenwerks.net/paste/controls-cl
[19:34] <OvenWerks> down load and make it executable if needed
[19:35] <OvenWerks> can be called with either start or stop as the only parmeter
[19:35] <Eickmeyer> OvenWerks: That look slike it should work for sure. I can't test it right now, but I'll try to after I'm done with work.
[19:38] <OvenWerks> Works here anyway
[19:41] <Eickmeyer> Sweet!
[19:45] <OvenWerks> When running Dolphin remotely (via latte-dock) it pops up dialogs on the local machine instead of the remote machine :P
[19:46] <OvenWerks> I think this is because all dolphine windows are the same process and so dialogs pop up on the display where it was first started
[22:18] <OvenWerks> Eickmeyer: the script I gave you can be translated to run native in qml
[22:20] <Eickmeyer> OvenWerks: Won't be necessary as qml just draws the frontend, defines the icon, and executes something when a button is pushed.
[22:20] <OvenWerks> ok
[22:20] <Eickmeyer> So, I'd just have it execute that script with an argument depending on what is pressed.


[05:25] <philipballew> Got someone from TJ coming to the Ubuntu hour here in San Diego by reaching out the the mx loco
[05:27] <philipballew> Were pretty much cross cultural now.
[23:27] <raevol> http://kb.mozillazine.org/Keyword.URL
[23:27] <darthrobot`> Title: [Keyword.URL - MozillaZine Knowledge Base]
[23:27] <raevol> omfg
[23:27] <raevol> if only i had known about this AGES ago
[23:27] <raevol> this is how you fix firefox sending your one-word searches to your DNS
[23:30] <akk> I've always set keyword.url, though I thought it only kicked in when you type two or more words.
[23:31] <akk> But when somewhere where the cable company intercepts DNS one-word queries, I also edit /etc/resolv.conf, make sure the cable company is out and replace it with <IP_ADDRESS> or whatever.
[23:31] <raevol> by default when i type two or more i get a google search, but when i only type one, it tries to take me to http://whatityped/
[23:31] <raevol> i see
[23:32] <akk> Hmm, yep, I go to google for a one-word keyword now too. I guess Mozilla changed that at some point.
[23:32] <akk> I guess I can try to unlearn the habit of typing [space]keyword when I only have one word to search for.
[23:34] <akk> I also need to go in and edit my jar files so I can middleclick-paste things that aren't a fully qualified url.
[23:36] <raevol> hehe
[23:43] <akk> They used to let you middleclick things like example.com/coolarticle.html but they disabled that a few years ago
[23:43] <akk> (too many people whining that they were middleclicking by accident, so do they make it configurable? nooo!)
[23:44] <raevol> hehe
[23:44] <raevol> i have an issue with my firefox at home taking like 30 seconds to load the first launch after a reboot
[23:44] <raevol> need to see if clearing my cache will fix it
[23:45] <akk> Firefox has always been super slow to start up for me.
[23:45] <raevol> 75 more minutes of work -_-
[23:45] <raevol> i fixed it once by "resetting" firefox
[23:45] <raevol> but that didn't work this time around
[23:45] <raevol> there's some command you can give it to clear out everything but your bookmarks basically
[23:46] <raevol> i'm learning unity keyboard shortcuts
[23:46] <raevol> so awesome
[23:46] <raevol> super+1-9 is amazing
[23:46] <akk> What does it do?
[23:47] <akk> Is super the windows key?
[23:47] <raevol> it's like pressing the icon in the launcher
[23:47] <raevol> yea
[23:47] <raevol> if you hold down super, it'll show you numbers on the launcher icons
[23:47] <raevol> then press the number to "click" that icon
[23:47] <akk> What I want is a way to use the HUD without having to run unity.
[23:47] <raevol> hud as in the Alt thing?
[23:48] <akk> I forget what key it is, but the thing that gives you keyboard access to menus in apps.
[23:48] <raevol> ah yea
[23:48] <raevol> i never use that :/
[23:49] <raevol> i always hated workspaces
[23:49] <akk> Wow, really?
[23:49] <raevol> but i've started using them on my work computer because i usually have a ton of stuff open on it
[23:49] <raevol> and i'm finding them really useful...
[23:49] <akk> I'd hate to compute without them.
[23:49] <raevol> well at home i usually don't have more than 2 windows open
[23:49] <akk> I don't have a lot, only 3 most of the time, but it's 1000% better than just one.
[23:49] <raevol> browser and something else, whatever it is
[23:50] <akk> I have my email/IRC space, my hacking space, and my browser space
[23:50] <akk> and if I'm running gimp, sometimes I'll make a fourth workspace for that if I'm working actively in the other three.
[23:50] <raevol> at work i have my browser, my virtualbox, my chat, and a fourth for random things, usually ssh