[06:09] <fullermd> Sheesh, it's quiet today.  Did I miss a memo about a picnic?
[06:26] <quik_> hey folks
[06:27] <quik_> if `bzr break-lock` isn't breaking the lock set yesterday.. what does one do?
[06:27] <Peng> quik_: Are you running it on the URL of the locked branch?
[06:28] <quik_> eh?
[06:28] <Peng> quik_: Are you trying to break the lock on your local branch or the server you push to or what?
[06:28] <quik_> the server I want to push to
[06:28] <Peng> quik_: Does "bzr break-lock" prompt you about the lock or do nothing?
[06:29] <quik_> seemingly, nothing
[06:29] <Peng> quik_: You need to pass it the URL of the branch. "bzr break-lock sftp://..." or whatever.
[06:30] <quik_> ah right
[06:31] <Peng> :)
[06:31] <quik_> thanks Peng
[06:32] <Peng> You're welcome. :)
[07:50] <jmhodges> hey, i can't bzr rspush to, for instance, deploy@foobar:~/thing. it tells me its not a branch or empty directory.  however, i have previously bzr pushed to that same directory.  is this a problem with the macports install of bzr and bzrtools or am i missing something?
[07:52] <fullermd> Yes   :)
[07:52] <fullermd> I have no real knowledge of the domain.  But I have a hard time picturing a way the install could be horked up, and it would work well enough to run, but be broken enough to look in the wrong place.
[07:53] <fullermd> You sure you're not accidentally push'ing instead of rspush'ing?
[08:19] <lifeless> jmhodges: what does ls -l of that directory show ?
[08:20] <jmhodges> lifeless: not the place for unix quesions. this is #bzr
[08:20] <jmhodges> lifeless: the #linux or #bsd or whatever you're on :)
[08:20] <jmhodges> s/the/try/
[08:20] <lifeless> jmhodges: also rspush is very old; you may prefer push + jam's post-push rsync plugin
[08:20] <lifeless> jmhodges: I'm helping you debug it, but whatever.
[08:21] <jmhodges> lifeless: jesus i'm sorry i misread
[08:21] <lifeless> jmhodges: I'm one of the core authors of bzr.
[08:21] <lifeless> jmhodges: still, I meant 'ls -al'
[08:21] <jmhodges> lifeless: i thought you asked me what ls -l always does
[08:21] <jmhodges> lifeless: like a newbie asking a question about ls
[08:21] <lifeless> heh
[08:21] <jmhodges> lifeless: i was like "wtf? havnt i seen this guy here before?"
[08:21] <jmhodges> sorry
[08:21] <jmhodges> one sec
[08:22] <jmhodges> lifeless: its just .bzr
[08:22] <lifeless> ok
[08:22] <jmhodges> lifeless: from the pushes i did before
[08:22] <lifeless> cat .bzr/branch-format, and .bzr/repository/format
[08:22] <jmhodges> lifeless: locally or in the remote?
[08:22] <lifeless> in the remote
[08:23] <jmhodges> branch-format: Bazaar-NG meta directory, format 1   and format: Bazaar pack repository format 1 (needs bzr 0.92)
[08:23] <jmhodges> that looks.. wrong somehow
[08:23] <jmhodges> bzr --version says "Bazaar (bzr) 1.0.0"
[08:24] <lifeless> ok, thats all good
[08:24] <jmhodges> yay
[08:24] <lifeless> the most likely thing then is that the path you are giving is not resolving correctly; could you try an absolute path ?
[08:24] <lifeless> deploy@foobar:/path/to/thing
[08:24]  * jmhodges nods
[08:25] <jmhodges> one sec, need to ci some changes
[08:26] <jmhodges> bzr rspush deploy@biggecko:/home/deploy/bzr/atelier-main # => bzr: ERROR: Remote location is not a bzr branch (or empty directory)
[08:26] <jmhodges> lifeless: ^
[08:37] <jmhodges> lifeless: again, sorry for being a jerk earlier.  i blame the couple of hours of sleep i've been getting for the past week and my own inattention.
[08:37] <lifeless> interesting
[08:37] <fullermd> Does rspush stuff anything in .bzr.log?
[08:37] <lifeless> forget about it
[08:38] <lifeless> jmhodges: I really recommend you try jam's plugin instead of rspush
[08:38] <lifeless> jmhodges: it ssh's in and runs bzr update
[08:38] <jmhodges> lifeless: jams plugin?
[08:38] <jmhodges> i've been out of bzr for too long
[08:38]  * jmhodges googles
[08:38] <fullermd> push-and-update, I think.
[08:38] <fullermd> Something like that.
[08:39] <jmhodges> fullermd: that's it
[08:40] <jmhodges> cool.  i'm assuming then that speed gains of rspush aren't worth other problems that i dont know about (other than "it not working")?
[08:40] <lifeless> oh, rspush is likely slower
[08:40] <fullermd> Actually, with packs, the speed gains of rspush can become very negative.
[08:40] <jmhodges> ohhh
[08:40] <jmhodges> thanks!
[08:41] <jmhodges> i'll just grab it out of trunk then.  thanks again
[08:47] <jmhodges> hm.. it pushes fine, and the command shows up in `help commands` but bzr push doesn't "do what i expected" or does it really require running `bzr push-and-update` ?
[08:48] <jmhodges> weird
[08:48] <fullermd> Probably, if that shows up in the command list.
[08:49] <lifeless> try bzr help push-and-update :)
[08:54] <jmhodges> natch.  for some reason, i thought it "overwrote" push
[09:23] <Laurens_S> Hello, is there someone here who has experience using bzr 1.0, with bzr+ssh on windows? I can't seem to get it to work. sftp works fine, but I'd like the speedimprovement of bzr+ssh which I've seen in linux
[09:30] <spiv> Laurens_S: what problem are you having?
[09:31] <Laurens_S> this is the error I get:
[09:32] <Laurens_S> (reproducing error.....)
[09:34] <Laurens_S> Z:\src>bzr log bzr+ssh://username@server/full/path
[09:34] <Laurens_S> Connected (version 2.0, client OpenSSH_3.8.1p1)
[09:34] <Laurens_S> SSH username@server password:
[09:34] <Laurens_S> Authentication (password) successful!
[09:34] <Laurens_S> Secsh channel 1 opened.
[09:34] <Laurens_S> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[09:34] <Laurens_S> Z:\src\>
[09:34] <Laurens_S> I tried -Dhpss, didn't show anything more
[09:34] <spiv> Laurens_S: -Dhpss puts more information in the .bzr.log file
[09:35] <Laurens_S> ah :)
[09:35] <Laurens_S> I'll try again
[09:35] <spiv> ("bzr version" should report the location of that file)
[09:36] <spiv> So, put the contents of the log file on pastebin.com
[09:37] <Laurens_S> ah, I finally figured it out:
[09:37] <spiv> I'm guessing it's something wrong on the server side, perhaps "bzr" is not on the PATH?
[09:37] <Laurens_S> yes, that was indeed the case
[09:37] <spiv> Heh, lucky guess :)
[09:37] <Laurens_S> I set BZR_REMOTE_PATH to the correct location now
[09:38] <Laurens_S> I thought I did that, but SET revealed that I messed up :
[09:38] <spiv> Ah, right.
[09:38] <Laurens_S> zbr_remote_path=/home/ls/local/bin/bzr is not really the same as BZR_REMOTE_PATH :)
[09:38] <spiv> heh.
[09:38] <Laurens_S> well, thanks for helping out :)
[09:38] <spiv> You're welcome :)
[09:39] <Laurens_S> now it turns out I forgot to do a bzr bind, bzr commit before leaving the house :)
[09:39] <Laurens_S> anyway, thanks again, and have a good day y'all :) Loving bzr!
[09:57] <Kinnison> lifeless: Has anyone come up with the answer for you for the traffic shaping?
[09:57] <Kinnison> lifeless: If not, my recommendation is to use 'tc' but it's arcane and confusing, even for people who already know how to use it
[10:02] <gus> I broke my branch :(
[10:02] <gus> anyone know what this means:
[10:02] <AfC> Try using gun tape.  It is bound to BzrBranch6('sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/'), which is bound to sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/.
[10:02] <gus>
[10:03] <gus> its not real informative
[10:03] <AfC> gus: Sounds like you don't have write permissions on the target branch, but I assume this used to work for you?
[10:03] <gus> yes
[10:04] <AfC> gus: anyone else committing to this branch?
[10:04] <gus> it was a lightweight checkout, but I removed that and did a heavyweight checkout
[10:04] <gus> nope, its all me
[10:04] <fullermd> Er.  It's recursive.
[10:04] <AfC> gus:  (ie, beware debian style group-per-user nonsense which can result in various users trampling permissions in a repo)
[10:04] <gus> afc: its my laptop and home desktop - i don't think there are other users here
[10:05] <fullermd> You've got a branch bound to itself.  That kinda doesn't work...
[10:05] <AfC> gus: and as another aside, any particular reason you're using a bound branch ("checkout") instead of a full power branch?
[10:05] <gus> I don't know, I'm not really a power bzr user
[10:05] <Kinnison> gus: log onto mongrel, cd into /home/gus/archives/libapache-sessionx-perl/debian/
[10:05] <Kinnison> gus: type bzr unbind
[10:05] <Kinnison> gus then try again
[10:06] <Kinnison> gus: As fullermd says, your remote branch is bound to itself, which is the complaint
[10:06] <gus> works fine
[10:06] <gus> interesting
[10:06] <gus> before the unbind, it said this:
[10:06] <gus> % bzr info
[10:06] <gus> Repository bound branch (format: dirstate-tags)
[10:06] <gus> Location:
[10:06] <gus>   shared repository: /home/gus/archives/libapache-sessionx-perl
[10:06] <gus>   repository branch: .
[10:06] <gus>
[10:06] <gus> Related branches:
[10:06] <gus>     push branch:
[10:06] <gus>   parent branch: /home/gus/archives/libapache-sessionx-perl/upstream
[10:06] <gus>
[10:07] <gus> where's the bit that tells me where its bound to?
[10:07] <Kinnison> gus: oddness, it doesn't specifically say it was
[10:08] <Kinnison> it should say checkout of branch: .....
[10:08] <Kinnison> but then again, it was bound to itself, so who know how odd it could have gotten
[10:08] <fullermd> My checkouts say "Repository checkout (format: dirstate-tags)"
[10:08] <Kinnison> gus: fyi, in future, please use a pastebin like pastebin.ca or rafb.net/paste/ for anything more than a line or two
[10:08] <gus> meh. I haven't touched these for ages, perhaps I typed something dumb once ages ago
[10:09] <gus> kinnison: yep, sorry I'm being lazy.  me--
[10:09] <fullermd> What version of bzr are you running?
[10:09] <Kinnison> fullermd: oh true, repos will say that
[10:09] <Kinnison> gus: and it does say "Repository bound branch" at the top
[10:09] <gus> I now have bzr 1.0 at both ends, but these repositories were created / last-modified by a much older bzr version (I couldn't tell you how old)
[10:10] <gus> anyway, thanks.  I can pretend I'm still an active debian developer now.  ;)
[10:12] <Kinnison> If you have 1.0, consider using pack format for faster operation (make backups first obv.)
[10:12] <Kinnison> I've found pack to be much faster when working with remotely bound branches
[10:12] <Kinnison> But then again, I am odd :-)
[10:13] <gus> heh.
[10:13] <gus> as an aside: I had lots of trouble finding a way to convert a lightweight checkout into a heavyweight.  Is there some way of doing that 'in place'?
[10:14] <fullermd> I think reconfig can do that.
[10:14] <fullermd> At least in recent versions.
[10:14] <gus> didn't seem to (at least in 1.0)
[10:16] <fullermd> It's got --checkout in 1.0...
[10:17] <gus> right, but both heavyweight and lightweight checkouts are checkouts, right?
[10:17] <gus> or have I confused some terminology somewhere
[10:17] <gus> I guess I want a bound branch or something
[10:17] <fullermd> Unqualified 'checkout' implies heavyweight.
[10:18] <gus> ah ok.  I'll give that a go next time.
[10:54] <i386> lifeless: ping
[12:21] <dgl_> hi, where can I find something really useful about bzr? I guess documentation at http://bazaar-vcs.org are not very clear.
[12:21] <dato> dgl_: try http://doc.bazaar-vcs.org/
[12:24] <dgl_> dato: I've already been there, sorry about that but I really don't think bzr has a complete documentation that can explain it at all .
[12:24] <dato> explain it all in what sense?
[12:25] <dato> what all? using should be well covered by http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[12:25] <dato> usage
[12:27] <dgl_> dato: I've been svn user since a couple of years ago and it has a clear workflow description. I know bzr has a lot of possible workflows, but none of them are really explained.
[12:28] <dato> not really explained *where*? I haven't read the user guide myself, but the table of contents *hints* like as if they are explained there
[12:35] <dgl_> dato: I've read it, it just superficially describes some workflows.
[12:36] <luks> anything in particular that you think is missing there?
[12:39] <dgl_> dato: I guess, as svn user, learn decentralized workflows is a little hard.
[12:40] <dato> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style has the very basics, but honestly, there's not *much* more
[12:41] <dgl_> dato: and there are some concepts that works little different, like branches, where in svn is just a copy
[12:41] <luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch
[12:41] <dato> dgl_: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#concepts
[12:42] <dato> oh, what luks says is better
[12:42] <dato> but using DAG in that section, eek
[12:43]  * fullermd finds copies a buttload harder to understand.
[12:45] <dgl_> gutsy uses bzr 0.9 and my local doc are a little bit smaller
[12:46] <fullermd> 0.9?!
[12:46] <dato> 0.90
[12:46] <dato> dgl_: the docs got *really* polished for 1.0
[12:46] <fullermd> Jeez.  Don't DO that to my poor brain...
[12:47] <dgl_> sorry 0.90
[12:47] <dato> dgl_: if you could read or download the online versions, I think it'd be very helpful
[12:47] <dato> dgl_: most of it if not all will apply
[12:48] <dgl_> dato: I'll read online version
[12:48] <dato> great
[12:50] <dgl_> dato: maybe I'll do some pinning to get 1.0
[12:51] <dato> there ought to be backports for gutsy in bazaar-vcs.org/releases/debs
[13:11] <zurgutt> Hi folks.  Is there gui for bzr, or some ide/editor with integration?
[13:13] <dgl_> olive
[13:14] <dgl_> zurgutt: olive is a gui for bzr
[13:16] <zurgutt> thanks dgl
[14:41] <smagoun> We have a bzr repository on a server. I'm interested in running
[14:42] <smagoun> a script whenever someone pushes to that repo. Is there an easy way to do that?
[14:42] <smagoun> (I want to run the script on the server side, and ideally don't want to install a plugin on every developer workstation)
[14:43] <mwh_> well
[14:44] <mwh_> if you're pushing over a dumb transport that sounds kinda hard
[14:44] <smagoun> mwh_: I was afraid someone would say that. Polling the repo is the obvious solution then?
[14:45] <mwh_> if it's bzr+ssh only then something might be possible
[14:45] <mwh_> but, hm, probably not easy
[15:31] <ndim> Meh. Google for "git to bzr conversion" and the first hit is titled "How To Convert Bazaar Repo to Git".
[15:31] <LeoNerd> Use Tailor
[15:32] <ndim> LeoNerd: Is http://bazaar-vcs.org/BzrForeignBranches/Git known to be broken?
[15:33] <ndim> I'm looking for a one-off conversion. I have a few git branches based on old CVS versions of Mailman, and Mailman has since switched to bzr.
[15:33] <LeoNerd> Dunno.. never seen it before. Try it :)
[15:33] <ndim> Good :)
[15:33] <LeoNerd> If it's just a oneoff conversion, do you care about history?
[15:33] <LeoNerd> If not, it might be easier just to do an export/import snapshot, and forget history
[15:33] <ndim> I care about the stuff I did.
[15:33] <ndim> History-wise.
[15:34] <ndim> It will probably be easier to merge 50 line patches than one 2000 line patch.
[15:34] <ndim> divide et impera and stuff. :)
[15:36] <luks> ndim: the converted branch probably won't help you much if you want to merge it to the current mailman bzr branch
[15:37] <luks> revisions will have different IDs, files will have different IDs
[15:45] <ndim> $ bzr branch mailman-2.1.7.cg mm-git2bzr-test
[15:45] <ndim> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_output_one_line'
[15:45] <ndim> luks: Uhm.
[15:46] <luks> what does ~/.bzr.log say about the error?
[15:46] <ndim> Sounds like I'm better off converting current mailman from bzr to git, rebase my git stuff on that converted thing, and then convert the merged thing back to bzr...
[15:47] <luks> ndim: converting from git won't get you branch mergeable with trunk either
[15:47] <ndim> luks: traceback in stgit.
[15:47] <luks> oh
[15:47] <luks> mailman-2.1.7.cg is a git branch?
[15:48] <ndim> yupp.
[15:48] <ndim> cogito, to be exact.
[15:48] <ndim> bzr-git/stgit incompatibility.
[15:49] <ndim> The conversion from git to bzr I could do as generating a few dozen patches and commiting them with bzr.
[15:49] <ndim> That result would then be mergeable.
[15:49] <ndim> As I'd start on the bzr side with real upstream's bzr repo.
[15:49] <luks> ah
[16:07] <dato> jelmer: any chance to look at #180128?
[16:07] <dato> bug #180128
[16:07] <ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
[16:07] <jelmer> will have a look in the next few days
[16:07] <dato> ok, no hurries, just thought I'd ask.
[16:07] <jelmer> there's a couple of other bzr-svn issues I have to look at as well, and I prefer doing them in batches
[16:07] <dato> very well
[16:07]  * jelmer is in Samba-mode atm :-)
[16:30] <ubotu> New bug: #181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] https://launchpad.net/bugs/181811
[16:36] <jelmer> ddaa: btw, I made a couple of small fixes to your bzr-git branch
[16:36] <ddaa> great
[16:36] <jelmer> https://code.edge.launchpad.net/~jelmer/bzr-git/jelmer
[16:36] <jelmer> fixes support for python2.4
[16:37] <ddaa> jelmer: I do not plan to put any more work on bzr-git in the near future.
[16:37] <jelmer> ok
[16:37] <ddaa> feel free to own it
[16:37] <jelmer> I'm not sure I want to :-)
[16:37] <ddaa> well, it actually has the beginning of a useful test suite :)
[16:37] <jelmer> I may end up owning it though, if I start using it for Samba
[16:48] <muffinresearch> Quick question. Does anyone think it would be useful to have a shell script installer for mac that installs bazaar including all of the dependencies
[16:48] <muffinresearch> Does anything like that exist already?
[16:49] <jelmer> muffinresearch, I know there were some people working on it
[16:49] <jelmer> muffinresearch, not sure what the status is though
[16:49] <jelmer> phanatic: ping
[16:49] <muffinresearch> I see this: http://www.nabble.com/Bazaar-OS-X-Installer-status-td14254776.html
[16:49] <phanatic> jelmer: pong
[16:50] <jelmer> phanatic: ^^
[16:50] <phanatic> muffinresearch: there is already an installer available for leopard (bazaar 1.0)
[16:51] <phanatic> muffinresearch: http://bazaar-vcs.org/Download
[16:52] <muffinresearch> I don't have leopard
[16:53] <muffinresearch> Presumably macports is kept fairly up to date.
[16:53] <phanatic> indeed
[16:53] <phanatic> that works fine as well
[16:54] <phanatic> jelmer: i could even get bzr-gtk working with macports, it's pretty cool :)
[16:54] <muffinresearch> The main reason is just providing a quick way for colleagues to get up and running with the latest version. I normally install from source myself
[16:57] <muffinresearch> macports is probably the best option. I'll get someone to try that
[17:37] <nebuchadnezzar> hello
[17:38] <jelmer> hi
[17:55] <nebuchadnezzar> I'm following the bzr upgrade in my debian SID and I see some new format, rich-root and rich-root-pack, I don't find documentation/specification about them.
[18:48] <brianpeiris> hello
[18:49] <brianpeiris> quick question, am I correct in assuming that bzr diff does not support UTF-16 ?
[18:50] <jelmer> brianpeiris: AFAIK, yes
[18:50] <jelmer> brianpeiris: you can however use it with external diff tools
[18:50] <luks> but it will print utf-16
[18:51] <brianpeiris> ok, explains the "binary files ... differ" message I was getting while trying to diff a UTF-16 sql script.
[18:51] <luks> actually, it won't print anything
[18:51] <luks> yeah
[18:51] <luks> bzr checks if the file has nul bytes, and if yes it assumes it's binary
[18:54] <brianpeiris> alrighty, thanks for the help.
[18:55] <ubotu> New bug: #181842 in bzr "BZR_SSH environment variable is not explained in docs" [Undecided,New] https://launchpad.net/bugs/181842
[18:55] <dgl> hi
[18:56] <dgl> Can anyone explain me what are the differences between init and init-repos?
[18:57] <jelmer> init creates a branch
[18:57] <jelmer> init-repo creates a (shared) repository
[18:58] <dgl> jelmer: ok, i've already read that, but what does it mean?
[19:01] <dgl> basically you create a branch just few times and then start to 'branch' it, isn't it?
[19:01] <jelmer> dgl: see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts for an explanation of branch and repository
[19:04] <brianpeiris> @dgl, see also: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#repositories
[19:05] <dgl> thanks, I will
[19:29] <UbuntuStats> Hi - From now on #bzr will have statistics on ubuntuircstats.org (gouki)
[19:32] <dgl> where is a nice place to create a shared repos at an ubuntu server?
[19:32] <gouki> Here it is: http://ubuntuircstats.org/bzr.html
[19:32] <gouki> Enjoy guys!
[20:01] <ubotu> New bug: #181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Undecided,New] https://launchpad.net/bugs/181855
[20:16] <dgl> where is a nice place to create a my mainline shared repos at an ubuntu server?
[20:17] <beuno> dgl, Launchpad es where you create branches, but it doesn't support shared branches as far as I know
[20:17] <beuno> I suppose, at the moment, it's meant for local use, to save space
[20:17] <LarstiQ> depends on what you mean with shared
[20:17]  * beuno waves at LarstiQ
[20:18] <LarstiQ> multiple people can push to branches on launchpad, provided they are part of the team owning the branch
[20:18] <LarstiQ> beuno: heya :)
[20:18] <dgl> beuno: I've got a server with ssh, I just want to use it as a shared repos
[20:18] <LarstiQ> dgl: you're asking what a good location is to place public repositories?
[20:18] <beuno> dgl, you want multiple people to be able to work on a branch, or you want multiple branches to use the same repo?
[20:18] <LarstiQ> in a FHS kinda way
[20:19]  * LarstiQ user /srv/bzr/<repository-name-here>
[20:19] <dgl> LarstiQ: sorry, but I think I was not clear
[20:19] <dgl> I was talking about filesystem
[20:20] <beuno> dgl, that just confuses me more  :D
[20:21] <dgl> beuno: LarstiQ's understood me
[20:21] <beuno> ah, yes, he's very good at that
[20:21] <dgl> beuno: I was asking about a nice place to create a shared repos at my server file system
[20:22] <beuno> dgl, happy you got your answer  :D
[20:23] <LarstiQ> dgl: it depends on the rest of your filesystem layout of course, /var/www/bzr/ is also not unthinkable :)
[20:23] <dgl> LarstiQ: and /var/bzr?
[20:23] <LarstiQ> dgl: not where I'd place it myself
[20:23]  * LarstiQ thinks it fits best under /srv
[20:24] <LarstiQ> dgl: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
[20:24] <lifeless> /srv/bzr/www
[20:24] <lifeless> hmm, maybe /bzr/www/srv/var/
[20:24] <LarstiQ> lifeless: argh :P
[20:25] <lifeless> no like?
[20:25] <LarstiQ> you'd have to have a rather complex setup for that to make sense I think
[20:25] <lifeless> ok, ok.
[20:25] <LarstiQ> something like launchpad perhaps
[20:25] <lifeless> /var/bzr/srv/www/
[20:25] <LarstiQ> lifeless: are you pulling my leg again? :)
[20:25] <lifeless> moi?!
[20:25] <dgl> I just want to use sftp
[20:26] <LarstiQ> lifeless: true true, I've never caught you doing it before.
[20:26] <lifeless> maybe not on IRC; in person you have:)
[20:26] <LarstiQ> hah! Now I did ;)
[20:26] <lifeless> dgl: anything is fine; key things to think of is 'will it be backed up by your backup programme'
[20:28] <dgl> lifeless: thanks
[21:12]  * lamont looks around for a bzr god
[21:12] <lamont> lifeless: you awake?  and are you a god? :-)
[21:14] <lamont> if a user has read access to .bzr/* (and down), but lacks read access on bar/foo.c, how can I tell bzr to just ignore that little issue and keep right on going with its life?
[21:15] <dato> heh
[21:15] <lifeless> lamont: (True, True)
[21:17] <lamont> lifeless: I see that you remember ghostbusters.
[21:17] <lamont> now about bzr and bar/foo.c ....  any hope for me?
[21:20] <lamont> lifeless: ^^
[21:23] <lifeless> lamont: you can't
[21:24] <jearl> \q
[21:24] <lifeless> lamont: (in general). Bu perhaps you can give me more info ;)
[21:37] <Peng> Nice, some random doofus clicked on one of my bundles because it's the only Google result for "JGR1my space". :\
[21:38] <Peng> Googlebot also found a link to /yaygyosr.html in one of them.
[21:43] <lifeless> rotfl
[22:31] <Peng> Ooh, the "JGR1my space" search was from Mexico!
[22:39] <lifeless> yay hung test :(
[22:39] <LeoNerd> Hung-like-horse, or hung-like-Sadam ?
[22:39] <Peng> Ouch.
[22:39] <lifeless> I'll find out soon
[22:40] <lifeless> hung like reading bytes that never came
[22:40] <Peng> I got a "Connection reset by peer" after 3 minutes pushing 1 KB of changes over bzr+ssh. :D
[22:55] <abentley> lifeless: Your patch to remove the need for ParentProvider.get_parents looks very strange.  The goal is fine, but please don't merge in current form.
[22:56] <lifeless> abentley: good timing; I had just hit enter to push and submit
[22:56] <lifeless> whats wrong with it ?
[22:56] <abentley> It means that Graph.parents_provider is sometimes None.
[22:56] <abentley> Sorry
[22:56] <abentley> Graph.get_parents is sometimes None
[22:56] <abentley> That's a public API
[22:56] <dato> abentley: (when you have a couple minutes and if you don't mind, did you see my question about having send, when -r is specified, always bundle those revisions, even if they're in the submit branch?)
[22:57] <abentley> It should always be a callable.
[22:57] <lifeless> abentley: oh, that wasn't clear to me because its not defined explicitly
[22:58] <abentley> You can deprecate it, or remove it entirely, but no one expects a method to sometimes be None.
[22:58] <lifeless> so if I add
[22:58] <lifeless> 'if self.get_parents is None: del self.get_parents' you're happy ?
[22:59] <abentley> You mean Graph.get_parents would sometimes be defined, and sometimes not defined?
[22:59] <lifeless> or I can write a regular get_parents method
[22:59] <lifeless> well currently I can supply a ParentsProvider with get_parents = None
[22:59] <abentley> I prefer either deprecate it, or remove it in all cases.
[22:59] <lifeless> because the Graph class does not define any of what you are referring to
[23:00] <lifeless> and we don't provide any thunking in either direction
[23:00] <abentley> lifeless: You can, but that's an API violation.
[23:00] <lifeless> abentley: how about I write Graph.get_parents and graph.get_parent_map, both in terms of each other
[23:01] <lifeless> abentley: then the constructor can replace just one from the ParentsProvider
[23:01] <abentley> Why would you write Graph.get_parents_map?
[23:01] <abentley> Let's just standardize on ParentsProviders having that.
[23:01] <lifeless> so that providers with get_parents still work - that is the point of deprecating that isn't it ?
[23:02] <abentley> There are no providers with only get_parents.
[23:02] <lifeless> let me rephrase; we appear to have a deprecation which is not really a deprecation - its not compatible. I'm happy to either turn it into a full break; or a real deprecation where the old code works. Your choice.
[23:02] <lifeless> abentley: third party repositories will almost certainly be providers with only get_parents
[23:02] <lifeless> which is public in that Graph.__init__ takes a public parameter.
[23:04] <abentley> I have a slight preference for real deprecation, but I'd be fine with either.
[23:04] <lifeless> ok I'll whip it up
[23:05] <abentley> dato: That has already proven to result in horrible messes, and that's why there's a submit branch.
[23:05] <abentley> However, if you want an override, that's fine.
[23:05] <dato> override == option?
[23:06] <abentley> Yes.  People have asked for that in the past, but they've never suggested how the commandline would work.
[23:06] <dato> ok, I'll make a note, and possibly talk to you about it in the (near) future. now it'd be bed time for me.
[23:06] <abentley> One way would be a second revision spec.
[23:06] <abentley> Another would be an option that says --use-revision-spec-instead-of-submit-branch
[23:08] <dato> (I guess I didn't realize the time it was when I brought up the subject, sorry. chao)
[23:09] <abentley> But remember that a merge directive, is meant to convey the changes you want made.  That's what the -r controls.
[23:10] <abentley> The revisions supplied are the ones necessary for other people to apply the those changes.
[23:10] <abentley> For a cherry-pick, that is typically *more* revisions than the -r range includes.
[23:11] <abentley> The submit branch should indicate which revisions everyone already has.


[11:45] <lool> ian_brasil: If you want to mention something in the monthly news, Matthew Garret, Steve and I worked on a new hildon version of cheese
[11:45] <lool> Steve == smagoun
[11:46] <ian_brasil> lool: OK, thx
[11:50] <StevenK> I was going to say.
[11:51] <StevenK> I'm happy to take credit, though ... :-)
[15:40] <lool> cjwatson: 5 seconds gained on the boot thanks to the console-setup change!  Thanks!
[15:55] <cjwatson> lool: excellent
[17:29] <GrueMaste1> \join #moblin
[18:49] <raji> asac_the_2nd: I couldnt test wpa using your network-manager 0.7 bits because, it has dependency on libnl-pre8.0 , I couldnt find one suitable for lpia architecture.
[21:05] <khashmeshab> hello everybody. can anyone tell me a brief summary of current ubuntu-mobile project status?
[21:06] <khashmeshab> I'm working on a article about mobile and embedded operating systems.
[21:08] <agoliveira> khashmeshab: Hi. What do you want to know?
[21:09] <khashmeshab> I want to know what systems and arch.s this version can installed on.
[21:11] <agoliveira> Did you check the links on the topic? They say preety much everything but the current details.
[21:11] <agoliveira> https://wiki.ubuntu.com/MobileAndEmbedded/FAQ and https://wiki.ubuntu.com/MobileAndEmbedded
[21:13] <khashmeshab> yes I did. thanks a lot. but consulting with an expert is more useful!
[21:15] <Sciri> khashmeshab: Unfortunately I don't have an overview of the current state of Ubuntu Mobile, but check out the meeting notes at https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/ since there's a lot of cool tidbits in there. :D
[21:15] <khashmeshab> thanks a lot for your time and fingers.
[21:16] <Sciri> khashmeshab: Also, there's an Ubuntu Mobile Sprint in Oregon next week; I'm looking to see if I can find the page now.
[21:18] <agoliveira> khashmeshab: Is there any information you need to know besides what's on the docs?
[21:24] <khashmeshab> I have a emergency question now! Can I install ubuntu-mobile on my Sony-Ericsson P990i? If no, which similar system can I install it? I think the best way to write about a product is to install it!
[21:26] <agoliveira> khashmeshab: As it's stated on the faq, UME is intended, at least for now, for x86 devices, not PDA or cellphones.
[21:26] <khashmeshab> also not for ARM processors?
[21:27] <agoliveira> khashmeshab: No.
[21:27] <suihkulokki> For P990, someone woul first need to port Linux kernel for it, before you can start thinking what distro to run on it
[21:29] <khashmeshab> Is it possible to port Linux (or any other) kernel to P990?
[21:30] <suihkulokki> if you get the documentation or are willing to reverse engineer the system
[21:32] <khashmeshab> Linux kernel currently can run on ARM processors. So compiling it might not be so difficault. So the problem is the system design arch. Am I right?
[21:33] <suihkulokki> khashmeshab: the problem is writing drivers for gsm, touchscreen, power managment, batttery, ...
[21:34] <khashmeshab> OK! I completely had forgotten them.
[21:36] <khashmeshab> Thanks a lot everybody, specially suihkulokki!


 I am sort of tempted to explore Miami tomorrow @RazPi
 Watch YouTube videos at the Linux terminal | Opensource.com … https://opensource.com/article/18/12/linux-toy-youtube-dl
 @RazPi - you can now add YouTube videos to emacs!!!
 Why does that look like Rick astley?  I'm gonna click it.
 It is bit no need to worry about a rickroll
 Wow.  I didn't get Rick rolled.  And I expected to.
 so i just realized allo is going away in march
 https://allo.google.com/
 google, make up your mind.
 for a company with such amazing talent, they do some strange stuff at times.
 Management is awesome I'm guessing
 valid point
 btw, i'm thinking of leaving 18.04 lts in favor of 18.10. what are you guys running? @KMyers @ahoneybun
 for production, i'm sticiking with lts
 @govatent, Honestly ChromeOS
 Buy my servers are on a mix of 16.04 and 18.04. I need to do some updates next week
 I'm thinking of installing either 18.04 or Debian on this desktop
 I FOUND MORE FACES!!!
 nice
 @govatent 18.10 on desktop 18.04 on server.


 I don't find it neither in ubuntu docs or qt docs
[12:06] <__marco> Good afternoon. I have a problem with two packages that I created
[12:07] <__marco> the first is qemu compiled with vde support
[12:07] <__marco> qemu (= 2.0.0+dfsg-2ubuntu1.3vde1)
[12:07] <__marco> the second is a package that depends on that version of qemu
[12:08] <__marco> All worked fine until a new version of qemu appeared in Ubuntu
[12:08] <__marco> 2.0.0+dfsg-2ubuntu1.19
[12:08] <__marco> Note the 1.3 vs 1.19 at the end
[12:10] <__marco> That specific version is still reachable by my repository
[12:11] <__marco> why apt-get refuses to install my package even it can install all dependencies?
[12:11] <ogra_> because 19 > 3
[12:13] <__marco> ogra_: and?
[12:13] <__marco> that can I understand, but why?
[12:14] <__marco> note that qemu is not installed. So no downgrade is required
[12:14] <ogra_> no, but the ubuntu archive is most likely enabled on your machine
[12:14] <__marco> yes
[12:14] <ogra_> apt-cache policy qemu ...
[12:15] <__marco> ogra_: can you read or the output is only in my irc client?
[12:16] <ogra_> ?
[12:16] <__marco> qemu:
[12:16] <__marco>   Installato: (nessuno)
[12:16] <__marco>   Candidato:  2.0.0+dfsg-2ubuntu1.19
[12:16] <__marco>   Tabella versione:
[12:16] <__marco>      2.0.0+dfsg-2ubuntu1.19 0
[12:16] <__marco>         500 http://de.archive.ubuntu.com/ubuntu/ trusty-updates/universe amd64 Packages
[12:16] <__marco>         500 http://security.ubuntu.com/ubuntu/ trusty-security/universe amd64 Packages
[12:16] <__marco>      2.0.0+dfsg-2ubuntu1.3vde1 0
[12:16] <__marco>         500 http://cnrl.deis.unibo.it/repo/ trusty/main amd64 Packages
[12:16] <__marco>      2.0.0~rc1+dfsg-0ubuntu3 0
[12:16] <__marco>         500 http://de.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
[12:16] <__marco> (sorry for the italian)
[12:17] <ogra_> you dont need to paste this here ... i knew what it would show ... this was to make you understand that the newer package is used first
[12:17] <ogra_> you will likely need to bump your PPA package to 0.19
[12:18] <ogra_> (also use a pastebin next time if the output is more than a few lines)
[12:18] <ogra_> err
[12:19] <ogra_> s/0.19/1.19/
[12:19] <__marco> ogra_: Now I can't upgrade the version of qemu. I need now a fast fix. I will pin qemu to 1001
[12:19] <__marco> that should fix it
[12:21] <__marco> (I hope)
[12:50] <mhall119> rpadovani: it's in the webbrowser-app codebase, not the uitk
[12:56] <rpadovani> mhall119, yap, thanks, that was a dumb question
[12:58] <mhall119> rpadovani: if you have any idea why the unittests fail, i need some help there
[12:58] <mhall119> oSoMoN: ^ too
[12:58] <mhall119> that's about my MP to webbrowser-app
[13:00] <rpadovani> argh my firefox crashed again
[13:00] <rpadovani> mhall119, I take the branch and take a look
[13:00] <ogra_> time to switch to webbrowser-app ;)
[13:02] <rpadovani> the real problem is that firefox takes with it also xorg
[13:02] <ogra_> time to switch to M;ir on the desktop ;)
[13:02] <rpadovani> ahahh right
[13:02]  * ogra_ grins
[13:02] <rpadovani> I'm still on 14.04 on this pc
[13:06] <rpadovani> mhall119, if I understand well oSoMoN's comment, you need to move the KeyboardShortcuts inside the TabsBar component, and then forward the key events to it, if needed
[13:06] <rpadovani> I'm not sure about dynamic instanstation (is that even a word?)
[13:12] <nemo> rpadovani: about:crashes ?
[13:14] <rpadovani> nemo, no crashes reported
[13:16] <nemo> odd
[13:17] <nemo> almost all my crashes are on this machine are due to my obstinately trying to use layers acceleration on a sucky card/driver combo  but all the r600_dri.so in about:crashes makes that pretty clear
[13:21] <pp__> Hello guys, can you help me
[13:22] <pp__> I am trying to make run my emulator
[13:22] <pp__> after booting it
[13:22] <pp__> it is not connected to it
[13:22] <pp__> the device does not finish to boot
[13:23] <pp__> I can make it run only if using stable one
[13:23] <pp__> in 14.10
[13:23] <pp__> I would need latest 15.04
[13:23] <pp__> unfortunatly it stays stall, any ideas?
[13:27] <oSoMoN> mhall119, I commented on the MP to explain why the unit tests fail
[13:34] <LocutusOfBorg1> mcphail, hi, do you need help for hedgewars?
[13:50] <mhall119> oSoMoN: saw that after I pinged you, will look into it later today. thanks
[16:53] <ogra_> hmpf
[16:53] <ogra_> did the WebView change ? my apps cant get the clicked URL anymore
[16:54] <ogra_> ** (process:9600): WARNING **: Unable to dispatch url 'file:///opt/click.ubuntu.com/google-plus.ogra/0.2.1/qml/undefined':GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'file:///opt/click.ubuntu.com/google-plus.ogra/0.2.1/qml/undefined' is not handleable by the URL Dispatcher
[16:54] <ogra_> this is what i get since recently when tapping an URl
[16:55] <ogra_> chrisccoulson, do you happen to know ?
[17:18] <ogra_> qml: [JS] (:0) Entering fullscreen in an <iframe> with no allowfullscreen attribute is deprecated and will stop working in M46, around October 2015. Please use the allowfullscreen attribute.
[17:18] <ogra_> hrrrrm
[17:19] <ogra_> so i'm using a stable API for my app, how can it be that such things change ? (the above issue is obviously that WebView suddenly starts to decode urls on its own while my code did the decoding before)
[17:19] <ogra_> pmcgowan, our framework is a gross mess !
[17:23] <ogra_> (why does the 15.04 framewkr change in ways it breaks my apps)
[17:24] <pmcgowan> hmm
[17:25] <pmcgowan> how long has that deprecation been planed?
[17:25] <ogra_> the fullscreen issue is a bit older already ... i only found the tine now to check why videos dont go fullscreen anymore
[17:26] <ogra_> the url change is a massive breakage for me though and affects all apps i use that use a plain WebView and try to open external links
[17:27] <pmcgowan> ogra_, is that a real change or just a bug n the url dispatcher? I saw an issue with it gettig confused
[17:27]  * ogra_ is really angry, the 15.04 framework shouldnt change like this
[17:28] <ogra_> pmcgowan, well my G+ app cant open any external links since a few weeks ... i just checked now and obviously the handling of the url property changed so my functions suddenly get the wrong or no content
[17:28] <ogra_> thats not really acceptable for a soo-called stable framework imho
[17:28] <pmcgowan> alex-abreu, is that a webap container change?
[17:29] <ogra_> thats not a webapp container
[17:29] <pmcgowan> ogra_, this is on rc proposed?
[17:29] <pmcgowan> where then
[17:29] <ogra_> i use plain WebView from the SDK
[17:29] <alex-abreu> ogra_, your is a home made container right?
[17:29] <alex-abreu> yeah
[17:29] <alex-abreu> ogra_, so is the failure in the dispatcher ?
[17:29] <ogra_> well, its a MinView with a WebView inside
[17:30] <ogra_>                 function navigationRequestedDelegate(request) {
[17:30] <ogra_>                     var url = request.url.toString();
[17:30] <ogra_> ....
[17:31] <ogra_> url suddenly comes across decoded ... while it was encoded before
[17:32] <ogra_> i understand that this is an improvement (since it would save me from having to decode stuff myself now) ... but it shouldnt change like this for the "stable" framework
[17:32] <ogra_> and yes, this is rc-proposed ... but it is broken since before the last stable promotion
[17:34]  * ogra_ will just fix the app, but i really wonder about our regression testing WRT the framework bugfixes
[17:34] <alex-abreu> ogra_, mmh I am not aware of a change at that level ...
[17:34] <alex-abreu> ogra_, I'll investigate
[17:34] <pmcgowan> not finding the culprit so far
[17:35] <ogra_> thanks
[17:35] <pmcgowan> alex-abreu, let me know what you figure out
[17:35] <ogra_> might be an oxide change, not sure what navigationRequestedDelegate() talks to in the back
[17:35] <alex-abreu> pmcgowan, yes, I am intrigued
[17:36] <alex-abreu> ogra_, I'd be surprised if it was an oxide change, we careful about those api changes
[17:36] <alex-abreu> ogra_, you are using oxide 1.9.x right?
[17:36] <ogra_> whatever is the default for the 15.04 framework
[17:37] <ogra_> my app simply declares the framework version
[17:37] <alex-abreu> ack


[20:27] <Laibsch> am I wrong to think that python3-virtualenv is a bit of a misnomer?  It is my understanding that virtualenv is for python2 and venv is for python3.  As such, python3-virtualenv should not exist but it's been aroud since bionic, or am I mistaken? bug 1958789