[00:12] <kbZ> powersj you around?
[00:15] <rharper> kbZ: he's out already, but should be back tomorrow morning Pacific times,
[03:52] <blackboxsw> rharper: for tomorrow https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/370970/comments/970219 my azure validation on v2 metrics branch for secondary nic. Why isn't route-metric 200  showing?
[03:52]  * blackboxsw skips out
[11:43] <otubo> Hi guys, I still can't seem to find out the reason why this thing happens, does anyone have a little bit of time to help me debug this issue? https://bugzilla.redhat.com/show_bug.cgi?id=1593010
[11:43] <otubo> (oh, cool bot!)
[11:48] <otubo> Right now I'm using 18.5 to work on, but it's no big deal to have anything newer to have backported
[11:49] <otubo> The only environment I have right now is ESXi, and I can reproduce it.
[14:25] <rharper> blackboxsw: that sure looks like a bug to me w.r.t the metric on eth1
[14:27] <rharper> I suspect that the ESXi bug is related to the OVF datasource resetting instance-id =(
[14:35] <Odd_Bloke> rharper: blackboxsw: We discussed yesterday having the new Oracle network code off-by-default for now; I'm thinking I'll name the config option "apply_network_config", following the naming in the Azure DS.  Does that sound reasonable?
[14:57] <rharper> Odd_Bloke: that sounds reasonable, yes
[15:43] <kbZ> ᕕ( ⁰ ▽ ⁰ )ᕗ
[16:28] <blackboxsw> +1 Odd_Bloke.
[17:15] <blackboxsw> rharper: ok Azure 2 nics Eoan plus route-metric.... again I am not getting any route represented with a route-metric cost of 200. Will probably need to screen share and discuss with your sometime today
[17:15] <blackboxsw> and maybe it's just that nic 2 is also on the same subnet, so the route is omitted as it's a dup
[17:16]  * blackboxsw tries switching the vnet to <IP_ADDRESS>/16 instead of <IP_ADDRESS>/16 (which eth0 is also on)
[17:26] <blackboxsw> hrm, looks like I am just not certain how to setup multiple nics with different routes in azure vms. two nics on separate subnets result in only one interface with routes defined from the dhcp server.
[17:37] <rharper> blackboxsw: hrm
[17:37] <rharper> lemme verify on my openstack instances
[17:40] <rharper> blackboxsw: is that with or without the systemd with classless static route fix ?
[17:41] <blackboxsw> rharper: right, eoan is without the classless route fix. lemme bump it to -proposed
[17:41] <blackboxsw> and grab the queued fix for that too
[17:41] <rharper> no I was hoping without
[17:41] <blackboxsw> ok
[17:41] <rharper> I've a bionic instance that's doing it right
[17:41] <rharper> so I need to see what's different
[17:41] <rharper> can you import my ssh keys? lp:raharper  ?
[17:41] <rharper> and let me know where the instance is at ?
[17:43] <rharper> http://paste.ubuntu.com/p/gkhGkYqQfG/
[18:16] <Odd_Bloke> rharper: blackboxsw: On reflection, I don't think apply_network_config is the right name; in other places that disables DS-provided network config entirely which wouldn't be the meaning here.  I'm leaning towards apply_imds_network_config.  What do you think?
[18:17] <rharper> would you update the Azure one as well ? I agree we had some confusion over what it meant
[18:18] <rharper> Azure would accept both
[18:18] <rharper> or check both ?
[18:19] <blackboxsw> rharper: Odd_Bloke +1 on Azure ds_cfg needed to accept both, as apply_network_config on Azure currently means read IMDS and use it.
[18:21] <blackboxsw> hrm Odd_Bloke which datasource has apply_network_config disabling network config completely? OpenStack? I'd suggest that it is the same meaning in OpenStack as Azure. OpenStack's network_data.json is complex network config for the instance from OpenStack's IMDS. If we ignore it, w/ apply_network_config false, we aren't disabling network completely, just relying on fallback dhcp on primary nic (like azure does)
[18:23] <Odd_Bloke> I didn't say we disabled network completely, I said we disable _DS-provided_ network.  But, yeah, I see that that's not quite what it's doing on Azure.
[18:23] <blackboxsw> ... I'm probably misreading sorry.
[18:23] <Odd_Bloke> (On OpenStack it does just return None from .network_config, which is a full disable.)
[18:23] <Odd_Bloke> (On Azure it generates its own fallback config with slight modifications to the call.)
[18:24] <blackboxsw> ahh right, shoot. I thought cloudinit/stages.py did a fallback config if ds.network_config == None. I see now the LOG.info("network config is disabled by %s", src)
[18:25] <Odd_Bloke> I'm pretty sure stages _does_ do a fallback config.
[18:26] <Odd_Bloke> Yeah, a DS has to return {'config': False} to disable _all_ networking.
[18:27] <blackboxsw> looks like true: Init._find_networking_config walks through each potential network source, if ds.network_config == None, it still walks to self.distro.generate_fallback_config()
[18:27] <Odd_Bloke> Returning None from ds.network_config is just indicating that the DS doesn't have any network configuration to apply.
[18:27] <blackboxsw> right +1
[18:28] <blackboxsw> cloudinit/stages.py:line 644 is the catchall if no applicable network config from ds initramfs kernel_cmdline etc
[18:28] <blackboxsw> ok
[18:28] <Odd_Bloke> So I think the Azure behaviour and the OpenStack behaviour are quite similar, in that they both result in fallback configuration being emitted.
[18:28] <blackboxsw> in either case, I'm not opposed to a more specific config option name apply_imds_network_config
[18:29] <blackboxsw> better to avoid vague interpretations as to the config option meaning
[18:29] <Odd_Bloke> The Oracle behaviour of this flag is different; we will always generate the initramfs configuration (i.e. _not_ fallback), the flag only affects whether you get configuration for your _secondary_ NICs.
[18:30] <Odd_Bloke> I think this being interaction with an IMDS is a red herring naming-wise, actually.
[18:30] <Odd_Bloke> Perhaps `configure_secondary_nics`?
[18:30] <blackboxsw> AHH
[18:31] <blackboxsw> sure, though in Azure's case apply_network_config == True has the side-effect of being the only option that'll get you secondary_nic config too, because otherwise it's just fallback :)
[18:31] <blackboxsw> same with OpenStack as it were
[18:32] <Odd_Bloke> Sure, apply_network_config is a stronger statement than configure_secondary_nics.
[18:32] <blackboxsw> but it is the most appropriate config option for Oracle... and I suppose we could add that alias in Azure && OpenStack to mean apply_network_config= True  if we wanted to grow similary config options for each DS
[18:32] <Odd_Bloke> I'm not sure that disabling secondary NICs is something we want to enable generically.
[18:32] <Odd_Bloke> At least, not without some intentional discussion about it.
[18:33] <blackboxsw> ahh, flipping that on it's head right, the converse would not be true in Azure/OpenStack. configure_secondary_nics == False. I get you. agreed
[18:35] <blackboxsw> rharper: ssh<EMAIL_ADDRESS>[18:35] <blackboxsw> id imported
[18:35] <rharper> y
[18:36] <blackboxsw> I'd like to have you walk me through triage if you would
[18:36] <blackboxsw> hangout?
[18:36] <rharper> yes
[19:19] <Odd_Bloke> rharper: blackboxsw: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371053 <-- Oracle secondary VNICs (WIP because I need to document the new behaviour, but otherwise ready for review)
[21:08] <chillysurfer> unfortunately i can't seem to get the emailing to the mailing list working. i've pinged the launchpad channel to see if they have any ideas. but in the meantime, the message i've been trying to send is a question about vendordata getting overwritten by userdata: https://gist.github.com/trstringer/be871f87efca0cd41e7017db0fd31798
[21:08] <chillysurfer> i dumped a gist there which was the content of the email
[21:08] <chillysurfer> let me know if you have any thoughts!
[21:12] <rharper> chillysurfer: sorry about the email trouble
[21:15] <chillysurfer> rharper: not a problem at all :)
[21:18] <rharper> https://git.launchpad.net/cloud-init/tree/tests/unittests/test_data.py
[21:18] <rharper> chillysurfer: I think looking there, that might help get the formatting right
[21:19] <rharper> I think it covers several of the jsonp merging between user/vendor data
[21:19] <chillysurfer> rharper: so my jsonp formatting is off?
[21:19] <rharper> it _looks_ like (and I need to read closer) that user-data might need to include vendor_data: {enabled: True}
[21:19] <rharper> to merge with vendor data
[21:19] <chillysurfer> oh wow
[21:19] <rharper> but I need to look at those examples too
[21:20] <rharper> because user_data can also disable vendor_data completely
[21:20] <chillysurfer> yep i see that with the /vendor_data path
[21:21] <chillysurfer> rharper: and merge_how doesn't apply to vendor data, is that correct? so even if user data and/or vendor data specify merge_how then it still won't be "included"
[21:21] <chillysurfer> is that a fair statement?
[21:21] <rharper> it can
[21:22] <rharper> but the user-data needs to include it as well
[21:22] <rharper> this is awkward
[21:22] <chillysurfer> "this is awkward" -> you mean that user-data includes merge_how to take vendor data into account?
[21:22] <rharper> requiring user-data to specify merge-how in each section
[21:22] <rharper> that is if you pass in 3 user-data mime parts
[21:22] <rharper> each one has to say the merge-how
[21:22] <chillysurfer> ah i see
[21:23] <rharper> you cant, set a _default_ merge-how
[21:23] <rharper> via cloud-config
[21:23] <chillysurfer> so for instance if user data specifies runcmd then that section needs to specify a merge_how?
[21:23] <rharper> I'd like to say, list: append : dict: recusrive: append et c
[21:23] <rharper> yes, in vendor-data and in each user-data
[21:23] <rharper> which is a real PITA
[21:23] <chillysurfer> yeah that sounds pretty rough
[21:24] <rharper> the lxd folks had a more common append and recursive update for dicts; and users could *clear* previously merged data by inserting empty list or things like that
[21:24] <chillysurfer> but how else could a vendor communicate to a user "hey we want to do this thing, but you need to specify a merge_how in runcmd, bootcmd, etc"
[21:24] <rharper> I need to read up on their implementation but was thinking that might be nicer for cloud-init
[21:24] <rharper> documentation
[21:24] <rharper> which is why it's not great
[21:25] <chillysurfer> rharper: right i see what you mean. so for lxd the user would have to deliberately clear sections, but for cloud-init it's the opposite... no action is clearing vendor data, and requires action to retain vendor data
[21:26] <rharper> well, at least I;d like some cloud-config to set the default merge mode
[21:54] <metsuke> I'm attempting to use cloud images on ESXi.  Am I able to provide a "Url to seed instance data from" on ESXi and then it will use the host's network to grab the config, or do I need to configure the VM's network first?
[22:14] <Odd_Bloke> metsuke: o/ I believe cloud-init will attempt to DHCP on the first interface in order to fetch that data, but let me double check.
[22:17] <Odd_Bloke> metsuke: OK, no, it doesn't do an ephemeral DHCP (which is what I was thinking of), but I _believe_ that it will only attempt to fetch metadata after networking is up in the host.
[22:18] <Odd_Bloke> metsuke: I'm not very familiar with ESXi or the OVF data source though, so your best bet is probably to try it and see what happens. :)
[22:20] <metsuke> That makes sense, thank you. I'm trying to make these images as barebones as possible without having to set up things like network configs manually
[22:24] <Odd_Bloke> cloud-init will configure the first interface to DHCP by default.
[22:24] <Odd_Bloke> So if you have DHCP set up, then you shouldn't need to touch network config to get the instances up, at least.
[22:25] <metsuke> Odd_Bloke: indeed, though in my particular case, a specific static IP is required for connectivity


 Looking forward to Friday
[22:47] <aedend> just curious why you don't use an addon for disabling ads?
[22:48] <Unit193> I do, this is different.  You know the 'speed dial'?  Ever seen suggestions there?  Yeah, I think of those as ads.
[22:49] <Unit193> I use ublock Origin.
[22:51] <aedend> Unit193, not sure what you mean by "speed dial"?
[23:36] <Unit193> http://www9.pcmag.com/media/images/347219-firefox-new-tab-page.jpg?thumb=y


[15:57] <NCommander> Morning all
[15:58]  * janimo waves
[15:58] <Guest40648> G'day NCommander
[15:59] <NCommander> #startmeeting
[15:59] <MootBot> Meeting started at 09:59. The chair is NCommander.
[15:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:00] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110526
[16:00] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110526
[16:00] <NCommander> *is having some issues with the wiki and 500 errors*
[16:00] <NCommander> There are no action items from last meeting so ...
[16:00] <NCommander> [topic] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html
[16:00] <MootBot> New Topic:  http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html
[16:00] <NCommander> [topic] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html
[16:00] <MootBot> New Topic:  http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html
[16:01] <ogra_> still lots missing
[16:01] <NCommander> and of course the WI tracker doesn't see any of my specs
[16:01] <ogra_> but davidm said he would do an approval round
[16:02] <ogra_> NCommander, they need to be approved first
[16:02] <Guest40648> Yep I want to to approvals today
[16:02] <ogra_> and have a prio
[16:02] <ogra_> and indeed need to be assigned to oneiric
[16:02] <ogra_> i see 6 for NCommander btw :)
[16:03] <NCommander> yeah, a number thats bound to go up :-(
[16:03] <ogra_> yes
[16:03] <GrueMaster> I see none for me.  Yippie!
[16:03] <ogra_> heh
[16:03] <NCommander> I sent a list of all the server specs to davidm. With the exception of the security/entropy one, they're all drafted and ready for review
[16:03] <ogra_> you have at least two items on my specs
[16:03] <GrueMaster> damn.  :(
[16:03] <ogra_> https://blueprints.edge.launchpad.net/~davidm?searchtext=o-arm
[16:04] <ogra_> that should be all our specs
[16:04] <ogra_> if anything is missing we need to fix that
[16:04]  * ogra_ sees david has fun with nickserv
[16:05] <NCommander> I don't think there's anything else on burndown charts
[16:06] <NCommander> [topic] Unity 2D Status
[16:06] <MootBot> New Topic:  Unity 2D Status
[16:06] <ogra_> well, action; everyone get their specs in the right state
[16:06] <ogra_> before end of the week
[16:06]  * ogra_ guesses release team wants to review in the release meeting tomorrow
[16:06] <NCommander> [action] everyone to get their specs in proper shape before end of the week
[16:06] <MootBot> ACTION received:  everyone to get their specs in proper shape before end of the week
[16:06] <ogra_> NCommander, we too that one out btw
[16:07] <ogra_> unity-2d is desktop team now
[16:07]  * ogra_ though we discussed that last week)
[16:07] <davidm_> See if I stay davidm this time
[16:07] <ogra_> heh
[16:07] <ogra_> just be nice to nickserv :)
[16:07] <davidm_> sometimes nickserv hates me
[16:08] <NCommander> flower and candy are a good way to sooth rough feelings
[16:08] <ogra_> heh
[16:08] <NCommander> [topic] Kernel Status (cooloney, rsalveti, ppisati)
[16:08] <MootBot> New Topic:  Kernel Status (cooloney, rsalveti, ppisati)
[16:08] <ogra_> davidm_, since you missed it
 well, action; everyone get their specs in the right state
 before end of the week
[16:08] <ogra_> ACTION received:  everyone to get their specs in proper shape before end of the week
[16:08] <ogra_> davidm_, i suspect the release team will want to review
[16:08] <davidm_> Actually I need to get to it today as today is the deadline
[16:08] <rsalveti> bug 770679 is now fixed commited
[16:09] <ogra_> so we need to get them ready before meeting
[16:09] <rsalveti> only major change for kernel
[16:09] <rsalveti> still long way to hit the archive
[16:09]  * ppisati is here too
[16:09] <ogra_> rsalveti, thats .proposed though
[16:09] <ogra_> any oneiric news you want to share ?
[16:09] <rsalveti> ogra_: not yet proposed
[16:10] <ogra_> well, will be :)
[16:10] <ppisati> nothing i'm aware off: at last TI call someone mentioned a .39 tree, wwaiting for it to appear
[16:10] <janimo> omap4 still remains a separate source for O ?
[16:10] <ppisati> yes
[16:11] <ppisati> still a topic branch
[16:11] <ogra_> yup
[16:11] <ppisati> we will cherry pick CVE and stable updates from master
[16:11] <ppisati> no rebase (unfrotunately)
[16:11] <ogra_> until mainline is on par feature wise
[16:11] <ppisati> actually i'll try (but since ompa4 is so big i'm pretty sure i'll fail)
[16:12] <ppisati> btw, can anyone add me to the invitation of the weekly TI conf call?
[16:12] <ogra_> ppisati, talk to ndec in #ubuntu-arm
[16:12] <ogra_> he owns the invitation iirc
[16:12] <ppisati> ok
[16:13] <ogra_> NCommander, move ?
[16:13] <davidm_> ppisati, done, you are added
[16:13] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, janimo)
[16:13] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, janimo)
[16:14] <ppisati> davidm_: thanks
[16:14] <janimo> nothing here
[16:14]  * NCommander hides in fear of the FTBFS list
[16:14] <janimo> a bit of bug triaging in the KInaro Jam
[16:14] <ogra_> 31 packages in main isnt that bad
[16:14] <janimo> the nasty oes from natty are still here
[16:15] <janimo> as they are upstream issues
[16:15] <ogra_> only 8 arm specific
[16:15] <NCommander> true
[16:15] <NCommander> and some of that seems to be ghc blew up
[16:15] <ogra_> dbus, upstart and libnih look serious
[16:15] <NCommander> yeah
[16:16] <ogra_> i gave back dbus and upstart already
[16:16] <ogra_> and the failures are weird segfaults
[16:16] <janimo> ld segfaults iirc
[16:16] <NCommander> Great
[16:16] <ogra_> yep
[16:16] <NCommander> Has anyone reproduced out of the data center?
[16:16] <janimo> same in chromium
[16:16] <ogra_> do we know if anyone is inspecting that on the toolchain side ?
[16:17] <janimo> Linaro know about it, I am not sure what the status is
[16:17] <ogra_> oh, also note that we will switch seeds this release
[16:17] <GrueMaster> Buh???
[16:17] <janimo> to ubuntu-desktop?
[16:17] <ogra_> so look at the desktop seed once the first images roll in
[16:17] <ogra_> right
[16:17] <GrueMaster> ok
[16:17] <ogra_> netbook will go away
[16:18] <NCommander> ogra_: do you want to follow up with Linaro w.r.t. binutils segfaults?
[16:18] <janimo> so our images get larger as well? will we ship the same ubuntu desktop metapackage?
[16:18] <ogra_> NCommander, well, would at least be good to know a bugnumber
[16:19] <ogra_> janimo, do you know if there is one (since you seem to know that linaro knows about it)
[16:19] <davidm_> We might need to make our own  seed, I don'think we want all of desktop on ARM
[16:20] <ogra_> thats fine
[16:20] <janimo> ogra_, no idea, I just saw it discussed on #linaro
[16:20] <ogra_> we can do per-arch excludes
[16:20] <ogra_> no need for an extra seed
[16:20] <ogra_> NCommander, then put an action item on for me
[16:20] <janimo> did  not follow FTBFS lately as it seemed there were large rebuilds and I was waiting for it to settle down
[16:20] <NCommander> [action] ogra to trim down desktop seed on ARM
[16:20] <MootBot> ACTION received:  ogra to trim down desktop seed on ARM
[16:20] <ogra_> NCommander, ??
[16:20] <NCommander> ogra_: what?
[16:21] <ogra_> "<NCommander> ogra_: do you want to follow up with Linaro w.r.t. binutils segfaults?"
[16:21] <NCommander> oh
[16:21] <ogra_> i was referring to that one
[16:21] <NCommander> wrong followup :-P
[16:21] <ogra_> i dont need an action item for my day to day work :P
[16:21] <NCommander> [action] ogra to follow up with Linaro on binutils segfault
[16:21] <MootBot> ACTION received:  ogra to follow up with Linaro on binutils segfault
[16:21] <GrueMaster> Hard to follow the multiple topics of the meeting.
[16:21]  * ogra_ has nothing else for ftbfs
[16:22] <NCommander> [topic] ARM Image Status (NCommander, ogra)
[16:22] <MootBot> New Topic:  ARM Image Status (NCommander, ogra)
[16:22] <ogra_> dead
[16:22] <ogra_> but i think cjwatson built the first x86 images today
[16:22] <janimo> eta for live helper?
[16:22]  * NCommander is making funeral perperations :-(
[16:22] <ogra_> so it shouldnt be long anymore
[16:22] <ogra_> and its still 2 weeks to A1
[16:22] <NCommander> then we get to re-implement evertyhing for l-h
[16:22] <cjwatson> yesterday
[16:22] <ogra_> so chances are good we can make it
[16:23] <GrueMaster> I estimate image availability the day before A1.
[16:23] <cjwatson> janimo: not necessarily for a1
[16:23] <ogra_> cjwatson, wohoo
[16:23] <cjwatson> still using livecd-rootfs for now
[16:23] <ogra_> ah
[16:23] <ogra_> when do you plan the final switch ?
[16:23] <cjwatson> when it's ready
[16:23] <ogra_> heh
[16:23] <GrueMaster> good plan.
[16:23] <ogra_> k
[16:23] <NCommander> I don't think their is much mor eon this point
[16:24] <cjwatson> if I can make it before a1, I will, but I'm not promising anything
[16:24] <ogra_> k
[16:24] <NCommander> thanks cjwatson
[16:24] <cjwatson> the CD image cron jobs are back on now
[16:25] <GrueMaster> wrt netboot images, make sure we have both uImage/uInitrd & vmlinuz/initrd.img available
[16:25] <NCommander> \o/
[16:25] <ogra_> so we should have something to test (if it builds)
[16:25] <cjwatson> so unless GrueMaster knows something I don't, they should build tomorrow
[16:25] <ogra_> GrueMaster, will do
[16:25] <ogra_> GrueMaster, i also plan a "mini iso" as well
[16:25] <GrueMaster> I'm just speaking from experience as the QA guy that has last minute image testing to do...always.
[16:25] <NCommander> anything else on this subject or can I move on?
[16:25] <GrueMaster> :P
[16:26] <ogra_> move
[16:26]  * NCommander moves to New York
[16:26] <NCommander> :-P
[16:26] <NCommander> [topic] QA Status (GrueMaster)
[16:26] <MootBot> New Topic:  QA Status (GrueMaster)
[16:26] <ogra_> haha
[16:26] <GrueMaster> Hey, that's me.  Isn't that special.
[16:26] <GrueMaster> Work continues on usbboot.
[16:26] <ogra_> wowie
[16:27] <GrueMaster> Issues still with aboot, but we have enough to enable the buildd farm.
[16:27] <ogra_> GrueMaster, btw, it would be good to know if there is a usb0 after boot
[16:27] <ogra_> then we wouldnt need the conventional network for netcatting the tarball but could pull it via usbnet
[16:27] <GrueMaster> There is.  Networking and usb ports both function (My keyboard/mouse is on one, usb drive on the other).
[16:27] <ogra_> i mean a usbnet device
[16:28] <ogra_> (the g_ether module being loaded)
[16:28] <ogra_> well, lets discuss that offline
[16:28] <GrueMaster> Missing are mmc and reboot.  mmc is mia, reboot causes the kernel to hang at the end with message:  Rebooting.
[16:28] <ogra_> hmpf
[16:28] <GrueMaster> Oh, that requires musb to work.
[16:28] <ogra_> we dont need mmc so i dont care
[16:28] <GrueMaster> Which it doesn't.
[16:29] <ogra_> in kernel ?
[16:29] <GrueMaster> I need mmc for automation testing.
[16:29] <ogra_> hmm, i thought that worked
[16:29] <GrueMaster> Nope.
[16:29] <ogra_> gar
[16:29] <ogra_> k, then its conventional network, sad
[16:29] <ppisati> IIRC musb is broken upstream
[16:29] <ogra_> usb would have been sexier
[16:29] <ppisati> since .38.x where i don't remeber the x
[16:30] <GrueMaster> musb has never worked in .38 that I know of.
[16:30] <GrueMaster> Last worked in .35.
[16:30] <GrueMaster> iirc.
[16:30] <ogra_> well
[16:30] <ogra_> moot discussion then
[16:31] <GrueMaster> Back to usbboot.  I am very concerned about the copyright issues with the source.
[16:31] <ogra_> well, for internal use thats a non issue
[16:31] <ogra_> for packaging it thats a disaster
[16:31] <GrueMaster> Right.
[16:32] <ogra_> did you start conversation with upstream ?
[16:32] <NCommander> ogra_: w.r.t. to copyright, if the code is invalid, we can't use it, internatl or not.
[16:33] <GrueMaster> For initial deployment, I should have it working fully by eod tomorrow.  For packaging and future automation, I am looking to do a rewrite, at least for the host side.  Not much to it, shouldn't take too long (2-3 days max).
[16:33] <ogra_> NCommander, as long as we dont distribute it ...
[16:33] <NCommander> ogra_: I'm not going to argue specifics during this meeting, but I'll be glad to discuss in private
[16:34] <ogra_> sure
[16:34] <GrueMaster> The mods needed for immediate deployment are fairly trivial and can be pushed upstream.
[16:35] <NCommander> can I move on?
[16:35] <GrueMaster> I am also gearing up to review lava for our use.
[16:35] <GrueMaster> Currently, it will not work with our images.  Looking to see what modifications need to be in place for that.
[16:35] <GrueMaster> Done.
[16:36] <davidm_> I'm sure we can sort license issues, I'm in contact with upstream
[16:36] <NCommander> [topic] AOB]
[16:36] <MootBot> New Topic:  AOB]
[16:36] <ogra_> is it a requirement that all images get tested with lava ?
[16:36] <ogra_> or could we just define a certain set of i.e. images that work ootb
[16:36]  * ogra_ could imagine the mini iso might work just fine
[16:37] <ogra_> or any other alternate ones
[16:37] <GrueMaster> I was told to get lava working on some of our images.  headless & server are prime candidates.
[16:37] <ogra_> well, mini iso with server preseed file should get you that
[16:37] <ogra_> it can test isos too, right ?
[16:38] <GrueMaster> no.
[16:38] <ogra_> (i mean for x86)
[16:38] <ogra_> err
[16:38] <GrueMaster> It currently works with linaro style images & hw packs.
[16:38] <ogra_> why the heck are we forced to use it then ? i thought its the "save the world" solution for all image testing automation
[16:38]  * ogra_ wasnt aware thats only used for linaro tarballs
[16:38] <GrueMaster> Not my call.  Way beyond my pay grade.
[16:39] <ogra_> hmpf
[16:39] <ogra_> then i dont understand the hype
[16:39] <GrueMaster> That's why it is called the Linaro Automated Validation App.
[16:39] <ogra_> right, still i thought the plan was to have all images tested on it
[16:40] <GrueMaster> The front end is pretty good.  It is the back end that needs rework.  Unfortunately, it is all combined in one atm.
[16:40] <GrueMaster> It isn't modular.
[16:40] <ogra_> oh, like livecd-rootfs :)
[16:40] <GrueMaster> Never having seen that, I can only guess.
[16:40]  * ogra_ likes non modular after looking at live-build today :P )
[16:41] <ogra_> anyway, no more questions for QA here
[16:41] <GrueMaster> You want modular, but in an intelligent way.
[16:42] <GrueMaster> Otherwise we would be stuck with a hugh kernel binary that loaded every driver under the sun.
[16:42]  * ogra_ doesnt want too modular :)
[16:42]  * NCommander would rather just refactor livecd-rootfs into modules
[16:42] <NCommander> :-P
[16:42] <ogra_> NCommander, ++++++++++++
[16:42] <ogra_> +++
[16:42] <ogra_> and +
[16:42] <GrueMaster> The proper way to do it is with libraries and function calls.
[16:42] <ogra_> but i guess we cant have that pony
[16:42] <GrueMaster> At least that was what I did in my old days of automation development.
[16:43] <ogra_> well, for shell scripts thats different :)
[16:43] <GrueMaster> Not just shell scripts.
[16:43] <ogra_> i agree for C code though ...
[16:43] <ogra_> but we somehow get offtopic :)
[16:44] <GrueMaster> I'm done unless someone has other questions on QA.
[16:44] <NCommander> anything got anything else?
[16:45] <NCommander> if not, I'll close the meeting
[16:45] <ogra_> go for it
[16:45] <NCommander> closing in 3
[16:45] <NCommander> 2
[16:45] <NCommander> 1
[16:45] <NCommander> #endmeeting
[16:45] <MootBot> Meeting finished at 10:45.
[16:45] <ogra_> and dont call me anything :P
[16:46] <NCommander> er
[16:46] <NCommander> anyone
[16:46] <NCommander> wow
[16:46] <ogra_> :)
[16:48] <rsalveti> ogra_: we should be able to test ubuntu images on lava
[16:48] <rsalveti> it's linaro but it can be more generic
[16:48] <rsalveti> if it's not supported yet it's just because nobody created the support
[16:48] <rsalveti> but it'll probably be there
[16:48] <ogra_> right
[16:48] <rsalveti> pplars can answer your questions on this
[16:49] <ogra_> i was expecting that it already supports a wider range of images if we switvch the whole testing framework
[16:49] <ogra_> but apparently that needs to grow first :)
[17:47] <ubuser> can someone help me? i tried to install grub2
[17:47] <ubuser> and now my pc wont boot, it says grub error 15
[17:47] <ubuser> is there anyway around this from boot screen?
[17:48] <davidcalle> ubuser: hi, this channel is dedicated to team meetings, you should ask this question in #ubuntu.
[17:48] <smartere> Hello there
[17:48] <ubuser> yea, i got booted from the others
[17:48] <ubuser> please help me.
[17:49] <ubuser> ive been having problems after problems and they just dont like me
[17:49] <ubuser> idk what to do anymore
[17:49] <ubuser> i cannot get my pc running
[17:49] <davidcalle> ubuser, you can try to ask on #omg!ubuntu!
[17:49] <ubuser> ty
[17:51] <ubuser> b4 i reload, again..
[18:00] <Technoviking> are folks here for the Ubuntu Power User meeting
[18:01] <Omega> o/
[18:01] <xdatap1> \o/
[18:01] <toros> .o/
[18:01] <Technoviking> awesome
[18:01] <Technoviking> #startmeeting
[18:01] <MootBot> Meeting started at 12:01. The chair is Technoviking.
[18:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <Technoviking> [LINK] https://wiki.ubuntu.com/PowerUsers/Meeting
[18:02] <MootBot> LINK received:  https://wiki.ubuntu.com/PowerUsers/Meeting
[18:02] <Technoviking> there is the agenda
[18:03] <Technoviking> [TOPIC] Organization of the team
[18:03] <MootBot> New Topic:  Organization of the team
[18:04] <Technoviking> So this team is pretty new and we are still getting our bearing
[18:05] <Technoviking> We have done alot of work on our wiki
[18:07] <Technoviking> [link] https://wiki.ubuntu.com/PowerUsers
[18:07] <MootBot> LINK received:  https://wiki.ubuntu.com/PowerUsers
[18:07] <Technoviking> but I think the key thing we need to work on is goual for the next cycle
[18:07] <Technoviking> s/goual/goals
[18:08] <Technoviking> first off, low hanging fruit
[18:09] <Technoviking> We have been working on getting useful Unity quicklist in to the Ubuntu 11.10 base install
[18:09] <Technoviking> [LINK] https://wiki.ubuntu.com/PowerUsers/Quicklists
[18:09] <MootBot> LINK received:  https://wiki.ubuntu.com/PowerUsers/Quicklists
[18:09] <Technoviking> what else can we help with this?
[18:10] <Technoviking> I guess first off, I shall have asked if everyone know what the team vision is?
[18:11] <Omega> Clarify on that (so we are all on the same page).
[18:12] <Technoviking> yes?
[18:13] <snap-l> Please state the vision. :)
[18:25] <LaserJock> Technoviking: does that make sense?
[18:25] <Miles-Prower> The guy trying to make Unity run on his Eee701 (CPU @ 600MHz)
[18:26] <Technoviking> LaserJock: yes
[18:26] <Technoviking> but we need to focus on clear actionable goals
[18:26] <LaserJock> Technoviking: yes, thats the next step
[18:26] <Technoviking> LaserJock: so, what do you suggest
[18:27] <LaserJock> well, we have 3 fronts, right, Docs, Tools, Communicate
[18:27] <jono> apologies for being silent, currently doing a job interview for my team
[18:27] <Technoviking> maco: also I think we need to think Ubuntu on this team as derivative generic
[18:28] <LaserJock> I'm thinking it would be good to start of by picking maybe 3-5 actionable (low-hanging fruit?) things to do in each category
[18:28] <Technoviking> there power users on Ubuntu, Kubuntu, Studio, etc...
[18:29] <LaserJock> in Tools, there is discussion about Ubuntu Tweak and other such tools and how to get them ready for the archives
[18:29] <Omega> Technoviking: That's what I have been trying to say, but didn't want to clutter the meeting up more, so I just dropped it.
[18:29] <Technoviking> The dev of Ubuntu Tweak joined our mailing list
[18:29] <LaserJock> yes, good start
[18:30] <LaserJock> I think an analysis of Ubuntu Tweak
[18:30] <Technoviking> [LINK] https://wiki.ubuntu.com/UbuntuTweak
[18:30] <MootBot> LINK received:  https://wiki.ubuntu.com/UbuntuTweak
[18:30] <LaserJock> a  Power Users Bug Day
[18:30] <xdatap1> Technoviking, I agree with derivates. And also, a power user may be interested in mixing technologies from different platforms. Yesterday I tried plasma-desktop over unity, it was fun :)
[18:31] <LaserJock> and then we need to liaison with MOTU to figure out what needs to be done
[18:31] <Technoviking> so, I think the next version of Ubuntu Tweak will have a plugin feature, so the PPA part the prgram can been an spearate install in the next version.
[18:32] <LaserJock> a plugin system will be a major help
[18:32] <Technoviking> do we have in MOTU/core-devs on the poweruser team yet
[18:32] <LaserJock> I'm former core dev but a bit rusty
[18:32] <maco> LaserJock: you expired?
[18:33] <LaserJock> yes, I let it go
[18:33] <Technoviking> LaserJock: would you be willing to work with<EMAIL_ADDRESS>and be that liaasion
[18:33] <Technoviking> I can help as needed
[18:34] <LaserJock> maybe, I think maybe we need to cross that bridge when we get there
[18:34] <LaserJock> I think Ubuntu Tweak still needs some work, I think it's good to focus on getting the code in shape
[18:35] <LaserJock> the packaging will fall into place pretty easily once that is done
[18:36] <LaserJock> Ubuntu Tweak does a lot of stuff
[18:36] <LaserJock> I think it really needs some analysis
[18:36] <Omega> Maybe we can start documenting the various configuration options that are available (in dconf)
[18:36] <LaserJock> for safety and stability
[18:37] <LaserJock> It killed my Unity and did some funky things on me the other day
[18:37] <LaserJock> so I want to see the 100+ bugs looked at
[18:38] <Technoviking> LaserJock: We should add that info to the tweak wiki
[18:39] <Technoviking> What actions do people suggest we can work on now
[18:40] <toros> LaserJock: have you tried the stable or a development version of ubuntu tweak?
[18:40] <LaserJock> stable I think
[18:40] <LaserJock> whatever is on their site
[18:40] <LaserJock> Technoviking: do we know if trualatrix wants help with the plugin system?
[18:40] <Omega> Well, the documentation of the various configuration options we have available (we need this info to integrate it into a pretty GUI configurator anyway)
[18:41] <Technoviking> He is looking for people to write plugins
[18:41] <toros> he asked for help in creating the unity plugin
[18:41] <LaserJock> it seems to me that the plugin system and plugin writing/analysis would be top priorities
[18:42] <xdatap1> Technoviking, I agree with Omega, we need to document what we can configure on unity. Also what we would like to configure. IE: launcher background color and alpha is not configurable afaik
[18:42] <LaserJock> I would favor essentially starting with a blank slate and adding plugins as they are found to be stable and meeting Use Cases
[18:43] <cprofitt> just got back from doing a trouble ticket -- I am curious what low hanging non-technical items need to be tackled?
[18:43] <LaserJock> On the documentation front, I agree with Omega and xdatap1,  a good set of documentation on Unity would be great
[18:43] <agrundner> I'm getting the feeling that this ubuntu power user idea is morphing into something unexpected and possibly unwieldy. Looking forward to seeing an outline of the scope of this project.
[18:43] <LaserJock> keyboard shortcuts, what options exist and what they actually do
[18:43] <cprofitt> +1 xdatap1 -- documenting what can be done would be a good idea... and one I could put some people to work on as well as do myself
[18:44] <toros> LaserJock: we already have many documentation on Ask Ubuntu
[18:44] <LaserJock> some yes
[18:44] <Omega> agrundner: Now is your chance to influence it, speak up! :)
[18:44] <LaserJock> but Ask Ubuntu is not, IMO, a documentation source
[18:44] <maco> LaserJock++
[18:44] <Technoviking> is the doc team working on Unity docs
[18:45] <LaserJock> maco: I would also like to see some documentation maybe on the KDE side
[18:45] <toros> is there anything that isn't documented on Ask Ubuntu regarding Unity?
[18:45] <LaserJock> yes
[18:45] <LaserJock> like what the heck some of the options actually mean/do
[18:45] <maco> LaserJock: ive kinda got the impression it doesnt exist...like..at all
[18:45] <Omega> I'm not exactly sold on this "one configurator to rule them all" idea. Is that not why we have gsettings?
[18:45] <LaserJock> Omega: I agree
[18:45] <Omega> Err, dconf-editor.
[18:45] <maco> LaserJock: nixternal used to write kubuntu docs but he's been busy the last year and a team hasnt really formed around it
[18:45] <LaserJock> well
[18:46] <LaserJock> I'm not saying kubuntu docs
[18:46] <Technoviking> there can be multiple, but "support one" is a good idea
[18:46] <maco> LaserJock: and based on what happens every time i try the help menu in any app in kubuntu, either there are no docs upstream or for some reason we dont put them on the iso
[18:46] <LaserJock> I mean Kubuntu Power User docs, which I don't know if they really exist or not
[18:46] <agrundner> "kitchen sink" app to tweak your desktop and Unity defaults: cool. #ubuntu-power-user channel to exchange tips and experiences: cool. Wiki for XYZ outside of kitchen sink's capabilities: potentially become a mess and overlap previous wiki documentation items.
[18:46] <LaserJock> well, you don't have to put a GUI on *every* option
[18:46] <cprofitt> askubunut is a good place to look for help if you know what you are looking for... but some folks want to know what is possible and would not know what to search for
[18:47] <Technoviking> I think the power user wiki is a good place to centralize the docs, maybe get it into help.ubuntu.com at a later date
[18:48] <LaserJock> I still have no idea what "Fade on bfb and Slide" means in the Hide Animation option in Unity
[18:48] <LaserJock> for instance :-)
[18:48] <cprofitt> Technoviking: I think having the wiki point at askubuntu is ok too, but having a centralized place to document the 'cool power options' is good
[18:48] <Technoviking> So do we want to make a overall Unity Guide a action item for the next few month
[18:48] <toros> LaserJock: http://askubuntu.com/questions/29553/how-can-i-configure-unity
[18:49] <toros> "Fade on bfb and Slide - fades based on the position of your cursor in the bfb (big funny button - the one in the top left of your panel with the Ubuntu circle of friends on it) and slides."
[18:49] <toros> It's already documented :)
[18:49] <LaserJock> no
[18:49] <LaserJock> that's not documented
[18:50] <LaserJock> thats somewhere on the net where I never found it ;-)
[18:50] <LaserJock> it doesn't do me any good if I don't know it exists
[18:50] <LaserJock> that's the point of a centralized "go to" place
[18:50] <cprofitt> LaserJock: +1
[18:50] <cprofitt> it makes it easy for us to 'document it' since all we have to do is point to it
[18:50] <Technoviking> +1 here
[18:50] <LaserJock> in other words, Ask Ubuntu is great for information
[18:51] <LaserJock> not so great for documentation
[18:51] <Technoviking> LaserJock: agree
[18:51] <toros> cprofitt: it is already linked at our wiki: https://wiki.ubuntu.com/PowerUsers/Documentation
[18:51] <cprofitt> toros: awesome!
[18:51] <toros> should we make a copy&paste session, and copy&paste everything from ask ubuntu into a wiki?
[18:52] <LaserJock> well, and organize and prettify it
[18:52] <LaserJock> but I think it would be a good idea personally
[18:52] <Technoviking> DO we want to make a https://wiki.ubuntu.com/PowerUsers/Documentation/UnityGuide page, to organize just the UNity info and make it an easy link to sahre
[18:52] <LaserJock> sounds good to me
[18:52] <agrundner> Not sure what happened there... sorry if I missed any responses.
[18:52] <xdatap1> Technoviking, +1
[18:53] <Technoviking> [action] create an UnityGuide page on the wiki
[18:53] <MootBot> ACTION received:  create an UnityGuide page on the wiki
[18:53] <LaserJock> I would like to see pages for the different use cases too
[18:54] <agrundner> LaserJock: there should be a UnityGuide in the official docs, no?
[18:54] <LaserJock> what official docs?
[18:54] <cprofitt> usecases would be a good idea as well
[18:55] <toros> personally, I am not really a fan of forking an already existing documentation...
[18:55] <Technoviking> agrundner: help.ubuntu.com
[18:55] <Technoviking> ?
[18:55] <agrundner> LaserJock: sorry, in the non-poweruser ubuntu wiki
[18:55] <LaserJock> well, it might go there when it's done
[18:55] <toros> I think it is better to spend our time on improving the already existing one rather than copying it
[18:56] <LaserJock> toros: I would see Ask Ubuntu as a starting point
[18:56] <agrundner> toros: that's kind of my point
[18:57] <Technoviking> I think have a Unity section of the docs section would help the wider community,
[18:57] <LaserJock> docs generally undergo  a few stages of development
[18:57] <LaserJock> information -> Work In Progress/feedback -> publication
[18:57] <agrundner> Technoviking: exactly... there should be a general documentation as a base and then a power user wiki page for tweaks/overrides
[18:58] <LaserJock> Ask Ubuntu is (information), the Power User wiki would be (Work in Progress), and help.ubuntu.com would be (Publication)
[18:59] <toros> LaserJock: what about things like custom quicklists, lenses, etc.? Should they be included in the documentation? (add this PPA, install that package...)
[19:00] <LaserJock> most likely yes, if they reach stability
[19:00] <Technoviking> so, we need to close out, out two goals are duction an unity section and working with Ubuntu Tweak dev and help get his program into the archive for Ubuntu 11.10
[19:01] <LaserJock> when should the next meeting be?
[19:01] <Technoviking> same time next month, or should we switch times
[19:02] <cprofitt> as difficult as it is for me to do this during work -- I think stable meeting times are better than rotating
[19:02] <cprofitt> rotating tends to cause confusion
[19:02] <LaserJock> would it be worth setting up a time "poll" to see what most people want?
[19:03] <LaserJock> I just usually pick morning US/evening Europe
[19:03] <LaserJock> but it stinks for East Asia
[19:03] <xdatap1> maybe a poll in doodle for checking in which timezone lives most of the members?
[19:03] <Technoviking> xdatap1:  could you set that up
[19:03] <xdatap1> Technoviking, sure, no problem
[19:04] <Technoviking> thanks
[19:04] <agrundner> FYI, I was confused about the location of the meeting. The channel message #ubuntu-power-users makes it sounds like it was going to be held there
[19:04] <Technoviking> ok , sorry I have to go
[19:04] <Technoviking> the meeting should take place in #ubuntu-meeting always
[19:04] <xdatap1> Technoviking, bye and thanks for this meeting
[19:05] <LaserJock> thanks Technoviking
[19:05] <Technoviking> #endmeeting
[19:05] <LaserJock> thanks everybody
[19:05] <MootBot> Meeting finished at 13:05.


[08:41] <Burgundavia> ajmitch: zch is looking to help you with authtool, but you keep missing each other
[08:49] <ajmitch> ok
[12:32] <zch> hi
[12:38] <fernando> zch: hi


[00:17] <menn0> thumper: next one (small): http://reviews.vapour.ws/r/5112/
[00:21] <davechen1y> menn0: re: the conversation we had at standup
[00:29] <wallyworld> redir: sorry, network dropped
[00:30] <davechen1y> menn0: increasing the timeout, i'm having trouble finding the place to make that change
[00:31] <redir> wallyworld: meeting timeout:)
[00:32] <wallyworld> redir: yeah, sorry, network dropped out
[00:32] <wallyworld> i think we had finished?
[00:32] <redir> sure
[00:32] <redir> I've got enough rope...
[00:41] <menn0> davechen1y: I was thinking that testWatcher.NumDeltas should be changed to take a timeout
[00:41] <menn0> davechen1y: and then change the 2 calls to it so that AssertNoChanges passes ShortWait and AssertChanges passes LongWait
[00:41] <davechen1y> There are millions of AssertNoChanges
[00:42] <davechen1y> and something about a stringsWatcher
[00:42] <menn0> davechen1y: the 2 places where NumDeltas is called
[00:42] <davechen1y> is that a test mock ? or the usual strings watcher
[00:42] <davechen1y> oh creap
[00:42] <davechen1y> https://bugs.launchpad.net/juju-core/+bug/1594578
[00:42] <menn0> testWatcher.AssertNoChange and
[00:42] <mup> Bug #1594578: state: test failure in race build <juju-core:New> <https://launchpad.net/bugs/1594578>
[00:42] <davechen1y> I was looking at the wrong bug
[00:42] <davechen1y> sorry, it should make sense now
[00:43] <menn0> davechen1y: looks to be a special mock/fake for these tests
[00:43] <menn0> it's all a bit ropey
[00:44] <menn0> davechen1y: the whole NumDeltas thing a bit crap... maybe there's a better way.
[01:11] <wallyworld> thumper: does maas 1.9 support arbitary tags on machines? maas 2 does right - that tag slice on gomaasapi/machine can have anything added to it we want during StartInstance() ?
[01:11] <thumper> wallyworld: no
[01:11] <thumper> the tag slice at the moment is maas tags
[01:11] <thumper> not user defined tags
[01:11] <thumper> I don't think gomaasapi exposes the user tags yet
[01:12] <wallyworld> damn ok
[01:12] <wallyworld> was hoping to add controller uui etc
[01:12] <thumper> nope
[01:12] <thumper> sorry
[01:12] <wallyworld> ok :-(
[01:12] <wallyworld> still need that provider-state file then
[01:12] <thumper> for now
[01:13] <wallyworld> was hoping to avoid an upgrade step
[01:19] <davechen1y> menn0: wow, AssertNoChange is nuts
[01:19] <davechen1y> start sync, look, and hope that nothing changed
[01:19] <davechen1y> so you dn't know if you looked to quickly
[01:19] <davechen1y> or if nothing happened
[01:19] <davechen1y> or something else went wrong
[01:43] <wallyworld> menn0: you got a minute?
[01:43] <wallyworld> or thumper
[01:43] <wallyworld> got a migration question
[02:07] <menn0> wallyworld: hi, yep
[02:07] <wallyworld> menn0: quick hangout?
[02:08] <menn0> wallyworld: sure
[02:08] <wallyworld> https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
[02:08] <wallyworld> axw: ^^^
[02:19] <mup> Bug #1594290 changed: Duplicate key error on juju.txns.stash creating model <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1594290>
[02:22] <davechen1y> menn0: thanks for your suggetiosn
[02:23] <davechen1y> i have  PR that makes that test a little less crackful
[02:24] <menn0> davechen1y: awesome. let me know if you need a review.
[02:44] <thumper> menn0, wallyworld: trivial fix http://reviews.vapour.ws/r/5114/
[02:44] <wallyworld> ok
[02:45] <menn0> thumper: double ship it
[02:45] <wallyworld> thumper: jeez, what a bad assert
[02:45] <thumper> cheers
[02:46] <thumper> I'll just backport to 1.25
[02:55] <natefinch> who wants to review some windows code?  Fun for young and old! https://github.com/natefinch/npipe/pull/21
[02:56] <natefinch> (also short and easy)
[03:00] <davechen1y> menn0: allwatcher_internal_test.go:3106: c.Assert(len(d), gc.Equals, 0)
[03:00] <davechen1y> ... obtained int = 1
[03:00] <davechen1y> ... expected int = 0
[03:00] <davechen1y> yay
[03:00] <davechen1y> i fixed it
[03:00] <davechen1y> now the other test fails ...
[03:00] <davechen1y> fml
[03:01] <menn0> davechen1y: progress! ;-)
[03:03] <davechen1y> sorta
[03:04] <davechen1y> also, witness the brilliance of gocheck
[03:04] <davechen1y> http://paste.ubuntu.com/17630317/
[03:04] <davechen1y> which of the six calls to AssertNoChange on this page failed ?
[03:04] <davechen1y> there is a prize if you guess the correct one
[03:05] <davechen1y> 'cos I sure af don't know
[03:07] <wallyworld> axw: oh yeah, also, there's currently no exposed method to get the name of the model's cloud that i can see; there's st.Cloud() but that doesn't expose the nme from the cloudDoc
[03:07] <wallyworld> did we want to use a bespoke struct which maybe embeds cloud.Cloud
[03:08] <axw> wallyworld: State.ControllerInfo() has it
[03:08] <wallyworld> ah rightio
[03:08] <axw> wallyworld: I think we'll end up adding it to Model tho
[03:08] <wallyworld> i thiknk so yeah
[03:08] <axw> a new method, CloudName() string
[03:08] <wallyworld> i'll stick with what we have for now
[03:08] <natefinch> davechen1y: it's not fair to blame bad tests on the framework.  It would be just as bad with the default test infrastructure
[03:08] <wallyworld> can iterte
[03:09] <davechen1y> natefinch: false
[03:10] <davechen1y> t.Errorf(...) // will print this exact line
[03:10] <davechen1y> it does mean you cannot write test helpers
[03:10] <davechen1y> but that was something that rob pike hates
[03:10] <davechen1y> for reasons that I don't understand
[03:11] <natefinch> my general approach to tests is that DRY is an extreme anti-pattern in tests.   You want the code right in your face as much as possible.
[03:13]  * thumper looks at how to reapply a diff
[03:13] <natefinch> this kind of failure message is one reason why I hate table driven tests. You have to be really really careful about how you code them, or they are super confusing when they fail.  The latest addition to the go test framework makes that significantly better, but not perfect.
[03:18] <davechen1y> thumper: FUK FUK FUK
[03:18] <davechen1y> now i've broken the test the other way
[03:18] <thumper> heh
[03:18] <davechen1y> AssertNoChange now randomly reports some bullshit results
[03:23] <thumper> oops
[03:25] <davechen1y> this is like when you're working on the car
[03:25] <davechen1y> you;ve got the engine disconnected from the transmission and you discover you need a part from the store
[03:25] <davechen1y> and you've just taken your car apart
[03:28] <natefinch> davechen1y: http://www.dailymotion.com/video/x2gp98t
[03:29] <thumper> wallyworld: http://reviews.vapour.ws/r/5118/ serialization tag reintroduction
[03:29] <thumper> wallyworld: what did I get wrong last time?
[03:29] <wallyworld> storagesize
[03:30] <thumper> wallyworld: can I get you to cast your eyes over the diff
[03:30] <thumper> and just open issues for all wrong bits?
[03:30] <wallyworld> yep looking
[03:30] <thumper> I'll fix before landing
[03:30] <thumper> cheers
[03:30] <wallyworld> thumper: diff looks like you got branches mixed up
[03:31] <thumper> wat?
[03:31]  * thumper looks
[03:31] <wallyworld> hmm maybe not
[03:31] <wallyworld> just saw the first few changes
[03:31] <wallyworld> looked unrelated
[03:31] <thumper> no
[03:31] <thumper> there were issues where the api was doing bad things
[03:31] <thumper> like using its own structs
[03:31] <thumper> or passing through state structures
[03:32] <wallyworld> gawd
[03:32] <thumper> wallyworld: also, if testing was inside a goroutine
[03:32] <thumper> I ended up changing the Asserts for Checks
[03:33] <thumper> because you souldn't assert in a go routine
[03:33] <wallyworld> yay, good catch
[03:33] <thumper> full test suite run is running locally for that branch
[03:33] <thumper> making my fan howl
[03:43] <menn0> wallyworld: so as fwereade pointed out in a review yesterday, it's a bug that the client side watchers (in api/watcher) could still be doing stuff (like calling the Stop API for a watcher) after the client side watcher has indicated it is done
[03:44] <menn0> wallyworld: I think I know how to fix it (using catacombs) but it's a non-trivial amount of work
[03:44] <wallyworld> menn0: which bug? sorry lack context
[03:47] <menn0> wallyworld: http://reviews.vapour.ws/r/5106/ the remaining open issue
[03:48] <menn0> wallyworld: the test is even worse than it needs to be because it the Stop call happens in a goroutine that might still be running after the client side watcher is dead
[03:49] <wallyworld> menn0: i reckon land it and fix later, it's not like this PR introduces the bug
[03:49] <menn0> the problem is the way commonWatcher (api/watcher) integrates with the specific watcher types
[03:50] <menn0> wallyworld: i've already landed the PR ... just wondering about fixing the problem in a separate PR
[03:50] <menn0> I might just do Will's suggestion and have the worker take a watcher constructor
[03:50] <menn0> and file a bug about the broken watcher behaviour
[03:50] <wallyworld> sgtm, incremental progress
[03:50] <menn0> kk
[03:51] <menn0> wallyworld: thanks for being a rubber duck :)
[03:51] <wallyworld> quack quack
[03:55] <natefinch> anyone care to rubberstamp a deps update that fixes a blocking bug? http://reviews.vapour.ws/r/5119/diff/#
[03:56] <wallyworld> natefinch: lgtm
[03:56] <wallyworld> thumper: i marked the typo in the pr
[04:06] <thumper> wallyworld: cool
[04:16] <davechen1y> thumper: menn0 https://github.com/juju/juju/pull/5676
[04:16] <davechen1y> took the easy way out
[04:17] <menn0> davechen1y: looking
[04:17] <menn0> davechen1y: not sure if that's a good idea
[04:17] <menn0> davechen1y: that makes the testWatcher.AssertNoChange calls take 10s right?
[04:18] <menn0> if the code is behaving correctly and there is in fact no change
[04:18] <menn0> davechen1y: that's why I was suggesting that there might need to be a more invasive change
[04:19] <menn0> davechen1y: maybe NumDeltas should go away, and AssertNoChange and AssertChange should have independent implementations
[04:21] <davechen1y> menn0: i tried that
[04:21] <davechen1y> it jsut make a mess
[04:21] <davechen1y> i did that
[04:21] <davechen1y> menn0: http://paste.ubuntu.com/17632486/
[04:21] <davechen1y> now AssertNoChange fails reliably ... :(
[04:25] <menn0> davechen1y: hmmm
[04:25] <menn0> davechen1y: i'm not exactly sure what's happening there
[04:25] <menn0> davechen1y: is len(d) > 0 when a change is detected?
[04:25] <menn0> (where d is the actual deltas)
[04:26] <davechen1y> yup
[04:26] <davechen1y> if there is no change, then nothing should be deliverd on tw.delta
[04:33] <menn0> davechen1y: could it be that there's deltas not being completely consumed from the previous change?
[04:34] <menn0> davechen1y: FWIW I'm pretty sure AssertChanges in your diff should be using LongWait, not ShortWait
[04:34] <davechen1y> menn0: this is all rubbish
[04:34] <davechen1y> make a chage
[04:34] <davechen1y> wait to see if anything happened
[04:35] <davechen1y> maybe something happened, maybe didn't wait long enough
[04:35] <davechen1y> reverse the logic for _not_ expecting a change
[04:35] <davechen1y> there is no synchonisation, only waiting
[04:35] <davechen1y> i'm amazed this works at all
[04:35] <menn0> welcome to watchers
[04:37] <davechen1y> what a bunch of bollocks
[05:07] <mup> Bug #1594663 opened: Client side watchers may still be active when they report themselves as dead <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1594663>
[05:07] <mup> Bug #1594665 opened: reboot-executor is missing from the list of workers <juju-core:New for fwereade> <juju-core model-migration:New> <https://launchpad.net/bugs/1594665>
[05:31] <menn0> thumper or wallyworld : addresses an issue fwereade raised in a previous PR: http://reviews.vapour.ws/r/5106/
[05:31] <wallyworld> ok
[05:34] <menn0> wallyworld: sorry, wrong PR: http://reviews.vapour.ws/r/5121/
[05:34] <wallyworld> tis ok, found it already
[05:35] <menn0> wallyworld: at least it was the one where fwereade raised the issue :)
[05:38] <wallyworld> menn0: i just had a quibble / question about end-end test coverage, but it does look far less complicated
[05:39] <menn0> wallyworld: and I don't think we really lost any coverage here... the API call was fake before
[05:39] <menn0> wallyworld: it's just avoiding testing stuff that is actually in another package and tested there
[05:40] <wallyworld> rightio
[05:40] <menn0> wallyworld: agreed on the end-to-end test. there will be a feature tests added, and CI tests of course, as everything comes together
[05:40] <wallyworld> sgtm
[05:40] <menn0> wallyworld: veebers is on the case with the CI test
[05:40] <wallyworld> \o/
[06:21] <davechen1y> menn0: this is terrible
[07:14] <davechen1y> menn0: thumper https://github.com/juju/juju/pull/5678
[07:14] <davechen1y> attempt #2
[07:38] <frobware> dimitern: want to skip 1:1? I want to go through some of the things we discussed with jay last night before standup.
[07:38] <dimitern> frobware: sure, np
[07:39] <dimitern> frobware: I've picked up bug 1594580 anyway
[07:39] <mup> Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580>
[07:39] <frobware> dimitern: one useful tidbit is: sudo cat /proc/net/bonding/bond0
[07:39] <frobware> dimitern: the info in there (and must run as root) tells you whether the LACP setup actually happened.
[07:40] <dimitern> frobware: that's useful to know indeed!
[07:40] <menn0> davechen1y: reviewed
[07:41] <dimitern> frobware: I've decided against trying to set up bonding on the nucs for now
[07:41] <frobware> dimitern: makes sense in absence of h/w :)
[07:42] <dimitern> frobware: yeah :)
[07:42] <frobware> dimitern: I woild not suggest the nuc I bought - too slow and the lack of AMT is a pain
[07:44] <dimitern> frobware: what cpu did it have? dual-core celeron?
[07:44] <frobware> dimitern: yep, though it may have threads, so 4.
[07:44] <dimitern> frobware: but still.. celeron :)
[07:53] <davechen1y> menn0: thanks, i'll try to integrate some more "wait this long, max" logic
[07:55] <menn0> davechen1y: cool
[08:05] <axw> wallyworld: this change I'm working on is excruciating, and unlikely to be ready by beta10. I think I'll take a break tomorrow and fix some of the bugs raised on beta9
[08:06] <axw> and when I say "unlikely", I mean "almost certainly not"
[08:16] <anastasiamac> axw: is this json for gce?
[08:17] <axw> anastasiamac: not working on that yet, will probably look tomorrow
[08:17] <axw> anastasiamac: hve been looking at some fundamental changes to model config / cloud / credential separation
[08:17] <anastasiamac> axw: k. thnx \o/
[08:56] <mup> Bug #1594720 opened: 2.0 b9: Fail to deploy LXD container in restricted network <juju-core:New> <https://launchpad.net/bugs/1594720>
[09:02] <jam> dimitern: voidspace: standup
[09:02] <jam> ?
[09:02] <dimitern> sorry, omw
[09:38] <babbageclunk> dimitern, voidspace: hmm - why didn't this PR get a review created? Is it because I ended with a comment in parens? https://github.com/juju/juju/pull/5679
[09:39] <voidspace> babbageclunk: no idea...
[09:39] <voidspace> babbageclunk: ask ericsnow when he comes online
[09:39] <voidspace> babbageclunk: every now and then this happens
[09:39] <babbageclunk> voidspace: ugh, that's ages away
[09:39] <voidspace> babbageclunk: yep
[09:40] <babbageclunk> voidspace: I'll try a little chicken-slaughtering to see if that helps.
[09:42] <babbageclunk> voidspace: Yeah! I'm the boss of computers!
[09:44] <babbageclunk> voidspace: I mean, it could just have been a coincidence, but that superstition is sticking from now on!
[09:47] <TheMue> morning
[09:51] <babbageclunk> dimitern, voidspace, frobware: reviews welcomed! http://reviews.vapour.ws/r/5123
[09:51] <dimitern> babbageclunk: I'll have a look in a bit
[09:51] <babbageclunk> dimitern: cool thanks - no big rush
[10:18] <babbageclunk> niemeyer1: ping?
[10:21] <voidspace> babbageclunk: heh, I didn't realise chicken sacrifices helped
[10:21] <voidspace> babbageclunk: I don't have any chickens but I do have two children, maybe I could spare one of them...
[10:22] <babbageclunk> I think children are worth between 5-10 chickens.
[10:24] <voidspace> babbageclunk: so worth waiting for a really serious bug
[10:24] <voidspace> babbageclunk: hmmm... I wonder if sacrificing both would fix our issues with /en/n/i
[10:25] <voidspace> might actually be worth it...
[10:25] <voidspace> we can always grow some more
[10:25] <babbageclunk> voidspace: tsk
[11:28] <frobware> voidspace: well, no chickens or children needed. A sleep of 0.5s between ifdown/up seems to cure it. \o/
[11:33] <babbageclunk> frobware: yay!
[11:33] <babbageclunk> frobware: that's better than a 10min reboot.
[11:33] <frobware> babbageclunk: give or take, about 10mins. :)
[11:34] <frobware> babbageclunk: I cut & paste the commands we run and ran them "by hand" in the shell.. it was then I noticed that it worked.   Want to take a look at bug 1593299 ?
[13:55] <mup> Bug #1593299: HA recovery fails in azure <azure-provider> <blocker> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1593299>
[13:56] <natefinch> cherylj: I figured that might be your answer, being the only blocker not in progress.  Sure thing.
[13:56] <cherylj> I'm sorry I'm so predictable
[13:56] <cherylj> ;)
[13:56] <natefinch> :)
[13:57] <natefinch> oh azure, that special flower...
[14:24] <frankban> cherylj: hi, do you know more or less when master will be unblocked so that I can merge a couple of little contributions I have?
[14:25] <cherylj> frankban: if you send me the PRs, I'll evaluate and merge it for you
[14:25] <frankban> cherylj: http://reviews.vapour.ws/r/4936/ and http://reviews.vapour.ws/r/5124/ (though the latter could wait for another review)
[14:30] <mup> Bug #1571053 changed: container networking lxd 'invalid parent device' <ci> <lxd> <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1571053>
[14:31] <alexisb> frobware, just need a few minutes for a cup of coffee
[14:31] <alexisb> brt
[14:40] <dimitern> frobware, voidspace: a tiny-ish review fixing bug 1594590, please take a look - http://reviews.vapour.ws/r/5125/
[14:40] <mup> Bug #1594590: [needs packaging] arc-theme <Ubuntu:In Progress by fossfreedom> <Debian:New> <https://launchpad.net/bugs/1594590>
[14:40] <dimitern> oops not that one
[14:41] <voidspace> dimitern: I don't believe you ever produce small reviews
[14:41] <voidspace> but I'm willing to be surprised
[14:41] <dimitern> voidspace: :) you might be surprised
[14:41] <dimitern> let's try again mup.. bug 1594580
[14:42] <mup> Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580>
[14:43] <cherylj> frankban: I kicked off the merge for the first PR.  Let me know when you get another review for the second
[14:44] <natefinch> OMG https://jujucharms.com/docs/devel/help-azure
[14:45] <natefinch> sudo apt-get install -y nodejs-legacy npm
[14:45] <natefinch> WTF
[14:46] <frankban> cherylj: ty!
[14:46] <cherylj> natefinch: you can grab the CI creds and not have to do all that
[14:47] <voidspace> dimitern: LGTM
[14:47] <natefinch> cherylj: thanks... I have azure set up from forever ago, so in theory, I just need to grab those values off the website or something... it's just... do we really expect someone to follow this 15 (yes, I counted) step process
[14:49] <dimitern> voidspace: cheers!
[14:50] <frankban> perrito666: could you please take a look at replies at http://reviews.vapour.ws/r/5124/ ? what do you think?
[14:51] <perrito666> frankban: I see, well we can always change if we need something else in the future, as roger says
[14:52] <frankban> perrito666: so can I go ahead and ship it?
[14:53] <perrito666> frankban: you have a shipit from roger :p he just forgot to click the button
[14:53] <perrito666> frankban: is master unlocked?
[14:53] <frankban> perrito666: no, I'll handle that, I'd like to have a ship it from a core dev
[14:56] <perrito666> frankban: sure, ship it
[14:56] <perrito666> (I added the shipit to the pr)
[14:57] <frankban> perrito666: thanks
[15:03] <mup> Bug #1594855 opened: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1594855>
[15:06] <katco> ericsnow: standup time
[15:10] <cherylj> natefinch: would you be able to port your fix for bug 1581157 to 1.25?
[15:10] <mup> Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157>
[15:13] <dimitern> cherylj: hey, re 1.25.6 - still planned to ship tomorrow?
[15:13] <natefinch> cherylj: yeah. it's just a deps change
[15:14] <cherylj> thanks, natefinch
[15:14] <cherylj> dimitern: I don't think it'll be tomorrow
[15:14] <cherylj> dimitern: but we should try for this week
[15:14] <dimitern> cherylj: ok, cheers
[15:14] <cherylj> dimitern: are you asking for bug 1594855?
[15:14] <mup> Bug #1594855: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1594855>
[15:14] <dimitern> cherylj: yeah, exactly :)
[15:15] <dimitern> cherylj: it's affecting a customer
[15:15] <mup> Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
[15:15] <cherylj> dimitern: k, do you have an ETA on the fix?
[15:16] <dimitern> cherylj: likely tomorrow - frobware is testing a fix already
[15:17] <dimitern> cherylj: we've (more or less) established the root cause at least
[15:17] <cherylj> ok, cool
[15:17] <cherylj> dimitern: did someone ask you about bug 1590598 too?
[15:17] <mup> Bug #1590598: ipv6 interfaces configured on a machine (in maas) are not added to lxc containers deployed to that machine <sts> <juju-core:Confirmed> <MAAS:Invalid> <https://launchpad.net/bugs/1590598>
[15:17] <dimitern> cherylj: nope, looking..
[15:18] <cherylj> dimitern:  you had a comment in there that "we'll address this soon", and wanted to know if this was still on your radar
[15:18] <dimitern> cherylj: ah, I remember this one
[15:18] <dimitern> cherylj: yeah, it's a known limitation atm
[15:18] <cherylj> dimitern: is it something we want to commit to for 2.0?  or does it need more time and should be deferred to 2.1?
[15:19] <dimitern> cherylj: I'd say 'good to have for 2.0', but realistically - 2.1
[15:20] <cherylj> dimitern: is it large enough that it needs to be sized and budgeted for (headcount wise)?
[15:20] <dimitern> cherylj: it's not inherently difficult, there are more serious issues we're focusing on first
[15:20] <cherylj> dimitern: k, thanks
[15:21] <mup> Bug #1593838 changed: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
[15:30] <mup> Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
[15:45] <mup> Bug #1594865 opened: 2.0 beta8: deployment with sphere as provider - bootstrap node - no space left on /  <oil> <juju-core:New> <https://launchpad.net/bugs/1594865>
[15:58] <natefinch> cherylj, sinzui: where are the juju 2.0 CI credentials for azure stored?  In cloud-city somewhere, I presume?
[15:58] <cherylj> natefinch: yeah, in cloud-city
[15:58] <cherylj> natefinch:  need a refresher on how to access?
[15:59] <natefinch> cherylj: no... I just forgot I hadn't updated my branch of it in like a year
[15:59] <natefinch> cherylj: credentials.yaml looks promising :)
[15:59] <sinzui> natefinch: cloud-city, look in credentials.uaml
[16:07] <natefinch> ahhhh azure is so slow
[16:12] <natefinch> whoever added model/controller/cloud/version to juju status, thank you!
[16:17] <natefinch> cherylj: do you know who did the updates to juju status?  looks like it's fixed in current master, but the bug hasn't been updated: https://bugs.launchpad.net/juju-core/+bug/1571792
[16:17] <mup> Bug #1571792: Juju status should show controller and model names <juju-release-support> <rc1> <status> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571792>
[16:18] <cherylj> natefinch: that was thumper, I think
[16:21] <mup> Bug #1594875 opened: Please alias 'relate' to 'add-relation' <juju-core:New> <https://launchpad.net/bugs/1594875>
[16:28] <tvansteenburgh> wallyworld: you around?
[16:29] <tvansteenburgh> wallyworld: i'm working on getting jujuclient working with beta9. looks like top-level status keys were switched to lowercase, is that right? is it only the top level keys?
[16:35] <tvansteenburgh> anyone else know? ^
[16:40] <tvansteenburgh> nevermind, i think i found the answer
[16:55] <mup> Bug #1594883 opened: initial juju status is really ugly <status> <juju-core:New> <https://launchpad.net/bugs/1594883>
[17:04] <alexisb> tvansteenburgh, you should have a mail in your inbox that provides some input, thumper can provider more backgroun to qs when he comes online
[17:05] <alexisb> natefinch, thank you for  you input on lp 1594883
[17:09] <tvansteenburgh> alexisb: thanks
[17:21] <rogpeppe1> here's a fun review if anyone wants to take a look: https://github.com/juju/juju/pull/5684
[17:22] <rogpeppe1> it adds redirect support when making API connections
[17:36] <perrito666> Rogpeppe1 I'll review after lunch
[17:43] <alexisb> rogpeppe1, for your PR, did you work with anyone on the techboard, or someone else on the core team?
[17:55] <mup> Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
[18:01] <mup> Bug #1594924 changed: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
[18:07] <mup> Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
[18:11] <ejat> axw: r u there
[18:26] <perrito666> bbl
[18:51] <Yash1> katco: Hey :)
[18:51] <katco> Yash1: o/
[19:37]  * redir steps out for some air. bbiab.
[20:10] <aisrael> sinzui: Do you know if it's possible for the juju devel ppa to keep copies of previous beta versions? In this case, I need to rollback to beta 8 in order to run bundletester, but I autoremove'd my apt cache after upgrading to beta 9.
[20:14] <sinzui> aisrael: debian/ubuntu does not permited
[20:15] <sinzui> aisrael: users can copy packages to less volitile ppas
[20:16] <sinzui> aisrael: for CI, we keep a copy of all the clients we release so we can do compatability testing
[20:16] <natefinch> aisrael: you can always just copy the binaries to a new folder. put them in a beta8 directory or something
[20:17] <aisrael> sinzui: natefinch: is there a way I can get a copy of the beta8 release then?
[20:17] <aisrael> I'll start backing them up from now on. :)
[20:20] <natefinch> sinzui: do we store the linux binaries somewhere?  I see centos and osx and windows on launchpad, but not linux
[20:20] <natefinch> er not ubuntu
[20:21] <sinzui> aisrael Lp has a record of most of what it historically built. I think this helps https://launchpad.net/~juju/+archive/ubuntu/devel/+packages?field.name_filter=juju-core&field.status_filter=superseded&field.series_filter=
[20:21] <sinzui> natefinch: QA team stores all clients we release to do client compatability testing.
[20:21] <aisrael> sinzui: That's perfect, thanks!
[20:22] <mup> Bug #1594958 opened: Bootstrapping on OpenStack fails with juju 2 <juju-core:New> <https://launchpad.net/bugs/1594958>
[20:25] <natefinch> it's kind of amusing that we have different builds for different ubuntu series.. as if they're actually any different.  If the go tool did it right, they'd probably be bit for bit identical/
[20:28] <perrito666> its the debian way, which is in the exact oposite of static binary compilations
[20:28] <natefinch> hell, the CentOS one I'm sure is also identical.  It runs just fine on my machine.  Go doesn't care what flavor of linux you're compiling on
[20:47] <perrito666> mm, what is the API call to delete a model
[20:53] <natefinch> hmm... kill-controller is kind of a confusing command when you're in HA
[20:54] <natefinch> I guess if you think of it like the cluster is the controller, not each machine is a controller
[20:54] <natefinch> sigh... naming is hard
[21:05] <wallyworld> katco: ericsnow: quick catch up?
[21:06] <wallyworld> https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
[21:06] <katco> wallyworld: brt
[21:32] <thumper> anyone want this? http://reviews.vapour.ws/r/5129/diff/#
[21:33] <perrito666> thumper: rb just display errors
[21:33] <thumper> because it doesn't show deletions well
[21:33] <thumper> summary says deleted
[21:33] <perrito666> yes github says so too :-
[21:33] <perrito666> :p
[21:33] <perrito666> ship it
[21:52] <mup> Bug #1594977 opened: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
[22:01] <mup> Bug #1594977 changed: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
[22:13] <bdx> hey whats up guys? - Quick question, will there be a 'destroy-machine' command in the future?
[22:13] <mup> Bug #1594977 opened: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
[22:15] <bdx> On that, would it be wise, or confusing to refactor references to "DestroyMachine" or "DestroyedMachines" or whatever variation of 'destroy machine' to a similar variation of 'remove machine'?
[22:18] <thumper> bdx: there will be a command that removes a machine
[22:19] <bdx> thumper: you mean "destroys"
[22:19] <thumper> I think we called it 'remove-machine'
[22:19] <thumper> destroy was always an alias
[22:19] <thumper> we went for naming consistency
[22:19] <bdx> I see, yea
[22:20] <bdx> so should references in the code base like "DestroyMachine" be refactored to "RemoveMachine" ?
[22:21] <bdx> 'destroying' machine operations are carried out by the code, but 'destroying' a machine is not a user facing command?
[22:25] <bdx> thumper: what I'm getting at is the inconsistency between destroy-machine ops in the codebase, and the fact that destroying a machine isn't really an operation that can be performed
[22:26] <bdx> thumper: should "destroy-machine" references in the codebase be refactored to "remove-machine", also the naming of the functions and classes that reference "destroying" a machine ...?
[22:27] <thumper> not entirely sure right now, my head is elsewhere
[22:36] <cherylj> menn0: thank you for the review! :)
[22:36] <menn0> cherylj: No problems.


[08:59] <CIA-16> debian-installer: cjwatson * r1581 ubuntu/ (build/config/armhf.cfg debian/changelog debian/control): Enable armhf/omap4.
[09:02] <CIA-16> debian-installer: cjwatson * r1582 ubuntu/debian/changelog: releasing version 20101020ubuntu84
[15:41] <CIA-16> ubiquity: cjwatson * r5101 trunk/ (d-i/manifest debian/changelog):
[15:41] <CIA-16> ubiquity: Automatic update of included source packages: flash-kernel 2.28ubuntu35,
[15:41] <CIA-16> ubiquity: hw-detect 1.88ubuntu1, localechooser 2.39ubuntu1, partman-uboot 5.
[15:48] <CIA-16> ubiquity: cjwatson * r5102 trunk/ (6 files in 3 dirs): Add armhf support.
[16:22] <CIA-16> ubiquity: cjwatson * r5103 trunk/ (4 files in 3 dirs):
[16:22] <CIA-16> ubiquity: Set DPKG_UNTRANSLATED_MESSAGES=1 when installing packages so that bug
[16:22] <CIA-16> ubiquity: reports are easier to analyse; requested by Brian Murray.
[16:26] <CIA-16> ubiquity: cjwatson * r5104 trunk/debian/changelog: releasing version 2.9.6
[17:57] <CIA-16> partman-auto: cjwatson * r616 ubuntu/ (2 files in 2 dirs):
[17:57] <CIA-16> partman-auto: Don't offer resize_use_free autopartitioning method on armhf (already
[17:57] <CIA-16> partman-auto: excluded on armel).
[17:59] <CIA-16> ubiquity: cjwatson * r5105 trunk/ (4 files in 2 dirs): Add a few armhf -> armel symlinks to fix the armhf build.
[17:59] <CIA-16> partman-auto: cjwatson * r617 ubuntu/debian/changelog: releasing version 93ubuntu17
[18:09] <CIA-16> ubiquity: cjwatson * r5106 trunk/ (d-i/manifest debian/changelog): Automatic update of included source packages: partman-auto 93ubuntu17.
[18:16] <CIA-16> ubiquity: cjwatson * r5107 trunk/ubiquity/plugins/ubi-partman.py: typo
[18:53] <kyleN> ev, hi. I'd like to use oem-config  in an arm chroot with proper preseeding to create the user and the other basics that oem-config normally does. is this possible? oem-config-debconf?
[18:54] <kyleN> that chroot becomes a rootfs tarball that can be combined with kernel and other bits with linaro tools create a working system
[20:07] <infinity> cjwatson: Argh.  d-i thinks it knows better than udebs, and just flattens things to /lib? :/
[20:08] <cjwatson> haha
[20:08] <cjwatson> library reduction fun
[20:08] <cjwatson> maybe just make a special exception; that code is no fun
[20:09] <infinity> Well, the added irony in this case is the line a bit further up where it knows that the PI is "/lib/arm-linux-gnueabihf/ld-linux.so.3" and then it decides it doesn't need it. :P
[20:09] <infinity> (Given the above, you may be able to generalise it, rather than make an exception... ie: if it's looking up the PI location anyway, ensure that we keep it?)
[20:10] <infinity> And by "you", I might mean "I".
[20:10] <infinity> But someone. :P
[20:11] <cjwatson> Feel free - I'm pretty much out 'til Monday
[20:11] <infinity> Mmkay.
[20:11] <infinity> Is that bit in d-i itself, or one of the many subpackages?
[20:11]  * infinity doesn't feel particularly like hunting, if you happen to know.
[20:13] <cjwatson> probably debian-installer/build/Makefile
[20:13] <cjwatson> or if you're unlucky it's in mklibs
[20:13] <infinity> Mmkay.
[20:13] <cjwatson> one of the two anyway
[20:28] <infinity> And the fun continues:
[20:28] <infinity> 13:20 < GrueMaster> grmbl.  "Loading libc6-udeb failed for unknown reasons. Aborting."
[20:29] <cjwatson> Crappy error, but there should be something in syslog
[20:30] <cjwatson> It means udpkg exited non-zero
[20:30] <GrueMaster> yea, uh.  No syslog accessible without libc6.  No shell, no saving logs.
[20:31] <infinity> Installing to an SD that you can pull and put in another machine?
[20:31] <cjwatson> no virtual terminals?
[20:32] <GrueMaster> cjwatson: headless for one.
[20:33] <cjwatson> Can you run armhf in qemu?  It might be quickere.
[20:33] <cjwatson> *quicker
[20:33] <cjwatson> Given that this failure has got to be pretty early.
[20:33] <GrueMaster> This is right after loading the preseed.  Way before install starts.
[20:33] <infinity> I see no reason why not.
[20:35] <GrueMaster> I am not setup for qemu.  And I don't want to take the time to learn it now.  I have way too much on my plate.  I'll try on a system that has monitor/keyboard.
[20:35] <cjwatson> I'm not necessarily saying *you* have to ...
[20:36] <cjwatson> (Sorry, I did say "you", but I meant "one".)
[20:36] <cjwatson> That said I should go be sociable ...
[20:41] <GrueMaster> yea, that didn't work.  'can't run "-/bin/sh":  Permission denied".


[09:10] <smjms> does anyone know why ttfautohint makes the fonts look so good on Windows/DirectWrite, even though it's based on FreeType's auto-hinter and FreeType autohinting on Linux doesn't look as crisp and clear as on Windows?


[16:01] <devicenull> hey where can I find a changelog for the installer update for precise-updates that was pushed on the 23rd?
[16:01] <devicenull> I think it's causing some problems with our network installs
[16:01] <devicenull> ah
[16:01] <devicenull> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu136.14
[16:02] <devicenull> so, it seems that with this kernel version bump, I'm no longer able to install cleanly.  I get an error 'No kernel modules were found'..
[16:07] <devicenull> in syslog, I see 'no packages matching running kernel 3.2.0-58-generic in archive'
[16:22] <devicenull> opened https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1264333
[16:22] <ubot2`> Launchpad bug 1264333 in debian-installer (Ubuntu) "Cannot install with 20101020ubuntu136.14 installer update " [Undecided,New]
[16:22] <devicenull> this definitely looks like a problem with that update (I can't see how installs would ever work when it's looking for a kernel verison that doesn't exist in precise-updates)
[17:32] <infinity> Gah, who released that d-i to updates?
[17:33] <infinity> cjwatson: Generally not clever to release d-i before the kernels...
[17:35] <infinity> Maybe I can just flip the current/ symlink and pretend like nothing happened...
[19:47] <cjwatson> infinity: bah, I did think I'd checked but I always forget that kernels don't show up normally in pending-sru
[19:48] <cjwatson> Yeah, flipping the symlink should work


[01:24] <james_w> have there been discussions that anyone is aware of about changing UDS scheduling again this time?
[01:25] <james_w> we're currently discussing some changes to the way we do our planning in Linaro, and if there are going to be changes for UDS I would like to factor them in now
[06:54] <AlanBell> james_w: what sort of changes?
[07:08] <jono> has anyone heard from peria?
[07:08] <jono> persia?
[07:08] <nigelb> no :(
[07:08] <nigelb> Anyone canonical has his phone number?
[07:09] <jono> he is safe
[07:10] <nigelb> yay!
[07:14] <jono> who is else is based in Japan?/join #ubuntu-jp
[07:14] <jono> oops
[08:07] <dholbach> good morning
[08:09] <dpm> good morning all
[08:09] <dpm> morgen dholbach
[08:09] <dholbach> hey dpm
[08:10] <jono> ok, I posted on my blog about what to do with the Tsunami, arrival times, put it on planet Ubuntu and GNOME and posted to all Ubuntu FB groups
[08:10] <jono> and tweeted
[08:10] <jono> if it help save one life, this is worth it
[08:10] <jono> headed to bed, night all!
[08:11] <kim0> Morning
[08:11] <jono> if you folks can check in our with community members in Japan and the affected areas, I would appreciaste it
[08:11] <jono> night all!
[08:16] <nigelb> morning dpm, dholbach, kim0 :)
[08:16] <kim0> morning everyone o/
[08:16] <kim0> was catching up on this tsunami thing
[08:18] <dholbach> hi nigelb
[09:01] <czajkowski> Aloha
[11:34] <czajkowski> anyone heard from folks in the locos/boards that are being effected over in Japan
[11:34] <nigelb> jono said peria was okay.
[11:34] <nigelb> *persia
[11:34] <nigelb> I suppose he called.
[12:13] <duanedesign> morning friends
[12:14] <Pendulum> hi duanedesign
[12:16] <kim0> morning duanedesign
[12:17] <nigelb> morning duanedesign, Pendulum :)
[12:18] <duanedesign> heyo
[12:18] <duanedesign> Pendulum: have a second?
[12:18] <Pendulum> yep
[13:21] <james_w> AlanBell, e.g. the way blueprints have to be named to get scheduled
[13:21] <james_w> we changed from tracks to themes last time
[14:28] <vish> huh! we have a http://piratepad.net/
[14:41] <popey> been around a while, that one
[14:52] <jono> hey all
[14:53] <dholbach> hey jono
[14:55] <jono> hey dholbach
[15:44] <czajkowski> jono: ello
[15:45] <jono> hey czajkowski
[15:45] <czajkowski> jono: you free ?
[15:46] <jono> czajkowski, now?
[15:46] <jono> I am for a few mins, don't have too long though
[15:46] <czajkowski> well in the next hour
[15:46] <czajkowski> could give you a ring as we missed our call the other evening
[15:47] <jono> czajkowski, give me a few mins to respond to a bug and then I will ping you
[15:47] <czajkowski> jono: grand job
[15:51] <jcastro> jono: are you going to be affected by the tsunami or are you inland?
[15:51] <jono> jcastro, I *think* we are OK
[15:51] <jono> I think if anyone gets hit it will be SF and Oakland
[15:52] <jono> but the reports are that it is not going to be a huge problem here, with limited evacuations
[15:52] <jcastro> oh that's right, you moved
[15:52] <jono> I think we should be fine
[15:52] <jono> I think our old place would have been fine too
[16:17] <jono> czajkowski, sorry, I am not going to be able to chat
[16:17] <jono> I have to get on a call
[16:17] <jono> apologies
[16:17] <czajkowski> jono: no worries shall poke you monday
[16:17] <czajkowski> jono: tis grand really
[16:17] <jono> thanks!
[16:17] <czajkowski> np
[16:22] <duanedesign> nigelb: made a little progress on the Parental Control wiki page https://wiki.ubuntu.com/duanedesign/sandbox
[16:37] <jcastro> jono: JohnLea needs to chat with you asap
[16:37] <jono> jcastro, call is now
[16:37] <jono> jcastro, on a call now, will ping later
[16:46] <Technoviking> jcastro: ping
[16:46] <jcastro> Technoviking: on a call, but I'm in and out
[16:47] <Technoviking> jcastro: If you have some common asked questions about Unity, I would love to put them in my next Ubuntu User Q7A article
[16:48] <dpm> have a great weekend all!
[17:15] <dholbach> ok my friends
[17:15] <dholbach> I call it a day
[17:16] <dholbach> have a great weekend everyone
[17:16] <dholbach> big hugs to you all
[17:16] <cjohnston> bye dholbach
[17:36] <JFo> hggdh, tell me to shut up in there if I am in the way :)
[17:38] <hggdh> JFo, you are never in the way (figurativelly speaking, of course)
[17:38] <hggdh> :-)
[17:38] <JFo> heh
[17:39] <hggdh> but I *have* been blocked from the barman before by you, and it was a major block
[17:39] <JFo> I apologize for such things :-)
[17:39] <JFo> I would never get between a man and his beverage on purpose ;)
[17:40] <JFo> man or woman that is
[17:40] <JFo> but I do make a good roadblock
[18:41] <jcastro> well, not roadblock JFo
[18:41] <jcastro> more like a plow
[18:41] <jcastro> when he zombie apocalypse comes I'm going to strap you on the front of my truck with a chainsaw.
[18:41] <JFo> lol
[18:42] <JFo> just one? I'd like at least 2 ;)
[19:01] <jcastro> JFo: you've seen zombieland right?
[19:01] <jcastro> you're like woody harrelson in that movie
[19:34] <JFo> jcastro, :)
[19:34] <JFo> sorry was OTP
[21:16] <komputes> jcastro: http://uds.ubuntu.com/participate/sponsorship/
[21:16] <komputes> jcastro: bottom says <!---
[21:16] <komputes> The deadline for sponsorship closes on 8th September 2010.
[21:16] <komputes> —>
[21:16] <komputes> jcastro: also will there be a way for us to check the sponsored folks and vote this time around?
[21:21] <AlanBell> vote on what?
[21:29] <czajkowski> komputes: vote for people to get sponsored?
[21:34] <AlanBell> komputes:so you found an old date *inside an HTML comment block*
[21:34] <komputes> czajkowski: yep
[21:34] <AlanBell> I don't think many people will be viewing the source and getting confused by that
[21:34] <komputes> AlanBell: the comment block is displayed on the page, it shouldn't be
[21:35] <AlanBell> in what browser?
[21:35] <komputes> AlanBell: if it was just in the source then it'd be ok. FF on Lucid
[21:35] <komputes> AlanBell: might be cuz its wiki
[21:35] <pleia2> yeah, I see it too
[21:36] <AlanBell> hmm, so do I, but not in chromium
<!---<br />  doesn't get parsed correctly as a start comment in firefox
[21:37] <AlanBell> it isn't wiki, it is wordpress, the HTML looks right in the chromium source browser
[21:38] <AlanBell> that is worth fixing
[21:38] <AlanBell> there will be no vote on people getting sponsorship, that is a decision made inside Canonical about who they want to spend their money on bringing to UDS
[21:39] <popey> komputes: community members dont vote on UDS attendance
[21:40] <AlanBell> everyone is free to attend
[22:51] <doctormo> AlanBell: especially if they pay themselves ;-)


[09:48] <JamesTait> Good morning all; happy Curmudgeons Day! :-D
[10:56] <Spads> JamesTait: Pah.  Happy?
[10:57] <JamesTait> I'm only happy when I'm grumpy. ;)
[10:59] <JamesTait> Bah! And now it's snowing!
[11:31] <davmor2> surely you are grumpy when you are grumpy :P
[11:31] <davmor2> happy is an other dwarf altogether


[04:51] <blahdeblah> head_victim: If you're willing to get up early, i can pick you up on the way to LCA - i'll probably be starting before 8 most days.
[04:53] <head_victim> blahdeblah: yeah I was thinking of heading in to arrive 0800 - 0815 to make sure I get a park.
[04:53] <head_victim> I'm one of these people that feel lost without a mode of transport that doesn't rely on others :/
[04:53] <head_victim> blahdeblah: you be up for the pancake manor?
[04:54] <blahdeblah> head_victim: I just saw on the mailing list you were thinking of public transport, and my route into town isn't too far from your place.
[04:54] <blahdeblah> When is the pancake manor?
[04:54] <head_victim> Monday night.
[04:54] <head_victim> I thought I spammed the list enough, apparently not ;)
[04:54] <blahdeblah> head_victim: Probably my memory, not your spamming talent
[04:54] <head_victim> Website event help?
[04:55] <head_victim> Or have I broken that enough for one week
[04:55] <blahdeblah> If it's happening, put it up there, i say.
[04:55] <head_victim> http://www.pancakemanor.com.au/ for where and what
[04:55] <blahdeblah> Far out my web browsing is laggy at the moment.
[04:56] <blahdeblah> Took me 10 secs just to bring up the Ubuntu-AU home page
[04:56] <head_victim> I was thinking of sending it to the lca-chat list but don't know enough about lca to know if it's a good idea
[04:56]  * head_victim lends you some bandwidth
[04:56] <blahdeblah> I wish
[04:57] <blahdeblah> We just upgraded to 100 Mbps fibre at one of my clients - wish i could steal some of that for home.
Oh well, the NBN is going to solve all that...</sarcasm>
[04:57] <head_victim> Hah well I have heaps of team business cards to distribute as well so I thought that would be a good place to give them to people to let people know we exist (I've found lots of people use Ubuntu but have no idea the loco even exists)
[04:57] <head_victim> blahdeblah: oh so when you get the nbn connection in 2020 you'll be right?
[04:57] <blahdeblah> yep ;-)
[05:02] <head_victim> I'll ping you when it's done, as much as I can probably publish it myself now I think it's always good practice to have someone else's eyes double check
[05:15] <head_victim> blahdeblah: if you can have a quick look and make sure it's not too dry (I *think* I got my links right) I would greatly appreciate it
[05:43] <head_victim> blahdeblah: might take you up on that travelling together idea as well. Depends on if what you're doing afterwards I might have to take myself in on Monday to pick up the wife for the Pancake Manor
[05:46] <blahdeblah> head_victim: Looks pretty good.  Suggested changes: make sure there's no space before your </a> closing tags - it makes the links look a bit daggy when you hover on them.
[05:46] <blahdeblah> Also, i would probably take out the bit "For those of you living under a rock for the last 12 months you might not know that" - it doesn't have a very newbie-friendly sound.
[05:47] <blahdeblah> And drop-ins is hyphenated.
[05:48] <head_victim> Yeah actually that whole paragraph fails
[05:49] <head_victim> I just rejigged it a bit
[06:37] <blahdeblah> head_victim: Another tip: get rid of the line breaks - only put a line break between paragraphs.
[06:37] <head_victim> I thought that's what I did?
[06:38] <blahdeblah> Well, there are lots there now.
[06:38] <blahdeblah> Are you using a visual editor, or just plain text?
[06:38] <blahdeblah> Doesn't look like a visual one is available
[06:39] <blahdeblah> Sorry - i was looking at the unpublished LCA open day notice.
[06:39] <blahdeblah> I might delete that one now.
[06:39] <blahdeblah> head_victim: Your current page is fine
[06:39] <head_victim> Ahh yeah I just looked at the one you spoke of. That was a copy and paste job that I then went on and edited
[06:40] <blahdeblah> yep
[06:40] <blahdeblah> I'll get rid of it
[06:40] <blahdeblah> elky: Deleting your unpublished node from last August, too... ;-)
[06:41] <blahdeblah> head_victim, elky: Do you know of any stock of Ubuntu T-shirts in Australia?
[06:42] <head_victim> I only have the old design, 1 tshirt and 1 polo
[06:42] <blahdeblah> bradm: Any idea how we can stick a rocket up the folks at the shop to work out why they won't respond to my queries?
[06:42] <head_victim> It was a bit of a bummer that branding change
[06:42] <blahdeblah> head_victim: Which was the old design?
[06:42] <head_victim> The old ubuntu brand, the rounded one
[06:43]  * blahdeblah can't remember it
[06:43] <blahdeblah> Whatever it is, if it doesn't have that stupid new default font they put in with Maverick, i like it! :-)
[06:43]  * blahdeblah despises the font "Ubuntu"
[06:44] <head_victim> http://www.flickr.com/photos/45015261@N04/4283714935/in/set-72157623233310760/
[06:44] <head_victim> I was going to wear one on the open day and take another one along for someone else.
[06:45] <elky> blahdeblah, no.
[06:45] <blahdeblah> elky: No probs - thanks
[06:46] <blahdeblah> head_victim: Is there a public version of that flickr photo?  Yahoo's login process is being recalcitrant
[06:46] <head_victim> Oh that's not public
[06:46] <head_victim> Thought it was
[06:46] <blahdeblah> Well, it's asking me for a login
[06:47] <head_victim> Try again sorry
[06:47] <head_victim> Just updated it
[06:47] <head_victim> The left is the polo and the right is the tshirt. The middle is a jumper but I don't think anyone will be willing to wear that in Brisbane anytime soon.
[06:47] <blahdeblah> certainly not me! ;-)
[07:02] <bradm> blahdeblah: um, I'll see if I can find out, not sure off hand
[13:21] <DKG779> hey all
[13:21] <blahdeblah> yo
[13:29] <head_victim> Evening DKG779
[13:37] <DKG779> hi head_victim, how are ya ?
[13:38] <head_victim> Not too bad, yourself?
[13:38] <head_victim> I'm spending the night working out what DDR ram I have actually works (power surge here killed a ram slot on a MB i *think*)
[13:39] <DKG779> ouch head_victim, you don't run a ups ?
[13:39] <DKG779> yeah I have been better mate, dry rot, termites, rusted gutters
[13:40] <DKG779> ses out to tarp part of the roof
[13:40] <DKG779> last week and a bit has been chaos
[13:41] <head_victim> Supposed surge protection, can't afford to run a UPS because when I start running a ups on one pc then there's 5 pcs, 2 modems, 2 switchs and a router that all want a UPS as well
[13:43] <DKG779> supposed surge protection ?
[13:43] <head_victim> Can't be that good if I've dropped a ram slot
[13:44] <DKG779> hell no, what is your surge protection at the meter board or just power board ?
[13:45] <head_victim> Normal safety switch stuff at the meter board but power board as well
[13:45] <DKG779> safety switch is just earth leakage ?
[13:46] <head_victim> Yeah and elcbs
[13:46] <blahdeblah> head_victim: Sounds like a couple of mid-sized UPSes would be cheaper than working out problems like those...
[13:47] <head_victim> blahdeblah: you'd think so but the initial outlay is the killer
[13:47] <blahdeblah> true
[13:47] <head_victim> blahdeblah: you've seen my place :/ I'd need one in the desktop rack and then another in the other rack.
[13:48] <blahdeblah> yep
[13:48] <blahdeblah> I have 3 UPSes - mostly 400 VA or smaller
[13:48] <DKG779> I have a ups on my file server, the rest well... one day
[13:49] <head_victim> My newer stuff doesn't really have much of a drama it's just the stuff that's P4s and earlier is getting a bit long in the tooth.
[13:49] <head_victim> Starting to run out of MBs mainly.
[13:50]  * blahdeblah has a box full of P4 mobos sitting on the shelf - want some?
[13:50] <blahdeblah> and a bunch of DDR ECC RAM that i can't use
[13:50] <head_victim> blahdeblah: oh yes please. I hate to be picky but anything with sata would be great. I don't mind agp or pcie.
[13:51] <blahdeblah> I don't think they have SATA or AGP/PCIe, but i'll check
[13:51] <head_victim> That will mean I can get 2 pcs back up and running, one for the wife's sewing room and my other one.
[13:51] <head_victim> No agp? Onboard video?
[14:09] <blahdeblah> head_victim: Yeah, i think so
[14:10] <head_victim> Ah ok. I'm still arguing with the one I thought only had a broken ram slot
[14:10] <blahdeblah> I'll check them out and let you know on Monday
[14:11] <head_victim> blahdeblah: appreciate it mate.