[02:52] <marcosroriz> honk
[02:54] <duanedesign> hello marcosroriz
[02:54] <marcosroriz> hi duanedesign
[02:54] <marcosroriz> the thing is
[02:54] <marcosroriz> I have a folder called wallpaper
[02:54] <marcosroriz> this folder has like 300+ files
[02:54] <marcosroriz> and when I browse u1 in the web I usually just get like 30 file
[02:55] <duanedesign> is this a folder you put in the Ubunt One directory?
[02:56] <marcosroriz> yep
[03:00] <duanedesign> ok
[03:00] <duanedesign> when did you add the folder
[03:01] <duanedesign> what version of Ubuntu One are you using. You can get that by opening a ter minal and running:  dpkg -l ubuntuone-client
[03:01] <marcosroriz> whell this folder is like 3 months
[03:01] <marcosroriz> ii  ubuntuone-clie 1.0.3-0ubuntu1 Ubuntu One client
[03:02] <duanedesign> ok
[03:04] <duanedesign> marcosroriz: can you open this file and see if it has anything in it
[03:04] <duanedesign> gedit  ~/.cache/ubuntuone/log/syncdaemon-exceptions.log
[03:06] <marcosroriz> one min
[03:06] <duanedesign> if there is can you paste it at http://paste.ubuntu.com
[03:07] <marcosroriz> theres a bunch
[03:08] <marcosroriz> and bunch of days
[03:09] <duanedesign> copy and paste it at the address above. After you hit paste post the address here
[03:10] <marcosroriz> all the files are empty
[03:11] <duanedesign> ok
[03:12] <marcosroriz> maybe I can do something like
[03:12] <marcosroriz> share with you the folder
[03:12] <marcosroriz> and you can try to browse
[03:13] <duanedesign> lets look at  ~/.cache/ubuntuone/log/syncdaemon.log
[03:13] <marcosroriz> oh
[03:13] <marcosroriz> thats huge
[03:14] <duanedesign> can you paste it at http://paste.ubuntu.com
[03:14] <marcosroriz> sure
[03:16] <marcosroriz> http://paste.ubuntu.com/409311
[03:31] <marcosroriz> any idea?
[03:31] <marcosroriz> looks like the wallpaper are tehre
[03:31] <marcosroriz> :3
[03:32] <duanedesign> yeah. What you can do is come back by when all the Ubuntu One devs are here.
[03:32] <duanedesign> they are in here on weekdays from 13:00-21:00 GMT
[03:33] <marcosroriz> ok dokie ;)
[03:50] <duanedesign> marcosroriz: one thing you can try /5
[03:50] <duanedesign> oop
[08:45] <MatsHenricson> Hi! I have a question regarding the privacy policy for the files I save on Ubuntu One. Is this a place to ask them, or should I go somewhere else?
[08:46] <MatsHenricson> "honk"
[09:01] <duanedesign> yes
[09:02] <duanedesign> MatsHenricson: there is a wiki page that covers a lot of the most asked questions.
[09:02] <duanedesign> https://wiki.ubuntu.com/UbuntuOne/Security
[09:03] <MatsHenricson> Not my question, unfortunately
[09:03] <MatsHenricson> That pages says that my data will not be shared with anyone, except if "required by law"
[09:04] <MatsHenricson> But WHICH law? US law? I mean, the data is backed up (if I remember correctly) by Amazon, which is a US company.
[09:04] <MatsHenricson> Or UK law, since Canonical is registered in the UK
[09:04] <MatsHenricson> Or Sweden, where I live?
[09:05] <MatsHenricson> Or is that page vague intentionally? I don't trust anyone, since my data isn't encrypted
[09:05] <duanedesign> The servers are in the US
[09:05] <duanedesign> you can encrypt your data if you wish
[09:32] <MatsHenricson> So, it is US law, then?
[09:32] <MatsHenricson> How could they do such a bone-headed decision to base the servers in the US?
[09:33] <MatsHenricson> Seriously!
[09:39] <duanedesign> just dont put your plans to build a dirty bomb in your Ubuntu One folder ;)
[09:40] <nijaba> hello. Where can I find documentation on configuring Ubuntu One contact sync via funambol?
[09:41] <duanedesign> nijaba: hmmm. it was in the topic. Let me see
[09:44] <MatsHenricson> It is just so sad...
[09:45] <duanedesign> nijaba: https://edge.one.ubuntu.com/phones/   when 'beuno' gets in (anytime now) he can help you further
[09:45] <nijaba> duanedesign: thanks a lot :)
[10:11] <beuno> nijaba, hi
[10:11] <beuno> I'm geting ready to board a plane
[10:11] <beuno> but if I can help you in the meantime
[10:11] <beuno> let me know
[10:46] <PaulGit> vds: ping
[10:48] <vds> PaulGit: pong
[10:48] <PaulGit> vds: Good morning, I just wanted to let you know that I did some testing again and the duplicate contact issue as I reported before is still there :(
[10:51] <vds> PaulGit: auch
[10:51] <vds> PaulGit: thanks for testing
[10:53] <PaulGit> vds: No problem.  Let me know when you want me to test again.
[11:21] <mmiicc> hi everyone, I'm trying contact sync from Nokia N900 but I'm still getting 401 error. beuno any advice?
[12:58] <mdke> hi all. On latest lucid there appears to be no entry in the "Internet" menu for Ubuntu One - is that intentional or a bug?
[13:01] <kermiac_> mdke: that is by design. Ubuntu One can be found in the "me menu"
[13:01] <bac> hey beuno i have some sync feedback
[13:04] <mdke> kermiac: ok. I don't think it would hurt to include it in both (as gwibber) but I assume this is now settled and will update the documentation accordingly
[13:05] <beuno> bac, hey hey
[13:05] <beuno> give it to me!
[13:05] <beuno> popey, hi
[13:05] <bac> beuno: ok, so i last successfully synced under karmic usint t'bird 2
[13:06] <bac> i just tried using lucid and tbird3...it didn't go well.  couchdb-daemon died and then tbird crashed
[13:06] <bac> is it required that i reset all my contacts before trying given the migration?
[13:06] <beuno> bac, tb3 doesn't use couch
[13:07] <beuno> so I'm a but stunned
[13:07] <bac> ah, ok
[13:08] <beuno> bac, you shouldn't need to reset your contacts at all
[13:08] <bac> ok
[13:08] <beuno> bac, did you install the addon for tb3?
[13:08] <bac> yes
[13:08] <mmiicc> beuno: I'm trying contact sync from Nokia N900 but I'm still getting 401 error.
[13:10] <mdke> I'm really struggling to figure out how to update an instruction "Click Applications->Internet->Ubuntu One" to point at the "me menu". Does anyone have any ideas? What do you use in the Ubuntu One documentation?
[13:10] <popey> hi beuno
[13:10] <beuno> mmiicc, the n900 is not well supportes, I think. Do you have a log for that?
[13:10] <kklimonda|G1> is android 1.6 supported?
[13:10] <kklimonda|G1> for contacts syncing
[13:10] <beuno> popey, kklimonda|G1, Androids are not officially supported
[13:10] <bac> beuno: tried again twice.  funambol gets to "receiving server data" and then t'bird just quits, no crash report
[13:10] <beuno> it's not something we can really address
[13:10] <popey> massive :(
[13:11] <mmiicc> beuno: yes, but it's not complete I think: http://pastebin.org/136594
[13:11] <beuno> popey, kklimonda|G1, I do know that most people with androids, both 1.6 and 2.0 have made it work with the community-built apps
[13:11] <beuno> bac, ah, awesome
[13:11] <popey> why is there a distinction between supporting community-built apps and other apps?
[13:11] <popey> given ubuntu is a community distro
[13:12] <bac> beuno: let me know if you want me to help troubleshoot.
[13:12] <popey> seems wonky
[13:13] <beuno> popey, this is Funambol
[13:13] <beuno> we've built the glue between Funambol and couchdb
[13:13] <beuno> but the support for hundreds of mobiles comes from Funambl
[13:14] <popey> ok, and the android bit is community developed?
[13:14] <kklimonda|G1> and not for iphone nor android :D?
[13:14] <beuno> AFAIK, they wait for the clients to have a certain level of maturity before making them official
[13:14] <kermiac> mdke: System -> Preferences -> Ubuntu One will do the same thing
[13:14] <beuno> popey, correct
[13:14] <beuno> kklimonda|G1, popey, the iphone is well supported
[13:14] <beuno> it has a funambol app in the store
[13:14] <beuno> and very very very soon there will be an ubuntu one app on the apple store
[13:14] <beuno> which will have the branding and the hostname pre-configured
[13:15] <beuno> so for iphones it will be super easy
[13:15] <kklimonda|G1> so it's just android? what about meego/meebo? does it have client?
[13:15] <beuno> Androids, we need to work with the existing community of developers to improve
[13:15] <popey> ok, thats going to get Ubuntu some more stick that it really doesnt need right now
[13:15] <popey> IMO
[13:15] <beuno> popey, having an iphone app?
[13:15] <popey> we are putting an Ubuntu branded app in the _iphone_ store, but not android?
[13:15] <beuno> popey, Funambol provides it for the iphone, not for android
[13:16] <statik> the only way to distribute iphone apps is via the store
[13:16] <popey> sure, I appreciate that it's an upstream issue
[13:16] <beuno> I promise you, this is not our choice  :)
[13:16] <popey> but it's still an issue that's going to make us look very silly IMO
[13:16] <mdke> kermiac: does it actually start the application? If so, do you think that System->Preferences->Ubuntu One would be a valid correction to use in a document like this: http://doc.ubuntu.com/ubuntu/newtoubuntu/C/applications.html
[13:16] <popey> we already get flak for looking like a mac, now we have an app in the iphone store, and not supporting (officially) the geek choice of phone
[13:16] <beuno> kklimonda|G1, I don't know about meego/meebo support, but let me know when you find out  ;)
[13:16] <kklimonda|G1> beuno: noone is going to see that this wway. Ubuntu and Ubuntu One are not funambol products but canonival
[13:17] <kklimonda|G1> oh god, small g1 keyboard is killing me ;)
[13:17] <beuno> mmiicc, did you get the rest of the log?
[13:17] <statik> popey, kklimonda|G1: something else to consider - only paying subscribers will be allowed to use phone sync
[13:18] <statik> I'm not saying this because I think it invalidates your point, just want you to know all the details
[13:18] <popey> statik: yes, and you've just made it _less_ (not more_ likely that I'll become a paid subscriber
[13:18] <beuno> kklimonda|G1, popey, I understand the perception we will create. Can you guys think of a way to make this better short of us embarking on android upstream development?
[13:18] <statik> exactly
[13:19] <popey> short of making a supported android client I dont know
[13:19] <popey> this just 'feels' wonky to me
[13:19] <beuno> popey, do you think it woulc be better to not have such a service due to lack of support for androids?
[13:19] <statik> popey: it will be interesting to watch and see how this all plays out with user adoption - i have certainly considered whether we should just kill phone sync totally and work more on the music store instead. but we'll go through a full cycle and see how many people use it before doing anything major like that.
[13:20] <popey> well one thing about android is that we already have sync
[13:20] <popey> built in
[13:20] <popey> it's near-zero effort for me to sync to google
[13:20] <popey> so one reaction might be "who cares, I wouldn't use u1 phone sync anyway, it's less useful than the built in sync"
[13:21] <kklimonda|G1> heh, android is suprisingly closed platform
[13:21] <popey> so it ubuntu one ;)
[13:21] <beuno> right, we don't have a very interesting story for android users
[13:21] <popey> *is
[13:21] <beuno> yet
[13:22] <popey> i would say that needs to be spelled out clearly as to why that is
[13:22] <beuno> I feel that enabling a big chunk of the market to sync their contacts is still very valuable
[13:22] <popey> at the moment i had to dig about to figure out my phone isnt supported
[13:22] <popey> oh sure, I agree it's a valuable feature
[13:22] <kklimonda|G1> it just sucks that ubuntu is so dependant on 3rd party - other developers and companies.
[13:23] <popey> we are dependant upon 3rd parties for most of the ubuntu software stack
[13:23] <popey> mozilla, openoffice...
[13:23] <kklimonda|G1> because Ubuntu takes hit for upstream shortcomings and issues
[13:23] <beuno> right, we need to communicate better what is supported and what isn't. We will do that before the beta launch. Right now, we're testing how stable the service is
[13:23] <popey> beuno: and I'd love to help test that :)
[13:23] <beuno> popey, I will help you find an app for 1.6
[13:23] <beuno> let me dig in my emails
[13:23] <popey> thanks
[13:24] <popey> just be ready for the flak that will inevitably come from the apple haters
[13:24] <kklimonda|G1> heh, especially after rhythmbox got a good sync with iphones/ipods
[13:26] <popey> beuno: ok, the issue with those two sites not working was a local one, i can now get to cryket and appbrain
[13:27] <popey> and this will be less of an issue when htc get their finger out and actually release 2.x for htc hero >:|
[13:27] <beuno> popey, cool, see if any of those work, I'm sure I added them as people reported success
[13:27] <popey> beuno: both of them say 2.x only
[13:28] <beuno> popey, looking...  I also know that Funambol has a bounty for the first person to port the 2.0 app to 1.6
[13:28] <popey> hah
[13:29] <popey> opportunity for you to earn some money on the side there then ;)
[13:29] <kklimonda|G1> ] 24
[13:29] <beuno> popey, I'd have to get an android phone first!
[13:30] <kklimonda|G1> beuno: the cost mentioned in the announcement is the cost of creating the server itself or some license fee you have to pay funambol?
[13:30] <statik> both
[13:30] <popey> i thought funambol was free software
[13:31] <statik> funambol is open source but we pay for a support contract etc
[13:31] <statik> we may have an extra component that is not open source, it's been a while since i built funambol from svn
[13:32] <beuno> popey, I see a lot of people talking about them just installing the 2.0 app. Does that make any sense?
[13:32] <mmiicc> beuno: part1 - http://pastebin.org/136794 part2 - http://pastebin.org/136803
[13:32] <beuno> statik, there are a few components that are not open source, yes, like the json connector
[13:33] <popey> will try beuno
[13:34] <beuno> thanks popey
[13:35] <beuno> this is the page for 1.6 syncing: https://android-client.forge.funambol.org/servlets/ProjectProcess?pageID=IHR75o
[13:35] <beuno> the bounty, etc
[13:41] <popey> beuno: appbrain just tries to get the app from the marketplace which fails because funambol isnt in the market
[13:45] <beuno> popey, argh. I can't find the email from the person who synced their G1
[13:49] <kermiac> Is there a wiki or tutorial page for FF sync. that I can point people to?
[13:50] <mdke> kermiac: https://wiki.ubuntu.com/UbuntuOne/Tutorials/Bookmarks ?
[13:52] <kermiac> mdke: thanks, I wasn't very specific. I actually meant is there any updated documentation that outline the process in lucid
[13:52] <kermiac> i.e. click on "install" next to bookmarks, install bindwood plugin, etc
[13:53] <mdke> kermiac: ok
[13:53] <kermiac> mdke: but thanks anyway :)
[13:53] <mdke> no worries
[14:14] <mmiicc> beuno: sorry, I was offline, did you check my logs?
[14:15] <beuno> mmiicc, I did not, let me do that now
[14:15] <mmiicc> beuno: ok, thanks
[14:15] <beuno> mmiicc, so the sync looks succesful. You always get a 401 error?
[14:16] <beuno> mmiicc, actually..
[14:16] <beuno> [2010-04-05 11:11:35.442]  authorization failed, check username '06953478' and password
[14:19] <beuno> mmiicc, I will look through the logs for anything suspicious, but could you google around to see if there are any known problems with the n900?
[14:19] <mmiicc> beuno: I've tried resetting passwords, but everytime I got error
[14:20] <beuno> mmiicc, now that I recall, I've seen that problem before
[14:23] <cwraig> hi all, is there anyway to get U1 client on ubuntu 9.10 to rescan the folder to ensure integrity with the cloud
[14:24] <cwraig> honk
[14:25] <mdke> mattgriffin: here?
[14:25] <mattgriffin> mdke: hello!
[14:26] <mdke> mattgriffin: hi :) Thanks for your email, I figured it would be quicker to discuss here if you were around
[14:26] <mattgriffin> mdke: cool
[14:26] <mdke> the issue is that the string freeze for documentation has now passed and it is too late to include further documentation
[14:27] <mmiicc> beuno: so, it might be problem with N900 itself?
[14:27] <mdke> mattgriffin: if we shove it in now, the translators would only have a couple of weeks to translate the new material
[14:27] <mattgriffin> mdke: i was afraid of that
[14:28] <mdke> mattgriffin: we could either ask the translators if they are willing to do the work in the short time, or include it in the next release
[14:28] <mattgriffin> mdke: that sounds good. where all does this content live?
[14:28] <mdke> I'm minded to give it a shot given the importance of the feature and the fact that it's entirely undocumented
[14:28] <mdke> mattgriffin: how do you mean?
[14:29] <mattgriffin> mdke: i know it lives at help.ubuntu.com ... where else is the same text used?
[14:29] <mdke> mattgriffin: in System->Help and Support
[14:29] <mattgriffin> gotcha
[14:30] <mdke> I'll send an email to the translators list to get their thoughts
[14:30] <mattgriffin> mdke: cool. thank you very much.
[14:30] <mdke> and next release we can work on trying to add some help to the Rhythmbox manual too, which would be appropriate I think
[14:31] <mattgriffin> mdke: yeah. need to figure out a good way to incorporate it :)
[14:32] <mdke> I'm sure we'll find something
[14:37] <mdke> mattgriffin: I assume the material can be used under cc-by-sa 3.0 licensing terms?
[14:38] <duanedesign> rye: if you have a chance could you look at this pastebin I have from a user and tell me what you think. line 255?  http://paste.ubuntu.com/409311/
[14:39] <statik> duanedesign, rye is away today so probably won't be responsive as normal
[14:40] <duanedesign> oops. thank you
[14:40] <duanedesign> statik: thought it was strange that he hadnt popped up yet this morning :)
[14:41] <statik> yep :)
[14:47] <mattgriffin> mdke: sure. i wrote it :)
[14:49] <beuno> mmiicc, yes, it seems to be the n900 client
[14:53] <mmiicc> beuno: ok, thanks, I'll google for that (or should I say "I'll yahoo! for that" :D )
[15:07] <duanedesign> has anyone heard anything in regards to a plugin for Amarok to acces the Ubuntu One Music Store
[15:45] <hunger_p> Hi. Trying to start ubuntuone-preferences I get an import error about clientdefs in lucid. Is this a known issue?
[15:46] <dobey> hunger_p: try doing "sudo dpkg-reconfigure python-ubuntuone-client" in a terminal
[15:51] <hunger_p> dobey: I'll try that, thanks
[15:52] <dobey> sure
[15:53] <hunger_p> Helped, thanks.
[15:53] <hunger_p> So how can I rename the ubuntu one folder?
[15:55] <dobey> you can't
[15:55] <dobey> you can pick any other folder in your home, to also sync with ubuntu one, though
[15:55] <hunger_p> Not even in gconf?
[15:58] <hunger_p> I would like to share the encfs dir that backs the ubuntu one folder instead.
[15:59]  * hunger_p may not send or store his data unencrypted.
[16:16] <hunger_p> hmm... doesn't sync at all. I can't even see any applet:-(
[16:17] <hunger_p> Is UO supported on the netbook remix?
[16:19] <hunger_p> Oh, sorry, it does work:-) checked the wrong place in the web ui it seems:-)
[16:25] <liamwilson> Hey guys
[16:26] <liamwilson> I'm having a bit of trouble with the music store, and was wondering if anyone could help me out a bit?
[16:27] <peppe84> Hi in evolution I don't see my contact present on ubuntuone siteweb. Any idea?
[16:32] <dobey> peppe84: https://wiki.ubuntu.com/UbuntuOne/Tutorials/Contacts
[16:35] <hunger_p> Whenever I try to share a folder to UO nautilus crashes:-(
[16:36] <peppe84> dobey: Yes yes. I have try. I don't see anything.
[16:36] <hunger_p> Must have broken something... or it does not like symlinks or the length of the filenames or the location or I don't know:-(
[16:37] <liamwilson> Hey, I bought an album of the music store almost an hour ago, and it's still not showing up in rhythmbox, but some of the files show up on the web interface
[16:37] <liamwilson> Do I have to download them from the web interface and save them to ~/music?
[16:38] <duanedesign> peppe84: when launching evolution does it ever consume a large amount of the cpu?
[16:39] <duanedesign> hunger_p: r-click and selecting 'Syncronize with Ubuntu one' crashes nautilus?
[16:40] <peppe84> duanedesign: no. I have open System monitor, firefox, rhythmbox, evoluton. My cpu cosum is variable 17% - 33%
[16:40] <peppe84> is normal
[16:40] <hunger_p> duanedesign: At least the nautilus window is gone after selecting that option.
[16:41] <hunger_p> duanedesign: and in the webui that folder does not show up either... does not get that green checkmark in nautilus either.
[16:45] <duanedesign> peppe84: could you try to run in a Terminal:  evolution --force-shutdown
[16:46] <duanedesign> peppe84: then : /usr/lib/evolution/evolution-data-server-2.28
[16:46] <peppe84> server up and running
[16:47] <duanedesign> peppe84: then open evolution and try and access the contacts
[16:47] <duanedesign> peppe84: hopefully it will output something usefull to the terminal as to what is going on.
[16:49] <peppe84> duanedesign: chouch db error: http://paste.ubuntu.com/409560/
[16:49] <duanedesign> hunger_p: could you run: u1sdtool --list-folders
[16:57] <duanedesign> peppe84: hmm. I am not sure what that means.
[17:00] <duanedesign> peppe84: usually when you cant see the contacts it means desktopcouch is not started.
[17:03] <peppe84> duanedesign: in system monitor i have four process name couchdb e one process name couchjs in status pipe_wait and do_wait
[17:04] <peppe84> (in sleeping)
[17:04] <duanedesign> peppe84: you can try.  Then http://ln-s.net/5Zpr do the steps 'Killing and restarting desktopcouch' replace step 4 with start evolution, access contacts
[17:12] <dantalizing> morning all .. i've downloaded the android 2.x funambol sync client, changed the server url to syncml.o.u.c, but what username and password do i put in ?  my u1 acct username/pass doesnt seem to work.
[17:13] <duanedesign> hello dantalizing. I think beuno might be able to help you.
[17:13] <peppe84> duanedesign: ok on table named contacs I see my 300 contacs. but in evolution... :-(
[17:14] <beuno> duanedesign, did you go to https://edge.one.ubuntu.com/phones?
[17:14] <beuno> er
[17:14] <beuno> dantalizing, ^
[17:14] <beuno> you need to create a username/pass there
[17:15] <duanedesign> peppe84: you see the database in Futon but not evolution
[17:15] <dantalizing> ah... thx beuno
[17:15] <peppe84> ya
[17:16] <dantalizing> ow ... OOPS-ID-1556appserver75849
[17:17] <beuno> interesting
[17:17] <beuno> dantalizing, let me look at that for you
[17:17] <beuno> where did you get that?
[17:18] <beuno> in the URL I gave you?
[17:19] <dantalizing> yes
[18:08] <frith_> are there cli tools yet to use ubuntu one?
[18:39] <duanedesign> frith_: there is u1sdtool
[18:39] <frith_> thanks
[18:39] <frith_> not part of karmic i guess
[18:40] <duanedesign> frith_: there has been a lot added to u1sdtool in Lucid.
[18:40] <frith_> oh i will wait till the end of the month
[18:40] <duanedesign> frith_: i am not running Karmic. i believe its there, just not quite as feature rich. 'man u1sdtool' should tell you whats available
[18:41] <frith_> oh i didn't think it was in karmic
[20:39] <leonel2> Hello ...
[20:41] <leonel2> I'm using Ubuntu Lucid  and  using ubuntuone-preferences I've disconected from ubuntuone  but I still keep seeing  connections to <IP_ADDRESS>  with ssl_esock
[20:41] <leonel2> how can I totally disable those connections and connect ONLY when I need to connect ?? like it works on karmic / jaunty..
[20:44] <leonel2> honk
[21:06] <mario-kemper> hi there - I am experimenting with the DBus API and I am wondering how I can get the public url of a file after publishing. Is there anyone who can point me in the correct direction?
[21:18] <dobey> there's a signal that gets called when something is successfully published, which contains the information in a dict
[21:20] <mario-kemper> ah, ok...I'll have a look
[21:45] <mario-kemper> this is working great, thanks
[21:46] <mario-kemper> is there any way to obtain the url again when the file is already public?
[21:46] <mario-kemper> do I have to call 'change_public_access' again?
[21:47] <dobey> there's no way to just get the list of public files curently, no
[21:48] <dobey> you can cache the results in memory and look it up internally though
[21:49] <mario-kemper> yes, sure
[21:49] <mario-kemper> thanks for your help
[21:53] <vladanian> Hey guys, I've been having tons of trouble w/ tomboy sync. What do you think about just syncing with a local folder, and having that folder be on U1?
[21:54] <vladanian> Do you foresee problems
[22:15] <diverse_izzue> honk
[23:02] <jmcantrell> are there any plans to make it so that i can change the location of the ubuntu one directory to something less visible? maybe ~/.ubuntuone ?
[23:03] <sanderqd> hi bueno, when i log in using the iphone app and my email address, sync fails with the error 'Client not authenticated.' am i doing something wrong?
[23:03] <sanderqd> pretty sure my password is correct, and i haven't changed the server settings
[23:03] <jmcantrell> also, file syncing is SLOW
[23:27] <TecnoBrat> Is https://edge.one.ubuntu.com/phones/ down .. or is it just me? :)
[23:27] <sanderqd> TecnoBrat: it's not just you


[00:44] <hazmat> davecheney, any comment re juju for armhf? ^
[00:45]  * hazmat notices previous nick ref too late
[00:59] <davecheney> hazmat: recap ?
[01:00] <hazmat> davecheney, small. but http://paste.ubuntu.com/5692238/ mwhudson's been asking around
[01:03] <davecheney> TTBOMK go 1.1 is not avilalble in any ubuntu form for armhf
[01:03] <davecheney> 1.1 was imported from upstream into saucy proposed, but it didn't build on armhf
[01:03] <davecheney> that is all I know at the moment
[01:04] <davecheney> If you're happy to use a tarball, http://dave.cheney.net/unofficial-arm-tarballs
[01:22] <wallyworld_> davecheney: how closed is the goamz group? I have a goamz branch i want to land. should i bother asking for group membership or is it best to get one of the group members to land it?
[01:25] <davecheney> wallyworld_: dunno
[01:25] <davecheney> is this another 'we're all not members of gophers' problem ?
[01:25] <wallyworld_> i'm not a member of ~goamz
[01:26] <wallyworld_> which owns goamz project
[01:26] <wallyworld_> you and rodger are
[01:27] <thumper> wallyworld_: congrats on landing all those branches
[01:28] <wallyworld_> thumper: yeah, finally!
[01:28] <davecheney> wallyworld_: well, that is fucked
[01:28] <davecheney> let me see if I can fix that
[01:28] <wallyworld_> davecheney: thanks!
[01:28] <thumper> davecheney, wallyworld_: here is a trivial branch to review: https://codereview.appspot.com/9677044/
[01:28] <davecheney> nope, can't fix
[01:28] <davecheney> gustavo owns it
[01:29] <wallyworld_> restricted team :-(
[01:29] <wallyworld_> ok, will ask him
[01:29] <thumper> davecheney: we can fix it... with the right request :)
[01:29] <mwhudson> davecheney: ok thanks
[01:29] <wallyworld_> i just wasn't sure how protective he is of that project
[01:29]  * wallyworld_ looks at thumper's branch
[01:30]  * thumper considers a constraint of "machine=0"
[01:31] <thumper> --force-machine is all well and good, but doesn't capture intent in state
[01:31] <thumper> I'm trying to work out a way to have state represent the desire for maximum density...
[01:31] <thumper> a.k.a. cheap solution with everything on one ec2 instance
[01:34] <wallyworld_> s/ec2/openstack as well :-)
[01:34] <thumper> wallyworld_: exactly
[01:34] <thumper> wallyworld_: I've been reading through jam's comments on the wiki page
[01:35] <thumper> I don't want to go too far down the path of explicitness when we know we need intent
[01:35] <wallyworld_> thumper: force-machine was always a *very* short term quick fix AFAIUI, so we had better not propogate it's use
[01:35] <thumper> that is my thinking too
[01:36]  * thumper considers a multitude of edge cases
[01:36] <wallyworld_> i think the comments we more along the lines of - we can do the mechanics first (and require explicitness), and once the machinery is there, automate the intent
[01:36] <thumper> juju deploy -n 2 wordpress --constraints "machine:0"
[01:36] <wallyworld_> which i agree with at first read
[01:36] <thumper> should barf
[01:36] <wallyworld_> what does -n do?
[01:36] <thumper> yeah, I've been thinking about that too
[01:36] <thumper> deploy two units
[01:37] <thumper> of the service
[01:37] <wallyworld_> for HA?
[01:37] <wallyworld_> load balancing
[01:37] <thumper> yes
[01:37] <thumper> although...
[01:37] <thumper> would be possible if (and only if) containerised
[01:38] <wallyworld_> yes, makes sense to allow that scenario for testing, even if on the one physical machine
[01:38] <thumper> however...
[01:38] <thumper> what happens if you have the initial environment...
[01:38] <thumper> where everything was deployed onto machine/0
[01:38] <thumper> then you want to scale out
[01:38] <thumper> and add two more units of "foo"
[01:39] <thumper> you don't want it to use the contstraint "machine:0:
[01:39] <thumper> you want it to make new machines...
[01:39] <thumper> ish
[01:39] <thumper> maybe
[01:39] <thumper> geez
[01:39] <wallyworld_> so you wouldjust "juju deploy foo" without the constraint bit?
[01:40] <wallyworld_> then it would allocate a new machine?
[01:40] <thumper> no, it is deployed
[01:40] <thumper> you use add-unit
[01:40] <wallyworld_> right, yes
[01:40] <thumper> it already has constraints though
[01:40] <thumper> how about a constraint...
[01:41] <wallyworld_> so you override those?
[01:41] <thumper> yeah
[01:41] <thumper> but I image it would get icky
[01:41] <wallyworld_> perhaps last specified constraint wins
[01:42] <wallyworld_> or maybe a constraint for "just this one operation"
[01:42] <thumper> yeah...
[01:42] <wallyworld_> eg policy is to allocate a new machine, but just for this add-unit, do it here
[01:42] <thumper> a unit constraint
[01:42] <thumper> rather than a service constraint
[01:42] <wallyworld_> yes
[01:42] <thumper> that _may_ work
[01:42] <wallyworld_> still complicated for users to internalise the model though
[01:43] <wallyworld_> juju status would need serious work i reckon
[01:43] <thumper> yeah, I'd prefer something semantically simple
[01:43] <thumper> to work with maximum unit density
[01:43] <wallyworld_> i reckon we need a "tell me what you are about to do but let me conform first" switch
[01:43] <wallyworld_> confirm
[01:43] <thumper> I think the default will soon be to have machines with lots of units on them
[01:44] <thumper> one machine to do multiple things
[01:44] <wallyworld_> i've been wanting that for ages
[01:44] <wallyworld_> didn't understand why we never had it to start with
[01:44] <thumper> yeah, unit density is the primary outcome for containers I think
[01:44] <thumper> because it is simpler to start a new machine for everything?
[01:44] <wallyworld_> maybe
[01:45] <thumper> the trick is to record intent
[01:45] <thumper> but to have intent flexible
[01:45] <thumper> and easily understandable
[01:45]  * thumper waves his hands
[01:45] <thumper> and magic happens
[01:45] <thumper> that shit
[01:45] <wallyworld_> USB plugged into the back of users' heads should do the trick
[01:46] <thumper> wasn't there a movie ages ago called "free jack" ?
[01:46] <wallyworld_> not sure, perhaps
[01:46] <wallyworld_> maybe only in NZ
[01:46] <wallyworld_> thumper: so we still have lots to discuss before we can fire up our IDEs and start hacking me thinks
[01:47] <thumper> wallyworld_: well, there should be some things we can start on soon
[01:47] <thumper> wallyworld_: but the subtleties are the hard bit
[01:47] <thumper> and I'd like williams input
[01:47] <thumper> when he is back next week
[01:48] <wallyworld_> yes. i fear even the "simple" things could turn nasty unless we fully understand the solution we are aiming for
[01:49] <wallyworld_> although if we agree containers are machines with parent machines we could start reworking the relevant interfaces
[01:50] <thumper> yes
[01:50] <thumper> and having a create-machine command could be useful
[01:50] <thumper> we already have a destroy-machine
[01:51] <wallyworld_> as in create-machine just ultimately calls the provider's startInstance() and registers the machine in the env but there's nothing deployed to it?
[01:51] <thumper> right
[01:52] <thumper> but "create-machine 0:lxc" could create an lxc container on machine 0
[01:52] <wallyworld_> if we were to do that, and come back later and do a deploy, that machine should then be used
[01:52] <thumper> and put a machine agent on it
[01:52] <wallyworld_> rather than creating a new one
[01:52] <thumper> maybe...
[01:52] <thumper> sounds reasonable at least
[01:53] <wallyworld_> i think your n:lxc thing works also
[01:53] <thumper> "create-machine :lxc" would create a new machine, and a container
[01:53] <thumper> this way, we could have nested containers
[01:53] <wallyworld_> but there's no point doing those things as commands for the user to run manually unless the result machine/container were to be used by juju later
[01:53] <thumper> as the container is represented as a machine
[01:54] <thumper> wallyworld_: unless we had a constraint "machine x"
[01:54] <thumper> but I agree, it should be deployed to
[01:54] <thumper> if it is empty
[01:54] <wallyworld_> hmmm. that would require the user to keep track of a lot of stuff
[01:54] <thumper> and fits the requested constraints
[01:54] <thumper> wallyworld_: not necessarily
[01:54] <wallyworld_> yes, fits the constraints is essential
[01:54] <thumper> and it is only a first cut
[01:55] <thumper> and it gives a very definite "first thing" to do
[01:55] <wallyworld_> thumper: ok, so i'll create a branch for the start-machine command
[01:55] <thumper> ok.
[01:55] <thumper> initially take no params
[01:55] <wallyworld_> initially without :lxc
[01:55] <thumper> and just create a new machine from the provider
[01:55] <thumper> ack
[01:55] <wallyworld_> yes
[01:55] <thumper> also...
[01:56] <wallyworld_> since lxc not done yet
[01:56] <thumper> hmm...
[01:56] <thumper> we do have a weird case
[01:56] <thumper> we explicitly don't reuse machines
[01:56] <thumper> which means, if a machine is sitting there empty
[01:56] <wallyworld_> we could do if they are marked as empty
[01:56] <thumper> we explicitly don't use it
[01:56] <wallyworld_> let's add an "is empty"  param
[01:56] <wallyworld_> attribute
[01:56] <thumper> well...
[01:56] <thumper> it is harder than that
[01:57] <thumper> we effectivly have "is empty" by "no prinicple units"
[01:57] <thumper> and there is code there already
[01:57] <wallyworld_> ok
[01:57] <thumper> perhaps what we need is "clean"
[01:57] <thumper> a machine is clean if it is new
[01:57] <wallyworld_> sounds better
[01:58] <thumper> if a unit is deployed, not in a continer
[01:58] <thumper> and then removed
[01:58] <thumper> the machine is "unclean"
[01:58] <wallyworld_> yes
[01:58] <thumper> if a unit is deployed in a container
[01:58] <thumper> and removed
[01:58] <thumper> the machine is clean
[01:58] <wallyworld_> but if container is nixed, machine is clean
[01:58] <thumper> we can use clean machines
[01:58] <wallyworld_> yes
[01:58] <thumper> not "unclean"
[01:58] <wallyworld_> +1
[01:58] <thumper> ok, this is almost making sense
[01:59] <wallyworld_> i'll start hacking and see where the yellow brick road takes me
[01:59] <wallyworld_> suspect there will be a few branches
[01:59] <thumper> wallyworld_: start with a create-machine
[01:59] <wallyworld_> yes
[01:59] <thumper> I'll try to document our thought process above
[01:59] <wallyworld_> ok, thans
[01:59] <wallyworld_> add it to your document
[02:00] <wallyworld_> i can't wait for this stuff to mature, i really want to fire up lots of stuff on my local machine
[02:00] <thumper> yeah
[02:00] <thumper> we'll make it fully manured
[02:00] <wallyworld_> lol
[02:00]  * thumper goes to shower
[02:00] <wallyworld_> bad visual image
[02:03] <niemeyer> wallyworld_: Not too protective.. just want to give access to people actually doing good work on it.
[02:03] <niemeyer> wallyworld_: If you have stuff for it, I'll add you to the team
[02:04] <wallyworld_> niemeyer: thank you. i just wanted to make sure i wasn't stepping over any boundaries
[02:04] <niemeyer> wallyworld_: Not at all, thanks for contributing
[02:04] <wallyworld_> niemeyer: my branch fixes a user reported bug - it allows for EC2_ env vars to be reconised for credentials
[02:05] <niemeyer> wallyworld_: Oh, haven't heard of those
[02:05] <niemeyer> wallyworld_: Thanks
[02:05] <niemeyer> wallyworld_: That's done
[02:05] <wallyworld_> niemeyer: is there a landing bot or do we run tests locally and push manually
[02:05] <wallyworld_> thanks
[02:05] <niemeyer> wallyworld_: The latter
[02:06] <niemeyer> wallyworld_: "LGTM" + test + lbox submit
[02:06] <wallyworld_> niemeyer: thanks. bug 1174874 fwiw
[02:06] <_mup_> Bug #1174874: EC2_* style Amazon environment variables not consulted <juju-core:Confirmed for wallyworld> <https://launchpad.net/bugs/1174874>
[02:07] <niemeyer> wallyworld_: Huh..
[02:07] <niemeyer> wallyworld_: Where's the reference for these environment variables?
[02:07] <niemeyer> wallyworld_: I mean, who uses it?
[02:07] <wallyworld_> not sure. i know i had them set up originally when i was got my ec2 account
[02:07] <niemeyer> wallyworld_: As John points out, the EC2 tools actually use the AWS_* ones
[02:08]  * niemeyer googles
[02:08] <wallyworld_> i think they may have come from the aws account sign up perhaps
[02:08] <wallyworld_> not sure
[02:08] <wallyworld_> but i have . files with them in from ages ago
[02:08] <niemeyer> eucatools
[02:08] <niemeyer> Okay, +1
[02:08] <wallyworld_> ok, thanks
[02:09] <wallyworld_> just gives a nice robustness for the user
[02:09] <niemeyer> Yeah
[02:30] <wallyworld> niemeyer: when i run the tests, there's an issue with the test http server already being started. from what i can see, a few tests start separate test servers and don't clean up?????
[02:30] <wallyworld> this issue is unrelated to my changes but best not to land something with test failures
[02:31] <niemeyer> wallyworld: In aws_test.go?
[02:31] <wallyworld> var testServer = testutil.NewHTTPServer() is in several test files
[02:32] <wallyworld> s3_test, iam_test etc
[02:32] <wallyworld> running go test ./... from the root dir exposes the issue
[02:32] <wallyworld> example error
[02:32] <wallyworld> PANIC: s3_test.go:28: S.SetUpSuite
[02:32] <wallyworld> ... Panic: listen tcp <IP_ADDRESS>:4444: address already in use (PC=0x413D81)
[02:32] <wallyworld> /usr/lib/go/src/pkg/runtime/panic.c:229
[02:32] <wallyworld>   in panic
[02:32] <wallyworld> /home/ian/juju/go/src/launchpad.net/goamz/testutil/http.go:47
[02:32] <wallyworld>   in HTTPServer.Start
[02:32] <wallyworld> s3_test.go:29
[02:32] <wallyworld>   in S.SetUpSuite
[02:33] <wallyworld> so several tests call testServer.Start()
[02:34] <wallyworld> maybe there needs to be a Stop() method called from TearDown
[02:58] <wallyworld> niemeyer: i fixed the issue https://codereview.appspot.com/9545045
[02:58] <wallyworld> go test ./... from toor dir now works
[02:58] <wallyworld> root
[02:59] <niemeyer> wallyworld: Hmm
[03:00] <niemeyer> wallyworld: I'd prefer to not mix the two sets of variables
[03:00] <wallyworld> which variables? the listener and testServer?
[03:00] <niemeyer> wallyworld: if auth.AccessKey == "" || auth.SecretKey == "" { ... set both of them again using EC2_* ... }
[03:01] <wallyworld> oh, you mean the bug fix
[03:01] <wallyworld> ok, i can change that
[03:01] <niemeyer> wallyworld: As it is, it's mixing the two sets of variables, which may end up pretty confusing
[03:01] <wallyworld> sure, will change it
[03:01] <wallyworld> you agree with the test fixes?
[03:02] <niemeyer> wallyworld: Yeah
[03:02] <wallyworld> with the variables thing, i just did what we did for goose
[03:02] <wallyworld> so you won't agree with goose either :-)
[03:03] <niemeyer> wallyworld: I suppose :)
[03:03] <wallyworld> maybe we'll do a drive by fix sometime
[03:03] <niemeyer> wallyworld: On Stop(), might be worth adding listener = nil at the end, although that's really minor
[03:04] <wallyworld> ok
[03:28]  * thumper laughs
[03:28] <thumper> grr
[03:28] <thumper> I was going to bitch at niemeyer
[03:28]  * thumper wonders if he'll come back
[03:41] <thumper> davecheney, wallyworld: updated that branch https://codereview.appspot.com/9677044/ to follow gustavo's suggestion
[03:42]  * wallyworld looks
[03:48] <thumper> wallyworld: ta
[03:48] <wallyworld> np
[03:48] <thumper> imagine my surpise when I found a test that actually tested the use case, and it passed
[03:48] <wallyworld> another Go gotcha
[03:49] <thumper> I'm pleased it isn't idiomatic to return None in python instead of []
[03:49] <thumper> 'cause that kinda blows
[03:52] <wallyworld> yes indeed
[04:00] <wallyworld> thumper: i wonder, should the new machine being created use constraints stored in the env (for mem etc) or allow the user to specify different ones
[04:01] <thumper> yes
[04:01] <thumper> wallyworld: both
[04:01] <wallyworld> ok, so if none specified, use the env ones
[04:01] <thumper> wallyworld: specifying new ones override the existing env, but become a superset
[04:01] <thumper> not an override, but a merge
[04:02] <thumper> with specified overriding others
[04:02] <thumper> make sense?
[04:02] <wallyworld> yes
[04:02] <wallyworld> aye
[04:07]  * thumper looks at the assignment policies
[04:07] <thumper> again...
[04:08] <thumper> actually, I'll go pick up the sushi first
[04:55] <thumper> davecheney: what is our next juju-core milestone?
[06:42] <dimitern> morning all
[07:16] <TheMue> morning
[07:17] <dimitern> TheMue: hiya
[07:17] <TheMue> dimitern: just playing around with the gmail account ;)
[07:18] <dimitern> TheMue: oh, yeah?
[07:19] <TheMue> dimitern: yep, I've used the automatic filtering so far. now I've got a lot of labels for each imap folder and I want to clean it up.
[07:20] <dimitern> TheMue: i have like 60 filters in thunderbird already, didn't want to go through the hassle of migrating to gmail, so I opted out
[07:23] <TheMue> dimitern: hehe
[07:24] <TheMue> dimitern: I dislike client side filters as I access my mail (private as work) from multiple devices
[07:24] <jam> dimitern, TheMue: my point as well. I did client side for a while, but I access the account from multiple locations (phone, laptop, desktop), and client-side doesn't work so well there.
[07:25] <jam> I was trying it back when I ran my own mailserver, but server-side just works a lot better.
[07:26] <TheMue> jam: yes. I run my private mail server (for my family and some friends) too and their I also provide server-side filtering
[07:26] <jam> TheMue: gmail does ok. There are bits I'd like to be better, but at least to set up a filter you can say "filter messages like this" and it will detect the list header and set it for you from the start.
[07:26] <jam> It doesn't work with custom Launchpad headers.
[07:27] <jam> but for lists, it is quite easy to set up.
[07:28] <dimitern> rogpeppe1: ping
[07:29] <TheMue> jam: yes, looks fine so far. will now only clean up the migrated old folder. I kept too much unneeded stuff
[07:29] <rogpeppe1> dimitern: pong
[07:29] <dimitern> rogpeppe1: hey, i've been trying to figure out the correct client-side logic for the LifecycleWatcher loop, in particular when to call next initially
[07:30]  * rogpeppe1 goes to look at state.LifecycleWatcher
[07:30] <dimitern> rogpeppe1: I should call it once initially and then after the select (like in entitywatcher), right?
[07:30] <davecheney> thumper: milestone ?
[07:30] <davecheney> you mean release number
[07:30] <davecheney> nfi
[07:31] <davecheney> i hope someone tells me
[07:32] <rogpeppe1> dimitern: that sounds plausible, yes
[07:32] <rogpeppe1> dimitern: actually, no
[07:33] <rogpeppe1> dimitern: i think you should follow the pattern of entitywatcher
[07:33] <dimitern> rogpeppe1: but for that initial call I shouldn't care as much for error handling - I mean return whatever error I got from Next, otherwise for the second call (after the select), I use the same logic as in the entitywatcher loop
[07:33] <dimitern> rogpeppe1: well, I need some changes []string to send on the out channel
[07:34] <rogpeppe1> dimitern: why should the error handling be different for the first call and the second call?
[07:34] <dimitern> rogpeppe1: and the select appears before the Next call
[07:34] <rogpeppe1> dimitern: ah, yes, the logic will need to be a bit different - you'll need to set the out channel to non-nil only when you've got something to send
[07:35] <dimitern> rogpeppe1: ah, right - that tricky case
[07:35] <dimitern> rogpeppe1: so set w.out to nil initially to bypass the select and set it to not nil after i have changes?
[07:36] <rogpeppe1> dimitern: yup
[07:36] <rogpeppe1> dimitern: well, probably have a local "out" variable to do that
[07:36] <rogpeppe1> dimitern: just before the select, set it to non-nil iff there's something to send.
[07:37] <dimitern> rogpeppe1: yes, I have out := w.out; w.out = nil; var lastChanges []string
[07:37] <dimitern> rogpeppe1: and w.out <- lastChanges (both of these are set when relevant)
[07:37] <rogpeppe1> dimitern: i wouldn't ever set w.out to anything different than its original value
[07:38] <rogpeppe1> dimitern: i think it's easier to see correctness when mutable state is in local variables
[07:38] <dimitern> rogpeppe1: so use out < lastChanges instead of w.out in the select then?
[07:39] <dimitern> rogpeppe1: and have var out chan []string before the for loop
[07:39] <rogpeppe1> dimitern: no, do: for { var out chan []string; if lastChanges != nil { out = w.out }; select {case out <- lastChanges: lastChanges = nil; case lastChanges = <-in: } }
[07:39] <rogpeppe1> or something like that
[07:40] <rogpeppe1> dimitern: you'll probably need to have a loop calling Next in its own goroutine
[07:40] <dimitern> rogpeppe1: I didn't get the last "case" - why that?
[07:41] <rogpeppe1> dimitern: how are you going to receive new changes?
[07:41] <dimitern> rogpeppe1: after the select I have if changes, err := callNext(); err != nil .....
[07:42] <rogpeppe1> dimitern: you can't do that
[07:42] <dimitern> rogpeppe1: why not?
[07:42] <rogpeppe1> dimitern: because the call to Next can block indefinitely
[07:42] <rogpeppe1> dimitern: which means you won't be able to stop the watcher
[07:43] <dimitern> rogpeppe1: hmm - why is it working for the entitywatcher's loop then?
[07:43] <dimitern> rogpeppe1: no gorouting for calling next there
[07:43] <rogpeppe1> dimitern: hmm, yes. le me think a mo
[07:43] <rogpeppe1> dimitern: (the other works because Stop is called in a goroutine)
[07:44] <dimitern> rogpeppe1: i suspected as much
[07:45] <dimitern> rogpeppe1: so with the same goroutine for stop it should work w/o another for next?
[07:45] <rogpeppe1> dimitern: i don't think it would be quite right
[07:45] <rogpeppe1> dimitern: the key is in the "Note that because the change notification contains no information" comment
[07:46] <rogpeppe1> dimitern: if we don't have the Next in a separate goroutine, if the receiver is slow, we'll be trying to send stale information.
[07:47] <rogpeppe1> dimitern: we could decide that we don't care about that, but i suspect that william might not be keen
[07:47] <dimitern> rogpeppe1: hmm.. so how about having another go func() block before the loop for calling next, and moving all the logic & error handing around it there
[07:47] <rogpeppe1> dimitern: i think that sounds reasonable
[07:48] <rogpeppe1> dimitern: if it gets an error, it can kill the tomb and die
[07:49] <dimitern> rogpeppe1: thus inside the loop only the select and out channel switching will remain, and the lastChanges will be a closure used by that goroutine
[07:49] <rogpeppe1> dimitern: i think lastChanges will be a local slice variable
[07:50] <dimitern> rogpeppe1: local to the next() goroutine?
[07:50] <rogpeppe1> dimitern: local to the select loop
[07:50] <dimitern> rogpeppe1: how will the next goroutine report the changes to back?
[07:50] <dimitern> rogpeppe1: s/to//
[07:50] <rogpeppe1> dimitern: with a channel (i called it "in" above)
[07:51] <dimitern> rogpeppe1: ah! cool
[07:51] <dimitern> rogpeppe1: does it have to take it as an argument or it can be a closure?
[07:51] <rogpeppe1> dimitern: huh? "it" ?
[07:52] <dimitern> rogpeppe1: the in chan
[07:52] <rogpeppe1> dimitern: how can a channel take an argument or be a closure?
[07:54] <dimitern> rogpeppe1: sorry, i'm not explaining well enough - if I have in := make(<-chan []string); go func() { ... using in directly .. }() will it work or I have to use go func(in<-chan []string){ ... }
[07:54] <rogpeppe1> dimitern: ah, i see. yeah the former is just fine.
[07:55] <dimitern> rogpeppe1: good
[07:55] <dimitern> guys is the call now or in 1h ?
[07:55] <rogpeppe1> dimitern: i think it's in 5 mins
[07:56] <dimitern> rogpeppe1: ok, I set my calendar correctly this time :)
[07:57] <dimitern> rogpeppe1: and in addition to the in chan, i'll need a done chan error as well in the next goroutine, right?
[07:58] <rogpeppe1> dimitern: i don't think so
[07:58] <rogpeppe1> dimitern: i think you can use the tomb for that
[07:58] <dimitern> rogpeppe1: kill the tomb on error?
[08:01]  * danilos is installing latest hangout plugin :/
[08:25] <dimitern> rogpeppe1: take a look at this please http://paste.ubuntu.com/5692992/
[08:25] <dimitern> rogpeppe1: does it look sane more or less?
[08:26] <rogpeppe1> dimitern: i'll look after the meeting
[08:26] <dimitern> rogpeppe1: sure, np
[08:48] <dimitern> rogpeppe1: so?
[08:48]  * rogpeppe1 looks
[08:50] <mramm> I think if we are going to keep the containerization and API everywhere lanes, we should kill core 1 and core 2 -- the idea there was one lane per feature group anyway
[08:50] <dimitern> rogpeppe1: haven't compiled it yet (just realized I need to add panic("unreachable") in the next goroutine for go1.0x compatibility)
[08:50] <mramm> and we can move some of the existing stuff that is in the core1/2 lanes back into the backlog if they are just providing too much visual clutter
[08:51] <rogpeppe1> dimitern: i'd like to know if we still need to be go1.0.2 compatible
[08:51] <dimitern> mramm: and change the lanes as we progress down the roadmap?
[08:51] <mramm> (which I think is why thumper created the new lanes)
[08:51] <mramm> dimitern: well, I did make them generic so we don't have to change them
[08:52] <dimitern> rogpeppe1: i really don't want to care about go1.0[23] anymore, but we need to remove a lot of these panics throughout and possibly some other improvements are in order
[08:52] <mramm> but I honestly don't care, changing them occasionally is no big deal
[08:52] <thumper> mramm: if we do that, then add a general bugs lane
[08:52] <mramm> I did
[08:52]  * thumper has another call now
[08:52] <mramm> (at the top)
[08:52] <thumper> oh
[08:52] <thumper> ok
[08:52] <thumper> good
[08:52] <thumper> :)
[08:52] <rogpeppe1> dimitern: i was wondering about other stuff. for instance my recent tasks branch uses a go1.1 feature
[08:53] <rogpeppe1> dimitern: (method values)
[08:53] <dimitern> we should've brought that up in the call, i just realized now
[08:54] <dimitern> let's make it official and send a mail to juju-dev "We're now using go1.1 only"
[08:55] <dimitern> TheMue, davecheney, jam, mgz, rogpeppe1, danilos, wallyworld_, mramm: any objections to the above? ^^
[08:55] <wallyworld_> Go for it :-)
[08:55] <rogpeppe1> dimitern: code looks reasonable
[08:55] <wallyworld_> the sooner the better
[08:56] <rogpeppe1> dimitern: i might be tempted to factor out the Next error handling logic into a function, so it's not duplicated
[08:56] <jam> wallyworld_, dimitern: I believe the original discussion ended in "we'd like to be able to compile with the platform tools". Already it is really hard to backport to precise.
[08:56] <jam> because we don't have the tool there.
[08:56] <danilos> dimitern, if we've got golang packages lined up for people wanting to do development on precise and raring, I am +1
[08:56] <jam> But if 1.1 is officially at least in Saucy, we can probably go with it.
[08:56] <jam> And then we have to backport 1.1 for at least P, and probably Q and R
[08:56] <mgz> dimitern: only?
[08:56] <wallyworld_> can we put 1.1 in backportsd?
[08:56] <jam> mgz: his point was only
[08:56] <mgz> how do we get that on prrecise?
[08:56] <jam> mgz: he just wants to make the release process harder on you. :)
[08:57] <jam> mgz: the same way we'll get != go 1.0 ?
[08:57] <jam> mgz: arguably if we have to do something to get go 1.0.3, we might as well get 1.1
[08:57] <jam> instea
[08:57] <jam> instead
[08:57] <mgz> I'm not *sure* we do yet...
[08:57] <rogpeppe> mgz: go1.1 works fine on precise - you just won't be able to use the standard golang package
[08:57] <jam> mgz: I'm about 75% sure go 1.0 won't pass the test suite.
[08:57] <mgz> but we could SRU an new minor version, a new major version would be... not sruable
[08:58] <jam> (as I have precise and I have to install go from the ppa to work on juju-core)
[08:58] <jam> I *know* lbox is broken with go 1.0, I think juju-core might be as well.
[08:58] <dimitern> so the agreement is not yet there - ok then, to early for an announcement on the list
[08:58] <wallyworld_> mgz: major = .x ?
[08:58] <dimitern> rogpeppe: what is duplicated about the error handling?
[08:58] <jam> mgz: so I do believe that go 1.1 is source-compatible with go 1.0
[08:58] <wallyworld_> dimitern: if stuff being committed break with 1.0.3, we should tell people
[08:59] <mgz> jamespage is shaking his head
[08:59] <jam> it is intended to be, at least, because of the "minor" bump
[08:59] <rogpeppe> dimitern: it's exactly the same logic as in EntityWatcher.loop
[08:59] <mgz> we can't use backports
[08:59] <rogpeppe> i feel strongly that we should move to using go 1.1
[08:59] <dimitern> rogpeppe: ah, good point, ok
[08:59] <mgz> when you do a backport, it doesnt build against backported packages
[08:59] <jam> mgz: because of the bug that backports can't build with other backports?
[08:59] <mgz> jam: indeed
[09:00] <rogpeppe> but if it's not possible to backport to precise, then perhaps we should stay away from 1.1-specific features
[09:01] <mgz> wallyworld_: I'm reading "1.1" as major and "1.0.3" as minor, but it's all pretty fuzzy, the policies of the project matter more than the actual numbers
[09:01] <rogpeppe> that means we should probably gate commits on 1.0.3 compatibility
[09:01] <mgz> rogpeppe: I'm not sure what the current status is, or what our priorities are
[09:01] <wallyworld_> yeah :-(
[09:02] <jam> rogpeppe: so while I agree that use 1.1 when available, especially for official binaries. However, is there something in 1.1 which would prevent it working with 1.0.3 compiler?
[09:02] <jam> I thought it was at least supposed to be syntactically the same.
[09:02] <jam> maybe lib changes?
[09:02] <rogpeppe> jam: there are language additions, yes
[09:02] <mgz> if we want newest juju installable on precise without a ppa, that then does make what version of go we run against more limited, unless we have other workarounds
[09:02] <rogpeppe> jam: 1.0.3 code is compatible with 1.1 but not vice versa
[09:03] <dimitern> jam: e.g. panic("unreachable") is no longer needed in funcs with a for loop + select only  (most of the watchers, etc.) - it's a compile error in go1.0.3, not in go.1.1; there are nice features we can use in go1.1
[09:04] <dimitern> and there's the performance improvements, method values, race detection..
[09:05] <rogpeppe> jam: another nice feature is you can use a method as a value (it becomes a closure like you might expect)
[09:06] <rogpeppe> jam: the changes are all here: http://golang.org/doc/go1.1
[09:06] <jam> dimitern: performance improvements and race detection can be used without changing syntax
[09:07] <jam> method values are nice, but you can use closures, and not having panic is also nice but a bit trivial
[09:07] <dimitern> jam: true, but if we're not allowed to use go1.1 due to (stupid?) packaging/backporting issues..
[09:07] <jam> so I think stating that for now, 1.0.3 compatible, but use 1.1 when you like.
[09:07] <rogpeppe> jam: the issue i have is that it's very easy to fall outside 1.0.3 compatibility.
[09:07] <jam> rogpeppe: thats what the bot is for
[09:08] <jam> If it is running precise (the one I have currently is), then we have that gate in place already.
[09:08] <rogpeppe> jam: so the bot would test against 1.0.2 and 1.1 ?
[09:09] <jam> rogpeppe: I would tend to not do a multi-compiler pre-commit check, though that could be done.
[09:09] <jam> right now, goose is still 1.0 compatible (and passes the test suite there)
[09:09] <jam> so I didn't have to even try to get 1.0.2/3 there.
[09:09] <dimitern> rogpeppe: how about http://paste.ubuntu.com/5693088/?
[09:11] <jam> rogpeppe: the issue is trading off time-to-land-in-trunk with how much you expect to actually benefit from spending the time. A CI system is much better at doing multiple-platform-and-compiler level testing, vs the pre-commit testing
[09:11] <rogpeppe> jam: right
[09:11] <jam> so the "most expected platform/system" is the pre-commit check, and the CI lets you know that you could release this across all your supported platforms.
[09:11] <jam> you could certainly do 1.0.3 in CI, but I would put that in "most expected to fail" vs 1.1
[09:13] <rogpeppe> dimitern: how about this instead? http://paste.ubuntu.com/5693094/
[09:14] <rogpeppe> dimitern: oops, with a tomb argument too, i guess
[09:14] <dimitern> rogpeppe: yeah
[09:15] <dimitern> rogpeppe: and the call()?
[09:15] <rogpeppe> dimitern: i think that bundling the error checking with the call itself makes for a slightly more coherent function
[09:15] <rogpeppe> dimitern: see callWatch in EntityWatcher.loop
[09:16] <dimitern> rogpeppe: so call has the be an arg as well - call func() error
[09:16] <rogpeppe> dimitern: with one extra argument
[09:16] <rogpeppe> dimitern: yeah, you'd do: if err := watcherNext(call, &w.tomb); err != nil {w.tomb.Kill(err)}
[09:17] <dimitern> rogpeppe: what if we have a commonWatcher with next() error and pass that instead? or even make this a method of the commonWatcher & embed it in both watchers?
[09:18] <dimitern> rogpeppe: having commonWatcher will allow all this to be handled inside it's next() method
[09:18] <rogpeppe> dimitern: i'm not sure i see a particular advantage in using a commonWatcher type rather than a closure
[09:19] <rogpeppe> dimitern: but there may be something i'm not seein
[09:19] <rogpeppe> g
[09:19] <dimitern> rogpeppe: well, there are going to be at least 3 watchers with this logic - entity, life and environconfig
[09:20] <rogpeppe> dimitern: what do you see going into commonWatcher other than next() ?
[09:20] <dimitern> rogpeppe: right, we need different next calls for each one
[09:20] <rogpeppe> dimitern: anything else?
[09:21] <dimitern> rogpeppe: so watcherNext(call func(method string, result interface{}), err error, wtomb *tomb.Tomb) error {..} then
[09:22] <rogpeppe> dimitern: watcherNext(call func(method string, result interface{}) error, wtomb *tomb.Tomb) error {..}
[09:22] <rogpeppe> dimitern: i think
[09:22] <dimitern> rogpeppe: oh yeah, the err is internal now
[09:22] <dimitern> rogpeppe: sgtm
[09:22] <rogpeppe> dimitern: i may very well change my position on commonWatcher if we find more stuff that can be factored out
[09:23] <rogpeppe> dimitern: but for the time being, i think it makes things less obvious and would use more code
[09:24] <rogpeppe> dimitern: actually, i think i see a way to factor out almost all of the code
[09:25] <dimitern> rogpeppe: except next is different for each watcher - entitywatcher returns nothing but an error, while the lifecyclewatcher returns a slice as well
[09:25] <rogpeppe> dimitern: i think entitywatcher is different
[09:25] <rogpeppe> dimitern: i'm thinking about other watchers that all return some actual data
[09:26] <dimitern> rogpeppe: so?
[09:26] <rogpeppe> dimitern: go with just factoring out the next call for the time being.
[09:27] <rogpeppe> dimitern: the other factor can be done with the next watcher
[09:27] <dimitern> rogpeppe: you mean factoring out only the error handling, and not call next() inside it?
[09:28] <rogpeppe> dimitern: no, i mean call next inside it, as i suggested. i *think* that looks nicer.
[09:28] <dimitern> rogpeppe: what about the results?
[09:28] <rogpeppe> dimitern: that's just an extra arg
[09:29] <dimitern> rogpeppe: no, i mean we should return error & the results we got, right?
[09:29] <rogpeppe> dimitern: ha, good point.
[09:30] <rogpeppe> dimitern: watcherNext(results interface{}, call func(method string, result interface{}) error, wtomb *tomb.Tomb) error
[09:31] <dimitern> rogpeppe: yeah, sgtm
[09:52] <dimitern> rogpeppe: params.EnvironConfigWatcherNextResults :) that starts to look like java
[09:53] <rogpeppe> dimitern: :-)
[09:53] <rogpeppe> dimitern: at least you'll only be using it in about two places
[09:54] <dimitern> rogpeppe: yeah
[09:58] <dimitern> rogpeppe: I can think a couple of cases where commonWatcher is useful
[09:58] <dimitern> rogpeppe: e.g. Stop() and Err() are the same
[09:58] <rogpeppe> dimitern: i've got a suggestion coming up
[09:58] <dimitern> rogpeppe: in addition we can have callNext call as a field in commonWatcher as well
[10:01] <dimitern> rogpeppe: and the tomb and wg
[10:02] <dimitern> and st
[10:02] <dimitern> rogpeppe: although "commonWatcher" might be incorrect, as it's just a few bits of common code extracted, but not a complete watcher
[10:05] <dimitern> rogpeppe: maybe "watcherBase" is better - we can have the go func() { .. spin the loop } in newBaseWatcher
[10:05] <rogpeppe> dimitern: something along these kinds of lines? http://paste.ubuntu.com/5693203/
[10:06] <mgz> was there a message to list about the code.google.com/p/go.crypto dep?
[10:06] <rogpeppe> dimitern: it's not *quite* right, but i think it's not too bad
[10:07] <rogpeppe> mgz: i don't remember one
[10:08] <dimitern> rogpeppe: mostly ok, except for a few things
[10:09] <dimitern> rogpeppe: call needs to handle the case when results is nil
[10:09] <rogpeppe> dimitern: i think it does that ok, doesn't it?
[10:09] <mgz> we should probably do such things when adding deps
[10:10] <dimitern> rogpeppe: not sure - shouldn't the last arg of st.call be &results ?
[10:10] <rogpeppe> dimitern: i don't think so
[10:11] <rogpeppe> dimitern: result is already a pointer (created by the newResults function)
[10:11] <dimitern> rogpeppe: ah, ok
[10:11] <dimitern> rogpeppe: should work then
[10:12] <rogpeppe> dimitern: actually, i think there's another way of avoiding a bit more work in each watcher
[10:12] <rogpeppe> dimitern: one mo
[10:13] <dimitern> rogpeppe: how about overriding init() and setting there the out chan, call and newResult? then we can just spin up the loop goroutine right after that
[10:14] <rogpeppe> dimitern: i'm not quite sure what you mean
[10:14] <dimitern> rogpeppe: i'd like to factor out this somehow as well: http://paste.ubuntu.com/5693224/
[10:15] <dimitern> rogpeppe: except out's type is different so it won't work probably (damn generics!)
[10:16] <rogpeppe> dimitern: yeah, i think the wg.Wait can go (suggestion in a moment) but the rest should probably stay
[10:29] <rogpeppe> dimitern: marginally better, perhaps: http://paste.ubuntu.com/5693269/
[10:33] <dimitern> rogpeppe: nice; only in the case of if !ok { should return some error }
[10:34] <rogpeppe> dimitern: no need to return an error - the tomb will already have been killed with an appropriate error
[10:34] <dimitern> rogpeppe: and this will work for entitywatcher as well, right?
[10:35] <dimitern> rogpeppe: it won't compile with just "return"
[10:35] <rogpeppe> dimitern: i think it will. it won't be *quite* as efficient, but i don't think we mind.
[10:35] <rogpeppe> dimitern: yeah, it should be return nil probably
[10:36] <dimitern> rogpeppe: ok, and i'll put a comment about the tomb there as well
[10:36] <dimitern> rogpeppe: thanks
[10:36] <rogpeppe> dimitern: np
[10:56] <dimitern> rogpeppe: so if we return nil from the loop, and in commonLoop we already killed the tomb with an error, won't the "return nil" wipe out that original error?
[10:57] <rogpeppe> dimitern: no
[10:57] <rogpeppe> dimitern: the first non-nil, non-ErrDying error will stick
[10:59] <dimitern> rogpeppe: i see, ok
[10:59] <dimitern> rogpeppe: wasn't immediately obvious for me looking at tomb.Kill
[11:03] <rogpeppe> dimitern: rtfm :-)
[11:03] <rogpeppe> dimitern: http://paste.ubuntu.com/5693339/
[11:05] <dimitern> rogpeppe: isn't w.commonWatcher.init() the same as w.init() ?
[11:05] <rogpeppe> dimitern: yeah. i guess i prefer the explicitness there.
[11:05] <dimitern> rogpeppe: sure
[11:23] <dimitern> rogpeppe: so either the TestMachineWatch logic is wrong or the commonLoop logic is wrong, because Next never returns an inital event
[11:24] <rogpeppe> dimitern: interesting. the Next call is being made and doesn't return?
[11:24] <dimitern> rogpeppe: yes - it returns only after the timeout
[11:25] <dimitern> rogpeppe: http://paste.ubuntu.com/5693378/ - added debug logs after next returns and one after sending to in
[11:26] <rogpeppe> dimitern: ah, this is interesting. it looks like i designed it that way deliberately.
[11:26] <dimitern> rogpeppe: :) so? is the test wrong or the loop?
[11:26] <rogpeppe> dimitern: look at srvMachine.Watch - it reads the channel
[11:27] <dimitern> rogpeppe: yeah, it does, but shouldn'y
[11:28] <rogpeppe> dimitern: actually, i think it should
[11:28] <rogpeppe> dimitern: and i think the test is right, as is the current loop
[11:28] <rogpeppe> dimitern: the suggested implementation should be different though
[11:28] <dimitern> rogpeppe: what then?
[11:29] <dimitern> rogpeppe: it shouldn't call next initially?
[11:29] <rogpeppe> dimitern: we should return the initial data with the initial watch request
[11:29] <rogpeppe> dimitern: so that we don't do two round-trips whenever we start a watcher
[11:29] <rogpeppe> dimitern: that was the reason for doing things this way anyway
[11:30] <dimitern> rogpeppe: saving a roundtrip seems sane
[11:30] <jam> danilos, wallyworld_, w7z: poke
[11:31] <dimitern> rogpeppe: but what does this mean for the loop?
[11:32] <rogpeppe> dimitern: something like this: http://paste.ubuntu.com/5693401/
[11:32] <dimitern> rogpeppe: move the next call after the select and have in := w.in
[11:32] <dimitern> rogpeppe: ah, right
[11:34] <dimitern> rogpeppe: but for the entitywatcher, this should be changes := struct{}{} instead
[11:35] <rogpeppe> dimitern: no need to have a changes variable for the entity watcher
[11:35] <dimitern> rogpeppe: wait, so the entitywatcher is the one not working, haven't written tests for the others yet
[11:36] <rogpeppe> dimitern: the entity watcher was working before, right?
[11:36] <dimitern> rogpeppe: yes
[11:36] <dimitern> rogpeppe: for the lifecycle and environconfig watchers what you suggested should work
[11:36] <rogpeppe> dimitern: so you're just changing it to use the commonWatcher to start with?
[11:38] <dimitern> rogpeppe: yes, but the entitywatcher doesn't have results, so calling etype, eid, "Watch" won't report anything
[11:39] <dimitern> rogpeppe: maybe you meant out = w.out initially for entitywatcher loop
[11:39] <dimitern> rogpeppe: yeah, it works like this
[11:39] <rogpeppe> dimitern: the entitywatcher loop will be a bit different
[11:40] <dimitern> rogpeppe: that was the only change needed
[11:40] <dimitern> rogpeppe: the test now pass
[11:40] <rogpeppe> dimitern: cool
[11:47] <dimitern> rogpeppe: so the same has to be applied for lifecycle and environconfig watchers? calling Changes in Watch* at server-side?
[11:48] <rogpeppe> dimitern: yeah, i think so
[11:48] <rogpeppe> dimitern: it's probably worth checking that all those things always produce an initial event
[11:48] <dimitern> rogpeppe: so the params.*WatcherId should embed params.*WatcherNextResults then
[11:49] <wallyworld__> jam: you forgot to ask me what i did, but that's ok. one thing for you - i talked to is about the rt, got the cc list updated, and they have also bumped its priority so hopefully will be done real soon now
[11:50] <jam> wallyworld__: yay, sorry I missed you. You had been talking about landing your other branches, so I thought you were done. But good to hear about the rt.
[11:50] <rogpeppe> dimitern: i don't think you can embed it, but yes, the same value should be there. and i'd probably call it, e.g. params.LifecycleWatchResults
[11:50] <rogpeppe> rather than WatcherId
[11:50] <dimitern> rogpeppe: ok
[11:51] <wallyworld__> jam: i also fixed goamz - tests weren't cleaning up and so were failing, and i didn't want to land my changes without fixing even though my changes weren't responsoble
[11:51] <jam> wallyworld__: so instead of cleaning up at the start of the test we cleanup at the end?
[11:51] <wallyworld__> jam: each test was creating a socket and then just leaving it opened and not closing, so subsequent tests would fail
[11:52] <wallyworld__> so i added cleanup to the suite teardown
[11:52] <dimitern> rogpeppe: and afaics both lifecycle and environconfig watchers send initial event
[11:52] <wallyworld__> jam: also talked to tim about containerisation, agreed on some work items,  and started work on the first branch
[12:01] <frankban> rogpeppe, anyone else: it seems there is something like a logging loop in machine 0 when you use --force-machine. /var/log/juju/all-machines.log grows about 2 MB per second. and debug-log is unusable
[12:02] <rogpeppe> frankban: what are all those log messages?
[12:03] <frankban> rogpeppe: it seems to repeat the same messages again and again (e.g. messages from hooks execution)
[12:03] <rogpeppe> frankban: what messages?
[12:07] <dimitern> rogpeppe: should I use params.LifecycleWatchResults for both Watch* and Next then ?
[12:07] <frankban> rogpeppe: http://pastebin.ubuntu.com/5693483/ just an example. the problem is the same logs are repeated in a loop.
[12:07] <dimitern> rogpeppe: and just pass the id in next as well
[12:08] <rogpeppe> dimitern: i suppose you could. or just leave the id blank for next.
[12:08] <dimitern> rogpeppe: ok
[12:08] <rogpeppe> frankban: could you paste the log with at least 3 repetitions of the cycle, so i can get an idea for what's going on, please?
[12:09] <rogpeppe> s/the log/a portion of the log/
[12:11] <frankban> rogpeppe: sure, grabbing it. however, to dupe: bootstrap a juju-core env, deploy wordpress (or the GUI) using --force-machine 0.
[12:16] <frankban> rogpeppe: http://pastebin.ubuntu.com/5693508/
[12:17] <rogpeppe> frankban: thanks
[12:18] <frankban> np
[12:18] <frankban> .me lunches
[12:33] <dimitern> rogpeppe: I don't have to add tests like TestServerStopsOutstandingWatchMethod for the other watchers, right?
[12:34] <rogpeppe> dimitern: looking
[12:35] <rogpeppe> dimitern: i think that functionality should be tested for each watcher actually
[12:36] <rogpeppe> dimitern: i think it's probably possible to make the test code generic though
[12:36] <dimitern> rogpeppe: but all of them are resources and handled all the same in stopAll, right?
[12:36] <rogpeppe> dimitern: that test is more about testing the client-side stop logic actually
[12:37] <rogpeppe> dimitern: stopAll isn't invoked in that test, i don't think
[12:37] <rogpeppe> dimitern: oops
[12:37] <rogpeppe> dimitern: sorry, i'm wrong
[12:38] <dimitern> rogpeppe: it's on the server side when stopping
[12:38] <dimitern> rogpeppe: so I can transform that test into a table-based with setup funcs for each watcher
[12:39] <rogpeppe> dimitern: it might be good to make that test something that starts one of every kind of watcher, and checks to see that they're all torn down appropriately when the server is stopped.
[12:40] <dimitern> rogpeppe: by "torn down" you mean returning CodeStopped, right?
[12:41] <rogpeppe> dimitern: yeah.
[12:41] <dimitern> rogpeppe: ok
[12:41] <rogpeppe> dimitern: i'd start all the watchers at once, then tear down the state just once.
[12:42] <dimitern> rogpeppe: yeah, so some state setup code first, start all & wait for initial events from everyone, then stop the server and try calling changes on each one and check for CodeStopped
[13:08] <jam> mgz: we missed you earlier. How's your day going?
[13:10] <mgz> fighting dpkg a little, otherwise okay
[13:11] <mgz> (should have mentioned I'd be out over lunch, but you probably saw me discussing that with gavin)
[13:12] <jam> mgz: so are there plans to get go-1.0.2 or 3 into precise?
[13:13] <jam> I think we have a failure in the test suite from using go-1 in gobot
[13:13] <jam> (it fails reliably on gobot, but succeeds on my local machine)
[13:17] <mgz> not currently, but we could form some
[13:18] <mgz> we're the only people who'd drive that, juju is the only real user for go in precise
[14:04] <dimitern> rogpeppe, mramm: kanban?
[14:04] <rogpeppe> dimitern: ah, good point
[14:12] <mgz> jam: the go bot kinda hates life it seems
[15:40] <jam> mgz: well, its doing things slightly differently than what the rest of us have all worked around manually.
[16:16] <dpb1> Hi all -- I'm getting an error with the latest updated juju-core: http://paste.ubuntu.com/5694171/  <-  What am I missing?  (I'm using the 'cstack' environment)
[16:17] <dpb1> Man, I just enabled mouse mode for weechat and byobu.  It's working really great.  Even cut and paste is working better now.
[16:17] <dpb1> wow, that was the wrong window.
[16:22] <rogpeppe1> dpb1: mgz or jam or dimitern might know what's going on there
[16:25] <mgz> looks like the container was not marked public...
[16:29] <mgz> dpb1: can you pastebin `nova endpoints` with your novarc sourced? I'm assuming e8231fcc9d9546c9961caf858676ea4e is your tenant id
[16:31] <dpb1> checking
[16:32] <dpb1> mgz: http://paste.ubuntu.com/5694222/
[16:32] <mgz> dpb1: for now, you can probably just set public-bucket-url... though I just checked and that seems to not have the streams data
[16:33] <mgz> dpb1: can you file a bug please?
[16:33] <dpb1> mgz: sure, what I have in those two pastes enough?
[16:33] <dpb1> mgz: also, what should I set public-bucket-url to?
[16:36] <mgz> https://swift.canonistack.canonical.com/v1/AUTH_526ad877f3e3464589dc1145dfeaac60
[16:37] <mgz> right, I'm off now
[16:37] <mgz> may be around later tonight
[17:12] <hatch> umm well we are still on the upswing of this project so we have a support team of 5 and a core team of 7
[17:12] <hatch> so 12 fulltime
[17:13] <hatch> plus some floaters if needed for specific things we don't have the experience for already
[17:13] <hatch> damn
[17:25]  * rogpeppe1 is very happy with the new Task abstraction
[18:56] <rogpeppe1> anyone around to review a branch that i think's trivial that unbreaks trunk for go 1.0.* ?
[18:56] <rogpeppe1> if so, it's at https://codereview.appspot.com/9682047
[21:05] <thumper> morning
[21:11] <kyhwana> Yep *chugs coffee*
[23:19] <thumper> niemeyer: you around?


[12:57] <bittin> Upgrading my test VM to noble atm :)
[13:23] <bittin> https://cdn.discordapp.com/attachments/1034064478762967080/1167815623506661427/Ubuntunumbat.png