[03:31] <bobweaver> !info
[07:12] <lool> Hey
[07:13] <lool> just saw a case where a team with a public mailing-list archive was subscribed to a private bug, and the private bug was of course visible in the public archives
[07:14] <lool> Is this something that Launchpad should avoid or warn about, or is it just misuse on the users' side?
[07:15] <wgrant> Launchpad could possibly special case that, but it seems somewhat dangerous to let people expect a warning when many teams use non-LP mailing lists that can't be warned about.
[07:16] <wgrant> Shouldn't people normally be knowing about the team they're subscribing to a private bug?
[07:16] <lool> Here, it's a release team which is listed in the members of another team which owns the project
[07:16] <lool> https://bugs.launchpad.net/lava-scheduler-tool/+bug/842524
[07:17] <lool> I don't understand the reasons why ~linaro-release is a member of ~linaro-validation, this seems unnatural to me
[07:19] <wgrant> It's unnatural, but a valid structure :)
[07:19] <lool> well what I really wonder about is whether it's a really stupid or a really clever one  :-)
[07:20] <lool> wgrant: I'll pass the argument of non-lp MLs in the discussion I'm startong; makes sense to me
[07:21] <lool> wgrant: There is a real problem with LP MLs here though IMO: as soon as you make a team a ML, then you lose the chance of using for any private communication, but I guess that's the choice of people setting this up
[07:21] <wgrant> Yeah, it's not ideal, but it's not entirely clear how to make it better.
[07:22] <lool> yes
[07:43] <jtv> wgrant: would you be up for another gina-dominatrix review?  Here's my follow-up branch as discussed: https://code.launchpad.net/~jtv/launchpad/re-830890/+merge/74552
[07:45] <wgrant> jtv: Let me see.
[07:45] <wgrant> (I didn't expect it so soon!)
[07:46] <jtv> wgrant: nooobody expects transitional debian domination!  Our chief…
[07:46] <wgrant> Heh
[07:51] <geser> oh, the imported Debian packages in LP get now proper status instead of being in "Pending" forever?
[07:55] <tumbleweed> geser: does that break requestsync?
[07:56] <geser> tumbleweed: yes, but the fix should be easy: ubuntutools.lp.lpapicache lines 305-313 can be deleted once this is live
[07:56] <wgrant> geser: They'll behave sensibly soon, yep.
[07:57]  * tumbleweed suspects that may affect other u-d-t things too
[07:57] <geser> we might also need to do an SRU in Ubuntu and Debian to unbreak requestsync
[07:57] <wgrant> Superseded ones will be superseded, deleted ones will be deleted, and published ones will be published instead of pending.
[07:57] <wgrant> This hasn't landed quite yet.
[08:01] <geser> is bug 830890 the right one to subscribe to get notified when this goes live?
[08:04] <wgrant> jtv: ^^
[08:05] <jtv> geser: I'm afraid it's no longer down to a single bug.  I'll cross-link them in a minute, if you want to follow this closely.
[08:05] <jtv> thanks wgrant for the notice
[08:06] <jtv> and speaking of wgrant: there's a comment in gina's ImporterHandler saying that the new pubs are Pending so that they can be "republished into a Soyuz archive."  Does that make any sense?
[08:12] <wgrant> jtv: For the initial Ubuntu import.
[08:12] <jtv> Phew.  So I can just change that to Published and have a clear conscience?
[08:12] <wgrant> Except that Dapper was imported as Published and then they were all duplicated as Pending.
[08:12] <wgrant> So.
[08:12] <wgrant> No valid reason to keep it.
[08:13] <jtv> Great.
[08:16] <mrevell> Morning all
[08:16] <jtv> morning mrevell!
[08:54] <poolie> hi all
[08:54] <poolie> lp is down, hopefully only briefly
[08:55] <nigelb> Update the /topic as well? And tweet?
[08:55] <wgrant> And we're back.
[08:56] <nigelb> That was fast.
[08:56] <wgrant> It was meant to be faster :(
[08:57] <wgrant> nigelb: It was a trial run of our fast DB update process.
[08:57] <nigelb> Ooh. Success?
[08:57] <wgrant> nigelb: Rather than going down for 90 minutes a month, we go down for a minute or two whenever we need.
[08:57] <wgrant> Indeed.
[08:57] <nigelb> That's definitely nicer.
[08:58] <nigelb> But what if a DB patch is expensive
[08:59] <bigjools> well, hopefully a lot less than a minute
[08:59] <bigjools> we are not writing expensive db patches now
[09:02] <nigelb> But yeah. This means things get deployed faster without blocking.
[09:02] <nigelb> That is good news. I guess there'll be some sort of detailed blog post about this soonish :)
[09:03] <wgrant> lifeless blogged about it ages back, but I guess everyone has forgotten.
[09:03] <wgrant> http://blog.launchpad.net/coming-features/no-more-monthly-90-minute-downtime
[09:03] <nigelb> Ah, that is this.
[09:05]  * ajmitch probably shouldn't try & get lp running on his laptop again late in the evening
[09:05] <nigelb> Yeah, its addictive.
[09:06] <ajmitch> only if it's working :)
[09:07] <nigelb> What's not working?
[09:07]  * ajmitch is back at the point where LP appears to be running, but can't log in
[09:07] <nigelb> https?
[09:07] <nigelb> (that's my *most* common mistake)
[09:08] <ajmitch> afaik it's working, firefox shows the page & some fake-looking certificate
[09:08] <nigelb> oh, but you can't login as<EMAIL_ADDRESS>[09:08] <ajmitch> well when I try & log in I get "OpenID Provider Is Unavailable at This Time"
[09:09] <nigelb> Never faced that before.
[09:09] <wgrant> ajmitch: Can you browse to testopenid.dev?
[09:09] <ajmitch> yep
[09:09] <ajmitch> not a very informative page, but "Test OpenID provider for launchpad.dev"
[09:09] <wgrant> Are you running it in a VM?
[09:10] <ajmitch> no, just on my local apache on the laptop
[09:10] <wgrant> Hmm.
[09:10] <wgrant> Nothing in the appserver or apache error logs?
[09:10] <ajmitch> nothing obvious that I saw
[09:12] <ajmitch> which log in particular should I look at?
[09:13] <wgrant> The output of 'make run'
[09:13] <wgrant> And all of Apache's logs.
[09:14] <ajmitch> ok, looks like something isn't running, /var/log/apache2/error.log & showing connection refused on port 8086
[09:15] <wgrant> Does it give a hostname?
[09:15] <ajmitch> [Thu Sep 08 21:11:33 2011] [error] (111)Connection refused: proxy: HTTP: attempt to connect to <IP_ADDRESS>:8086 (localhost) failed
[09:17]  * ajmitch wonders if that's even related, restarted the appserver & tried to log in, no entry in /var/log/apache2/error.log
[09:17] <wgrant> You are running make run, right? :)
[09:17] <nigelb> heh
[09:17] <ajmitch> of course :P
[09:18] <wgrant> Because 8086 is where *.launchpad.dev goes.
[09:18] <nigelb> HA.
[09:18] <wgrant> So if that's down, you shouldn't have much luck requesting launchpad.dev...
[09:18] <nigelb> I'm guessing that's a request from just before launchpad.dev came up
[09:18] <nigelb> when apache returns the 503.
[09:18] <ajmitch> yeah
[09:18] <ajmitch> when I was in the middle of restarting the appserver & being impatient
[09:21] <nigelb> Yay, back to zero.
[09:22]  * ajmitch wonders if he should just try it in a VM instead
[09:23] <nigelb> What version of ubuntu?
[09:23] <nigelb> I don't use a VM for launchpad.
[09:23] <ajmitch> lucid
[09:24] <ajmitch> & I have had LP running before on this, but it was at least a few months ago that I started it up :)
[09:26] <nigelb> Hrm, I run launchpad on lucid dwithout VM.
[09:27] <ajmitch> so have I :)
[09:28] <nigelb> maybe try doign an rf-get to update your code
[09:29] <ajmitch> did the
[09:29] <ajmitch> s/the/that/
[10:25] <chrisccoulson> i'm not sure what  https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/2771746 is doing, but someone might want to kill it
[10:25] <chrisccoulson> it's been hung for ages now
[10:26] <wgrant> Let me guess, someone turned shipova or bohrium back on...
[10:26] <chrisccoulson> it's shipova ;)
[10:26] <wgrant> Heh.
[10:26]  * wgrant kills.
[10:26] <chrisccoulson> thanks
[10:28] <wgrant> chrisccoulson: Hmm, it is taking its time to die.
[10:28] <wgrant> Will give it a few minutes before I obtain a larger hammer.
[10:38] <chrisccoulson> wgrant, i guess you need to get the larger hammer ;)
[11:21] <jjardon> Hello, does launchpad support bz or xz files?
[11:22] <jjardon> I have to change the release URL patter of GTK+: https://launchpad.net/gtk/3.2
[16:04] <bjf> i need to get the LP credentials for a lplib script onto a headless system
[16:05] <bjf> how do i do that? i used to be able to just copy the credentials from my cache but i don't seem to be able to find the credentials anymore
[16:06] <bjf> is there an officially supported way to do this?
[16:07] <tumbleweed> bjf: just run the launchpadlib program on the headless system, and it'll create a credentials cache in a file, rather than in gnome/kde secret store
[16:08] <tumbleweed> see /usr/share/doc/python-launchpadlib/NEWS.Debian.gz
[16:17] <bjf> tumbleweed, that doc suggests uninstalling python-gnomekeyring which will break other apps on the local system
[16:18] <tumbleweed> bjf: that was the best workaround we could come up with :/
[16:23] <Daviey> Hmm.. Silly question, but how do i use non-system-wide / keyring with launchpadlib?
[16:25] <tumbleweed> bjf: I guess your best workaround is to pass an UnencryptedCredentialStore to Launchpad.login
[16:25] <tumbleweed> Daviey: I don't think you do, any more
[16:29] <Daviey> tumbleweed: Yeah, I don't think you can use a non gui agent can you?
[16:29] <Daviey> As in, kinda makes the API less useful for server tasks.
[16:29] <Daviey> cron etc
[16:29] <tumbleweed> Daviey: yes, there's the UnencryptedFileCredentialStore
[16:30]  * Daviey grosk that
[16:30] <Daviey> thanks
[16:30] <bjf> tumbleweed, any examples of using UnencryptedFileCredentialStore ?
[16:31]  * tumbleweed writes a quick example
[16:31]  * Daviey hopes that still allows non-private read-only access
[16:36] <tumbleweed> bjf: http://paste.ubuntu.com/685412/
[16:36] <macer1> Hi
[16:37] <macer1> I have a problem with bug status changing
[16:38] <macer1> It affects project 1, and project. Now i now that it does not affect project 1 and 2 completly, but affects project 3(and is fixed now). How can I add another affect ...?
[16:38] <macer1> *now i know
[16:39] <bjf> tumbleweed, very interesting thanks!
[16:40] <macer1> *it affects project 1, and project 2
[16:49] <dobey> Daviey: what are you trying to do exactly?
[16:49] <dobey> Daviey: use one set of credentials for multiple lplib scripts?
[16:50] <Daviey> dobey: No, i want per script auth, and not have to type in a passphrase for the keyring
[16:51] <dobey> Daviey: oh. change your keyring password to be the same as your system log-in password. then it will unlock automatically when you log into ubuntu
[16:52] <Daviey> dobey: and cron?
[16:52] <dobey> oh, from cron
[16:53] <dobey> do what tarmac does :)
[16:53] <dobey> (and don't run scripts that need to authenticate to things as your normal user from cron)
[16:55] <Daviey> not helpful :)
[16:56] <dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/view/head:/tarmac/bin/commands.py#L84
[16:57] <dobey> iow, just pass credentials_file='/home/blah/.config/blah' to login_with() :)
[16:57] <dobey> and disposable bot users ftw
[16:59] <macer1> no help?
[17:00] <dobey> macer1: you can use the expander arrow and change one of the projects it does not effect, to one it does, or click the "also affects project" link
[17:01] <macer1> oh ok
[17:01] <macer1> that  button
[18:42] <VadimTk> bac, hi, I am one had question with vaucher
[21:44] <kirkland> dobey: ping
[21:44] <kirkland> dobey: https://bugs.launchpad.net/ubuntu/+source/lptools/+bug/845170
[21:44] <kirkland> dobey: could you take a look at the branch/fix there
[21:44] <kirkland> dobey: this is breaking lp-project-upload in oneiric
[22:16] <reed> hello folks, is there a way to download the mailing list archives from launchpad?
[23:07] <bjf> OOPS-2077CD1260
[23:09] <exarkun> Can I hide downloads?
[23:14] <wgrant> exarkun: I don't believe so.
[23:16] <wgrant> bjf: Bug #716780
[23:16] <bjf> wgrant, thanks
[23:18] <bjf> wgrant, i'm getting that from a script i'm running, does that mean i'm screwed until it gets fixed ?
[23:20] <bjf> wgrant, or will i "get lucky" some times ?
[23:21] <wgrant> bjf: You may get lucky sometimes, but it's pretty difficult to say.
[23:22] <bjf> wgrant, ok, will try it occasionally
[23:34] <lifeless> exarkun: you can remove them I think. Or do you mean you want them available but not visually advertised ?


[11:02] <nickoe> Hello, I wonder about the following comment when trying to mark a bug a duplicate. "Marking this bug as a duplicate will, by default, hide it from search results listings."   Soo does this mean that if anything matches the bug that is marked as a duplicate will return the one that one specifies it a duplicate of, or does it just hide the bug al together, such that no one can find it anymore?
[13:03] <cjwatson> nickoe: Bugs that are marked as duplicates of other bugs are hidden from search results by default, although this is configurable.  See e.g. the "Hide duplicate bugs" checkbox on https://bugs.launchpad.net/launchpad/+bugs?advanced=1.
[14:26] <nickoe> cjwatson: ok, there. But with that checkbox checked, it seems to me it is harder to find a bug, i.e. if ther eis three bugs that is actually describing the same, but with different words. So if i mark two of those bugs a duplicate of one of them, then other people discovering the bug has a harder time searching for the bug they have discoverd, and might not find it, because they are hidden from search, then we could have yet another duplicate.
[14:56] <cjwatson> nickoe: Right.  But the point of marking things as duplicates is generally that you don't want to see them.  You can edit the description of the duplicate target if that helps searches
[15:22] <nickoe> cjwatson: ok


[00:02] <james_w> yeah
[00:02] <james_w> not tonight though
[00:04] <james_w> ah, I think it's just karmic that is affected
[00:05] <james_w> I missed that branch when fixing last time
[00:05] <james_w> so even if I had added the check it still wouldn't have caught this problem
[00:07] <johnf> jelmer: ping
[00:09] <SamB_XP_> barry: why did you decide to use the nightlies by accident ?
[00:16] <lifeless> james_w: it wouldn't have caught it? [oh because you wouldn't have added the check there :P]
[00:16] <lifeless> james_w: I'll see if johnf can fix it, its his daytime now.
[00:16] <lifeless> johnf: https://bugs.edge.launchpad.net/bzr/+bug/439100
[00:16] <james_w> yeah
[00:16] <james_w> just add python-pyrex to build-depends
[00:17] <james_w> and then glob the .so files in the .install file I say
[00:17] <lifeless> so that dh_install errors if missing?
[00:17] <lifeless> uhm, I suspect the python stuff will interact badly
[00:18] <james_w> yeah
[00:18] <james_w> or just an "ls" glob in the rules file or something
[00:19] <lifeless> in particular if things change we'll break, so we shhouldn't alter the install mechanism
[00:19] <lifeless> james_w: yeah, I was thinking
[00:19] <lifeless> [ 7 -e `ls debian/pkg/.../*.so | wc -l` ]
[00:20] <lifeless> erm, not -e. equal.
[00:20] <johnf> so my question is what are the nightlies being built from because the other PPA packages are fine
[00:20] <johnf> Although I'm using a new method now which I need to document soon
[00:20] <lifeless> \o/
[00:21] <lifeless> you've probably discarded the karmic packaging
[00:21] <lifeless> the nightlies build using the packaging branches AIUI
[00:21] <lifeless> james_w: are the nightlies conceptually compatible with autoppa
[00:21] <james_w> not sure
[00:22] <james_w> the normal builds don't have a problem as they are built from the release tarballs
[00:22] <johnf> ahh the packaging branches don't have pyrex
[00:22] <james_w> with you don't need pyrex for
[00:22] <james_w> as the release manager does that step
[00:22] <james_w> so it's an uneeded dependency there
[00:22] <james_w> but just installing it everywhere makes it easier to manage
[00:22] <johnf> ok Let me document my new process using debian as a base and autoppa on top of that over the weekend and then let's switch the nightlies over to that process
[00:22] <lifeless> johnf: so I have two goals: a) fix it. b) put a rule in to catch regressions (e.g. if we change to cython)
[00:23] <johnf> lifeless: I think preference would be to catch it in the Makefile so that we solve this problem for all distributions. ie a make install should fail
[00:24] <johnf> in fact why don't we just make the make fail if pyrex is missing?
[00:27] <lifeless> different users
[00:27] <lifeless> we were going to start versioning the .c files
[00:44] <idnar> what exactly is the format of a bzr+ssh:// URL?
[00:44] <lifeless> std66
[00:44] <lifeless> which is to say, what you'd expect
[00:44] <lifeless> idnar: is there a particular thing that is troubling you?
[00:45] <idnar> I just don't know how to construct one, I've only ever worked with scp/rsync-style paths
[00:45] <lifeless> oh
[00:45] <lifeless> so the same as http:// urls
[00:45] <idnar> and I seem to be doing it wrong, because bzr tells me "Parent directory of [...] does not exist"
[00:45] <lifeless> rooted at /
[00:45] <idnar> I guess I need the absolute path to the home directory
[00:45] <lifeless>  bzr+ssh://[user[:password]@host/paths/home/here
[00:45] <lifeless> yes
[00:46] <lifeless> because we start the server when we connect, it doesn't have a build in chroot like http servers do
[00:48] <spiv> (If you have bzr.dev on the server, you can use a path starting with ~/ to be relative to the home directory on the server, e.g. bzr+ssh://myhost/~/myproj)
[00:48] <idnar> ah, I tried that, but this is with 1.16 or something
[00:48] <mzz> I keep forgetting where /~/ works. Is that only with bzr.dev with bzr+ssh currently?
[00:48] <spiv> mzz: yes
[00:48] <lifeless> idnar: we had a choice between // meaning root and / meaning homedir, or /~/ meaning homedir and / meaning root
[00:49] <mzz> ok
[00:49] <lifeless> we took the latter choice
[00:49] <lifeless> mzz: and sftp
[00:49] <lifeless> mzz: sftp has always worked
[00:49] <mzz> ahh, sftp is probably what I was confused with then.
[00:49] <mzz> oh well, no big deal either way, my name's not that long compared to the hostname and branch name usually
[00:50] <lifeless> idnar: 2.0. Its good. Get it.
[00:51] <mzz> yay, progress (although I really don't use bzr with any trees of sufficient size for it to matter all that much to me)
[00:52] <idnar> lifeless: we probably will once it's in lenny-backports
[00:54] <lifeless> idnar: I suspect that requires a request
[00:54] <lifeless> its in debian so should be trivial for the backport team to do
[00:59] <idnar> anyhow, it's pretty far down my list of priorities right now
[01:00] <lifeless> sure
[01:00] <lifeless> I'd drop them a mail though :)
[01:00] <idnar> 2a format seems like it'll be nice when we switch, though
[01:00] <lifeless> its rocking
[01:01] <idnar> we're currently using 1.6 format, I think
[01:02] <jelmer> /clear
[01:02] <idnar> whatever the minimum that supports stacking is
[01:02] <lifeless> 1.6
[01:02] <lifeless> 1.9 has faster indices
[01:02] <lifeless> 2a has faster everything
[01:02] <idnar> I think we could upgrade to 1.14, but I'll just wait until we can do 2a
[01:03] <lifeless> you can now
[01:03] <lifeless> but it is fragile < 2.0.0
[01:33] <mwhudson> Peng: can you explain in words of one syllable what the problems with loggerhead and yui3 final are?
[01:38] <mzz> that is not a lot of speech sound things. To say a thing with that rule in place is hard, but at the same time a bit fun
[01:41] <lifeless> mwhudson: does not work ? ;)
[01:41] <mwhudson> lifeless: ta
[01:41] <mwhudson> seems to be accurate in fact, surprisingly enough
[01:42] <mwhudson> it just doesn't work at all, for no very obvious reason
[01:43] <lifeless> if I can suggest unbundling yui - debian unbundle it anyway; make it a dependency
[01:44] <mwhudson> possibly a good idea
[01:44] <mwhudson> orthogonal though
[01:44] <lifeless> yes
[02:25] <Peng_> mwhudson: There's a new feature in YUI 3.0.0, where you basically do YUI.use('whatever', function() { my_code(); }). It's possible that the old style that Loggerhead uses doesn't work anymore. I didn't check, though.
[02:25] <Peng_> mwhudson: http://www.yuiblog.com/blog/2009/09/29/yui-3-0-0/
[02:25]  * Peng_ goes AFK again
[02:25] <mwhudson> Peng_: yes, that's right it seems
[02:26] <mwhudson> Peng_: it's not a new feature in yui 3 vs 3pr2, it's new compared to yui2
[02:26] <mwhudson> Peng_: thanks for the prod
[02:28] <emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
[02:29] <emmajane> kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
[02:29] <emmajane> kirkland, http://bazaar-vcs.org/static/
[02:30] <emmajane> (just in case you still happen to be around :) )
[02:34] <emmajane> hrm
[02:34] <emmajane> let's try that again...
[02:34] <emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
[02:34] <emmajane>  kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
[02:34] <emmajane> kirkland, http://bazaar-vcs.org/static/
[02:34] <emmajane> (just in case you still happen to be around :) )
[02:36] <kirkland> emmajane: these are wrong:
[02:36] <kirkland>   var googleSearchIframeName = "cse-search-results";
[02:36] <kirkland>   var googleSearchFormName = "cse-search-box";
[02:36] <kirkland> emmajane: mine look like this:
[02:36] <kirkland>                 var googleSearchIframeName = "results_003883529982892832976:ly2fmeg302s";
[02:36] <kirkland>                 var googleSearchFormName = "searchbox_003883529982892832976:ly2fmeg302s";
[02:37] <kirkland> emmajane: you need yours to make your google cx id or whatever
[02:37] <kirkland> emmajane: do you have access to the google custom search front end?
[02:37] <emmajane> kirkland, it's poolie's. I don't have all the controls as when I make my own.
[02:39] <kirkland> emmajane: gotcha
[02:39] <kirkland> emmajane: try this...
[02:39] <emmajane> I believe I'm: cx=009852948614216791564:dr5xzrczfnu
[02:40] <kirkland> emmajane: oh, there you go
[02:40] <kirkland> emmajane: http://pastebin.ubuntu.com/282607/
[02:40] <emmajane> so just results_009852948614216791564:dr5xzrczfnu (maybe?)
[02:40] <kirkland> emmajane: replace the _[0-9]* with that
[02:41] <kirkland> emmajane: yes, exactly
[02:41] <emmajane> with the :etc
[02:41] <kirkland>     <input type="hidden" name="cx" value="009852948614216791564" />
[02:41] <kirkland> emmajane: and that too
[02:41] <kirkland> emmajane: yes, with the :.*
[02:41] <emmajane> thanks :)
[02:41] <emmajane> I've found the documentation on this to be plentiful AND useless all at the same time. :/
[02:44] <kirkland> emmajane: :-)
[02:44] <kirkland> emmajane: it is a bit of a mystery
[02:44] <emmajane> kirkland, /me shakes her fist at the proprietary money makers. ;)
[02:45] <emmajane> ok. I've plugged that in and now I'm getting no error and no results locally. Just uploading to test.
[02:54] <emmajane> kirkland, hm. same thing as locally. no results. http://tools.hicktech.com/bzr-website/
[02:55]  * kirkland looks
[02:55] <lifeless> meep
[02:55] <lifeless> I've wandered into html land
[02:56] <emmajane> lifeless, avert your eyes! :)
[02:57] <lifeless> davidstrauss: its plone you're upstream on right?
[02:58] <emmajane> davidstrauss, you're meddling in plone now too?!
[02:58] <emmajane> davidstrauss, TRAITOR :)
[02:58] <kirkland> emmajane: change <form action="search.html" id="cse-search-box">
[02:58] <kirkland> emmajane: to id="searchbox_009852948614216791564:dr5xzrczfnu"
[02:59] <emmajane> ah
[02:59] <kirkland> emmajane: and also:
[02:59] <kirkland>

[03:00] <lifeless> emmajane: no, I was confused
[03:00] <lifeless> its drupal
[03:00] <kirkland> emmajane: to

[03:00] <lifeless> I knew it was some webby thing
[03:00] <emmajane> lifeless, LOL
[03:00] <emmajane> lifeless, plone. drupal. what's the diff? ;)
[03:00] <lifeless> exactly!
[03:00]  * emmajane grins
[03:01] <lifeless> so I was going to ask
[03:01] <lifeless> what does it do for test runs; web based reporting and so on, or very console orientated?
[03:01] <emmajane> lifeless, ummm. they have a bot and a farm.
[03:02] <emmajane> there's a testing suite which has web-based reporting and updates the issue queue to say if patches passed the suite.
[03:02] <emmajane> after that I start running out of words to repeat.
[03:02] <lifeless> ;)
[03:03] <lifeless> http://drupal.org/node/394888 seems relevant
[03:03] <emmajane> sdboyer, you know the answer to that ^^
[03:03] <emmajane> chx would know too if he were around.
[03:08] <lifeless> http://testing.drupal.org/ needs more google juice
[03:09]  * emmajane nods.
[03:09] <lifeless> jelmer: http://testing.drupal.org/pifr/file/1/13019
[03:12] <emmajane> lifeless, http://drupal.org/node/162788#comment-1697272 <-- example of integration with our issues queue.
[03:12] <emmajane> not sure if you wanted to see that bit though.
[03:12] <emmajane> http://drupal.org/node/162788#comment-1770146 <-- and failures
[03:13] <lifeless> emmajane: thats nice
[03:13] <emmajane> as much as we hate our issues queue, the test bot is pretty cool.
[03:14] <lifeless> http://build.samba.org/?function=Recent+Builds;tree=samba_4_0_test uses http://launchpad.net/subunit but does its html rendering via regex and guesswork
[03:14] <lifeless> so there is a bug on subunit to have a good html reporter
[03:14]  * emmajane nods
[03:16] <emmajane> lifeless, it can be a bit brutal to track down the right test (most of the time I'm doing docs patches and it's a wonky test that needs to be fixed), but generally I find it more useful than having nothing.
[03:16] <lifeless> does it file bugs automatically?
[03:16] <emmajane> hahaha
[03:16] <emmajane> no.
[03:16] <emmajane> :)
[03:17] <lifeless> so, how do you get the integration, you just say 'test XXX' when you file it?
[03:17] <emmajane> patches don't get accepted to core if they don't pass the bot.
[03:17] <emmajane> (which is the issue queue integration part).
[03:17] <emmajane> patches that are "red" don't go in.
[03:17] <lifeless> ok
[03:17] <lifeless> so you have a queue
[03:17] <emmajane> yah
[03:17] <lifeless> and if it passes it lands
[03:18] <lifeless> and if it fails it becomes an item in the issue queue?
[03:18] <emmajane> uploading a .patch triggers the bot to run the tests.
[03:18] <lifeless> its basically a prettier PQM :)
[03:18] <lifeless> I like
[03:18] <emmajane> then you hit reload on the issue a million times and eventually the place where you uploaded your patch turns green or red.
[03:18] <spm> Am trying to debug why 'bzr launchpad-login' (in a chroot) is returning "bzr: ERROR: Connection error: curl connection error (Problem with the SSL CA cert (path? access rights?))" any suggested flags? or is strace the best bet?
[03:19] <emmajane> lifeless, "normal people" don't ever look at testing.d.o they just wait to get the results back.
[03:19] <lifeless> emmajane: so you upload the patch to the bug tracker?
[03:19] <emmajane> lifeless, yup
[03:19] <lifeless> emmajane: very nice
[03:20] <emmajane> it seems to work for us. :)
[03:20] <lifeless> emmajane: is committing to core done by the bot, or someone taking a passed item and going 'doit'
[03:20] <emmajane> lifeless, one of two humans gets to commit to core.
[03:20] <lifeless> spm: apt-get remove python-curl
[03:20] <lifeless> spm: :P
[03:20] <emmajane> lifeless, we have a status on an issue which is, "ready to be committed"
[03:20] <lifeless> spm: (don't, I'm teasing)
[03:20] <spm> lifeless: ha ha. :-)
[03:20] <emmajane> lifeless, then either Dries or $co-maintainer will commit the patch.
[03:20] <lifeless> spm: its probably ca-certificates
[03:21] <spiv> spm: what lifeless just said; is the ca-certifcates package installed?
[03:21] <kirkland> emmajane: any luck?
[03:21] <emmajane> lifeless, contrib modules are, of course, totally different and don't have a testing suite unless the developer chooses to create one (but I don't believe that's part of the testing bot's job)
[03:21] <emmajane> kirkland, no. :(
[03:21] <emmajane> kirkland, back to Bad Request.
[03:21] <spm> lifeless: spiv: huh. no it isn't. lets try that then.
[03:21] <kirkland> emmajane: where's the latest?
[03:21] <emmajane> kirkland, Just trying to figure out what I did this time. :(
[03:21] <spiv> lifeless: thinking of subunit, is it time to add --subunit to make check?
[03:21] <kirkland> emmajane: it's working for me
[03:21] <lifeless> spiv: yes!
[03:22] <emmajane> arh. wrong tab.
[03:22] <kirkland> emmajane: http://tools.hicktech.com/bzr-website/search.html?cx=009852948614216791564%3Adr5xzrczfnu&cof=FORID%3A10&ie=UTF-8&q=emma&sa=Search#881
[03:22]  * emmajane bangs her head repeatedly.
[03:22] <emmajane> kirkland, you are like a Google-god.
[03:22] <emmajane> kirkland, thank you :)
[03:22] <lifeless> kirkland: so how did you get roped into this ;)
[03:23] <lifeless> [not why, how :P]
[03:23] <emmajane> lifeless, I think I threatened to cry...
[03:23]  * emmajane is classy like that
[03:23] <lifeless> lol
[03:23] <kirkland> lifeless: heh, not sure
[03:23] <lifeless> spiv: should I submit a pycon talk; I think I have about 5 hours to do that in.
[03:23] <kirkland> lifeless: i have a couple of semi-useful google-custom-searches up and around
[03:23] <lifeless> spiv: do they do travel assistance ever?
[03:23] <kirkland> lifeless: i think poolie outed me :-)
[03:23] <spiv> lifeless: I'm afraid I don't know.
[03:23] <emmajane> lifeless, I think hypa7ia is just working on hers. :)
[03:24] <kirkland> emmajane: results, formatting look nice
[03:24] <lifeless> spiv: bah, some python god :P
[03:24] <emmajane> kirkland, I'll never tell who outed you. I need to protect my sources. :)
[03:24] <kirkland> emmajane: heh
[03:25] <kirkland> emmajane, et al: enjoy ;-)
[03:25] <emmajane> bzr commit -m "Google Search is now working. Everyone buy kirkland a $drink."
[03:26] <kirkland> emmajane: heh!
[03:26] <lifeless> drink="bombay sapphire" \1
[03:26] <lifeless> spiv: would you like to do the honours [--subunit to trunk?]
[03:27] <spiv> lifeless: do we care about normal humans that might type "make check"?
[03:27] <lifeless> spiv: lets say we don't, and if we're wrong change it again
[03:28] <spiv> Heh.
[03:28] <spiv> Fair enough.
[03:28] <lifeless> its a fairly specialised interface
[03:28] <lifeless> spiv: alternatively, we can add a variable PQM can set
[03:28] <lifeless> but that seems like a round about way if few folk run 'make check'
[03:28] <spiv> lifeless: right
[03:29] <spiv> I'm ok with "just change it", as you say it's easy to undo if it causes trouble for someone.
[03:29] <lifeless> BasicOSX: hi!
[03:30] <lifeless> BasicOSX: I need feedback from you per bug ###(I forget, check your bugmail :P)
[03:30] <BasicOSX> hello
[03:32]  * igc lunch
[03:35] <davidstrauss> lifeless: Nope, but I can put you in touch with people from Plone.
[03:36] <spm> lifeless: spiv: fyi. that did it (ca-certs) have now moved onto a different problem, but progress :-)
[03:36] <emmajane> davidstrauss, turns out lifeless just doesn't know the difference between plone and drupal.
[03:36] <spiv> spm: cool
[03:37] <emmajane> :)
[03:37] <lifeless> davidstrauss: I don't really care about plone :P I was interested in the test discussion - see what emmajane and I covered after my gaffe
[03:38] <emmajane> lifeless, oh you'll never get to live it down. ;)
[03:39] <emmajane> davidstrauss, he was asking questions about the testing suite. I invented a couple of answers which may vaguely resemble the truth.
[03:39] <davidstrauss> emmajane: :-)
[03:41] <arkanes> are the pyrex-compiled C modules covered by the test suite?
[03:41] <lifeless> davidstrauss: did you end up getting your hudson foo on ?
[03:41] <lifeless> arkanes: yes
[03:41] <arkanes> yay
[03:41] <davidstrauss> lifeless: We're using Hudson for The Economist
[03:41] <arkanes> I experimeted with compiling them using cython instead, and I ran the test suite and everything was fine, but I wasn't sure if that was a good way to exercise them
[03:41] <lifeless> davidstrauss: yeah, when I ran into you in #hudson you were setting it up I think
[03:41] <davidstrauss> lifeless: And I am in touch with the developer of Bazaar-Hudson integration
[03:42] <arkanes> well, I ran bzr selftest, is that the right thing to do?
[03:42] <lifeless> arkanes: yup
[03:42] <lifeless> arkanes: as long as you've run make build
[03:42] <arkanes> hmm
[03:42] <arkanes> I did setup.py build insteadl
[03:42] <lifeless> (setup.py build -i
[03:42] <lifeless> it the inplace thats needed if you're testing in-tree
[03:43] <arkanes> I installed first, tested later :P
[03:43] <lifeless> thats fine
[03:44] <arkanes> cython support is somethign like a 4 line patch, correct procedure is to file a bug on launchpad & attach patch?
[03:45] <spiv> lifeless:
[03:45] <spiv> -	$(PYTHON) -Werror -O ./bzr selftest -1v $(tests)
[03:45] <spiv> +	$(PYTHON) -Werror -O ./bzr selftest -1v --subunit $(tests)
[03:45] <lifeless> arkanes: doc.bazaar-vcs.org/en, developer docs are there
[03:45] <lifeless> arkanes: that said, are you making it 'work with', or 'change it to use' cython ?
[03:45] <spiv> lifeless: look ok?  I guess -v is probably irrelevant now.
[03:45] <lifeless> spiv: -v is irrelevant
[03:45] <BasicOSX> lifeless:  not seeing request for feedback, got bug number?
[03:46] <arkanes> lifeless: work with
[03:46] <lifeless> spiv: separately I'd like to discard the -1, but that may need discussion
[03:46] <arkanes> lifeless: as in, fall back to cython if pyrex is not present
[03:46] <spiv> lifeless: yes
[03:46] <lifeless> arkanes: ok, cool. We don't want to depend on cython at this point as its not as widely available as pyrex (we support python 2.4 platforms)
[03:47] <arkanes> yeah, I use cython and don't keep pyrex around so I just wanted it to work in that environment
[03:47] <spiv> lifeless: if you make the test suite fast enough I'm sure people won't mind if -1 is left off ;)
[03:48] <spiv> lifeless: ok, pqm-submitting that to bzr.dev.
[03:48] <lifeless> spiv: well most submissions should land, and most failures may have multiple things wrong with them
[03:48] <lifeless> spiv: :)
[03:55] <spiv> lifeless: talk to oubiwann about PyCon, I think he knows stuff.
[03:56] <oubiwann> lifeless: you gonna submit?
[03:56] <spiv> lifeless: also, http://pqm.bazaar-vcs.org/: Running [ 3% 552 test(s) 3 failure(s) 5 errors(s) ] ...
[03:56] <oubiwann> (tomorrow's the last day for proposals)
[03:56] <spiv> Given the -1, I guess those are skips and known failures...
[03:57] <lifeless> oubiwann: looking at the web site stuff now
[03:57] <lifeless> spiv: \o/
[03:58] <lifeless> sexy
[03:58] <oubiwann> lifeless: awesome
[03:58] <lifeless> oubiwann: I'm wondering about aid
[03:58] <oubiwann> ah, yeah
[03:58] <oubiwann> it's not granted for speakers, but speakers are encouraged to apply
[03:58] <lifeless> 'we' don't seem to know who we'll send or not, so I have to work on the basis that I may be solo if I submit
[03:58] <oubiwann> (for aid)
[04:00] <lifeless> oubiwann: are you on TIP?
[04:07] <oubiwann> lifeless: TIP?
[04:10] <lifeless> testing in python
[04:10] <lifeless> oubiwann: this is what I would submit a pycon talk about: - would you come to see it? http://rbtcollins.wordpress.com/
[04:11]  * oubiwann checks it out
[04:12] <oubiwann> lifeless: oh HELLZ YEAH
[04:15] <lifeless> oubiwann: glad you like it :)
[04:28] <lifeless> vila: aren't you meant to be sleeping?
[04:31] <lifeless> spiv: I like the pqm output
[04:31] <lifeless> feels much more usable to me
[04:31] <lifeless> do you ?
[04:50] <emmajane> beuno, just got feedback from someone who couldn't find the option to download builds on code.edge.launchpad.net/bzr. Not sure if you wanted a UI bug submitted for LP?
[05:00] <arkanes> I've got a branch I'd like to submit back to bzr but the instructions on http://bazaar-vcs.org/BzrGivingBack conflict slightly with the launchpad UI, is "lp:bzr" the correct target branch?
[05:04] <emmajane> arkanes, you'll upload things to your own workspace on LP and then submit a merge request.
[05:04] <lifeless> oubiwann: http://us.pycon.org/2010/conference/proposals/127/
[05:04] <oubiwann> lifeless: thanks!
[05:04] <emmajane> arkanes, http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html#submitting-changes this has more info
[05:04] <lifeless> oubiwann: its insane
[05:04] <spiv> lifeless: yeah, it's much nicer to have the percentage.
[05:05] <lifeless> it thinks canonical's homepage is rbtcollins.wordpress.com.  I don't know how to fix that
[05:05] <spiv> lifeless: the non-zero failure and errors are a bit alarming, though.
[05:05] <lifeless> oubiwann: ^
[05:06] <spiv> lifeless: curiously, I saw "Current test: None
[05:06] <spiv> " at one point.
[05:06] <spiv> (67% of the way through)
[05:08] <lifeless> spiv: yes, it means one test finished, the next had not started
[05:09] <spiv> Yeah, not unreasonable.
[05:09] <lifeless> oubiwann: oh, I get it.  The bio 'link' links to affiliation, not the author. BAH
[05:10] <lifeless> >bah<
[05:19] <emmajane> Stating the obvious: We don't have a .dmg for installing Explorer and we don't seem to have install instructions.
[05:19] <emmajane> (on OSX)
[05:23] <emmajane> igc, ping?
[05:24] <igc> hi emmajane
[05:24] <emmajane> igc, hey :)
[05:24] <emmajane> igc, the woman who solved the nav bar problem for me is trying to install bzr! *woot!*
[05:24] <igc> excellent
[05:24] <emmajane> she's on OSX though and keeps getting errors that are getting progressively harder for me to google.
[05:24] <emmajane> she's trying to get Explorer working
[05:25] <igc> :-(
[05:25] <emmajane> yeah
[05:25] <emmajane> do you know anything about Explorer on OSX?
[05:25] <igc> she ready needs to wait for the desktop installer to arrive
[05:25] <igc> verterok is working on it
[05:25] <emmajane> cool!
[05:25] <emmajane> will it be ready "soon" or is it a long term project?
[05:25] <igc> emmajane: installing Qt on OS X is easy
[05:26] <igc> emmajane: but PyQt is a pain in the butt
[05:26] <emmajane> she's getting errors about SIP?
[05:26] <emmajane> yeah
[05:26] <igc> igc: I have done it in the past but it wasn't fun
[05:26] <emmajane> :/
[05:26] <emmajane> that's what she's running into as well.
[05:27] <igc> it's *ready* important verterok gets that installer done - hassle him when he's next online!
 jacinembp:PyQt-mac-gpl-4.6 jacine$ python configure.py
 Traceback (most recent call last):
   File "configure.py", line 37, in <module>
     import sipconfig
 ImportError: No module named sipconfig
[05:27] <emmajane> that's as far as she got.
[05:27] <igc> emmajane: I can't remember sorry
[05:27] <verterok> emmajane, igc: hi :)
[05:28] <igc> emmajane: emailing the bzr-mac list is a good idea though
[05:28] <emmajane> verterok, hey ! :)
[05:28] <igc> hi verterok!
[05:28] <igc> I was hoping you'd pop up
[05:28] <jacine> hi! :)
[05:28]  * emmajane waves at jacine
[05:28] <igc> hi jacine
[05:28] <jacine> hi emmajane, igc ;)
[05:29] <verterok> jacine: hi
[05:29] <emmajane> jacine is a designer/themer with Drupal and fixed the nav bar. We love jacine ! :)
[05:29] <jacine> thanks for helping me get started :)
[05:29] <jacine> hi verterok
[05:29] <verterok> emmajane, jacine: here is a somewhat good step by step to get PyQt installed: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
[05:30] <emmajane> verterok, can we get this added to the OSX install instructions either on the Wiki or in the Official Docs?
[05:30] <jacine> hmm, reading
[05:30] <verterok> igc: do you know if there is requirement on a specific pyqt/qt version? (for qbzr/explorer)
[05:30] <igc> verterok: Qt 4.4 or later
[05:30] <verterok> jacine: be carefull with the version ^ I don't know if qbzr works with PyQt 4.5
[05:30] <verterok> igc: oh, ok. thanks! :)
[05:30] <jacine> ok verterok, thx
[05:31] <emmajane> verterok, jacine is involved with the Drupal design community as well. Having an .dmg would make it way easier to promote bzr within Drupal. Is the installer going to be ready "soon" for OSX? I have no idea how hard these things are.
[05:31] <igc> verterok: Qt 4.5 should be fine - that's the version on jaunty
[05:31] <verterok> emmajane: we could add this to the wiki...don't know in which place :)
[05:32] <jacine> emmajane: ya, so far this is much harder to get running compared to CVS ;)
[05:32] <emmajane> verterok, http://bazaar-vcs.org/QBzr ?
[05:32] <emmajane> jacine, hehe
[05:32] <emmajane> jacine, y'think? ;)
[05:32] <jacine> hehe, and I have Xcode ;)
[05:32] <emmajane> verterok, and http://doc.bazaar-vcs.org/explorer/en/install-osx.html ?
[05:33] <verterok> emmajane: thanks to jfroy that showed me an alternative way of building the packages I think it's going to be easier than using the previous approach...but I still need to get it working ;)
[05:33] <emmajane> I had igc 's branch downloaded and ready to update the docs and then we just kept getting more nad more errors.
[05:33] <emmajane> \o/
[05:33] <emmajane> easier is gooder :)
[05:36] <verterok> emmajane, jacine: I'll work on this tomorrow, probably for OS X 10.5 first as I'll have access to my 10.4 ibook probably during the weekend
[05:36] <jacine> cool
[05:36] <emmajane> verterok, awesome. thank you! :)
[05:37] <emmajane> igc, search is working thanks to kirkland and the nav bar is working thanks to jacine :)
[05:37] <jacine> hehe ;)
[05:44] <igc> emmajane: that's great news - well done
[05:45] <emmajane> :)
[05:45] <igc> verterok: I'm happy to test your installer on 10.4 when it's ready
[05:46] <emmajane> I think jacine said she's on OSX?
[05:46] <emmajane> erg 10.5 rather
[05:46] <emmajane> <--- tired bear
[05:46] <jacine> yeah, 10.5 :)
[05:46] <igc> emmajane: must be time for some sleep soon :-)
[05:46] <emmajane> igc, yeah. the anticipation of Explorer almost working for jacine is keeping me up :)
[05:47] <jacine> haha ;) well, I'm gonna make it happen emmajane!
[05:47] <emmajane> WOOT!
[05:48] <igc> emmajane: another minor thing: the Bazaar logo is being clipped in ff 3.0 on jaunty. Can you move it right a bit?
[05:48] <emmajane> igc, it's probably easier just to make the text smaller?
[05:48] <igc> maybe left-align it with the Home area in the nav bar?
[05:49] <emmajane> it should have loads of room though. hm
[05:50] <emmajane> http://browsershots.org/screenshots/f8ab0781362b8fc8e1920f59c3cac3c4/ <-- from earlier tonight
[05:50] <emmajane> igc, is it your fonts?
[05:51] <emmajane> OOOoo. logo, not text.
[05:51] <emmajane> how wide is your browser?
[05:51] <igc> emmajane: how can I easily tell?
[05:51] <emmajane> is it basically the width of the page?
[05:51] <emmajane> the design rather
[05:52] <emmajane> I shifted the logo to the left so that it pointed into the middle of "home"
[05:52] <igc> emmajane: there's no horinzontal scrollbar fwiw
[05:52] <emmajane> but on narrower screens the amount of shift can be clipped.
[05:53] <kirkland> emmajane: \o/
[05:53] <emmajane> kirkland, :)
[05:53] <emmajane> kirkland, again, you rock! :)
[05:54] <igc> emmajane: I'm on 9.04 btw
[05:55] <emmajane> igc, I'm 9.04 FF 3.0.14.
[05:55] <emmajane> igc, if you make your window a tad wider, does the clip go away?
[05:55] <emmajane> I just want tomake sure I'm solving the right problem. :)
[05:55] <igc> emmajane: wider fixes the problem
[05:56]  * emmajane nods
[05:56] <igc> emmajane: it is truly center aligned with "Home" - that just is too far left
[05:56] <emmajane> let me add +30px to Home and leave the logo where it wants to be.
[05:57] <igc> emmajane: left-aligned with the text below will look better
[06:01] <emmajane> igc, uploaded
[06:01] <igc> emmajane: fixed. Thanks!
[06:02] <emmajane> awesome!
[06:02] <emmajane> igc, I saw your note about the news too
[06:02] <emmajane> I'm not loving it at the bottom, and don't mind if the headlines are in the banner space.
[06:02] <igc> emmajane: ah good
[06:03] <igc> emmajane: poolie wants it to look like news though
[06:03] <emmajane> i'm still feeling a bit gunshy about posting things to the list after the stuff last week.
[06:03] <igc> emmajane: so it needs a box and maybe some little news icon to highlight it if we move it there
[06:03] <emmajane> bleh
[06:03] <emmajane> dancing monkeys! :)
[06:03] <igc> emmajane: wecome to my world :-)
[06:04] <emmajane> lol
[06:04] <igc> emmajane: open source development isn't kind on the ego :-)
[06:04] <emmajane> igc, we still have some of the designer's time if you wanted me to ask him to solve it. but more direction is better than "be creative" ;)
[06:04] <emmajane> igc, heh. y'think? :)
[06:04] <igc> emmajane: there's a new critic every day!
[06:05] <igc> emmajane: I think we need approval in principle from poolie first
[06:05]  * emmajane nods
[06:05] <emmajane> there is time left there, so don't feel that you or I *needs* to solve it. :)
[06:06] <emmajane> to my eye I want the text on the left to be bigger so taht the news isn't lonely on the bottom right.
[06:06] <emmajane> I wanted to keep the logos as a divider/end of page summary (which is why I took them out of the left side)
[06:07] <emmajane> bigger/longer/other
[06:07] <emmajane> (for left text)
[06:08] <igc> emmajane: maajane: bumping the LHS up a text size is worth a try - it may stand out more then
[06:08] <igc> typo sorry
[06:08] <emmajane> kay
[06:15] <igc> bbiab
[06:15] <emmajane> hrm. if I do that the headings don't line up nicely. /me plays more
[06:16] <spm> beating my head against the brickwall here. "bzr: ERROR: Connection error: Unable to authenticate to SSH host as" AFAICT, we have the right ssh setup and all; but clearly not. Suggested places I could/should be looking?
[06:17] <spiv> As a bzr error?  I guess that means it's using paramiko...
[06:17] <spiv> I'm a bit surprised its not using OpenSSH.
[06:17] <spm> spiv: yeah, bzr info bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/ by way of example
[06:18] <spiv> Not that it should matter either way.
[06:18] <spm> spiv: ahhh. are you implying that's a different package we're missing? I don't have ssh (the binary) in this chroot so... ?
[06:19] <spiv> Well, bzr will happily enough fallback to paramiko if /usr/bin/ssh doesn't exist.
[06:19] <spiv> And judging from that error it appears to be doing so just fine.
[06:19] <spiv> But presumably it's trying either the wrong username and/or key.
[06:19] <spm> oh I dunno - it doesn't read as "happy" to me. fallback sure. ;-)
[06:20] <spiv> The 'fallback-to-paramiko' part is happy.  That doesn't mean that the rest of it is ;)
[06:20] <spm> heh
[06:21] <spm> so is the paramiko side going to be doing the right ~/.ssh/config bits? or... ?
[06:21] <spm> should i be adjusting in ~/.bazaar/authentication.conf ?
[06:22] <spiv> I think it'll prefer authentication.conf
[06:22] <spiv> I'm not sure if it will try use ~/.ssh at all.  I'm not very familiar with what config paramiko uses.
[06:22] <emmajane> igc, the bigger font size on LHS ends up being distracting.
[06:23] <spiv> (or our glue for it)
[06:23] <jacine> igc: verterok, emmajane!  got it! :)  Thank you so much!
[06:23] <emmajane> jacine, WOO! :)
[06:23] <spm> hmmm. 'k.
[06:23] <jacine> yay ;)
[06:23] <spiv> I'd be inclined to just install openssh-client, personally, because I know the config for that quite well :)
[06:23] <lifeless> paramiko doesn't use the ssh config, does it ?
[06:24] <emmajane> jacine, let me know what can be added where to make the instructions easier. I'm not sure if the installer will include everything verterok ?
[06:24] <jacine> emmajane: actually, this was perfect: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
[06:24] <spiv> lifeless: I don't *think* so, but I'm not at all sure.
[06:24] <emmajane> jacine, cool!
[06:24] <lifeless> ok, benefits of starting at 0630; gnight :)
[06:24]  * lifeless waves ciao
[06:24] <jacine> emmajane: i think we would just need to pull the other parts in...
[06:24] <spm> spiv: heh; from what I can see, the only missing piece'd be the specifying of the IdentityFile, as it's not the default
[06:24] <spm> night lifeless
[06:25] <spiv> lifeless: move to NZ already :P
[06:25] <spiv> lifeless: g'night :)
[06:25] <jacine> emmajane: gonna save the links and summarize what I did before that part and send it to ya... after I create a test project.
[06:25] <emmajane> jacine, awesome. I'm going to update the wiki right now to add that URL.
[06:26] <spm> spiv: ARGH. cp id_rsa-ODDNAME id_rsa and same for the .pub == success. ARGH.
[06:29] <emmajane> jacine, I updated the wiki to include that URL.
[06:29] <jacine> where is the wiki, sorry, tab overload here...
[06:30] <emmajane> http://bazaar-vcs.org/QBzr
[06:30] <jacine> thanks :)
[06:30] <emmajane> np
[06:32] <emmajane> verterok, https://twitter.com/joncruz/statuses/4518006753 <-- you've got volunteers to help with the installer. :)
[06:36] <emmajane> ok. sleep f'reals this time.
[06:37] <jacine> emmajane: I'll e-mail u a link to what I'm writing
[06:37] <jacine> thanks again for everything :)
[06:37] <jacine> u guys rock!
[06:37] <emmajane> jacine,  thanks for stickign with it. very very very much appreciated.
[06:37] <jacine> ;)
[06:38] <emmajane> jacine, also? thanks for fixing the nav bar. very^3 appreciated. :)
[06:38] <jacine> anytime emmajane :)
[06:38] <emmajane> :)
[06:38] <emmajane> don't be making offers like that ;)
[06:38] <jacine> hehe ;)
[08:04] <bialix> hello bzr
[08:05] <Peng_> Hi
[08:39] <poolie> hello all
[08:40] <poolie> hi jelmer?
[08:52] <bialix> hi poolie
[08:53] <poolie> hello bialix
[08:53] <bialix> poolie: as I understand big announce is delayed so I'm planning to release qbzr 0.14.3 soon
[08:54] <bialix> there is several important bug fixes
[08:54] <bialix> I hope jam won't object to build another installer
[08:54] <poolie> ok
[08:55]  * bialix hopes there is still possible to update packages in Karmic
[08:57]  * igc dinner
[08:57] <poolie> sorry, back into meetings...
[08:57] <poolie> bialix: with bug fixes, yes
[08:58] <bialix> good
[10:06] <jelmer> poolie: hi
[10:13] <poolie> hi jelmer
[10:29] <StyXman> I have an original branch/repo where I've been commiting all my changes so far. now I setup a project in savanah, which gives me a bazaar repo, and I intend to import all the history there. should I branch the savannah repo, then pull from my repo into this branch, and then push into savannah? did I get it right?
[10:32] <Peng_> StyXman: Just push to Savannah from your original branch.
[10:36] <naoki> hi jelmer
[10:37] <jelmer> hi naoki
[10:37] <naoki> jelmer: I can branch from git:// on Windows!  https://bugs.launchpad.net/bzr-git/+bug/382125/comments/10
[10:38] <naoki> I attached quick fix patch. Please confirm.
[10:41] <naoki> I think bzr-git may be a killer-app for bzr on Windows, because git on Windows requires msys or cygwin. Gread job! jelmer.
[10:51] <bialix> naoki: cool! \o/
[11:30] <jelmer> naoki: thanks
[11:31] <jelmer> naoki: couldn't we just eliminate that assert ?
[11:37] <naoki> jelmer: I tryed it, but next line also uses  "self.index"
[12:01] <jelmer> naoki: any chance you can try with current trunk?
[12:01] <jelmer> I've pushed an alternative fix
[12:08] <naoki> OK!
[12:08] <naoki> It works!
[12:11] <jelmer> naoki: great :-)
[12:11] <jelmer> naoki: what about the other warning?
[13:06] <jelmer> naoki: ?
[13:16] <SamB_XP> jelmer: you really need to get together with whoever does the bzr nightly PPA and figure out what's going on with bzr-doc ...
[13:24] <jelmer> SamB_XP: ? The PPA's are only for Ubuntu aren't they?
[15:21] <abentley> jam or vila: Where is the 2.0.0 branch?  I can't find it on https://code.edge.launchpad.net/~bzr-pqm/ or bazaar-vcs.org/bzr
[15:21] <jam> abentley: all pqm branches are now on launchpad
[15:21] <jam> 2.0.0 is ~bzr-pqm/bzr/2.0.0
[15:22] <jam> 2.0 stable is ~bzr-pqm/bzr/2.0
[15:22] <jam> trunk is ~bzr-pqm/bzr/bzr.dev
[15:23] <abentley> jam: Oh, I guess 2.0.0 is hidden because it's been merged into 2.0.
[15:23] <abentley> jam: Thanks.
[15:24] <jam> abentley: ah hidden from the main view?
[15:24] <jam> thats a shame
[15:24] <jam> given that we fully intend to continually 'merge up'
[15:24] <jam> 2.0.0 => 2.0 => bzr.dev
[15:25] <abentley> jam: Yeah.  I'm marking it as "development", which a new commit would do anyway.
[15:25] <jam> I'm pretty sure we don't expect another commit on 2.0.0
[15:26] <abentley> jam: I think the same thing won't happen to 2.0, because it's associated with a series.
[15:27] <abentley> jam: getting perfect rules for this stuff is hard...
[15:27] <jam> yeah
[15:30] <macflag> does bzr support database version control?
[15:31] <abentley> jam: The significance of 2.0.0 isn't the fact that it may or may not be under development, it's the fact that it corresponds with a release.
[15:31] <jam> abentley: yeah, but I think lp only has that for a series, right?
[15:31] <jam> macflag: not explicitly, though you can certainly version your sql dumps
[15:31] <abentley> jam: Right.
[15:31] <arkanes> so when I do "bzr pull" and there's some merges, is there a trivial option I can pass to bzr diff that's basically "diff this and the branch it was before I just updated", or do I have to look back and figure out what revision number that was?
[15:31] <macflag> jam: how economical and accurate is that?
[15:32] <arkanes> macflag: versioning databases is hard because they're running images, not something you can update with a textual diff
[15:32] <abentley> arkanes: I don't think there's a direct way, because we don't keep a record of what pull did.
[15:33] <arkanes> abentley: yeah I figured. i just do this so often, looking at the files changed in a pull and then wanting to know what got merged.
[15:33] <macflag> arkanes: i'm working with reasonably small databases, does this change your answer?
[15:33] <arkanes> macflag: not really
[15:34] <abentley> arkanes: You want to know which of your local changes were merged?
[15:34] <arkanes> macflag: the nature of a database is that it's a running image that you modify in place, rather than traditional development where you build something from an authorative source
[15:34] <arkanes> abentley: I don't have local changes, it was just updates from the pull
[15:35] <abentley> arkanes: When you say "wanting to know what got merged", what's an example of something that might have been merged?
[15:36] <arkanes> abentley: well in this specific case i updated by bzr.dev branch
[15:36] <macflag> arkanes: yeah i know, but *theoretically* there must be some format or "instantiation" to which i can convert a database, which is more suited for running diffs against, or am i wrong?
[15:37] <arkanes> and there was a change to doc/developers/HACKING.txt and I'm curious to know what that was, since I just started contributing
[15:37] <arkanes> macflag: sure, the sql dumps
[15:37] <Lo-lan-do> macflag: SQL dumps could be that, if you added something to guarantee that rows always get out in the same order.
[15:37] <arkanes> macflag: but without the cooperation of the database itself, and some smart diff tools (since a simple textual diff won't do), it can be awkward and error prone to do it
[15:38] <arkanes> macflag: if you're using an embedded database like sqlite, just sticking the binary DB file in there works too
[15:38] <abentley> arkanes: So I think you care about changes, not just merges.  Hmm, we've been talking about adding diff support to pull for ages, but it looks like that hasn't been done.
[15:39] <arkanes> abentley: sorry, yes, I want to know what changed, not specifically was merged
[15:39] <arkanes> I said merge because there was an M next to the file name :)
[15:39] <abentley> arkanes: You can always do "bzr pull -c $REVISION" where $REVISION is the one that modified HACKING.
[15:39] <abentley> arkanes: Sorry, diff -c ...
[15:39] <macflag> arkanes: i am not familiar with bzr, so by "embedded" do you mean bzr has such sqlite support?
[15:40] <arkanes> macflag: no
[15:40] <arkanes> macflag: sorry, getting a little misleading
[15:41] <arkanes> macflag: sqlite is a self-containted database, there is no server, so the single datafile contains the entire thing and versioning it as a binary file is sufficient to version the database
[15:42] <arkanes> it sounds like thats not what you're using though so don't get derailed :)
[15:42] <macflag> :)
[15:42] <arkanes> abentley: hmm it looks like -c is basically exactly what I want
[15:43] <macflag> arkanes: just curious, is "diff-able database support" something that we can expect vcs's to start to feature any time soon?
[15:43] <arkanes> maybe it should default to your current revision instead of making you look it up
[15:43] <arkanes> macflag: not really
[15:43] <macflag> arkanes: no demand, or too difficult?
[15:43] <arkanes> macflag: it's something that the database vendors need to start with, and they could use a vcs engine like BZR to implement
[15:43] <abentley> arkanes: Cool.
[15:44] <arkanes> yeah it gave me the diff I wanted
[15:44] <macflag> arkanes: so the answer is "it's not what vcs's are supposed to do", right?
[15:45] <arkanes> it's more that the way database engines are built makes them unsuitable for versioning by generic VCS tools
[15:46] <Meths> At the end of the day if you want to version control the DB schema you just version control a SQL create script.  If you want to version control data, that's what backups are for.
[15:46] <arkanes> versioning running objects in memory is a very different problem than versioning a filesystem tree
[15:47] <arkanes> document based stuff like couchdb should be more amenable
[15:47] <lifeless> abentley: would 'mature' work (for 2.0.0 ?)
[15:47] <lifeless> davidstrauss: bug 276449, if you could comment that would be great
[15:47] <macflag> is any other vcs system equipped for database versioning any better than bzr?
[15:47]  * lifeless crashes
[15:47] <abentley> lifeless: I don't remember the implications, but it's easy to find out.
[15:48] <Meths> macflag: Firstly you haven't defined "database versioning" - schema, data or both.
[15:48] <macflag> Meths: both
[15:49] <abentley> lifeless, jam: Mature looks like a good status for 2.0.0
[15:49] <Meths> macflag: Secondly all VCSs are pretty much the same, they can all version a SQL script but none will version a binary blob.
[15:50] <abentley> Meths: Most VCSes will version a binary blob, they just can't diff it.
[15:50] <Meths> macflag: So either use the DB backup system for your database to create backups at version changes (or whenever you need them) or dump the SQL at various intervals
[15:51] <macflag> Meths: also, what about data only?
[15:51] <Meths> abentley: ah, true
[15:51] <Meths> macflag: data can be dumped or backed up
[15:52] <Meths> macflag: It's data that takes you to dumping or backing up for the "both" scenario too
[15:52] <macflag> Meths: so i guess dealing with dumped data only would be absolutely fine, right?
[15:52] <macflag> Meths: actually i don't need to deal with both
[15:54] <Meths> macflag: Depends, the biggest issue with database versioning is that data for a new schema won't easily load back into an old schema, so versioning independently is just one big headache - hence all DBMSs support backups and none (AFAIK) support version control
[15:55] <macflag> Meths: for example, when / how often does mediawiki generate a new schema?
[15:55] <Meths> no idea, read their release notes
[15:56] <macflag> not so often i think, so i guess i could deal with such steps manually
[15:56] <macflag> and then i could stick to dumped data diffing
[16:01] <Lo-lan-do> When merge requests are sent to the bzr devs, they go to a pqm, right?
[16:04]  * Lo-lan-do thinks his 2009-05-07 patch should be either accepted or rejected
[16:04] <macflag> Lo-lan-do: what's the third option?
[16:05] <Lo-lan-do> Apparently, "simply ignored".
[16:07] <Lo-lan-do> I'm tempted to add "presumed forgotten".
[16:07] <luks> that's quite popular option, unfortunatelly
[16:10] <Lo-lan-do> I thought pqm was there to keep track of merge requests?
[16:10] <abentley> Lo-lan-do: No, merge requests are tracked on Launchpad.
[16:10] <abentley> Lo-lan-do: PQM simply performs the merge when it's been approved.
[16:12] <Lo-lan-do> Ah, got it wrong then.  But my bundle sent to the list was forwarded to Launchpad though, right?
[16:13] <abentley> Lo-lan-do: No.  It would hopefully be tracked in bundle buggy, but that's not being used anymore.
[16:14] <Lo-lan-do> O-kay, so the bundle's status *is* "forgotten".
[16:15] <abentley> Lo-lan-do: Yes.  If you look at the list of unreviewed stuff on Launchpad, it's pretty short: https://code.edge.launchpad.net/bzr/+activereviews
[16:16] <Lo-lan-do> I see.
[16:17] <Lo-lan-do> I guess I'll rebase onto trunk and send a new bundle then.
[16:18] <abentley> Lo-lan-do: Sure.  You'll want to use<EMAIL_ADDRESS>as the address and specify the branch on launchpad you want to merge into.
[16:19] <abentley> Lo-lan-do: I recommend lp:bzr
[16:21] <Lo-lan-do> Will do.  Currently converting the local branch to 2a, which seems to take some time.
[16:29] <abentley> james_w: I am making a custom "distribution" of bzr 2.0.0 with 4672:lp:/bzr/2.0 applied.  I am having trouble setting up the right version numbering so that zc.buildout likes it.  Any ideas?
[16:33] <jam> spiv: are you still around?
[16:37] <james_w> abentley: afraid not, I've never used buildout
[16:40] <jam> abentley: it seems to me that if you just did a custom 2.0.1b1 or rc1 would be easier
[16:40] <jam> take the current 2.0 branch, and package it
[16:42] <abentley> james_w: It installs packages using the standard setup.py foo.  I just don't know if it's appropriate to change bzrlib.version_info to (2, 0, 0, 'launchpad', 0) or what.
[16:42] <james_w> I think bzr will reject that
[16:43] <james_w> you could tweak the last number, but that may not be enough
[16:43] <james_w> you could make it (2, 0, '0lp', 'release', 0)
[16:43] <james_w> but that might not sort correctly
[16:43] <abentley> james_w: What's the right way to tweak a package number that has distro-specific changes?  Where your target version number is something like 2.0.0-ubuntu-1 ?
[16:44] <james_w> we don't tweak the version in setup.py
[16:44] <james_w> we just do it from the package version number
[16:44] <jam> abentley: if you look it bzrlib.__init__.py _format_version_tuple
[16:44] <jam> we only support 'alpha' 'beta' 'final' 'dev' and 'candidate' in that field
[16:45] <jam> all others must be pure integers ('%d' formatting)
[16:46] <jam> so I would recommend "2.0.1a1" if that works best for you
[16:50] <abentley> jam: Okay, I'll give that a go.
[16:52] <abentley> jam: Would deprecation warnings be suppressed for an alpha?
[16:52] <jam> abentley: no
[16:52] <jam> only for 'final'
[16:52] <jam> bzrlib.commands.main:
[16:53] <jam> # Is this a final release version? If so, we should suppress warnings
[16:53] <jam> if bzrlib.version_info[3] == 'final':
[16:53] <jam>     suppress_deprecation_warnings(override=False)
[16:53] <jam> though I've noticed that it doesn't actually work with python2.6, because something on my path is also adding a deprecation warning
[16:53] <abentley> jam: *facepalm*
[16:53] <jam> so you actually need "override=True".
[16:55] <poolie> hi jam, abentley
[16:56] <abentley> poolie: Hi.
[16:59] <jam> hi poolie
[17:03] <abentley> jam: I think I'm going to replace bzrlib.__version__ with '2.0.0-lp-1' in setup.py.
[17:08]  * Lo-lan-do ponders adding a --no-remember option to bzr push
[17:09] <Lo-lan-do> Would that have a chance of being accepted?
[17:10] <abentley> Lo-lan-do: bzr already has a --no-remember option.
[17:10] <jam> abentley: though I don't think we pay attention to it...
[17:11] <jam> in the case that there is no current default push location, it always gets set
[17:11] <jam> Lo-lan-do: you could probably turn the 'remember' field into a tri-state boolean (True, False, None)
[17:11] <jam> whatever you would call that other than boolean .. :)
[17:12] <jam> Lo-lan-do: or are you looking for a --forget option?
[17:12] <abentley> jam: We pay attention to it, it just disables a previous --remember.
[17:13] <jam> abentley: I just mean that internally --no-remember is equivalent to not passing --remember
[17:13] <jam> which is different than saying "don't remember this path even though there is nothing already set"
[17:13] <jam> if you change the run(..., remember=None) then we can tell the difference
[17:14] <abentley> jam: Sure.  I did write the code that adds those hidden inversion options.
[17:15] <abentley> jam: When it gets up to trinary, I usually use strings: "yes", "no", "auto".
[17:19] <Lo-lan-do> Sorry, my mum chose this particular moment to phone :-)
[17:19] <vila> abentley: Isn't it ternary ? I ask before I jokingly use tri-lean in French as opposed to boo-lean...
[17:20] <Lo-lan-do> I was thinking of making the remember a tristate, yes, *and* getting it not ignored when no default is set.
[17:21] <Lo-lan-do> But a --forget option would be nice, independently.
[17:21] <abentley> vila: It looks like ternary is preferred, but both are used.
[17:22] <vila> but otherwise, I've a strong preference for True, False, None myself as the extended boolean, because it perfectly matches to "I know it's true, I know it's false or I don't know"
[17:22] <vila> abentley: thks
[17:23] <abentley> vila: If None didn't evaluate to False in python, that would be okay with me, but I think explicit description of behavior is clearer.
[17:25] <vila> abentley: good point, my coding style generally compensates  that by using 'if xx is None' before attempting 'if xx'
[17:28] <Lo-lan-do> How long does it usually take for merge requests to show up on https://code.launchpad.net/bzr/+activereviews ?
[18:28] <jam> Lo-lan-do: usually fairly close to immediate, I believe
[18:29] <jam> are you sure you had the right submission target?
[18:30] <Lo-lan-do> I used "bzr send --mail-to<EMAIL_ADDRESS>lp:bzr"
[18:31] <Lo-lan-do> (As suggested by abentley)
[18:40] <jam> Lo-lan-do: I have very little clue about merge-by-email, I always just push a branch up and click the "propose this branch for merging" link.
[18:41] <jam> poolie: poke on https://code.edge.launchpad.net/~jameinel/bzr/2.0-cache-cix/+merge/11465
[18:42] <jam> that, and you seem to have 2 branches 'approved for merging" on the active reviews page
[18:42] <_oggy> hi, i need to interface with an svn repo. the repo uses svn:externals. i know that up until a few months ago, bzr (and hence bzr-svn) didn't support nested trees. with 2.0 out, what's the current status of that?
[18:42] <Lo-lan-do> jam: I guess I could push my branch, but I don't see a link to propose it for merging.
[18:43] <jam> if you look on my page: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple
[18:43] <jam> Branch Merges
[18:43] <jam> Propose for merging
[18:44] <jam> about in the middle of the page, towards the left
[18:44] <jam> though you may not see it for *my* branches
[18:45] <Lo-lan-do> Oh, so it needs to be on Launchpad?
[18:46] <Lo-lan-do> I mean, I can't propose to merge a branch hosted elsewhere?
[18:46] <jam> Lo-lan-do: well, you can have lp mirror it, but Launchpad certainly needs to know about it
[18:46] <jam> I think you can register the branch to launchpad, and then propose it from there
[18:47] <Lo-lan-do> I guess I'd need a Launchpad account anyway.
[18:47] <jam> Lo-lan-do: you'd have to ask abentley for more info about sending requests by mail. I believe he does so regularly, I've *never* done so
[18:47] <jam> Lo-lan-do: ah, I think you need to gpg sign your merge request with a key that LP recognizes
[18:47] <Lo-lan-do> I'd rather stick with emails, yes.
[18:47] <jam> so you still need an account for email access
[18:48] <jam> so if you'd rather
[18:48] <jam> send it to me, and I'll propose it
[19:12] <poolie> hi jam, Lo-lan-do
[19:12] <poolie> jam, poke for a review?
[19:13] <poolie> ok, though probably not tonight :/
[19:13] <jam> poolie: yeah, its been sitting there for ~1month
[19:13] <poolie> sorry
[19:13] <jam> someone else can do it, but I thought we wanted it in the 2.0.x series
[19:13] <poolie> we should also have a look at moving reviews from bb
[19:13] <jam> and I thought you explicitly requested it, thus I wanted to give you first dibs at reviews
[19:13] <poolie> or finishing them off
[20:54] <bialix> hello jam
[20:57] <jam> hi bialix
[20:59] <bialix> jam, I'm planning to release qbzr 0.14.3 very soon. In particular there is important bug fix for TBZR users (bug #433137). I'd like to know is you keen to build new installer or I should strongly suggest to windows people upgrade via qbzr installer
[21:02] <bialix> anybody knows does 'root:' revision id is supported inside bzrlib or this is unrelated to bzrlib?
[21:02] <jam> bialix: I believe "root:" is a generic file id for loggerhead indicating the root of the tree, but I'm not positive
[21:02] <jam> I'll build an installer if this is serious enough
[21:03] <jam> though I wonder about getting bugfixes in to the 2.0.1 release, rather than forcing everything into the 2.0.0-XXX releases
[21:03] <bialix> jam: well, we have several duplicates of this bug already
[21:03] <bialix> maybe 2.0.1 is better
[21:04] <bialix> maybe
[21:05] <bialix> I hope website stuff will be released soon, so 2.0 will go out officially
[21:06] <bialix> but https://launchpad.net/bzr/2.0 does not provide any hints about ETA for 2.0.1
[21:07] <jparker1> the release notes for 2.0 mention an "upgrade guide"; where is this?
[21:08] <jam> bialix: official position is "when reasonable based on bugfixes landed in 2.0.x branch", but something like 1 month post 2.0.0, though again we are having difficulties getting 2.0.0 official announced
[21:09] <bialix> jparker1: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
[21:09] <jam> jparker1: note that on http://doc.bazaar-vcs.org/latest/en/ there is a Search box
[21:09] <bialix> jam: official position is related to bzr core I suppose, right?
[21:09] <jam> i believe it is the approved statement in 'cycle.txt'
[21:13] <bialix> jam: any way I will build qbzr installer.
[21:29] <idnar> argh
[21:30] <idnar> do I have to add a new entry to locations.conf to override a more general one?
[21:30] <idnar> I was hoping I could just do eg. bzr push --remember <differentlocation>
[21:35] <hsn> how do i resolve Conflicting tags issue during push?
[21:38] <awilkins> Anyone tell me an editor that doesn't append a line terminator to the last line?
[21:39] <hsn> vim?
[21:40] <awilkins> Nope. vim, gedit, and nano all seem to append line terminators where there were none before... trying to edit "location" in a transplanted lightweight checkout
[21:40] <awilkins> But it doesn't like the linefeed
[21:41] <awilkins> Appears the answer to my question is "cat"
[21:42] <awilkins> cat > location
[21:42] <awilkins> file:///home/adrian/branch/location^D
[21:43] <fullermd> I woulda gone with `echo -n` myself.
[21:43] <awilkins> I remember using that before too
[21:43] <hsn> vim: help endofline ->  When writing a file and this option is off no <EOL> will be written for the last line in the file.
[21:43] <fullermd> Though I think vim has a....   yeah, what hsn said.
[21:43] <awilkins> hsn: I don't actually believe it though, did you read all the caveats in that
[21:44] <awilkins> I don't think I got it to work
[21:44] <awilkins> I remember wrestling with it
[21:45]  * awilkins tries again
[21:45] <fullermd> I've never tried using it, so it may be harder than it sounds.
[21:46] <fullermd> Alternate crazy solutions include editing with $WHATEVER, then using dd or head to cut off the \n  ;)
[21:47] <brmassa> guys, im getting bzr: "ERROR: Permission denied: "/bazaartest": [Errno 13] Permission denied"
[21:48] <brmassa> what should i do?
[21:48] <hsn> sudo
[21:49] <brmassa> hsn: is it for me?
[21:49] <awilkins> Aha, you have to pass -b to vim
[21:49] <awilkins> Then it automatically remembers the no-line-endingness
[21:53] <brmassa> ??
[22:00] <antoranz> Hi, guys!
[22:01] <antoranz> why doesn't bzr ask for ssh password (using bzr+ssh or sftp) on windows?
[22:02] <antoranz> it says that the only available methods to authenticate are password and keys.... but it doesn't ask for the password in the first place
[22:08] <bob2> sure the remote server supports paassword auth?
[22:09] <SiDi> Hi there
[22:09] <antoranz> well.... yes, I can login (server asking for the password) on that hohst by ssh
[22:09] <SiDi> Is there a method to allow people to code without them to have an account with an actual shell defined ?
[22:10] <SiDi> s/to code/to push code/
[22:10] <antoranz> when it fails, bzr says: supported auth types: ['publickey', 'keyboard-interactive']
[22:17] <antoranz> also, ssh password authentication works like a charm if I run bzr from a GNU/Linux box against that ssh server
[22:19] <awilkins> SiDi: If you set their shell to /bin/false in the /etc/passwd file that will prevent them using a shelll
[22:20] <awilkins> Or not .... http://www.semicomplete.com/articles/ssh-security/
[22:21] <SiDi> awilkins: but that'll break bzr+ssh:// :/
[22:21] <bob2> look in the contrib dir in the bzr source
[22:22] <SiDi> will do, thanks
[22:22] <awilkins> Which, /bin/false, or setting AllowGroups?
[22:23] <awilkins> /bin/false shouldn't break bzr+ssh:// AFAIk
[22:32] <awilkins> Ok, it does
[22:32] <awilkins> I'm an idiot
[22:34] <SiDi> awilkins: if it can make you feel better, i discovered it did by constating it
[22:45] <abentley> awilkins: bzr+ssh runs bzr on the remote machine.  That's all it needs to be able to run.
[22:54] <lifeless> moin
[23:08] <lifeless> davidstrauss: bug 276449, if you could comment that would be great
[23:26] <davidstrauss> lifeless: Sorry, that's pretty ancient
[23:26] <davidstrauss> lifeless: I'd have to contact that (former) client to get a copy
[23:37] <tolstoy> Are the loggerhead devs here?
[23:37] <tolstoy> Any reason loggerhead doesn't work using bzr 2.0?
[23:38] <tolstoy> AttributeError: 'module' object has no attribute 'ProgressBarStack'
[23:43] <igc> morning
[23:46] <tolstoy> Hm. Looks like something changed in bzrlib 2.0 that broke loggerhead.
[23:48] <lifeless> davidstrauss: no worries
[23:48] <lifeless> davidstrauss: I've closed it
[23:50] <zsquareplusc> tolstoy: i think launchpad uses bzr 2.0 and loggerhead. there should be a working version i'd guess
[23:51] <tolstoy> zsquareplusc: I was trying to pull down the latest, but I think I see where I messed that up.
[23:52] <lifeless> mwhudson: ^
[23:53] <mwhudson> tolstoy: what version of loggerhead are you using?
[23:53] <tolstoy> No idea.
[23:53] <mwhudson> tolstoy: i thought the latest release had the fix for that, certainly loggerhead trunk does
[23:53] <tolstoy> I think I have a "real" copy somewhere, and my running copy syncs with that, so I just need to figure out what directory I'm in. ;)
[23:53] <tolstoy> mwhudson: I'll see what I can pull.
[23:54] <tolstoy> Now on version 345, which is promising.
[23:55] <tolstoy> Oh, wait, that's not right. That's the one I already have.
[23:55] <tolstoy> Is this the right repo? http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/
[23:58] <tolstoy> mwhudson: The last revision I can see is May 13, 2009. That can't be right.
[23:58] <mwhudson> oh right
[23:58] <tolstoy> Did the repo change?
[23:58] <mwhudson> tolstoy: loggerhead trunk is now http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich
[23:58] <mwhudson> tolstoy: we upgraded to 2a


[02:59] <bdx> does juju big-data have its own irc channel?
[03:00] <bdx> do the big data charms offer a way to decouple hdfs and hadoop?
[03:57] <bdx> http://docs.ceph.com/docs/kraken/cephfs/hadoop/ < anyone looked into this
[06:39] <kjackal> hi bdx, this is the channel for big data charms as well. kwmonroe is leading the big data effort.
[06:41] <kjackal> bdx: the abstraction hadoop processing offers over the storage solution is included in the slave+namenode node of the hadoop processing bundle
[06:42] <kjackal> bdx: would you be interested in cephfs as an alternative?
[06:44] <kjackal> bdx: you might want to make this an official request by opening a feature request issue against the hadoop processing bundle or just send an email to the juju list
[07:37] <kjackal> bdx: just saw you already brought that to the list. Thank you
[07:57] <armaan> jamespage: Hello, I am hitting this bug: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1684040
[07:57] <mup> Bug #1684040: "Missing relations: network-service" is not covered in metadata nor documentation <OpenStack neutron-gateway charm:New> <https://launchpad.net/bugs/1684040>
[07:57] <armaan> Mitaka + Trusty environment
[08:00] <jamespage> armaan: do you have the relation between nova-cc and neutron-gateway?
[08:01] <armaan> jamespage: After adding the nova-cc and neutron-gateway relation, i get a 'Incomplete relations: network-service' message.
[08:01] <jamespage> armaan: can you make sure you have a relation between nova-cc and neutron-api as well
[08:01] <jamespage> armaan: your message is 'incomplete' rather than 'missing' which has a different meaning - so not quite the same bug
[08:02] <jamespage> I think we should probably add the neutron-api - nova-cc relation to REQUIRED_INTERFACES - its been optional in the past to support nova-network based deployments
[08:03] <jamespage> but that feels like a thing of the past
[08:04] <armaan> jamespage: Yes, a relation exists between nova-cc and neutron-api as well.
[08:04] <armaan> jamespage: ahhh, wait
[08:04] <armaan> jamespage: I guess that was the issue, this fixed the problem "juju add-relation nova-cloud-controller neutron-api"
[08:04] <armaan> thanks! :)
[08:05] <jamespage> yw
[09:57] <armaan> jamespage: After adding the relation earlier, neutron agents are failing to report their state. http://paste.openstack.org/show/616542/
[10:13] <armaan> jamespage: All the services look fine to me http://paste.openstack.org/show/616551/
[10:31] <noops> current method of deployment which i m using : juju deploy /charm/mycharm --resource install = "tar file" -to <any-unit> . How can I do that using yaml file if i don't want to provide resource through cli
[10:33] <anrah> if you mean bundle? I don't know whether that is possible.. At least it was not some time ago
[10:36] <noops> yes i mean that
[10:37] <noops> So providing through cli is the only way ?
[10:39] <anrah> https://bugs.launchpad.net/juju/+bug/1623217 at least according to that Bug it is not yet resolved
[10:39] <mup> Bug #1623217: juju bundles should be able to reference local resources <sts> <talisman> <juju:Triaged by ecjones> <https://launchpad.net/bugs/1623217>
[15:42] <jhobbs> how can I specify in the 'machines' section of a bundle, which zone I want a machine in?
[15:43] <jhobbs> if I want machine 0 in zone 'zone2' how do I specify that in the bundle?
[15:43] <jhobbs> it seems to ignore 'zone' field and says 'zone' is an invalid constraint
[15:44] <thedragon> how easy is it to set up juju?
[15:45] <rick_h> jhobbs: which provider?
[15:45] <jhobbs> rick_h: maas
[15:46] <thedragon> open stack?
[15:51] <rick_h> jhobbs: hmm yea not sure. It looks like zone is supported in the code to get a node, but not sure where that gets maps out to a valid constraint to listen to. I thought it was availability-zone or something on AWS, but normally Juju round-robins zones for unit resilience
[15:53] <jhobbs> rick_h: i can do juju deploy cs:ubuntu --to zone=zone3
[15:53] <jhobbs> that works fine, i just don't know how to from a bundle
[15:53] <jhobbs> i will file a bug
[15:54] <rick_h> jhobbs: ah! so it's not a constraint
[15:54] <rick_h> jhobbs: it's a placement directive ugh
[15:54] <rick_h> jhobbs: and bundles try to parse that as an application name in the bundle vs understanding that zone thing
[15:55] <jhobbs> it's a constraint to maas but a placement directive to juju
[15:55] <rick_h> jhobbs: so sounds like an issue in how we model that and a bug on the /juju/bundlelib probably
[15:55] <rick_h> jhobbs: right, but not something juju does with --constraints "x=y"
[15:55] <jhobbs> yeah
[15:55] <jhobbs> ok, thanks rick_h, i'll file a bug
[15:58] <jhobbs> https://bugs.launchpad.net/juju/+bug/1706704
[15:58] <mup> Bug #1706704: bundles: no way to specify which zone a machine should be in <cdo-qa> <juju:New> <https://launchpad.net/bugs/1706704>
[17:01] <Mmike> hi, lads. Is there a way to do a staging, manual upgrade of juju? I'm running juju 2.0.2 and I'd like to go to latest 2.2, but if I allow all of my agents to connect to the stateserver, bad-things-happen
[17:02] <Mmike> so I was thinking, firewalling deployed machines, upgrading stateserver via 'juju upgrade-juju', and then 'manually' (somehow) upgrading the agents
[17:02] <Mmike> is that even an option?
[17:04] <ak_dev> Hi all,  I would like to say that the prototype of the OVN charm is ready, you can deploy pods successfully using that
[17:04] <ak_dev> This the charm : cs:~aakashkt/ovn-13
[17:04] <ak_dev> and the repo : https://github.com/AakashKT/ovn-kubernetes-charm
[17:04] <ak_dev> I  would also be bringing up issues on the repo soon, as kjackal suggested
[17:04] <ak_dev> Finally, would like to have you guys review the charm and give your suggestions on what can be improved  / added
[17:04] <ak_dev> Thank you
[17:05] <ak_dev> Mmike : Sorry i posted the message just after yours, dont have an answer to your query, but I am sure somebody else will help out :-)
[17:05] <Mmike> ak_dev: no worries :) It's IRC, that's how it works :)
[17:06] <ak_dev> Mmike: Yeah, still kind of new here :-)
[20:24] <natefinch> marcoceppi or arosales (or anyone else who knows):  are there stories for rolling restarts, rolling upgrades, or a/b deployments in Juju yet?
[20:35] <arosales> natefinch: I believe rolling upgrades aren't a juju-core base function but are modeled through actions and config given the charm author implements such a method.
[20:36] <arosales> natefinch: for a/b deployments though model migration may be worth taking a look, https://jujucharms.com/docs/2.1/models-migrate
[20:37] <arosales> hth natefinch
[20:39] <natefinch> Thanks :)
[20:39] <natefinch> oh yeah, model migration, forgot about that.  That would be nice.
[20:41] <arosales> natefinch: model migration does work under the same cloud.
[20:41] <arosales> If others have thoughts on rolling upgrades please chime in
[20:44] <natefinch> what's the state of the art in docker support these days?
[20:46] <arosales> natefinch: modeled by the author at the charm level
[20:47] <natefinch> ok
[20:48] <arosales> natefinch: k8 charms are a pretty solid
[20:48] <arosales> http://jujucharms.com/canonical-kubernetes
[20:49] <natefinch> yeah, we've kind of decided against k8s because it's so complicated
[20:53] <arosales> ya, pending the scale k8's may not be worth the over head. But once its running provides nice features to keep scaled and running
[20:56] <arosales> to keep docker containers scaled and running, that is
[20:57] <natefinch> right
[20:58] <natefinch> docker is also a problem for us, since we use a lot of storage-based systems, postgres, cassandra, kafka, etc... and those don't play well with docker by default
[21:00] <tvansteenburgh> natefinch: you can leave your storage external at first
[21:01] <tvansteenburgh> e.g. as mentioned in https://insights.ubuntu.com/2017/07/20/run-django-applications-on-the-canonical-distribution-of-kubernetes/
[21:02] <natefinch> does networking work on AWS yet?
[21:02] <thumper> natefinch: which bit exactly?
[21:04] <natefinch> like creating subnets and assigning services to a specific subnet
[21:05] <thumper> you generally assign applications to spaces, not subnets
[21:05] <thumper> if you create a space and put the right subnets in it, then I think it works
[21:05] <natefinch> sure.... but the docs say spaces are only supported on MAAS
[21:05] <natefinch> "Note: Advanced networking features, such as 'spaces`, are currently only supported by MAAS."
[21:05] <thumper> spaces are kinda supported on AWS, but FSVO working
[21:06] <thumper> that is a focus this cycle
[21:06] <natefinch> *nod*
[21:19] <natefinch> what about networking among containerized services?
[21:22] <natefinch> thumper, arosales: ^ .   (i.e. last I heard that was still a problem)
[21:23] <thumper> otp
[21:23] <natefinch> kk
[21:27] <arosales> natefinch: we regularly put applications in lxc containers for OpenStack


[08:10] <dholbach> good morning
[15:22] <dholbach> bkerensa, I'm done with my patch pilot shift now - I'll start writing the spotlight (getting fixes in and getting upload rights) now
[15:23] <dholbach> bkerensa, if you want to squeeze in anything else, there's still time :)
[16:01] <akgraner>  dholbach, just so you know Issue 246 will be the last issue of 2011 Issue 247 will be the published after the 2nd of January
[16:02]  * dholbach nods
[16:02] <dholbach> thanks akgraner
[16:02] <dholbach> we will do our last next week Thursday
[16:03] <akgraner> great - thanks!
[16:43] <pleia2> MrChrisDruif: re: cat, kidney failure, she's coming home tonight but with lots of meds and things to manage it
[16:44] <MrChrisDruif> Alright, that's indeed bad news.
[16:44]  * pleia2 nods
[17:22] <dholbach> bkerensa, last chance to add something to the dev update
[17:22] <dholbach> (or to have a look over it
[17:22] <dholbach> )
[17:27] <dholbach> ok, got it out :)
[17:28] <pleia2> \o/
[17:30] <dholbach> and with that, I'll call it a day - see you all next week :)
[17:30] <pleia2> have a nice weekend :)
[17:30] <MrChrisDruif> Nice weekend dholbach
[17:31] <dholbach> and the same to you
[17:31] <dholbach> bye
[17:34] <MrChrisDruif> Thanks =)
[19:49] <akgraner> pleia2, what did we have to do to get the calendars to display on the fridge?  I am trying to add a calendar to another WP site and just adding the embed code isn't working or was it that it didn't show in draft but did show once it was published.
[19:50] <pleia2> akgraner: it doesn't show in draft mode
[19:50] <akgraner> well that explains it :-) thanks
[19:51] <pleia2> might have to do some tweaking after you save it, but it should show up alright published
[23:19] <bkerensa> dholbach: Sorry for the delay.... I got epic busy yesterday and it got sidetracked
[23:19] <bkerensa> oh darn
[23:19]  * bkerensa needs to start checking if people are in channel (I assume everyone uses a bnc :P )
[23:20] <MrChrisDruif> A what?
[23:45] <zkriesse> bkerensa: you mean a ZNC
[23:45] <zkriesse> not a bnc
[23:46] <pleia2> znc is a type of bnc
[23:46] <bkerensa> indeed
[23:46] <bkerensa> psybnc for instance was one of the first bnc's
[23:46] <bkerensa> :D
[23:47] <bkerensa> although I do currently use znc for it's Growl support


[05:56] <estan> hi folks. anyone care to have a look at the qtbase-opensource-src in the xenial upload queue that resulted from my bug? (https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173)
[14:07] <gQuigs> can I please get this nomination accepted for xenial - https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1673579  (debdiff already attached)
[14:21] <rbasak> gQuigs: done
[14:21] <gQuigs> rbasak: thanks!


[04:25] <blithen> Woah! This is tiny channel.
[04:25] <blithen> Surprising that it's not bigger since the main ubuntu channel has about<PHONE_NUMBER>86 people in it.


[14:13] <ondine> hi, i have a quick question about upstart jobs with instances
[14:14] <ondine> asuming i have a job 'start-workers' that starts 5 worker instances N=1..5, i know i can restart all workers with service start-workers restart
[14:15] <ondine> but can i also safely restart only a specific worker, say worker N=3?
[14:22] <xnox> ondine: yes. $ restart worker N=1
[14:24] <xnox> e.g. look at $ sudo initctl list
[14:24] <xnox> ondine: that will show all jobs (instance)
[14:30] <ondine> xnox: okay, thanks