[07:06] <wgz> happy pre-morning all
[07:07] <fullermd> Oh no, not another one.
[07:10] <SamB> fullermd: they come once per day, dude
[07:12] <wgz> he can always hope, some day that may change.
[07:13] <fullermd> I've devoted my life to the erradication of this horrific scourge upon mankind.
[07:59] <ZyX-I> How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)?
[09:52] <poolie> hi vila?
[09:53] <vila> poolie: hey !
[09:53] <poolie> hey, thanks for your reply about orphans
[09:53] <vila> mypleasure
[09:53] <poolie> i was just going to ask the same question as bialix, about whether/why this isn't linked in to the main doc tree
[09:53] <vila> oops, didn't say hi :-}
[09:53] <poolie> also, whether your mail is a vote against changing the default
[09:54] <vila> surely not, my vote is (and always been) to turn it on :)
[09:54] <vila> it has been in my bazaar.conf since day one
[09:55] <poolie> ok
[09:55] <vila> and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven
[09:55] <poolie> i have a branch
[09:55] <poolie> i was going to add some docs to the user guide too
[09:55] <vila> and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven't looked at how this should be achieved
[09:55] <vila> there is a bug titled 'config doc is ugly' or something
[09:56] <vila> that I think about as a way to track that
[09:56] <vila> the most important part was to *have* a doc for each option which has been going pretty well since we started to migrate
[09:58] <poolie> yeah
[09:58] <poolie> fixing this together with deleting the ugly hardcoded doc would be good
[10:29] <ZyX-I> How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)?
[10:40] <LeoNerd> Define "get" ?
[10:40] <LeoNerd> You can know it, by  bzr revno
[10:40] <LeoNerd> You can refer to it if needed explicitly by -1, because negative revnos count backwards from the top
[10:44] <ZyX-I> LeoNerd: It is answer to my question?
[10:44] <LeoNerd> Yes
[10:45] <ZyX-I> LeoNerd: Try the following: “bzr branch lp:bzr && pushd bzr && bzr update -r -2 && bzr log -r revno:-1”. I do see revision 6472 in the output
[10:45] <ZyX-I> But I must see 6471 here
[10:45] <LeoNerd> ?
[10:45] <LeoNerd> bzr log -r-1
[10:45] <LeoNerd> Is sufficient
[10:45] <ZyX-I> LeoNerd: Exactly the same.
[10:46] <LeoNerd> Oh I see, you updated to -2
[10:46] <ZyX-I> LeoNerd: It does not show currently checked out revision
[10:46] <LeoNerd> Yes it does. It shows the -checked out- revision
[10:46] <LeoNerd> Which is now earlier, because you  up -r-2 'ed
[10:47] <ZyX-I> LeoNerd: I have checked out revision 6471 which is -2. “bzr log -r -1” shows 6472
[10:49] <ZyX-I> LeoNerd: Maybe there is a problem with understanding term “checked out”. In mercurial terms it “currently checked out rev” = “working directory parent”.
[10:54] <ZyX-I> I am surprised there is no simple answer to such question. I bet I would have got “use HEAD/./BASE as revision argument” answers on git/mercurial/svn channels just after somebody saw my question.
[10:55] <fullermd> If you want the working tree rev, you want revno --tree (or various other incantations for revid)
[10:57] <LeoNerd> Ya, it's a rare situation
[10:57] <LeoNerd> 99.9% of the time the revno of the checkout == the revno of the branch
[10:57] <LeoNerd> Your  update -r ...  has specifically gone and changed that
[10:58] <ZyX-I> fullermd: Thanks. Thus “bzr log -r $(bzr revno --tree)” is the only way to get message for working directory parent?
[10:59] <fullermd> Probably.  I have vague recollection of discussion about a tree: revspec, but I don't see it listed in the help, so it probably never got implemented.
[10:59] <LeoNerd> I don't understand this phrase "working directory parent"
[10:59] <LeoNerd> Working directory is a UNIX concept, the CWD of a process.
[10:59] <LeoNerd> The things important here are the checkout, and the branch.
[11:00] <fullermd> "working tree" would be the more common VCS-world term.
[11:00] <LeoNerd> Both have a (latest) revno concept. Normally the checkout is a copy of some revision of a branch, possibly including some local modifications that will become the next revision
[11:00] <LeoNerd> Normally, the checkout is a copy of the latest revision in the branch. So normally  bzr revno  and so on is unambiguous
[11:01] <LeoNerd> But specifically in your situation you rolled back the checkout to an earlier revision from the branch, so now you have two different "latest"s, depending whether you asked the branch (6472) or the checkout (6471)
[11:03] <ZyX-I> LeoNerd: “working directory parent” is how revision “.” is described in “hg help revisions”.
[11:03] <LeoNerd> Yah, please read what I just wrote :)
[11:04] <vila> right, that would be basis revision for the working tree in bzr speak
[11:07] <vila> ZyX-I: I think the initial confusion is that 'bzr log' always refers to the branch tip (which is almost always the same as the working tree (wt) basis revision)
[11:08] <vila> ZyX-I: instead of 'bzr update -r-2' you could have used 'bzr pull -r -2' and your wt will have pointed to the branch tip
[11:08] <vila> ZyX-I: but may be I don't understand what you were trying to achieve ?
[11:10] <ZyX-I> vila: No. Initial confusion is that all other VCS I have to support mention basis revision in either “vcs help revisions” (hg,git) or directly in the description of every command supporting revision arguments (svn). Only bzr requires use of the separate command.
[11:10] <vila> that doesn't tell me what you're trying to achieve :-/
[11:11] <ZyX-I> vila: I want to make vim-addon-manager distinguish between cases “‘bzr pull’ has updated something” and “‘bzr pull’ did not touch working tree”.
[11:12] <vila> right, so better avoid 'bzr update' then, 'bzr pull' outputs 'No revision to pull' if nothing has changed IIRC
[11:13] <ZyX-I> vila: I don’t do “bzr update”. But the user may  have done it.
[11:14] <ZyX-I> vila: If there are revisions to pull, but basis revision/=tip revision, “bzr pull” won’t update anything like other “vcs pull”, will it?
[11:16] <vila> hmm, I dunno for other VCSs but I think 'bzr pull' doesn't require a clean wt to pull, it merges the uncommitted changes if there are any instead
[11:16] <fullermd> Not relevant to the question   ;p
[11:17] <vila> meh, the question, as I read it was: will pull do something if revisions are missing in the branch even if the wt basis revisions is not tip anymore
[11:17] <fullermd> No, bzr pull will force the tree up to the new head rev.  That may or may not be a bug...
[11:18] <fullermd> In hg, pull will always pull the branch, and not touch the tree.  You'd need a separate update, or a pull -u to get it to touch the tree too.
[11:18] <vila> ha right, I never ends up in setups where wt basis revision != branch tip
[11:18] <fullermd> That explains the years it took to land update -r...   :p
[11:19] <vila> right, pull updating the wt if there is one matches my use cases...
[11:19] <vila> hehe
[11:19] <vila> probably, but I'm only one user, others have different workflows ;)
[11:19] <fullermd> I'm not entirely sure it should when it's not the previous tip.  That seems like it may be slightly surprising.
[11:20] <vila> right, seems weird to me too, but I don't know the workflows involved hence my remark
[11:20] <vila> well, s/don't know/don't have enough practice with/
[11:21] <fullermd> It's probably never come up or been explictly questioned at all.  Just Happens(tm).
[11:22] <vila> I always thought that if you want to get a tree not based on your branch, it's only temporary (since you will commit on tip anyway)
[11:22] <vila> that bzr doesn't warn or block in these cases is probably a bug in itself
[11:22] <fullermd> I can't think of an obvious case where you'd want to pull, AND maintain that explicit older rev.  Still, it feels more like the right choice.
[11:23] <fullermd> If I update -r, I'm telling bzr, I want the tree on that rev specifically; I'm not sure later saying 'pull' is best interpreted as "undo my update too".
[11:23]  * vila nods
[11:23] <fullermd> You could make a case either way I guess.  Just never been actually argued, TTBOMK, so we get the emergant behavior.
[11:24] <vila> add a --strict to pull ?
[11:24] <fullermd> Well, that also opens up the can of --overwrite worms.
[11:24] <vila> yeah, exactly
[11:25] <fullermd> Plus we'll get to tackle the bound branches arguments all over again.
[11:25] <vila> I can't hear you ?
[11:25] <fullermd> Would be fun, of course.  But I don't really have the time for that...
[11:54] <jelmer> vila: could I perhaps trouble you with two reviews?
[11:55] <jelmer> https://code.launchpad.net/~jelmer/bzr/use-tree-iter-children/+merge/93609 and https://code.launchpad.net/~jelmer/bzr/iter-child-entries/+merge/93993
[12:01] <vila> jelmer: I'm gently landing the eggs I'm juggling with and was about to lunch, will have a look after that
[12:02] <jelmer> vila: maybe you should have eggs for lunch ? :P
[12:02] <jelmer> vila: anyway, thanks :)
[12:02] <vila> hehe
[14:22] <vila> jelmer: reviewed
[14:25] <jelmer> vila: danke!
[16:00] <pilot419> I branched a working copy from remote, i want to create a experiment branch from checked out copy
[16:01] <mgz> go ahead and do that then :)
[16:01] <pilot419> But bzr creating a seperate directory <experiment>
[16:02] <pilot419> So i had to configure ide to experiment branch
[16:02] <mgz> seperate dirs are the default if you only want one tree to avoid confusing your ide, you can use switch,
[16:03] <mgz> either with the current beta and colocated branches,
[16:04] <mgz> or by reconfiguring your setup so you have a lightweight checkout and two different treeless branches
[16:05] <pilot419> it's more difficult than Git :s
[16:07] <mgz> currently there's an extra step you need to begin with, yes
[16:08] <mgz> what version of bzr are you using currently?
[16:08] <pilot419> 2.4
[16:11] <pilot419> So branching from remote will be normal bzr branch <remote> project
[16:13] <pilot419> Next i need to create lite
[16:14] <mgz> okay, so you can either use the bzr-colo plugin, or do what I do
[16:14] <mgz> the first requires some specific forms to address branches, see the documentation
[16:15] <mgz> for the treeless branches thing, you do: `bzr init-repo --no-trees PROJECT`
[16:16] <mgz> then `bzr branch REMOTE PROJECT/trunk` (remote can be the local branch you already have, if you then change it's parent)
[16:16] <mgz> then `bzr checkout --lightweight PROJECT/trunk PROJECT/tree`
[16:16] <mgz> you can point your IDE at the tree folder
[16:17] <pilot419> ok
[16:17] <mgz> and create a new feature branch from in there with `cd PROJECT/tree && bzr switch -b feature`
[16:17] <mgz> merging and other things that need branch references you just point at the branch locations you have in the filesystem
[16:23] <pilot419> Ok maybe i got it
[16:26] <pilot419> mgz: Thanks man
[21:47] <wilx> Hi.
[21:47] <wilx> What is the best way to convert whole SVN repo to BZR?
[21:47] <wilx> So far I was not able to arive to satisfactory result.
[21:47] <bob2> what happened when you tried bzr-svn?
[21:48] <wilx> The best so far seems conversion based on svn2git -> fasexport from GIT -> fastimport to BZR.
[21:48] <bob2> note that oddly managed svn repos will suck to import into anything else
[21:48] <wilx> bob2: It seems to convert only a single branch at once.
[21:48] <mgedmin> there's also svn-all-fast-export
[21:48] <wilx> mgedmin: Where is that?
[21:49] <mgedmin> apt-get install svn-all-fast-export, or http://repo.or.cz/w/svn-all-fast-export.git
[21:49] <mgedmin> I just learned about it the other day
[21:49] <mgedmin> seems to be very fast
[21:50] <mgedmin> and you can define rules to straighten out quirks in a messy svn history
[21:52] <wilx> http://gitorious.org/svn2git/
[21:52] <wilx> That seems like a older version of svn2git.
[21:53] <wilx> I have a fastexport file that it created. It contains branch "1.1" but bzr fastimport never creates this one branch. It also ignores many of the merges.
[21:53] <mgedmin> what about https://github.com/nirvdrum/svn2git ?
[21:53] <mgedmin> I'm confused -- are there two different tools both called svn2git?
[21:54] <wilx> mgedmin: It looks more like forks of the same source.
[21:54] <mgedmin> I recently watched a linuxconf.au video about svn -> git conversion tools
[21:55] <mgedmin> the guy mentioned three existing ones, described their downsides (two couldn't handle messy conversions, the last one was too slow, iirc) and told how they wrote a fourth tool based on those
[21:55] <mgedmin> unfortunately I don't remember any of the tool names
[21:55] <mgedmin> I wonder if svn-all-fast-export is that fourth tool
[21:56] <mgedmin> btw, re: "It seems to convert only a single branch at once."
[21:56] <mgedmin> bzr svn-import should be able to handle multiple branches
[21:56] <mgedmin> afaiu
[21:58] <wilx> http://barrbrain.github.com/svn-dump-fast-export/
[21:58] <wilx> This is the one from the video, I think.
[21:58] <wilx> I believe it did not work well either. Let me retest.
[22:05] <jelmer> wilx: 'bzr svn-import' will indeed import all branches from the repository
[22:06] <wilx> Ah, right, it crashed, the http://barrbrain.github.com/svn-dump-fast-export/ tool.
[22:16] <jelmer> fast-import isn't a great format for conversion that doesn't involve git, as it can only represent things that exist in git
[22:21] <wilx> Ah, I know why I did not like svn-import. It seems that it entirely ignores all merges.
[22:21] <wilx> Hmm...
[22:21] <wilx> But cherry pickings are not recored in bzr specially, right?
[22:21] <wilx> That might be it.
[22:22] <jelmer> wilx: yeah, they're indeed not recorded (yet). None of the DVCSes track cherry pick merges in their metadata yet.
[22:23] <mgedmin> I think arch used to :)
[22:23] <mgedmin> is it not a DVCS now?
[22:24] <wilx> Arch/TLA was weird.
[22:24] <fullermd> Darcs does too.
[22:24] <wilx> jelmer: Well, The SVN->GIT conversion did show some merges though.
[22:24] <fullermd> Probably need a 'conventional' in that sentence   8-}
[22:28] <jelmer> mgedmin: ah, sorry, yes - arch did indeed
[22:28] <mgedmin> don't mind me, I'm just trolling
[22:29] <mgedmin> when people say "DVCS" nowadays, they mean git + hg + bzr
[22:30] <fullermd> Actually, I'm pretty sure they mean "git".
[22:31] <fullermd> (see, _that's_ trolling!)
[22:43] <spiv> fullermd: really, I thought they meant "monotone or darcs" ;)
[22:43] <fullermd> Don't be such a fossil.
[22:43] <mgedmin> svk gets no love for some reason ;)
[22:59] <wilx> SVK seems like SVN with disconnected operations.
[22:59] <wilx> Not too distributed.
[22:59] <wilx> Though I have never used it seriously.
[23:14] <mwhudson> mgedmin: i have no idea why!!


 ello @all , anyone here experience freeze desktop in latest plasma?
[12:26] <BluesKaj> Hi all
[17:09] <mmikowski> myfenris: what type of graphics do you have? Intel or AMD?
 intel iris (re @IrcsomeBot: <mmikowski> myfenris: what type of graphics do you have? Intel or AMD?)
[18:15] <mmikowski> myfenris: We have found challenges on 12th and 13th-gen CPUs, causing intel GPUs to spam to the syslog and hang. These addressed through kernel parameters. These problems tend to occur when running Vulkan apps, however.
[18:16] <mmikowski> So I suggest you check your /var/log/syslog and see if you are seeing i915 errors. If so, then that may be the problem.
 im on 10th gen (re @IrcsomeBot: <mmikowski> myfenris: We have found challenges on 12th and 13th-gen CPUs, causing intel GPUs to spam to the syslog and hang. These addressed through kernel parameters. These problems tend to occur when running Vulkan apps, however.)
[22:24] <arraybolt3> @myfenris: You don't happen to have an application open that creates a *lot* of notifications, do you?
[22:25] <arraybolt3> If so, you might be running into this: https://bugs.kde.org/show_bug.cgi?id=458936
[22:25] -ubottu:#kubuntu-devel- KDE bug 458936 in plasmashell "Stability issues related to notifications (or images in them?) on debian testing/unstable" [Major, Unconfirmed]
 ok, thanks ... at least know what to check as previously i dont hv idea where to look at (re @IrcsomeBot: <mmikowski> So I suggest you check your /var/log/syslog and see if you are seeing i915 errors. If so, then that may be the problem.)
 not really the same to this bug (re @IrcsomeBot: <arraybolt3> If so, you might be running into this: https://bugs.kde.org/show_bug.cgi?id=458936)
[22:30] -ubottu:#kubuntu-devel- KDE bug 458936 in plasmashell "Stability issues related to notifications (or images in them?) on debian testing/unstable" [Major, Unconfirmed]
 but the desktop does unresponsive a few seconds and there is a time where it took longer time until it became black n white
 so far i check no errors related to i915 (re @IrcsomeBot: <mmikowski> So I suggest you check your /var/log/syslog and see if you are seeing i915 errors. If so, then that may be the problem.)
 and desktop shown a little bit blurry under 200% scale


[04:33] <inetpro> good morning
[04:34]  * inetpro eventually got precise-desktop-i386.iso downloaded... burning to usb now
[05:28] <nuvolari> mornings inetpro, sdehaan
[05:51] <inetpro> nuvolari: hiho
[07:02] <superfly> $#$%$%^$%^$ raining in summer!!
[07:03] <inetpro> superfly: huh?
[07:04]  * inetpro loves the rain, please send it here
[07:04] <superfly> inetpro: it's summer time... in Cape Town, that means it should be hot and dry, and it's not, it's cold and wet
[07:04] <inetpro> hmm...
[07:05]  * inetpro forgot that you guys are upside down :-)
[07:06] <inetpro> good morning superfly
[07:06] <superfly> morning inetpro :-)
[07:31] <nuvolari> hmm, what font do you guys use for coding?
[07:33] <superfly> nuvolari: Liberation Mono
[07:37] <zeref> purisa
[07:46] <superfly> morning maiatoday
[07:49] <nuvolari> zeref: and your code is working? :P
[07:49]  * nuvolari just had a look at purisa. shocking
[07:50] <fulcrum> morning
[07:50] <fulcrum> purisa?
[07:51] <nuvolari> fulcrum: fonts for programming
[07:52] <zeref> yeah
[07:52] <zeref> i use it in emacs
[07:52] <zeref> well actually my desktop theme is purisa
[07:56] <fulcrum> looks a neater version of comic...
[08:01] <maiatoday> hi superfly
[08:04] <nuvolari> /buffer 2
[08:15] <zeref> http://imgur.com/gallery/x0lj3 <<--- good way to start the morning
[13:50] <fulcrum> ok I tried... but Empathy sucks, ah back in the comfy arms of pidgin
[14:12] <nuvolari> fulcrum: like CLI much?
[14:18] <fulcrum> I CL lots
[14:20] <nuvolari> fulcrum: then what about CLI irc client + bitlbee?
[14:57] <superfly> oh hey, nuvolari, did you see, HIB4 is out!
[15:02] <nuvolari> superfly: affirmative! The audio track download for Jamestown is pretty cool
[15:03] <nuvolari> (the only thing I could check out today :P)
[15:04]  * nuvolari downloading NightSky just now
[15:16] <nuvolari> I don't know if it the idea of going on leave, but today was the most productive day this year :>
[15:16] <nuvolari> I think
[15:18] <zeref> nuvolari: how is precise?
[15:23] <fulcrum> nuvolari:  I use xchat for irc, I'm nost so sure about using text based for irc and/or IM
[15:24] <fulcrum> nuvolari:  will look it up though...
[15:33] <nuvolari> zeref: eh?
[15:33] <nuvolari> I don't understand
[15:40] <zeref> didnt you download 12.04 alpha?
[15:41] <nuvolari> zeref: me? nope :P
[15:46] <zeref> oh :P
[16:49] <inetpro> tumbleweed: how often does the daily iso get updated?
[16:49]  * inetpro just noticed changes between now and this morning
[16:51] <tumbleweed> daily, but new kernels are only uploaded every few days. Unfortunatly, all we've really determined here is that the bug still exists
[16:51] <tumbleweed> somebody needs to fix it...
[16:57] <inetpro> tumbleweed: thanks, I was just wondering
[16:58] <inetpro> I'll keep lurking in #ubuntu-x but please let me know if you see something happening there
[17:00] <inetpro> that is in case I miss it
[17:01]  * inetpro will be afk more often in the next few days
[17:02] <inetpro> but I will try to checkin as much as possible
[17:05] <inetpro> tumbleweed: but I was just wondering anyway how often that ISO is updated in a day
[17:05] <inetpro> because it seems to me that it is more than once
[17:07] <tumbleweed> normally once.