[01:33] <bigjools> roaksoax: I am landing a change to the cluster worker that will require it to have bind privs on port 68.  I use authbind in the development environment but how do you want to approach this in packaging?
[01:35] <roaksoax> bigjools: im not home now(from the cell) but can we discuss this later?
[01:35] <roaksoax> binding to 68 might cause problems with otjet services
[01:35] <roaksoax> smoser ^^
[01:36] <roaksoax> other*
[01:36] <bigjools> roaksoax: it uses SO_REUSEADDR
[01:36] <bigjools> no problem discussing later
[01:36] <roaksoax> cool
[01:36] <roaksoax> ttyl
[01:37] <smoser> i'm on my way out. and i'd have to think about this.
[04:05] <roaksoax> bigjools: ok, so where's the branch, why is it needed, and what impliations do you think it will cause?
[04:52] <bigjools> roaksoax: it's to detect dhcp servers, it has to bind to source port 68.  end of.
[04:54] <roaksoax> bigjools: right, so what will bind to it?
[04:54] <bigjools> roaksoax: the cluster worker
[04:56] <roaksoax> bigjools: what other servicces use port68?
[04:56] <bigjools> roaksoax: it's the dhcp client source port
[04:56] <roaksoax> bootpc		68/tcp				# BOOTP client
[04:56] <roaksoax> bootpc		68/udp
[04:56] <bigjools> so I hope nothing
[04:56] <bigjools> but even if there is something it doesn't matter
[04:57] <bigjools> I have tested locally with dnsmasq running and it's fine
[04:57] <bigjools> so, how can you sort this out in packaging?
[04:57] <roaksoax> bigjools: "This packet identifies that a client is searching for an IP address. The packet uses UDP port 68 as it's source address for the client, since it does not have an IP address that refers back to the client."
[04:57] <bigjools> dude the branch has landed and it ain't gonna change
[04:58] <roaksoax> bigjools: i'd need more information that that really. It seems that it is the port used by a dhcp-server to discovery clients right? so what happens if you bind that port and DHCP is useless?
[04:58] <roaksoax> what happens if it create DHCP issues?
[04:58] <bigjools> no, it is not used by a dhcp server
[04:59] <bigjools> dhcp serves on port 67
[04:59] <roaksoax> bigjools: udp        0      0 <IP_ADDRESS>:68              <IP_ADDRESS>:*                           15106/dhclient
[04:59] <bigjools> that's the client
[04:59] <roaksoax> bigjools: so dhclient seems to bind to port 68
[04:59] <bigjools> yes, they all do
[04:59] <bigjools> that's why the cluster worker does it
[05:00] <roaksoax> bigjools: right, but have you tested this on a client that uses dhclient to obtain IP address?
[05:00] <bigjools> think about this
[05:00] <roaksoax> bigjools: note that I'm not against using the part, I just want to understand the implications of doing so
[05:00] <bigjools> why would your machine, which is running a dhcp server, also be running a dhclient?
[05:01] <roaksoax> bigjools: because mymachine obtains a DHCP from a router
[05:01] <bigjools> you can't do that you'd be running two dhcp servers
[05:01] <roaksoax> bigjools: my machine does not have a static IP address and DHCP's from another DHCP server
[05:01] <bigjools> so unless you configure them not to cross, it's stupid :)
[05:02] <bigjools> anyway I have tested this and it works fine even if you have a dhcp client running already
[05:02] <bigjools> it uses SO_REUSEADDR
[05:02] <bigjools> the point of the feature is to help idiots from shooting themselves in the foot by running more than one dhcp server
[05:04] <roaksoax> bigjools: yeah I understand that, I just want to make sure doing so doesn't coonflict with other operations mof the OS
[05:04] <roaksoax> if this is tested and doesn't then cool
[05:04] <bigjools> it won't
[05:04] <roaksoax> if it does, then sucks
[05:04] <roaksoax> as i said
[05:04] <roaksoax> I just want to understand the implications of doing so to make sure nothing will break
[05:04] <roaksoax> anyway
[05:04] <bigjools> it is very careful to use a transaction ID on the probe packet
[05:04] <bigjools> so won't clash
[05:04] <roaksoax> send me what you need for the packaging to email
[05:04] <roaksoax> i'm off now
[05:05] <bigjools> good night roaksoax
[05:05] <roaksoax> night
[05:05] <roaksoax> bigjools: is this a new daemon or what?
[05:05] <bigjools> roaksoax: no
[05:06] <bigjools> part of celery
[05:06] <roaksoax> bigjools: so then I don't think we will need packaging changes then
[05:06] <roaksoax> if it is being run by maas-region-celery
[05:06] <bigjools> does it run as root?
[05:06] <bigjools> if not we need changes to set up authbind
[05:07] <roaksoax> bigjools: it runs as maas user/pass
[05:07] <roaksoax> user/group
[05:07] <roaksoax> exec /usr/sbin/maas-region-celeryd --logfile=/var/log/maas/celery-region.log --schedule=/var/lib/maas/celerybeat-region-schedule --user=maas --group=maas
[05:08] <bigjools> so needs to be exec authbind --deep /usr/sbin/maas-reg.....
[05:08] <bigjools> after setting up /etc/authbind/byport/68
[05:08] <bigjools> or similar
[05:09] <roaksoax> bigjools: ok, please send me that over email, my eyes will explode soon -> ved
[05:09] <roaksoax> bed
[05:09] <bigjools> ok :)
[07:27] <jtv> bigjools: shall I update the daily PPA to include the DHCP-probing code?
[07:38] <bigjools> jtv: no it won't work yet, needs packaging changes
[07:41] <jtv> That's unfortunate because my dhcp-checking branch for maas-test requires it.
[07:42] <bigjools> jtv: well go ahead anyway it'll just traceback in the celery log
[07:42] <bigjools> jtv: hit rebuild on the recipe
[07:42] <jtv> Shouldn't I land an update to the changelog first?
[07:42] <bigjools> no, daily build will DTRT
[07:43] <bigjools> recipes are fkin awesome
[07:43] <jtv> But we already have a build from yesterday in there, and it uses an old revision of trunk...
[07:43] <bigjools> when you hit rebuild it will pull latest trunk
[07:43] <jtv> Ah!
[07:43] <jtv> That is nice.
[07:43] <jtv> I'm all motivated to go back to work on LP.  :)
[07:43] <bigjools> lol
[07:46] <ticking> Say, does somebody know if MAAS supports non pxe hardware? e.g. mac pros
[07:46] <bigjools> ticking: sort of
[07:47] <bigjools> provided it can tftp to the right place it'll get boot resources
[07:47] <ticking> but the avahi boot image is unsuported right?
[07:47] <bigjools> yeah that's getting junked entirely in 14.04
[07:48] <ticking> so there is no standard way of using tftp anymore?
[07:49] <bigjools> define standard
[07:50] <ticking> boot cd/stick, configure, connect, be happy ^^
[07:50] <bigjools> normally the machine requests pxeconfig first, but other hardware like arm that doesn't pxe will request a specific tftp path
[07:50] <ticking> ah I see, so the hardware does the tftp
[07:50] <bigjools> tftp is nothing to do with avahi
[07:51] <bigjools> avahi was just a way for the installer cd to discover the maas server
[07:51] <bigjools> but in the real world nobody is going to go around sticking CDs in hundreds of racks
[07:52] <ticking> ah I see, the wiki is worded as if there was a way to load the boot image with the help of some provided base system
[07:53] <bigjools> the general idea is that machines will be discovered from the maas server using ipmi
[07:54] <bigjools> it'll then attempt to power them up using ipmi and they'll hunt for a dhcp server which directs a pxe boot
[07:54] <ticking> yeah, I have a ton of decent mac pros lying around, being able to configure them quickly and painlessly would be nice
[07:54] <ticking> but they only support wake on lan, no pxe no tftp boot
[07:54] <bigjools> WoL is nasty
[07:54] <bigjools> you have no way of powering off
[07:56] <ticking> for now I'm only concerned with at least booting them ^^
[07:57] <bigjools> I can't remember offhand how to direct machines to tftp from the right place when not using pxe
[07:57] <ticking> Interestingly it seems that mac pros do indeed support tftp ^^
[07:57] <ticking> so thanks for the pointer
[07:58] <bigjools> are they power?
[07:58] <bigjools> because maas doesn't know about power :)
[07:59] <jtv> PowerPC, that is.
[07:59] <ticking> hrhr no
[07:59] <ticking> intel
[07:59] <ticking> x64
[08:02] <ticking_> lol, liiks like I
[08:02] <ticking_> looks like I killed my switch with the netboot ^^
[08:17] <tom___> hi, what is the minimum # of nodes required to deploy a MAAS server?
[08:17] <jtv> Absolute minimum?  One node, plus one server.
[08:18] <tom___> can the node be a VM? (Virtual Box VM)
[08:18] <jtv> I think it can, but MAAS won't create it for you.
[08:19] <tom___> I want to learn how to setup Openstack with Ubuntu, and don't have many machines.
[08:19] <tom___> I can create the VB VM, and add it to MAAS?
[08:19] <tom___> ok, I get it
[08:19] <jtv> I don't know if virtualbox can simulate a BMC though.
[08:19] <tom___> what is a BMC?
[08:20] <jtv> Baseboard management controller.  It's what lets MAAS reboot a node remotely.
[08:20] <tom___> No, VB probably not support that
[08:21] <tom___> I have some old PC, is BMC a requirement for the hardware?
[08:21] <jtv> Effectively, yes.
[08:21] <jtv> You might get by with manual handling of the power switch, but that's not going to be as convenient.
[08:22] <jtv> I know there are virtual machine managers out there that do support it though.
[08:22] <tom___> does MAAS power cycle the nodes often? Or only when it do the initial OS install?
[08:22] <tom___> which VM manager?
[08:23] <jtv> Might have been KVM...
[08:23] <jtv> MAAS reboots a machine as part of commissioning, once to install it, and then once again at the end of installation IIRC.
[08:24] <tom___> so I can probably try to manually reboot the box.
[08:24] <jtv> I think so.  Once the machine is deployed, it's basically yours to boot at will.
[08:25] <tom___> after installation, there's no need to physically reboot the node
[08:25] <jtv> Right.
[08:27] <tom___> thanks
[08:27] <jtv> I'd be curious to know how it works out!
[08:29] <tom___> will let you know
[08:34] <jtv> Thanks.
[09:05] <tom___> @jtv, http://marcoceppi.com/2012/05/juju-maas-virtualbox/
[09:06] <tom___> someone managed to get maas to work with VirtualBox.
[09:06] <jtv> \o/
[09:06] <jtv> Thanks for that pointer.
[09:28] <gmb> rvba: I'm seeing this this morning when I run m-t on my Saucy machine. Any idea WTF is going on? http://paste.ubuntu.com/6518779/
[09:30] <jtv> gmb: any chance that you're running an older uvtool?  I can still create VMs with uvtool directly.
[09:31] <gmb> jtv: No, this is after an apt-get update.
[09:40] <jtv> gmb: I was just wondering if maybe you weren't using the right PPA.
[09:42] <jtv> gmb: for comparison, I'm running uvtool 0~bzr66~ubuntu13.10.1
[09:42] <gmb> jtv: Good thinking. I'll check.
[11:32] <rbasak> gmb: I see: "qemu: at most 2047 MB RAM can be simulated" in that pastebin. How much system RAM do you have on that machine?
[12:45] <gmb> rbasak: 4GB. And it was working last week.
[12:45] <rbasak> gmb: which release are you on?
[12:45] <rbasak> gmb: (of Ubuntu)
[12:45] <gmb> Saucy
[12:46] <rbasak> Ah. I see that you already said, sorry.
[12:47] <rbasak> gmb: I'm not sure what's going on there, but it seems to be an issue with qemu/kvm or your system, not libvirt or uvtool, if that helps.
[12:47] <gmb> rbasak: It helps me narrow it down, certainly. I'll try poking at a few things. Thanks.
[12:47] <rbasak> gmb: perhaps try lowering the --memory option and see if that helps?
[12:47] <gmb> That was going to be the first thing I poked :)
[12:48] <gmb> rbasak: Yeah, that works. --memory 2047 is _fine_
[12:48] <gmb> (I hadn't noticed that option until just now)
[12:48] <rbasak> gmb: there's no i386 vs. amd64 thing going on here, is there?
[12:49] <rbasak> 2048 is a magic boundary point for some things I think.
[12:49] <rbasak> Ah
[12:49] <rbasak> The line says arch=i386
[12:49] <rbasak> Hmm
[12:49] <rbasak> uvtool doesn't actually care about that. It never specifies the required arch to libvirt, so that's just the image arch, rather than the guest machine arch.
[12:49] <rbasak> I wonder if that's a bug.
[12:50] <rbasak> gmb: are you on an i386 or amd64 kernel?
[12:51] <gmb> rbasak: uname says i686
[12:52] <rbasak> gmb, rvba: I think http://bazaar.launchpad.net/~maas-maintainers/maas-test/trunk/revision/81 introduced this, but only on i386 machines, like gmb's.
[12:52] <rbasak> You're asking for --memory 2048, but gmb is getting an i386 guest, which doesn't support that.
[12:53] <gmb> rbasak: Yeah, I just came to the same conclusion. I'll revise that value down by one.
[12:53] <rbasak> Currently uvtool has no provision for setting guest architecture, except through --template. I wonder if that needs to be addressed.
[12:54] <rbasak> gmb, rvba: it might be worth considering and documenting a minimum memory requirement for maas-test.
[12:54] <gmb> Right.
[12:56] <rbasak> Other related thoughts: perhaps it's because the guest doesn't support pae by default, which is uvtool bug 1256658.
[12:56] <rbasak> (rather than an inherent i386 limitation)
[12:56] <rbasak> gmb: I'd be interested to know if it works if you use a template that is patched according to comment 1 in that bug.
[12:57] <rbasak> (for memory >= 2048)
[12:58] <gmb> rbasak: I'll check in a second. bear with me.
[12:58] <rbasak> Thanks!
[13:04] <gmb> rbasak: Nope, still get the memory error with that snippet in place.
[13:05] <rbasak> gmb: just to check, did you patch its use in maas-test, rather than the (unused) system one?
[13:05] <gmb> rbasak: Yes, I patched the template we use in maastest/kvmfixture.py:383 (KVM_TEMPLATE).
[13:06] <matsubara> gmb, allenap: are you guys using the MAAS lab? I see a running instance there
[13:06] <allenap> matsubara: Not me.
[13:07] <gmb> matsubara: Not me.
[13:07] <rbasak> gmb: OK, thanks. I'm not sure what's going on there. For now, I think --memory=2047 is probably sensible then.
[13:08] <gmb> rbasak: Cool, thanks for helping me out.
[13:08] <rbasak> np. Good to know what sorts of issues people will hit.
[13:08] <rbasak> I'd never considered the host/guest arch selection before.
[13:37] <ticking> say, what does adding a node via the ubuntu install disk really do? there seems no informatiuon whatsoever on this online
[13:40] <ticking> does it require ubuntu 12? lan boot enabled? wake on lan enabled?
[13:42] <ticking> also what happened to maas-import-isos?
[13:42] <gmb> ticking: IIRC it allows you to boot up a node using the Ubuntu CD and then have MAAS provision that node; I'm not clear on the details of how that works, but the plan is to drop it for 14.04.
[13:43] <gmb> ticking: I believe -import-isos went away and we now have maas-import-ephemerals / -import-pxe-files. Don't quote me on that, though; -import-isos was before my time.
[13:43] <ticking> gmb, ah thanks, it seems broken already with 13
[13:43] <gmb> ticking: 13.what?
[13:44] <rbasak> maas-import-pxe-files calls maas-import-ephemerals by default, unless that changed recently.
[13:44] <rbasak> You can trigger a simple run from the web UI as well I think.
[13:44] <ticking> 13.10
[13:44] <ticking> rbasak, cool thanks :)
[13:44] <rbasak> ticking: how is it broken?
[13:45] <ticking> rbasak, node shuts down, but does not register with maas
[13:46] <rbasak> Hmm. Not sure about that. Grabbing console output might help you debug the cause for that.
[13:46] <ticking> rbasak, yeah I would if it didn't autoshutdown
[13:48] <rbasak> You can modify the cloud-init userdata for the enlistment case to change that. I can't remember the details though. Somewhere in /etc/maas/templates probably.
[13:50] <ticking> rbasak, I'll try that thanks
[14:35] <ticking> I give up ^^ using pxe just makes sense
[14:41] <roaksoax> rbasak: ping
[14:41] <roaksoax> err
[14:42] <roaksoax> rvba: ping
[14:42] <gmb> roaksoax: He's unavailable today.
[14:42] <roaksoax> gmb: thanks!
[14:42]  * gmb notes that he has the Good Ship MAAS pretty much to himself this afternoon.
[14:43] <gmb> Now there's a disturbing idea.
[14:43] <mgz> it's okay, you can't sink it in an afternoon
[14:43] <gmb> mgz: No, but I can start rewriting it in Go.
[14:43] <mgz> :D
[15:16] <ticking> gmb, you have my sword, and my go!
[15:17] <gmb> :)


[04:40] <kantlivelong> does RPCNFSDCOUNT not work in 16.04 for nfs-kernel server? it looks to me that its never used by the service unit file but the unit does use RPCNFSDARGS
[04:42] <kantlivelong> i only ask because increasing the thread count seems to make no diff
[06:44] <lordievader> Good morning
[14:52] <lucidguy> Ok, Server with 192GB of ram.  I assume that's GIGA, and not GIBI.  Convert that to Gibibytes and you get 178GiB.  If you do a free -g on the box you get 187?  I'm pretty sure df is in GiB, so why is there about 10GiB discrepancy?
[14:54] <sdeziel> lucidguy: AFAIK, RAM is expressed with a 1024 base value for "K"
[14:55] <lordcirth> sdeziel, -g is gibibytes according to the manpage
[14:55] <sdeziel> lordcirth: I'm referring to the 192GB part
[14:56] <lordcirth> Ah, the manufacturer? Yeah I don't know what they use
[14:56] <lucidguy> Ohh, so ram is sold in GiB not GiG like drives?
[14:56] <sdeziel> lucidguy: that said, that doesn't explain where the 5GB went
[14:56] <blackflow> 192GB of physical RAM but not every bit is addressable. dmesg will show available physical addressable RAM in bytes.
[14:57] <sdeziel> lucidguy: I'd check 'dmesg | grep -i memory' and see how the kernel reserved that RAM
[14:59] <sdeziel> lucidguy: on a random box here, I have: Memory: 4740848K/4914680K available (8613K kernel code, 1335K rwdata, 4028K rodata, 1484K init, 1284K bss, 173832K reserved, 0K cma-reserved)
[14:59] <lucidguy> Memory: 196455640K/199738988K available (12300K kernel code, 2473K rwdata, 4288K rodata, 2408K init, 2416K bss, 3283348K reserved, 0K cma-reserved)
[14:59] <sdeziel> lucidguy: and this VM has 4800MiB assigned
[15:00] <sdeziel> If I'm doing my maths right, your kernel only sees 190.4 GiB
[15:00] <lucidguy> sdeziel: Does that make sense?
[15:00] <sdeziel> and 3.13 GiB are 'reserved', whatever that means
[15:01] <blackflow> stack <-> heap gaps'n'all, that RAM is not addressable.
[15:01] <sdeziel> lucidguy: I don't know why the kernel doesn't see the full 192 GiB, looks like the EFI/BIOS is hiding some of it or something like that but I'm just guessing at this point
[15:02] <lucidguy> Ok, this makes more sense now.  I knew storage, like drives were in GiG and not GiB, thought RAM was sold/represented the same way.
[15:02] <sdeziel> blackflow: I would assume that only apply to virtual addresses, not physical ones, no?
[15:02] <patdk-lap> if you have some pci devices that use memory (aka video cards)
[15:02] <patdk-lap> that memory is not usable by the os
[15:02] <sdeziel> yeah ^
[15:03] <sdeziel> but 2G of video RAM on a server sounds a little excessive ;)
[15:03] <lucidguy> My last statement is accurate right?  Disks are still sold in GiG?
[15:03] <patdk-lap> I think some network cards do this also, and infiniband cards, but those are rare
[15:03] <patdk-lap> ya, I guess it has to be a real server motherboard to have 192gb ram anyways
[15:04] <patdk-lap> could need it if it was a windows server :)
[15:04] <lucidguy> Ubuntu Server
[15:04] <patdk-lap> efi/bios doesn't hide it
[15:04] <patdk-lap> hmm, that motherboard was designed for only ubuntu server?
[15:05] <lucidguy> I wonder if the BOSS storage controller is taking some
[15:06] <sdeziel> patdk-lap: do you know where the NIC/video cards reserved chunks would be visible/accounted for? Would the kernel still see that memory or not? If it does, would they be in the 'reserved' section from that dmesg line?
[15:06] <patdk-lap> the kernel won't see it, it will be subtracted before the os boots
[15:07] <lucidguy> Thanks guys, appreciate the responses, solved my mystery.
[15:07] <sdeziel> OK so that would explain where the 1.6GiB went
[15:07] <lucidguy> I'm sure I read online that ram sold was represented in GiG not GiB.. grr
[15:07] <sdeziel> one day, I hope to understand what the kernel reserves...
[15:08] <patdk-lap> well, I cannot remember how it does it now
[15:08] <patdk-lap> but should reserve <1meg
[15:08] <patdk-lap> still lots of dma stuff that only works below 1meg or 16megs
[15:08] <sdeziel> 170MiB on that i440fx VM
[15:08] <sdeziel> out of 4800MiB assigned to it
[15:09] <blackflow> sdeziel: yes, but that will always reduce the availability of physical RAM as long as physical addresspace is less than virtual (which is always unless you had gazillions of ram)
[15:10] <blackflow> oh yeah, there's the GPU as well, sometimes it shares the system RAM
[15:10] <patdk-lap> said that way above
[15:10] <blackflow> sorry, didn't see it
[15:11] <sdeziel> blackflow: I don't understand how the gap between stack and heap wouldn't be usable by the kernel. That gap is in virtual address space alone, no?
[15:19] <patdk-lap> it is
[15:19] <patdk-lap> but that doesn't really help the kernel
[15:19] <patdk-lap> if the kernel was places randomly in each process, none of it's memory pointers or anything would work
[15:20] <sdeziel> patdk-lap: I'm arguing with: blackflow: stack <-> heap gaps'n'all, that RAM is not addressable.
[15:20] <patdk-lap> define addressable :)
[15:20] <sdeziel> more specifically the 'not addressable' part
[15:20] <patdk-lap> if you use it, it will cause a exception
[15:21] <sdeziel> not addressable by the userspace process
[15:21] <patdk-lap> it is addressable
[15:21] <patdk-lap> it's not backed by anything, and needs to be allocated
[15:21] <sdeziel> what I'm saying is this gap is purely virtual, it doesn't waste any physical RAM
[15:22] <patdk-lap> well, there is some waste, but your talking on a small level, 4k
[15:22] <sdeziel> I don't understand why the gap would be allocated at all
[15:22] <patdk-lap> or maybe more for empty stack allocations
[15:22] <patdk-lap> unused stack space
[15:23] <patdk-lap> unused heap space
[15:23] <patdk-lap> and mmap
[15:23] <sdeziel> right but that's not part of the gap
[15:23] <patdk-lap> outside of that, nothing is allocated to physical or swapped ram
[15:23] <sdeziel> or is it? Is there actually a gap or can the stack and heap grow till they meet? Causing explosion
[15:24] <patdk-lap>  heh?
[15:24]  * sdeziel vaguely remembers stackclash
[15:24] <patdk-lap> of course they can grow till they meet
[15:24] <blackflow> sdeziel: ah yes, these days it's all in virtual address space only
[15:24] <patdk-lap> when all the virtual address space is used up
[15:24] <patdk-lap> the kernel will allocate physical and swap memory to back those pages
[15:25] <patdk-lap> if there isn't enough swap space, then it will blow up sooner
[15:25] <blackflow> sdeziel: they could meet in the past, there was a CVE about it, forgot the details. but iirc kernel now protects against that.
[15:26] <sdeziel> https://access.redhat.com/security/vulnerabilities/stackguard
[15:26] <blackflow> ah yes, the stack clash, you said it.
[16:27] <jamespage> coreycb: apologies - dpdk things blew out my morning today - I'll endeavour todo some of the dep updates for train m1 tomorrow
[16:48] <coreycb> jamespage: no problem at all, i'm going to focus on it this afternoon and see what deps i can get through.
[19:08] <ahasenack> rafaeldtinoco: ok, so, sponsoring
[19:09] <rafaeldtinoco> ahasenack: tks, NOW ill finally cherry-pick iproute2 patches for cosmic and disco then.
[19:10] <rafaeldtinoco> ahasenack: do I have to ping someone for the missing +1s on the review ?
[19:10] <rafaeldtinoco> (server team / etc)
[19:10] <rafaeldtinoco> or just let it hang in there
[19:10] <ahasenack> rafaeldtinoco: no, one is enough from our team
[19:10] <ahasenack> and I can sponsor
[19:11] <ahasenack> ahasenack: we usually just do a final check, like the bank asks you to ack sometihng on the phone loud and clear
[19:11] <ahasenack> rafaeldtinoco: rather
[19:11] <ahasenack> rafaeldtinoco: so, ok for having 96b1b4a6b461effe47a19d5d62d9f0e9825e9fcb sponsored?
[19:11] <rafaeldtinoco> ahasenack: +1
[19:12] <ahasenack> ok
[19:12] <ahasenack> rafaeldtinoco: two things I'll do then
[19:12] <ahasenack> rafaeldtinoco: one is push the upload tag, which marks the commit has corresponding to the dput I'll do right after
[19:12] <ahasenack> rafaeldtinoco: and second is the actual dput
[19:13] <ahasenack> rafaeldtinoco: that will upload the package to eoan-proposed, where it will go through what we call migration checks
[19:13] <ahasenack> rafaeldtinoco: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[19:13] <ahasenack> rafaeldtinoco: it may take a while to show up there after the upload, but I'd ask you to do what we call "follow its migration"
[19:13] <ahasenack> i.e., keep an eye there to see if it passes the tests and actually lands in the archive
[19:13] <rafaeldtinoco> will do
[19:17] <ahasenack> rafaeldtinoco: that page refreshes about twice an hour, it's a bit irregular
[19:19] <rafaeldtinoco> good to know
[19:23] <ahasenack> rafaeldtinoco: it's currently building: https://launchpad.net/ubuntu/+source/iproute2/4.18.0-1ubuntu3
[19:23] <ahasenack> a good hint that it migrated, and usually comes way before the excuses page updates, is the email from lp saying the bug was closed, since it's mentioned in d/changelog
[19:24] <rafaeldtinoco> ok
[19:30] <ahasenack> rafaeldtinoco: you can now also move the card to "external dependency", signaling we now have to wait for this external process
[19:30] <rafaeldtinoco> ahasenack: done
[19:30] <ahasenack> and I just assigned it to you, that was missing
[19:30] <rafaeldtinoco> hum. maybe others are missing that too, /me review
[19:39] <rafaeldtinoco> ahasenack: disco and cosmic are good also
[19:40] <rafaeldtinoco> ahasenack: are we waiting for full verification on eoan ?
[19:40] <ahasenack> ok, let's wait for eoan to migrate
[19:40] <ahasenack> yep
[19:40] <rafaeldtinoco> ok
[19:50] <cncr04s> my grub won't boot from my mdadm array anymore
[19:51] <cncr04s> some recent update broke it
[19:51] <cncr04s> its an imsm array
[20:01] <rafaeldtinoco> ahasenack: alright. so after dput to -proposed, and update_excuses are good, how does it get to -updates ?
[20:02] <rafaeldtinoco> (in ccase this was an actual sru)
[20:02] <ahasenack> rafaeldtinoco: for eoan there is no -updates yet, so it will just move to where it should be
[20:02] <rafaeldtinoco> yep
[20:02] <ahasenack> main or universe
[20:02] <rafaeldtinoco> ah gotcha
[20:02] <ahasenack> for srus,
[20:02] <ahasenack> the upload to proposed will be in an unapproved state
[20:02] <ahasenack> until a member of the sru team gets to it
[20:02] <rafaeldtinoco> ah i know where that is
[20:03] <rafaeldtinoco> all makes sense now
[20:03] <ahasenack> if it's accepted, then this person will move it to -proposed, lp will get that standard comment about it having been accepted and asking for help testing it, etc
[20:03] <ahasenack> we also have to check the excuses page for that particular ubuntu release, to see if dep8 tests failed
[20:04] <ahasenack> if there are failures, they need to be investigated, and either justified in the bug with a comment, or fixed in a subsequent upload
[20:04] <rafaeldtinoco> ok
[20:05] <ahasenack> rafaeldtinoco: the per-release excuses page is like this: https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
[20:05] <ahasenack> replace "bionic" with your release of choice
[20:05] <rafaeldtinoco> ok, saving bookmarks
[20:05] <ahasenack> yep
[20:39] <Soni> what are alternatives to lighttpd that will fit a shitbox VPS? 1 core, 256 MB of RAM, 10 GB of disk, etc
[20:40] <Soni> I don't like the configs, I have the same block copypasted 5 times, once for each subdomain, and I wanna add a blog to it.
[20:45] <OerHeks> a blog on a vps, interesting
[20:48] <ploxiln> Soni: I use nginx a lot, it's also very efficient ... it's pretty popular so you may have already considered it
[20:49] <ploxiln> there's an "nginx-light" package with a reduced set of features enabled
[20:49] <Soni> but how hard is it to configure?
[20:49] <ploxiln> I suppose it takes some getting used to, but it can be very concise to just serve some files or just proxy. fcgi requires a separate helper like spawn-fcgi
[20:51] <ploxiln> https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/
[20:52] <sdeziel> Soni: I'd advise sticking to nginx-core which is an Ubuntu specific flavor that mirrors upstream default plugin selection, that's the one in 'main'
[20:52] <sdeziel> Soni: with that version, you get a handful of plugins that you can disable to reduce the RAM usage. Those plugins are for TCP and mail proxying
[20:57] <sdeziel> Soni: with those plugins removed, my TLS/HTTP 2.0 nginx on 18.04 takes only 5.5M of RAM ;)
[21:06] <Soni> maybe I should just use thttpd
[21:13] <Soni> hm
[21:14] <Soni> it's really hard to fit a blog engine into a shitbox VPS apparently
[21:15] <sdeziel> Soni: if 5.5M of RAM is too much for you, then yeah, you'd need to use something != nginx
[21:15] <Soni> does nginx have some plugin to turn an atom feed into an HTML blog?
[21:15] <sdeziel> Soni: the biggest RAM consumers are often the DB engine and PHP depending on your blog
[21:15] <Soni> so I edit the .atom and it changes the blog automatically?
[21:17] <sdeziel> Soni: not sure that is what you are looking for but I found this : https://ef.gy/serving-an-atom-bundle
[21:21] <Soni> okay, let's see if I can make any sense of this stuff
[21:21] <Soni> first, how do I clean the package cache?
[21:22] <Soni> actually hm is it safe to just remove everything in /var/cache?
[21:33] <sdeziel> apt-get clean
[21:33] <sdeziel> Soni: this should reclaim some space
[21:34] <Soni> sdeziel: that's only for apt tho, I have stuff like the webserver as well
[21:35] <sdeziel> Soni: I don't know your server but I'd recommend to tread carefully, rm -rf can hose a server pretty quickly ;)
[21:35] <Soni> sdeziel: so can certbot. doesn't stop me from using it.
[21:36] <sdeziel> Soni: I find dehydrated less intrusive but I guess it's a question of personal taste
[21:38] <Soni> hm I wish I knew about that before setting up certbot
[21:39] <Soni> would probably be lighter on disk usage as well
[21:41] <sdeziel> dehydrated only deps are bash and curl IIRC
[21:42] <Soni> anyway, any tool to clean up /var/cache?
[21:49] <OerHeks> !info Polipo


[02:21] <holstein> quickard: OH
[02:22] <holstein> whats up?
[02:22] <holstein> i just noticed the 03:20 [freenode] quickard<EMAIL_ADDRESS>requested CTCP VERSION from holstein:
[02:22] <holstein> and found it rude
[02:22] <holstein> are you there?
[02:25] <quickard> yes sorry
[02:25] <quickard> I didnt mean to version you
[02:26] <holstein> yeah?
[02:30] <holstein> AH.. no worries


[01:58] <[Kid]> thumper, so that i can put the master and worker roles on it, but when i thought this through, i think that i can just put the master constraint on the machine level and then in the application level point the to: to the "master" nodes
[10:28] <akshay__> Hi All
[10:28] <akshay__> Do we have python api's equivalent to juju cli's?
[10:29] <akshay__> I am looking for a python api equivalent to "juju status - -format json"
[11:07] <zeestrat> akshay__: have you checked out https://github.com/juju/python-libjuju ?
[20:29] <bdx> can I specify juju 2.3 storage in a bundle?


[01:39] <SCBEllard> Hello all!
[01:40] <SCBEllard> Sorry I missed the meeting. Does anyone know where there are logs of the meeting?
[01:42] <pleia2> SCBEllard: looks like no one has put them up on the agenda page yet, but you can always find logs at irclogs.ubuntu.com, let me get you the exact link for the last meeting...
[01:44] <pleia2> https://irclogs.ubuntu.com/2016/10/31/%23ubuntu-us-ca.html
[01:44] <darthrobot> Title: [/srv/irclogs.ubuntu.com/2016/10/31/#ubuntu-us-ca.txt]
[01:44] <pleia2> ^^ there you go :)
[05:43] <tusharsonawane> Hello
[05:43] <tusharsonawane> Anybody there
[05:43] <tusharsonawane> I want some help
[05:46] <lynorian> argh I started typing and then they quit


[00:07] <Unit193> bluesabre: It's really not much, but someone was interested in taking up the hamster plugins in Debian so I asked about the xfce plugin.  He wasn't didn't know about it so I linked the git repo in case he wanted it (and since I'm the only one to commit, gave full permission to remove me/change license and everything.)
[00:08] <bluesabre> Alrighty, that seems reasonable to me
[00:10] <Unit193> I know we're not interested in it, but hey it's Xfce!
[00:10] <Unit193> Seems no movement on sn-plugin though, which is quite sad.
[00:11] <Unit193> At the same time, I haven't poked anyone since a newer version may be coming which would be quite a bit better.
[00:13] <bluesabre> Yeah
[00:18] <ninetls> Unit193: better in memory leakages!
[00:18] <ninetls> I still don't understand why doest it leak
[00:19] <Unit193> ninetls: That, the ctrl+click thing, and most important: no 1x1 px icons. :P
[04:21] <immaBear> hello?
[04:24] <Unit193> Howdy.
[04:25] <immaBear> How's it going? this is my first time here. I was thinking about contributing to Xubuntu, this was the first thing the docs hit :)
[04:27] <Unit193> Yeah we're pretty IRC centric, though you won't generally find too many of us around at this hour.  Great!  Where are you interested in contributing?
[04:32] <immaBear> gotcha. Well I've been doing web development mostly & I notice you guys have some tickets for the website, so I was thinking about that. But I've been trying to kind of branch out my development skills more, so maybe some of the bug tickets?
[04:34] <immaBear> This would be my first contribution to an open source project, so I'm kind of new to this.
[04:35] <immaBear> (I got my CS degree a few years ago, went straight into web development. Kind of looking for "non-web" type of things if that's available.)
[04:45] <Unit193> Aha, OK!  So yes a lot of what makes Xubuntu itself are Xfce packages, which we pull from upstream.  As far as our own packages, we basically have mugshot, catfish, menulibre, lightdm-gtk-greeter(-settings), and maybe some other(s) that I'm not remembering.
[04:45] <Unit193> We have blueprints linked off of the dev site, but so far this has been a pretty relaxed cycle.
[04:51] <immaBear> Ok, sounds cool :) I'm currently reading through the Contributor Documentation, so I will check out those packages & blueprints once I finish reading that :)
[04:52] <immaBear> I need to go to bed soon, so I may not finish reading the contributor docs til the next few days.
[04:52] <Unit193> Also, while most of us idle here, you may need to wait quite a while for answers sometimes (people work, sleep, etc.) :)
[04:52] <Unit193> OK, sounds fair.
[04:54] <immaBear> ok that's totally fine, I have all those things as well so I understand 100% :)
[04:56] <Unit193> Some people see a chat window and seem to think someone will respond within 5 minutes, just making sure.  And the blueprints are all linked under https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-a-roadmap
[04:59] <immaBear> cool, bookmarked :)
[05:00] <immaBear> I should probably hop off & get to bed now though. But thanks for the info, I really appreciate it! :)
[05:01] <Unit193> Sure thing, g'night!
[05:01] <immaBear> night! :)
[05:02] <Unit193><EMAIL_ADDRESS>that's why it's useful to set the maintainer as Xubuntu Devs. :3
[06:22] <flocculant> Unit193: ack
[06:26] <Unit193> Won't yet though, bindings aren't there.
[06:26] <flocculant> :)
[09:29] <Unit193> bluesabre: ...Miiight work better if we sub ubuntu-sponsors. :P
[09:31] <bluesabre> Unit193: was pretty sure I had
[09:31] <Unit193> (Still) not showing up on the sponsoring page.
[09:32] <bluesabre> Yeah, they're definitely not subbed now
[09:33] <bluesabre> Subbed
[09:33] <bluesabre> (probably again)
[09:33] <Unit193> :/
[09:54] <Unit193> onboard stuff still pending in x-d-s, but don't think that counts as FF, more UIF.
[10:24] <bluesabre> oh yeah
[10:25] <bluesabre> Feel free to upload
[18:31] <sorinello> Hello guys. I have 2 lenovo Thinkpad laptops, and the Power Settings, more exactly dimming/turning off the display after a certain amount of time does not work. Any idea on how to debug this ?
[23:37] <Unit193> Are there any specific Xfce updates we want to get in?
[23:42] <ochosi> depends on whether the new pulseaudio plugin will be ready
[23:42] <ochosi> or the statusnotifier plugin
[23:43] <Unit193> pa-plug isn't merged to master, sn-plug we're trying but not seen much movement.  Only other one might be garcon.
[23:43] <ochosi> as a test to replace the indicator-plugin
[23:44] <ochosi> garcon has an issue with icon sizes where there is a patch, but so far eric_the_idiot hasn't merged it
[23:44] <Unit193> (https://bugs.launchpad.net/ubuntu/+bug/1709733)
[23:48]  * ninetls is keeping sn-plugin launched via valgrind trying to find memory leaks


[19:06] <pleia2> knome: you about?
[19:06] <pleia2> I need a line-art version of the xubuntu logo
[19:07] <knome> by when
[19:07] <pleia2> 5 minutes
[19:07] <pleia2> :D
[19:07] <knome> fsst
[19:07] <knome> can't do in that timeframe
[19:07] <knome> maybe by tomorrow? :P
[19:07] <pleia2> alright
[19:07] <knome> for what do you need it anyway? the eggbot?
[19:07] <pleia2> yeah :)
[19:07] <knome> hah
[19:08] <knome> are you going to do something with it that you're going to present somewhere?
[19:08] <knome> or just for fun?
[19:08] <pleia2> just for fun, I'll blog about it and probably give people xubuntu ping pong balls ;)
[19:08] <knome> lol
[19:09] <knome> ok, i'll create that for you today or tomorrow :)
[19:09] <knome> so, probably in the next 28 hours
[19:09] <pleia2> thanks!
[19:09] <pleia2> http://www.flickr.com/photos/pleia2/7663611124/
[19:09] <pleia2> early experiment
[19:09] <knome> probably not going to boot the desktop machine today, and we have guests coming in tomorrow night so i don't know when i have time tomorrow
[19:10] <pleia2> it's not exactly round ;) still working on alignment
[19:10] <knome> lol,k
[19:14] <Unit193> You said "line-art" and I'm thinking ascii art. :P
[19:16] <elfy> looks like great fun
[21:11] <mr_pouit> micahg: hey, could you sync orage when you have some time? (syncpackage looks broken in sid right now :)
[21:18] <GridCube> pleia2, :P http://imagebin.org/222429
[21:28] <mr_pouit> uploaded shimmer-themes with new bluebird/greybird/albatross to quantal
[21:28] <knome> \o/
[21:28] <knome> thanks mr_pouit
[21:28] <knome> i owe you some rum
[21:29] <mr_pouit> knome: don't rejoice too much, ochosi is in vacation, so bug reports will be for you :P
[21:29]  * mr_pouit runs
[21:29] <knome> hah
[21:30] <knome> that's fine. i'll make satya make the corrections, and let *you* reupload the packages
[21:30] <mr_pouit> works for me (:
[21:30] <knome> good
[21:31] <knome> still want that rum, or should i rejoice of it myself? d:
[21:35] <mr_pouit> hihi
[22:12] <pleia2> GridCube: have as svg? :)
[22:17] <GridCube> :P not really no, i just made it up from the logo on xubuntu.org using edge detection
[22:30] <Morroque> Edge detection? Into SVG?
[22:30] <Morroque> What program did you use for that?
[22:33] <GridCube> irfanview, but i made an svg pleia2 :D
[22:33] <GridCube> it was easier than i though
[22:34] <GridCube> well... actually an odg :/
[22:49] <knome> eh
[22:49] <knome> i already posted the xubuntu logo lineart
[22:49] <knome> and no need to use edge detection
[22:49] <knome> easy enough with inkscape to just modify the original svg
[22:49] <GridCube> :P