[00:08] <lifeless> back online in a bit
[01:18] <jml> lifeless: so, the work I've done on testresources is broken up into three branches, but I think it'll be easier for both of us if you just review the final branch.
[01:21] <jml> lifeless: https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup/+merge/767
[01:39] <nteon> does anyone know where the 'branch stacking' feature of 1.6 is documented?  I'm trying to figure out what it is
[01:40] <bob2> nteon: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches
[01:41] <nteon> bob2: ah, thanks!  google was not helpful for me in this situation
[01:47] <markh> heh - so I entered a bug report with my ISP for the proxy yesterday, and they just rang me to arrange to put my account on a proxy bypass :)
[02:10] <rextilleon> anyone here
[02:10] <jml> yes.
[02:10] <rextilleon> whats up
[02:10] <rextilleon> quiet around here
[02:11] <rextilleon> jml, is there a directory site that gives you a master list of irc locations
[02:24] <jml> beuno: is there a nice URL for viewing the latest revision of a file in loggerhead?
[04:37] <xshelf> Is there anyway to handle symbolic links on windows in bzr? Like, creating a hardlink if NTFS or creating a copy of the pointed file as fall back and prevent any operations to be committed into bzr on such files
[04:39] <xshelf> I have read this article: http://bazaar-vcs.org/WindowsSymlinkSupport?highlight=(symlinks)
[04:43] <markh> xshelf: not that I'm aware of - but bzr shouldn't break IIUC - only things that try to follow the links will :)
[04:52] <xshelf> I have a perforce folder tracked by bzr on gnu/linux, I wanted to clone it on wxp. It had a few symlink files and it failed
[04:53] <xshelf> I did the following: I did a 'p4 sync' on gnu/linux, 'bzr init' followed by 'bzr add' and 'bzr commit'. I copied the .bzr folder to wxp and did a 'bzr revert'
[04:58] <xshelf> i just read, mercurial handles symlinks on system with no support to symlink!
[06:19] <lifeless> xshelf: there is a plugin for bzr to do this
[06:20] <beuno> jml, you can use :head for the last revision
[06:21] <beuno> not sure about the path
[06:21] <beuno> (ue, not use the fileid)
[06:28] <xshelf> lifeless: which plugin is that, I need it please
[06:39] <lifeless> its called win32symlinks or something; its on the plugins page
[06:41] <xshelf> will look into it
[08:21] <arjenAU> lifeless: around?
[08:25] <lifeless> vaguely
[08:26] <arjenAU> lifeless: wa just trying to install the bzr-hg plugin and failing miserably
[08:26] <arjenAU> using the prescribed info
[08:26] <arjenAU> fastimport installs fine
[08:26] <xshelf> arjenAU: are you trying to import hg to bzr?
[08:27] <arjenAU> yea. for a gsoc project of a student of mine that needs to be public tonight
[08:27] <arjenAU> the hg repo is not public
[08:28] <xshelf> one dirty way: hg to svn
[08:28] <xshelf> svn to bzr
[08:28] <xshelf> or use tailor
[08:29] <lifeless> arjenAU: for one-shot conversions just use fastimport
[08:31] <arjenAU> lifeless: just did. works. the point was, I couldn't get your gizmo to even install.
[08:31] <arjenAU> which is probably my python incompetence, however fastimport did work
[08:33] <lifeless> arjenAU: bzr-hg is not complete at all
[08:33] <lifeless> arjenAU: but I do appreciate the feedback
[08:34] <arjenAU> hmm so fastimport makes me a master subdir... hmm
[08:43] <arjenAU> all is well, not just trying to understand launchpad for the rest
[08:44] <arjenAU> lifeless: ok. no worries!
[08:45] <arjenAU> lifeless: https://code.launchpad.net/sql-obfuscator whatever it says there, how to fix?
[08:46] <lifeless> FF is restarting for me
[08:46] <lifeless> I dunno what it says :)
[08:46] <arjenAU> I think I found it, needed to re-edit the project info. just checking now if that did it.
[08:46] <arjenAU> the branch (trunck) was not yetnoted as the dev focus for the project
[08:47] <arjenAU> A branch has not yet been specified as the primary development focus for SQL Obfuscator (set).
[08:47] <arjenAU> still says.... hmm
[08:47] <lifeless> click on set
[08:49] <arjenAU> hmm had to work out how the format worked in the set .... does it look ok now?
[08:55] <lifeless> dunno ;)
[08:55] <lifeless> let mepeek
[09:00] <lifeless> arjenAU: looks fine to me
[09:01] <robsta> hi
[09:01] <robsta> does `merge --pull' recognise whether the branches are in sync, except for the pulled changes?
[09:02] <arjenAU> lifeless: ye. once done once it's perfectly sensible. and it's oh so functional. was just trying to do this in a hurry while actually needing to do other stuff. tnx for your elp
[09:02] <arjenAU> +h
[09:05] <lifeless> robsta: it looks at the graph, not the content
[09:06] <robsta> graph == "chain of revision numbers", for noobs?
[09:07] <lifeless> directed acyclic graph of UUID
[09:07] <lifeless> which we show as a chain of numbers :)
[09:07] <robsta> the thing is, i'd only managed to "merge --pull" the other branch once, so i didn't have to commit myself
[09:08] <lifeless> merge --pull is a 'fast forward' in git terms
[09:08] <lifeless> if that helps
[09:08] <robsta> definitely not :P
[09:08] <lifeless> :)
[09:08] <robsta> does a pulling merge fall back to normal merge automatically when the branches are not in sync?
[09:08] <lifeless> its for when two people are 'sharing' a branch but they each have separate copies and no shared writable space
[09:08] <lifeless> yes
[09:09] <robsta> and there is no way to force pulling merge?
[09:09] <lifeless> pull --force?
[09:09] <lifeless> merge --pull is 'merge if you can't pull'
[09:10] <lifeless> got to go
[09:11] <robsta> thx, looks like that's what i want
[09:11] <robsta> to have the other author show up in the commit log
[09:12] <robsta> oh, there's commit --author too
[09:26] <xshelf> the win32symlinks plugin works, great!
[10:21] <EarthLion> hey, i have a directory under control. I then copied these files manually and started working on the files in their new directory. I want to place this under control but keep all the history of the revisions. I realise i should of started a new branch and then done a checkout. Is there anyway I can do this now?
[10:33] <bob2> what do you mean by "these files"?
[10:34] <awilkins> EarthLion_: Did you copy the folder recursively?
[10:34] <EarthLion_> yep
[10:34] <awilkins> Then it's already a bzr branch :-)
[10:34] <awilkins> Do a bzr info in it and see if you got the .bzr control dir
[10:34] <EarthLion_> ok (scratches head)
[10:35] <awilkins> Well, only if you copied the whole tree from the root
[10:48] <thumper> if I have shared repo with no trees, and I want to check out a branch from within the shared repo, how can I specify the hardlink location?
[10:48] <thumper> so I have a working tree called trunk
[10:48] <thumper> and a branch called foo
[10:48] <thumper> in branch foo I do a `bzr co --hardlink ???`
[10:49] <thumper> how do I specify trunk as the hardlink source?
[10:52] <lifeless> thumper: you can't today
[10:53] <lifeless> thumper: unless you have a checkout of trunk
[10:53] <lifeless> thumper: in which case just cp -al it and then switch :P
[10:59] <EarthLion_> awilkins: so dispite doing a recursive copy (it must of been because the directories are many levels deep, and the website still functions perfectly) but the .bazaar directory isn't there. a bzr info tells me that it isn't a branch
[10:59] <EarthLion_> so is there a way to just commit a directory to an existing branch?
[11:07] <lifeless> EarthLion_: make a new branch, copy the directory into the branch
[11:08] <EarthLion_> fair enough
[11:12] <EarthLion_> lifeless: and just replace/overwrite existing files?
[11:21] <siretart> beuno: FYI, I've uploaded a bzrtools 1.6.0 package for hardy to my PPA. it is based on jelmer's package for debian/experimental.
[12:01] <ignas> hi, where do I find out what was added to 1.6rc3 compared to 1.6rc2?
[12:01] <dato> the NEWS file does not say?
[12:03] <ignas> found it, thanks
[12:04] <ignas> do you know if anyone is going to fix the memory consumption problems in 1.6 series?
[12:05] <mwhudson_> which particular problems?
[12:05] <ignas> bzr upgrade
[12:06] <mwhudson> in any case, i don't think anything more is going to be fixed in 1.6
[12:06] <ignas> ouch :/
[12:06] <mwhudson> 1.7 is only about 3 weeks away tho
[12:07] <ignas> i guess I should start warning all of my colleagues to ignore the "your repository is too old, bzr upgrade it" warning
[12:07] <beuno> siretart, great! I'll copy over to the bzr PPA.  Thanks  :)
[12:08] <ignas> because that eats 1.5 Gb of ram quite reliably
[12:09] <mwhudson> ignas: :(
[12:09] <mwhudson> ignas: can you branch into a new repository instead?
[12:10] <mwhudson> at least you can probably do that in stages if you have to...
[12:12] <ignas> emm, that would be very painful
[12:12] <ignas> I would have to redo the central repository setup again
[12:13] <ignas> on a remote machine
[12:13] <ignas> and then hope that launchpad mirrors keep working, and no one commits to anything while i am switching
[12:13] <ignas> not even talking about the 20 branches in the shared repository on my machine :/
[12:15] <ignas> mwhudson: what kinds of manipulations are you performing with the code to explode from 70mb repository on disk into more than 1.5 Gb in memory
[12:15] <ignas> ?
[12:16] <ignas> well, 140mb repository
[12:16] <mwhudson> ignas: i don't know, and am not a bzr developer either :)
[12:20] <ignas> hmm, I wonder if python gives memory allocation information when profiling
[12:21] <ignas> bzr branch from my shared repository to the outside is taking 7 minutes already
[12:23] <ignas> mwhudson: ouch, I can't branch using 1.6rc3 too
[12:23] <ignas> at least not without running out of ram
[12:24] <fullermd> Well, to be sure, I wouldn't so much expect (branch into new format) to have memory usage or performance much different from (upgrade to new format)...
[12:25]  * ignas is thinking that migrating to git might be faster than waiting for 3 weeks to be able to create new branches :/
[12:25] <ignas> I wonder how will launchpad migrate my branches to the new format... maybe branching from a remote repository will work out better ...
[12:26] <mwhudson> ignas: you can probably bzr pull -r 100
[12:26] <mwhudson> then bzr pull -r 200
[12:26] <mwhudson> etc
[12:26] <ignas> up to 6000?
[12:26] <mwhudson> ignas: is there a bug on lp?
[12:26] <ignas> ok 4000
[12:26] <ignas> for upgrade - yes
[12:27] <mwhudson> ignas: maybe you can do 1000 at a time, or write a script ...
[12:27] <ignas> and make everyone who has a schooltool checkout do that... :/
[12:28] <ignas> that will be as painful as migrating from svn to bzr was...
[12:28] <fullermd> You'll understand the reasoning next week, when Canonical starts selling RAM   ;)
[12:28] <mwhudson> ignas: or rebranch, i guess
[12:28] <luks> haha
[12:30] <ignas> mwhudson: we have a distributed team, most of the developers are part time, and will be working only in a week, or in two weeks, and I don't even know what are update schedules of deployed instances, making everyone do "something" or *not* do "something" is a bit tricky ...
[12:30] <mwhudson> ignas: well, you _can_ pull from packs to knits and so on
[12:31] <mwhudson> ignas: anyway, i hope a fix is found soon, i am off to bed
[12:31] <ignas> good night
[12:32] <lifeless> ignas: disk compression is very good
[12:32] <lifeless> ignas: the memory usage is a bug, its the sum of the plain texts, I suspect
[12:32] <lifeless> ignas: but it shouldn't do that unless its cross-format
[12:33] <ignas> lifeless: cross-format?
[12:33] <lifeless> ignas: please file a bug about this, get someone here to mark it critical
[12:34] <lifeless> I need to go sleep right now
[12:34] <lifeless> ignas: 1.6 is nearly released, to please file the bug asap
[12:34] <ignas> lifeless: ok
[12:35] <dato> poor jam
[12:35] <ignas> https://bugs.launchpad.net/bzr/+bug/256757 is there already
[12:35] <ignas> I can update it with new information
[12:36] <ignas> as soon as I'll be done bzr branching from a remote repository
[12:37] <ignas> I know that local branching is not working, so I want to see whether I can at least create new branches from my server
[12:44] <fullermd> Yeah, do stick repo size and revision coutn and all that yada yada on it.
[12:44]  * fullermd critical-bumps it.
[12:44] <ignas> ok, will do that
[12:44] <ignas> fullermd: how do I get revision count?
[12:45] <dato> bzr info should say afaik
[12:45] <fullermd> info -v lists it, under the 'Repository' heading.
[12:45] <fullermd> (total revisions in the repo, rather than the number of revs in a branch)
[12:48] <ignas> fullermd: posted full bzr info -v of one of the "main" branches in that shared repository
[13:20] <xshelf> quit
[13:40] <balor> Is there a way to recursively inventory a directory and see if I've forgotten to add some files a-la-tla's [U] flag for unknown files?
[13:44] <vila> hi all
[13:45] <vila> Can someone remind me why diffs from bzr viz are colored under Linux but not under windows ?
[13:46] <vila> I'm pretty sure it's some python package but can't remember which nor find one...
[13:46] <Toranin> whee, left bzr-svn svn-import running all weekend...looks like only another day or two for it to actually finish :p
[13:47] <Toranin> copying revision 58473/81533
[13:49] <luks> hm, lots of revisions
[13:50] <Toranin> yeah
[13:52] <Toranin> it's (a) large project with (I think) 5 or 6 years' history, and (b) contains a bunch of 'content translation' commits in the last year or two from our i18n infrastructure.  Ideally I'd like to see the translations moved to a separate repository, but right now I'm just doing basic feasability testing
[13:53] <fullermd> vila: gtksourceview?
[13:53] <vila> fullermd: the name rings a bell ! thanks
[13:54] <vila> fullermd: yup, that's the one
[14:01] <aantn> I'm trying to upgrade a repository to format 6
[14:02] <aantn> do I need to do anything other than run bzr upgrade --development && bzr push?
[14:02] <aantn> err, sorry; there should also be a bzr commit --unchanged in there
[14:02] <aantn> is that correct?
[14:04] <fullermd> push won't update the format at the far side.
[14:04] <fullermd> You have to do an upgrade there (or give upgrade the URL, though remote upgrade'ing is likely to be really slow unless you're really close)
[14:05] <Necoro> aantn: and make sure the remote update won't fail (esp. if you are using LP) ^^
[14:05] <Necoro> I haven't found a way of restoring the repository (except deleting and repushing the branch)
[14:05] <luks> why do you want to use a development format, though?
[14:06] <aantn> luks: I'm actually not certain that I do
[14:06] <luks> so what do you want to do? :)
[14:08] <aantn> luks: is format r the development version or is that default?
[14:08] <aantn> *format 6
[14:08] <luks> I don't know, there is no "repository format 6" as far as I know
[14:09] <aantn> luks: sorry, branch format 6
[14:09] <luks> that's the default
[14:10] <aantn> thanks
[14:10] <aantn> I misunderstood that
[14:11] <luks> and if you want to upgrade a remote branch, you need to run either bzr upgrade sftp://... or run it remotely on the server
[14:12] <aantn> luks: is there any way to run an upgrade on launchpad without doing it remotely?
[14:12] <luks> no :(
[14:12] <luks> sftp is the only way
[14:12] <Necoro> bzr upgrade bzr+ssh://... works too
[14:12] <luks> bzr+ssh doesn't work, it was implemented only in 1.6 and it still not more efficient than sftp
[14:12] <Necoro> ;)
[14:13] <aantn> luks: do you mind giving an example upgrade command for launchpad
[14:13] <Necoro> ok - I used 1.6
[14:13] <aantn> I'd like to make sure that I don't mangle this up
[14:13] <luks> Necoro: the server needs 1.6
[14:13] <luks> aantn: what's the branch you want to upgrade?
[14:14] <aantn> https://code.launchpad.net/~universal-applets-core/universal-applets/trunk
[14:14] <Necoro> aantn: make sure you have a local branch ready in case it fails ;)
[14:14] <aantn> Necoro: will do
[14:15] <luks> bzr upgrade sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/
[14:15] <luks> or insert your username before the hostname, if you don't have it configures in .ssh/config
[14:15] <luks> *configured
[14:15] <aantn> luks: thanks; I'll try that in a few minutes
[14:16] <Necoro> luks: but ... I used bzr+ssh ... and at least it started ... it later failed - but with a message that does not read like "we don't support upgrading via bzr+ssh"
[14:16] <Necoro> "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data." was the error message to be specific
[14:17] <luks> Necoro: you did not specify the format
[14:17] <luks> and you can't convert rich-root formats into the default formats
[14:17] <Necoro> the old format there was dirstate-tags
[14:18] <luks> I think it was 'rich-root' :)
[14:18] <Necoro> luks: http://rafb.net/p/rRkVlp50.html
[14:19] <Necoro> thats the output of "bzr info" from before upgrading
[14:19] <luks> dirstate-with-subtree then, even worst
[14:19] <luks> *worse
[14:19] <Necoro> oh ... I should improve my reading skills ;)
[14:20] <Necoro> but - this format hell is not really easy to understand ;)
[14:21] <luks> yeah
[14:21] <Necoro> for example - I don't know where there is the difference between pack-0.92, rich-root and rich-root-pack
[14:21] <Necoro> and which one to use for my repositories
[14:22] <luks> with that specific branch you can upgrade only to --pack-0.92-subtree
[14:23] <luks> --dirstate-tags, --rich-root and --dirstate-with-subtree are basically the same format, but with different handling of "tree root"
[14:23] <luks> same for --pack-0.92, --rich-root-pack and --pack-0.92-subtree
[14:23] <luks> the subtree variants were never 'officially supported'
[14:24] <Necoro> hmm - I guess I used this on LP, because it is a converted svn repo
[14:25] <luks> yeah, bzr-svn used to need the subtree formats
[14:25] <luks> the rich-root formats were added basically only for bzr-svn
[14:25] <luks> to avoid the subtree ones
[14:26] <Necoro> hmm - ok ... so it is not necessarily a good idea to have nearly all my repositories (even these ones which are created directly in bzr and never saw any subversion) in rich-root-pack
[14:26] <luks> AFAIK, the plan was to make a rich-root variant the default
[14:27] <fullermd> AFAIK, it still is.  That should land in 1.2 or so...
[14:27] <luks> but I guess they are still not the default, because it's much slower to upgrade the default formats to them
[14:27] <luks> it needs to rewrite a lot of data
[14:27] <luks> can't see any other reason do to not do it
[14:27] <fullermd> Last I heard, it was still blocked on the upgrade not actually doing everything right.
[14:28] <luks> oh, and that, yes
[14:28] <luks> but that was fixed in 1.5, no?
[14:28] <fullermd> BTFOOM.
[14:28] <Necoro> hmm - and by "rich-root", it is meant to have a repos A - and inside it another repos B? - or something different?
[14:29] <fullermd> abentley was working on it, and I thought he still had another bump when he got busy with other stuff.
[14:39] <robsta> hi
[14:39] <robsta> i'm trying to interoperate between gnome's svn and bzr-playground
[14:39] <robsta> rumor has it that the newest bzr has lots of svn fixes, but i can't install from the ppa
[14:40] <robsta> this is on hardy, looks like deps are missing
[14:40] <LarstiQ> can't install bzr, or can't install bzr-svn?
[14:40] <robsta> added deb http://ppa.launchpad.net/bzr/ubuntu hardy main to sources.list, but it won't let me update
[14:41] <robsta> when i try with hardy's 1.3 it says SvnRepository and KnitRepository are incompatible
[14:42] <robsta> or "not implemented" when i try to "push --overwrite" to gnome-svn
[14:42] <luks> robsta: the latest version will tell you the same thing, because it's not compatible
[14:42] <luks> well, that's different
[14:42] <luks> but push --overwrite is almost a good idea
[14:43] <luks> what are you trying to do?
[14:43] <robsta> push my bzr-playground branch to gnome svn
[14:43] <luks> damn, "almost NEVER a good idea"
[14:43] <robsta> ooooh
[14:43] <luks> the svn branch has probably diverged since then
[14:44] <robsta> it said it had, but actually trunk/ was empty
[14:44] <robsta> not i "svn import" ed the source tree and try to "push --overwrite"
[14:44] <robsta> no2 i "svn import" ed the source tree and try to "push --overwrite"
[14:44] <robsta> *now
[14:45] <robsta> so the state of svn is irrelevant, the project was born on bzr-playground
[14:46] <luks> oh, it never existed in svn before?
[14:46] <robsta> no
[14:46] <luks> and the trunk/ in svn is already created, right?
[14:46] <robsta> yes
[14:46] <luks> so it thinks it's a different branch
[14:46] <luks> I'm not sure what's the best fix
[14:47] <Jc2k> robsta: hi again
[14:47] <robsta> well, now it has the latest source, because it tried to import it with svn, and the overwrite with bzr
[14:47] <Jc2k> robsta: i'm afraid we need bkor or jelmer to do this
[14:47] <luks> push --overwrite to svn can't work
[14:47] <Jc2k> robsta: i have a link for you
[14:47] <luks> I'd personally use "bzr replay" to copy the branch
[14:48] <luks> but there is probably a better way
[14:48] <robsta> Jc2k: are you the guy that gave us bzr-playground?
[14:48] <Jc2k> robsta: not quite, i spawned bzr-mirror and then canonical people spawned the playground
[14:48] <luks> )but of course that would screw up revision numbers in the original bzr branch)
[14:48] <Jc2k> robsta: http://uwstopia.nl/blog/2008/06/importing-bazaar-branches-into-gnome-svn
[14:50] <luks> oh, a trick with moving the trunk
[14:51] <Jc2k> thats what jelmer came up with
[14:51] <robsta> Jc2k: thx, and anyway, bzr-playground rocks :)
[14:52] <Jc2k> yes, they did a sweet job
[14:53] <robsta> svn rm'ing trunk doesn't work because of the maintainer hook
[14:53] <Jc2k> robsta: thats why we need bkor
[14:54] <Jc2k> (or jelmer, who threatened to write a python script that was immune to that hook)
[14:54] <robsta> ah, hah
[14:54] <robsta> Jc2k: ok, no hurry
[14:55] <robsta> it's just i don't know if people are happy when i'm starting to release tarballs of a playground-only module
[14:56] <Jc2k> robsta: you are just being to nice
[14:57] <Jc2k> *too
[14:57] <Jc2k> afaik, telepathy isnt on svn.gnome.org for example
[14:58] <robsta> hmm
[14:58] <robsta> by the way, is there any chance that bzr will interoperate with git repose some day?
[14:59] <Jc2k> jelmer is working on it
[14:59] <robsta> oh rock
[14:59] <Jc2k> indeed
[15:00] <Necoro> hmm ... there is the need for one common format of storing repository information ;) ... and then just having git, bzr, hg, svn etc. as frontends -- so everyone can use what they prefer ;P
[15:00] <LeoNerd> Er.. no, becasue that misses the entire point
[15:00] <robsta> Jc2k: so there /is/ a light at the end of the tunnel for DVCS :P
[15:00] <Necoro> LeoNerd: ok
[15:00] <LeoNerd> The different systems store diffrent data, in different models, with different capabilities. No one system would cover them all
[15:00] <fullermd> Good idea.  But it doesn't go far enough.  We also need one common format of command interface too, for easy interoperability.
[15:01] <fullermd> Then git and bzr and hg and svn can just be different...  uh...
[15:01] <Jc2k> oh dear, meta-dvcs talk is never good
[15:02] <Jc2k> robsta: i dont see light, really. if bzr talks git, then git wins anyway
[15:02] <Jc2k> robsta: which i dont call light at the end of the tunnel
[15:02] <robsta> Jc2k: honestly, i don't care who wins
[15:03] <Jc2k> robsta: i have phases, but the bzr team consistently impresses me and think its a better long term choice
[15:03] <robsta> yeah, but git has such an incredible head start
[15:04] <fullermd> You think that's bad, look at the head start CVS has.
[15:04] <pickscrape> Not in terms of usability it doesn't...
[15:04] <LeoNerd> No, git just has better marketing.. I.e. kernel uses it
[15:04] <LarstiQ> robsta: head start on what? Market share?
[15:04] <robsta> market share in number of projects
[15:04] <robsta> (and that is guesse)
[15:04] <LarstiQ> robsta: right
[15:05] <pickscrape> What worries me about git is that it is very much focused on "What the kernel devs need"
[15:05] <LeoNerd> Ya.. it's highly tuned to one specific use case.. It doesn't work too well outside of that
[15:06] <luks> but but... it's so fast!
[15:06] <pickscrape> Diminishing returns though.
[15:07] <LeoNerd> luks: "The wrong answer quickly is still wrong"
[15:07] <pickscrape> Plus, I found that the speed advantage of git was more than eaten up by the time taken to refer to the man pages and googling for help every 2 minutes :)
[15:08] <LarstiQ> lots of people are happy with it though.
[15:09] <Necoro> hmm - btw: the GHC folks - they wanted to leave darcs behind ... does anyone know where they ended (or whether they already found an end at all)
[15:09] <luks> no program is ever going to fit all use cases
[15:09] <luks> Necoro: I think they decided to go with git, and now they argue if it was such a good idea
[15:09] <LeoNerd> luks: Exactly my point above, on the "no we don't want one VCS"
[15:10] <Necoro> luks: hmm ... if they at least had chosen hg ^^
[15:11]  * luks is not going into hg vs git debate :)
[15:11] <Necoro> luks: the only point, why I would have preferred it is: "at least hg is not git" ;P
[15:12] <luks> there is nothing wrong with git, er... wait
[15:12]  * LarstiQ doesn't think this is particulary constructive.
[15:13] <Necoro> LarstiQ: who wanted to be constructive?
[15:13] <Necoro> ;P
[15:13] <Necoro> perhaps it needs another bzr-hosting-service ... LP is a lil' bit too ubuntu-centric imho
[15:14] <luks> almost any webhosting can host bzr
[15:14] <LeoNerd> I've never quite seen the point...
[15:14] <luks> I don't see a problem there
[15:14] <LeoNerd> Any ol' webserver will do
[15:14] <Necoro> luks: webhosting with SSH access ... because pushing via FTP is annoying
[15:16] <Necoro> and this isn't the cheapest thing to get ;) (if you don't own one already)
[15:19] <LeoNerd> Why is FTP pushing worse than sftp/bzr+ssh ?
[15:20] <Necoro> always typing a password is annoying
[15:21] <Necoro> and no: I'm not saving the pwd as part of the push-branch-address
[15:23] <LeoNerd> Ahright....
[15:27] <cody-somerville> LeoNerd, bzr+shh makes use of the smart server
[15:30] <gour> Necoro: still git (for GHC) without any other alternative really concerned. i sent some msg to ml and two days ago started some discussion on #ghc 'cause someone noticed that git's workflow is not all in all. unfortunately, #bzr was quite sleepy and there was nobody to explain how looms can replace need for git's rebase :-(
[15:31] <Necoro> gour: oh =|
[15:31] <hsn_> i have checkout and want to checkout different revision from same tree into same directory bzr checkout -r give error 183: .bzr file exists
[15:31] <LarstiQ> lifeless, jelmer: do you have cycles to help gour with explaining things to #ghc people?
[15:33] <gour> LarstiQ: someone should go there and talk...i'm too young with bzr and didn't go into such stuff as looms
[15:33] <LarstiQ> gour: aye, and I have been away too long.
[15:33] <LarstiQ> gour: you mentioned rebase earlier, jelmer would be the guy for that. And in general, lifeless is good at explaining things.
[15:35] <Necoro> hsn_: I would say: bzr revert -r 183
[15:35] <gour> LarstiQ: yeah, i called for 'em. btw, see (huge) thread http://www.haskell.org/pipermail/glasgow-haskell-users/2008-August/015134.html
[15:35] <gour> LarstiQ: thumper jumped in and helped a bit, but then he had to go quickly
[15:36] <Necoro> hsn_: but if you want to create a new branch that starts at rev 183, I would say, it would be saner, to delete the current branch and start fresh at rev 183 ...
[15:36] <LarstiQ> gour: I'll try to read that thread today.
[15:37] <LarstiQ> Necoro: bzr branch -r 183 . ../newstart ?
[15:37] <Necoro> LarstiQ: please read what hsn_ wants ;P
[15:37] <Necoro> " and want to checkout different revision from same tree into same directory"
[15:37] <LarstiQ> Necoro: I have difficulty parsing that sentence.
[15:38] <hsn_> yes bzr revert -r works
[15:38] <LarstiQ> hsn_: could you describe some more what your desired end result is?
[15:38] <Necoro> LarstiQ: he wants to have rev 183 in the current directory (for whatever reason)
[15:38] <LarstiQ> Necoro: is that it? That's fine for testing a historicals behaviour for instance, sure. And you are right that revert -r 183 is the way to do that.
[15:39] <gour> LarstiQ: the most unfortunate thing is that bzr was ruled out due to speed only although on wiki page it is quite feature-rich - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation howver, maybe there is still chance 'cause they did not switch. someone knowledgeable should contact them, ask for common workflows and explain how to do it in bzr. i'll continue using bzr (came from darcs), but i'm sure that ghc's move will heavily
[15:39] <gour> influenced the rest of haskell community (the whole hackage - haskell' cpan - uses darcs)
[15:39] <Necoro> true ... but one should not modify and commit now ;P - except this is what is really intended ;)
[15:41] <LarstiQ> Necoro: there are reasons to do that, but yes, it is slightly peculiar. Ref my request for clarification of intent from hsn.
[15:41] <LarstiQ> hsn_: so. :)
[15:42] <Necoro> ah btw ... just because this is such a great tool: Thanks to all you Bzr-Devs for your efforts ;)
[15:42] <Necoro> (needed to be said today :D)
[15:42] <hsn_> can i start bazaar without loading plugins?
[15:42] <LarstiQ> hsn_: yes, bzr --no-plugins
[15:42] <luks> --no-plugins
[15:52] <awilkins> markh: Are you building Python-flavoured builds?
[15:53] <aantn> luks: how would I attach my username to the url sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/
[15:53] <luks><EMAIL_ADDRESS>[15:55] <aantn> luks: thanks
[15:55]  * aantn crosses his fingers and hopes nothing goes wrong with the remote upgrade
[15:55] <luks> it will probably take some time
[16:54] <aantn> luks: yeah, bzr is still backing up the tree history
[17:28] <aantn> do I need to repull a local copy of my branch after I finish upgrading the remote branch?
[17:30] <LarstiQ> aantn: that depends. Was it previously up to date?
[17:31] <LarstiQ> aantn: If yes, the no pulling is needed. You might still want to make sure it uses the same format as remote (though not required).
[17:31] <LarstiQ> aantn: so bzr info local; bzr info remote; and bzr upgrade to remote's format if different
[17:32] <aantn> LarstiQ: thanks
[17:55] <TemplePrime> can I have multiple projects in a repository?
[17:57] <Tak> I must be doing something wrong here, correct? http://rafb.net/p/I0Yaxz51.html
[18:03] <LarstiQ> Tak: what do `bzr st` and `bzr missing` say?
[18:03] <Tak> `bzr st` returns empty
[18:04] <LarstiQ> Tak: there might be a bug there. Frankly, being bound to a branch but having zero revisions is a strange situation.
[18:04] <LarstiQ> How did you end up in that state?
[18:04] <Tak> ah, ok
[18:04] <Tak> I'm following the manual, setting up a new repo
[18:04] <LarstiQ> really? Which manual?
[18:04] <Tak> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[18:05] <Tak> except I guess I mingled the working-offline section with the starting-a-central-branch section in a way that's not supported
[18:05] <LarstiQ> Tak: it mentions unbind a couple of times, but they don't seem to match. What section are you following?
[18:07] <LarstiQ> Tak: ah.
[18:07] <Tak> if I just can't do that with the initial revision, then that's cool
[18:07] <LarstiQ> Tak: I'm still trying to understand what you were trying to do.
[18:08] <LarstiQ> Tak: it is certainly a bug that bzr tells you to do something, you do it, and then it doesn't help you.
[18:08] <Tak> I was trying to do the initial file import on a checkout of a newly-created repo
[18:09] <LarstiQ> Tak: I have a hunch as to why things go awry in this case, but if you can give me a complete recipe for reproducing this, I can thwack the bug on it's head.
[18:09] <Tak> sure
[18:10] <LarstiQ> Tak: does the master have any revisions at all?
[18:11] <Tak> no
[18:14] <LarstiQ> Tak: thanks, that gave me enough info I think. 'bzr init sftp://localhost/tmp/master; bzr checkout sftp://localhost/tmp/master/ slave; cd slave; bzr unbind; touch foo; bzr add; bzr ci -m 1; bzr bind; bzr ci; bzr up; bzr ci;' gets me the same error.
[18:14] <Tak> yes, that's exactly what I did
[18:14] <Tak> I was just pastebinning an entire session for you ;-)
[18:14] <LarstiQ> Tak: I'll still look at it for your effort :)
[18:15] <LarstiQ> Tak: so, you'll find that if master actually has a revision, the update will do something.
[18:15] <Tak> ok, cool
[18:15] <LarstiQ> Tak: say, bzr checkout master slave2; cd slave2; touch bar; bzr add; bzr ci; cd ../slave; bzr update
[18:16] <LarstiQ> Tak: and status should show your initial local commit as a pending merge
[18:16] <Tak> `bzr push master` seems to rectify it for me
[18:16] <Tak> (for the zeroth => first revision)
[18:18] <LarstiQ> That is also an option.
[18:18] <LarstiQ> You're basically operating in standalone branch mode there, and not checkouts.
[18:19] <LarstiQ> Tak: what I'd personally would have done is probably: bzr init trunk; cd trunk; cp -a ../prebzr/* .; rm -rf CVS; bzr add; bzr ci; bzr push master (this will create the branch); bzr bind master;
[18:19] <Tak> I see
[18:20]  * Tak obviously new to bzr
[18:20] <LarstiQ> Since you're setting up the branch from scratch. With a preexisting master it would just be 'bzr co master trunk; cd trunk; *hack*; bzr ci'
[18:21] <LarstiQ> Tak: that's ok, you help find bugs in cases more experienced users won't think of :)
[19:27] <jam> I just found a major regression in knit => pack performance :(
[19:28] <LarstiQ> namely?
[19:29] <jam> LarstiQ: "bzr branch knit pack" results in a 170MB repo when it should be 34MB
[19:29] <jam> https://bugs.edge.launchpad.net/bzr/+bug/256757
[19:29] <jam> It might actually only be in bzr.dev, though.
[19:29] <LarstiQ> Aha.
[19:29] <jam> the problem is that it does an "unsorted" fetch with all fulltexts
[19:29] <LarstiQ> I recently upgraded my bzr repo, it took all evening and was constantly thrashing. 2.3G committed memory.
[19:29] <jam> which means that the target repository
[19:29] <LarstiQ> so yeah.
[19:30] <jam> will insert fulltexts in random order
[19:30] <jam> and "random" doesn't delta very well
[19:30] <LarstiQ> oh boy.
[19:30] <Peng_> Wow.
[19:30] <luks> doesn't it _always_ diff against the left-most parent?
[19:35] <LarstiQ> james_w: do you remember what happened to your test for bug 120968 ?
[19:35] <Tak> hooray!
[19:35]  * LarstiQ has trouble finding a test for that in bzr.dev
[19:35] <james_w> hey LarstiQ
[19:36] <jam> luks: When you insert in random order, the left-hand parent may not be *present* yet, and thus you get a fulltext
[19:36] <LarstiQ> Tak: that's a different bug though :)
[19:37] <jam> So about 50% of your deltas get expanded to fulltexts
[19:37] <LarstiQ> Tak: yours is #259146
[19:37] <jam> Changing it to "topological" causes it to re-delta everything, which is costly CPU (and memory) wise, but at least the target repo isn't bloated.
[19:39] <luks> oh, I thought it would reject revisions with missing parents
[19:39] <luks> but thinking about it again, it wouldn't make sense for ghosts
[19:39] <jam> fullermd: ping about bug 256757
[19:39] <jam> I just want to check what version of bzr is involved
[19:39] <jam> as to whether this is a 1.6 regression, or just bzr.dev
[19:40]  * Tak subscribe
[19:41] <james_w> LarstiQ: ah, that was never merged I think
[19:42] <james_w> I just never got round to writing the fix part of the patch
[19:43] <jam> damn, it *is* in bzr-1.6
[19:44] <jam> beuno: I'm going to need a 1.6rc4... :(
[19:44] <LarstiQ> james_w: 1.5 doesn't break on this, but it isn't testing it afaics, so I don't want to close the bug yet.
[19:44] <jam> LarstiQ: have you tried 1.6rc?
[19:44] <LarstiQ> jam: nafaict
[19:45] <LarstiQ> jam: I _think_ it was 1.5, but I can do it again (I kept the old repo around, it didn't seem right to me)
[19:46] <LarstiQ> jam: du -mcs backup.bzr .bzr: 100 and 610 meg
[19:46] <pickscrape> jam: if you have a repository affected by this bug, will a "bzr pack" using a fixed bzr bring the repo down to normal size (obsolete_packs notwithstanding)?
[19:47]  * LarstiQ looks at the bug
[19:48] <jam> pickscrape: no :(
[19:48] <jam> pickscrape: that is why it is an extreme blocker for 1.6
[19:48] <pickscrape> Heck, yes indeed.
[19:49] <jam> we could *teach* pack to do so
[19:49] <jam> but it doesn't yet
[19:49] <jam> pickscrape: we probably should anyway, to get people who have already upgrade to get back into reality again
[19:50] <TemplePrime> hey guys, are there any bazaar hosting services around? free and non free?
[19:50] <Tak> launchpad?
[19:51] <TemplePrime> does it provide though security features, like only memebers of groups can see source?
[19:51] <LarstiQ> TemplePrime: any file hoster would do for bare requirements.
[19:51] <jam> TemplePrime: there *are* private branches, which is non-free
[19:51] <jam> And IIRC, not widely disseminated. I think it is still in a beta program.
[19:52] <TemplePrime> launchpad seems a decent service, I'll get an account
[19:54] <LarstiQ> jam: started an upgrade with 1.5 to --pack-0.92
[19:54] <jam> fullermd: thanks for marking the bug critical, btw. It caused me to investigate it.
[19:54] <jam> and it really is a critical regression
[19:55] <aantn> luks: by the way, thanks for the help earlier; I got my branch switched over successfully
[19:55] <beuno> jam, :(
[19:56] <jam> beuno: yeah, but when we start warning users that they need to upgrade, I don't think we want to bloat their repos by about 5:1
[19:57] <LarstiQ> jam: hmm, that seemed to have gone wonderfully well
[19:57] <jam> LarstiQ: with 1.5?
[19:57] <LarstiQ> jam: yes
[19:57] <LarstiQ> jam: so perhaps I did the upgrade previously with bzr.dev, let me try that
[19:58] <beuno> jam, right. Makes sense  :)   When?
[20:01] <LarstiQ> jam: at 300 megs and rising, so far so good.
[20:02] <jam> beuno: Well, I would really like lifeless to wake up and review the patch
[20:03] <jam> Otherwise I'll be submitting a patch for review in about 10 minutes
[20:03] <LarstiQ> jam: ~1G and system becoming unresponsive.
[20:03] <jam> LarstiQ: yeah it was rev 3854 that introduced the bug
[20:03] <LarstiQ> so yeah, seems to be the same behaviour as last time.
[20:03] <jam> which is in 1.6 and bzr.edv
[20:03] <luks> aantn: what version did you use to upgrade? maybe it was not such a good idea after all :(
[20:04] <jam> luks: 1.5 is safe
[20:04] <jam> 1.6-final *will* be safe
[20:04] <luks> I think aantn was seing the upgrade warning
[20:04] <luks> which is only in 1.6-something
[20:04] <jam> luks: yep, and bzr.dev
[20:05] <clemente> Hey, „bzr log“ is slower in current bzr.dev than in 1.5 :-( 1' 30" vs 1' 15" for showing the log of lp:bzr.dev
[20:06] <aantn> luks: I upgraded to the repository format 6
[20:09] <beuno> jam, alright, ping me and I'll try and upload tonight
[20:09] <beuno> I'm supposed to be on holiday today :)
[20:11] <jam> beuno: well, we *can* wait until tomorrow if you are busy. This is just a serious regression :(
[20:12] <pickscrape> On holiday already? :p
[20:17] <jam> On the plus side, with my fix the branch time drops from 5m => 30s, which actually makes knit => pack faster than it would be in 1.5
[20:19] <jam> Of course, all of this is discovered while *3* core devs are on vacation
[20:19] <jam> (abentley, spiv, poolie are all away this week)
[20:19] <jam> beuno: LarstiQ, can you try to review the patch?
[20:20] <LarstiQ> jam: I'll look at it, but I don't promise to be worth anything.
[20:21] <jam> LarstiQ: well, the patch is pretty much 'trivial" as it was just a "not" logic inversion
[20:21] <jam> if you want to just download it and try it on your upgrade
[20:21] <jam> that would probably be enough for me.
[20:22] <LarstiQ> right
[20:25] <LarstiQ> that does look simple
[20:26] <jam> I think the problem is that the naming of the parameter is poor
[20:26] <LarstiQ> agreed.
[20:26] <jam> "fetch_uses_deltas" versus "include_delta_closure"
[20:26] <jam> the latter sure *sounds* like it sends deltas
[20:26] <LarstiQ> (on it being pure, don't know if that is _the_ problem)
[20:27] <jam> it actually means trace back through all deltas and make sure to include all the referenced info
[20:27] <LarstiQ> is it me, or is bundlebuggy slow/not resolving?
[20:27] <jam> abentley has been complaining about his hosting
[20:27] <LarstiQ> jam: well, _closure does sort of evoke that in my mind
[20:27] <jam> I'm not getting to the site
[20:27] <LarstiQ> sort of, because I didn't know exactly what a closure would involve
[20:27] <jam> LarstiQ: sure, though I will say lifeless wrote both apis and got it wrong :)
[20:28] <LarstiQ> jam: oh yes, I support you
[20:29] <jam> LarstiQ: BB is probably down right now, and abentley isn't around to ping to bring it back up.
[20:29] <jam> You'll have to just do a reply
[20:29] <jam> and assume BB will wake up later
[20:29] <LarstiQ> jam: I wanted BB to pull from, but I've saved the patch and scped it. Running the upgrade with a patched bzr.dev
[20:31] <jam> I don't think BB has even detected my patch yet
[20:31] <LarstiQ> jam: bzr: ERROR: Revision {('testrevisionnamespaces.py-20050711050225-8b4af89e6b1efe84', 'robertc@robertcollins.net-20051002215128-5686c7d24bf9bdb9')} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x895d90c>".
[20:31] <jam> LarstiQ: I just got a timeout with a "Proxy Error"
[20:31] <jam> LarstiQ: you need bzr.1.6
[20:31] <jam> Though I would have thought that was merged into bzr.dev tip
[20:31] <LarstiQ> jam: this is my historical bzr repo
[20:31] <jam> LarstiQ: or is that what you get when upgrading?
[20:32] <jam> LarstiQ: it wouldn't be something that you need to 'bzr reconcile' would it?
[20:32] <jam> IIIRC the 1.5 fetch code could handle "broken" repos that need reconcile
[20:32] <jam> 1.6 doesn't
[20:33] <jam> And I would guess Robert's "bug" would let you fetch because it would cause everything to be sent as fulltexts...
[20:33] <jam> So it basically does reconcile on-the-fly
[20:34] <jam> but the fetch into-packs won't trigger the "auto-reconcile" code, which means you run into your problem....
[20:34] <jam> hmmm
[20:35] <jam> LarstiQ: can you try a line for me, just a sec
[20:36] <jam> LarstiQ: http://rafb.net/p/Ux6YDH80.html
[20:38]  * LarstiQ is currently afk on the phone
[20:48] <LarstiQ> jam: it was indeed what I got when upgrading *looks at rafb*
[20:49] <LarstiQ> jam: applied and trying again
[20:49] <jam> thx
[20:52] <LarstiQ> jam: same problem
[20:52] <jam> LarstiQ: can you post the traceback, so I can see where it happens?
[20:54] <LarstiQ> jam: http://rafb.net/p/bV38GS44.html
[20:55] <jam> LarstiQ: ok, it is getting to the failure before it gets a chance to reconcile.
[20:55] <jam> LarstiQ: unfortunately, I think the correct fix is to upgrade using bzr.1.5 and then run reconcile.
[20:56] <jam> or run reconcile first
[20:56] <jam> but that is generally very slow with knits.
[20:56] <LarstiQ> yeah
[20:58] <LarstiQ> I'll do some reconciling
[20:59] <jam> LarstiQ: keep an old copy of it, if it isn't too much overhead
[20:59] <jam> just so we remember stuff like that.
[21:01] <LarstiQ> jam: I'm working on copies of my original backup.bzr, it's too valuable to touch directly.
[21:07] <LarstiQ> great
[21:07] <LarstiQ> bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit inventory corrupt:
[21:19] <jam> LarstiQ: so... I would try upgrading with bzr-1.5, and then doing "bzr reconcile" and see where you get.
[21:21] <LarstiQ> will do. That was an 1.5 reconcile on the knit repo btw.
[21:36] <LarstiQ> jam: 1.5 upgrade, 1.5 reconcile -> oh hey, your repository is corrupt kthxbye!
[21:36] <LarstiQ> jam: trying a 1.5 upgrade, bzr.dev reconcile now
[21:36] <LarstiQ> just out of sheer desperation
[21:36] <jam> LarstiQ: I wouldn't expect much, if this is the bug I'm thinking of
[21:37]  * jam guesses LarstiQ pulled directly from one of abentley's repos at some time in the past when they had diverged when we didn't realize
[21:37] <LarstiQ> maybe
[21:37] <LarstiQ> sha-1 548f019618118527ae97bb092643be0d187c0cf1  of reconstructed text does not match expected 89853621e92f00ae1bb075139284c4df9a0434d0 for version<EMAIL_ADDRESS>[21:37] <jam> LarstiQ: specifically, there were ghosts in aaron's repo, which caused "last-modified" entries to be different
[21:37] <jam> there were *deltas* generated against those texts
[21:38] <LarstiQ> jam: considering I have decendant code of nested-trees, it's not unlikely
[21:38] <jam> and those deltas were pulled directly on top of the other form
[21:38] <jam> without realizing that the base sha1 differed
[21:57] <wolever> I'm getting a message 'bzr: ERROR: Revision {...revision ID...} not present in "filename.py-...revision ID..."' -- how would I go about figuring out what's happening?
[22:13] <LarstiQ> jam: ehm, that 1.5 upgrade, 1.6 reconcile seemed to work.
[22:13] <LarstiQ> wolever: I don't have a good answer to that.
[22:13] <Peng_> wolever: Not that this helsp, but the "filename.py-..." thing is a file ID, not a revision ID.
[22:14] <LarstiQ> jam: trying to comment on the patch, slow going because it means reading other parts of the codebase
[22:16] <zeth> Hi
[22:16] <pickscrape> Is it possible to create a branch of a branch with working tree that carries over the state of the working tree also?
[22:16] <lifeless> moining
[22:16] <zeth> So at the moment I am just going open('.bzr/branch/last-revision').readline().split()[0] to get the rev number, can I do this with bzrlib?
[22:17] <Peng_> pickscrape: Well, you can use "bzr merge --uncommitted" after you branch.
[22:17] <awilkins> pickscrape: If you are using checkouts, you can push to a new branch and switch to it
[22:17] <lifeless> zeth: bzrlib.branch.Branch.open('.').last_revision()
[22:18] <Peng_> zeth: You can also do something like "bzr revno".
[22:18] <pickscrape> Peng: I'll try that
[22:18] <lifeless> jam: hi
[22:18] <Peng_> (well, that's if you're not doing it from Python)
[22:18] <pickscrape> awilkins: I don't want to commit what's in my WC yet, though I suppose I could do that and uncommit etc.
[22:19] <awilkins> pickscrape: I think if you push a new branch and switch what's left in your WC remains?
[22:19] <awilkins> I could be wrong
[22:20] <awilkins> hmm. Or you could shelve and switch
[22:20] <zeth> lifeless: cheers
[22:20] <zeth> Peng_: sorry should have said that from python
[22:20] <pickscrape> awilkins: yes, you're right. My current tree is in a checkout of a checkout (which actually works). I'm wanting to experiment with a loom, so I want to try it in a new branch
[22:20] <pickscrape> merge --uncommitted has basically done exactly what I wanted though. Thanks for the help :)
[22:22] <wolever> Peng_: Ah, excuse me.  LarstiQ: Darn.  Oh well, it's just a frustration, no lost work.
[22:22] <LarstiQ> wolever: other people should know though, but I wanted to say something and not let your question go without any reply.
[22:22] <LarstiQ> lifeless: heya
[22:23] <LarstiQ> lifeless: I think jam would like your feedback on [REGRESSION][1.6] fetching knits => packs
[22:23] <wolever> LarstiQ: Alright, I'll keep a copy of the offending repositories around then come back tomorrow
[22:24] <LarstiQ> wolever: if you can provide some more context on when it happens, that would help I think.
[22:24] <lifeless> LarstiQ: yes, I need to talk to him about it
[22:25] <LarstiQ> lifeless: good, then I'll stop looking at code and call it a day.
[22:25] <wolever> LarstiQ: I'd love to, but so far it's only happened once, and I'm not sure how to repeat it.  My suspicion is that it's got something to do with either mismatched versions of bzr-svn and bzr or canceling an operation at the wrong time.
[22:25] <LarstiQ> jam: do you want me to do anything with the upgraded/reconciled repository?
[22:26] <lifeless> LarstiQ: lol :)
[22:26] <LarstiQ> wolever: hmm, I'd say it still shouldn't in those cases. Your ~/.bzr.log should contain a traceback for it btw.
[22:29] <awilkins> Is it me or is Bundle Buggy Busted?
[22:29] <LarstiQ> awilkins: it is not you.
[22:35] <jam> LarstiQ: you can keep it on the side if you want. Thanks for your help. You did miss a 'get_record_stream()' I didn't see.
[22:35] <jam> lifeless: I'd like your help to put together a quick test case for all the fetches
[22:35] <jam> I believe there are 4 or so
[22:35] <jam> revs, sigs, invs, texts
[22:36] <lifeless> jam: yah, I think there are two tests needed
[22:36] <lifeless> one with _fetch_uses_delta True, and one False
[22:36] <jam> I really want to get an rc4 out today if at all possible
[22:36] <lifeless> we can use the existing VersionedFilesDecorator to catch the get_record_stream_calls
[22:36] <lifeless> so its roughly
[22:36] <lifeless> make_repo_a
[22:36] <lifeless> make_repo_b
[22:36] <lifeless> repo_a.texts = VersionedFilesDecorator(repo_a.texts)
[22:37] <lifeless> .signatures
[22:37] <lifeless> .revisions
[22:37] <lifeless> .inventories
[22:37] <lifeless> repo_b.fetch(repo_a)
[22:37] <lifeless> inspect repo_a.texts.calls
[22:37] <lifeless> this is a bzrlib.tests.test_fetch test-case, because it doesn't need to be parameterised by formats
[22:38] <lifeless> and we should do it with repo_b as a pack, and again with repo_b as a weave, to get both values for _fetch_uses_deltas
[22:39] <lifeless> jam: I can actually write it if you want, I figure that handoff time doing that would be greater
[22:40] <jam> lifeless: I think you've given me enough
[22:40] <jam> I've already got the code here
[22:41] <LarstiQ> jam: those are all icw _fetch_uses_deltas afaics, the rest is in (True, False, include_delta_closure)
[22:41] <rick_h_> lifeless: ping, I sent off the article I told you about. If you get a chance to peek at it. Pretty simple examples
[22:42] <rick_h_> no big deal though
[22:42] <jam> LarstiQ: 'icw' ?
[22:43] <LarstiQ> jam: in combination with, sorry, that is a Dutchism.
[22:43] <awilkins> "I cuckold walruses?"
[22:43] <jam> awilkins: sorry to hear that awilkins
[22:43] <awilkins> :-P
[22:44] <awilkins> The standalone exe for win32 has all the source compiled inside it, yes?
[22:45] <awilkins> What does it do about things like GTK libraries?
[22:45] <LarstiQ> jam: the endresult now is 173 knitpack and 100 knit repos btw
[22:45] <jam> LarstiQ: with my patch... and does that include removing files from .bzr/repository/obsolete_packs ?
[22:45] <jam> reconcile, IIRC, creates an obsolete pack
[22:46] <LarstiQ> awilkins: last I looked at it, fall over. But maybe markh has done something smart to instrument import.
[22:46] <lifeless> awilkins: not sure, bundles I thought
[22:46] <LarstiQ> jam: reconciled with your patch, yes. *looks at oldpacks*
[22:46] <jam> LarstiQ: We don't have the gtk libraries bundled into the all-in-one so you can't use the bzr-gtk plugin
[22:46] <jam> awilkins: I thought there was a discussion about adding places to the search path
[22:47] <jam> but I don't think it got very far
[22:47] <jam> so, ATM, the win32 will bundle the QT libraries to go with qbzr and tortoise
[22:47] <LarstiQ> jam: and now it is 87 megs big, cheers.
[22:47] <jam> LarstiQ: that sounds better
[22:47] <awilkins> It must bundle some of the QT stuff because it uses qbzr now
[22:47] <LarstiQ> jam: iirc 14 meg bigger than just the 1.5 upgraded version. But reconciled, so I can live with that.
[22:48] <awilkins> markh has not posted the Python flavoured builds of the installer
[22:48] <awilkins> (for win32)
[22:48] <jam> LarstiQ: probably for the bits that had bad deltas, it inserted new fulltexts
[22:48] <jam> we should really teach 'bzr pack' to combine a bit better
[22:48] <jam> but that will probably wait for something like 'group-compress'
[22:48] <LarstiQ> jam: yes.
[22:48] <jam> where I see 100MB => ~20MB when done correctly
[22:53] <lifeless> rick_h_: cool
[22:55] <jam> lifeless: how do you want to handle the 'extra' calls, like get_parent_map() and iter_lines_added...
[22:55] <jam> should I just check the *last* entry, which is 'get_record_stream' ?
[22:55] <jam> or should I be asserting the whole thing
[22:57] <zeth> so back to bzrlib, bzr has some magic way of finding the branch always, even if you are symlinked off or whatever, any idea how to use that from bzrlib?
[22:58] <jam> zeth: bzrlib.branch.Branch.open? or open_containing
[22:59] <rockstar> lifeless, hi
[23:00] <zeth> jam!, sweet cheers!
[23:01] <lifeless> jam: I would check there is only one get_record_stream call, and that it has the right value for that parameter
[23:01] <lifeless> jam: thats all
[23:02] <jam> lifeless: yeah, I didn't think we wanted to check all of it is constant
[23:02] <lifeless> zeth: if you look at bzrlib.builtins, you can see the code we use
[23:02] <lifeless> rockstar: hi
[23:03] <lifeless> jam: doing wakeup-stuff, back in a little bit
[23:03] <jam> lifeless: of course, for signatures, we seem to be doing 2 calls . :(
[23:07] <rockstar> lifeless, I,ve been hacking on cscvs today. Have some questions when you get back.
[23:16] <jam> lifeless: also, it seems that the proper value is 'unordered' not 'unsorted'...
[23:17] <jam> 'unsorted' worked because anything other than 'topological' works
[23:19] <chadmiller> rockstar: Heya.  Did you get mail from me (chad at sun com) about revno reset.
[23:19] <chadmiller> ?
[23:19] <lifeless> jam: meep
[23:19] <lifeless> rockstar: hi, just shoot
[23:19] <rockstar> chadmiller, I certainly did.  Thank you!
[23:19] <rockstar> lifeless, aggregating now
[23:21] <chadmiller> rockstar: I have another case for you.  :)  :\  :(
[23:21] <rockstar> lifeless, testInitProtocolBadHost seems to hang
[23:21] <rockstar> chadmiller, yes?
[23:21] <chadmiller> rockstar: Same problem.  Same three developers.
[23:21] <lzhang> is there a way to make bzr missing remember the branch that you want to want to run the command on?
[23:22] <jam> lifeless: ugh, it seems that for the 'iter_items_introduced_by' we do a direct get_record_stream() check for every revision to see if there is a signature
[23:22] <rockstar> chadmiller, and bzr resolve doesn't help?
[23:23] <rockstar> chadmiller, I mean bzr reconcile
[23:23] <lifeless> jam: thats in Model1To2
[23:23] <jam> lifeless: no, it is in "item_keys_introduced_by"
[23:23] <lifeless> jam: so you are doing a plain->rich-root conversion in your test case
[23:23] <jam> lifeless: nope, it does a "get_signature_text() try/except" to decide if it is part of the stream
[23:24] <lifeless> jam: oh fugkly
[23:24] <jam> and get_signature_text is implemented as get_record_stream
[23:24] <jam> which we then discard when we actually stream
[23:24] <lifeless> still, its been like that for a while
[23:24] <jam> lifeless: sure, I'm trying to do the minimum possible
[23:24] <jam> so I'll cheat for that one with a big TODO/XXX
[23:24] <chadmiller> rockstar: "oh [reconcile] does fix it... we just lose about 3 hours daily running it to fix the corruption"
[23:25] <lifeless> ok, breakfast
[23:25] <lifeless> then I will be here uninterrupted
[23:25] <jam> chadmiller: do you happen to be using knits in one place, and packs in another?
[23:25] <chadmiller> rockstar: "then someone pushes and it goes to hell again."
[23:25] <rockstar> chadmiller, oh yikes.
[23:25] <chadmiller> jam, doubtful.
[23:26]  * chadmiller verifies.
[23:26] <jam> chadmiller: well, a) you only need to reconcile the branch, which is a very small and fast portion of 'reconcile' and I think someone wanted to introduce a flag for only runing parts
[23:26] <jam> chadmiller: well, if it is a mysql tree, they never went public with a knit tree
[23:26] <jam> s/tree/repo/
[23:27] <chadmiller> jam: it's an internal project, unpublished.
[23:27] <jam> b) the only time I've specifically seen this, is when someone is accessing a repo that is missing a mainline revision
[23:27] <chadmiller> Hrm.
[23:27] <jam> there was a way that an old client pushing pack => knit could cause this if they ^C at the right time
[23:28] <jam> it at least feels like someone has a branch with a bad pointer, and they keep pushing over your official location
[23:28] <rockstar> chadmiller, did the branch come from a conversion of another vcs?
[23:28] <chadmiller> rockstar: Yes.  svn, iirc.
[23:30] <chadmiller> jam: all the branches I see pushed to are rich-root-pack.
[23:31] <jam> chadmiller: the problem is the 'from' (I'm guessing)
[23:33] <rockstar> That would make sense.
[23:39] <LarstiQ> hah.
[23:42] <jam> lifeless: if you get a chance, there is a patch up for review, and i'd like to get it submitted
[23:43] <jam> No standup today, unless igc comes around
[23:44] <chadmiller> jam, rockstar:  One other weirdness out of this team is that they're using sftp as transport.
[23:44] <jam> chadmiller: I'm not particularly worried about that part
[23:46] <chadmiller> Alright.  They're watching to see when it happens.  I have them running "bzr revno" on the destination before and after each push, branch, and merge.
[23:49] <lifeless> jam:
[23:49] <jam> ?
[23:50] <lifeless> jam: sorry
[23:50] <lifeless> reading, I'm not sure about the assertion
[23:50] <jam> chadmiller: what would be nice is to have a post_branch_tip_changed hook, but you aren't using bzr+ssh to install it on the server, and it is probably a pain to install it on all the clients
[23:50] <lifeless> you didn't alter weaves for instance :)
[23:51] <jam> lifeless: I think we should have *something* to make sure recognized values are passed. I don't care a lot about that part
[23:51] <jam> and I just want to get a 1.6rc out that can actually become final
[23:51] <lifeless> bb:approve
[23:56] <jam> lifeless: with the assert left in?
[23:56] <lifeless> jam: yes
[23:59] <jam> thanks, submitted


[00:32] <jo-erlend> how do I use the Launcher API from a PyGTK app? Unity seems to use gi.repository.GObject, which conflicts when I try to import it in my app.
[00:35] <mhr3> jo-erlend, something like https://github.com/emesene/emesene/blob/master/emesene/gui/common/UnityLauncher.py
[00:38] <jo-erlend> there is no API for PyGTK users, in other word?
[00:40] <mhr3> afaik no
[00:40] <jo-erlend> well. I guess that's a good incentive for me to get Quickly Widgets ported quickly.
[00:41] <jo-erlend> heh. So I'm actually going to spend several days trying to add a menuitem. Great. :)
[00:46] <jo-erlend> damn... That won't do it. The entire Quickly needs to be ported. :|
[02:00] <jmcantrell> can someone help me with unity+compiz?
[02:02] <jmcantrell> with the grid plugin, when doing left/right window placement, size cycling doesn't work, whereas it does when doing corner placement
[07:01] <oSoMoN> good morning
[12:00] <om26er> smspillaz, Hi :-) the sru for compiz-plugins-main caused some serious regressions with the grid plugin, one example is bug 875557 Got a say?
[15:02] <alourie> hello
[15:02] <alourie> I need some info on how Unity lenses work
[15:02] <alourie> how, for example, typing "friendly" finds checkbox?
[15:03] <davidcalle> alourie, the search engine uses informations stored in the .desktop file of the application
[15:04] <davidcalle> If you look at /usr/share/applications/checkbox-gtk.desktop, there is the line :
[15:04] <davidcalle> "Comment=Test your system and submit results to the Ubuntu Friendly project"
[15:05] <alourie> davidcalle: does it only look for "comment" field?
[15:07] <davidcalle> alourie, i'm not sure. It uses Name, Comment, maybe Categories. And the translated fields.
[15:10] <alourie> davidcalle: ah, so there are categories? Can they be used as "tags"?
[15:13] <davidcalle> alourie, I think so. But I don't think it's the proper way of using it. A nicely worded Comment would be preferable because shells that are not Unity use Categories to nest your application in the right menu.
[15:14] <alourie> davidcalle: ok, got it. Is there a way to set which match appears first? Or is it on a-b-c basis?
[15:15] <alourie> and while we're there, can it be made to parse things like "tag:me" in the search field?
[15:15] <alourie> and have this "tag" field in the .desktop file?
[15:16] <kamstrup> davidcalle, alourie: we also check X-GNOME-Keywords
[15:18] <alourie> kamstrup: ok, and how about ^^ that feature? Is it hard to implement?
[15:19] <kamstrup> davidcalle, alourie: we index Name, DisplayName, Comment, Exec, and X-GNOME-Keywords
[15:20] <kamstrup> alourie: the apps lens does not have a concept of tags...
[15:20] <kamstrup> and - hits aresorted by relevancy
[15:20] <kamstrup> and if there is no query, they are sorted alphabetically
[15:21] <alourie> kamstrup: ok, I get it doesn't have the concept yet. Would it be hard to implement?
[15:21] <kamstrup> alourie: no - but it would be hard to add the metadata to the apps - and frankly - what value would it add?
[15:22] <alourie> well
[15:22] <alourie> if all the data (for tags) can be used in Comment or Category or X-GNOME-Keywords
[15:22] <alourie> then you're right
[15:23] <kamstrup> alourie: or, I am not really sure what you want to accomplish really, :-)
[15:25] <kamstrup> alourie: the apps lens already support a few prefixes that you cna use to control the queries - they are undocumented though
[15:25] <alourie> kamstrup:  there's a brainstorm item about it, so I wanted to understand how unity does it :-)
[15:25] <kamstrup> alourie: section, type, category, namepkgname, exec, keyword
[15:26] <kamstrup> alourie: try fx "exec:gc"
[15:26] <kamstrup> matches all apps that contain "gc" in the fiename of the executable
[15:27] <kamstrup> or "keyword:print" matching apps with "print" in X-GNOME-Keywords
[15:33] <Saviq> greyback: PM?
[15:35] <ali1234> when i press ctrl-alt-2 to make the window fill the top half of the screen, is that part of the compiz grid plugin?
[15:37] <mardy> greyback: hi! Any news about https://code.launchpad.net/~gerboland/unity-2d/shutdown-problem/+merge/79168 ?
[15:39] <Saviq> mardy, greyback: re ^, I will rework the KeyMonitor to use QSocketNotifier on ConnectionNumber(display) and XPending(display), unless you want to pick that up
[15:39] <alourie> kamstrup: ah! this may be it!
[15:39] <alourie> thanks
[15:40] <mardy> Saviq: you're welcome :-)
[16:06] <mhr3> kenvandine, where can i find the gwibber lens?
[16:06] <kenvandine> mhr3, unity-lens-gwibber is the package
[16:07] <kenvandine> the source is in lp:gwibber
[16:07] <mhr3> kenvandine, i'm looking for bzr branch
[16:07] <mhr3> ah, k
[16:07] <mhr3> thx
[16:07] <kenvandine> although, the async changes i made over the weekend broke the build for the lens
[16:07] <kenvandine> i am fixing it right now
[16:07] <mhr3> async changes?
[16:07] <kenvandine> i made refresh_model async
[16:07] <kenvandine> in libgwibber
[16:08] <kenvandine> and now it complains about unused variables
[16:08] <mhr3> hmm, ok i see
[16:08] <kenvandine> so in lp:gwibber it is in the lens subdir
[16:19] <kenvandine> mhr3, for now to get it to build, you can just disable the maintainer flags
[16:19] <kenvandine>  --enable-maintainer-flags=no
[16:19] <mhr3> kenvandine, that's fine thx, i just needed to run a quick grep ;)
[16:20] <mhr3> figuring out if small api change in dee is going to affect anyone
[18:09] <kamstrup> kenvandine: did you see the startup optimizations I did in my profiling branch?
[18:09] <kamstrup> kenvandine: in essence was to only pass the filters over the model one time
[18:10] <kamstrup> kenvandine: cut off 500ms of 100% cpu churn on my i5 sandybridge
[18:10] <kamstrup> so probably a lot more on netbooks and the likes
[18:10] <kenvandine> i didn't...
[18:10] <kenvandine> did you push it?  i am skimming over the commit messages and it isn't jumping out to bite me
[18:11] <kenvandine> oh, NM
[18:11] <kenvandine> <- idiot
[18:11] <kenvandine> it was at the top :)
[18:11] <kamstrup> kenvandine: lp:~kamstrup/gwibber/stream-profiling ... I probably broke some things :-) but basic functionality was still working :-)
[18:11] <kenvandine> i look at it
[18:11] <kenvandine> thx!
[18:12] <kenvandine> the slowness on the dbus call was lacking and index on the table in the DB
[18:12] <kenvandine> brought the sql query from 1.25s to 0.003s
[18:12] <kamstrup> kenvandine: ah... going to an async dbus call should also help a lot
[18:13] <kenvandine> yeah
[18:13] <kenvandine> yeah, for precise i want to make that dbus call async
[18:13] <kenvandine> but did make refresh_model in libgwibber async
[18:13] <kenvandine> which helped a ton too
[18:16] <kenvandine> kamstrup, i'll work on updating that to apply to trunk
[18:16] <kenvandine> looks good to me
[18:37] <Trevinho> hey kamstrup: what do you think about this https://bugs.launchpad.net/ayatana-design/+bug/869888 (comment #2)
[18:53] <kamstrup> Trevinho: the problem is that this would make matching between the apps from software center and installed once different
[18:53] <kamstrup> Trevinho: as substring matching can not be implemented efficiently
[18:54] <kamstrup> Trevinho: adding to that that I also want the matching between the files and apps lenses to be identical, so we'd need this on files as well, which is a non-starter
[19:04] <Trevinho> kamstrup: ok, maybe substringing could be avoided, however... tools like gnome do or synapse are really efficent on that matching...
[20:58] <haibane> alright, let me tell you what makes unity unusable and see if you can work with me here. First, you know how I have to Right clicke to get to a category of apps, then I have to left click on that category to get a list of icons of my apps.  Can you make an icon that I Left click to get a menu of my apps like gnome 2?
[20:59] <haibane> and lastly, I need different sessions of the same applications all the time. It works best when I have all those things in tabs on my taskbar like gnome 2, windows, and every sane interface since the invention of the gui. Is there anyway to add that functionality to unity
[21:02] <haibane> thats it really. the glowing icon thing is unusable and confusing. I can deal with the whole "disappearing" universal menu thing that only works half the time and I can deal with the fact that your disappearing taskbar that only works half the time. If I had those two things, even if they were hidden in settings or whatnot. I could deal
[21:24] <davidcalle> Haibane, hi. You should try Unity in 11.10, your first complaint is fixed there.
[21:26] <haibane> how so?
[21:31] <haibane> davidcalle: I have used unity in 11:10. Its not fixed, you have media apps and internet apps (woohoo, two whole categories, still giant icons) and find files which doesn't actually find any files.
[21:33] <haibane> if when clicking the ubuntu icon, it send me to find apps. It would probably be a bit better but ugh.. alright. I can live with that I guess.
[21:34] <haibane> erm, find files. which is find applications not files
[21:36] <haibane> and why the heck would you try to use so many 3d effects when 2d open source drivers work great and the 3d drivers work only a quarter of the time and sometimes the fallback crashes the whole os?
[21:39] <haibane> well, on a good note. Its better then gnome 3. Which has alienated everyone ever. I had one guy i installed ubuntu for complain about unity. I showed him gnome 3, eyes like dinner plates
[21:44] <haibane> any chance that the taskbar can be fixed so it doesn't try to copy windows 7/osx?
[22:03] <haibane> well, i hope for the next version these things are included. have to do some more work
[23:31] <Pablo___> hi
[23:32] <Pablo___> could you tell me how to move side bar where lauchers are placed?
[23:33] <Pablo___> I want to put it on low edge


[09:24] <somethinginteres> hello all I am trying to install the Shepherd EPG grabber but I seem to be missing a dependency that I think is causing guide data to not make its way into MythTV libjavascript-perl I try 'apt-get' but the package isn't listed in synaptic on Maverick. Any help?
[09:34] <somethinginteres> situation resolved the fix is listed on the Shepherd site
[10:55] <Yammeh> Hi, I was just curious if someone could help me troubleshoot installing installing mythbuntu
[10:56] <Yammeh> I'm trying to install from USB onto a memory card on an Acer Revo and it's just getting stuck on the mythbuntu with the dots underneath after selecting install mythbuntu
[15:08] <spydmobile> hi there, im on mythbuntu auto builds. when I turned on the mythweb plug in in mythbuntu control center, and fired it up I get : Incompatible protocol version (mythweb=50, backend=56)
[15:08] <spydmobile> how do I correct this odd version mismatch?
[15:22] <Patrickdk> looks like mythweb needs to be upgraded
[17:49] <tgm4883> spydmobile, what is the output of
[17:49] <tgm4883> dpkg -l mythweb mythtv-backend
[19:20] <BajK> hey, I just bought a new 24" 16:9 screen and wanted to set up a little tv box for my living room. the pc is rather old, 512 mb ram, and a ATI All-in-wonder Radeon 9000 with 64 mb ram, I know those cards are hardly supported but is there a way of making it run with mythbuntu/mythtv? I have a working windows installation with drivers installed, I read something that you need some of the files from the ati tv
[19:20] <BajK> program but i dont know
[19:20] <BajK> is there a good tutorial on this?
[23:32] <spydmobile> tgm4883: Hi thanks, output is here: http://mythbuntu.pastebin.com/ycJVgjGv
[23:32] <Zinn> [mythbuntu.pastebin.com] Desired=Unknown/Install/Remove/Purge/Hold | Statu
[23:35] <tgm4883> spydmobile, you have 0.22 mythweb installed and 0.23 mythbackend
[23:35] <tgm4883> how did you do that?
[23:36] <tgm4883> spydmobile, what version of Mythbuntu are you running?
[23:45] <spydmobile> i am on the autobuild system so I long since stopped paying attention to which version, and it has given me no trouble til now. How I did it? umm I just opened mythbuntu control center and turned on mythweb
[23:46] <spydmobile> should i remove the mythweb package and try again?
[23:46] <spydmobile> using MCC i mena
[23:46] <spydmobile> ^^^mean
[23:47] <spydmobile> tgm4883: Sorrey I should have used your nick here.....
[23:52] <tgm4883> spydmobile, what version of mythbuntu are you using?
[23:53] <spydmobile> tgm4883: 9.10 Linux mythbackend 2.6.31-22-generic #70-Ubuntu SMP Wed Dec 1 23:48:17 UTC 2010 x86_64 GNU/Linux
[23:55] <tgm4883> Do you still have mythbuntu-repos installed?
[23:55] <spydmobile> not to sure, how would i check from the shell , I am SSHed in...
[23:56] <tgm4883> dpkg -l mythbuntu-repos
[23:56] <tgm4883> or you could 'cat /etc/apt/sources.list.d/mythbuntu-repos.list'
[23:56] <tgm4883> the 2nd command actually tells us what I need to know
[23:56] <spydmobile> ok 1st said:  mythbuntu-repo 8.3-0ubuntu0+m Mythbuntu repos installer ill do the second
[23:57] <spydmobile> tgm4883:  nothin :(
[23:57] <tgm4883> spydmobile, ok, do this
[23:57] <tgm4883> dpkg-reconfigure mythbuntu-repos
[23:58] <tgm4883> then configure it to get you the updates you want (eg. 0.23)
[23:58] <tgm4883> then just upgrade your system as normal


[00:37] <fatgoose> anyone know how to get the kube-controller-manager log from a k8s (the canonical distribution of kubernetes) deployment?
[00:37] <fatgoose> where is it on the master node?
[00:43] <thumper> unfortunately many of the k8s charmers are in the USA and past EOD
[04:51] <tvansteenburgh> if fatgoose comes back, the answer is:
[04:51] <tvansteenburgh> juju ssh kubernetes-master/0 -- journalctl -o cat -u snap.kube-controller-manager.daemon.service
[18:26] <magicaltrout> docker crashes when removing containers \o/
[18:38] <rick_h> magicaltrout: howdy, and :(
[18:38] <rick_h> magicaltrout: I wanted to make sure you saw https://blog.jujugui.org/2018/01/03/accessing-the-juju-cli-from-within-the-gui/ and see if your folks had a chance to try it out
[18:53] <rick_h> have to pull the plug on the juju show due to some issues on my end today folks. Apologies for all of you looking forward to hearing my dulcet tones again after the new year
[19:06] <kwmonroe> bummer rick_h - i have wicked allergies today and was hoping to have an opportunity to blow my nose on youtube.
[19:06] <rick_h> kwmonroe: lol sorry man
[21:16] <jhobbs> is there a way to show the current space bindings for an application?
[21:22] <thumper> jhobbs: does it show in the yaml status?
[21:24] <jhobbs> no thumper
[21:29] <kwmonroe> jhobbs: does 'juju list-spaces [--format yaml]' show the apps for each space?
[21:30] <jhobbs> kwmonroe: no
[21:30] <kwmonroe> i don't have an env to test atm, but i'll keep my fingers crossed that it does
[21:30] <kwmonroe> doh


[06:17] <Noskcaj> jared, I just got home from brisbane and the stickers are here. Thanks for sending so many
[09:27] <jared> Noskcaj10: no problem, I'm sorry I didn't keep the other ones I had
[09:27] <Noskcaj10> don't worry. i've got more than enough for everything except my list of flavors
[09:32] <jared> Noskcaj10: cool, glad they're useful :)
[16:20] <mesquka> Hi


[21:28] <horus87> Hello everyone,
[21:28] <horus87> I recently joined the Ubuntu Kernel Team just a few hours ago.
[21:28] <horus87> I'm incredibly excited about this opportunity, and if any of you have suggestions, I'd be more than glad to hear them.
[21:28] <horus87> Thank you!


[01:48] <duflu> AlbertA: still around?
[02:21] <AlbertA> duflu: just for a bit
[02:21] <AlbertA> duflu: how is it going?
[02:22] <duflu> AlbertA: OK, I swear you fixed this already, or something like it? https://bugs.launchpad.net/mir/+bug/1406725
[02:24] <AlbertA> duflu: I fixed one for "software" buffers... does flicker use software buffers?
[02:24] <duflu> AlbertA: Yep. And I found in a related bug it seriously breaks arale too :)
[02:24] <duflu> https://bugs.launchpad.net/mir/+bug/1498806
[02:25] <duflu> which may be related
[02:26] <AlbertA> duflu: interesting... I hope HWC is not leaking the fds
[02:27] <AlbertA> duflu: the fix for the graphical corruptions were the flags in AndroidAllocAdaptor::convert_to_android_usage
[02:28] <duflu> AlbertA: Although treat them as separate bugs. The primary issue is the corruption which happens on mako with Xmir too. And mako does not have the fd leak
[02:29] <AlbertA> duflu: the flags in lp:mir look correct.
[02:31] <duflu> AlbertA: The least buggy form of corruption is when you just get in-surface tearing. So that combined with the fd leak shows our android buffer fencing isn't working
[02:31] <duflu> I guess that could reveal apparent corruption too
[02:32] <AlbertA> duflu: right
[02:32] <duflu> AlbertA: Never mind, and good night. I have endless tangents if you linger too long
[02:32] <AlbertA> I wonder what changed....
[02:32] <AlbertA> is this a regression? or did you just notice it now?
[02:33] <duflu> AlbertA: AFAIK it's never works
[02:33] <duflu> worked
[02:33] <AlbertA> ok
[02:35] <RAOF> Can I plz haz jenkins & merge proposals on launchpad git? Grr.
[02:37] <duflu> RAOF: Merge proposals for LP git exist. I've done one!
[02:37] <RAOF> I can't propose a merge into lp:mir though!
[02:38] <duflu> That's true. Mir is not git yet though
[02:39] <duflu> BTW did wily break? https://bugs.launchpad.net/mir/+bug/1499134
[02:39] <duflu> Fully updated wily can't even build our stable branches any more
[02:40]  * RAOF updates to check!
[02:40] <RAOF> Plausibly; we've got mesa 11.0 now.
[02:40] <duflu> Woo, good news then
[02:40] <duflu> But we should build too
[02:53] <RAOF> Hm. I think it's actually mir that's broken...
[02:56] <RAOF> Heh, yes.
[02:57] <duflu> That's why I left Mir tasks open :)
[03:08] <robert_ancell> duflu, hmm, that merge commit seems to be confusing git rebase. I think we should just rebase on xmir-1.17 and you can keep your changes on another branch if you want them. Note that all this history will ultimately be lost when we go upstream.
[03:22] <duflu> robert_ancell: Do what you need to. Just don't lose yesterday's additional fix... Also I think next time we should aim to merge without clobbering history. It's OK to lose the history when upstreaming, but very annoying when you're mid-sprint and can't see what you've just done
[03:23] <robert_ancell> duflu, I think you should treat xmir-1.17 branch as upstream and just maintain a branch with your changes. git doesn't seem to handle keeping history around
[03:25] <duflu> robert_ancell: git does. And in fact it did by accident yesterday. I'm just saying that accident is what git should be doing and is meant to do anyway
[03:25] <robert_ancell> duflu, but git rebase is horribly confused after you made that change. So I can't effectively rebase anymore.
[03:26] <duflu> robert_ancell: Sorry, all I did was pull then push. Normal activities so I guess we need to find out where it went wrong
[03:29] <duflu> robert_ancell: I'll stay hands off for a while so if you want to forcefully overwrite things to fix it, go ahead.
[03:29] <robert_ancell> duflu, all fixed now
[03:29] <duflu> I'm still worried that git automagically created this situation....
[03:29] <duflu> "you're holding it wrong"
[03:30] <robert_ancell> Not surprised in the least with git :)
[03:31] <duflu> The whole point of non-numerical revision IDs is that they get to stay around and don't get confused by merges
[03:32] <robert_ancell> Oh, the changes will always remain. Just I don't think the tools can handle a branch being both rebased and merged at the same time.
[03:34] <duflu> robert_ancell: So is simply 'push, edit, commit, push' wrong?
[03:34] <duflu> 'pull, edit, commit, push'
[03:34] <robert_ancell> I *think* git pull -r might do it right.
[03:35] <robert_ancell> i.e. you should rebase on xmir-1.17 instead of merging.
[03:35] <robert_ancell> The other option is to keep on another branch and then rebase those changes into xmir-1.17 periodically (i.e. when we release packages)
[03:36] <robert_ancell> I'm open to better ideas but I found it very hard to generate the actual patches from a branch with full history.
[03:36] <duflu> robert_ancell: git diff <oldrev> HEAD ?
[03:37] <duflu> Something like that was working for me
[03:37] <duflu> We need some solution that doesn't require deleting commit history so often...
[03:37] <duflu> Or ever
[03:38] <robert_ancell> duflu, the history is never deleted - keep it on another branch if you want
[03:38] <robert_ancell> git diff doesn't handle having more than one change like we do
[03:38] <duflu> robert_ancell: The history should be visible on launchpad. If we need another branch on LP?....
[03:39] <duflu> It's not OK to lose history of what you've done
[03:39] <duflu> And not OK to say, you should keep it locally
[03:39] <robert_ancell> duflu, just put it on another branch.
[03:42] <duflu> robert_ancell: Essentially I want to know the URL of the "trunk" that shows everyone's workings
[03:43] <duflu> That used to be https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/ but not now
[03:43] <robert_ancell> duflu, The xmir-1.17 branch is a) the patches that go into the .debs and b) what we will propose upstream. It's never been anything else.
[03:44] <duflu> robert_ancell: Losing history is still not OK. I don't expect our history to be visible upstream, but it should always be visible on LP
[03:44] <robert_ancell> THEN PUT IT IN ANOTHER BRANCH
[03:46] <duflu> robert_ancell: I'm considering it, but the same problem will reoccur when that gets 'rebased'. So still needs fixing
[03:48] <duflu> robert_ancell: So we'd need one new branch for each "sprint" right? So that branch with the history never needs rebasing in itself
[03:48] <robert_ancell> duflu, you could just make a branch xmir-1.17-trunk and use that for development
[03:49] <robert_ancell> or we could rename xmir-1.17 to xmir-1.17-rebased
[03:50] <duflu> robert_ancell: AFAICT git merge -p solves it
[03:52] <robert_ancell> yay, git merge --help mentions -p in an example but doesn't define it...
[03:52] <duflu> robert_ancell: Oops, I mean git rebase -p
[03:54] <duflu> Although when you're ready to upstream, then you don't use -p  maybe
[03:54] <RAOF> Hm. We actually need the android NDK around to build Mir now.
[03:54] <duflu> RAOF: It appears that way. Why did it work up to yesterday?
[03:54] <RAOF> Because mesa was using a 4 year old version of Khronos' eglplatform.h
[03:55] <RAOF> Oh, sorry. 5 year old.\
[03:55] <duflu> RAOF: Oh didn't we have the missing bits in 3rd_party? Just got cleaned out recently by alan_g
[03:55] <duflu> He removed "unused" files
[03:57] <RAOF> Oh, good catch. Yes, native_window.h was one of those.
[03:57] <RAOF> It *was* unused ;)
[03:57] <duflu> robert_ancell: I think we need just one new branch in LP. One that keeps history (rebase -p) and one for upstreaming preparation (rebase)
[03:58] <robert_ancell> duflu, well, we have that second one and you're welcome to keep the first if you want it.
[03:58] <robert_ancell> s/keep/create/
[04:00] <duflu> robert_ancell: I'll look into it... are we tied to the existing branch name xmir-1.17 too?
[04:00] <robert_ancell> duflu, nope, the name is fairly arbitrary. It's just 1.17 because at some point we'll need to rebase on 1.18
[04:12] <robert_ancell> Is something weird going on in vivid with Mir? My silo is failing on amd64, armhf and i386 with a missing mir_toolkit/mesa/platform_operation.h. Builds fine on the other architectures
[04:43] <duflu> robert_ancell: OK, I've created the two newly named branches. Can we delete the old (duplicate) one now?
[04:44] <duflu> Or rename it
[04:44] <duflu> I might try
[04:45] <robert_ancell> duflu, is -development supposed to have all the history in it?
[04:45] <duflu> robert_ancell: Yep
[04:45] <RAOF> duflu: If you need it, https://code.launchpad.net/~raof/mir/fix-ftbfs-against-mesa-11/+merge/272203
[04:45] <robert_ancell> It doesn't appear to here
[04:45] <robert_ancell> oh, hang on
[04:45] <duflu> RAOF: Ta
[04:47] <robert_ancell> duflu, ok, now I see a single merge commit
[04:48] <duflu> robert_ancell: Yeah merge seems much more friendly than rebase. The latter is designed to clobber history
[04:49] <robert_ancell> was there a reason why you didn't set xmir-1.17-development to your old pre-rebased branch?
[04:51] <duflu> robert_ancell: If that's what I think you mean then it contained history of the breakage. So best to not confuse git with the brokenness in the history
[05:00] <robert_ancell> bye all
[05:03] <duflu> robert_ancell: Bye
[06:20] <anpok> RAOF: shouldnt that header be part of android-headers?
[06:22] <RAOF> anpok: I don't think so, no. android-headers is for bits of AOSP that we need, right?
[06:22] <RAOF> native_window.h is a part of the NDK.
[06:27] <anpok> RAOF: not sure if that is relevant but it defines the native window but not those functions..
[06:28] <RAOF> Not relevant at all; all we need of it is “struct ANativeWindow;”
[06:28] <RAOF> (That's all EGL needs of it, at least)
[06:46] <duflu> RAOF: I would have top approved but Jenkins has found all sorts of fail
[06:46] <duflu> Can't see how it's related
[06:47] <RAOF> I believe the answer is “it isn't”
[06:47] <RAOF> Do we need to build 0.15/0.16 on wily?
[06:48] <duflu> RAOF: Is that a trick question? What other Mir version do you intend to put in wily archive?
[06:48] <guest42315> 0.17 pls
[06:48] <RAOF> 0.17, of course!
[06:48] <duflu> Hah
[06:48] <guest42315> :P
[06:49] <duflu> Let's release 0.16.0 first.
[06:49] <duflu> To wily
[06:49] <RAOF> Spoil sport :P
[06:50]  * duflu is waiting for Mir 0.42 personally
[06:50] <duflu> Which oddly still happens before 1.0 is reached
[06:50]  * RAOF presses the Jenkins retry button.
[06:50] <duflu> RAOF: Works on my machine anyway
[06:51] <duflu> And presumably yours too
[06:51] <RAOF> Indeed.
[08:39]  * guest42315 they see me rollin' la la la
[09:09] <duflu> alf_: Didn't you kill the auth magic stuff? It's still used in Xmir
[09:11] <duflu> Or is that OK and it's wrapped as a platform message?
[09:11] <alf_> duflu: But through platform operations right?
[09:11] <duflu> alf_:  hw/xmir/xmir-dri2.c:        msg = mir_platform_message_create(auth_magic);
[09:11] <duflu> Is that current/safe?
[09:11] <alf_> duflu: yes, so only the direct drm stuff was removed from the API and we replaced them with platform ops
[09:12] <duflu> alf_: OK thanks
[10:05] <Saviq> hey guys, any idea why the new mir is in UNAPPROVED queue? sounds like wily feature freeze is starting to bite us?
[10:07] <alan_g> Saviq: first I've heard (camako has been working this release), I thought yesterday it just needed to re-sync qtmir.
[10:09] <Saviq> alan_g, oh yeah it's past QA and all, it's published, but says mir is in UNAPPROVED, I think that's because of FF in effect