[00:00] <_stink_> JustOkSoup
[00:06] <cmaloney> MediocreSoup++
[00:49] <shakes808> alright, so here is what i have, but the image part isn't working correctly.  I see the files but can't open them :|
[00:49] <shakes808> https://pastebin.com/r5Ht0J8q
[00:52] <shakes808> the split stopped working, went back to the " ... + 4"
[00:52] <shakes808> don't know why it worked one time and then stopped later
[00:56] <shakes808> what am i doing wrong with saving the images?
[00:58] <cmaloney> Which site are you crawling?
[00:59] <shakes808> spider("http://www.smashbros.com/us/", "characters/", 1)
[00:59] <shakes808> there is the command line call
[01:00] <cmaloney> So you're trying to get all of the character images?
[01:00] <shakes808> correct
[01:01] <cmaloney> What I'd try
[01:01] <cmaloney> #1: split on /
[01:01] <cmaloney> and get the pages that way
[01:02] <cmaloney> so you'd have site, country, characters, character_name
[01:09] <shakes808> so do a split on item like this -> (h, b, baseURL, country, characters, character_name  = item.split("/")
[01:13] <cmaloney> Yeah
[01:19] <jrwren> is there a reason you cannot simply use wget?
[01:20] <shakes808> ??? Just found the script and started modifying it.
[01:32] <shakes808> jrwren: I just tried using wget and the same outcome, creates the files on my local but can't open them ->   os.system("wget -c " + fullURL + " -O " + savedPicture)
[01:33] <shakes808> be back online in 20ish
[02:13] <shakes808> bak
[02:13] <shakes808> back*
[02:26] <shakes808> i think i found one of my issues.  i had the final url incorrect.  but i have some things to hammer out.  might have to find another way to get the url so i can get the correct png.  I found that bowser's image is called koopa
[02:40] <cmaloney> nice
[02:40] <cmaloney> welcome to Nintendo. ;)
[02:41] <shakes808> mega-man is named rockman :|  wth haha
[02:41] <cmaloney> That's what he's called in Japan
[02:41] <shakes808> oh really?
[02:42] <shakes808> didn't know that
[02:43] <shakes808> so now i figure out how to get the images from the site
[02:46] <cmaloney> schweet.
[12:46] <cmaloney> Good morning
[12:53] <rick_h> morning
[12:53] <Zimdale> Morning
[12:58] <_stink_> yes
[12:59] <jrwren> good morning
[13:08] <cmaloney> How goes?
[13:09] <brousch__> Too busy
[13:09] <brousch__> I'm giving a talk Monday and have no time this weekend to prepare
[13:10] <_stink_> wing it?
[13:10] <rick_h> steal cmaloney's talk
[13:11] <jrwren> you'll find time.
[13:18] <cmaloney> Yeah, it only has a few flaws in it. :)
[13:19] <brousch__> Well mine is supposed to be about SaltStack
[13:24] <shakes808> morning
[13:28] <cmaloney> brousch__: I have one about Ansible that you can steal. :)
[13:33] <brousch__> Yeah, one problem I have is there's not a lot of interest in Salt. People on complex systems are using Chef/Puppet, and smaller systems are using Ansible
[13:34] <brousch__> When I asked for requests about specific Salt use cases, it was stuff more suited to Ansible
[13:39]  * shakes808 naive to such things
[13:39] <shakes808> what is Salt / Ansible / Chef / Puppet?   Automation for DevOPs?
[13:39] <cmaloney> shakes808: It's system configuration / management
[13:40] <cmaloney> eg: instead of logging into a machine, ensuring there's a directory present, and doing git clone repo:foo tag/bar you can instead run a playbook that will do that
[13:40] <cmaloney> (and any other steps needed to make that work)
[13:41] <cmaloney> (eg: ensure that build-essential is installed, that you have Python3, etc.)
[13:41] <jrwren> https://saltstack.com "Intelligent orchestration for the software-defined data center"
[13:41] <cmaloney> Puppet does the same thing (in a sense) but it has clients that ping a server to see what all needs doing
[13:41] <jrwren> why would you ever want build-essential installed on a production server?  duh, i guess if it is your build server :)
[13:41] <cmaloney> (unsure about Chef, and Salt Stack)
[13:42] <cmaloney> jrwren: Don't ask.
[13:42] <cmaloney> we built our own Python on our prod servers
[13:42] <brousch__> Salt has a "master" that can control the "minions"
[13:42] <cmaloney> Salt has possibly the worst terminology out of them
[13:42] <cmaloney> "pillars"
[13:43] <brousch__> Or multiple masters and mid-level managers (syndics) in cases like ours
[13:43] <jrwren> cmaloney: you are doing it wrong.
[13:43] <brousch__> Pillar is used for system-specific variables, but we only use it for encrypted data here
[13:43] <jrwren> :p
[13:43] <cmaloney> jrwren: I no longer work there, so don't care. :)
[13:44] <rick_h> get ahead of the curve: https://github.com/purpleidea/mgmt
[13:44] <rick_h> that had a lot of attention at cgfmgmtcamp in ghent this year
[13:44] <brousch__> rick_h: We already have cfengine, chef, and Salt in production
[13:44] <rick_h> jrwren: :) always comes down to the build artifact on all of these doesn't it.
[13:45] <jrwren> cmaloney: its ok. I do it wrong every day. "we have to"
[13:45] <rick_h> brousch__: right, time for another one!
[13:45] <jrwren> rick_h: yup.
[13:45] <brousch__> And sendconf
[13:45] <cmaloney> jrwren: Had I had my druthers I would have made RPM packages that we would install
[13:45] <cmaloney> or containers that we would deploy to.
[13:45] <jrwren> cmaloney: exactly!
[13:45] <cmaloney> but they were also CentOS6 machines so lord knows what we would have blown up
[13:45] <cmaloney> (again, not my decision to deploy to CentOS)
[13:46] <cmaloney> so a /usr/local/bin/python pre-built on the target machine was the least of my problems.
[13:46] <brousch__> rick_h: Not "had" in production, "have" in production. It's kind of a mess
[13:47] <jrwren> cmaloney: IME (10+yrs ago) building rpms is a bit easier than building debs and it all just works once you get it. I'm sure you'd have been fine.
[13:47] <shakes808> cmaloney - what is wrong with CentOS?  The company that I am working for is looking to switch over to that from Debian because of compatibility issues with another service.
[13:47] <rick_h> shakes808: :/
[13:47] <rick_h> shakes808: what service?
[13:47] <cmaloney> Oracle
[13:48] <rick_h> lol
[13:48] <cmaloney> shakes808: CentOS is not bad, but it tends to be crufty
[13:49] <cmaloney> The version we had didn't get Python 2.7 until it was pailfully out of date to ship 2.6
[13:53] <shakes808> we are switching our virtual hosts or something.  From Xen to something else.  And their conversions from Xen include - Red Hat, Cent, Ubuntu, and some other one but not Debian.   We don't understand how they support Ubuntu but not Debian ( to my knowledge Ubuntu is based off of Debian, correct? )
[13:54] <jrwren> oh yes, that is why py26 had support for so long.
[13:54] <jrwren> ubuntu has their own kernel, different from debian kernel
[13:54] <cmaloney> xen to kvm lijely
[13:55] <cmaloney> xen has a lot of security issues
[13:55] <jrwren> how did you manage the li in likely, but not the j?
[13:55] <cmaloney> linode is migrating customers off of xen
[13:55] <jrwren> and yet... EC2.
[13:55] <cmaloney> phone keyboadd
[13:55] <jrwren> Xen is GPL, right? oh, but is it not AGPL so AWS can keep theri mods for EC2 only?
[13:56] <cmaloney> possibly? nfc
[13:58] <cmaloney> could also be that kvm is best suited for linux only vs multiple os
[13:58] <cmaloney> haven't peeked thst hsrd ibto ut
[13:58] <cmaloney> (i'm creating my own language)
[14:00] <jrwren> definitely not.
[14:01] <cmaloney> which?
[14:01] <jrwren> Xen has 2 modes. HVM and whatever the default is.
[14:01] <jrwren> kvm/qemu is good at any OS, windows, et.
[14:01] <jrwren> but Xen has been around a little longer, it is possible that for windows the drivers function better.
[14:01] <jrwren> the virtio drivers for kvm/qemu can be a pain in windows.
[14:02] <cmaloney> ah
[14:04] <jrwren> remember last night... er afternoon with greg-g, we were talking about packaging extremists. The most recent debian-devel msg is on that subject and it points out that section 4.13 of debian policy says "SHOULD" not "MUST" :)
[14:09] <rick_h> you can't get 3 techies in a room to agree on "must" :P
[14:10] <jrwren> so true! that is why design by commitee fails. BDFL wins
[14:28] <brousch__> rick_h: Ah, crap mgmt is written in Go. Now our people will get excited about it
[14:29] <rick_h> brousch__: yea, it's fast, builds across platforms pretty well, etc
[14:29] <rick_h> brousch__: :P
[14:29] <jrwren> lol.
[14:30] <jrwren> too bad it can't benenfit from shared memory of shared libraries.
[14:34] <shakes808> we are moving from Xen to VMWare
[14:35] <shakes808> and they contacted their support and they flat out said they don't support that conversion
[14:36] <jrwren> lol, WHAT??
[14:38] <shakes808> yeah, that is what we don't understand either.
[14:39] <shakes808> how much different is Debian to Ubuntu that they would support the latter but not former?
[14:39] <shakes808> it is all rick_h fault ! HAHA
[14:42] <jrwren> oh, VERY .
[14:42] <jrwren> because the kernel is what matters when it comes to VM support.
[14:42] <cmaloney> Totally
[14:42] <jrwren> also, "support" is all about contracts.
[14:42] <jrwren> they don't support debian because there is no company behind it.
[14:42] <cmaloney> Ideally it shouldn't give two figs about what the kernel is that's running it
[14:42] <jrwren> they support ubuntu because canonical partners with them to support it.
[14:43] <jrwren> there is always 2 things.  1. what is supported.   2. what works.
[14:43] <jrwren> I'm always a little surprised when any company says they support centos, but centos is EXACTLY rhel with the name changed, so its a way of saying you support RHEL without partnering with RH, I guess?
[14:44] <cmaloney> Yeah, it's a lateral movel
[14:46] <jrwren> what kernel does debian even ship these days. isn't jessie 3.13 or some such?
[14:47] <jrwren> 3.16
[14:49] <rick_h> yea support means testing which means $$ which means trying to get partners to help subsidize it and it's hard to "partner with debian"
[14:49] <jrwren> so latest debian ships 3.16 kernel. that is VERY different than what Ubuntu does with HWE kernels: https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.A14.04.x_Ubuntu_Kernel_Support
[15:09] <shakes808> with that logic, Ubuntu 14.x has the same kernel as Debian then.  So in theory, it should be supported since they had the same kernel.  .... correct?!
[15:10] <jrwren> 14.04 did, but 14.04.[15] upgraded.
[15:10] <jrwren> and even then the kernel build options are different.
[15:10] <jrwren> and "supported" no.
[15:10] <jrwren> will it work, yes.
[15:10] <rick_h> "supported" as in it might work? Or "supported" as in "VMware will answer the phone"?
[15:11] <rick_h> two different things :)
[15:11] <shakes808> HAHA, awesome
[15:12] <cmaloney> Yeah, 14.04 has the Hardware Enablement Stack
[15:12] <cmaloney> so you can use the later video card drivers
[15:12]  * cmaloney has it on all of his machiens
[15:12] <cmaloney> machines
[15:13] <shakes808> i guess that kind of makes sense from their side though.  Canonical has people that can support it for sure as where Debian doesn't have that?   As for Debian, doesn't have anyone but the community behind it?
[15:13] <cmaloney> I <3 how my shit-ass AMD process from 2012 is dusting JoDee's recent laptop w/ an i5 chip
[15:13] <cmaloney> s/process/processor/
[15:13] <jrwren> debian is community effort. you could probably install the ubuntu kernel debs on debian and it would all be nice.
[15:13] <jrwren> but jessie isn't packaged that way out of the box.
[15:14] <cmaloney> "AMD FX(tm)-8350 Eight-Core Processor"
[15:14] <jrwren> cmaloney: REALLY!?!?!
[15:14] <jrwren> that is surprising.
[15:14] <cmaloney> "Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz"
[15:14] <cmaloney> It's a laptop though, so there might be some power-management shenannigans going on that I'm not aware of
[15:15] <jrwren> on what is it "dusting" it?
[15:17] <jrwren> support means you can call them adn they'll try to help you. That also means if they fix your problem  you may need to add their private support repo or maybe even a repo just for you with fixes just for you, because they haven't tested your fixes enough for a general release
[15:18] <cmaloney> jrwren: I'm running Python2 tests for Astropy
[15:18] <cmaloney> er, Python3
[15:18] <cmaloney> and my desktop machine completed them faster than JoDee's machine
[15:19] <jrwren> cool.
[15:20] <cmaloney> which is still processing those tests
[15:20] <jrwren> its that high clock rate.
[15:20] <jrwren> http://www.cpu-world.com/Compare/148/AMD_FX-Series_FX-8350_vs_Intel_Core_i5_Mobile_i5-6300HQ.html
[15:21] <cmaloney> Ah, it looks like it's underclocked
[15:22] <cmaloney> it also consumes an order of magintude more power
[15:22] <cmaloney> also likely doesn't help that she's now watching Big Bang Theory on the machine
[15:23] <cmaloney> (*sigh*)
[15:24] <jrwren> lol
[15:25] <jrwren> no, that won't help.
[15:28] <jrwren> still, I had no idea AMD processors could even keep up with intel, especially skylake
[15:44] <cmaloney> Trying to explain why anyone would want to use a virtualenv is fun
[15:45] <cmaloney> (for someone who isn't a developer)
[16:13] <gamerchick02> i'm doing my upgrade now. for some reason it didn't pop last night. oh well
[16:17] <jrwren> yacketty and z are the first time in yrs that I didn't upgrade. I'm still on xenial like a sucka.
[16:23] <brousch__> jrwren: That's one sign of old age - sitting on LTS
[16:23] <jrwren> lol.
[16:23] <jrwren> i really should upgrade eh?
[16:25] <cmaloney> So is it a sign of being elderly when you're still on 12.04 and 14.04?
[16:25] <cmaloney> Get me my walker and my whipping cane.
[16:25] <brousch__> Senility
[17:48]  * rick_h watches jedi teaser 5x and then tries to go back to work
[18:12]  * shakes808 agrees with rick_h
[20:02] <jrwren> i'm doing xenail->yackety
[20:02] <jrwren> it asks:
[20:02] <jrwren> 126 packages are going to be removed.
[20:02] <jrwren> Removing the packages can take several hours.
[20:02] <jrwren> how long do you think it will really take?
[20:02] <jrwren> I'm thinking 3 minutes.
[20:02] <cmaloney> I think it depends
[20:03] <jrwren> oh wow... it just plain failed the remove.
[20:03] <cmaloney> but yeah, several hours seems a bit much
[20:03] <jrwren> instantly moving to next step
[20:04] <cmaloney> x -> z?
[20:24] <jrwren> err, well, yes, once I clean up a bit.
[20:24] <jrwren> I like to audit installed pacakges and apt purge anything I no longer need eveyr time I upgrade.
[20:24] <jrwren> keeps pkg count down and makes for speedier upgrades
[20:27] <jrwren> apt autoremove was the same pkglist and it took less than 1m.
[20:27] <jrwren> that hours message must be hard coded from a long time ago with no attempt to estimate
[20:38] <cmaloney> Likel one of those "on a really slow computer this could take a long time" messages.
[20:39] <jrwren> no matter what, its a bug. its the wrong message.
[20:39] <jrwren> we can do better :)
[21:02] <cmaloney> Playing around with JavaScript, so decided to do my traditional "Hello World"
[21:02] <cmaloney> https://github.com/craigmaloney/js_shutbox
[22:07] <jrwren> that was a fun cleanup session... now y->z :)
[22:15] <jrwren> anyone know why my upgrade from yakkety to zesty says its removing strongswan? did ipsec move to different package or is it gone from ubuntu?
[22:17] <jrwren> http://packages.ubuntu.com/zesty/strongswan-charon is there. I guess it is OK
[22:29] <jrwren> Fetched 1,352 MB in 6s (2,309 kB/s)
[22:29] <jrwren> it was a lot longer than 6s.... more ubuntu bugs :)