[00:00] <poolie> but i'm ok with making it a dependency of bzr, we don't aspire to have every feature working on a bare python install
[00:01] <denys> with a _bare_ install, I can give you encrypted bzr server connections
[00:02] <denys> surely, that's an improvement (even if minute)
[00:02] <poolie> so is that the main difference in your view?
[00:04] <denys> yes - so far, it is something small that improves security and THEN makes possible authentication over an encrypted channel
[00:09] <dash> i'm using bzr 1.17 and after doing 'bzr shelve' I get this: "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-5')]"
[00:10] <dash> unshelve seems to work OK, but it worries me a little. :)
[00:10] <dash> anything I can do to diagnose or fix this?
[00:10] <lifeless> dash: are you shelving only some changes?
[00:11] <lifeless> dash: also file a bug
[00:12] <dash> no, all of them
[00:12] <dash> OK
[00:12] <lifeless> what does bzr status show, if you can show me?
[00:12] <denys> hmm... my more general question has not been answered: how do I get a request to change something in the server e.g. in the connection (socket)?
[00:13] <lifeless> denys: there isn't any way to do that at the moment, the server doesn't assume a socket even exists
[00:13] <lifeless> denys: which is why I started talking about framing etc
[00:13] <dash> lifeless: mmm, this is proprietary code, so i probably can't show it to you verbatim
[00:14] <denys> lifeless: I know, but should I give up or is there value in trying to make that work?
[00:14] <lifeless> dash: feel free to transform the filenames
[00:14] <lifeless> dash: I want the structure
[00:14] <dash> but it's just 4 files modified, 3 files added, no pending merges, mucho unknowns
[00:14] <dash> OK
[00:14] <lifeless> denys: and whether specific items are directories or files
[00:15] <lifeless> denys: well, I don't see a lot of value, but if you do I'm happy to help you figure it all out.
[00:15] <poolie> denys, i thought i answered that, or at least pointed in the right direction
[00:15] <poolie> make the objects link to each other on the way up
[00:15] <poolie> so then the request can tell the socket to start encryption
[00:16] <lifeless> denys: the reason I don't see a lot of value is that unlike e.g. SMTP, bzr's protocol aims to layer on transports that are already encrypted. SMTP though, defines a wire protocol for talking on a socket.
[00:16] <poolie> however, i really wish we could understand each other about ssh :-(
[00:17] <lifeless> oh wow
[00:17] <lifeless> http://www.techdirt.com/articles/20090328/1445494290.shtml
[00:17] <lifeless> copyright law fail
[00:17] <denys> poolie: there's a lot that I just can't do with with ssh that could be done if I have free reign.  but I have to play with the cards I get.
[00:18] <lifeless> denys: what sort of things?
[00:18] <dash> lifeless: http://paste.ubuntu.com/256004/
[00:18] <poolie> lifeless: mm i saw, that's a bit awful
[00:18] <denys> lifeless: I can't sell it to admins
[00:18] <lifeless> denys: it doesn't need system users though, or even to be on port 22
[00:18] <poolie> mind you it'd probably be infeasible to run such a service _at all_ in au or uk because of libel law
[00:18] <denys> I can't sell restricted shells
[00:19] <lifeless> denys: it doesn't even need a shell
[00:19] <poolie> the SMH restaurant reviewer was sued for criticizing a restaurant
[00:19] <denys> lifeless: you cannot reason it.  this is not a reasonable requirement . it just is. and I have to deal with it.
[00:20] <lifeless> oh; so you're saying that when you say 'ssh', your sysadmins think 'open ssh, PAM, passwd files and shells', but when you say 'https' they think 'some custom code I don't need to worry about' ?
[00:21] <denys> they worry about it, but at least they have pretty goof hanlde on that
[00:21] <lifeless> even though those two things are totally interchangable? [there are system web servers that offer shells and ssh servers that simply don't...]
[00:21] <poolie> ah :)
[00:21] <denys> s/goof/good/
[00:21]  * poolie made the classic mistake of assuming the requirements were rational
[00:21] <denys> i have spent 3 years of lobbying :-(
[00:22] <denys> what I have got is pretty good compared with we what we had before
[00:23] <lifeless> so
[00:23] <lifeless> one possibly thing to do would be to make bzrs be bzr+ssh :)
[00:23] <lifeless> and just not tell anyone
[00:24] <denys> lifeless: you don't work at a university ibviously
[00:24] <denys> ;-)
[00:24] <poolie> so
[00:24] <lifeless> denys: I used to
[00:25] <poolie> even if it's not externally visible at all, they're going to object if you're running a standard protocol at the top layer, but not if you're running a hand-crafted protocol?
[00:25]  * poolie wonders where you draw the line
[00:25] <denys> lifeless: last time we did domething that the security officer didn#t approve of, he cut the entire university network
[00:25] <lifeless> denys: wow
[00:25] <poolie> if it's ssh but you must send the string 'cest la vie' before you start is that ok?
[00:25] <denys> yeah!
[00:26] <denys> poolie: no dice
[00:26] <poolie> ok
[00:26] <poolie> so that probably explains the confusion
[00:26] <poolie> i think at least some other it departments would actually prefer people use standard secured protocols
[00:26] <lifeless> its a form of conflation
[00:27] <poolie> mm
[00:27] <lifeless> 'ssh' is being conflated with implementations that have various implications
[00:27] <poolie> i've heard, years ago, of ssh being banned in favor of telnet
[00:27] <poolie> i'm not sure if it was that they wanted to sniff your traffic, or just fear of the new
[00:27] <denys> they may eventually come that conclusion themselve, but it CANNOT be thrust upon them
[00:28] <AfC> poolie: fear of the new
[00:28] <lifeless> right
[00:28] <AfC> denys: [and, that's very astute]
[00:29] <igc> morning
[00:29] <poolie> denys: so, ok,
[00:29] <poolie> sheesh
[00:29] <igc> poolie: the quick references cards did move some weeks back, yes
[00:29] <poolie> i'd like to help you out here but i'd also like something that makes sense for other people
[00:30] <poolie> and i think that's more likely to be builtin ssh
[00:30] <poolie> how about if you write a small separate program that works just like ssh but is not actually ssh
[00:30] <lifeless> rephrase
[00:30] <lifeless> 'uses the same encryption as ssh'
[00:30] <poolie> in other words it opens an ssl connection, sends a username and password, then runs a server process
[00:30] <lifeless> :)
[00:30] <poolie> no, not the same protocol
[00:31] <poolie> so from bzr's point of view it will be 'program that gives me a connection to the server'
[00:31] <poolie> and 'program that starts the server in inetd mode'
[00:31] <denys> poolie: I don't think that forcing EVERYTHING into the same mold is necessarily a good strategy.  I'd like to see where we can take the bzr protocol.
[00:32] <denys> the other consideration is: how hard is it to set up
[00:32] <denys> I can guarantee you that setting things up on the university server is unbelievably hard
[00:32] <poolie> i can believe it
[00:33] <poolie> i'm reminded of getting an hp-ux account with no compiler and not even any cursor key support in the shell
[00:33] <poolie> that gets very very tedious
[00:33] <poolie> anyhow, if you put up clean patches, we can certainly look at them
[00:34] <denys> my tack is to promove virtual servers - but I still have to ackonoledge the authentication rules set up by the univesity
[00:34] <poolie> i think your requirements here are weird enough they're not necessarily what we'd generally recommend
[00:34] <denys> oops
[00:34] <poolie> but maybe it will turn out to be generally useful
[00:34] <denys> my requirement are not weird. they are just what we have to deal with in france
[00:34] <poolie> lifeless & others: so on another topic, i'm wondering if rather than 1.18final we should do 2.0beta1 today
[00:34] <poolie> with the format set
[00:35] <poolie> acknowledging we'll need more bug fixes, but we may not need anything other than bug fixes
[00:35] <poolie> well, some things like selected-file commit may need to be fudged as bug fixes; they arguably are
[00:35] <lifeless> poolie: uhm
[00:35] <lifeless> poolie: I really think we're confusing people by changing the release labelling before 2.0
[00:36] <lifeless> there isn't a stable that we have been patching
[00:36] <lifeless> so I'm very much in favour of 1.18
[00:36] <poolie> to take a step back
[00:36] <lifeless> and only changing the labelling at 2.0
[00:36] <poolie> we could release 1.18final
[00:36] <poolie> off that branch
[00:36] <poolie> and then immediately release 2.0b1 at the base of a new branch
[00:36] <lifeless> not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive
[00:37] <poolie> what's wrong with 2.0~beta1?
[00:37] <poolie> you can't have tildes in the upstream version?
[00:37] <lifeless> a ~ means sort before
[00:38] <poolie> right
[00:38] <lifeless> but its not part of the python version spec
[00:38] <lifeless> which you said you wanted to follow
[00:38] <poolie> istm (2, 0, 0, 'beta', 1) [00:38] <poolie> what is the problem?
[00:39] <lifeless> that works for me I think
[00:39] <poolie> surely that's the commonsense way to represent it in both systems?
[00:41] <lifeless> well, I'm only aware of ~ having this sort before meaning for dpkg specifically.
[00:41] <lifeless> I think its fine to start using it elsewhere, but it doesn't follow on its own from the starting point of using python identifiers ;)
[00:41] <lifeless> poolie: has it been 4 weeks since we released 1.18rc1?
[00:41] <poolie> i seem to be having a bad morning for communication
[00:41] <poolie> no
[00:41] <poolie> it's been a week and a half
[00:42] <lifeless> then I think we should wait ;)
[00:42] <poolie> you said
[00:42] <poolie> > lifeless: not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive
[00:42] <poolie> i think i answered that
[00:42] <lifeless> sure
[00:43] <poolie> i don't think we have to use the tilde anywhere else
[00:43] <poolie> in source or windows exe files it can be just 2.0beta1
[00:43] <poolie> for rpms iirc they already have a special sort algorithm that treats 'beta' as meaning 'before'
[00:50] <poolie> lifeless: btw i suppose you implicitly fixed https://bugs.edge.launchpad.net/bzr/+bug/413584 ?
[00:52] <poolie> i marked it fixed
[00:53] <lifeless> so did I:P
[00:57] <AfC> Um
[00:57] <AfC> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[00:57] <poolie> bzr info?
[00:57] <AfC> All I was trying to do was `bzr pull`
[00:57] <lifeless> AfC: is that a checkout ?
[00:57] <lifeless>  / bound branch
[00:57] <AfC> poolie: Repository checkout (format: 1.14-rich-root)
[00:57] <AfC>   repository checkout root: .
[00:57] <AfC>         checkout of branch: http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
[00:58] <AfC> lifeless: yes
[00:58] <lifeless> AfC: ok, so this is a bug
[00:58] <AfC> bzr 1.17 brand newly installed
[00:58] <lifeless> we're not matching urls correctly
[00:58] <lifeless> bzr unbind
[00:58] <AfC> k
[00:58] <lifeless> bzr bind http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk
[00:58] <AfC> && pull?
[00:58] <lifeless> then you'll be back to normal
[00:58] <lifeless> and can use bzr update again
[00:58] <fullermd> Bug?  Isn't that just what you'd expect to do when pulling a checkout over http?
[00:59] <AfC> [sometimes I think that you guys should kill "checkout" and only offer branch & bind.
[00:59] <lifeless> fullermd: no, the %7E != ~
[00:59] <fullermd> Sure, but what's that matter?
[00:59] <AfC> or, only offer branch ^W checkout & bind, etc]
[00:59] <fullermd> If you're trying to pull INTO a http://something, you'd expect locking failure since it isn't writable.
[00:59] <lifeless> fullermd: it fails the test in bzr.pull for master == source url
[00:59] <lifeless> fullermd: trust me :) look in malone if you want the gory details
[01:00] <fullermd> Well, maybe there's another bug there, but it *SHOULD* fail writing over HTTP regardless of any other matching.
[01:00] <AfC> I was trying to *pull*
[01:00] <lifeless> fullermd: pulling from the master of a bound branch pulls locally only
[01:00] <fullermd> In a checkout.  Which means the branch you're trying to write to is across HTTP.
[01:00] <AfC> And then I recalled I really ought to "update"
[01:01] <lifeless> can we please not paint the chicken a new colour right now?
[01:01] <fullermd> It WHAT?  That sounds like an insane level of DWIM...
[01:01] <AfC> (/me hates the fact that sometimes you do that as one step, sometimes two. eg push pull asymmetry, etc. I think in trying to make it easier we just made it more confusing)
[01:01] <lifeless> fullermd: I'm not defending it, but its been there for years; and the url mismatch is causing the error AfC is getting
[01:02]  * fullermd never heard of that before.
[01:02] <lifeless> fullermd: its part of the original bind patch I think
[01:02] <AfC> lifeless, poolie: thanks Robert & Martin. Fixed.
[01:02]  * AfC relocates
[01:54] <lifeless> brb, fooding
[02:13] <lifeless> dash: sorry, distractions
[02:14] <lifeless> dash: so, uhm shelve is failing
[02:14] <dash> yes
[02:14] <lifeless> and you're doing shelve --all ?
[02:14] <dash> using shelve1 at the moment in bzrtools
[02:14] <dash> lifeless: well i hit 'f' at the first prompt so basically
[02:14] <lifeless> to humour me, could you try shelve --all?
[02:15] <dash> sure
[02:15] <lifeless> also are there any pending merges?
[02:15] <dash> no pending merges
[02:15] <lifeless> kk
[02:15] <dash> same error using --all
[02:15] <lifeless> ok
[02:15] <lifeless> definitely file a bug
[02:15] <dash> except it says new-6 now, don't know if that's related to pulling new revs since i tried last
[02:15] <lifeless> nope
[02:15] <lifeless> you've modified another file probably
[02:16] <dash> the parent of this branch is an svn branch, don't know if that's relevant
[02:16] <lifeless> it might be; but the shelve operation is all local so shouldn't be
[02:17] <dash> ok
[02:17] <dash> guess i'll try this with 1.18rc1 too
[02:17] <dash> thanks
[02:24] <mozmck> Do the nautilus extensions work on ubuntu 9.04?  I installed from source and I can't get olive to run and nothing shows up in nautilus.
[02:26] <mozmck> This is what I get when I try to run olive-gtk:  Traceback (most recent call last):
[02:26] <mozmck>   File "/usr/local/bin/olive-gtk", line 89, in <module>
[02:26] <mozmck>     import bzrlib.plugins.gtk.ui as ui
[02:26] <mozmck> ImportError: No module named gtk.ui
[03:10] <spiv> mozmck: sounds like you hvaen't got the bzr-gtk plugin installed
[03:19] <mozmck> spiv: that's what I installed from source: bzr-gtk-0.96.2
[03:19] <mozmck> I'm running bzr 1.17 from the ppa deb package
[03:20] <lifeless> how did you install it
[03:20] <mozmck> ./setup.py install I think.
[03:21] <lifeless> it may have installed to something not on your python path
[03:21] <mozmck> oh, how would I find that out?  where is the python path?
[03:22] <lifeless> if you touch one of the source files
[03:22] <lifeless> like __init__.py
[03:22] <lifeless> and install it again, you can see the path it installs the python files to
[03:22] <mozmck> touch it?
[03:23] <AfC> $ touch path/to/filename.py
[03:24] <mozmck> ah, changes the timestamp.  Then how do I find it once installed?
[03:24] <lifeless> the installer outputs stuff
[03:24] <lifeless> read what it outputs :)
[03:25] <mozmck> /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk
[03:25] <lifeless> and now
[03:25] <lifeless> python -c "import sys; print sys.path"
[03:26] <mozmck> '/usr/local/lib/python2.6/dist-packages' is at the end of the printout
[03:27] <lifeless> ok
[03:27] <lifeless> python -c "import bzrlib; print bzrlib.__path__"
[03:28] <mozmck> ['/usr/lib/python2.6/dist-packages/bzrlib']
[03:28] <lifeless> so, this is a python limitation; by default it doesn't really know how to deal with different locations like that
[03:28] <lifeless> I suggest moving /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk to /usr/lib/python2.6/dist-packages/bzrlib/plugins/gtk
[03:28] <mozmck> ah, so I need to tell it to install in /usr/lib somehow
[03:29] <mozmck> I'll try that
[03:33] <mozmck> looks like that worked.  The first time I tried to run olive it gave a different error than it was giving, but now it runs.
[03:33] <mozmck> so should the nautilus stuff work after I log out and back in?
[03:34]  * igc lunch
[04:32] <lifeless> so, it feels like every tweet gets a new spam follower
[04:44] <bialix> igc: hi
[04:45] <igc> hi bialix
[04:45] <igc> bialix: is qinfo better now?
[04:45] <bialix> igc, what version of PyQt/Qt you're have?
[04:46] <bialix> similar problem with layout and in quncommit
[04:46] <igc> bialix: PyQt 4.4.4, Qt 4.5.0
[04:46] <igc> bilaix: jaunty
[04:47] <igc> bialix: I'm seeing crap layout in quncommit - I'm yet to try tuning that, I just wanted something working first
[04:47] <bialix> what strange combination!
[04:47] <igc> bialix: qinfo is ok for me though
[04:48] <bialix> I think PyQt should be 4.5.x too
[04:48] <bialix> weird weird weird
[04:48] <bialix> wait a sec
[04:49] <bialix> igc: http://imagebin.ca/view/RdaTOA.html
[04:49] <bialix> this is what I see by default
[04:49] <bialix> "move tip to" group should not be elastic. progress widget should be
[04:50] <igc> bialix: ok
[04:50] <lifeless> vila: hi :P
[04:51] <bialix> igc: there is several places that needs fixing in quncommit, unfortunately I have urgent work...
[04:51] <igc> bialix: karmix will be pyqt 4.5.2, qt 4.5.1 by the look of things
[04:51]  * vila snores
[04:51] <bialix> igc: how about next plan: I'll merge quncommit as is but make it idden command
[04:51] <bialix> *hidden
[04:52] <igc> bialix: if you can, let me fix it in the next hour or two
[04:52] <igc> bialix: can the 0.14 release wait another few hours?
[04:52] <bialix> igc: I will do release tonight in my tz, ~ +12 hours from now. But you'll be sleeping
[04:53] <igc> bialix: cool. I have another 2-3 things to clean up so I'll have them up for review asap
[04:54] <igc> bialix: I won't get to the qconfig nicer diff/merge tool selection so it will need to come later
[04:55] <bialix> igc: also, why for you need this code in do_start:
[04:55] <bialix> 280	+ cwd = urlutils.local_path_to_url(os.getcwd()) + '/'
[04:55] <bialix> 281	+ if cwd != dest:
[04:55] <bialix> 282	+ args.append(dest)
[04:55] <bialix> 283	+ self.process_widget.do_start(None, 'uncommit', *args)
[04:55] <bialix> igc: never never never never never use bare os.getcwd()!!!
[04:55] <bialix> os.getcwdu()
[04:56] <igc> bialix: ah - ok
[04:56] <bialix> but I think that code is useless
[04:56] <bialix> you need just append branch location
[04:56] <bialix> and most important!
[04:56] <bialix> quncommit should operate on working tree root, not branch root!
[04:57] <bialix> because if you have light checkout you've got wrong thing
[04:57] <bialix> see qmerge as example
[04:57] <igc> bialix: but it needs to work on a treeless branch
[04:57] <bialix> qpull then
[04:57] <bialix> igc: yes, it should
[04:58] <abentley> spiv: re: bug 250451, break-lock never suggests a URL, so I don't think your wording is an improvement.
[04:58] <igc> bialix: ok, I'll take a look
[04:58] <bialix> igc: but if there is tree it should uncommit in the tree to update dirstate
[04:59] <bialix> igc: lib/html_log.py?
[05:00] <bialix> is it exisiting code from somewhere else?
[05:00] <igc> bialix: code I use in explorer
[05:00] <bialix> ah
[05:00] <igc> bialix: we could use qlog widget if I knew how
[05:00] <bialix> we have htmlize function in util.py instead of cgi.escape
[05:01] <bialix> but maybe it does not matter right now
[05:01] <davidstrauss> This was a fun bug to run into today: https://bugs.launchpad.net/bzr/+bug/415936
[05:02] <bialix> igc: ok, so I've made almost full review over quncommit
[05:02] <igc> bialix: thanks for the fast review
[05:02] <bialix> igc: I need to go to work, I'll check mails but will be busy
[05:03] <igc> bialix: ok. Thanks
[05:03] <bialix> igc: qinfo is not critical for 0.14?
[05:04] <igc> bialix: well, it breaks in explorer when users ask for Location Information on anything without a WT :-(
[05:04] <bialix> now qinfo better
[05:05] <bialix> but anyway something wrong when I'm resizing it
[05:05] <igc> bialix: resizing is ok on Ubuntu fwiw
[05:05] <bialix> igc: perhaps I'll merge it anyway and we polish it later
[05:05] <bialix> wanna my screenshot?
[05:06] <igc> bialix: please - it's a step forward definitely
[05:06] <igc> yep
[05:07] <bialix> igc: http://imagebin.ca/view/21L7Di.html
[05:08] <bialix> igc: I'm just resize it by vertical up and dowm
[05:08] <bialix> down
[05:08] <igc> bialix: might be a bug in QFormLayout in Qt 4.4
[05:08] <lifeless> poolie: ping
[05:08] <lifeless> poolie: something is going wrong with your merges to bzr.dev
[05:08] <lifeless> 1.18 is in there twice, and this morning hno reporting that changes from 1.18 are listed under 1.17
[05:09] <bialix> igc: maybe, but it looks ugly nevertheless
[05:09] <bialix> ok, time runs out
[05:09]  * bialix disappears
[05:09] <igc> bye for now
[05:12] <xiaohui> Hi, when I use *bzr push* to my branch on lauchpad.net, it shows that the"Unable to obtain lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock
[05:12] <xiaohui> held by<EMAIL_ADDRESS>on host crowberry [process #10793]
[05:12] <xiaohui> locked 13 hours, 41 minutes ago
[05:12] <xiaohui> Will continue to try until 05:11:09, unless you press Ctrl-C
[05:12] <xiaohui> If you're sure that it's not being modified, use bzr break-lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock
[05:12] <xiaohui> bzr: ERROR: Could not acquire lock "(remote lock)": "
[05:13] <lifeless> bzr break-lock lp:~xiaohui/opencog/moses
[05:13] <xiaohui> I use the *bzr break-lock lp:~/xiaohui/opencog/moses* but is unuseful
[05:16] <xiaohui> then it returns an error:bzr: ERROR: exceptions.TypeError: a float is required
[05:16] <lifeless> xiaohui: what is your bzr version
[05:16] <lifeless> I believe that was a bug that we have fixed
[05:17] <xiaohui> my version is 1.14
[05:17] <lifeless> I'm quite sure that that is fixed
[05:20] <spiv> xiaohui: upgrade your bzr, or use "nosmart+lp:~xiaohui/opencog/moses" (I think) as a workaround.
[05:21] <xiaohui> what is the *nosmart*  mean
[05:23] <spiv> It disables most of the interesting smart protocol code, and just does direct file accesses.  It's roughly equivalent to sftp.
[05:24] <spiv> If I'm remembering correctly, it also avoids that bug in that version of bzr.
[05:27] <xiaohui> hmm, it doesn't work
[05:27] <xiaohui> so I have to upgrade the bzr
[05:38] <xiaohui> another error:
[05:38] <xiaohui> so what should I do? update the version of bzr
[05:38] <xiaohui> bzr: ERROR: Invalid url supplied to transport: "lp:~/xiaohui/opencog/moses": No such person or team:
[05:39] <xiaohui> why it said no such person or team
[05:41] <lifeless> you've mispelt the url
[05:41] <lifeless> you added a / between ~ and x
[05:41] <xiaohui> oh , my fault
[07:07] <vila> hi all
[07:47] <abentley> With bzr trunk, bzrtools tests are failing due to dirstate locks that did not fail previously: http://pastebin.ubuntu.com/256159/ Any ideas?
[07:50] <vila> abentley: does that involve some transform_tree ?
[07:51] <vila> abentley: https://code.launchpad.net/~lifeless/bzr/transform_tree/+merge/10440 may be related ?
[07:51] <abentley> vila: No, it doesn't involve that.
[07:51] <vila> I' don't that's been merged yet tough
[07:52] <vila> abentley: by the way, what TZ are you in right now ? 8-}
[07:53] <vila> abentley: well, your pastebin shows a 'transform_tree' in the traceback, so have a look at lifeless patch maybe that's what you need
[07:53] <abentley> Perhaps America/Caffienated.
[07:54] <vila> abentley: may be I should have said merge.transform_tree
[07:54] <lifeless> abentley: you may find my merge request put up a couple hours ago fixes them
[07:54] <lifeless> it fixed something like 1/2 the tests in bzr.dev that had been annotated as not being safe on windows
[07:54] <spiv> abentley: thanks for pointing out my thinko in that bug title.
[07:55] <abentley> spiv: np
[07:55] <lifeless> abentley: if it doesn't fix them, you can make them pass by calling thisTestFailsStrictLocks()
[07:55] <abentley> vila: Okay, I could have sworn it was failing when opening the tree.
[07:56] <vila> abentley: I've seen your announce for bzrtools-1.18 but no new commits on lp:bzrtools (and no tag either), that's what you're working on right now ?
[07:56] <vila> abentley: hehe ,np, get more caffeine :0D
[07:56] <abentley> vila: did that just before posting to IRC.
[07:57] <vila> abentley: excellent, pulled
[07:58] <abentley> lifeless: Your patch fixes my problem.
[07:59] <lifeless> cool
[08:23] <poolie1> hi vila?
[08:23] <vila> hey poolie1
[08:25] <poolie1> how's stuff?
[08:26] <vila> good ! ;-D
[08:28] <mdke> is there anyway that I can tell bzr merge to always prefer the source tree if it encounters a text conflict?
[08:37] <poolie1> mdke: no, but it'd be a nice feature to add
[08:38] <spiv> mdke: "bzr revert -r:parent `bzr conflicts`" or something like that would be a rough approximation.
[08:47] <mdke> poolie1: I'll file a bug I guess.
[08:47] <poolie1> vila, beyond the stuff in the metronome mail i'm thinking about branching off 2.0 tomorrow
[08:47] <poolie1> and then asking for only bug fixes into that
[08:47] <poolie1> what do you think?
[08:47] <mdke> spiv: thanks, should I run that after the merge or instead of it?
[08:47] <vila> poolie1: checking mail
[08:49] <vila> poolie1: right, I agree, 1.18final today and 2.0 tomorrow
[08:49] <vila> especially since karmic now passes the full test suite :-D
[08:49] <poolie1> or monday
[08:49] <poolie1> that's good
[08:49] <poolie1> it'd be nice to fix some more of the critical 2.0 bugs firs
[08:49] <poolie1> first*
[08:51] <vila> poolie1: yeah and check with jam too
[08:52] <mdke> spiv: the merge command I'm running which gives me the conflicts is "bzr merge -r 147..150 ../intrepid" - any idea how I could adapt your formula to suit that?
[08:55] <lifeless> poolie1: I'm fine with branching soon; just not 'releases' :)
[08:57] <mdke> brb
[09:02] <lifeless> poolie1: by which I mean, 'do you want me to branch 2.0 when I get up tomorrow'
[09:02] <poolie1> oh that'd be nice
[09:05] <mdke> spiv: nevermind - I've figured out that I can avoid the conflicts entirely by merging some earlier revisions first. Thanks for the help anyway though
[09:09] <poolie1> oh i did mention that already
[09:16]  * igc dinner
[09:20] <hno>  lifeless: A small piece of information missing from your 2a format switch announcement.. which version are minimum required to use 2a repositories.
[09:21] <lifeless> hno: 1.16 is the bare minimum, but its had _many many_ bugfixes since then
[09:22] <lifeless> hno: I would recommend the absolute latest version you can get - 1.18rc1 at the moment, and 2.0 for sure once thats released, as there are still major bugs related to 2a.
[09:22] <lifeless> (not in correctness, in performance regressions in various corner cases)
[09:22] <lifeless> hno: the headsup announcement was preventative for folk tracking trunk; we assume those folk know this stuff somewhat :)
[09:33] <poolie1> omg i just looked at the new project homepage https://edge.launchpad.net/bzr
[09:33] <poolie1> that is really nice
[09:35] <bob2> tad verbose
[09:35] <poolie1> mm the bit about packaging does not scale well
[09:35] <bob2> yeah
[09:36] <vila> poolie1: I had the same reaction yesterday evening
[09:37] <bob2> ah, looks less insane on a small monitor
[09:38] <bob2> on 24" the downloads stuff falls the bottom of the packages list
[09:40] <hno> lifeless: I would not bet on it..  memory quickly fades on in which version a format was added, and even quicker on which versions may have had serious bugs in the format...
[09:41] <lifeless> :)
[09:41] <lifeless> we'll make a serious song and dance about it when 2.0 is actually released.
[09:42] <lifeless> bob2: and they say size doesn't matter.
[09:45] <hno> regarding the new project page.. I agree that the packaging do not scale. Currently overly overbose, and sorted "wrongly". Should have most recent distribution first, and only list the current release per distribution by default with the full history collapsed.
[09:48] <marcchr> hi
[09:48] <marcchr> I have a problem merging from a bzr-branch into a svn-checkout. I get "AttributeError: 'Revision' object has no attribute 'foreign_revid'"
[09:49] <marcchr> http://pastebin.ubuntu.com/256202/
[09:51] <marcchr> bzr branch spam /tmp/test-zr; [modify something in test-zr and commit]; in spam: bzr merge /tmp/test-zr gives the error
[09:51] <marcchr> spam is the svn checkout
[10:04] <poolie1> marcchr: probably your copy of bzr-svn is out of date with bzr
[10:04] <poolie1> otherwise please file a bug in bugs.launchpad.net/bzr-svn
[10:05] <vila> lifeless: care to have a look at https://code.edge.launchpad.net/~vila/bzr/selftest-fixes/+merge/10364  ?
[10:05] <marcchr> bzr-svn 0.6.4 is the latest if I'm not mistaken?
[10:06] <marcchr> poolie1: ok, I will file a bug
[10:06] <marcchr> poolie1: I'm using bzr 1.17
[10:09] <poolie1> ok good night all
[10:11] <vila> poolie1: good night !
[10:26] <fullermd> Ooh, ...544432 for the 1.18 tar.  How cute.
[10:28] <vila> fullermd: Is that the size ?
[10:28] <fullermd> No, the lplibrarian dir.
[10:32]  * fullermd tosses ports updates out into the aether.
[11:28] <spirov92> hey, a quick question...
[11:28] <spirov92> if I in a branch I make a link to another branch(say, a module) how will bzr handle it?
[11:28] <spirov92> I mean a symlink
[11:30] <bob2> as a symlink
[11:30] <spirov92> but if the module folder has a .bzr folder, will it try to version it?
[11:31] <bialix> igc: are you still around?
[11:31] <bialix> igc: question about quncommit
[11:32] <igc> hi bialix
[11:32] <bialix> hi igc, I have some time to look at quncoomit
[11:32] <bialix> it looks better now
[11:32] <fullermd> spirov92: The symlink isn't dereferenced.  It's just stores as a symlink.
[11:32] <bialix> igc: I just wonder about terms, like tip
[11:33] <bialix> igc: why you're using idiom "move tip to"?
[11:33] <igc> bialix: would you prefer another name like "head"?
[11:33] <bialix> igc: this is not blocks me from merge, but if you have couple of minutes, I'd better ask
[11:34] <bialix> igc: no, I mean why we talk about moving tip and not about uncommit actually?
[11:34] <bialix> igc: e.g. we can show revision details under first radiobutton
[11:35] <bialix> and put the label for radiobutton: Uncommit last revision:
[11:35] <bialix> igc: actually I have troubles to correctly translate tip, and it does not seem bzr uses "tip" term internally or in the docs
[11:36] <igc> bialix: firstly, I think 'tip' is fine ...
[11:36] <igc> from core-concepts in the User Guide: The last revision is known as the *tip*
[11:36] <bialix> igc: ok, I did not know this
[11:37] <bialix> so I can translate tip as "last revision"?
[11:37] <igc> bialix: yes
[11:37] <bialix> I understand that "tip" is short and nice word in English
[11:37] <bialix> as many others: pull and push
[11:37] <igc> bialix: also, we need to display what revisions will be removed anyhow so there seems limited benefit in displaying that in advance
[11:38] <igc> bialix: I thought pretty hard about that and ...
[11:38] <bialix> it so nice to be Englishman and speak in so wonderful language
[11:38] <igc> I've been through several designs on paper over the last few months thinking about quncommit
[11:38] <bialix> igc: what if I want uncommit 100 last revisions?
[11:39] <bialix> what I'll see in confirmation dialog then?
[11:39] <igc> bialix: we'll display those just like the CLI does
[11:39] <igc> bialix: that would be very unusual, of course
[11:39] <bialix> on CLI any long info go out of my console
[11:40] <bialix> this becomes problem for GUI
[11:40] <igc> bialix: 99% of the time it's just one revision - to fix the commit message, bug metadata, etc :-)
[11:40] <bialix> you just can't have an infinite tall dialog, do you? ;-)
[11:40] <bialix> igc: so if this is 99% cases, why not show ther details right in the quncommit window?
[11:40] <igc> bialix: I guess we could use a scrolling panel or the qlog widget
[11:41] <igc> bialix: I'm ok with doing that
[11:41] <igc> bialix: I just don't think it's mandatory
[11:41] <igc> to land this
[11:41] <bialix> igc: no of course.
[11:41] <bialix> igc: +1 on land the last version
[11:42] <igc> bialix: thanks. Did you want to merge it or I?
[11:42] <bialix> igc: I'm just want to discuss with you how it could be improved, especially re better UI for translations to other languages
[11:42] <bialix> igc: if you can, merge n push it yourself
[11:42] <igc> bialix: no problem. I do think it can be improved
[11:42] <igc> bialix: but that can come later
[11:43] <bialix> yes, of course
[11:43] <igc> bialix: what about my qbind tweak?
[11:43] <bialix> but later I forgot what I'm thinking right now
[11:43] <bialix> qbind tweak sounds ok conceptually
[11:43]  * bialix looks at qbind patch now
[11:44] <igc> bialix: there have been a few threads re that on the main bzr list so ...
[11:44] <igc> I thought we'd make the GUI better at least
[11:44] <bialix> igc: can we just dump this discussion about quncommit to new bug report?
[11:44] <bialix> so I don't forget about it later?
[11:44] <igc> bialix: sure. Also, qexport should be cleaner now though ...
[11:45] <igc> bialix: I suspect it's still not perfect wrt lightweight checkouts
[11:45] <igc> bialix: but it ought to be a small tweak from here I hope
[11:50] <bialix> rats, what's going on with lp?
[11:51] <bialix> igc: what you mean when said: "there have been a few threads re that on the main bzr list so ..."?
[11:52] <igc> bialix: about checkout vs branch+bind
[11:53] <bialix> I'm lack context. This is related to qbind?
[11:54] <igc> bialix: yes. Basically having a bind checkbox on qbranch is desirable
[11:54] <igc> bialix: until then, it's nicer if qbind defaults to the parent if never bound before
[11:55] <bialix> igc: there is combain qgetnew
[11:55] <bialix> *combine
[11:55] <bialix> it do everything and makes you sandwitch
[11:55] <igc> bialix: right, but it's worth improving qbind anyway
[11:55]  * bialix looking at qbind actually
[11:55] <igc> bialix: I'm yet to warm to qgetnew
[11:56] <igc> bbiab
[11:56]  * bialix is not fun of qget new
[11:58] <bialix> igc: qbind patch is ok for me
[11:59] <bialix> igc: perhaps I'll look at qexport improvements later
[12:02] <bialix> igc: if you have any specific plans about releasing bzr-explorer let me know beforehand, I need to update translations
[12:27] <garyvdm> Hi all
[12:27]  * garyvdm was looking for jam
[12:28] <bialix> Hi garyvdm
[12:28] <bialix> too early for jam ,I guess
[12:39] <luks> bah, this reminds me why I stopped caring about bzr development
[12:49] <bialix> luks: ?
[12:52] <luks> bialix: nothing, I just read about the 2.0 branching and having a patch submitted at the start of 2.0dev cycle, it reminded me how non-Canonical patches are handled
[12:52] <luks> it's very demotivating
[12:53] <bialix> luks: I'm still under impression of discussion about review processes, I was guess it's relates
[12:54] <bialix> luks: yeah, it seems better way to ensure your patch will be merged is to poke people in this chat
[12:58] <fullermd> It IS rather disencouraging.
[12:59] <fullermd> Also makes one want to skip NEWS entries.  You know it'll just cause conflicts that have to be manually fixed anyway, 2 releases later when it's applied.
[13:17] <garyvdm> Hi bialix/luks
[13:17] <garyvdm> Hmm my irc is dodge. I can see bialix said hello to me here: http://irclogs.ubuntu.com/2009/08/20/%23bzr.html , but not in my irc client, and I was signed in....
[13:18] <bialix> your client seems timed out and reconnect then
[13:19] <garyvdm> luks: :-(  You should raise that as an issue.
[13:19] <bialix> I've heard this from luks beginnign from 2007
[13:22] <luks> garyvdm: it's not something I care that much about, it's just sad that bzr is even a GNU project, but the development process is far from the open source standard
[13:23] <fullermd> Well, I wouldn't go that far...
[13:23] <luks> I would :)
[13:23] <fullermd> But that's more a statement on the state of the 'open source standard'.
[13:24] <luks> well, I wouldn't say a word if patches were ignored and there were no releases
[13:24] <luks> but the issue is very visible with monthly releases
[13:35] <garyvdm> bailix: Anything important that you want me to look at for 0.14?
[13:36] <bialix> garyvdm: I guess everything is ok
[13:36] <bialix> luks mentioned slower startup of qcommit
[13:36] <bialix> I see this too
[13:36] <fullermd> I came across some annoying behavior in qlog that I'm not sure is a bug (or how to describe concisely if it is)...
[13:36] <bialix> I guess the problem in new treewidget stuff
[13:36] <luks> that's not easy to fix, I guess
[13:37] <bialix> garyvdm, luks: I'm still mulling the idea, but I have a feeling that we need either threads for long running stuff or launch subprocess to do heavy work and implement some sort of rpc
[13:37] <fullermd> Clicking on a rev in the list selects it, but there's no way to un-select it.
[13:37] <bialix> and implement multi-pass visualisation for things
[13:38] <bialix> garyvdm: no, I remember
[13:38] <luks> bialix: well, that will not make it faster, just more responsive
[13:38] <bialix> garyvdm: problem with misadded
[13:38] <fullermd> When you expand a branch in the history, it redraws the window, and adjusts placement to show the selected row, if there is one.
[13:38] <bialix> luks: if we populate the widget in qcommit with simplke data and then add more data, e.g. icons
[13:38] <fullermd> So, if you've selected a rev, scroll around a while, then expand a branch, *pow* you're dragged way the heck away from what you just expanded.
[13:39] <bialix> fullermd, garyvdm: I think it was fixed recently?
[13:39] <garyvdm> My irc seems very delayed.
[13:39] <garyvdm> bialix: bug 414729.
[13:39] <bialix> garyvdm: yes
[13:40] <bialix> garyvdm: I found the way how to hide this items from qcommit
[13:40] <bialix> but not from qbrowse
[13:41] <garyvdm> fullermd: Thats has been fixed.
[13:41] <fullermd> Hm, guess so.  Can I borrow this time machine sometime?
[13:42] <garyvdm> fullermd: in rev 902
[13:42] <bialix> fullermd: you're always welcome
[13:42] <fullermd> Doubly irritating since I was at 901   :p
[13:42] <bialix> garyvdm: here where I've started http://pastebin.com/m1cee143
[13:42] <luks> :)
[13:42] <bialix> lol
[13:43] <garyvdm> bialix: re bug 414729: we can just filter out the item in the FilterProxyModel.
[13:44] <bialix> garyvdm: we need the list of misadded for qcommit to implicitly commit them
[13:48] <garyvdm> bialix: I just checked on this: The FilterProxyModel affects what is displayed, but not what is passed to the command line. - So that would be the place to do it.
[13:49] <bialix> garyvdm: that's nice!
[13:49] <garyvdm> bialix: You will see in the FilterProxyModel that we allways show an item that is checked, so you will have to override that.
[13:51] <garyvdm> bialix: I'm going to do some profiling of qcommit. I be afk from about 4pm to about 8pm UTC+2
[13:51] <bialix> garyvdm: I'll start prepare release after 8pm UTC+2
[13:51] <bialix> and will be in iRC
[13:55] <davertron> hi, I'm getting "Cannot lock LockDir" when I try to pull from a remote repo due to a permission denied error trying to write to .bzr/branch/lock; however, if i go look at that directory, my user belongs to the right group and that group has write permission on that directory. Any idea what I'm doing wrong?
[13:57] <garyvdm> luks, bialix: In what situations is qcommit load slow. It is quick for me.
[13:58] <davertron> also, another interesting thing is that the parent branch isn't the directory where I get the error from
[13:58] <bialix> garyvdm: it's not slow as "really sloooooooooooooow". it's just now slower than before treewidget landed
[13:58] <bialix> qbrowse too
[13:59] <garyvdm> luks, bialix: If you have a situation that is slow, please email me a .callgrind.
[13:59] <garyvdm> davertron: please will you pastebin the last entry of ~/.bzr.log
[14:01] <davertron> garyvdm: from the directory i'm trying to pull from or the one i'm pulling to, or does it matter?
[14:02] <garyvdm> davertron: there will only be one on your computer.
[14:02] <garyvdm> davertron: are you on windows?
[14:02] <davertron> garyvdm: sorry, I'm pulling from a totally different machine, does it matter if it's from the machine i'm pulling to or the machine i'm pulling from?
[14:02] <davertron> garyvdm: nope, on ubuntu
[14:03] <garyvdm> davertron: The machine that you ran the bzr command on.
[14:04] <davertron> garyvdm: http://pastebin.ca/1536285
[14:06] <davertron> garyvdm: nm, I think i figured it out
[14:06] <davertron> looking at wrong machine i think
[14:06] <garyvdm> davertron: Cool
[14:06] <davertron> i was looking at the permissions on the remote machine, instead of the local machine
[14:07] <davertron> should have noticed the "file:///" stuff...
[14:07] <davertron> thanks :)
[14:18] <vila> http://instantrimshot.com/
[14:19] <vila> Finally no more './bzr selftest --no-plugins' that fail to test core plugins, welcome `BZR_PLUGIN_PATH=-site ./bzr selftest` :-D
[14:20]  * beuno is going to release loggerhead today so it can get updated for karmic
[14:23] <vila> fullermd: funny qlog bug huh ? Drove me nuts too but garyvdm fixed it as soon as I mentioned it :-D (Of course the pity is I mentioned it after having suffered a lot :)
[14:25] <vila> Can someone remember where we wanted to display the plugins path ?
[14:34] <bialix> vila: nice
[14:34] <vila> bialix: https://code.edge.launchpad.net/~bzr/bzr/412930-plugin-path/+merge/10458 pending review :-D
[14:35] <vila> bialix: Even if you don't vote, I'll appreciate your comments regarding windows,
[14:35] <bialix> vila: I'll try to look tonight
[14:35] <bialix> from home
[14:35] <vila> I've read a couple of bug reports but what needs/can/shouldn't be done on windows is a bit unclear to me,
[14:35] <bialix> ROTFL
[14:35] <vila> in particular, is there a clean way to have a 'site' directory for shared plugins ?
[14:35] <bialix> what?
[14:36] <vila> a directory where plugins can be installed and used by all users
[14:37] <vila> If I read the current code correctly we don't even try to define one for win32, I've respected that but I've also read various incoherent reports on that
[14:41] <davertron> man, still running into permissions errors trying a bzr pull...everything looks like it's going fine, but then i get a "Permission denied" on .bzr/repository/upload/598ikvm63uwlti81qibp.fetch", even though I own that file and have read/write permissions on it
[14:41] <davertron> everytime i run "bzr pull", i get a new file that is created in that directory and the same "permission denied" error
[14:44] <davertron> http://pastebin.ca/1536340 output from last entry in ~/.bzr.log
[14:48] <vila> davertron: you're working under /usr/local/lib ? With what login ?
[14:48] <davertron> david.davis
[14:49] <davertron> this is a repo that someone else intitally set up
[14:49] <davertron> so that's why i think i'm having the issues with it
[14:49] <davertron> i don't think they did a good job of setting permissions on the damn thing
[14:50] <vila> the permission denied is related to the containing directory (upload) do you have write access there ?
[14:50] <davertron> i do
[14:50] <davertron> in fact, the file that it claims "permission denied" on is created in that directory
[14:50] <davertron> whenever i run "bzr pull"
[14:50] <bialix> vila: vso what is your question?
[14:51] <bialix> vila: do you read bzrlib/plugin.py?
[14:51] <vila> hmm, yeah, right, sorry, look under the packs directory, that should be the target and the place where you lack access
[14:51] <vila> bialix: I patched it heavily yes, did you read my merge proposal ?
[14:51] <vila> :)
[14:52] <vila> damn, I just realized I dind't preserve the 'no site directory for win32' bit :-/
[14:52] <bialix> vila: sorry, I'm busy right now
[14:53] <vila> bialix: np
[14:53] <bialix> vila: I'll read your patch tonight, from home
[14:53] <davertron> vila: yeah, i just ran a chmod -R g+w on the whole .bzr dir
[14:53] <davertron> that seems to have gotten me a little farther
[14:53] <davertron> the perms on this repo are just all hosed
[14:53] <davertron> the guy who created it obviously didn't set perms correctly for anyone else to work on it
[14:53] <davertron> even though it's a damn production deploy repo
[14:54] <davertron> anyway
[14:54] <davertron> i'll just have to keep mucking with the stupid perms
[14:54] <davertron> and try not to take the site down :p
[14:54] <vila> davertron: may be you should just stop working in /usr/local but install there from root
[14:54] <vila> You already have a shared repo on another server right ?
[14:54] <davertron> yes
[14:54] <davertron> he didn't really set that one up right either :)
[14:55] <davertron> i had to muck with that for a bit so I could push to it
[14:55] <vila> davertron: no need to mess with permissions in two different places no ?
[14:55] <davertron> now i'm mucking more to pull
[14:55] <davertron> well, bzr doesn't preserve all perms does it?
[14:55] <vila> davertron: rm -fr the damn thing :-) (Kidding put it aside instead)
[14:55] <davertron> vila: heh
[14:55] <davertron> vila: i'll just rm -rf this other developer instead... :P
[14:56] <davertron> he's got different perms on the different repos, so he probably screwed it all up himself just to get it working in production
[14:56] <davertron> different groups own different things
[14:56] <davertron> it's a mess :)
[15:02] <emmajane> beuno, ping.
[15:02] <beuno> emmajane, hi
[15:02] <emmajane> PM ok?
[15:02] <beuno> always!
[15:02] <emmajane> excellent. :)
[15:06] <igc> night
[15:10] <beuno> igc, night!
[15:10] <beuno> I forgot to CC you on an email for the bazaar web page design
[15:10] <beuno> fwding now!
[15:11] <vila> beuno: wrong window ? :-D
[15:11] <beuno> vila, no!
[15:11] <beuno> it's public  :)
[15:12] <vila> but who is 'you' in 'CC you' then ? :)
[15:12] <beuno> vila, igc
[15:13] <beuno> I'm just lazy
[15:13] <vila> haaa
[15:13] <vila> right, makes sense, was a bit ambiguous, thought it was for emmajane :)
[15:14]  * emmajane is apparently off in another world and requires explicit pinging to see windows. :)
[15:30] <beuno> james_w, hi
[15:30] <james_w> hey beuno
[15:30] <beuno> james_w, how are you?
[15:31] <james_w> good thanks, how about you?
[15:31] <beuno> pretty good
[15:31] <beuno> sprinting, as usual  :)
[15:31] <beuno> james_w, I need your super powers
[15:31] <james_w> where are you this time?
[15:32] <beuno> james_w, buenos aires, but sprinting anyway  :)
[15:32] <james_w> nice
[15:32] <beuno> with the Ubuntu One guys
[15:32] <james_w> ah, cool
[15:32] <beuno> james_w, I've released a new version of Loggerehad
[15:32] <beuno> so we can get all the changes into loggerhead
[15:32] <beuno> er
[15:32] <beuno> karmic
[15:32] <beuno> :rolleyes"
[15:32] <james_w> ok
[15:33] <beuno> james_w, can you upload to ubuntu and/or karmic?
[15:33] <beuno> jelmer doesn't seem to be around
[15:33] <james_w> I'll work on it
[15:34] <beuno> james_w, THANK YOU
[15:34] <beuno> I'm in London for the last 2 weeks of Sept
[15:34] <beuno> please come by to say hi and claim your beer
[15:35] <james_w> heh
[15:42] <james_w> beuno: I like the new project overview pages, thanks
[15:43] <beuno> james_w, ah, I'm happy to hear that
[15:43] <beuno> a fe wmore changes in the pipeline, but it's roughly what it will look like
[15:43] <james_w> a lot less scrolling and hunting
[15:48] <beuno> james_w, how does the navigation feel?
[15:50] <james_w> beuno: better I think, though the fact that what were the tabs are now much less prominent threw me
[15:50] <james_w> plus I just noticed "Submit code" goes to what I presume is the wrong place
[15:51] <beuno> james_w, yeah, still working out the quirks
[15:51] <james_w> I certainly find it much more attractive, but I know you're interested in more than that :-)
[15:51] <james_w> and I still have quibbles with merge proposals
[15:51] <beuno> yes, merge proposals is the next thing I'm working on for the 3.0 re-design
[15:51] <beuno> will CC you on the email, if you like
[15:51] <beuno> it will go to the launchpad-dev list, if you're subscribed
[15:52] <james_w> I'm not, but I think I will do so now
[15:52] <james_w> there's a mail I need to send to it, but I can't remember what right now
[15:52] <james_w> I can't find a bug for this "Submit code" thing, I'll file it now unless you know it's known
[15:53] <beuno> james_w, it's been submitted to PQM already
[15:53] <james_w> ah, excellent
[16:26] <vila> beuno: 'last bugs reported' and 'last bugs touched' lists should be longer or an access to a longer list should be provided,
[16:27] <vila> I think the bug mentioned by james_w above is the one filed by lifeless less than a day a ago, and commented by me less than half a day ago, and yet, it's nowhere to be seen...
[16:28] <beuno> vila, yes, we're trying to figure out that page
[16:28] <vila> beuno: I understand, that's why I throw my 2 cents remark :)
[16:28] <vila> ha, here it is: bug #416125
[16:29] <vila> ha err, not sent to pqm then, were you talking about a different one ? james_w ? beuno ?
[16:30] <beuno> vila, the fix should be visible tomorrow
[16:30] <vila> beuno: don't you mark the bug Fix committed or at least in Progress ?
[16:30] <vila> or is it just a dupe ?
[16:30] <beuno> vila, it should be in progress
[16:30] <beuno> I'll ask  :)
[16:31] <vila> not really important. I was just wondering
[16:31] <beuno> vila, feedback is very useful, thank you
[17:30] <ddaa> hey
[17:30] <ddaa> anyone has figured out yet how to use the "parent diff" feature of reviewboard?
[17:31] <ddaa> it's driving me totally nuts
[17:36] <mtaylor> sadness has happened!
[17:36] <mtaylor> ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('lua-20081111233858-hzs0ti8sqjaycvlp-16', 'monty@inaugust.com-20081111233949-xwxzzzus31nn99aa')")
[17:47] <ddaa> Mh okay it SEEMS to expect the following
[17:48] <ddaa> diff = ancestor::prev..:last
[17:49] <ddaa> parent-diff = base-of-first-diff-for-this-review-request..ancestor::prev
[17:50] <ddaa> The problem I'm tying to solve is: How to feed reviewboard updated diffs when the branch to review merged changed from its base branch.
[18:51] <bialix> vila: why not: bzr --only-user-plugins selftest ...
[18:55] <rockstar> vila, tarmac just puked on me with the following error: http://pastebin.ubuntu.com/256461/
[18:56] <rockstar> It happened trying to commit from a heavyweight checkout.
[18:58] <bialix> rockstar: are you using 2a?
[18:58] <rockstar> bialix, I am indeed.
[18:58] <bialix> your server need upgrade maybe
[18:59] <rockstar> bialix, the server is Launchpad.  While we might be behind a bit, I don't think that's the issue, since I've been dealing with Launchpad all day.
[19:00] <bialix> error tells that some bzrlib does not understand your format
[19:00] <bialix> either your local installition or server
[19:00] <bialix> check /usr/lib/python2.6/dist-packages/bzrlib then
[19:02] <rockstar> bialix, I'm on bzr.dev
[19:02] <bialix> run bzr info -v then
[19:05] <bialix> are you sure that /usr/lib/python2.6/dist-packages/bzrlib is bzr.dev?
[19:17] <bialix> garyvdm: ping
[20:08] <garyvdm> bialix: Hi
[20:30] <sveinung> is this the correct place to ask questions about bzr builddeb?
[20:30] <james_w> sure
[20:31] <sveinung> I have checked out, built and installed the latest version from the bzr branch on launchpad
[20:31] <sveinung> how do I make it use the Debian date?
[20:31] <sveinung> when importing
[20:31] <sveinung> I see the code is there
[20:31] <sveinung> but I cant find an option to enable it
[20:32] <sveinung> (I look at bzr help import-dsc)
[20:32] <sveinung> when I say Debian date I mean the one from the changelog
[20:32] <james_w> hmm, it's not hooked up to the UI is it?
[20:34] <james_w> it's something I added later, and I didn't think it should be default
[20:34] <james_w> now I'm not so sure
[20:34] <sveinung> james_w: Ok, thanks
[20:34] <sveinung> so I should modify bzr builddeb if I want it?
[20:35] <james_w> patches welcome :-)
[20:51] <verterok> join #twisted
[21:10] <sveinung> james_w: is changelog-time an Ok name for an option?
[21:10] <james_w> I guess
[21:11] <james_w> should the default just change instead?
[21:13] <sveinung> I must admitt I was kind of confused when it used todays date. But I have looked at the autoimported branches at launchpad so I'm not sure if that is what will be least surprising for other people
[21:13] <sveinung> so I don't know
[21:15] <james_w> I think it might be better
[21:16] <james_w> I can't really remember my reasons now :-)
[21:17] <sveinung> ok
[21:18] <sveinung> (the it that might be better was to change the default, right?)
[21:32] <james_w> yeah
[21:46] <sveinung> james_w: is the test suite run during the building of the debian package?
[21:48] <lifeless> moin
[22:42] <sveinung> james_w: I found out how to run the test suite on my own. Merge request sendt
[22:57] <johnjosephbachir> if i have a lone checkout with no surrounding repo, but then make a repo, make a branch there, and then physcially move my checkout into the repo and bind it to the branch, will it [a] work, and [b] actually take advantage of the repo data?
[22:58] <bialix> a - yes, b - you need to run reconfigure
[23:00]  * johnjosephbachir looks at documentation for reconfigure
[23:00] <johnjosephbachir> bialix: thanks!
[23:00] <bialix> bzr help reconfigure
[23:02] <johnjosephbachir> bialix: hmm, even after doing that, my old reconfigured checkout (which i then turned into a branch) is  double the size of a fresh new branch
[23:03] <bialix> bzr reconfigure --use-shared ?
[23:04]  * johnjosephbachir reads the documentation more thoroughly......
[23:05] <johnjosephbachir> bialix: perfect.
[23:18] <Noldorin> lifeless: ping?
[23:25] <james_w> thanks sveinung
[23:25] <sveinung> np :)
[23:25] <james_w> I'll review tomorrow
[23:26] <sveinung> great
[23:27] <lifeless> Noldorin: hi?
[23:27] <Noldorin> heh
[23:27] <Noldorin> just checking you were there :)
[23:28] <Noldorin> lifeless: i'm trying to hack the source into outputing ftp commands now
[23:28] <Noldorin> but it doesn't seem trivial without altering the source for the actual ftp lib
[23:28] <Noldorin> any ideas here?
[23:28] <lifeless> if you want to log the exact commands tcpdump, or wireshark, or similar tools might be better suited
[23:28] <lifeless> I was suggesting just getting close :)
[23:30] <Noldorin> hmm, good point
[23:30] <Noldorin> might just use wireshark.
[23:30] <Noldorin> does the windows ftp client support ftp scripts?
[23:32] <Noldorin> the reason i'm wanting to replicate is purely out of laziness :)
[23:43] <Noldorin> RNTO /texdotnet/.bzr/repository/lock/held
[23:43] <Noldorin> FTP	Response: 550 /texdotnet/.bzr/repository/lock/held: Cannot create a file when that file already exists.
[23:44] <Noldorin> lifeless: that's what we expect, right?
[23:44] <igc> morning
[23:44] <goneri> hi igc
[23:44] <igc> hi goneri - I haven't forgotten your patch btw
[23:45] <goneri> (yes, I'm watching you :D)
[23:45] <igc> goneri: just flat out on non fast-import stuff yesterday
[23:45] <goneri> igc: I rewrite the second patch. There is just two tiny patches now.
[23:46] <goneri> s/rewrite/rewrote
[23:53] <lifeless> Noldorin: thats the behaviou, yes
[23:54] <Noldorin> lifeless: so there's a rename command before that which failed?
[23:54] <Noldorin> renaming /lock/held to something else
[23:54] <Noldorin> i presume
[23:54] <lifeless> yes
[23:54] <lifeless> but if theory is right it isn't actually erroring :)
[23:55] <lifeless> its just not working
[23:56] <Noldorin> yeah
[23:56] <Noldorin> just wanted to double check that
[23:56] <Noldorin> in the wireshark log
[23:57] <denys> I am unable to run the full test suite.  it always eventually errors out with "error: can't start new thread".  is there a trick I should know?
[23:57] <lifeless> is that with or without your patches?
[23:57] <lifeless> and on what platform?
[23:58] <denys> without and on gentoo/linux


[02:10] <lapion> Hi,
[02:17] <lapion> For some months now caja when displaying files on the desktop doesn't correctly truncate the amount of files displayed on the primary display of a desktop if it's resolution is lower then the 2 other displays of the desktop if that first display has a panel  on the left edge and top and bottom of that lower res display. ( the lower resolution display is to the far left of the desktop
[02:45] <superkuh> "truncate the amount of files displayed"? Do you mean the icons are not visible on the primary display and run off the display when tiled/organized?


 Is it safe to upgrde from Groovy to Hippo yet?
[02:37] <valorie> I did it with my travel lappy
[02:37] <valorie> all is well
[02:37] <valorie> have not had time to do it with this computer yet
[02:37] <valorie> maybe Sunday
[02:58] <guiverc> @Anarchotaoist, the Ubuntu release notes explain the reason why it wasn't opened; you can see https://askubuntu.com/questions/1333226/how-can-i-update-to-ubuntu-21-04/1333229#1333229 or https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221
[02:59] <guiverc> the bug is still marked IN PROGRESS so if you machine is one impacted; you won't reboot after upgrade..  (if you're not impacted you won't have issues)
 WFX
 NFLQ
 NELQ
[07:45] <alkisg> Hmm the NELQ keys are too far apart to imagine a cat walking on the keyboard... :D
 @alkisg, 🤣 Indeed
[12:33] <BluesKaj> Hi folks
[12:34] <evert1> hello, I'm trying to upgrade my 20.10 kubuntu to the new release. I followed the steps described on the website release article, but getting a 'no new release found'. Any tips how to fix this? Release-upgrades is set to 'normal'
[12:42] <BluesKaj> evert1, check your package manager sources setting, set to normal rather than LTS only
[12:42] <BluesKaj> ok
[12:43] <BluesKaj> then try sudo do-release-upgrade -d
[13:01] <evert1> BluesKaj: is that not the 'prompt=normal' in '/etc/update-manager/release-upgrades'?
[13:03] <tomreyn> evert1: it is. note that the 20.10 -> 21.04 upgrade path is not yet supported, there's a blocking bug which can lead to systems not booting due to a grub issue in combination with EFI 1.1 'BIOSes', which will need to be fixed first of all.
[13:03] <tomreyn> just wait a week or two and try again
[13:03] <evert1> tomreyn: oh, ok, I was not aware of that, thanks
[13:03] <tomreyn> you're welcome
[13:05] <BluesKaj> tomreyn, thanks for the heads up on thay bug :-)
[13:05] <BluesKaj> that
[13:10] <tomreyn> BluesKaj: you're welcome, i think it's on the release notes, too
[13:14] <BluesKaj> so 21.04 is kind of dead in the water until this bug is fixed
[13:16] <mikedk> BluesKaj: what bug? still issues with i5's and i7's?
[13:19] <BluesKaj> mikedk, no, quote: "<tomreyn> evert1: it is. note that the 20.10 -> 21.04 upgrade path is not yet supported, there's a blocking bug which can lead to systems not booting due to a grub issue in combination with EFI 1.1 'BIOSes', which will need to be fixed first of all."
[13:21] <BluesKaj> mikedk, I meant dead in the water for 20.10 to 21.04 reales upgrades
[13:21] <BluesKaj> release
[13:23] <mikedk> BluesKaj: oooh, so upgrade through rolling release method? That has always been an issue. an old friend from the danish Linux group tried doing rolling release method upgrading all the way from Warty back in, I think it was 2007 or 08'. At some releases he had to make a clean install. but basicly it actually worked back then.
[13:24] <mikedk> But DID produced some minor errors, but it worked
[13:25] <BluesKaj> yup, I recall having problems with the old release upgrade command so I did quite a few clean installs up until 2009 or so
[13:26] <mikedk> Yes, i remember that too. Had my fare share of installs from alternate cds back then.
[13:29] <mikedk> Have an old Linux friend from the gaming community, he started with Gentoo back in the day. So he knows his way around. Had him helping me with Debian Sarge install back a bit beofre May 1st 2004. Runned that for a while untill I stumbled over Ubuntu, Been using Ubuntu and derivatives ever since.
[13:29] <BluesKaj> I've been testing Kubuntu dev releases since 2010 , but I usually sed my sources list to the new dev release...it's a workaround that's worked so far
[13:30] <mikedk> :-D yeah, actually surpriced me some times that that method actually works with quite a lot of releases
[13:32] <mikedk> started playing around with psychocats guides back then too. actually loved the old e16 desktop
[13:45] <VvdBergh> just did a fresh install of #kubuntu on my brand new notebook
[13:51] <BluesKaj> VvdBergh, and ?
[13:51] <VvdBergh> I like it so far
[13:51] <VvdBergh> no hardware issues fortunatly
[13:52] <BluesKaj> good
[13:52] <VvdBergh> i guess i will reduce the swappiness of the system as I run with 32 GiB of RAM and the setting is at 60 out of the box
[13:53] <VvdBergh> to bad I have Nvidia graphics otherwise I could have started a Wayland Plasma session. That just killed itself during login
[14:01] <VvdBergh> so swappiness should be fixed now.
[14:01] <BluesKaj> VvdBergh, wayland isn't ready for primetime with kde/plasma no matter which gpu you have
[14:01] <BluesKaj> oops, too late
[14:06] <VvdBergh> setting swappiness to 10 via sudo nano /etc/sysctl.conf and then putting it into the file with nano worked great. just did a quick reboot to check and I got it back to the setting I put it on.
[14:07] <BluesKaj> VvdBergh, wayland isn't ready for primetime with kde/plasma no matter which gpu you have
[14:07] <VvdBergh> the responsiveness of the system is better now, not that it was bad to start with but why on earth does (K)ubuntu ship with a kernel that has a swappiness setting of 60 out of the box?
[14:08] <VvdBergh> @BluesKaj but I at least want to give it a try and see how far I can get it operational for my daily stuff.
[14:08] <VvdBergh> epic fail at login due to Nvidia drivers not supporting it properly is embarrassing
[14:14] <BluesKaj> it's not epic, it's just the development speed is slower on kde/plasma and nvidia, since there are fewer users
[14:21] <VvdBergh> I consider something an epic fail if it fails to start when I try to start something.
[14:21] <VvdBergh> Maybe I could try switching to Nouveau driver but no idea if it would change something in the outcome
[14:23] <VvdBergh> to bad my new notebook does not have Intel or AMD graphics in it as they tend to work better with wayland. It was just to hard to get a notebook with either of them inside for graphics performance
[14:32] <mikedk> VvdBergh: nouveau driver works very good in the new releases. Or so I've heard. It works better than the closed source binary driver in 14.04. which I'm still using. I'm not gonna upgrade to something that doesnt work on a daily basis. And it hasnt been since 16.04. constantly issues on other machines since 16.04. So I'm staying on 14.04 until the newer releases can boot my i7 4core. Tried 20.04 installed fine, and worked fine,
[14:32] <mikedk> until the 5.9 kernel came as an update. Then ist topped booting. tried installing 20.10 installed fine, but wouldnt boot at all.
[14:34] <VvdBergh> @mikedk I do not run games on my notebook anyway so for gaming performance I would not need Nvidia drivers anyway. I only need 2d power to give me my desktop and display the applications I use (Thunderbird, Firefox, Libreoffice, Skrooge, Scribus, Chemdraw)
[14:35] <mikedk> nouveau driver gives good 3d accel, actually works with games too.
[14:36] <mikedk> VvdBergh: so I can really recommend the nouveau driver.
[14:36] <VvdBergh> The installer did the installation of the Nvidia driver without asking in 21.04. I guess I will switch the driver of and go to nouveau after a reboot. Worst case scenario I have to reactivate the Nvidia driver and reboot back to X11 session
[14:37] <mikedk> yes, no problems there, that's easy.
[14:40] <VvdBergh> I guess I first set my workflow up. I just integrated my irc instances into Thunderbird via the chat option
[14:43] <VvdBergh> I try to get all the stuff I need and want running in as few applications as possible. Now I just need to find a way to get my Twitter feed into Thunderbird as well. It was working great in Thunderbird 68, but in Thunderbird 78 the addon I used is not working.
[14:46] <VvdBergh> I either need to get myself a proper client that respects my KDE desktop settings or use the **** website of twitter that I have not visited in ages for good reason. The only thing I use twitter for is getting a few news feeds in so opening a webbrowser tab for it sucks as it will launch a shitload of trackers towards my browser in the proces.
[16:52] <skramer_> How can I make the column width in KMail's e-mail list persistent?
[16:59] <Acts10-13> I am trying to upgrade to kubuntu 21.04 but `sudo do-release-upgrade -m desktop` can not find a new version.
[17:01] <RikMills> Acts10-13: https://lists.ubuntu.com/archives/ubuntu-devel/2021-April/041448.html
[17:01] <VvdBergh> I guess you first installed any available upgrades in Kubuntu 20.10 before trying to upgrade?
[17:02] <VvdBergh> then run sudo do-release-upgrade -d instead
[17:02] <Acts10-13> RikMills: -d seems to have worked. Thanks.
[17:08] <krytarik> And now to see if it also still boots.. >_>
[17:08] <Acts10-13> I have to set myself a pretty rigorous schedule for the next 4 months. Any opinions or thoughts on KOrganizer?
[17:08] <Acts10-13> I'd like it to give me alerts, play notifications and sounds when something comes up, etc.
[17:22] <Maik> Acts10-13: it's not recommended to upgrade to 21.04 as of yet due a bug
[17:22] <Acts10-13> Maik: What sort of bug are we talking about?
[17:22] <Acts10-13> Its upgrading as I speak.
[17:22] <Maik> https://www.omgubuntu.co.uk/2021/04/why-you-cant-upgrade-to-ubuntu-21-04-for-now
[17:23] <Acts10-13> how should I stop my upgrade then?
[17:24] <Acts10-13> Its downloading sources right now.
[17:24] <Acts10-13> just ctrl-c?
[17:24] <Maik> i don't know
[17:24] <Acts10-13> ctrl c it is
[17:24] <Acts10-13> lol
[17:25] <Maik> and -d let's you upgrade to a development version i was told so not recommended
[17:25] <Maik> VvdBergh: ^
[17:25] <VvdBergh> if you did the download only option during the upgrade and not actually install anything it is just a matter of sudo apt clean after the fact
[17:26] <VvdBergh> @Maik it forces the upgrade and when you are on 20.10 it will only bring you to 21.04 anyways
[17:26] <Maik> still not recommended at this point though
[17:29] <Acts10-13> oof now my dependencies are broken
[17:29] <VvdBergh> recommended or not is not the point. If someone wants to upgrade I assume someone knows the risk of an upgrade and concluded it was acceptable to that person.
[17:29] <Acts10-13> Now I can't install things like korganizer
[17:29] <VvdBergh> use dkpg command to fix your apt settings
[17:31] <Acts10-13> okay
[17:31] <tomreyn> Acts10-13: your apt sources were modified, now point to the target release
[17:31] <VvdBergh> sudo dpkg --configure -a' i believe it was @Acts10-13
[17:31] <tomreyn> if you wish to stay on the previous release, you will need to undo the change
[17:31] <Acts10-13> thanks
 Hi ! I would like to install PNG++0.2.9 but I always get errors in kubuntu 20.04!
 How to figure out this prob
 All versions of PNG++ won't be installed
 I tried them all
[17:34] <VvdBergh> we need more information for that to help you
[17:35] <Acts10-13> VvdBergh: Are you sure? I ran that, then I ran an upgrade, and it looks like it wants to still do an entire distribution upgrade
[17:36] <Acts10-13> yeah my sources are on hirsute.
[17:36] <Acts10-13> How do I downgrade it back to groovy?
[17:37] <krytarik> "<VvdBergh> recommended or not is not the point. If someone wants to upgrade I assume someone knows the risk of an upgrade and concluded it was acceptable to that person." - except you merely suggested using the '-d' flag, and simply assumed they know about the various kinds of risk this involves..
[17:40] <krytarik> Acts10-13: You need to edit your sources by hand and simply replace all occurrences of "hirsute" back to "groovy"
[17:41] <Maik> VvdBergh: i gave a clear reason why it's not recommended to upgrade at this point and that's because of a bug as i mentioned earlier
[17:41] <Acts10-13> good to know
[17:41] <Acts10-13> and how do I check my efi version? Restart?
[17:42] <Maik> VvdBergh: if people want to be that stubborn be my guest
[17:42] <krytarik> Now now..
[17:44] <Maik> Acts10-13: it was posted yesterday somewhere but i forgot about it, sorry
[17:44] <Acts10-13> Maik: mmm no problem. I'm surprised ddg doesnt have a simple solution immediate
[17:46] <Acts10-13> brb rebooting
[17:48] <krytarik> Acts10-13: Running off to another channel (#ubuntu) in the middle of a conversation here to also get advice there is mildly rude btw.
[17:49] <Acts10-13> I rebooted to get the uefi version.
[17:50] <Acts10-13> It's 1.79. I don't know if uefi is the same as efi
[17:50] <Acts10-13> krytarik:
[17:53] <VvdBergh> @krytarik I assume people who want to upgrade did their homework in advance. Yes I personally always use the -d flag to upgrade, but I only download the upgrades in graphical mode, then go to low graphics mode and do the actual installation.
[17:55] <krytarik> Assuming people have done prior research.. on IRC.. XD
[17:55] <Acts10-13> krytarik: Oh yeah, sorry. I guess that is a bit rude.
[17:55] <VvdBergh> @krytarik if it was a fresh install I would assume zero knowledge and 100% stupidity. I guess I am old school in that retrospect. Maybe it is because I use linux since 2000 and Kubuntu since 2006
[17:57] <VvdBergh> @krytarik the usage of irc means people have some understanding of what they do as all the new kids on the block will not know a thing about irc or how to get on it in the first place
[17:58] <Acts10-13> VvdBergh: It also depends on the person's profession. I use IRC, I even consider myself a Software Engineer, but when it comes to system administration, I am prepetually green to the topic.
[17:59] <krytarik> VvdBergh: Except if you simply click a link on a website or open a preinstalled IRC client with a default channel set..  But let's leave it at that.
[18:00] <VvdBergh> you mean the click and pray generation?
[18:02] <krytarik> Acts10-13: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1925010 - seems to indicate you should be fine with the EFI version you got.
[18:02] <Acts10-13> krytarik: Thank you for all the effort on my behalf
[18:03] <Acts10-13> !cookie | krytarik
[18:03] <krytarik> XD
[18:03] <Acts10-13> !cookies | krytarik
[19:29] <Acts10-13> Hey I updated kubuntu and my icons are black squares
[19:30] <Acts10-13> nvm
[19:30] <krytarik> Phew!
[19:30] <TBotNik> All: Hello!  Hey have an apache2 problem posted out on: https://www.apachelounge.com/viewtopic.php?p=40118#40118  I'm wanting to get it fixed 2day as actually have some time 2day!  Can aqny of you help?  Right now the only vhost working is projects.com!  Localhost and all other vhosts down!
[19:32] <tomreyn> which kubuntu version are you running apache2 on?
[19:32] <TBotNik> All: Hoping someone is an Apache2 guru!  Posted out on #httpd-unregistered, but no response
[19:33] <tomreyn> did you read the /topic on #httpd-unregistered ?
[19:34] <tomreyn> i assume it contained hints on how to register your nicknem, so that you could access the #httpd main channel
[19:34] <tomreyn> *nickname
[19:35] <krytarik> Also it's set to +m.. >_>
[19:35] <tomreyn> oh
[19:36] <krytarik> But they just identified to services anyway, so could just rejoin there..
[20:09] <Acts10-13> update went fine
[20:10] <Acts10-13> I'm trying to get plasma-hud to work in Kubuntu 21.04. Has anyone got it working?
[20:10] <Acts10-13> I tried setting a custom shortcut, its running in the background, but I have had absolutely no luck making the hud come up
[20:47] <krytarik> Acts10-13: #kde might be a better place for this, since the app isn't even in the Kubuntu repos, but what does "qdbus com.github.zren.PlasmaHUD /PlasmaHUD toggleHUD" return?
[21:33] <sloth_> hello everyone, i had a quick question for anyone that can help me
[21:33] <sloth_> can you install konversation on a windows 10
[23:18] <daniel> kreft
[23:18] <Guest43328> hi
[23:30] <simsyland> have to say loving kubuntu
[23:30] <simsyland> running it on a virtual machine on my windows pc it rocks :)
[23:38] <tomreyn> Simsyland_away: you should try it the other way arounnd.
[23:39] <Simsyland_away> true tom maybe one day when i have a laptop to sare


[09:07] <abinav> /serverirc.freenode.net
[09:07] <abinav> oops
[09:07] <abinav> my bad
[09:07] <abinav> sorry
[09:09] <abinav> / serverirc.freenode.net
[09:28] <dk0r> why can't I cd here?? http://pastebin.com/d272cb609
[11:00] <nalioth> dk0r: this is a 'bring-your-own-help' channel
[11:38] <dk0r> Im new to linux (feisty), would someone please explain how to me how implement the following appdb direction: http://pastebin.com/m1809d0d2


[00:30] <jml> are we still in testfix?
[00:52] <mars> jml, looks like maybe "out and back in again" since you last signed off :(
[00:52] <jml> mars, actually not the case. see my email.
[00:52] <jml> mars, although, yes, we are back in test fix now.
[00:52] <jml> but we weren't at half-past the hour :)
[01:44] <jml> ok, now for my next trick, I need subunit in ec2test-remote.py
[01:58] <jml> mwhudson, hi
[01:58] <jml> mwhudson, why can't I import subunit in ec2test-remote.py?
[02:16] <jml> mwhudson, the answer is that ec2test-remote.py is run without any of Launchpad's non-package-based dependencies in the sys.path
[02:17] <jml> I'm not sure why _that_ is, but doubtless there is a reason.
[02:57] <kfogel> gmb: ping
[03:02] <kfogel> gmb-mobile: hey
[03:02] <kfogel> gmb-mobile: heading down to lounge to meet up w/ mrjazzcat
[03:03] <gmb-mobile> kfogel: cool. i'm in the lobby atm. assuming I'll see you on your way through :)
[03:54] <jml> I've got to run
[03:54] <jml> but if anyone is bored, test out bzr+ssh://bazaar.launchpad.net/~jml/launchpad/subunit-by-default and see if it attaches a subunit log to test result messages, and that the attached file is named after the branch being tested.
[03:54]  * jml -> off to London
[04:39] <kfogel> \o/ jml is going back to london
[04:39] <kfogel> I will get to speak to him again.
[04:46] <wgrant> Oh, wow. Automated bug closing on release.
[04:46] <wgrant> sinzui wins.
[10:02] <GabydeWilde__> hi
[10:02] <GabydeWilde__> any chance for feeds in the mailin list?
[10:31] <henninge> Is PQM really still open or is the topic lying?
[10:31] <elmo> the topic is lieing
[20:06] <wgrant> sinzui: hm, you didn't get around to landing that branch?
[20:49] <sinzui> wgrant: I think I landed it
[20:50] <sinzui> staging did not update because of a test failure that deryck fixed...then there was a merge conflict that gmb indicated he was looking into
[21:43] <wgrant> sinzui: It doesn't look merged.
[21:43] <wgrant> And it needs an RC now :/
[21:44] <sinzui> gary and flacoste can issue RCs
[21:45] <sinzui> wgrant: that was to land in db-devel right?
[21:49] <wgrant> sinzui: It is, yes.
[21:49] <sinzui> I have no running instances,
[21:50] <wgrant> Hmmmm.
[21:50] <sinzui> There will be no issues getting it approved to land.
[21:57] <sinzui> wgrant: I submitted your branch about 15 minutes before my release-love branch. I saw a success. I do not recall getting a a PQM reject notice which is what I expect to get if PQM closes
[21:59] <sinzui> I really wish I had submitted your branch instead of asking if you needed assistance
[22:01] <sinzui> wgrant: ask for an RC from gary.


[11:56] <michael_tn> good day all
[11:57] <michael_tn> i'm looking for a bit of advice about deploying openstack on an HPC cluster
[11:59] <michael_tn> the ubuntu cloud infrastructure docs seem to prefer that there be two physical networks for all nodes in the cluster, ours is a typical HPC cluster, two head nodes connected to the WAN, compute nodes on private internal networks (ethernet and IB)
[12:29] <michael_tn> quiet, will try later :-)