[12:21] <mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 1 hour
[12:42] <lifeless> vila: hi
[12:42] <lifeless> vila: two things, firstly you can only delete the line if its the last line
[12:42] <lifeless> vila: if its not the last line you break dictionary references
[12:43] <lifeless> vila: secondly, please keep NEWS in alphabetical order as per the list thread a few weeks back.
[01:21] <Peng> Yay!
[01:22] <Peng> 10 points to Launchpad for using a "503 Service Temporarily Unavailable" for the maintenance page.
[02:30] <ubotu> New bug: #141629 in bzr ""bzr reconfigure" with no arguments throws an exception" [Undecided,Fix committed]  https://launchpad.net/bugs/141629
[03:43] <mthaddon> LP going down for maintenance in 15 minutes for 1 hour
[03:44] <Peng> Am I experiencing deja vu?
[03:44] <Peng> :P
[03:44] <Peng> What's up with LP?
[03:46] <elmo> Peng: we ran into some problems during the previous maintenance  window, so it had to be rolled back.  we've resovled them and trying again to rollout the new code
[03:46] <elmo> Peng: sorry for any inconvenience
[03:51] <Peng> Ah.
[03:51] <Peng> No problem or anything. I was just curious.
[07:14] <vila> lifeless: soooo, I broke my repo dictionary reference because I didn't respect alphabetical order in NEWS... Naah, I can't believe that... Will drink another coffee first
[07:27] <vila> lifeless: ok, so, the corrupted revision is the fourth from the end, you're saying I should delete the four to recover my repo. Should I track those revisions in the repository/knits hierarchy too ?
[07:29] <vila> lifeless: About NEWS, I saw your first notice, I had read the thread but haven't realized the decision have been taken, I will comply. As soon as I can :)
[07:40] <ubotu> New bug: #141555 in bzr-svn "Breakage with invalid SSL certificates (dup-of: 82086)" [Undecided,New]  https://launchpad.net/bugs/141555
[09:08] <vila> bbib
[10:27] <kgoetz> win 20
[12:45] <vila> lifeless: no, was waiting for a confirmation, trying to reproduce it in clean env, etc
[12:46] <vila> can't reproduce it so far :-/
[01:12] <vila> lifeless: http://paste.ubuntu-nl.org/38243/   describes the corrupted revision
[01:13] <vila> all zeroes, scary
[01:13] <vila> Could your last tuned_gzip.bytes_to_gzip be related ?
[01:14] <vila> My suspects so far: hardware problem (but find nothing else to confirm this),
[01:15] <vila> NFS, the repo is on HFS+ on OSX, mounted as NFS, but the commit itself was from OSX
[01:16] <vila> your last modification to tuned_gzip.bytes_to_gzip, but only because it modifies a code that may be related, I found nothing especially suspect in your modification, I just try to enumerate possible causes
[01:17] <vila> this is mainly an annoyance because the repo holds everythin bzr related (including plugins) and it seems many commands try to read that revision even from branches that have nothing to do with it
[01:18] <vila> for safety, I think I will reorganize this whole hierachy in several repos, just because I wanted to do that for quite some time
[01:19] <vila> I lack time to hack as much as I want on this bug, but I may need to at least fix the .kndx (or several ? That's the point I want confirmation on) just to extract the right info (I still have several long lived branches in this repo)
[01:21] <vila> I've made a backup of the whole hierarchy (888MB) and of the repo itself (93MO) and also from the .bzr.log of the two machines that may be involved
[01:21] <vila> All are available for diagnosis
[01:23] <vila> I lose some time doing that because tar suddenly told me 'file change while we read it' that scared me and made me think a little bit longer that I had an hardware problem (doing two consecutive tar and comparing them with cmp yielded ~3000 differences)
[01:24] <fullermd> See what happens when you step away from the computer for a couple weeks??
[01:25] <vila> After searching for the tar format and looking at the tar sources, it appears that some long file names triggers additional blocks containing the *current* date and time (sic), so false alert, I just learned that you can't compare two tar files :-/
[01:26] <vila> fullermd: hehe, did you know about tar wart above ?
[01:27] <fullermd> Not specifically what it was, but I did know that two tars of the same source aren't necessarily equal, even if they are equivalent.
[01:29] <vila> fullermd: what a shame... apparently this is triggered by block checksums being different (so far so good), the blocks in question are special blocks preceding file header blocks for long file names
[01:29] <vila> these blocks contain a mtime field, which is useless for them so they put 0
[01:30] <vila> ... and somwhow this 0 is converted to current date... boom
[01:30] <vila> fullermd: and the 'file change while we read it' rings a bell ?
[01:31] <vila> I triggered it by asking OSX the size of the folder I was tar'ing, silly me, lost a couple more minutes for that :-/
[01:33] <vila> the hard part was confirming that, indeed, OLDGNU_FORMAT (described in tar.h as 'obsolete RSN') was still the current format on OSX (and surely elsewhere) and that, yes, it includes an 'atime' field
[01:33] <vila> Never figured tar knew about that....
[01:42] <vila> lifeless: http://paste.ubuntu-nl.org/38244/ contains the .kndx files identified, thanks for confirming that deleting the lines (last of each file) will fix my repo (to the best of your knowledge :)
[01:44] <vila> lifeless: I'm ready to loose the two branches involved, osx.pass.test.suite and bzr.integration
[02:32] <tuXXX> When I bzr push on a sftp, files and directory aren't created, only .bzr, it this the correct behaviour?
[02:32] <Peng> tuXXX: Yes.
[02:33] <Peng> tuXXX: .bzr is all that's necessary to run bzr branch on it.
[02:33] <tuXXX> Then I need a web front-end to display those files on my web server
[02:33] <Peng> tuXXX: You can run "bzr checkout", then run "bzr update" in a cronjob or something.
[02:34] <Peng> tuXXX: Or using bzr+ssh might do it, I dunno.
[02:34] <Peng> tuXXX: Loggerhead is an advanced web front-end. I dunno about anything simple. There's bzr-webserve, but I'm not sure if it's maintained.
[02:35] <tuXXX> sftp is useful because it doesn't need bzr to be installed on the server
[02:35] <Peng> Yeah.
[02:39] <GaryvdM> tuXXX - There is a plugin that does that. I'm just going to find it...
[02:41] <GaryvdM> There is https://launchpad.net/bzr-push-and-update/
[02:42] <tuXXX> ok
[02:43] <tuXXX> bzr still needs to be installed server-side
[02:43] <GaryvdM> Yhea :-(
[03:04] <tuXXX> ok so I have to do a "bzr checkout ." on the server
[03:04] <tuXXX> and it's work
[03:04] <tuXXX> *and it works
[03:26] <lapthrick> hrmm
[03:26] <lapthrick> so Gutsy's bzr can't cope with https://
[03:28] <vila> lapthrick: what do you mean ?
[03:28] <lapthrick> vila: https://bugs.launchpad.net/bzr/+bug/141105
[03:28] <ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [Undecided,New]
[03:29] <lapthrick> first I thought it was bzr-svn that was failing, but it turns out to die for plain bzr https:// uris as well
[03:29] <vila> how so ? Can you try with https+urllib:// too ?
[03:30] <lapthrick> sure
[03:30] <AnMaster> gutsy? what is that
[03:30] <lapthrick> newest ubuntu, not released yet
[03:30] <AnMaster> ah
[03:31] <AnMaster> <-- Gentoo user
[03:31] <AnMaster> and FreeBSD
[03:31] <lapthrick> vila: works with urllib, yeah
[03:32] <lapthrick> I actually suspected it might be libcurl-gnutls's fault
[03:33] <vila> I should definitely look at that new version, that error code 77 may indicate some API break somewhere
[03:33] <lapthrick> ah, of course, you commented on that bug :)
[03:34] <vila> lapthrick: you're using a stock gutsy is it ?
[03:34] <lapthrick> aye
[03:34] <vila> lapthrick: yeah, didn't recognize you as mathrick either :)
[03:34] <lapthrick> :)
[03:35] <lapthrick> I need to setup an irc proxy
[03:36] <vila> lapthrick: if urllib is fine with you, keep using it, be aware that it makes *no* certificate verification though, track bug #82086 if you want to be kept informed on progress
[03:36] <ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]  https://launchpad.net/bugs/82086
[03:38] <lapthrick> vila: I see. That's strange though, as the original svn repo from that bug I have authenticated permanently with plain svn client
[03:40] <vila> nothing strange in that :) svn should do proper certificate verification :)
[03:40] <lapthrick> given the exceedingly brief help it has
[03:40] <james_w> lapthrick: I think if you use svn+https:// for bzr-svn on that repo you will havee more success.
[03:40] <lapthrick> vila: but isn't it supposed to re-use svn cache?
[03:40] <lapthrick> james_w: yes, I needed a newer bzr-svn though
[03:40] <lapthrick> I just got it, lesse if it works now
[03:41] <vila> lapthrick: 1) I don't know what bzr-svn does, 2) we are not talking about credentials, we are talking about certificates
[03:42] <vila> the server send a client saying: That's who I am (my certificate), this certificate have been validated by vendor$$$
[03:42] <lapthrick> vila: yes, using svn client I accepted that certificate permanently
[03:42] <vila> Ok, so it means bzr-svn doesn't use that
[03:43] <james_w> I think jelmer says that bzr-svn works fine, it is just that bzr is probing for a bzr branch first, and so fails, adding svn+ bypasses this and goes straight to using the svn client, and so uses the stored information.
[03:44] <lapthrick> ah
[03:44] <lapthrick> james_w: that makes sense
[03:44] <vila> ah
[03:44] <lapthrick> mathrick@hatsumi:/tmp$ bzr cl svn+https://beta.aimido.de/svn/src2/trunk
[03:44] <lapthrick> Segmentation fault (core dumped)
[03:44] <lapthrick> :(
[03:45] <lapthrick> it fetches the revisions info properly
[03:45] <lapthrick> then dies
[03:45] <lapthrick> cl == checkout --lightweight
[03:45] <james_w> lapthrick: you should report that against bzr-svn, jelmer will want to know.
[03:45] <james_w> a backtrace might be appreciated.
[03:46] <lapthrick> mhm, if I can get a sensible trace
[03:47] <james_w> I believe there are python debug packages, and maybe libsvn ones as well.
[03:47] <lapthrick> yeah, I'll just check if it happens with branch as well
[03:59] <lapthrick> seems to work just fine with branch
[04:10] <lapthrick> hmm, isn't bzr status in an svn checkout supposed to work?
[04:10] <lapthrick> it doesn't for me
[04:11] <james_w> yeah it should I think.
[04:11] <lapthrick> oh wait, wrong dir
[04:11] <lapthrick> I forgot trunk/
[04:12] <abentley> If you're getting a segfault, you should try running it under gdb.  That's a bug on the C side.
[04:12] <lapthrick> abentley: I know :)
[04:28] <lapthrick> h, what was the command to see the difference between branches?
[04:30] <dato> in terms of revisions, `bzr missing`
[04:30] <dato> (for diff, obviously `bzr diff`)
[04:33] <lapthrick> yeah, I just saw missing
[04:33] <lapthrick> thanks though
[04:47] <lapthrick> hey jelmer_
[04:48] <jelmer_> hi lapthrick
[04:50] <lapthrick> jelmer_: seen my latest bugreport?
[04:51] <lapthrick> I don't seem to be able to get a sensible trace, btw
[04:51] <jelmer_> yep
[04:51] <lapthrick> is python-dbg `which bzr` ... the correct way to get a backtrace from bzr?
[04:52] <jelmer_> `bzr co --lightweight`is just an alias for 'svn co ...' btw
[04:52] <lapthrick> jelmer_: oh
[04:53] <lapthrick> mathrick@hatsumi:/tmp$ svn co svn+https://beta.aimido.de/svn/src2/trunk
[04:53] <lapthrick> svn: Undefined tunnel scheme 'https'
[04:53] <jelmer_> without the svn+ :-)
[04:53] <jelmer_> ah, that's the problem
[04:54] <lapthrick> jelmer_: hmm? So the svn client underneath dies and it crashes because of that?
[04:54] <GaryvdM> bzr gdiff
[04:54] <GaryvdM> err wrong window
[04:54] <jelmer_> lapthrick: Yes, that's what I suspect
[04:54] <jelmer_> GaryvdM: :-)
[04:54] <lapthrick> it's noticeably faster
[04:55] <GaryvdM> lapthrick: I gave up trying to set it up on windows
[04:55] <jelmer_> lapthrick, can you try running that checkout command in gdb?
[04:55] <lapthrick> jelmer_: and bzr-svn is , especially now I got it to check out my work repo
[04:55] <lapthrick> jelmer_: I guess so
[04:57] <lapthrick> jelmer_: ah, yes, that's much more sensible
[04:57] <lapthrick> 0x080a215c in PyString_FromFormatV (
[04:57] <lapthrick>     format=0x816de98 "'%.50s' object has no attribute '%.400s'",
[04:57] <lapthrick>     vargs=0xbfb19f38 "\001") at ../Objects/stringobject.c:202
[04:57] <lapthrick> 202     ../Objects/stringobject.c: No such file or directory.
[04:57] <lapthrick>         in ../Objects/stringobject.c
[04:59] <lapthrick> jelmer_: http://pastebin.com/m33018646
[05:00] <jelmer_> thanks
[05:01] <jelmer_> looks like another python-subversion bug
[05:01] <lapthrick> I see
[05:01] <lapthrick> jelmer_: why is there a difference between what schemes svn and bzr-svn handle anyway?
[05:03] <jelmer_> lapthrick: bzr-svn supports everything that svn supports
[05:03] <jelmer_> lapthrick: and it also supports 'svn+https' to work around that problem with SSL certificates
[05:03] <lapthrick> jelmer_: yeah, but it was bailing out with the same error earlier, before I upgraded to 0.4.3
[05:04] <Qhestion> hi. can i put my bzr installation (from the windows installer) on my usb stick?
[05:04] <lapthrick> and isn't svn supposed to understand svn+https://? It's not uncommon to see urls like that on the net
[05:04] <jelmer_> lapthrick: it supports svn+ssh://, svn://, http:// and https://
[05:05] <jelmer_> lapthrick: which error did it bail out with earlier as well?
[05:05] <jelmer_> Qhestion: you mean the files that it installed or the setup file?
[05:05] <lapthrick> "Undefined tunnel scheme 'https'"
[05:06] <Qhestion> the files it installed
[05:06] <Qhestion> i just dont want to run the installer on the target machine
[05:06] <Qhestion> (read: can't)
[05:07] <jelmer_> Qhestion: should work ok as long as all the dependencies are installed
[05:07] <Qhestion> dependencies?
[05:07] <GaryvdM> Qhestion: I've never tried it, but I can't see why not.
[05:07] <jelmer_> Qhestion: python, paramiko if you would like to use sftp, etc
[05:07] <Qhestion> this is the "standalone installer"
[05:07] <Qhestion> there shouldnt be dependencies
[05:08] <Qhestion> and no sftp needed, only local (usb stick) repos
[05:08] <jelmer_> Qhestion, not sure in that case, I don't know where that installs its python binary
[05:08] <GaryvdM> Most of the dependencies are built into the installer, except the ssh stuff
[05:08] <Qhestion> well, in C:\Programs\Bazaar there is a Python25.dll
[05:08] <Qhestion> guess that is python ;)
[05:08] <jelmer_> lapthrick: bzr-svn has to strip the svn+ bit for svn+http and svn+https before it passes urls to the svn libraries
[05:09] <jelmer_> there was a bug where that wasn't happening in bzr-svn 0.4.1 I believe
[05:09] <lapthrick> ah
[05:09] <lapthrick> jelmer_: I thought svn+whatever was a general syntax
[05:09] <GaryvdM> Qhestion: I'm sure it will work - give it a go
[05:10] <Qhestion> i only have one try
[05:10] <Qhestion> ;)
[05:11] <lapthrick> Qhestion: can't you ask a random friend if you can test if it works?
[05:11] <lapthrick> most probably they won't have bzr installed, so it's a good way to find out
[05:12] <Qhestion> lapthrick: all my friends already got python ;)
[05:12] <Qhestion> and bzr
[05:12] <Qhestion> ya know, i need some people to test my software ;)
[05:13] <Qhestion> i stopped programming in python, but i use Bazaar as version control system, and also to publish my sources
[05:13] <Qhestion> hmm, i remember i should go back to the bazaar bugtracker
[05:13] <Qhestion> filed a feature request there
[05:13] <GaryvdM> Qhestion: I can do a test on my sisters machine when she gets home - probably in about 15 min.
[05:13] <Qhestion> k
[05:14] <Qhestion> thank you
[05:14] <Qhestion> shall i send you a zip ?
[05:14] <GaryvdM> ok
[05:14] <GaryvdM><EMAIL_ADDRESS>[05:16] <Qhestion> woo 11 MB
[05:16] <Qhestion> this will ake a bit
[05:16] <jelmer_> lapthrick: you can add custom tunnel mechanisms to svn for the native svn protocol
[05:16] <jelmer_> the http protocol is different though
[05:16] <jelmer_> lapthrick, Thanks for the backtrace, I have to head out now, will have a look at it later today.
[05:16] <GaryvdM> don't worry - I'll download the installer
[05:16] <Qhestion> ok
[05:44] <GaryvdM> Qhestion: It works
[05:45] <GaryvdM> And my sister dose not have admin rights on her machine
[05:45] <GaryvdM> s/dose/does
[05:46] <Qhestion> Garyvd: thank you
[05:47] <Qhestion> Garyvd: she does not have admin on her own machine? lol. good job ;)
[05:48] <GaryvdM> It's a work machine from a big corporate...
[05:48] <Qhestion> oh
[05:50] <schierbeck> phanatic: hey
[05:50] <phanatic> schierbeck: hi :)
[05:50] <schierbeck> phanatic: i was thinking
[05:51] <schierbeck> do you really need a date column in the viz treeview?
[05:51] <schierbeck> it happens quite often with big projects that the window becomes too wide
[05:52] <phanatic> good question, it's nice to see the date right away, not just in the details. but it often runs off the screen because of the graph being too wide
[05:53] <schierbeck> phanatic: but i'd rather have a nice, easy-to-comprehend graph than a timestamp...
[05:54] <schierbeck> i mean, it's not often you actually *need* to know the exact time of a commit, or do you?
[05:54] <schierbeck> it may just be me...
[05:54] <phanatic> yeah, you're probably right
[05:55] <schierbeck> i think i'll create a branch and toy around with it
[05:55] <GaryvdM> schierbeck, phanatic: I've hacked up a possible solution to reduce the with of the graph. I was just emailing phanatic about it.
[05:55] <GaryvdM> s/with/width
[05:55] <phanatic> actually i was thinking about redesigning the full thing. e.g. display only the graphs, and the details only when you move your mouse on a node. what do you think?
[05:56] <GaryvdM> https://code.launchpad.net/~garyvdm/bzr-gtk/brokenlines
[05:56] <schierbeck> GaryvdM: cool, as long as the graph is still easy to read
[05:56] <schierbeck> phanatic: i like the commit message being there, and sometimes the author
[05:56] <schierbeck> but there's no need for both the author name and email
[05:57] <GaryvdM> Thats a good point...
[05:57] <phanatic> indeed
[06:03] <schierbeck> GaryvdM: i'm not sure about the new graphs, i took a look, and it's a bit curvy (?)
[06:03] <schierbeck> of course, i'm no authority on the subject
[06:03] <phanatic> GaryvdM: this brokenlines stuff is pretty interesing
[06:03] <phanatic> schierbeck: imho they look better this way
[06:05] <schierbeck> phanatic: okay, it seems i'm outnumbered in my favor of straightness :P
[06:05] <phanatic> :D
[06:05] <schierbeck> i really like the way broken lines are handled
[06:05] <schierbeck> in the new branch, that is
[06:06] <phanatic> yep, me too
[06:06] <phanatic> does it load faster as well, or it's just me who feels it? :)
[06:08] <GaryvdM> I hope so :-)
[06:09] <GaryvdM> I should only be loading the revision data after the first screen is shown
[06:10] <GaryvdM> I'm hoping I can get it to only load the revision data for a rivision when it is scrolled into view.
[06:11] <GaryvdM> s/I/It
[06:11] <phanatic> 2.625s on bzr.dev, that's quite impressive
[06:11] <schierbeck> GaryvdM: do you think you could get the merge and branch-off lines to join at a different angle?
[06:12] <GaryvdM> Yes - play with the curve controll points
[06:13] <schierbeck> phanatic: i've made a version of viz without the date column, have a look: https://code.launchpad.net/~dasch/bzr-gtk/viz-remove-timestamp-column
[06:13] <schierbeck> GaryvdM: ok, i'll look into it
[06:13] <phanatic> huh, with current bzr-gtk trunk it takes 25.085s
[06:13] <GaryvdM> viv/graphcell.py line 181-187
[06:13] <phanatic> oops, 15.085s that is :)
[06:13] <phanatic> but still 7 times more than with brokenlines
[06:16] <ubotu> New bug: #144071 in bzr "dirstate-tags format is expensive for network operations?" [Undecided,New]  https://launchpad.net/bugs/144071
[06:16] <phanatic> schierbeck: thanks, i will :)
[06:16] <schierbeck> phanatic: i'm also looking into cutting off the email portion of the committer id
[06:16] <phanatic> great
[06:17] <phanatic> GaryvdM: what do you think: is brokenlines stable enough to get in into 0.91?
[06:18] <GaryvdM> I don't know - I would love to have testing done on it.
[06:18] <GaryvdM> Lots of new code.
[06:19] <GaryvdM> s/more testing
[06:20] <phanatic> fine, i won't merge it then before the release :)
[06:20] <GaryvdM> Yhea - lets merge it just after the release.
[06:21] <schierbeck> phanatic: the new version should have been pushed to lp now, got a little ahead of myself before
[06:21] <schierbeck> i also tried making the graph column non-resizable
[06:21] <schierbeck> i think it is actually better -- when do you *not* want to see the branch graph?
[06:24] <phanatic> schierbeck: if it gets too wide, maybe?
[06:25] <schierbeck> phanatic: perhaps, but i think the graph is the main feature of the viz -- without it, it's really hard to navigate
[06:25] <phanatic> yes, you're right
[06:25] <schierbeck> i think it's better to make sure the graph will almost never be too wide
[06:25] <schierbeck> :)
[06:26] <phanatic> that's where brokenlines comes into the scene ;)
[06:31] <schierbeck> phanatic: i've pushed the changes to lp; the email part is now hidden in the treeview
[06:32] <schierbeck> my implementation is not perfect; i guess the separation of name and email should go in bzrlib, not in bzr-gtk
[06:33] <phanatic> i get a traceback here
[06:33] <phanatic> Traceback (most recent call last):
[06:33] <phanatic>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/viz/branchwin.py", line 190, in populate_model
[06:33] <phanatic>     committer = revision.committer.split('<')[0] .strip()
[06:33] <phanatic> AttributeError: 'NoneType' object has no attribute 'split'
[06:35] <phanatic> (i ran bzr viz on bzr.dev tree)
[06:38] <schierbeck> phanatic: ok, committer can apparently be None...
[06:39] <phanatic> yeah, it seems :/
[06:40] <schierbeck> heh, there was a check for revision.committer is None one line above... doh!
[06:40] <lapthrick> so, I have one branch A (which is mine), and now I want to incorporate another branch B (upstream, not mine) as a part of A, but in a way that would still let me merge further changes in A
[06:41] <lapthrick> is that possible?
[06:41] <lapthrick> both branches are created by bzr-svn btw
[06:41] <lapthrick> *further changes in B
[06:42] <schierbeck> phanatic: pushed a fix
[06:42] <phanatic> wow, lp syncs pretty fast finally
[06:43] <schierbeck> yup
[06:44] <phanatic> schierbeck: looks fine to me :)
[06:44] <schierbeck> phanatic: can it get merged into trunk, or is it too big a change of the ui?
[06:45] <phanatic> i think it's sane change. and we don't have things like ui freeze :)
[06:46] <schierbeck> lovely :)
[06:46] <phanatic> schierbeck: you know the drill: add a NEWS entry, and i'll be all happy :P
[06:46] <schierbeck> great
[06:49] <Odd_Bloke> lapthrick: Are you asking if you can incorporate branch B into branch A but later be able to merge further changes from B into A?
[06:49] <Odd_Bloke> lapthrick: If so, is branch A related to branch B at all?
[06:49] <schierbeck> phanatic: added NEWS entry and pushed to lp
[06:50] <lapthrick> Odd_Bloke: no, not at all related. I want to incorporate it as in I want all the files from B in A (in a subdirectory, too)
[06:52] <GaryvdM> Do you want the rivision history from B in A?
[06:53] <GaryvdM> If not, you can just use a nested directory
[06:55] <GaryvdM> If yes - I think you need to use graft?
[06:55] <lapthrick> GaryvdM: no, I don't really need the history of B past the point it got imported into A
[06:55] <GaryvdM> http://spacepants.org/src/bzrgraft/
[06:56] <lapthrick> GaryvdM: so I just copy it and that's all? What happens if at one point I decide to move a file outside B? Also, will A see B as a part of it (as in, I will commit and it will notice all those files that appeared)?
[06:57] <GaryvdM> Are you talking about a nested branch?
[06:57] <lapthrick> I think graft is not compatible with recent bzr's
[06:57] <lapthrick> GaryvdM: I guess I am
[06:58] <lapthrick> if I use a nested branch, will the branches understand their mutual relationship?
[06:58] <GaryvdM> For a nested branch - you have two seperate branches with seperate rivision histories, but one is inside the other on the file system
[06:59] <GaryvdM> Once you have imported B into A, will you need to merge changes from B's trunk into B
[07:02] <lapthrick> GaryvdM: but I need them integrated. Basically I have a big repo A, and I have some outside vendor's source B I want to import. So I want A to contain all the files from B, but I want them also to retain their identity, so that when the vendor commits changes to their repo, I can just pull them and it'd do the right thing
[07:03] <lapthrick> yet I also need to be able to manipulate the imported files myself, as the B sources are not usable for me pristine
[07:06] <GaryvdM> I think a nested branches would be the best solution, but not perfect. Lets say you make a change to A and a change to B that go together, you would have commit seperatly to A and B.
[07:07] <GaryvdM> But it would be easy to merge you changes to B with the vendors changes.
[07:08] <lapthrick> GaryvdM: okay, so when someone branches off A, will they also get a copy of B?
[07:08] <GaryvdM> no
[07:09] <lapthrick> so that's not really a solution for me, I need A to actually have all of B in it
[07:17] <lapthrick> so basically I need 'bzr steal' functionality
[07:18] <lapthrick> GaryvdM_: how hard would it be to add such 'bzr steal' function?
[07:19] <lapthrick> hmm, I wonder if multiparent does anything of what I want
[07:20] <GaryvdM> lapthrick: I don't know - I have only been hacking on bzr-gtk for about a month.
[07:21] <lapthrick> I see
[07:21] <schierbeck> GaryvdM: do you think revision id deserves its own column in the viz window? i tend to prefer a tooltip instead
[07:22] <GaryvdM> No - it's very long
[07:22] <lapthrick> https://launchpad.net/bzr-merge-into/
[07:22] <lapthrick> oho!
[07:22] <GaryvdM> I supect that you are talking about the revision number column though
[07:23] <schierbeck> GaryvdM: sorry, i meant revision number
[07:24] <GaryvdM> Well  - Someone loged it as a feature request: https://bugs.launchpad.net/bzr-gtk/+bug/64167
[07:24] <ubotu> Launchpad bug 64167 in bzr-gtk "bzr viz don't show revno for main revisions" [Wishlist,Fix committed]
[07:25] <schierbeck> hmm, it says "fix committed" -- where's the fix?
[07:25] <schierbeck> (using trunk)
[07:25] <GaryvdM> Viz is being used for 2 things - a GUI for Log - and a graph renderer
[07:26] <GaryvdM> I't commited to https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges, but not to trunk yet
[07:26] <schierbeck> GaryvdM: ok
[07:26] <schierbeck> as a column or a tooltip?
[07:27] <GaryvdM> May be we need a interface to select what columns the user wants
[07:27] <phanatic> GaryvdM: btw we assume that "Fix committed" means it was committed to trunk (just a sidenote)
[07:27] <GaryvdM> Oh
[07:28] <GaryvdM> Changed
[07:32] <abadger1999> abentley: around?
[07:55] <lapthrick> does John Arbash Meinel IRC? And if so, what nick does he use?
[07:56] <phanatic> lapthrick: jam
[07:57] <lapthrick> doesn't really seem to be here
[07:57] <phanatic> lapthrick: 1. it's weekend 2. he's on us time
[07:57] <lapthrick> true
[08:32] <james_w> 3. he's got a new son.
[08:32] <james_w> lapthrick: I can't spot your question, would you mind repeating it?
[08:33] <lapthrick> james_w: yes, I basically want to do what merge-into provides: merge in outside code into my own branch, whilst still retaining the ability to pull in later changes in upstream
[08:34] <lapthrick> at least if I understand merge-into's scope correctly it's supposed to do that
[08:35] <james_w> and merge-into isn't what you want?
[08:35] <lapthrick> james_w: it is, but doesn't work
[08:36] <lapthrick> https://bugs.launchpad.net/bzr-merge-into/+bug/144108
[08:36] <lapthrick> just finished writing
[08:36] <ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New]
[08:37] <lapthrick> if I can get this fixed, I no longer will have to put up with stupid subversion crap
[08:38] <james_w> lapthrick: thanks, caught up now.
[08:39] <james_w> so, I believe merge into is now superceded by by-value nested trees, so I think that should solve your problem.
[08:39] <james_w> however I don't really know how they work, and they are still experimental.
[08:40] <james_w> and by-reference nested trees are currently completely broken, so maybe by-value are too.
[08:41] <lapthrick> ouch, I don't really understand what you just said
[08:41] <james_w> do you understand nested trees?
[08:42] <james_w> as in you have one tree (branch) tracked as part of another.
[08:44] <lapthrick> james_w: yes, the concept is pretty clear and incidentally exactly what I want (as long as I am still able to move parts of the inner tree to the outside one)
[08:45] <james_w> yeah, it sounds like you want a by-value nested tree.
[08:45] <lapthrick> what's the difference?
[08:45] <james_w> by-value means that the contents are tracked, by-reference means that just a pointer is tracked.
[08:45] <lapthrick> I see
[08:45] <lapthrick> so yeah, by-value
[08:46] <james_w> by-value is just breaking up a branch so that you can branch from a sub-directory of it.
[08:46] <ubotu> New bug: #144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New]  https://launchpad.net/bugs/144108
[08:46] <james_w> but also allows you to merge as you want I hope.
[08:46] <james_w> merge-into was jam's plugin to do by-value before nested trees were started.
[08:47] <lapthrick> james_w: excellent, bzr + bzr-svn == all bzr , no stupid svn
[08:47] <lapthrick> as long as it works, that is :)
[08:48] <james_w> yeah, you shouldn't have to touch svn
[08:51] <james_w> lapthrick: I have an idea for fixing merge-into, wnat to try it?
[08:52] <james_w> edit merge_into.py, and on the line (near the end) before conflicts = merger.do_merge() insert merger.find_base()
[08:52] <lapthrick> james_w: sure
[08:53] <james_w> that should set the missing attribute, but whether it will work is another question.
[08:53] <lapthrick> okay, lemme try
[08:55] <lapthrick> "Branches have no common ancestor, and no merge base revision was specified."
[08:56] <lapthrick> james_w: success was not full it seems
[08:56] <james_w> indeed.
[08:57] <james_w> perhaps try in __init__ just set self.base_is_other_ancestor = False and remove the other change.
[08:57] <james_w> I'm not sure what the effect will be, but it sounds like that will never be true in this case.
[08:57] <lapthrick> yeah
[08:59] <james_w> or I have another suggestion.
[09:00] <james_w> where you put find_base before put set_base_revision
[09:02] <james_w> merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
[09:02] <james_w> you will need to do from bzrlib import revision before
[09:03] <james_w> after that I'm a bit stuck for ideas.
[09:26] <lapthrick> james_w: okay, lemme try that
[09:26] <lapthrick> james_w: are those two separate ideas, or a single change?
[09:27] <james_w> two separate, I would try the second one first, it seems like less of a hacky change.
[09:27] <james_w> even if it is unlikely to work/
 merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
[09:27] <lapthrick> this one, set in place where I previously did find_base?
[09:27] <james_w> yes.
[09:28] <james_w> adding the import statment just above.
[09:28] <lapthrick> should I also add find_base call?
[09:28] <james_w> or add revision to the list of imports at the top.
[09:28] <james_w> no, the find base is the wrong one, it should be deleted, as I see it will never work here.
[09:28] <lapthrick> okay
[09:33] <lapthrick> james_w: awesome, that worked
[09:33] <lapthrick> I will post a patch for that bug then
[09:33] <james_w> wow.
[09:33] <james_w> did you try it on your branches as well?
[09:33] <lapthrick> james_w: yes, bzr missing --other ../other shows nothing
[09:34] <lapthrick> which is exactly what I expected :)
[09:34] <james_w> horsesome.
[09:34] <lapthrick> I'm gonna try pulling some changes from upstream now
[09:36] <lapthrick> hmm
[09:36] <lapthrick> james_w: http://pastebin.com/m1a097d9d
[09:38] <james_w> lapthrick: so is that file named foo.html or pokersource/foo.html in ../../pokersource?
[09:39] <lapthrick> james_w: foo.html, if I wanted to access it, I'd say ../../pokersource/foo.html
[09:40] <james_w> and when you did the merge-into you made it put the contents of the ../../pokersource branch in pokersource/ ?
[09:41] <lapthrick> james_w: yes
[09:41] <james_w> that's a good sign I think then.
[09:41] <lapthrick> how so?
[09:41] <james_w> it knows how to resolve that file in to the subdir.
[09:41] <lapthrick> do you mean it can be fixed, or that it's not broken?
[09:42] <james_w> so I think a path conflict comes when you add a file of the same name in two branches independently
[09:42] <james_w> which would suggest that the merge-into messed up the file-ids.
[09:43] <james_w> but the fact that it knows that ../.../foo.html corresponds to pokersource/foo.html means that it got something right.
[09:43] <lapthrick> ah
[09:43] <james_w> lapthrick: it's definately broken, I was just commenting that it seemed to be at least partially right.
[09:43] <lapthrick> james_w: can I get it to tell me file-ids?
[09:43] <james_w> It may be fixable.
[09:44] <james_w> lapthrick: I'm not sure about command line. I can do it with bzrlib easily if you want to.
[09:44] <james_w> python
[09:44] <james_w> >>> import bzrlib
[09:44] <james_w> >>> from bzrlib.workingtree import WorkingTree
[09:44] <james_w> >>> t = WorkingTree.open_containing('.')
[09:45] <james_w> >>> t.path2id(path)
[09:45] <james_w> however I'm not sure which id you will get it the conflicting case.
[09:46] <james_w> if you revert, and then check pokersource/foo.html in this branch, and then foo.html in the other they should be the same.
[09:46] <lapthrick> >>> t.path2id("pokersource/foo.html")
[09:46] <lapthrick> Traceback (most recent call last):
[09:46] <lapthrick>   File "<stdin>", line 1, in <module>
[09:46] <lapthrick> AttributeError: 'tuple' object has no attribute 'path2id'
[09:46] <james_w> t = t[0]
[09:46] <james_w> I always forget that one.
[09:47] <lapthrick> james_w: and how do I retrieve the id now? It didn't return any value
[09:47] <james_w> I'm also not sure whether it's the fact that you are doing a delete that is causing the issue.
[09:47] <james_w> >>> t.path2id should work now.
[09:47] <lapthrick> yes, but it doesn't return anything
[09:47] <lapthrick> well, returns None
[09:48] <james_w> that means the file is not versioned.
[09:48] <james_w> did you revert first?
[09:48] <lapthrick> no
[09:48] <james_w> try the reverted case first, and also uncommit + revert in the other branch to test that one.
[09:49] <james_w> let's check that it thinks the two files are the same first, then work out what causes the conflict.
[09:50] <lapthrick> >>> t.path2id("pokersource/foo.html")
[09:50] <lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
[09:50] <lapthrick> >>> t.path2id("foo.html")
[09:50] <lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
[09:50] <lapthrick> so they got the same ID
[09:52] <james_w> that's good. bzr will equate the two.
[09:52] <lapthrick> james_w: indeed, non-rm change works just fine
[09:52] <james_w> you may get the conflict as you are doing a delete. Can you instead try an edit in the upstream branch and then merge that.
[09:53] <james_w> ah, that's good then.
[09:53] <lapthrick> yeah, I just did :)
[09:53] <james_w> I wonder where that conflict comes from then.
[09:53] <james_w> you could look at the conflicts documentation.
[09:53] <lapthrick> what do you mean?
[09:55] <james_w> http://pastebin.com/d4818a9e7
[09:55] <james_w> there is a conflicts section of the user guide.
[09:56] <james_w> I guess this is the parent directory case.
[09:57] <james_w> so bzr sees 'rm foo' in one branch and 'mv foo ...' in the other and doesn't know who to listen to.
[09:58] <james_w> lapthrick: it appears to be working, so you could resolve the conflicts as a workaround, and then ask on Monday for any ideas for a fix.
[09:58] <lapthrick> james_w: hmm, but why does it see mv?
[09:59] <lapthrick> james_w: yep, it's already much much awesomely better than trying to do the same with subversion :)
[09:59] <lapthrick> I love how bzr is the best available svn client
[09:59] <james_w> well, one tree has / as the parent, the other has /pokersource/ and so it considers it a move I guess.
[10:00] <lapthrick> james_w: oh, I see. So we need to muck the path in there to make it see pokersource/ as the parent where needed
[10:00] <lapthrick> as / I mean
[10:01] <james_w> bzr doesn't actually record moves, it just preserves file ids, and then sees name and parent directory changes as moves later I believe.
[10:01] <lapthrick> james_w: in any case, huge thanks for the help
[10:01] <james_w> lapthrick: no problem. This fix is probably a bit in depth for me.
[10:02] <lapthrick> maybe jam will come around on monday
[10:02] <lapthrick> right now I have it working, I don't need to pull in any actual change yet, so it's really not a big issue
[10:02] <james_w> that would be one fix, but I'm not sure that you could enforce that without massive changes (aka nested trees I guess).
[10:02] <lapthrick> yeah
[10:02] <james_w> and the conflicts should be easy to solve, and perhaps rare.
[10:03] <lapthrick> otherwise it'd try to move to /.., and that just doesn't make sense
[10:03] <james_w> I guess the nested tree support there is may provide a way to fix this.
[10:03] <lapthrick> yeah, I'm more than happy to move to that once it's not broken
[10:03] <james_w> I guess jam maybe knew this was a limitation, but it was 'good enough'.
[10:04] <james_w> it needs someone to pick it up, and most of the core devs are on performance at the moment.
[10:04] <james_w> lapthrick: could you mail a bundle to the bug report with your fix please?
[10:06] <james_w> I'm off out now, so I can't commit it tonight, but if it's in my inbox it will remind me to do it tomorrow.
[10:06] <lapthrick> james_w: sure
[10:06] <james_w> thanks.


[00:20] <dragon> In #ubuntu, _BLACK_MAN_ is looking for attention.
[00:21] <dragon> thanks bazhang
[00:21] <bazhang> in PM now
[00:50] <bazhang> linera seems to be having trouble understanding basics
[01:15] <bazhang> linera seems to be trolling; anyone else seeing this?
[01:16] <MenZa> bazhang: looks like trolling to me
[01:16] <MenZa> [2009-12-19 01:15:10 UTC] < Linera> i need dxdiag to see it
[01:16] <MenZa> that got me convinced ^
[01:16] <bazhang> MenZa, oh hai
[01:16] <MenZa> o hai bazhang
[01:16] <bazhang> yep, and two suggestions have morphed into 10,000
[01:16] <bazhang> MenZa, UBUNTU MEMBER!!!!
[01:17] <MenZa> indeed!
[01:17] <bazhang> :)
[01:17] <MenZa> 'tis a nice feeling.
[01:17] <bazhang> hehe
[01:17] <nhandler> You deserved it MenZa :)
[01:17] <MenZa> Thanks, nhandler :)
[01:17] <bazhang> very true :)
[01:17]  * MenZa bows deeply.
[01:19] <MenZa> My @ubuntu.com e-mail still isn't functioning.
[01:19] <MenZa> :\
[01:19] <bazhang> hah
[01:22] <nhandler> MenZa: How long has it been? The script runs every 2 days: https://wiki.ubuntu.com/UbuntuEmail
[01:22] <MenZa> Aye, it's been since Tuesday
[01:22] <MenZa> I confirmed with ninnnu who was accepted at the same meeting, and she's experiencing the same
[01:22] <MenZa> so I sent off an e-mail to rt@ubuntu
[01:23] <nhandler> :)
[01:23] <MenZa> Oh, nhandler -- yesterday, yes, I was referring to the ubuntu-irc thread
[01:25] <bazhang> going out for a bit, linera seems to have quieted down
[01:38] <MenZa> I'm confused as to Linera's intentions.
[01:39] <MenZa> Trolling? Are they just clueless?
[01:40] <niko> any ops around ?
[01:41] <MenZa> Anyone?
[01:45] <bazhang> yikes
[01:45] <MenZa> bazhang: Hold it for a second.
[01:45] <bazhang> MenZa, ok
[01:45] <MenZa> bazhang: I've been watching it, and it seems like they /may/ make some sort of progress.
[01:45] <MenZa> Or perhaps they were just intimidated by all the ops calls.
[01:45] <bazhang> MenZa, apparently its been going on for hours
[01:46] <MenZa> bazhang: yeah, I'll keep watching
[01:46] <bazhang> okay, really going away now :)
[01:46] <MenZa> :<
[01:46] <MenZa> I have no access! :P
[01:46] <bazhang> I can mute her/him and have a chat
[01:47] <bazhang> the channel seems to be asking for his/her removal quite explicitly
[01:47] <MenZa> I'll just query switch
[01:47] <MenZa> No, no that's alright
[01:47] <MenZa> If it goes out of control, I'll call staff
[01:47] <bazhang> okay
[01:47] <niko> feel free to ask here
[01:47] <niko> if there is no ops
[01:48] <bazhang> he/she is just not listening.
[01:48] <MenZa> niko: gotcha
[01:48] <bazhang> same circle of I have ubuntu installed after repeated explanations
[01:49] <MenZa> \o enjoy, bazhang
[01:49] <bazhang> :0
[01:49] <MenZa> niko: If you're around, I'll poke you instead of calling everyone in here ;)
[01:50] <niko> i prefer you ask ops first :)
[01:50] <Pici> Its certainly not helping that 5 people are giving varying directions at the same time.
[01:51] <MenZa> Pici: I think people have gotten over-eager, and that last comment ("There is no terminal") is making me think this is just a very successful troll.
[01:51] <bazhang> its not varying directions. he/she was told to try something lighter.
[01:53]  * MenZa considers something like !confusion is <reply> Please don't all step in at once! It can be very overwhelming and confusing for a person to receive advice from more than one person at any given time.
[01:53] <bazhang> nah, its a troll.
[01:54] <Pici> It sounds like a confused user to me.
[01:54] <MenZa> Pici: It's been going on for hours now.
[01:54] <bazhang> that is what I thought as well
[01:54] <MenZa> Pici: Literally.
[01:54] <bazhang> but the responses are the exact same. and then it starts afresh.
[01:58] <bazhang> witness.
[01:58] <MenZa> ah, there we go
[01:58] <MenZa> the cycle is complete.
[01:58] <MenZa> and starts again.
[01:59] <Pici> Then take them aside
[01:59] <niko> i'm agree
[01:59] <bazhang> I'm already on ubuntu
[01:59] <MenZa> bazhang: yours for the taking.
[02:00] <MenZa> This is getting ridiculous.
[02:01] <bazhang> waiting for a response
[02:03] <niko> i guess you can wait a long time
[02:03] <bazhang> heh
[02:04] <bazhang> I'm a patient individual; try Taipei traffic sometime :)
[02:04] <MenZa> lol
[02:04] <bazhang> no response via PM so far
[02:05] <Pici> bazhang: please send another one
[02:05]  * Pici sighs
[02:05] <bazhang> Pici, done
[02:08] <Pici> incoming
[02:08] <bazhang> alright
[02:09] <Pici> bazhang: you're up
[02:09] <bazhang> Linera, hi
[02:13] <Pici> bazhang: Can you op up in #ubuntu and deal with Linera, I need to take a phone call
[02:13] <bazhang> Pici, no problems
[02:14] <bazhang> ray66, hi
[02:16] <bazhang> Linera, you are here though. This is where you need to address, or via PM
[02:19] <bazhang> Linera in here
[02:21] <bazhang> Pici, he/she claims not to be in this channel, I have to step out for a minute, will be back soon.
[02:24] <MenZa> I'm grabbing Cunbuntu in PM
[02:25] <elky> please tell me someone had a word about <AtomicSpark> i cant stalk the womens if my browser is unstable!
[02:25] <MenZa> wat
[02:25] <elky> in -ot
[02:25] <bazhang> did not see that
[02:25] <MenZa> me neither
[02:25] <elky> it seems he though myspace crashing firefox seemed to warrant that comment
[02:26] <elky> came through right on the hour to me
[02:26] <elky> 13:00:00 my time
 i have only 1 channel opened  (from #ubuntu)
[02:27] <Pici> Perhaps ask how they got to #ubuntu and suggest that they use the same method to get here?
[02:28] <bazhang> Pici, he/she is refusing to listen to any/all responses.
[02:28] <nalioth> then let them be
[02:28] <bazhang> ok
[02:29] <nalioth> Linera: if you don't wish to speak with us here, please respect our topic
[02:29] <bazhang> whoa in his quit message no less
[02:30] <nalioth> no ban needed
[02:32] <bazhang> remove the mute on Linera ?
[02:32] <MenZa> For the record, Cunbuntu insisted he did nothing wrong and threw more of his nonsense from -ot at me.
[02:32] <Pici> Just a heads up, terrorink seems to have some problem with me. I've given him the appeals stuff, so if he comes in here please try to address his concerns.
[02:33] <bazhang> okay
[02:34] <nalioth> bazhang: leave linera as they are, please.  i was responding to the DCC in #ubuntu
[02:34] <bazhang> nalioth, ah sorry.
[02:35] <bazhang> Pici, going to de-op now, as Linera is in here and still not responding to my PM
[02:36] <Pici> bazhang: thats fine
[02:36] <nalioth> Linera: may we help you?
[02:47] <Pici> bazhang: someone reported some racist spam they were getting from cunbuntu
[02:48] <bazhang> Pici, lee ?
[02:48] <Pici> yes
[02:48] <bazhang> aha
[02:48] <bazhang> he was doing similar in -ot
[02:49] <Pici> Also, it seems like terrorink is now trying to guess where I live.  I think I'll put him on soft-ignore now.
[02:53] <bazhang> he's klined now (cunbuntu)
[02:53] <nalioth> Pici: feel free to give them my address
[03:43] <PhantomLink> I have temporarily disabled my script so that I can get help in the main channel.
[03:43] <PhantomLink> Am I okay to join there?
[03:59] <dragon> This guy Dorkins in #ubuntu is trolling.
[04:01] <dragon> Asked the same question several times and never acknowledges answers. Several people tried between 6:55pm - 7:20pm PDT
[04:01] <dragon> s/PDT/PST
[04:02] <dragon> and now he's back with the same
[04:57] <nalioth> jrib: did dorkins not seem familiar to you?
[04:57] <nalioth> dorkins = linera (ban evading)
[05:07] <jrib> nalioth: nope, haven't been around much lately
[05:08] <nalioth> jrib: ok.  was a real big to-do earlier over it
[06:10] <DrVenture> test me
[06:10] <DrVenture> << test me >>
[07:31] <bazhang> just a heads up, computer issues so will be away for a bit.
[08:54] <mobi-sheep> !ops | dominic in #ubuntu
[08:55] <tonyyarusso> mobi-sheep: can you give me a quick run-down?  (just joined)
[08:55] <mobi-sheep> tonyyarusso: Spamming. Ubuntu is virus, etc.
[08:55] <tonyyarusso> heh, fun...
[08:56] <mobi-sheep> tonyyarusso: STFU and whatnot. :<
[08:56] <tonyyarusso> well that makes life easier.
[08:57] <mobi-sheep> tonyyarusso: Good job. :)
[08:57] <Flannel> Floodbots are crazy right now, apparently
[10:19] <aaron11> Hi!
[10:19] <aaron11> grubster wants to change somthing in !german
[10:52] <wgrant> elky: Thanks.
[10:54] <elky> wgrant, ping me if he comes back for your jugular
[10:55] <wgrant> elky: I'd have removed him myself if I hadn't been busy hunting for a reference.
[10:55] <elky> yeah, it's also better to have someone else deal with someone attacking you like that
[10:55] <elky> or some random onlooker will try cry personal
[10:55] <wgrant> Yeah, I guess.
[10:56] <elky> not essential, but makes it way easier to process
[10:56] <wgrant> Yep.
[11:18] <elky> yet another bad *jesus*@ :-/
[11:18] <Mamarok> Tm_T: what is wrong with that yang guy?
[11:21] <Mamarok> Tm_T: please don't feed a troll...
[11:22] <Tm_T> I don't think I feed
[11:23] <Mamarok> just ignore him, he has been told the appropriate place to ask for his question, if he continues he is out
[11:23] <Tm_T> but I feel these things have to be told, it's up to them then to listen
[11:24] <Mamarok> Tm_T: we told him 3 times, I guess that is enough, no?
[11:24] <Tm_T> sure, I wasn't planning to go further, only to say how these things works
[11:24] <Mamarok> everything else is feeding trolls IMHO
[11:24] <Tm_T> Mamarok: hmh, didn't notice, I'm busy here cleaning home, sorry
[11:25] <Mamarok> Tm_T: OK, just read the backlog next time :)
[11:26] <Tm_T> Mamarok: I tried, my old eyes seems to fail when in hurry (:
[11:27] <Mamarok> veery old eyes :)
[11:28]  * Tm_T oils his/her/its rusty joints
[11:29]  * Mamarok wonders what she could oil that is not completely blocked yet
[11:29] <Tm_T> banhammer?
[11:30] <Mamarok> oh, right, good suggestion, in case I need it it better is oiled, indeed :)
[11:38] <jussi01> Hello komputes, is there something we can do today?
[11:38] <jussi01> (for you?)
[13:37] <Mamarok> I am off for shopping, later :)
[15:11] <Amaranth_> MenZa: Actually the script to create your email is "making elmo setup emails every so often"
[15:11] <Amaranth_> So, not actually a script :)
[15:12] <Amaranth> Well, I guess there may be a script involved somewhere...
[16:05] <Myrtti> lots of new names...
[16:06] <pleia2> hey Myrtti :)
[16:23] <tritium> greetings
[16:24]  * Tm_T huggles Myrtti
[16:25] <Myrtti> hi. I'm only testing the water
[16:28] <Mamarok> jussi01: komputes not reacting?
[16:28] <Mamarok> komputes: can we help you?
[16:28] <Myrtti> he's idle...
[16:29] <Myrtti> I could remove him but he's a member and might have a valid reason
[16:30] <Mamarok> Myrtti: he is idling since days now
[16:30] <Mamarok> he still can come back when not idle anymore
[16:31] <Myrtti> ok, pming
[16:32] <Myrtti> wow, I still know how to do that
[16:32] <Myrtti> so, I hear paste.ubuntu.com has been rendered useless?
[16:33] <maco> why's that?
[16:33] <tritium> How so?
[16:33] <maco> hi Myrtti
[16:33] <Myrtti> the openid login stuff?
[16:33]  * maco hugs Myrtti
[16:33] <maco> i havent seen you in a long while!
[16:34] <maco> eeeeek when did THAT happen??
[16:34] <maco> now we have to send people to pastebin.ca? ugh. pastebin.ca is slow. its only use WAS the fact that it had encryption
[16:34] <maco> now i guess its use is "not everybody has an lp account"
[16:34] <Myrtti> well my banlist script now useless until I rewrite it
[16:35] <maco> whose idea was *this*?
[16:35] <Myrtti> and the reason I chose it to use paste.ubuntu.com was because p.u.c doesn't have a list of past pastes that you can click and look at
[16:35] <Myrtti> so there was the random anonymity of "if nobody knows the id, you're safe"
[16:36] <Tm_T> indeed
[16:36] <Myrtti> it's not like the ban statistics are high security stuff, but I would've wanted to keep them at some level discreet
[16:36] <Mamarok> it changed to ubuntu.pastebin.com
[16:36] <Myrtti> meh, not going to use it
[16:37] <maco> Mamarok: which does have the sidebar list Myrtti is complaining about
[16:37] <Myrtti> oo, I can click my way to an email pici has pasted there
[16:37] <Myrtti> intresting!
[16:38] <Tm_T> awww
[16:39] <Myrtti> "road to hell is paved with good intentions"
[16:40] <Myrtti> I wonder if pastebinit has taken this recent change into account
[16:40] <Tm_T> Myrtti: 99,99 % sure it has not
[16:41] <Myrtti> yup
[16:41] <Myrtti> oh, WELL.
[16:41] <Tm_T> Myrtti: interesting times are these
[16:42] <Tm_T> does this paste.ubuntu.com change being announced somewhere?
[16:42] <Myrtti> Tm_T: I don't know, I just read it from the logs of this channel today
[16:43] <Myrtti> I've been trying to keep up with the latest news via them
[16:43] <elky> pastebin.ca does allow basic passwording
[16:44] <Tm_T> Myrtti: yu, I was wondering if others knows about it
[16:47] <Myrtti> I need more tea
[16:59] <bazhang>  avash<EMAIL_ADDRESS>has left #ubuntu  just now
[17:00] <bazhang> avash, thanks for joining
[17:01] <avash> yeah because you forced too much. we are at residence now. so it was not any ban evading i was doing.
[17:01] <bazhang> asmodeus, ujjwhol switch , bulb have been using your addresses to troll several ubuntu channels
[17:01] <avash> not this one... they all maybe asleep by now. they do it at daytime from the ip of our work place not this one.
[17:02] <bazhang> avash, switching IP to gain entry to #ubuntu and other channels is ban evasion.
[17:02] <avash> this one is my personal one
[17:02] <avash> 113.199 is different one. you will know it after two days coz now we have weekend.
[17:02] <bazhang> avash, the way to resolve this is not to switch IP to gain entry, but to talk about it here
[17:03] <avash> the ip 113.199 may be banned till now also. its from our work place.
[17:04] <avash> anyway... i will take care of them. and promise you they will not spam or troll or disturb you in your channel. not oly inyours... in whole freenode
[17:04] <bazhang> and asmodeus was using it [asmodeus_] (n=avash@<IP_ADDRESS>): Avash
[17:04] <bazhang> just a little bit earlier today
[17:05] <avash> yeah man.. i said it is my residence and all the machines i have are mine
[17:05] <bazhang> then you need to control your machines.
[17:06] <avash> it was actullay the olpc we use. we give it to everyone. all from my supervision
[17:07] <avash> i will just stop them...now stop blaming me to ban evade. its 11 pm here. i will go to sleep. wil inform you when i have done it.
[17:09] <bazhang> odd. the floodbots did not ban with remove (he's using gateway)
[17:09] <tsimpson> bazhang: because he /nick'd probably
[17:10] <tsimpson> the +e was removed then
[17:10] <bazhang> tsimpson, oh right, LjL just told me
[17:10] <Myrtti> [18:54] <komputes> oh hi, sorry about idling in your channel, I did not  know, I just wanted to get to know the IRC operators for  the official ubuntu channels
[17:11]  * MenZa boggles
[17:11] <MenZa> A... Myrtti?
[17:11] <Tm_T> MenZa: no, go back to sleep
[17:11]  * Tm_T hides
[17:11] <MenZa> It's 6pm here
[17:11] <bazhang> hehe
[17:11] <tsimpson> to be fair, that's how I first became an op, joined here and started idling ;)
[17:11] <bazhang> had a long chat with avash
[17:12] <Myrtti> tsimpson: the times, they are a'changed
[17:12] <bazhang> two or three of his flatmates are using his machines to troll,stalk, etc #ubuntu channels
[17:12] <MenZa> O_o
[17:12] <MenZa> This is what passwords are for.
[17:13] <bazhang> yep
[17:13]  * MenZa never, ever lets anyone use his machines unless they're on a seperate user account which he'll happily create for the sole purpose of not using his, even for five minutes.
[17:13] <bazhang> I asked him to rejoin here when he has gotten the machines in question under control in the next day or so
[17:14] <bazhang> heh
[17:14]  * MenZa nods
[17:14] <bazhang> the leader of the project they are involved with in Nepal knows as well
[17:15] <MenZa> Ah
[17:15] <bazhang> #olenepal
[18:49] <guntbert> hi, the floodbots still tell people to use http://paste.ubuntu.com ....
[18:51] <Myrtti> yes, we know
[18:52] <guntbert> ok, ... bye then


[15:01] <mars> so are we still doing the reviewer's meeting?
[15:03] <sinzui> mars: I held barry up
[15:03] <sinzui> he should be free in a few mimutes
[15:04] <barry> #startmeeting
[15:04] <MootBot> Meeting started at 09:04. The chair is barry.
[15:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:04] <barry> hello and welcome to this week's ameu reviewer's meeting.  who's here today?
[15:04] <sinzui> me
[15:04] <mars> me
[15:04] <gary_poster> me, and I didn't do what I was supposed to yet :-P
[15:04] <noodles775> me
[15:04] <adeuring> me
[15:04] <barry> rockstar: sends his apologies
[15:05] <barry> gary_poster: oh well, next week <wink>
[15:05] <gary_poster> :-)
[15:05] <barry> allenap: ping
[15:05] <barry> bac: ping
[15:05] <barry> BjornT: ping
[15:05] <bac> me
[15:05] <barry> cprov: ping
[15:05] <barry> danilos: ping
[15:05] <allenap> me
[15:05] <intellectronica> me
[15:05] <abentley> me
[15:05] <barry> EdwinGrubbs: ping
[15:06] <EdwinGrubbs> me
[15:06] <barry> flacoste: ping
[15:06] <flacoste> me
[15:06] <barry> gmb: ping
[15:06] <cprov> me
[15:06] <barry> salgado: ping
[15:06] <barry> just another minute...
[15:06] <danilos> me
[15:07] <barry> [TOPIC] agenda
[15:07] <MootBot> New Topic:  agenda
[15:07] <barry> it's a light one today, not surprisingly
[15:07] <salgado> me
[15:07] <barry>  * Roll call
[15:07] <barry>  * Action items
[15:07] <barry>  * Mentoring update
[15:07] <barry>  * Peanut gallery (anything not on the agenda)
[15:07] <barry> [TOPIC] action items
[15:07] <MootBot> New Topic:  action items
[15:07] <barry> we already know about gary_poster :)
[15:07] <barry>  * flacoste to work on API reviewer cheat sheet
[15:07] <gary_poster> :-)
[15:08]  * flacoste whistles innocently
[15:08] <barry> we already know about flacoste :)
[15:08] <danilos> do we still need it?
[15:08] <flacoste> i think we do
[15:08] <flacoste> paradoxically
[15:08] <noodles775> lol
[15:08] <intellectronica> we've done quite good without it for a long tim
[15:08] <intellectronica> time, even
[15:08] <flacoste> well
[15:08] <danilos> ok, let me rephrase the question: is it worth keeping it in the agenda?
[15:09] <flacoste> maybe not
[15:09] <flacoste> i know i need to do it
[15:09] <barry> flacoste: i'll remove it.
[15:09] <flacoste> there is a lot of tricky issues in API export that are often missed
[15:09] <flacoste> updating the URLs being an obvious one
[15:09] <barry> but i still think it would be a good thing to have
[15:09] <flacoste> but often things about the use of readonly
[15:10] <flacoste> the naming conventions are kind of understood
[15:10] <barry> esp. because this will go in our dev wiki so it will be helpful to outside contributors
[15:10] <flacoste> btw, in the coming weeks we should be able to use launchpadlib for API testing within launchpad
[15:10] <barry> flacoste: as a buildout benefit?
[15:10] <flacoste> once gary moves zope to buildout and we update all the lazr.* packages to the latest version
[15:10] <flacoste> barry: right on
[15:11] <barry> nice!
[15:11] <flacoste> btw, anybody noticed the improved tags with buildout?
[15:11] <barry> flacoste: not yet!
[15:11] <flacoste> try it out! you can jump to symbol in the stdlib or stuff in any eggs
[15:12] <barry> flacoste: bin/tags tracebacks for me
[15:12] <flacoste> oops
[15:12] <flacoste> ok, we'll look into this
[15:12] <barry> flacoste: cool, thanks!
[15:12] <barry> between that and jml most awesome emacs module, you will never lose a symbol again
[15:13] <barry> moving on...
[15:13] <barry> [TOPIC] mentoring update
[15:13] <MootBot> New Topic:  mentoring update
[15:13] <barry> any feedback from mentors or mentats?
[15:13] <adeuring> I think it is time for Henning to graduate
[15:13] <barry> adeuring: soon as he shows up to a reviewer's meeting <wink>
[15:14] <noodles775> I'm still enjoying Celso's mentoring :), looking forward to getting back into it tomorrow after the 2 week break.
[15:14] <barry> adeuring: serious, that's great
[15:14] <barry> noodles775: excellent!
[15:14] <noodles775> BTW: I think he's resting from Ubuflu at the moment...
[15:14] <barry> :(
[15:14] <barry> cool, anything else?
[15:15] <barry> [TOPIC] peanut gallery
[15:15] <MootBot> New Topic:  peanut gallery
[15:15] <barry> anybody have anything not on the agenda?  any barcelonan epiphanies about reviews?
[15:16] <intellectronica> remind your mentats to land javascript branches with [js] in the commit message
[15:16] <abentley> Now that bzr 1.5 is out, everyone should check out bzr+ssh://bazaar.launchpad.net/%7Elaunchpad/lpreview-body/trunk/
[15:16] <abentley> This is a bzr plugin that automatically sets the message body for an lp review request to our standard template, and includes lint output.
[15:16] <barry> intellectronica: do we have a pqm regexp for that now?
[15:17] <noodles775> niice
[15:17] <cprov> err, sorry, was preparing a tea.
[15:17] <abentley> Of course, this only works with bzr send, so this is a good reason for everyone to use bzr send.
[15:17] <intellectronica> barry: no. we'd have to inspect the diff for something like that to work
[15:17] <noodles775> cprov: you're meant to be sleeping off your headache :)
[15:18] <cprov> barry: noodles775 is doing great reviews, his graduation will come soon too.
[15:18] <barry> intellectronica: so is this a [js=somebody] tag?
[15:18] <barry> cprov: fantastic
[15:18] <intellectronica> barry: no, just [js]
[15:18] <intellectronica> to indicate that the branch requires testing on multiple platforms
[15:18] <danilos> abentley: bzr send is good, can you email the list about the plugin as well
[15:19] <abentley> Also, with the recent launchpad changes, you don't need to push before you send, and you don't need to use lpsend or send --no-bundle.
[15:19] <mars> barry, it is just a flag to QA that somebody needs to look at the branch in all the browsers
[15:19] <danilos> abentley: perhaps document it on dev.launchpad.net as well
[15:19] <barry> intellectronica: k.  do all devs know about that?  maybe a msg to launchpad@ to remind people?
[15:19] <intellectronica> barry: we already had a message. i can send another one
[15:19] <abentley> danilos: Okay, but I already emailed the list, and no one responded, so I thought I should bring it up here.
[15:19] <barry> intellectronica: might not be a bad idea to remind people
[15:20] <danilos> abentley: ^^ :)
[15:20] <danilos> abentley: I am certainly going to check it out
[15:20] <barry> abentley: yes, document on the dev wiki, and this sounds awesome
[15:21] <abentley> barry: will do.
[15:21] <barry> abentley: thanks!
[15:22] <barry> anything else guys?
[15:22] <barry> 5
[15:22] <barry> 4
[15:22] <abentley> barry: It's not open-source, so does it make sense to document on the dev wiki?
[15:23] <barry> abentley: i think it's fine.  i'd still rather have one place to find relevant information, but i'll leave it up to you
[15:23] <barry> abentley: is there any reason it /can't/ be open source?
[15:24] <abentley> barry: Needs signoff from Mark or the holy trinity, and that hasn't happened yet.
[15:24] <barry> abentley: ok.  i'd say document it on the dev wiki and we can work toward open sourcing it
[15:24] <abentley> barry: The ball is currently in kiko's court on open-sourcing.
[15:25] <barry> abentley: let's keep the jfdi pressure on kiko then! :)
[15:25] <barry> anybody have anything else?
[15:25] <abentley> barry: See https://wiki.canonical.com/OpenSource/Process
[15:26] <barry> yeah
[15:26] <barry> 5
[15:26] <barry> 4
[15:26] <barry> 3
[15:26] <barry> 2
[15:26] <barry> 1
[15:26] <barry> #endmeeting
[15:26] <MootBot> Meeting finished at 09:26.
[15:26] <barry> thanks everyone!
[15:26] <noodles775> cheers barry
[15:27] <abentley> barry: thx


[13:45] <cwayne> heya is there any way to have windows snap into corners (like they do in unity8) in unity7? (as opposed to snapping into halves)
[13:46] <Trevinho> cwayne: in ccsm -> grid plugin, you can enable that
[13:47] <Trevinho> cwayne: just set the Corners options to proper values... and you can get it
[13:47]  * Trevinho wonders if it would be the case to have it by default
[13:48] <cwayne> Trevinho: thanks!
[13:48] <cwayne> Trevinho: IMHO it'd be a nice default, that's one of the things I immediately loved when trying out the u8 session
[13:48] <cwayne> but it could just be me :)
[13:49] <Trevinho> cwayne: well, it's ncie... it might be problematic in some scenarios, but yeah... I agree I t could be useful
[13:49] <cwayne> yeah, i could see it being an issue
[13:50] <Trevinho> like in low resolutions...
[13:51] <cwayne> maybe make it default if it knows its at a 4k resolution?
[13:51] <cwayne> or just make it clearer its an option
[13:51] <cwayne> i would've enabled it long ago if I'd known :)
[13:53] <Saviq> re
[15:59] <josharenson> pstolowski: Have you built unity-scopes-shell for armhf lately? I can't get vivid+overlay to build on my arale
[16:21] <cimi> josharenson, make a silo?
[16:23] <josharenson> cimi: that should work... lot of effort to iterate over small changes, but I'll just add a whole bunch of debug code each time to try and minimize the amount of rebuilds...
[16:23] <josharenson> cimi: I'm also trying to cross compile :-p
[16:31] <Saviq> josharenson, they might have a separate branch for vivid already
[16:32] <Saviq> josharenson, https://code.launchpad.net/unity-scopes-shell
[16:32] <Saviq> I'd try lp:unity-scopes-shell/vivid+overlay
[16:39] <cimi> yeah they have, told you yesterday
[16:45] <josharenson> cimi: yeah I tried that... still getting weird qt issues.. Have you tried building it lately?
[16:45] <cimi> josharenson, no but pawel did a ppa with vivid
[16:47] <cimi> josharenson, https://code.launchpad.net/~unity-api-team/+archive/ubuntu/dev-build-4
[16:48] <josharenson> cimi: cool, ok
[17:06] <josharenson> cimi: works with that ppa :-)
[17:16] <cimi> josharenson, managed to reach the root cause of the slowness?
[17:17] <josharenson> cimi: running an instrumented branch now... Didn't learn much from just running it on the mock yesterday
[18:26] <josharenson> cimi: well, moveFavoriteTo isn't the culprit
[18:26] <josharenson> cimi: neither are some of the other favorite functions...
[18:27] <josharenson> cimi: I'll enable QSG_RENDER_TIMINGS and dig through that


[11:27] <Bryan_Fury89> ciao a tutti
[15:45] <neillR> help
[15:45] <neillR> can u
[15:46] <neillR> sorry bye


[02:19] <ponchale> hi handsome_feng how are you doing?
[02:34] <handsome_feng> Hi, Did you get my email?
[03:14] <ponchale_> yeah I see you email and I was a little frustrated
[03:18] <ponchale> because we don't want to bifurcate but rather work together, perhaps unite or an alliance or a partnership, but if that was the leader's response
[03:45] <handsome_feng> Our team is small at the moment, but we'll keep an eye on your project and maybe even collaborate in the future!
[04:08] <ponchale> Ok, Excellent


[05:55] <Kilos> o/
[05:57] <Mister_Q> \o
[05:59] <svij> o/
[12:01] <ahoneybun> mhall119: ping community fund question
[12:10] <knome> ahoneybun, i would just ask it, then he or anybody else can answer it when they are back...
[12:13] <ahoneybun> one of our kubuntu members did not hear back about his request to attend akademy
[12:15] <knome> yeah... we've recently pointed out that it would be nice to always get a human response relatively quickly
[12:59] <popey> We try to set expectations on the form. It says expect a response in 14 days. However, half the community team are on vacation right now. So it's tricky
[12:59] <popey> Also, the person who manages the finance is also on vacation.
[13:00] <popey> ahoneybun: who hasn't received a response.
[13:00] <popey> ?
[18:00] <jcastro> pleia2: around?
[18:06] <pleia2> jcastro: hey
[18:23] <pleia2> so, the harddrive on my laptop just died (it's been touch and go for a couple days)
[18:23] <pleia2> I am now on my Ubuntu tablet, haha
[18:23] <pleia2> trial by fire
[18:23] <Kilos> ouch
[18:23] <pleia2> yeah, it's not great
[18:23] <jcastro> sounds like a good reason to get a new SSD
[18:24] <pleia2> work laptop, I have requested an SSD but they'll probably give me spinning rust again ;)
[18:24] <Kilos> what a speed difference ssd's make
[18:24] <pleia2> just 5 months shy of replacement window for this whole laptop (4 year hardware deprecation cycle)
[18:24] <jcastro> ;_;
[18:24] <Kilos> whew


[01:12] -queuebot:#ubuntu-quality- Builds: Lubuntu Next Desktop i386 [Artful Beta 1] has been updated (20170829)
[01:12] -queuebot:#ubuntu-quality- Builds: Lubuntu Next Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:22] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop i386 [Artful Beta 1] has been updated (20170829)
[01:22] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:24] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:24] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop i386 [Artful Beta 1] has been updated (20170829)
[01:25] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Artful Beta 1] (20170829) has been added
[01:25] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop i386 [Artful Beta 1] (20170829) has been added
[01:26] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:26] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] has been updated (20170829)
[01:27] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop i386 [Artful Beta 1] has been updated (20170829)
[01:27] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:32] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Artful Beta 1] has been updated (20170829)
[01:32] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop i386 [Artful Beta 1] has been updated (20170829)
[02:21] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Artful Beta 1] has been updated (20170829.1)
[02:21] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop i386 [Artful Beta 1] has been updated (20170829.1)
[11:23] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 1] has been updated (20170829.1)
[11:23] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop i386 [Artful Beta 1] has been updated (20170829.1)
[21:20] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD amd64 [Artful Beta 1] (20170829) has been added
[21:20] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD i386 [Artful Beta 1] (20170829) has been added