[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.  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 :)


[00:18] <vorlon> sergiodj: fwiw telegraf appears to be built without pie enabled, according to lintian
[00:19] -queuebot:#ubuntu-release- New: accepted telegraf [amd64] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
[00:19] -queuebot:#ubuntu-release- New: accepted telegraf [armhf] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
[00:19] -queuebot:#ubuntu-release- New: accepted telegraf [s390x] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
[00:19] -queuebot:#ubuntu-release- New: accepted telegraf [arm64] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
[00:19] -queuebot:#ubuntu-release- New: accepted telegraf [ppc64el] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
[00:50] <sergiodj> vorlon: I will look into that, thanks for the heads up
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [amd64] (groovy-proposed) [2.3.6-0ubuntu1]
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [armhf] (groovy-proposed) [2.3.6-0ubuntu1]
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [riscv64] (groovy-proposed) [2.3.6-0ubuntu1]
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [arm64] (groovy-proposed) [2.3.6-0ubuntu1]
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [s390x] (groovy-proposed) [2.3.6-0ubuntu1]
[00:55] -queuebot:#ubuntu-release- New: accepted geonkick [ppc64el] (groovy-proposed) [2.3.6-0ubuntu1]
[01:24] -queuebot:#ubuntu-release- New binary: ruby-aws-sdk-cloudformation [amd64] (groovy-proposed/universe) [1.41.0-1] (no packageset)
[01:25] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [amd64] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[01:25] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [s390x] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[01:26] -queuebot:#ubuntu-release- New binary: ruby-aws-sdk-kms [amd64] (groovy-proposed/universe) [1.24.0-2] (no packageset)
[01:28] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [arm64] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[01:39] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [armhf] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [ppc64el] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[02:05] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [riscv64] (groovy-proposed/universe) [<IP_ADDRESS>-1] (no packageset)
[06:06] <LocutusOfBorg> vorlon, just for heads up, lzop has been added and removed to bootstrap lintian, the problem is that lzop is also a runtime dependency of lintian, so removing it is a sad story
[07:57] -queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu6.4 => 1:4.2-3ubuntu6.5] (ubuntu-server, virt)
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (focal-proposed) [1.2.2-2.1ubuntu2]
[09:04] -queuebot:#ubuntu-release- Unapproved: accepted alsa-ucm-conf [source] (focal-proposed) [1.2.2-1ubuntu0.2]
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu3.6]
[09:28] -queuebot:#ubuntu-release- Packageset: Removed commonmark-bkrs from i386-whitelist in groovy
[09:28] -queuebot:#ubuntu-release- Packageset: Added commonmark to i386-whitelist in groovy
[10:15] -queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu<IP_ADDRESS> => 1.4.1~ubuntu<IP_ADDRESS>] (core)
[10:15] -queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu<IP_ADDRESS> => 1.4.1] (core)
[10:15] -queuebot:#ubuntu-release- Unapproved: secureboot-db (focal-proposed/main) [1.5 => 1.6~20.04.1] (core)
[11:48] <Laney> restoring lzop for qtbase-opensource-src
[11:58] -queuebot:#ubuntu-release- Unapproved: fonts-noto (focal-proposed/main) [20200323-1 => 20200323-1build1~ubuntu20.04.1] (desktop-core, personal-gunnarhj, ubuntu-server)
[12:13] -queuebot:#ubuntu-release- Packageset: Added lzop to i386-whitelist in groovy
[12:19] -queuebot:#ubuntu-release- Unapproved: language-selector (focal-proposed/main) [0.204 => 0.204.1] (core, personal-gunnarhj)
[13:21] <ricotz> Laney, can you restore libtext-xslate-perl:i386 too?
[13:21] <ricotz> https://launchpad.net/ubuntu/+source/ffmpeg/7:4.3.1-2ubuntu1/+build/19846675
[13:35] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1094.104] (kernel)
[13:35] <rbasak> sil2100: o/ I'm just looking at the ceph and apport SRUs as these are half done from my shift yesterday
[13:36] <sil2100> rbasak: ok, thanks for the heads up o/ I'm doing kernel SRUs anyway right now
[13:42] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.17]
[13:48] -queuebot:#ubuntu-release- Unapproved: util-linux (focal-proposed/main) [2.34-0.1ubuntu9 => 2.34-0.1ubuntu9.1] (core, i386-whitelist)
[13:55] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.3-0ubuntu<IP_ADDRESS>]
[14:04] <Laney> ricotz: lemme see
[14:11] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1051.55~16.04.1] (kernel)
[14:13] <Laney> done
[14:13] <Laney> same one is required for qt too
[14:14] <Laney> I should check if there's any more, let me do that
[14:17] <Laney> hard to tell because of lintian
[14:17] <Laney> ubuntu-archive what do we normally do with perl deps like the one blocking lintian on excuses?
[14:17] <Laney> iirc there's some kind of lightweight procedure for that
[14:17] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu26.3]
[14:17] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu26.3]
[14:18] <seb128> Laney, that's a MIR team question, https://wiki.ubuntu.com/MainInclusionProcess has an exception section only for fonts
[14:19] <seb128> there is a note in the maintenance section but no special process afaik
[14:20] <seb128> afaik foundations owns to do the MIR work for lintian
[14:21] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1093.103~16.04.1] (kernel)
[14:22] <Laney> well if I can clear it out during +1 because there is in fact a procedure then it would be good to do that, hopefully there is and someone remembers / can document it
[14:22] <Laney> feel free to reply if you're on the MIR team and know something good re: that
[14:28] <xnox> I love this! "Rejected: Symbolic link for debian/copyright not allowed"
[14:28] -queuebot:#ubuntu-release- Packageset: Added libtext-xslate-perl to i386-whitelist in groovy
[14:43] <ricotz> Laney, thank you, seems ffmpeg needs a kick later
[14:46] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.9 => 0.7.5-1ubuntu16.10] (core)
[14:49] <Laney> ricotz: no, it will auto retry
[14:54] <ricotz> Laney, ah it did, and failed :\
[14:54] <Laney> bah, ok, now it really fails to build due to lintian
[14:56] <Laney> more bootstrapping required
[15:28] -queuebot:#ubuntu-release- Packageset: Added libdata-messagepack-perl to i386-whitelist in groovy
[15:28] -queuebot:#ubuntu-release- Packageset: Added libmouse-perl to i386-whitelist in groovy
[15:28] -queuebot:#ubuntu-release- Packageset: Added libproc-processtable-perl to i386-whitelist in groovy
[15:28] -queuebot:#ubuntu-release- Packageset: Added libtext-levenshteinxs-perl to i386-whitelist in groovy
[16:11] <Laney> ok lintian looks installable on i386 now
[16:11] <Laney> happy days
[16:17] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1094.104]
[16:18] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1093.103~16.04.1]
[16:18] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1051.55~16.04.1]
[16:31] <vorlon> wahoo
[16:44] <vorlon> wgrant, cjwatson: has there been a known regression in launchpad handling of multiarch-annotated build-dependencies?  both :native and :any exist in the archive, but https://launchpad.net/ubuntu/+source/gdbm/1.18.1-5ubuntu3 fails weirdly
[16:44] <vorlon> juliank: ^^ or is this an apt change?
[16:45] <juliank> vorlon: not aware of anything
[16:50] <vorlon> sil2100, bdmurray: why does http://cdimage.ubuntu.com/releases/19.10/release/ (and http://cdimage.ubuntu.com/releases/19.10.1/release/) exist with no images in the directory?
[16:51] <vorlon> (reported via a misdirected mail to https://launchpad.net/~ubuntu-release/+mailinglist-moderate which goes nowhere)
[16:52] <vorlon> aaaaand why does http://old-releases.ubuntu.com/releases/19.10/ still exist when it's removed from ancientminister
[16:52] <sil2100> Looking!
[16:53] <sil2100> vorlon: ok, so that's not yet finished, I was waiting to get info about the archival of images before I proceeded since there's the source images there still
[16:53] <vorlon> ok
[16:53] <sil2100> So I'll move them along with the rest of cdimage stuff
[16:54] <vorlon> oh, and releases.ubuntu.com/19.10 redirected me to old-releases, so that's by design
[16:54] <vorlon> (and I didn't notice the url had changed when I copy-pasted ;)
[16:54] <sil2100> Darn sneaky redirects ;)
[16:54] <sil2100> Anyway, pinky promise I'll finish the archivals tomorrow
[16:55] <sil2100> Since today I am finishing up appliances release
[16:55] <vorlon> ok
[17:28] <cjwatson> vorlon: I don't think it's possible for that to be a Launchpad regression; it's just calling sbuild there
[17:28] <cjwatson> vorlon: "but it is not installable" generally means that the dependency target *exists* but is itself uninstallable
[17:28] <cjwatson> vorlon: (possibly in combination with other build-dependencies)
[17:29] <cjwatson> vorlon: apt has never been verbose about the actual root cause of this type of problem without drilling down
[19:14] <vorlon> cjwatson: hmm, I can't reproduce any build-dep uninstallability locally with apt :/
[19:22] <vorlon> cjwatson: but a retry of the package in the main archive again failed, whereas https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/19856882 succeeded in installing the build-deps without the multiarch annotation...
[19:43] <vorlon> cjwatson: right, the problem here is me forgetting the semantics of M-A: foreign + :any / :native until I double-checked https://wiki.ubuntu.com/MultiarchCross - so I'm just doing an invalid thing here
[21:06] <cjwatson> vorlon: OK :)
[21:07] <cjwatson> And yeah, I always have to look those up too
[21:19] <sforshee> vorlon: I'm not very experienced at reading update_output.txt, but I think nvidia-graphics-drivers-450 cannot migrate in groovy because it breaks some l-r-m packages copied forward from focal. Is there anything we can do about that?
[21:20] <sforshee> short of getting all of those kernels updated in groovy ...
[21:38] <ginggs> sforshee: i think someone needs to clear the block-proposed tag from LP: #1889111
[21:41] <sforshee> ginggs: the bug status in invalid now, and update_excuses isn't saying anything about it being blocked, so that isn't the problem
[21:43] <sforshee> it looks like it's because it's now providing nvidia-kernel-common-440 and is outside the versions required in the depends: of those copy forward packages
[22:19] <Eickmeyer> vorlon: How are the linuxaudio-new-session-manager binaries looking?
[22:20] <Eickmeyer> Also, RAOF had deferred on dragonfly-reverb because he had questions about it regarding distribution of fonts in a .cpp format (I think?).
[23:20] -queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [amd64] (groovy-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ruby-aws-sdk-cloudformation [amd64] (groovy-proposed/universe) [1.41.0-2] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: node-markdown-it [amd64] (groovy-proposed/universe) [10.0.0+dfsg-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: ruby-aws-sdk-kms [amd64] (groovy-proposed/universe) [1.24.0-3] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: netgen [amd64] (groovy-proposed/universe) [6.2.2006+dfsg-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [amd64] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [armhf] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [riscv64] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [amd64] (groovy-proposed) [<IP_ADDRESS>-2]
[23:35] -queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-cloudformation [amd64] (groovy-proposed) [1.41.0-1]
[23:35] -queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-kms [amd64] (groovy-proposed) [1.24.0-2]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [arm64] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [s390x] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-cloudformation [amd64] (groovy-proposed) [1.41.0-2]
[23:35] -queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [ppc64el] (groovy-proposed) [<IP_ADDRESS>-1]
[23:35] -queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-kms [amd64] (groovy-proposed) [1.24.0-3]
[23:35] -queuebot:#ubuntu-release- New: accepted node-markdown-it [amd64] (groovy-proposed) [10.0.0+dfsg-1]


[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is barry.
[15:00] <barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
[15:00] <gmb> me
[15:01] <intellectronica> me
[15:01] <flacoste> me (at sprint - so half here)
[15:01] <adeuring> me
[15:01] <sinzui> me
[15:01] <noodles775> and me
[15:01] <cprov> me
[15:01] <BjornT> me
[15:01] <barry> welcome noodles775 !
[15:01]  * noodles775 grins
[15:02] <allenap> me
[15:02] <barry> bac: ping
[15:02] <bac> me
[15:02] <barry> danilos: ping
[15:03] <barry> EdwinGrubbs: ping
[15:03] <barry> mars: ping
[15:03] <barry> rockstar: ping
[15:03] <barry> salgado: ping
[15:03] <salgado> me
[15:03] <barry> [TOPIC] agenda
[15:03] <MootBot> New Topic:  agenda
[15:03] <barry> pretty light day today!
[15:04] <barry> * Roll call
[15:04] <barry>  * Peanut gallery (anything not on the agenda)
[15:04] <barry>  * Mentoring update
[15:04] <barry>    * al-maisan graduates
[15:04] <barry>    * noodles to start js reviews this cycle, official mentat status next cycle
[15:04] <barry>  * Action items
[15:04] <barry> [TOPIC] peanut gallery
[15:04] <MootBot> New Topic:  peanut gallery
[15:04] <mars> me
[15:04] <barry> let's start off with this: does anyone have anything reviewish that they'd like to bring up?
[15:05] <barry> wow, nothing?
[15:06] <sinzui> js reviews
[15:06] <sinzui> can be difficult to organise when all the reviewers are sprinting
[15:07] <barry> mars: do we have a plan for mentoring more js reviewers?
[15:07] <sinzui> Do we want to consider a plan to train up js reviewers?
[15:07] <EdwinGrubbs> me
[15:07] <mars> barry, anyone can pick up a JS review, if they are comfortable doing so
[15:07] <intellectronica> ideally everyone should be able to review js
[15:08] <barry> sure, i'm just wondering if we need a mentoring program for those (like me) who feel less comfortable reviewing js.
[15:08] <adeuring> frankly, I think i need much more experience writing JS code before I would feel able to review JS code
[15:08] <mars> sinzui can't review his own JS code, but he can ask the OCR if they are comfortable doing so
[15:08] <mars> :)
[15:08] <mars> hmm
[15:09] <mars> the OCR/reviewer thing is the best we have for now - it spreads the knowledge pretty wide
[15:09] <mars> without having formal JS-Review training for all the other reviewers
[15:10] <barry> mars: i guess we just need backups then for stuff we're less experienced with?
[15:10] <sinzui> mars: Do we have updated standards and cheatsheet of common JS problems?
[15:10] <mars> barry, well, we do have 8 people who can review JS code
[15:10] <mars> sinzui, that's on my list to write today
[15:11]  * sinzui is thinking of the rule that zope3 does not make css3 valid ids, so Y.get() fails.
[15:11] <intellectronica> barry: in a way, reviewing is a great way to build confidence, because you _have_ to understand what the code does and why it's written the way it is, and you _should_ ask if you don't :)
[15:11] <barry> mars: i actually like the idea of throwing people into the deep end, getting the ocr to review the js, but with an experienced js'er reviewing the review
[15:11] <mars> sinzui, :)
[15:11] <barry> intellectronica: yep :)
[15:12] <mars> barry, if you were at the sprint, you may have rethought that...
[15:12] <barry> lol
[15:12] <mars> the deep end for browser scripting is... deep
[15:12] <mars> with sharks
[15:12] <cprov> :)
[15:13] <barry> mars: foundations will make it all better, right?
[15:13] <mars> that's why I feel it's best suited to a "volunteer" program
[15:13] <barry> mars: or are you fitting laser helmets right now?
[15:13] <mars> barry, we're working on it - tools should help
[15:13] <mars> barry, yes, tools will help
[15:14] <mars> in a few cycles we should be to the point where the reviewer can just trust the tests
[15:14] <mars> but we're not there yet
[15:14] <barry> mars: i think coding guidelines will help a lot, even if they're incomplete
[15:14] <barry> mars: something a reviewer can read and point to
[15:14] <mars> agreed
[15:14] <barry> mars: that we fill up as questions arise
[15:15] <barry> mars: so i guess the recommendation is: ocr should try to review, and ask if you're not sure
[15:15] <mars> barry, true - the JS review then becomes more of a style and conformance review, but it still has value
[15:15] <mars> also agreed
[15:16] <barry> mars: i think that's the best way to start, since those are easier to get a handle on
[15:16] <barry> oh, i also want to point out that mars updated https://dev.launchpad.net/ReviewerSchedule
[15:16] <barry> this now includes a "specialties" column so you have a better idea of who can help out with js
[15:16] <barry> sinzui: thanks.  did you have anything else on this topic?
[15:16] <sinzui> no
[15:17] <mars> s/specialties/mentoring offered/ ?
[15:17] <barry> cool, anybody have anything else on any topic not on the agenda?
[15:17] <barry> mars: sup to the reviewer i guess
[15:18] <barry> [TOPIC] mentoring update
[15:18] <MootBot> New Topic:  mentoring update
[15:18] <barry>    * al-maisan graduates
[15:18] <barry> but he's not here :)
[15:18] <adeuring> congart al-maisan!
[15:19] <barry>    * noodles to start js reviews this cycle, official mentat status next cycle
[15:19] <barry> noodles775: we'll figure out a mentor/ocr for you next cycle.  welcome aboard!
[15:19] <noodles775> Thanks!
[15:20] <barry> [TOPIC] action items
[15:20] <MootBot> New Topic:  action items
[15:20] <barry>  * gary to add `getStore()` as an alias for `_get_store()`
[15:20] <barry> gary's not here though.  does anybody know if this happened?
[15:21] <barry>  * flacoste to look into storm/sqlobject result set compatibility
[15:21] <flacoste> barry: gary still needs to do this, he's on a sprint so has an excuse
[15:21] <barry> cool :)
[15:21] <flacoste> barry: i replied with a possible solution to gavin yesterday
[15:21] <flacoste> barry: he can tell if it works or not :-)
[15:22] <barry> excellent, thanks!
[15:22] <allenap> flacoste: I'll be putting that in my branch later today.
[15:22] <allenap> Thank you :)
[15:22] <barry> allenap: great, let us know how it works
[15:22] <flacoste> allenap: if it works, i'd suggest you add it to storm itself
[15:22] <allenap> Will do.
[15:22] <barry> well, *if* it works :)
[15:22] <allenap> flacoste: Good idea!
[15:23] <barry>  * gary will check to see if there's a bug open for adding a hook to `bzr send`, and submit one if there isn't
[15:23] <barry> gary's sprinting so we won't worry about this one
[15:23] <barry>  * bigjools to take crack at helper functions for backpatching schemas to avoid circular imports
[15:23] <barry> and bigjools isn't here (sprinting?)
[15:23] <barry>  * abentley to experiment on storm base class
[15:23] <barry> nor is abentley, but does anybody know what the status of his sugarstorm branch is?
[15:24] <barry> i have not done my three action items, but now i have access to to the old wiki again, so i'm going to try to find some time to migrate/update
[15:25] <barry>  * flacoste to work on API reviewer cheat sheet
[15:25]  * flacoste hides
[15:25] <barry> no worries hoover :)  keep it on the list?
[15:26] <cprov> barry: bigjools is off (vacations) this week
[15:26] <barry> cprov: cool, thanks
[15:26] <barry> well.  that's everything that i have.  if there's nothing more we can break early
[15:26] <barry> 5
[15:27] <barry> 4
[15:27] <barry> 2
[15:27] <barry> 1
[15:27] <barry> #endmeeting
[15:27] <MootBot> Meeting finished at 09:27.
[15:27] <barry> thanks everyone!  record time
[15:27] <mars> thanks barry
[15:27] <allenap> Woo, thanks.
[15:28] <intellectronica> thanks, barry
[15:28] <noodles775> taa barry
[15:28] <barry> bye


[00:42] <pleia2> next Xubuntu at article drafted here http://xubuntu.org/?p=2965
[00:42] <pleia2> we need to find more orgs using Xubuntu, I've run out
[00:45] <bluesabre> ochosi, ali1234: https://launchpad.net/ubuntu/+source/xfce4-volumed/0.2.0-0ubuntu2
[00:46] <bluesabre> pleia2: that looks good :)
[00:48] <pleia2> great, it's shorter than some of the others, but very direct
[00:50] <bluesabre> nothing wrong with that
[00:50] <pleia2> I'll publish on Monday or so
[00:53] <Noskcaj> ochosi, darkxst did the work for me, so we now have http://phillw.net/ubuntu-gnome/Xvivid410.html
[01:02] <Noskcaj> It will probably be renamed to http://phillw.net/ubuntu-gnome/Xvivid412.html
[09:17] <Akusari> hello  :-)
[09:17] <elfy> morning
[09:19] <Akusari> elfy: you wrote " nice little disk space usage bar turned up in thunar" which version is it?
[09:20] <elfy> 1.6.5
[09:21] <Akusari> ahhh, thanks
[09:22] <Akusari> so, its a deb package in vivid?
[09:30] <elfy> yep an update in vivid
[09:33] <Akusari> thanks, wasn't an good idea todo a bling update in trusty :-P
[09:33] <Akusari> blind
[09:36] <Akusari> Well, maybe a backport to trusty is possible. I'll look on depencies and changelog. i have the bzr trunk already :-)
[09:45] <brainvvash> Akusari, https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xfce-4.12
[09:49] <Akusari> brainvvash thanks, sounds good
[09:53] <Akusari> hmmm, i don't see all thunar plugins shipped with this ppa. Maybe there are package collection changes. I'll test it on my dev vbox :-)
[09:54] <Akusari> btw: if xfce 4.12 is out finaly, do you plan a trusty backport ?
[12:07] <elfy> for you xfce peeps - https://wiki.xfce.org/contribute points to xfce users mailing list
[12:07] <elfy> that gets a 404
[12:07] <elfy> http://foo-projects.org/mailman/listinfo/xfce
[12:58] <bluesabre> elfy: lol
[13:00] <elfy> bluesabre: I was just looking at your blog re 4.12
[13:00] <elfy> so followed the trail ;)
[13:01] <elfy> just realised I can report that :p
[13:02] <bluesabre> :D
[13:02] <bluesabre> reported it up the chain
[13:03] <bluesabre> elfy: its fixed
[13:04] <bluesabre> thanks for your bug report :D
[13:04] <elfy> :D
[13:05] <elfy> that's funny - let me mark it fixed resolved
[13:05] <elfy> I really should hang about in xfce-dev I guess
[13:06] <elfy> bluesabre: anyway - so if xfce wants people to test this stuff - I assume as vanilla xfce, which is best done where?
[13:06] <elfy> and how on earth can you grab a bug list without specifying anything but date and not fixed?
[13:07] <bluesabre> elfy: its easiest to test in vivid, we have everything there
[13:07] <bluesabre> the bug list is tricky, you have to modify the url
[13:07] <elfy> just as xfce session?
[13:07] <bluesabre> xubuntu session should be fine actually
[13:08] <elfy> I hate bug lists - if I can't find something easily - report it, someone somewhere will facepalm and mark as dupe :D
[13:08] <elfy> bluesabre: oh ok - so doing that anyway then :p
[13:08] <bluesabre> but you can modify the url and drop all the extra fluff until you have product and resolution, like so
[13:08] <bluesabre> https://bugzilla.xfce.org/buglist.cgi?product=Exo&resolution=---
[13:09] <bluesabre> elfy: yup, xubuntu team is pretty invaluable for xfce testing since we always ship the latest
[13:09] <elfy> ok - might add trawling through xfce bugs to my plan
[13:09] <bluesabre> that and arch
[13:09] <elfy> yep
[15:18] <elfy> what I mean by lost any clue is I've lost the will to live when people "lightlocker 14.04" in any combination
[15:33] <dkessel> Unit193, others: yay for lowering the translation percentage - the german docs translation will make it into vivid now =)
[15:33]  * dkessel will continue translating the remaining parts nevertheless :)
[15:34] <dkessel> if any of you want to steal my PPA recipe for the docs and add it to staging or something, that's fine with me too
[15:35] <dkessel> ^ don't know who to ping ;)
[15:36] <elfy> neither do I :)
[15:53] <Akusari> I noticed that ppa xfec-4.12 includes xfce4-whiskermenu-plugin version 1.43. The official xubuntu-backports ppa for trusty is shipped with version 1.40 only. Version 1.43 includes only bugfixes and no functional change compared to 1.40. Suggestion: Copy version 1.43 to xubuntu-backports for all users :-)
[15:54] <Akusari> i'm using version 1.43 with trusty for a week now without any problems so far
[18:54] <Unit193> dkessel: Sure thing, doc.
[18:54] <Unit193> "The official xubuntu-backports ppa for trusty"?
[19:06] <dkessel> Nah
[19:06] <dkessel> Unit193: https://launchpad.net/~dkessel/+archive/ubuntu/xubuntu-docs-daily
[19:07] <Unit193> Nah, someone else's comment after yours.
[19:12] <dkessel> D'oh
[22:08] <knome> pleia2, ochosi: either of you around?
[22:12]  * bluesabre is
[22:12] <knome> 00:03 knome: oh wow
[22:12] <knome> 00:03 knome: our theme has been up for like 4 days
[22:12] <knome> i'm about to make it public soonish
[22:12] <knome> i need yes to check it once that's done
[22:13] <bluesabre> sounds exciting :D
[22:13] <knome> yes!!
[22:16] <knome> ok, done
[22:16] <knome> please look around
[22:17] <bluesabre> looking
[22:17] <bluesabre> no hand-drawn computers?
[22:17] <knome> not yet
[22:18] <bluesabre> knome: 14.10 release announcement points to the beta announcement
[22:18] <knome> heh.
[22:18] <knome> fixed
[22:19] <knome> damn caching :)
[22:20]  * bluesabre wants to standardize the screenshot size for http://xubuntu.org/screenshots/
[22:20] <knome> hmm?
[22:21] <knome> oh, heh, image aspect ratio?
[22:21] <knome> it also shows images in a weird order
[22:21] <knome> :)
[22:21] <knome> if you have a $bunch of shots for 14.04 and/or 14.10, put them somewhere and i'll grab an push them
[22:22] <bluesabre> I'll try to get a bunch of same aspect ratio in the next few days
[22:22] <bluesabre> http://xubuntu.org/blog/ is kinda left-heavy
[22:22] <knome> wfm
[22:22] <knome> or cooperate with slickymaster
[22:22] <knome> oh, of course
[22:22] <knome> need to fix that next
[22:23] <bluesabre> http://xubuntu.org/donations/ is pretty
[22:23] <knome> mhm
[22:23] <knome> many pages arẹ..
[22:24] <bluesabre> http://i.imgur.com/HMUq8RD.png
[22:24] <knome> i know i know
[22:24] <knome> just didn't get to that yet
[22:24] <bluesabre> :D
[22:25] <knome> should be better already
[22:26] <knome> search widget still looks crappy, so not showing it
[22:26] <bluesabre> knome: very nice
[22:26] <bluesabre> no other appearance issues
[22:26] <knome> this is all so nice
[22:26] <knome> thanks!
[22:26] <knome> i also tweeted about it, you might want to RT
[22:26] <bluesabre> indeed
[22:27] <bluesabre> done
[22:27]  * knome bows
[22:34] <bluesabre> knome: actually, why no 14.04 screenshots at all?
[22:34] <knome> because old stuff
[22:34] <knome> we are doing things in the new way (tm) now...
[22:34] <knome> i guess i could move the 14.04 screenshots to the screenshots page
[22:35] <bluesabre> its a lot prettier than the releases preceding it
[22:35] <knome> heh, i would hope every release is
[22:36] <bluesabre> so, what do we want the standard screenshot resolution to be?
[22:38] <knome> i guess we want it to be in widescreen, most people use that now
[22:38] <bluesabre> also, http://xubuntu.org/screenshots/oneiric_01/ (is the panel missing because that was the one with the seemingly innappropriate date)?
[22:38] <knome> i have no idea...
[22:39] <knome> i personally would dump all the old screenshots for now.
[22:39] <bluesabre> yeah
[22:39] <knome> we can reupload them if we need/want to
[22:39] <knome> probably to an archive page or sth
[22:39] <knome> the thing is,
[22:39] <knome> the screenshots page used to be the archive page
[22:39] <knome> because we had the recent screenshots on the front page
[22:40] <bluesabre> ah, right
[22:40] <bluesabre> 1280×720 maybe?
[22:41] <knome> preferably >1400 in width
[22:41] <knome> or, tbe, 1400 or more
[22:41] <knome> that's the max width specified for the site
[22:41] <knome> but if they aren't, then no big deal
[22:41] <knome> because they should always be centered anyway
[22:41] <knome> ..i guess
[22:42] <bluesabre> :)
[22:46] <bluesabre> not sure > 1400 is a good idea with the recent burst in 1366×768 laptops
[22:46] <knome> heh
[22:46] <knome> well...
[22:46] <knome> do 1366 then
[22:46] <knome> but it doesn't really matter much
[22:49] <bluesabre> http://www.w3schools.com/browsers/browsers_display.asp
[22:50] <knome> well i mean website-technically
[22:52] <bluesabre> yeah
[22:52] <bluesabre> just give me two numbers and I'll get on it
[22:52] <bluesabre> :P
[22:52] <bluesabre> and leave the VMs on my system in case we need to change
[22:52] <knome> well any regular widescreen aspect ration, with the width being 1400 or larger is ideal
[22:53] <knome> but if that's hard to do, 1366 or 1280 works as well
[22:55] <bluesabre> k
[22:55]  * bluesabre will work on 1440x900
[22:55] <knome> nice, thanks
[22:56]  * knome goes improve the download page
[23:04]  * knome fixed the release announcement posts with images
[23:04] <knome> http://xubuntu.org/news/14-10-release/
[23:04] <knome> looks nice and in line with the overall stuff now
[23:50] <bluesabre> knome: trusty https://www.dropbox.com/s/77fdiettxe6xcov/trusty.tar.gz?dl=0
[23:50] <knome> ta
[23:50] <knome> processing
[23:52] <bluesabre> I'll do a similar set for precise, and ~2-3 for utopic
[23:53] <knome> mhm
[23:53] <knome> fwiw, we currently have no way to order the images as we wish
[23:53] <bluesabre> oh?
[23:53] <knome> should probably think the right way (tm) to do that for 2.0
[23:53] <knome> yeah, currently it just orders based on time, newest first
[23:54] <bluesabre> we can use touch on the screenshots to order them before upload
[23:54] <knome> i believe it's upload time, not file creation time
[23:54] <knome> but that's an interesting idea.
[23:55] <bluesabre> not sure how ugly the upload time in the wp db is
[23:55] <bluesabre> or just bulk upload in order when we get all screens
[23:55] <knome> yes
[23:55] <knome> something like that
[23:57] <bluesabre> It'll take a while for the others, but should have them for you by morning
[23:58] <knome> http://xubuntu.org/screenshots/
[23:58] <knome> okay.
[23:58] <knome> i have no idea why they turned up like that
[23:58] <knome> and in multiples.
[23:58] <bluesabre> lol