[00:03] <justme_> ogra_cmpc / LaserJock: once the LTSP is installed, to make it into an edubuntu LTSP, you would still continue on and install the edubuntu addon CD... ON the server, correct?
[00:03] <justme_> and then as for clients machines, the method would be to install the regular ubuntu desktop (or using alternate I imagine would work), and then once in the gui, use the addon CD on the client?
[00:16] <justme_> err.. nevermind, heh.. clients are dhcp/pxe boots ;p
[00:44] <lns> justme_, afaik you don't need the CD per-se, just install edubuntu packages (don't recall which ones specifically) to turn ubuntu-ltsp into edubuntu (just depends on lots of edu apps & theme type things)
[01:03] <LaserJock> edubuntu-desktop
[01:03] <LaserJock> lns: ^^
[01:09] <lns> LaserJock, ty =)
[01:09] <lns> haven't done that in a while
[01:10] <LaserJock> you can also do edubuntu-desktop-kde if you have a bent that way
[01:23] <pygi> LaserJock, !
[01:23] <pygi> hey :)
[03:01] <justme_> oke.. I've run the installer off the alternate CD to install the LTSP server, but having issues near the end of the installation:
[03:02] <justme_> its trying to build the LTSP root, and keeps failing (even after I remove the /opt/ltsp/i386 folder so it can try again)
[03:02] <justme_> reading the last couple lines of the syslog, it says something about getting unexpected data at the end of /etc/apt/apt.conf.d/Proxy:2:
[03:03] <justme_> I checked that folder, and there is no files with proxy in their name, or as text inside any of the files in there, there is however:
[03:03] <justme_> /etc/apt/apt.conf that has a single line in it, and its my local proxy that I put in during the early part of the installation
[03:03] <boog> have you tried a complete fresh install?
[03:04] <justme_> this is a fresh install
[03:04] <boog> so you connect thru a proxy server?
[03:04] <justme_> the first install died on 2% of configuring en-language-base or something, this is the 2nd one now
[03:04] <justme_> I do to increase speeds when doing repetitive things, yes
[03:04] <justme_> so I'm assuming i've found a bug :(
[03:05] <justme_> I tried removing the single line (its the only line in the file) in the /etc/apt/apt.conf file, and deleted the i386 folder, and re-ran creation, but it still failed with the same error
[03:05] <boog> I have never configured edubuntu to use a proxy server.
[03:06] <justme_> I was hoping it was an easy fix and I wasn't going to have to go through the whole process again because one part of the process took forever because it downloaded part of openoffice during the installation.. I guess because there was a newer version, and either my inet is acting up (slow), or the servers are slow
[03:07] <justme_> and it took a long time at 90% of the installation where it simply said "please wait" .. with nothing else on the screen, but thankfully I have a little patience and knowledge,
[03:07] <justme_> and went and looked on another terminal and noticed that there was still network traffic on the ethernet interface, and then checked the syslog, and it showed that it was downloading some files
[03:07] <boog> could you install it without the proxy server just to know you have it working, or is that out of the question
[03:08] <justme_> its not out of the question, its just another hour away from finishing if it downloads those openoffice updates during the installation again
[03:08] <boog> I understand.  Can someone else here offer some advice?
[03:08] <justme_> and I am kind of short on time tonight, I had set a deadline for myself of 6pm.. and its already 7pm :p
[03:08] <justme_> my evening is quickly running away
[03:10] <justme_> how does one run the ltsp root creation after installation? .. because maybe I can finish the install (it looks like just grub is left to go), and then
[03:11] <justme_> run the updates and maybe these updates will fix the issue.. but I would need to be able to create the ltsp root after running all the updates
[03:17] <justme_> with a little googling, is this what i'd be wanting to use after running the updates? ltsp-update-image
[03:20] <LaserJock> probably
[03:28] <ToddEDM> is there a hardy beta of edubuntu?
[03:28] <LaserJock> yes
[03:30] <ToddEDM> where could i download it from?
[03:31] <LaserJock> http://releases.ubuntu.com/edubuntu/hardy/
[03:34] <ToddEDM> addon cd?
[03:35] <LaserJock> yeah
[03:35] <ToddEDM> can this just be installed to a blank HDD?
[03:35] <LaserJock> ToddEDM: are you after an LTSP server?
[03:35] <ToddEDM> no
[03:35] <LaserJock> no
[03:35] <ToddEDM> ok
[03:35] <LaserJock> you need an Ubuntu system first
[03:36] <ToddEDM> ok
[03:38] <justme_> ToddEDM, I just made a blog post about this: http://gumptravels.blogspot.com/2008/04/installing-ubuntu-804-ltsp-or-edubuntu.html
[03:38] <justme_> a few hours ago
[03:38] <justme_> i was looking for the same info :)
[03:38] <ToddEDM> ok cool, i will have a read
[03:39] <ToddEDM> so can edubuntu run in kiosk mode... im setting it up for a 6 year old
[03:40] <ToddEDM> i dont want him to mess with anything else
[03:41] <LaserJock> you can try pesselus and sabayon to lock down the machine
[03:42] <justme_> ToddEDM: I just realized you were just looking for edubuntu desktop, not the server.. my bad
[03:43] <justme_> the blogpost is only about the server side of things
[03:43] <justme_> as LaserJock said, you simply need a running hardy installation and then get the addon CD
[03:43] <justme_> a running desktop installation that is... with gui :)
[03:44] <justme_> you can also try just installing the edubuntu-desktop or edubuntu-desktop-kde meta packages which will install their respective counterparts of edubuntu for gnome or kde
[03:45] <justme_> if you didn't want to download and burn the addon CD
[08:00] <generalsnus> heyas
[08:01] <generalsnus> i can get thin clients to boot from edubuntu server out of the box, but how can i get workstations installed with edubuntu to authenticate against the server?
[10:21] <ogra_cmpc> justme____, could you file a bug about the proxy issue you had during install and attach /var/log/installer/syslog as well as /var/log/ltsp-image-build.log ?
[11:51]  * highvoltage waves hello from the middle east
[11:51]  * kgoetz waves hello to highvoltage
[11:53] <ogra_cmpc> highvoltage, how much in the middle of this east thing are you ?
[11:56]  * RichEd puts a tea towel on his head and throws a brick at highvoltage ...
[11:57] <RichEd> bahrein ? is that the .br extension
[11:59] <RichEd> .bh
[11:59] <RichEd> From Wikipedia, the free encyclopedia
[11:59] <RichEd> .bh is the Internet country code top-level domain (ccTLD) for Bahrain. It is administered by BATELCO.
[11:59] <RichEd> ^ jonathan2<EMAIL_ADDRESS>[12:00] <ogra_cmpc> .br would be brazil ... but there you have to go a lot more eastern to get to it ... thats hardkly the middle
[12:01] <RichEd> sorry .br was a typo ... .bh is correct
[12:01] <ogra_cmpc> yeah
[12:11] <highvoltage> ogra_cmpc: I'm in Bahrain, quite north of it, I think
[12:11] <highvoltage> RichEd: yep, .bh :)
[12:12] <RichEd> highvoltage: i guessing that the womenfolk in .bh dress quite differently to their counterparts in .br ... despite a similar beach weather
[12:13] <ogra_cmpc> RichEd, did your zsync work btw ?
[12:13] <ogra_cmpc> seems amitk has massive problems getting his img updated
[12:15] <highvoltage> RichEd: well, we were at a party last night where a lot of lebanese and arabic girls were wearing close to nothing :)
[12:20] <RichEd> ogra ... no ... it was a mess ... trying again today & tomorrow
[12:21] <RichEd> power & adsl been bouncing this week ... which brings up a question ...
[12:21] <RichEd> if i lose my connection, do i reissue the zsync command, and will it resume or start over?
[12:21] <ogra_cmpc> RichEd, but the zsync command generally worked for you ?
[12:21] <RichEd> ogra_cmpc: it looked like it ... but none of the checksums matched :(
[12:21] <ogra_cmpc> indeed, if  you resumed that might happen
[12:22] <ogra_cmpc> i'm just trying to help amit
[12:22] <ogra_cmpc> who doesnt seem to get zsync to even start the download
[12:22] <ogra_cmpc> if i use his command it starts fine here showing a progressbar made of #'s and an ETA
[12:23] <ogra_cmpc> do you remember seeing something like that ?
[12:25] <RichEd> yep ... 2 action sections if i remember
[12:25]  * ogra_cmpc thinks the classmate image will be very buggy ... nobody apart from kevin does actual tests
[12:25] <RichEd> a checking process ...
[12:25] <RichEd> then the actual get ... with % and ETA and ##### ...
[12:26] <ogra_cmpc> ... anhd thrusday the time for normal bugfixes is over ... bugs that i dont see personally wont be fixed
[12:26] <RichEd> i would love to test ... and replace the image i have that hangs randomly at the time of most annoyances
[12:27] <ogra_cmpc> RichEd, well, i know you have probs, but we gave out 20 cmpcs or so ... apart from kevin i didnt get any general testing ... mvo and asac tested their apps only (firefox, gnome-app-install) and are both to busy to force them into general testing
[12:28] <ogra_cmpc> but anyway i dont have any high hope to get more feedback over the weekend
[12:28] <RichEd> i've got an 8 year old and 6 year old testing crew lined up ... on school hols ... lots of time and ideas on how to break it
[12:32] <ogra_cmpc> LaserJock, do you happen to be around ?
[12:40] <RichEd> ogra_cmpc: heard about this ? just in from Gerry
[12:40] <RichEd> http://www.stuermer.ch/blog/promising-times-for-ubuntu.html
[12:40] <RichEd> stgraber: you aware of that ^ 9000 Ubuntu machines in geneva schools
[12:42] <ogra_cmpc> nice
[13:38] <ogra_cmpc> RichEd, extremadura (spain) installs 4000 debian ltsp servers this year (they just flew vagrant in to help them set this up)
[14:26] <pygi> yea. extramadura is amazing ogra_cmpc
[14:26] <pygi> I had a chance to talk with a folk that was setting this up
[14:40] <highvoltage> wow.
[14:50] <RichEd> ogra_cmpc: any idea why debian vs ubuntu ... is debian still considered "barer & more stable" than the user geared ubuntu ?
[14:50] <RichEd> i'm talkin about perception, not reality :)
[14:52] <pygi> highvoltage, what is it? :)
[14:53] <pygi> RichEd, because ubuntu still hasn't proven itself as a server platform? :)
[14:55] <highvoltage> pygi: wow @ extremadura, I think it's cool what they are doing, didn't know about it before.
[14:56] <highvoltage> pygi: strange that they're not using ubuntu though.
[14:59] <pygi> highvoltage, isnt Guadalinex based on ubuntu these days?
[15:00]  * pygi thinks it is
[15:38] <LaserJock> ogra_cmpc: I'm just "lurking"
[20:00] <achandrashekar>  Hi all. I have a dual ltsp setup with ldap/ltsp on one box and ldapclient/ltsp on the other. all other clients receive dhcpoffer by either server. Anyhow...when adding ldap accounts on the master...it takes an inordinate time in shell before i get the next prompt..as well some accounts take at least 3 mins to login in. Any ideas where the probmen may be? I looked at resolv.conf and hosts file and that part appea
[20:00] <achandrashekar> rs to
[20:00] <achandrashekar>   be correct...so not sure? Any help would be great.
[20:01] <kgoetz> what takes a long time, for users to login for for slapd to create the user?
[20:01] <achandrashekar> kgoetz: both
[20:02] <achandrashekar> kgoetz: i guess its a two part problem..so hence..maybe focus on ldap auth issue?
[20:02] <kgoetz> odd. user creeation should be almost instantanious (especially if its a small directory)
[20:03] <achandrashekar> yeah... here is a problem though that may be associated with it
[20:03] <kgoetz> are clients on the ldap server logging in ok?
[20:04] <achandrashekar> Some idiot (not me)..had plugged in alot of clients to a powerstrip that caused a power failure earlier in the week. On the master server....i  couldnt get it to boot up and had to use fsck to fix inodes.
[20:05] <achandrashekar> So..that is the start of the problem
[20:05] <achandrashekar> i thinks
[20:06] <achandrashekar> ;)
[20:06] <achandrashekar> So im not sure if the powerfailure affected the ldap database?
[20:07] <kgoetz> potentially yes
[20:07] <kgoetz> if it was in use at the time especially
[20:07]  * kgoetz shudders at the description of the servers location
[20:08] <achandrashekar> yeah...that was Unusually and unfortunately connected to same strip as other clients
[20:08] <achandrashekar> pretty f'ing ridiculous
[20:08] <achandrashekar> never hire a trucker to do admin work
[20:08] <achandrashekar> I was pissed off to say the least
[20:08] <achandrashekar> anyhow...
[20:08] <kgoetz> i'd belive that
[20:09] <achandrashekar> took a long time for me to learn how to get the setup all working at first
[20:09] <achandrashekar> and the guy who simply had to hook it all up did a really crappy job
[20:09] <achandrashekar> okay enough bitching..sorry
[20:10] <achandrashekar> I need to know "how" to check the integrity of that database
[20:10] <achandrashekar> the ldap that is..
[20:10] <achandrashekar> any ideas??
[20:10] <kgoetz> not off the top of my head. sorry. at work our server hasnt gon down yet
[20:10] <kgoetz> (thank heavens for that)
[20:12] <achandrashekar> hmm..maybe a question for the ltsp guys??
[20:13] <kgoetz> i'd say so.
[20:28] <offload> hello.  Does edubuntu have packages installed that keep the desktop wallpaper and things like this from being changed?
[20:29] <kgoetz> not sure if it does by defaut, but you can intall some
[20:33] <offload> kgoetz, know of any?
[20:34] <kgoetz> offload: sabayon
[20:36] <offload> kgoetz, isn't that a gentoo distro?
[20:37] <kgoetz> offload: try 'apt-cache show gentoo' and 'apt-cache show sabayon' :)
[20:38] <offload> well you can understand my confusion with a distro called Sabyon Linux.  Gentoo / KDE super graphical distro
[20:39] <offload> Xnest ?  hmmm I gots some readin to do ;)
[20:39] <kgoetz> :)
[20:39] <kgoetz> if you have questions when your reading feel free to ask
[20:40] <offload> Test installing it on this machine now
[20:43] <kgoetz> gl
[20:47] <offload> kgoetz, installed fine but there's no documentation that I see on http://live.gnome.org/Sabayon about it's use and having a tough time finding anythign on google.
[20:49] <kgoetz> offload: check in /usr/share/doc/sabayon/ for documentation
[20:51] <offload> kgoetz, nada
[20:51] <offload> readme is usless and there's nothing else really
[20:51] <kgoetz> offload: hm.
[20:52] <kgoetz> what ubuntu release are you running?
[20:53] <stgraber> RichEd: Hi, about the geneva schools Linux deployment, I wasn't aware of that but just saw a post on our mailinglist (ubuntu-ch). That's great news
[21:07] <achandrashekar> offload: run gconf-editor and it's under /desktop/gnome/background and then just right-click on the key for picture filename and click "Set as Mandatory"
[21:42] <offload> achandrashekar, awesome thanks
[21:47] <achandrashekar> yep
[21:47] <achandrashekar> been down that road too.
[23:08] <supreme> hi all
[23:10] <supreme> somebody please can recommend a good edubuntu/ltsp server hardware, long time probed, guaranteed?
[23:11] <kgoetz> supreme: not sure i follow you
[23:12] <supreme> sorry, english isn't my main language, but, i'll tell you the situation
[23:12] <supreme> now Im able to buy a new server for a classroom working with edubuntu and 25 thin clients
[23:13] <supreme> i must to know which hardware will be 100% supported by edubuntu working as terminal server
[23:15] <kgoetz> avoid nVIDIA  chipsets and your well on teh way IMO
[23:21] <supreme> i was having problems with intel chipsets,,
[23:22] <kgoetz> thats supprising. which chipsets?
[23:25] <supreme> i havent exact model, but it's for p4, sata, 1 gigabit, no sound plugs
[23:26] <justme____> unfortunately I think video cards in general are rather piss poor for support from all 3 major manufacturers, intel, nvidia, and ati.. one rule of thumb to follow, is to avoid the newest hardware, since it is lacking the most support, as linux dev's haven't had time to debug and reverse engineer the newest ones
[23:27] <justme____> realistically, a video card can be swapped, if you run into problems, or a new video card installed to replace the onboard video.. so I wouldn't worry much about that.. just hope that you get a working/supported one, and if not, replace it
[23:27] <supreme> i don't mind video cards, since it will work as a terminal server
[23:28] <justme____> yeah, but with edubuntu, you need a gui installed, so that becomes an issue :)
[23:28] <kgoetz> its a server, you dont need a video card ;)
[23:28] <justme____> I imagine there may be some edubuntu servers running without guis, where admins have finished the client gui setups, and then removed/disabled the local gui.. but I couldn't really say
[23:28] <supreme> the graphics are working ok
[23:29] <kgoetz> theres at least one *g*
[23:29] <supreme> the problem is that thin clients restart session :/
[23:30] <supreme> i use another pc and clients works ok, so connectivity hardware is ok
[23:30] <kgoetz> thats a client side issue. what are the clients running?
[23:31] <supreme> i dont think could be client issue, since i change server and everything works ok (same switch, same clients, same edubuntu 7.10)
[23:31] <supreme> the clientes are eboxes, no hd
[23:31] <supreme> *clients
[23:32] <kgoetz> hm.


[02:45] <davecheney> thumper: http://paste.ubuntu.com/12069959/
[02:45] <davecheney> this is from this morning's run
[02:45] <davecheney> summary: juju is now as stable on ppc64 as any other platform
[02:50] <thumper> hazaah
[03:35] <menn0> thumper: here's the final allenvwatcher pr: http://reviews.vapour.ws/r/2374/
[04:51] <menn0> thumper: any chance you can look at the above? ^^
[04:51]  * menn0 is keen to be done with this
[04:53]  * thumper is looking now
[04:53] <menn0> thumper: thanks
[05:25] <thumper> menn0: done
[05:25] <thumper> one (strong) suggestion
[05:25] <menn0> thumper: ok...
[05:27] <menn0> thumper: no problems. I had something like that at one point.
[05:29] <menn0> thumper: to be fair those funcs aren't really for truly public use (hence the comment)
[05:40] <thumper> well... if they have capital letters, they're public
[06:55] <dimitern> TheMue, morning
[06:56] <dimitern> TheMue, I see you've assigned the constraints card to yourself, but you're yet to land your other branch, so I've reassigned it to myself
[07:10] <TheMue> dimitern: morning, the landing card is just waiting, that CI is unblocked
[07:10] <dimitern> TheMue, cool
[07:11] <TheMue> dimitern: so which card can I start with now?
[07:12] <dimitern> TheMue, hmm.. let me have a look
[07:13] <dimitern> TheMue, you have a follow-up to do, don't you? :)
[07:13] <dimitern> also it seems I've assigned the wrong card to myself - I'm actually working on the other constraints card
[07:13] <TheMue> dimitern: hehe
[07:15] <TheMue> dimitern: you mean "Test isNetworkingEnvironment() in ..."? we haven't moved it from backlog to iteration backlog, so I thought it's not as important as the spaces cards
[07:16] <dimitern> TheMue, yeah, we forgot about this one
[07:16] <dimitern> TheMue, the net-cli stuff is the most important once the previous tasks are done :)
[07:16] <TheMue> dimitern: ok, so I'll move it
[07:16] <dimitern> TheMue, cheers, and feel free to estimate it as well
[07:17] <TheMue> let's move it, move it, let's move it, move it *sing*
[07:17] <TheMue> dimitern: ok
[07:22] <voidspace> dimitern: ping
[07:24] <dimitern> voidspace, pong
[07:24] <voidspace> dimitern: did you write ListSubnets?
[07:25] <voidspace> dimitern: unlike all the other API methods it tages a *names.SpaceTag rather than a names.SpaceTag and I'm wondering why
[07:25] <voidspace> I changed it, as it was marginally inconvenient in one place, and a few things broke
[07:25] <voidspace> so I probably have to put it back
[07:26] <dimitern> voidspace, I did - it's because the space is optional for filtering
[07:26] <dimitern> voidspace, it was supposed to make calling the client-side method more convenient :)
[07:26] <voidspace> dimitern: and you need to be able to distinguish between not used (nil) and an explicit empty space ("")
[07:28] <voidspace> dimitern: so, changing API methods to take tags instead of strings means changing a bunch of CLI calls too
[07:28] <voidspace> dimitern: they need to use the tags and do the validation
[07:29] <voidspace> so I'm now down to only 23 test failures...
[07:29] <voidspace> (the CLI methods were already validating of course - but not always storing a tag. And it's *mostly* tests that need to change.)
[07:32] <dimitern> voidspace, :)
[07:33] <dimitern> voidspace, sounds good
[07:44] <dimitern> TheMue, voidspace, dooferlad, guys, I'm suggesting to cancel the 1:1 meetings today - happy to chat about anything, if you want of course
[07:44] <dimitern> but in the face of the feature freeze I'd rather concentrate on that with priority
[07:45] <TheMue> dimitern: frome my side nothing special, so sounds good
[07:47] <dimitern> TheMue, cheers
[07:47] <voidspace> dimitern: sure
[07:48] <voidspace> dimitern: thanks
[07:55] <dooferlad> dimitern: +1
[07:55] <dimitern> thanks guys!
[09:01] <voidspace> dimitern: TheMue: dooferlad: ready in a minute or two - coffee!!!
[09:32] <voidspace> dimitern: TheMue: dooferlad: not sure if my last message got through, my internet went down
[09:32] <voidspace> sorry
[09:32] <voidspace> I'm back now but the hangout was empty
[09:33] <TheMue> voidspace: you've been frozen and then the connection dropped
[09:33] <TheMue> voidspace: so the question is, what has been the last message? ;)
[09:33] <voidspace> that was my last message...
[09:33] <voidspace> "my internet went down"
[09:33] <voidspace> :-)
[09:34] <dimitern> voidspace, oh - I think I heard only "own" :)
[09:36] <TheMue> hehe
[09:36] <voidspace> dimitern: own?
[09:40] <voidspace> dimitern: out of "down"?
[09:42] <dimitern> voidspace, I think so yeah
[09:42] <dimitern> (well it sounded like "on")
[09:42] <voidspace> heh
[09:42] <voidspace> sorry
[09:42] <voidspace> :w
[09:42] <voidspace> wrong window...
[09:43] <dimitern> voidspace, so it seemed we should chat about subnet add/create vs tagging?
[09:43] <voidspace> dimitern: well, I thought we had talked about it a few times already!
[09:43] <voidspace> dimitern: that's why I was so surprised
[09:44] <voidspace> dimitern: previously you seemed to agree that Create was easier and we didn't need to touch tagging for the MVP
[09:44] <dimitern> voidspace, yeah, I might have misinformed you unintentionally
[09:44] <voidspace> dimitern: if we *have* to do Add, then so-be-it, but I think it's *more work*
[09:44] <dimitern> voidspace, we'll implement create, but not include in the MVP
[09:45] <voidspace> sure, I'm talking about what is the least work we can do which gets something useful
[09:45] <dimitern> voidspace, also add doesn't need to respect pre-existing tags on a subnet in ec2
[09:45] <dimitern> for the MVP
[09:45] <voidspace> so what does it do?
[09:45] <dimitern> voidspace, it adds it to state, validating it exists on the provider
[09:45] <voidspace> just assumes the subnet exists and adds it to state
[09:46] <voidspace> so it does go out to the provider
[09:46] <voidspace> (the current implementation doesn't...)
[09:46] <dimitern> voidspace, yes, as we have already a Subnets call we can call - it shouldn't be too bad to add this check
[09:46] <voidspace> ok
[09:46] <voidspace> so if we ignore tagging then Add is easier :-)
[09:48] <dimitern> voidspace, indeed - we'll add tagging (discovery and updates) later if we manage - it's strictly an improvement in UX and observability, not so much in functionality
[09:52] <voidspace> dimitern: fair enough I guess
[09:52] <voidspace> dimitern: like I said, based on our previous conversations I was just surprised
[10:12] <voidspace> dimitern: updated PR http://reviews.vapour.ws/r/2360/
[10:25] <dimitern> voidspace, cheers, looking
[10:31] <dimitern> dooferlad, others: http://reviews.vapour.ws/r/2376/ spaces constraints
[10:31] <dooferlad> dimitern: already reading :-)
[10:34] <dimitern> dooferlad, ta!
[10:35] <dimitern> voidspace, didn't we talk about ListSubnets returning something like []params.SubnetInfo?
[10:36] <dimitern> voidspace, I mean the client-side api method
[10:37] <voidspace> dimitern: I don't recall a conversation about that, let me look and see what it does return
[10:37] <voidspace> it's been a while since I wrote that code
[10:38] <voidspace> dimitern: hmm... it returns a list of params.Subnet
[10:39] <voidspace> dimitern: there is no params.SubnetInfo is there?
[10:39] <dimitern> voidspace, sorry, I meant params.Subnet
[10:39] <voidspace> dimitern: well, it has a result type that holds a list of params.Subnet
[10:39] <dimitern> voidspace, well, looking at your branch it returns ListSubnetsResults and an error
[10:39] <voidspace> dimitern: do you mean removing the ListSubnetsResults part from the returned value
[10:40] <dimitern> voidspace, that's pretty unusual for client-side apis
[10:40] <dimitern> voidspace, just return the Results part of it and the error
[10:40] <voidspace> dimitern: ah
[10:40] <voidspace> dimitern: ListSpaces does the same
[10:41] <voidspace> dimitern: ah, and the CLI expects just a list of subnets
[10:41] <voidspace> dimitern: so that needs fixing
[10:41] <voidspace> probably the same for ListSpaces too
[10:41] <voidspace> dimitern: thanks
[10:43] <voidspace> dimitern: just return response.Results or can we get rid of the response type completely and just return a slice of Subnet ?
[10:44] <voidspace> (I mean can the apiserver return []params.Subnet or do we need a Result type to hold it)
[10:46] <voidspace> I'm just changing the api List* methods
[10:46] <dimitern> voidspace, nope, the apiserver-side still needs to use the result type like this
[10:46] <voidspace> yeah
[10:46] <dimitern> voidspace, you have a review
[10:46] <voidspace> dimitern: thanks
[10:47] <voidspace> dimitern: why do we need to verify that the command members are set correctly on error?
[10:47] <voidspace> dimitern: given that we report the error to the user and exist
[10:48] <dimitern> voidspace, I'd appreciate a second look on my review as well - esp. if any of the TODOs reminds you of something I might've missed
[10:48] <voidspace> dimitern: ok
[10:49] <dimitern> voidspace, it's not a big deal to leave this in place
[10:49] <dimitern> voidspace, is it?
[10:51] <voidspace> dimitern: well, as we're now using SubnetTag I can't construct a SubnetTag for an invalid CIDR
[10:51] <voidspace> dimitern: so in the case of error we can't check that
[10:52] <voidspace> dimitern: and if there's no *need* for the others then it's better not to test them
[10:52] <dimitern> voidspace, ah
[10:52] <voidspace> we should only test behaviour we actually need
[10:52] <dimitern> voidspace, sure, then it's fine
[10:52] <voidspace> thanks
[10:52] <dimitern> voidspace, unlike APIs, those CLI methods are not usable from outside the package
[10:53] <voidspace> yep
[10:53] <voidspace> that was my thinking
[10:53] <voidspace> dimitern: what's the value in changing providerId to network.Id?
[10:53] <voidspace> dimitern: there's no validation, so it doesn't really offer any benefit like SubnetTag and SpaceTag do
[10:54] <voidspace> it can take arbitrary strings
[10:54] <voidspace> I believe
[10:54] <voidspace> and it probably means finding and fixing another crap-load of tests :-p
[10:54] <dimitern> voidspace, fwereade reminded me on more than one occasion that we should use typed strings for foreign ids, like the provider ones
[10:54] <voidspace> ok
[10:54] <voidspace> fair enough
[10:54] <voidspace> I'll bite the bullet
[10:55] <dimitern> voidspace, yeah, no validation for now, having a type makes adding this easier
[10:55] <dimitern> if/when needed
[10:55] <dimitern> voidspace, thanks
[10:55] <voidspace> so for our imaginery future use case then
[10:55] <voidspace> ;-)
[10:56] <dimitern> well :)
[10:56] <voidspace> dimitern: network.Id is used for too many *different* things for us to ever be able to add meaningful validation
[10:56] <voidspace> we'd have to create a *specific* type
[10:56] <dimitern> good design and architecture includes some need for precognition and such
[10:57] <dimitern> voidspace, it's used for provider-specific ids
[10:57] <voidspace> dimitern: many *different* provider-specific ids with different specifications
[10:58] <dimitern> voidspace, at least having them marked as such will simplify changing them to separate types if needed IMO
[10:59] <dimitern> voidspace, I hope you don't mind too much for a string cast here and there :)
[11:01] <voidspace> dimitern: I'm not totally convinced about the *semantic* value of using types (that offer no tangible other benefit) to represent "things" that actually *are* strings, and having to case to and from everywhere they're used
[11:01] <voidspace> dimitern: I'll do it, I'm just not convinced it adds value
[11:01] <dimitern> voidspace, I'll wait for your and mine branches to land and then create the net-cli-mvp branch
[11:02] <dimitern> voidspace, right
[11:02] <voidspace> dimitern: cool
[11:03] <voidspace> dimitern: I'll take lunch shortly
[11:03] <voidspace> I'll try and get the branch landable first
[11:04] <dimitern> voidspace, ta!
[11:25] <voidspace> dimitern: right, made those changes
[11:25] <voidspace> dimitern: switching to network.Id touched 6 files, so you might want to take another brief look
[11:25] <voidspace> :-D
[11:25] <voidspace> maybe "want" is the wrong word
[11:26] <dimitern> voidspace, sure, looking
[11:27] <dooferlad> dimitern: https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-add-deployment-support-for-spaces?expand=1 seems to be all https://canonical.leankit.com/Boards/View/101652562/116603811 needs.
[11:27] <dooferlad> just let me know about printing/logging the deprecation warning and I will tidy up that comment and get it in for review
[11:27] <dimitern> dooferlad, ok, I'll have a look shortly
[11:27] <dooferlad> dimitern: thanks.
[11:28] <dimitern> voidspace, get some lunch first
[11:28] <dimitern> voidspace, you're eating tests otherwise :)
[11:29] <voidspace> :-)
[11:31] <voidspace> dimitern: well, I want to meditate and it will be a little bit of time before I can persuade my wife to clear out of the room I need :-D
[11:31] <dimitern> voidspace, I see ok :)
[11:34] <dimitern> voidspace, dooferlad, only now I realize ListSpaces API doesn't conform to the usual (results, error) behavior - it returns results and an error, but only the first error when fetching a space's subnets
[11:35] <voidspace> dimitern: you mean it should collect all errors
[11:35] <dimitern> it needs to use a Results and Error fields of the results for such errors
[11:35] <voidspace> dimitern: as the only possible error is connection with state failing (so all should fail or none)
[11:35] <voidspace> dimitern: I don't think it's a big issue
[11:35] <dimitern> voidspace, yeah, only return an error if it can't return anything
[11:36] <voidspace> I mean, we should fix it - but add a card for after mvp maybe
[11:36] <dimitern> voidspace, well, just because we're catching this now means it lacks bulk call coverage
[11:36] <voidspace> "bulk call coverage"?
[11:36] <voidspace> it's a bulk response not a bulk call...
[11:37] <voidspace> it's a single call with a bulk result
[11:37] <dimitern> voidspace, yeah - a call to it with e.g. one valid, one invalid, and another valid - checking 2 results and 1 error is returned
[11:37] <dimitern> voidspace, the apiserver method I mean
[11:37] <voidspace> right
[11:38] <dimitern> voidspace, it's trivial to fix and we should do it for the mvp by all means, as changing the api later is worse
[11:39] <voidspace> dimitern: ok
[11:39] <dimitern> voidspace, I'd add a card for it, but please add a TODO about it in your PR - apiserver/spaces
[11:40] <voidspace> dimitern: TODO added
[11:41] <voidspace> well, pushing now
[11:42] <dimitern> voidspace, thanks!
[11:42] <voidspace> done
[11:44] <voidspace> right, room free
[11:44] <voidspace> off to meditate
[11:46] <dimitern> dooferlad, hey
[11:47] <dimitern> dooferlad, the help docs need to mention the spaces constraints but not --networks btw
[11:49] <dimitern> dooferlad, but there are also - tests we do ignore --networks and dropping those that don't (or at least adding TODOs/skipping them)
[11:50] <dimitern> dooferlad, hmm sorry, I might have described it badly in the card
[11:51] <dimitern> dooferlad, the idea is not only to give a warning for it, but also not to pass it through the layers as well, so it can't interfere with the other work around spaces for deployments
[11:51] <dimitern> dooferlad, does that make sense?
[12:11] <dimitern> does anyone else get build errors for gwacl on master after updating and running godeps ?
[12:12] <dimitern> axw, ping
[12:40] <dooferlad> dimitern: yea, that isn't what I got from the card. I read it as we would still accept --networks, but we should mark it as deprecated to discourage its use before removing it in a later version.
[12:42] <dimitern> dooferlad, we would've done that if currently it was at least remotely useful
[12:43] <dimitern> dooferlad, and it will soon go away to be replaced by deploy time bindings of the right kind, with spaces (once we figure out how'd they look like)
[13:02] <dimitern> anyone up for a trivial review? http://reviews.vapour.ws/r/2377/
[13:05] <dimitern> TheMue, voidspace, dooferlad ^^
[13:07] <dooferlad> dimitern: *click*
[13:24] <dooferlad> dimitern: you said that space contraints are handled elsewhere in the card I am looking at. Where is that?
[13:25] <dooferlad> dimitern: also, with network constraints, do you want me to just remove them or just not wire them up in the CLI?
[13:25] <dooferlad> or just leave as-is I guess.
[13:26] <dimitern> dooferlad, they need to go, but that's a separate card, which will require a lot of prerequisites (mostly provider and provisioner related) landed first
[13:27] <dimitern> dooferlad, not sure what do you mean by "handled" - my PR implements parsing and tests for them, and since they're constraints that makes them usable everywhere
[13:27] <dooferlad> dimitern: doh! Haven't merged that in :-)
[13:28] <dimitern> whether we do anything with them is another thing
[13:34] <dimitern> dooferlad, did that answer your questions btw? :)
[13:35] <dooferlad> dimitern: I am leaving the constraints code as it is, so it will accept networks. I have removed the code path that --networks used for juju deploy.
[13:35] <dooferlad> dimitern: I have had a look at add-machine and add-unit and both seem to have no explicit --network support, so they are just constraints code again
[13:35] <dooferlad> dimitern: if that is right, yes.
[13:37] <dimitern> dooferlad, indeed - I just double checked
[13:37] <dimitern> dooferlad, are there a lot of tests affected by --networks being ignored ?
[13:38] <dooferlad> dimitern: I just removed the two that started to fail (correctly) once support for the --network flag was removed.
[13:38] <dooferlad> dimitern: I didn't look at any already skipped ones.
[13:40] <dimitern> dooferlad, by "removed" do you mean it returns an error like "flag provided but not defined: --networks" or it accepts it, prints a warning and continues?
[13:40] <dooferlad> prints a warning and continues as if it isn't there
[13:40] <dimitern> dooferlad, great!
[13:40] <dooferlad> dimitern: http://reviews.vapour.ws/r/2382/
[13:41] <dooferlad> dimitern: I haven't added any support, so much as removed other support.
[13:41] <dimitern> dooferlad, that's a lot better - less fallout than my original attempt which did the former
[13:41] <dooferlad> so the title is rubbish
[13:49] <dimitern> dooferlad, it's fine :)
[13:49] <dimitern> dooferlad, almost done with the review btw
[14:05] <dimitern> dooferlad, was the removal of that status test case necessary?
[14:09] <dooferlad> dimitern: yes, it failed.
[14:14] <dimitern> dooferlad, that's because we're not stopping tests from calling deploy APIs with networks
[14:15] <dimitern> dooferlad, rather than removing it, can you comment it out for now with a TODO about fixing it once the API and state layers also ignore (requested)networks (which --networks sets effectively) ?
[14:15] <dimitern> dooferlad, I'll add a comment to the review
[14:21] <dimitern> dooferlad, reviewed
[14:43] <voidspace> dimitern: ping
[14:47] <dimitern> voidspace, pong
[14:47] <voidspace> dimitern: so, I add a *Error field to params.Space so we can return partial results
[14:48] <voidspace> dimitern: the top level params.ListSpaceResult has an Error field (in case fetching the spaces fails - the new error is for an error fetching subnets for an individual space)
[14:48] <voidspace> dimitern: and ListSpaces also returns an error
[14:49] <voidspace> dimitern: so if we get an error fetching the subnets for a single space obviously we set the Error field on Space
[14:49] <dimitern> voidspace, you did all this in your subnets api branch?
[14:49] <voidspace> dimitern: do we set an error on ListSpaceResult and do we return an error too?
[14:49] <dimitern> voidspace, or in a follow-up?
[14:49] <voidspace> dimitern: no, new branch - looking at it now
[14:49] <dimitern> voidspace, ah, great
[14:49] <voidspace> dimitern: not sure if I can get it done before I go as I go to the gym in 40minutes
[14:49] <voidspace> dimitern: that branch landed on net-cli by the way
[14:49] <dimitern> voidspace, did the other one land?
[14:50] <voidspace> yep
[14:50] <dimitern> voidspace, awesome!
[14:50] <dimitern> voidspace, so I added a card for the ListSpace/Subnet errors
[14:50] <voidspace> I tried looking for other examples in the apiserver but failed to find any and thought it would be quicker to ask
[14:50] <voidspace> dimitern: it should just be ListSpace I believe
[14:50] <voidspace> dimitern: ListSubnets doesn't make extra calls per subnet, so either it all works or it all fails
[14:50] <dimitern> voidspace, so usually bulk calls that return many results for many entities
[14:50] <voidspace> (I believe)
[14:51] <voidspace> dimitern: with ListSpaces we can fetch the spaces and then fail to fetch the subnets for some of the spaces
[14:51] <voidspace> so partial results make sense in theory
[14:51] <dimitern> voidspace, ..only return errors if it's not possible to do its job
[14:51] <voidspace> I say in theory, because in practise the only error is that the connection to state goes
[14:51] <voidspace> so again, in reality it will be all or nothing
[14:51] <voidspace> but it's better to stick to the pattern
[14:52] <voidspace> dimitern: right, so we don't return a top level error
[14:52] <voidspace> dimitern: what about setting an error on ListSpacesResult?
[14:52] <dimitern> voidspace, let me have a look at the code now for a moment
[14:52] <voidspace> dimitern: or should we rely on the client checking the Error field of each Space
[14:55] <dimitern> voidspace, for ListSpaces you're correct - the backing error should be returned as top-level, others can only be per-space (fetching subnets failed)
[14:56] <cmars> wallyworld, http://reviews.vapour.ws/r/2387/ please
[14:57] <voidspace> dimitern: I'm sorry I don't understand
[14:57] <voidspace> dimitern: what is "the backing error"?
[14:57] <voidspace> dimitern: if we get an error fetching the subnets for a space obviously we set the Error on the params.Space
[14:57] <dimitern> voidspace, coming from the state (backing)
[14:57] <voidspace> dimitern: do we set an error anywhere else?
[14:58] <voidspace> dimitern: so we also set an error on ListSpaceResults? or are you saying we also return the error at the very top level?
[14:59] <dimitern> voidspace, sorry, let me explain better
[14:59] <dimitern> voidspace, https://github.com/juju/juju/pull/2980/files#diff-ec0483c931b7d3d2d378df66d465deb1R100 < this is a top-level error (with empty results)
[15:00] <voidspace> dimitern: yes
[15:00] <dimitern> voidspace, https://github.com/juju/juju/pull/2980/files#diff-ec0483c931b7d3d2d378df66d465deb1L109 < this is a per result error
[15:00] <voidspace> yes
[15:00] <voidspace> dimitern: that's what we do currently
[15:00] <dimitern> voidspace, in the latter case, the results != empty, err = nil
[15:00] <voidspace> right
[15:01] <voidspace> and we set the error on the individual params.Space we create
[15:01] <voidspace> (we should I mean)
[15:01] <voidspace> I'm asking do we *also* do anything else with it?
[15:01] <dimitern> voidspace, there's no individual params.Space
[15:01] <dimitern> voidspace, ListSpaces takes no args at apiserver side
[15:02] <voidspace> the object there "result" is a params.Space
[15:02] <voidspace> so instead of "return results, err" it would be
[15:03] <voidspace> result.Error = common.ServerError(err); result.Results = append(result.Results, result);continure
[15:03] <voidspace> *continue
[15:03] <dimitern> voidspace, ah, got you
[15:03] <voidspace> dimitern: that's the change you have said we ought to make
[15:03] <dimitern> voidspace, yes
[15:03] <voidspace> I'm asking if we should *also* set results.Error
[15:03] <dimitern> voidspace, and I've just realized ListSubnets apiserver side is not yet done, so it's fine
[15:03] <voidspace> and we've agreed that the returned err should still be nil
[15:04] <voidspace> ListSubnets won't have the same problem
[15:04] <voidspace> I'm asking if we should *also* set results.Error
[15:04] <voidspace> and we've agreed that the returned err should still be nil
[15:04] <dimitern> voidspace, yes, if you can fetch spaces ok, but not all subnets -> return results(with Error set as needed), nil
[15:05] <dimitern> voidspace, if you can't fetch spaces - as it is now
[15:05] <voidspace> so I should set result.Error for each Space where fetching subnets fail, and set a results.Error to indicate that there are only partial results
[15:06] <dimitern> voidspace, sorry, I'm confused - what do you mean by result.Error for each space?
[15:06] <voidspace> dimitern: every space we fetch is represented by a params.Space
[15:06] <dimitern> voidspace, yes, yes
[15:06] <voidspace> dimitern: that will grow an Error field
[15:06] <dimitern> voidspace, sorry
[15:06] <voidspace> dimitern: that is settled
[15:06] <dimitern> voidspace, I need to get in a call
[15:06] <dimitern> voidspace, it is, yes
[15:06] <voidspace> dimitern: I am asking, do we *also* set an Error on ListSpaceResults
[15:07] <dimitern> voidspace, where is that ListSpaceResults defined?
[15:08] <voidspace> sorry params.ListSpacesResults
[15:08] <voidspace> at the moment it doesn't have an Error field because the method would either return all results or an error
[15:08] <voidspace> so it didn't need one there were no partial results
[15:08] <voidspace> we're now adding partial results
[15:09] <voidspace> so I wonder if ListSpacesResults (apiserver/params/network.go I believe)
[15:09] <voidspace> I wonder if it now also needs an Error field
[15:09] <voidspace> used to indicate partial results
[15:09] <dimitern> voidspace, I believe we need to make api.ListSpaces() ([]params.Space, error)
[15:10] <voidspace> dimitern: earlier today you said that apiserver couldn't return []params.Space and ListSpacesResults was still needed :-)
[15:11] <dimitern> voidspace, then also change ListSpacesResults' Results field to be of type ListSpacesResult (or whatever), which has a Space and Error *Error fields
[15:12] <voidspace> instead of adding an Error to Space...
[15:12] <voidspace> add a new intermediate type
[15:12] <dimitern> voidspace, it's just confusing because of the api/apiserver transition
[15:12] <voidspace> I think you're still slightly misundestanding my question/suggestion :-(
[15:12] <voidspace> I think you have too much in your head
[15:12] <voidspace> we don't need a new intermediate result type, we can just add an Error field to Space
[15:13] <dimitern> voidspace, ok, I see how params.Space can be used as what I'm describing as ListSpacesResult (singular)
[15:13] <voidspace> I am asking if the *plural*, the container results type, ListSpacesResults also needs an Error field
[15:13] <voidspace> because if we get partial results (an error occurred somewhere) don't we want a top level Error field to indicate that the results are partial?
[15:14] <voidspace> maybe not, and just having the error printed inline with the space description is fine
[15:15] <dimitern> voidspace, it's not common to have ErrPartialResults from API server methods
[15:15] <dimitern> voidspace, and in this case I don't think it's even useful
[15:15] <voidspace> ok
[15:15] <voidspace> so we won't
[15:15] <voidspace> thanks
[15:15] <dimitern> voidspace, thanks for bearing with me :)
[15:15] <voidspace> :-)
[15:16] <voidspace> I go soon
[15:16] <voidspace> so I'll be leaving you to it
[15:17] <natefinch> ericsnow: if we always flush immediately after set, we should be able to remove the mergeProcMaps
[15:17] <dimitern> voidspace, sure
[15:18] <ericsnow> natefinch: right
[15:21] <voidspace> dimitern: cmd/juju/spaces/list.go - ListSpaces command fetches the subnets using api.AllSubnets()
[15:21] <voidspace> dimitern: it doesn't use the subnets on the Space!!
[15:21] <voidspace> I guess space.Subnets() is newer than the ListSpaces command...
[15:22] <voidspace> I don't think I can fix that in the time I have
[15:22] <voidspace> it will make the code simpler though
[15:22] <voidspace> I'll add it to the card
[15:23] <dimitern> voidspace, ack, otp - thanks
[15:26] <voidspace> dimitern: done, card updated - including the code to set the error correctly
[15:26] <voidspace> dimitern: have a good week
[15:26] <voidspace> TheMue: dooferlad: EOW
[15:26] <voidspace> I begin my journey home
[15:26] <voidspace> good luck with the MVP
[15:26] <TheMue> voidspace: have a safe trip
[15:26] <voidspace> thanks
[15:28] <natefinch> ericsnow: updated the code according to your suggestions, would like a re-review so we can get it done
[15:28] <TheMue> dimitern: maybe I'm missing something and you can point me to the right way. I've got my test, I've got my mock, but the way to inject is seems difficult
[15:28] <ericsnow> natefinch: will do
[15:47] <natefinch> ericsnow: realized I didn't publish my responses to your earlier comments.  Just did so.
[15:47] <ericsnow> natefinch: thanks
[15:47] <natefinch> (only one real comment)
[16:01] <dimitern> TheMue, can I look at the code you're having issues with?
[16:03] <dooferlad> dimitern: do you have an opinion about what card I should do next?
[16:05] <dimitern> dooferlad, I don't see a card for apiserver subnets - create and lest
[16:05] <dimitern> list
[16:05] <TheMue> dimitern: it's not a concrete issue, more a missing idea.
[16:06] <dooferlad> dimitern: you meen the apiserver side of what voidspace has done?
[16:06] <TheMue> dimitern: in the test in http://paste.ubuntu.com/12109009/ I try to inject the mock
[16:06] <dimitern> dooferlad, yeah
[16:07] <dimitern> dooferlad, we seem to have missed this - can you add a card and start on Add first perhaps?
[16:07] <dimitern> TheMue, I'll have a look shortly
[16:07] <dooferlad> dimitern: isn't it in the archive? https://canonical.leankit.com/Boards/View/101652562/115620070
[16:07] <dooferlad> dimitern: also https://canonical.leankit.com/Boards/View/101652562/115620186
[16:08] <dimitern> dooferlad, both of these are for spaces
[16:08] <dooferlad> dimitern: doh!
[16:08] <dooferlad> dimitern: yes, you are right
[16:09] <dimitern> dooferlad, I know it's confusing - it gets me every time :)
[16:12] <dimitern> dooferlad, and I'm wrong - apiserver has AddSubnets, but no list yet
[16:12] <dimitern> dooferlad, we don't need CreateSubnets for the MVP, so we can just do Add and List
[16:13] <dimitern> dooferlad, there's a card I added re ListSpacesResults and ListSubnetsResults - if you prefer
[16:13] <dimitern> dooferlad, also voidspace has a branch with some progress on it
[16:15] <dooferlad> dimitern: https://github.com/voidspace/juju/commits/spaces-subnets-api ?
[16:16] <dooferlad> dimitern: that is merged
[16:17] <dimitern> dooferlad, I think this is it - https://github.com/voidspace/juju/tree/spaces-list-errors
[16:18] <dooferlad> dimitern: that is about spaces, not subnets
[16:18] <dooferlad> but if both need list, then I can probably finish that and add subnets
[16:18] <dimitern> TheMue, it's about ListSpaces returning proper results, which will apply to ListSubnets as well even more (apiserver side)
[16:19] <dimitern> dooferlad, ^^
[16:19] <dimitern> TheMue, sorry, I meant to tell you to have a look at TestManageEnvironDoesNotRunFirewallerWhenModeIsNone
[16:19] <TheMue> dimitern: ah, thx. what a java-like name
[16:20] <dimitern> TheMue, :)
[16:20] <dimitern> TheMue, the next one after it is another example
[16:20] <dimitern> TheMue, since this is a pre-existing test suite, no need to go wild with mocks and things when they're not already in place
[16:21] <dimitern> dooferlad, does that make sense?
[16:21] <dooferlad> dimitern: yes
[16:22] <dimitern> dooferlad, cheers, let's discuss it tomorrow if needed
[16:22] <dooferlad> dimitern: it is EOD for me, so will make some notes in that card about what is needed and start tomorrow, at which point I will probably have questions :-)
[16:23] <TheMue> dimitern: my test so far is pretty similar, but environs.SupportsNetworking() tests against the environment. that's why I want to mock it here
[16:23] <dimitern> dooferlad, awesome!
[16:23] <dimitern> TheMue, you don't need to mock it with the dummy provider
[16:23] <TheMue> dimitern: when using dummy environs.SupportsNetworking() always returns true
[16:27] <dimitern> TheMue, ah, yeah - it wasn't calling SupportsAddressAllocation
[16:27] <dimitern> TheMue, then, the mocks are unfortunately needed
[16:27] <dimitern> TheMue, *or*
[16:28] <dimitern> TheMue, I guess you can make it easier to write tests  for all future cases like this
[16:28] <dimitern> TheMue, by making the dummy provider *not* support networking when a given environ config setting is there
[16:30] <TheMue> dimitern: yeah, the better approach, as we already discussed about, is mnot to use type assertion
[16:31] <dimitern> TheMue, yeah - it will make writing tests a lot easier
[16:32] <TheMue> dimitern: definitely
[16:42] <TheMue> dimitern: I change the card description with my ideas. could you take a look please?
[16:45] <dimitern> TheMue, looks good, only the name SupportsNetworking() on netEnv needs to be better I think
[16:47] <dimitern> TheMue, but I need to think about it - I'd suggest to go ahead and do it as you suggest, we can rename the NetworkingEnviron method name later as you propose it
[16:49] <TheMue> dimitern: exactly, renaming it en bloc is simple
[16:49] <dimitern> TheMue, +1
[17:00] <TheMue> dimitern: while doing it, how about ProvidesAddressAllocation or AllowsAddressAllocation for Allocate... and Release...
[17:00] <TheMue> dimitern: ?
[17:27] <dimitern> TheMue, we have this already - SupportsAddressAllocation - true for both Release and Allocate
[17:27] <dimitern> anyway, EOD for me
[17:28] <TheMue> dimitern: enjoy
[17:28] <dimitern> TheMue, thanks, same to you :)
[17:28] <TheMue> dimitern: ta
[19:33] <katco> natefinch: hey are you still blocked on feature tests for juju status?
[19:35] <natefinch> katco: I haven't spent time on it, but in theory, no.
[19:35] <natefinch> katco: I can unblock the card
[19:35] <katco> natefinch: k just checking. probably makes sense to stay on the 3-pointer?
[19:36] <natefinch> katco: yeah
[19:36] <katco> natefinch: kk
[19:39] <katco> wwitzel3: were you working on the rename cards?
[19:40] <wwitzel3> katco: haven't started them yet, just about have the feature test buttoned up, then that was my next item to start
[19:40] <katco> wwitzel3: cool
[19:41] <wwitzel3> katco: thanks to ericsnow's hand holding, I am just about done with the test
[19:41] <katco> lol
[20:46] <natefinch> ericsnow: does parseID return name, id or id, name? https://github.com/juju/juju/blob/feature-proc-mgmt/process/info.go#L42
[20:48] <natefinch> ericsnow: nvm, usage indicates name, id
[20:48] <ericsnow> natefinch: k
[22:06] <mup> Bug #1485781 opened: Juju is unreliable on Joyent <joyent-provider> <reliability> <repeatability> <juju-core:Triaged> <https://launchpad.net/bugs/1485781>
[22:33] <mup> Bug #1485784 opened: Error creating container juju-trusty-lxc-template; Failed to parse config <oil> <juju-core:New> <lxc:New> <https://launchpad.net/bugs/1485784>
[23:27] <davecheney> thumper: free now ?
[23:28] <thumper> davecheney: just munching down some food, 5 min?
[23:28] <davecheney> i'll see you in the hangout
[23:28] <davecheney> take your time


[20:45] <gQuigs> anyone know of a public bug on the thunderbird-trunk builds failing??  -  I'm not sure where to report bugs from the PPA (but am happy documenting that if I get an answer)
[20:49] <Mikaela> I think it has been mentioned here sometimes


[08:04] <joelesko> micahg: I hope this is what you were requesting. I created lp:~joe-nationnet/seamonkey/seamonkey.oneiric.beta
[08:06] <joelesko> Modified for the beta repo and pulled 2.5~b3. I'm sending it to my ppa to build and will test tomorrow.
[08:06] <joelesko> micahg: Just show me how you want the various repos to look and I will match them.
[08:07] <joelesko> micahg: thanks for helping to keep this moving along.
[08:09] <joelesko> chrisccoulson: thanks for getting this started and your valuable input in getting the new package in the correct state
[08:09] <joelesko> It was so cool to update to oneiric today and have a current seamonkey version working without adding ppa's
[12:57] <m_conley> chrisccoulson: ping
[12:57] <chrisccoulson> hi m_conley
[12:57] <m_conley> chrisccoulson: hey, how are you this morning?
[12:58] <chrisccoulson> m_conley, yeah, not too bad thanks. how are you?
[12:58] <m_conley> chrisccoulson: I'm all right - not too jazzed about bug 872639 though.
[12:58] <ubot2> Launchpad bug 872639 in thunderbird-eds-extension ""Cannot open book: Could not create DesktopcouchSession object"" [High,Confirmed] https://launchpad.net/bugs/872639
[12:58] <chrisccoulson> yeah, that's a pain.
[12:58] <chrisccoulson> i hate desktopcouch
[13:00] <m_conley> chrisccoulson: I just noticed that the user that reported the bug is running an older version of the EDS add-on - is it possible that they need to upgrade some of their software, including EDS and the desktopcouch backend?
[13:00] <chrisccoulson> which version is the latest now?
[13:01] <m_conley> chrisccoulson: 0.3.7a
[13:02] <chrisccoulson> yeah, i need to update it :)
[13:02] <m_conley> gah, yikes
[13:03] <m_conley> chrisccoulson: 0.3.7a will suppress the alert, but I don't think it'll solve the DesktopCouch problem - I think that's the backend being a bit screwy.
[13:04] <chrisccoulson> yeah, rodrigo seems to have a better understanding about the problem
[13:05] <chrisccoulson> ah, yes, i only added the latest version to the nightly branch so far
[13:05] <chrisccoulson> these extensions are probably all going to get disabled by default on upgrade to 8.0 anyway :(
[13:06] <m_conley> chrisccoulson: 0.3.7a should be good until TB 9.0
[13:14] <chrisccoulson> hmmm, enigmail keeps producing broken signatures in e-mails that i send :/
[13:43] <chrisccoulson> m_conley, oh, i remember why i never updated it now
[13:43] <chrisccoulson> xpidl ;)
[13:46] <m_conley> chrisccoulson: ah - is there anything I need to do to help drive this forward?
[13:54] <chrisccoulson> m_conley, i'll fix it so that it can build with both xpidl and typelib.py
[13:55] <m_conley> chrisccoulson: k - let me know if you need anything from me.
[14:34] <chrisccoulson> m_conley, https://code.launchpad.net/~chrisccoulson/thunderbird-eds-extension/support-xpidl
[14:34] <chrisccoulson> it also fixes a couple of other small issues too (such as shipping the idl files in the xpi)
[14:41] <m_conley> chrisccoulson: awesome!
[14:41] <m_conley> chrisccoulson: thanks! Inspecting / merging...
[14:41] <chrisccoulson> thanks. i'll merge the latest version in to our branch then :)
[14:52] <m_conley> chrisccoulson: ok, pushed to lp:thunderbird-eds-extension/0.3 - thanks so much!
[14:52] <chrisccoulson> excellent, thanks
[15:44] <chrisccoulson> heh, that was quick - https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034256.html !