[14:55] <ntemis> hi
[14:57] <tgardner> smb, did you run out of interest before reviewing Dapper CVE-2010-3880 ?
[14:57] <ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
[14:58] <ntemis> my ethernet adapte supports jumbo frames but the driver dodnt let me go beyond 7k
[14:58] <smb> No, I stumbled over the openvz fixup (which is attributed wrongly it seems) and then forgot about it.
[14:58] <ntemis> it can do 9k
[14:58] <ntemis> rlt 8111E
[14:58] <smb> tgardner, No, I stumbled over the openvz fixup (which is attributed wrongly it seems) and then forgot about it.
[14:58] <ntemis> in latest 2.6.35-25-server on x86_64
[14:59] <ntemis> the kernel loaded 8169 driver
[14:59] <smb> tgardner, Let me go back and do the Dapper one, but I think you should untangle the fix for openvz. (I'd probably do a separate patch anyway)
[15:00] <ntemis> it should be 8168
[15:00] <smb> tgardner, btw, when apw looked at it he noted that it seems to not only move it but the file modified had changed too.
[15:00] <ntemis> i searched realtek site and they have a proper driver there
[15:01] <ntemis> r8168-8.021.00.tar
[15:01] <tgardner> smb, hmm, I can't see anything wrong with it. maybe I'm just dyslexic this morning.
[15:01] <ntemis> can you please include it in a natty kernel?
[15:02] <apw> ntemis, we are unlikely to pull in one of their tarball drivers if we have good support from an in kernel driver
[15:03] <apw> already ... those drivers are often very nasty to debug and harder to maintain
[15:03] <smb> tgardner, Ah, no. I guess he might have been misled by kernel/net.. and net/...
[15:03] <ntemis> http://<IP_ADDRESS>/products/productsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&ProdID=239
[15:03] <ntemis> this is the ifo for the card
[15:03] <ntemis> LINUX driver for kernel 2.6.x and 2.4.x (Support x86 and x64)
[15:03] <ntemis> 	8.021.00	2011/1/27	56k
[15:04] <smb> tgardner, The main issue is that the fixup is not required by your change/cve but was required by his. So the fixup would now be attributed to the wrong cve
[15:04] <ntemis> apw: why is using the 8169 driver? the manufacturer produce a 8168 driver for it
[15:05] <apw> because the upstream driver claims that device, thus are claiming to support it
[15:05] <apw> and indeed your own report here is that it does at least for frames up to a cirtain size right?
[15:06] <ntemis> yes
[15:06] <tgardner> smb, you're referring to the openvz patch?
[15:06] <ntemis> Supports jumbo frame to 9K bytes
[15:06] <ntemis> see features
[15:07] <ntemis> current driver only 7k
[15:07] <smb> tgardner, Yes, that additional line (setting that variable to zero) was part of a previous cve. (apparently someone did not do a complete test-build ;-)). You just stumbled over it when trying your build.
[15:07] <ntemis> and also i loose the connection every now and then on the server
[15:07] <ntemis> random disconnection
[15:07] <ntemis> no ssh at all
[15:07] <ntemis> i have to restart the server
[15:08] <apw> ntemis, the former i don't expect is very important, the second is an issue indeed
[15:08] <apw> realtek have not tried to make our lives easy by just dumpiing out tarballs for every driver
[15:08] <apw> they are not easy to intregrate, maintain, or debug ... we are therefore very resistant to pull them in
[15:09] <ntemis> :)
[15:09] <ntemis> so what now?
[15:09] <apw> i would recommend trying the latest natty kernel to see if the random dropouts are there too
[15:09] <ntemis> i have to binutils and linux tree and install the realtek ones?
[15:10] <ntemis> can i use the generic 2.3.37 stable kernel for natty on my server?
[15:10] <apw> ntemis, have you any reason to think they are working any better
[15:11] <ntemis> they are the manuf drivers :) ;)
[15:11] <apw> no comment
[15:11] <ntemis> dont know untill tested
[15:11] <ntemis> lol
[15:11] <ntemis> o.k
[15:11] <ntemis> can i use the 2.6.37 generic kernel in this server?
[15:12] <ntemis> the one in ppa
[15:12] <apw> there is no support for the mainline kernels, so they are probabally not recommended for long term use; they are intended for debugging
[15:12] <ntemis> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-natty/
[15:13] <ntemis> this will fuction ok on a 10.10 release?
[15:13] <sconklin> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579276
[15:13] <ubot2> Launchpad bug 579276 in linux "Lost network in KVM VM / virtio_net page allocation failure" [Medium,Triaged]
[15:13] <apw> ntemis, it may, it has no ubuntu sauce, so it may have trouble
[15:14] <ntemis> i just want to be able to use my server , now i have to force shutdown from power every now and then
[15:15] <ntemis> olny way to comunicate is from that eth0
[15:17] <ntemis> one final question apw
[15:17] <ntemis> apw: is the v2.6.37-natty kernel includes drivers for the nic's or i have to load them manually
[15:18] <apw> ntemis, as i say i would recommended testing with a latest natty kernel to see if that is fixed, helps us find fixed
[15:18] <apw> ntemis, i would say it has the same drivers as previous versions so should support the same cards
[15:18] <ntemis> you mean go for 2.6.38 rc?
[15:19] <apw> ntemis, i would myself, i would pick the natty kerenl as it has the ubuntu sauce and is more likely to work with your userspace
[15:20] <ntemis> am seeing this: v2.6.37-rc2-maverick/
[15:20] <ntemis> what do you think?
[15:20] <ntemis> or this:	v2.6.38-rc3-natty
[15:20] <apw> i personally wouldn't run any of the kernel-ppa ones in a production env for very long, i would go for a full 2.6.37 without -rc if wanting 27, but again there are 27 based natty kerenls, i would use those
[15:21] <ntemis> thanks
[15:39] <tgardner> smb, so back to the Hardy review for Hardy CVE-2010-3880. Are you thinking the extra cruft should be folded back into the patch for CVE-2010-3876 (which is where it appears to have come from) ?
[15:39] <ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
[15:39] <ubot2> tgardner: net/packet/af_packet.c in the Linux kernel before 2.6.37-rc2 does not properly initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory by leveraging the CAP_NET_RAW capability to read copies of the applicable structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3876)
[15:40] <smb> tgardner, I probably would suggest the lazy mode. Which is split it off as separate patch and add references to 3876.
[15:41] <tgardner> smb, OK, I'll get to it in a bit.
[15:47] <apw> sforshee, can hear but not reply at the moment
[15:48] <apw> running strace on X to ensure you got the command right for someone, is a _really_ stupid idea
[15:55] <ntemis> apw: you here?
[15:56] <apw> ntemis, s'up
[15:56] <ntemis> i installed 2.6.37 natty
[15:56] <ntemis> 64bit
[15:56] <ntemis> all ok
[15:56] <apw> ok so upstream has fixed something then
[15:57] <ntemis> dont know yet
[15:57] <ntemis> i will leave it on for a few days
[15:57] <apw> ok
[15:57] <ntemis> if it looses connection is a negative
[15:57] <ntemis> am gonna try jumbo frames on this one to see any dif
[16:00] <ntemis> nope
[16:00] <ntemis> same output
[16:00] <ntemis> SIOCSIFMTU: Invalid argument
[16:01] <ntemis> am stuck at 1500 mtu
[16:01] <ntemis> for now :)
[16:01] <ntemis> i hope 11.04 is the sweet spot
[16:04] <ntemis> all survive the update nfs server samba etc
[16:07] <ntemis> hmmm....
[16:07] <ntemis> server is faster on this kernel!
[16:07] <ntemis> is it a placebo?
[16:08] <apw> ntemis, depends what you are using it for, there are changes in there to make it more responsive
[16:08] <ntemis> it is more responsive!
[16:09] <ntemis> CPU usage 	27% user, 4% kernel, 52% IO, 18% idle
[16:09] <ntemis> and responsive as hell
[16:09] <ntemis> a job welldone!
[16:10] <ntemis> Real memory 	3.87 GB total, 498.02 MB used
[16:10] <ntemis> my god!
[16:10] <ntemis> thanks guys
[16:10] <ntemis> 2.6.37 rocks
[17:04] <ogra> tgardner-afk, the plan for OMAP4 was that we have an installable .deb of .38 in the archive so people can install and test it, we wont build images with that
[17:04] <ogra> tgardner-afk, for *images* we need display, which is why i insisted to have it ready asap, a .deb and branch would be fine earlier
[17:06] <bjf> ogra, so the OMAP4 flavour (non-display) that is built from main, will that be an officially supported flavour ?
[17:06] <ogra> bjf, that will become the natty kernel, once the missing features are in
[17:07] <ogra> and yes, omap4 is an officially supported platform
[17:07] <ogra> (since maverick)
[17:08] <bjf> ogra, i'm trying to ask (poorly i know) will there be two supported Natty OMAP4 kernels, one built from the master branch (2.6.38) and one built from the ti-omap4 topic branch ?
[17:08] <ogra> no
[17:08] <ogra> the actual plan is that we get a working .38 kernel before kernel freeze
[17:09] <bjf> ogra, and if that doesn't happen ?
[17:09] <ogra> the prob is that .38 is not yet feature complete so we need .35 for images until thats done
[17:09] <ogra> bjf, if that doesnt happen people will be killed i guess :)
[17:09] <ogra> or something similar will happen
[17:10] <bjf> ogra, sounds like a plan ! :-)
[17:51] <JFo> <-need more coffee, brb
[18:08] <rigved> hi everyone...i created a initramfs for 2.6.32-28, which i had built eariler (following Linux Kernel in a Nutshell guide). when i try to boot into this in qemu, i get the error - unable to find udev. can anyone tell me what i'm doing wrong here
[18:09] <apw> rigved, how did you make it?
[18:09] <rigved> apw: you mean the initramfs?
[18:09] <apw> rigved, yes
[18:10] <rigved> apw: using mkintramfs
[18:10] <rigved> apw: wait, i'll tell you the exact command
[18:13] <rigved> apw: sudo mkinitramfs -f -o /boot/initrd.img-<IP_ADDRESS> -v <IP_ADDRESS>
[18:14] <jjohansen> rigved: try sudo update-initramfs -c -k <IP_ADDRESS>
[18:14] <rigved> jjohansen: ok. wait, i'll give it a try
[18:15] <jjohansen> rigved: you will also want to run update-grub after that so that grub knows about the new kernel
[18:16] <psurbhi> smb, ping
[18:16] <rigved> jjohansen: ya i had done that...i booted into the new kernel also...it showed me the Ubuntu 10.04 booting screen...with the dots...then it gave me this error and dropped me to a initramfs shell
[18:17] <tgardner> ogra, whats your call on the minimal ti-omap4 kernel for Natty? Is there any reason folks couldn't use the Linaro kernel until TI can get graphics in shape?
[18:18] <smb> psurbhi, hey, though I currently got only one eye and hand free
[18:19] <psurbhi> smb, what happened?
[18:19] <smb> psurbhi, I am on the phone :)
[18:19] <psurbhi> heh
[18:19] <psurbhi> i will wait for u
[18:21] <rigved> jjohansen: so when i run this command it generated the image, but it couldn't find any files under /lib/modules/<IP_ADDRESS>/ in the guide it said to put the built kernel in a test folder.
[18:22] <jjohansen> rigved: how did you build your kernel and how did you install it
[18:24] <rigved> jjohansen: make O=~/linux/linux-<IP_ADDRESS>/ menuconfig.
[18:24] <ogra> tgardner, see above :)
[18:24] <rigved> jjohansen: then make modules_install.
 tgardner-afk, the plan for OMAP4 was that we have an installable .deb of .38 in the archive so people can install and test it, we wont build images with that
 tgardner-afk, for *images* we need display, which is why i insisted to have it ready asap, a .deb and branch would be fine earlier
[18:24] <rigved> jjohansen: then make O=~/linux/linux-<IP_ADDRESS>/ ARCH=i386.
[18:25] <rigved> jjohansen: sorry that's make O=~/linux/linux-<IP_ADDRESS>/ ARCH=i386 install
[18:25] <ogra> tgardner, we should have a kernel in the archive asap so we can see whats broken in TIs tree and track the progress, while it is currently starting off from mainline i expect many patches that are pre-promoted in that tree before they hit upstream
[18:26] <tgardner> ogra, so, you're willing to suffer the regression of no GUI for awhile? I'm not really interested in managing 2 ti-omap4 packages.
[18:26] <ogra> well, no
[18:26] <ogra> we need .35 for finishing off the GUI work on unity-2d
[18:26] <ogra> i dont expect any changes to .35
[18:26] <ogra> none at all
[18:27] <ogra> just leave it rot and lets care for .38
[18:27] <rigved> jjohansen: sorry again. i had typed sudo for the last two commands
[18:27] <tgardner> ogra, so, you want me to carry yet another kernel _and_ meta package for Natty? Or can folks just use the Maverick kernel after I pull 2.6.38 into the Natty ti-omap4 branch?
[18:28] <ogra> hmm, no, it needs a different name indeed
[18:28] <ogra> we dont need a meta
[18:28] <ogra> just a binary
[18:28] <jjohansen> rigved: so the make install, make modules install should have put a kernel image in /boot/ and installed the modules in /lib/modules/
[18:29] <jjohansen> rigved: so what do you have under /lib/modules/
[18:29] <rsalveti> problem is that we want a new kernel but still need to use the older one to generate images
[18:29] <ogra> tgardner, we still need meta and .35 for images
[18:29] <ogra> but threre wont be changes to it
[18:30] <tgardner> ogra, could we get by with building the development kernel in a PPA ?
[18:30] <apw> why can't the new kernel hang out in a PPA until its ready
[18:30] <rigved> jjohansen: there are quite some files in /lib/modules/<IP_ADDRESS>/
[18:30] <ogra> worst case that would suffice, yep
[18:30] <rigved> jjohansen: i'm going to try to boot into qemu using the new initrd-img
[18:30] <jjohansen> rigved: err I thought you said that lib /lib/modules/<IP_ADDRESS>/ was missing
[18:31] <rigved> jjohansen: that's what update-initramfs said. but there are files under it
[18:32] <apw> its not even clear we need it in a PPA, we do most testing with hand rolled .debs anyhow
[18:33] <jjohansen> rigved: oh, okay I didn't realize it was only update-initramfs that was having the problem with that
[18:34] <apw> ogra, its not even clear we need it in a PPA, we do most testing with hand rolled .debs anyhow
[18:34] <jjohansen> rigved: maybe try update-initramfs -u -k all
[18:35] <JFo> <- grabbing a bite to eat, back son
[18:35] <JFo> soon*
[18:36] <rigved> jjohansen: so in virtualbox i get a different error: ALERT! /dev/disk/by-uuid/blah blah blah does not exist. Dropping to shell. then i have a initramfs shell (busybox)
[18:36] <rigved> jjohansen: now i'll try qemu
[18:36] <rigved> jjohansen: then i'll try the other command which you gave
[18:36] <ogra> apw, we want a .deb available asap, i dont care at all where we pull it from (it would be cooler to have it in the archive but indeed i dont want to add extra work for you guys)
[18:37] <apw> ogra, so do we have a tree yet?
[18:37] <tgardner> apw, ogra: we could do this in the pre-proposed PPA perhaps.
[18:37] <apw> tgardner, if its arm does it need to be a de-virt one yet ?
[18:37] <apw> still ?
[18:37] <ogra> yes
[18:37] <tgardner> apw, uh, you might be right
[18:38] <ogra> until we get the pandas that are ordered since Nov.
[18:38] <tgardner> apw, we only have one de-virt PPA, right?
[18:38] <apw> yeah, and i'd say for this use case a cross-build is as good
[18:38] <apw> so the main blocker is having a tree to make it out of
[18:38] <tgardner> apw, well, we could carry a dev branch for awhile.
[18:39] <rigved> jjohansen: same error in qemu.
[18:39] <rigved> jjohansen: now i'll try the other command
[18:39] <apw> tgardner, yeah i recon keep it in a separate branch but internally thinking its ti-omap4 until its ready, in the main repo
[18:39] <ogra> apw, cross isnt an option
[18:39] <apw> then we can just shove it over the top
[18:39] <apw> ogra, why not?
[18:39] <tgardner> apw, my thoughts exactly
[18:39] <ogra> we need the same thing we will get from the builders else testing is moot
[18:40] <bryceh> [ 4635.189079] exe (9084): /proc/9084/oom_adj is deprecated, please use /proc/9084/oom_score_adj instead.
[18:40] <apw> ogra, define the same ?
[18:40] <bryceh> ^^ does such an error message indicate the oom handler got called?
[18:40] <apw> its built witht he same compilers, just the cross versions
[18:40] <ogra> note that we also want to be sure the toolchain dtrt etc
[18:40] <apw> you normally test cross built ones
[18:40] <psurbhi> smb, i am pushng off for dinner ... its very late in here.. wanted to discuss bug 709392
[18:40] <ubot2> Launchpad bug 709392 in nfs-utils "NFS client does not submit "nfs_file_sync" write requests when the file open call includes O_SYNC." [High,Triaged] https://launchpad.net/bugs/709392
[18:40] <psurbhi> maybe  tomorrow
[18:40] <ogra> hmpf
[18:40] <psurbhi> see you around!
[18:41] <tgardner> apw, ogra: we can use the c-k-t PPA for Natty. It won't collide with anything going on right now. This should all resolve itslef by mid April
[18:41] <apw> tgardner, yep fine with me
[18:41] <ogra> tgardner, that sounds good
[18:41] <tgardner> ok, resolved.
[18:41] <apw> well other than the lack of a tree to package right ?
[18:41] <ogra> i'm really more confident in natively built packages, sorry for being so stuck in that
[18:42] <tgardner> ogra, I'll respond to Sebastien and Nicholas
[18:42] <ogra> thanks, i seem to have a mail prob i just tried to send an answer
[18:42] <apw> ogra, you are right at the end of the process you can't say its deffo good unless its native
[18:43] <apw> ogra, for the majority of the builds before that i recon you are fine, and you save 6 hours a cycle
[18:43] <ogra> i would just like to exclude all possible issues so we can see the real probs with the code
[18:43] <apw> then you pay 7 hours a spin, i'd be suicidal at that
[18:43] <ogra> and i'm sure there will be enough
[18:43] <apw> but its your life
[18:44] <ogra> we dont user that kernel on any images so 7h are fine imho
[18:44] <ogra> it doesnt block anything
[18:51] <herton> bryceh: nope, just that the process is trying to set oom_adj, it's a deprecated interface now
[18:51] <herton> for oom parameter, process should use now oom_score_adj
[18:52] <herton> Documentation/feature-removal-schedule.txt explains it better in linux source (/proc/<pid>/oom_adj section)
[18:59] <ogra> whoever is ML admin for the kernel list, please reject the duplicated mail from<EMAIL_ADDRESS>that will end up in your queue
[19:00] <ogra> (it was also sent from<EMAIL_ADDRESS>and got through the queue already)
[19:01] <tgardner> ogra, thats me
[19:01] <ogra> just throw it away please (if yuo do your admin work anyway, no need for extra action)
[19:03] <tgardner> ogra, done
[19:03] <ogra> bah, so you did extra action :P
[19:03] <ogra> thansk :)
[19:05] <bryceh> herton, thanks
[19:12]  * tgardner --> lunch
[19:23] <niemeyer> Greetings
[19:23] <niemeyer> Is there a way to *reserve* a contiguous area of virtual address space within a process, without having it interpreted as an allocation (e.g. without hitting ulimit -v problems)?
[19:30] <rigved> jjohansen: hi. i did some googling and found out that the problem is caused because the kernel is unable to mount a SATA HDD. So, in virtualbox, i changed the SATA HDD to a IDE HDD, and it worked. any idea what is happening here?
[19:33] <zul> has anyone seen this on 2.6.38 with running kpartx? http://pastebin.ubuntu.com/564033/
[19:33] <rigved> jjohansen: this is the bug report on launchpad - bug 576071
[19:33] <ubot2> Launchpad bug 576071 in ubuntu "After upgrade to Lucid /dev/disk/by-uuid missing when booting with initramfs" [Undecided,Incomplete] https://launchpad.net/bugs/576071
[19:35] <jjohansen> rigved: okay hrmm, I don't know anything atm but will take a look
[19:37] <herton> zul: looks you hit the same bug as LP#700165
[19:37] <herton> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/700165)
[19:37] <ubot2> Launchpad bug 700165 in linux "qemu-nbd kthread becomes defunct on disconnect" [High,Fix released]
[19:38] <rigved> jjohansen: i don't know what's happening exactly, i don't even understand teh bug report...but atleast now i can move forward in the kernel guide. thanks for your help. it's very late here. i'm off to sleep. good day
[19:56] <kees> smb: oh! http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f12d3d04e8f6223276abb068c5d72852174b8c31 should fix the Xen issues with RO/NX. can you re-enable that for the Xen builds?
[20:03] <niemeyer> kees: Any idea about the question above, or at least a direction I could look at?
[20:03] <niemeyer> herton: Bem vindo, btw :)
[20:03]  * kees reads backscroll
[20:03] <niemeyer> Is there a way to *reserve* a contiguous area of virtual address space within a process, without having it interpreted as an allocation (e.g. without hitting ulimit -v problems)?
[20:03] <niemeyer> kees: ^
[20:04] <kees> I'm not sure what the difference between "reserve" and "allocate" really would be.
[20:04] <kees> are you just trying to stop something from using a static range of memory?
[20:04] <herton> niemeyer: obrigado :)
[20:04] <niemeyer> kees: That's it
[20:05] <niemeyer> kees: So that in the future the page can be mapped continuously with the previous page, if necessary
[20:06] <niemeyer> kees: The trick being used now is to mmap() a big range with prot=0, and then changing the prot when it's actually needed
[20:06] <niemeyer> kees: It all works well, except that the dumb backend of ulimit -v restricts address space for no reason
[20:06] <niemeyer> (why the heck people use that)
[20:07] <kees> out of curiosity, why do you care about contiguous future memory allocation?
[20:07] <bguthro> kees / smb: I just noticed the kernel.org changeset above. Are there normally xen builds against the ubuntu kernel? If so - where could I find them?
[20:08] <kees> bguthro: the "linux-ec2" (Xen guest) is part of the normal natty kernel builds of the "linux" source package.
[20:09] <kees> niemeyer: anyway, you're only ever fighting against glibc, so you probably just want to use your own heap allocator.
[20:09] <bguthro> ah. Its a domU kernel. that makes more sense...I was hoping for the dom0 white whale
[20:09] <niemeyer> kees: It is "my own" heap allocator, actually :-) (Go's, to be more precise)
[20:10] <niemeyer> kees: The algorithm gets simpler and faster with it
[20:10] <kees> niemeyer: if you control the allocator, why do you need the reserve memory regions? you just need to not use them. :P
[20:11] <niemeyer> kees: Because other libraries have their own allocators, which will get in the way and explode the application if the area is not reserved
[20:12] <kees> niemeyer: right, I mean _replace_ the glibc allocator.
[20:13] <kees> niemeyer: so that your allocator is being used for all calls.
[20:13] <niemeyer> kees: I don't get what you mean.  Any library doing mmap() can take a page in a non-reserved space.
[20:13] <niemeyer> kees: It doesn't matter what glibc is doing
[20:13] <kees> niemeyer: ah, okay, sure. most just use malloc, though.
[20:14] <niemeyer> kees: mmap() is used for other reasons besides building the arena for malloc
[20:14] <kees> niemeyer: but anyway, I get what you're saying. I'm not aware of a way to mark mmap regions offlimits without actually allocating them.
[20:14] <niemeyer> kees: Ok, cool
[20:14] <niemeyer> kees: Do you know if there's a viable alternative to ulimit -v which doesn't hit the issue?
[20:15] <niemeyer> kees: It looks like most people doing ulimit -v are really trying to restrict swapping
[20:15] <niemeyer> kees: But the limit of virtual space is much more encompassing than this
[20:15] <kees> how much are you reserving? most sane users of ulimit -v shouldn't be setting it too low
[20:16] <kees> e.g. I use ulimit -v for local builds to make sure things like gcc and glibc testsuites don't wreck my system.
[20:16] <niemeyer> kees: A lot.. or nothing, depending on the POV :-)
[20:16] <niemeyer> kees: 16GB, for instance
[20:16] <niemeyer> It's quite a bit, but nothing taking a 64bit space in account
[20:16] <kees> O_o
[20:17] <kees> are you really growing continugous areas so frequently that you can't just use realloc?
[20:18] <bryceh> is   video=vesafb:off   the right way to disable vesafb?
[20:18] <niemeyer> kees: That doesn't work for a memory arena.. we're talking about the thing that backs malloc()
[20:18] <niemeyer> kees: realloc would mean all pointers inside the region shifting
[20:18] <niemeyer> kees: This is possible in the future, but it's a much larger problem than the one we're talking about
[20:19] <kees> niemeyer: but if it's for an arena why do you need it contiguous? can't you just have multiple arenas?
[20:20] <niemeyer> kees: Yes, that was the old implementation.. a contiguous region makes things a lot simpler and faster.
[20:21] <niemeyer> kees: E.g. 16GB is mapped with 22 bits (* page size)
[20:23]  * kees wonders if the kernel anonymous mmap routine uses greedy or "after last" allocations.
[20:23] <kees> i.e. alloc something, then alloc something 16GB later.
[20:23] <kees> will the next mmap end up in the middle, or after?
[20:26] <niemeyer> kees: Good question
[20:32] <kees> niemeyer: it works...
[20:32] <kees> wait, no
[20:32] <kees> yeah, seems to work.
[20:32] <kees> $ ./mmap
[20:32] <kees> 0x7f3b94f0c000 -> 0x7f3f94f0c000: 16384M
[20:32] <kees> 0x7f3b94f0a000: ok
[20:32] <kees> 7f3b94f11000-7f3b94f12000 rw-p 00000000 00:00 0
[20:32] <kees> 7f3f94f0c000-7f3f94f0d000 ---p 00000000 00:00 0
[20:33]  * kees attempts a larger secondary allocation....
[20:34] <niemeyer> kees: Hmm.. I don't think I get it
[20:34] <niemeyer> kees: This shows you're actually allocating 16GB, right?
[20:34] <kees> nope.
[20:34] <kees>     start = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
[20:34] <kees>     end = mmap(start + 16L*1024L*1024L*1024L, 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
[20:34] <kees>     more = mmap(NULL, 4096*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
[20:34] <kees> and more ends up below start, not above it
[20:34] <niemeyer> kees: Ahh, ok
[20:35] <niemeyer> kees: You mean below end?
[20:35] <kees> so... maybe you can use that, but I have no idea how stable it might be.
[20:35] <kees> no, 0x7f3b94f0a000 (more) is less than 0x7f3b94f0c000 (start)
[20:35] <kees> looks like it's growing the heap down.
[20:36] <kees> but this is probably all academic; there's nothing that says it won't change behavior at any moment. :P
[20:37] <niemeyer> kees: Well, hmm.. I don't think I understand why the experiment proves something useful
[20:37] <niemeyer> kees: You're allocating two pages consecutively, and they are 8k apart from each other?
[20:37] <niemeyer> >>> 0x7f3b94f0a000 - 0x7f3b94f0c000
[20:37] <niemeyer> -8192
[20:38] <kees> niemeyer: because the kernel didn't allocate anything between 0x7f3b94f0c000 and 0x7f3f94f0c000, leaving a 16GB gap
[20:39] <kees> and, ta-da, I broke it.
[20:40] <kees> niemeyer: it looks like it's just finding "best match" for anonymous mappings
[20:40] <kees> I can get it to alloc "start" below libc, and "end" after libc...
[20:40] <kees> so... nevermind! :P
[20:40] <niemeyer> I see
[20:40] <niemeyer> kees: Was a valid experiment, though
[20:40]  * kees nods
[20:41] <bryceh> JFo, bug #711568 turned out to be a kernel regression.  Upstream has committed a kernel patch, mind adding this to the kernel team's list to look at?
[20:41] <ubot2> Launchpad bug 711568 in xserver-xorg-video-intel "Dithering regression on Intel graphics with .38 Natty kernel" [Undecided,New] https://launchpad.net/bugs/711568
[20:41] <JFo> I don't mind at all bryceh :)
[20:43] <JFo> looks like apw beat me to the punch, but I went ahead and added the patch tag
[20:43] <JFo> thanks for the heads up bryceh :)
[20:44] <bryceh> sure
[20:45] <bryceh> hopefully I'll have more to come.  There's been a spate of gpu lockups lately, something must be futzed in the .38 drm still.
[20:53] <niemeyer> kees: How did you figure it wasn't deterministic?
[20:57] <kees> niemeyer: I switched start/end to use PROT_NONE, and looked at the maps file.
[20:57] <kees> niemeyer: there was all kinds of stuff between the two :(
[20:57] <niemeyer> Hmmm..
[20:57] <niemeyer> Ok
[20:58] <kees> niemeyer: http://paste.ubuntu.com/564073/
[20:58] <niemeyer> kees: Thanks
[20:59] <kees> np
[21:07] <niemeyer> kees: Hmmm
[21:07] <niemeyer> kees: That's not a definitive answer I think
[21:07] <kees> niemeyer: no, it shows it's pretty unstable.
[21:08] <niemeyer> kees: What I mean is that the compiler can choose to allocate certain libraries in fixed addresses
[21:08] <niemeyer> kees: This would affect such placement
[21:08] <kees> niemeyer: right, but that's against packaging policy (libraries must be -fPIC)
[21:09] <niemeyer> kees: Not really.. -fPIC just says the code should be relocatable
[21:09] <niemeyer> kees: It doesn't limit the freedom to put such code in a given address
[21:09] <niemeyer> kees: linker vs. compiler in this case
[21:11] <kees> niemeyer: okay, yes, that's true.
[21:12] <kees> but any pinning of objection locations would defeat the security purpose of ASLR
[21:42] <bjf> JFo, can you accept nominations on bug #714732 and bug #714846 ? thanks.
[21:42] <ubot2> Launchpad bug 714732 in linux "Maverick update to <IP_ADDRESS> stable release" [Undecided,New] https://launchpad.net/bugs/714732
[21:42] <ubot2> Launchpad bug 714846 in linux "CVE-2010-4242" [Undecided,New] https://launchpad.net/bugs/714846
[21:43] <JFo> bjf, I can indeed
[21:44] <JFo> bjf, done
[21:44] <JFo> :)
[21:44] <bjf> thanks
[21:45] <JFo> my pleasure


[08:28] <cjwatson> DalekSec: thanks, done
[08:28] <DalekSec> Odd, after I said that I went to -sysadmin and he restarted them.  Thought that made my point here moot.  Anyway, great!
[21:09] <QwertyChouskie> How can I reset an import?  Specifically https://code.launchpad.net/~stk/stk/trunk
[21:15] <QwertyChouskie> Any chance someone could take a look at https://bugs.launchpad.net/launchpad/+bug/253127 ?
[21:16] <QwertyChouskie> It's been "High" priority for almost 7 years...
[21:48] <cjwatson> I wish we had time for all our criticals, never mind all our highs :-/


[04:09] <jack_> Hi everyone.  Just checking out this program
 Welcome! :D
 Ty!
[11:24] <crydotsnake-M> Lol. Why i See my Message from Telegram Here
 It's a bridged chat :D
 Interesting..
[11:41] <RikMills> It is
 (Document) https://irc-attachments.kde.org/khB3RCfv/file_20641.mp4
[11:42] <RikMills> nice gif
 Cool
 LOL, I see what you did there 😏
[11:42] <RikMills-M> also via matrix
 Ooh, that's actually really cool. I quite like Matrix. I'll have to join!
 :D
[13:14] <BluesKaj> Howdy all
[15:23] <fmutungi> Hi. I am connected to the Internet using a mobile broadband connection. I would like to use my laptop as a hotspot so that other devices can use my Internet connection via WiFi
[15:23] <fmutungi> How would I go about doing that?
[15:24] <fmutungi> All the articles I've seen show the GNOME desktop not Plasma which is what I have.
[15:34] <Paulser> Does anyone now how to whipe or clean search as an application I have uninstalled still appears in search? Thanks for anyone that helps. Love using Kubuntu you all doing good work.


[07:37] <kjackal> Hello Juu world!
[08:51] <kjackal> admcleod_: Hey! How is it going?
[08:52] <kjackal> admcleod_: Got to play a bit with the bigtop kafka offering we have packaging. Did you use Kafka for your ML demo?
[11:02] <admcleod_> kjackal: good, we havent worked on the demo yet though
[16:10] <skay> is there a charm for celery flower? I searched, but am not getting any results on celery https://jujucharms.com/q/celery
[16:10] <skay> which seems really weird
[16:14] <lazyPower> skay - not that i'm aware of
[16:14] <skay> lazyPower: oh, okay. what do people normally use for monitoring celery stuff?
[16:15] <skay> we've got a django app that uses the old django-celery package, just to use the admin
[16:15] <lazyPower> I dont think we've got a charm that models a celery monitor. That would be a great contribution
[16:15] <skay> it's not actively developed, and the celery site recommends FLower
[16:15] <bdx> skay: I use flower
[16:15] <skay> I think that would get out of the scope of what I'm currently working on
[16:15] <skay> otherwise it would be a nice thing for me to do
[16:15] <skay> bdx: do you have a charm for it?
[16:16] <skay> lazyPower: I was hoping I could be lazy and
[16:16] <skay> remove a dependency while I'm at it!
[16:16] <skay> well, a django dependency
[16:16] <bdx> skay: I actually started up a celery charm last week ... I think flower would be a great configurable option
[16:17] <bdx> skay: I would just 'pip install flower' for the time being
[16:18] <bdx> skay: look out in the coming days/weeks for celery
[16:18] <skay> bdx: thanks
[16:18] <bdx> np
[16:24] <bdx> skay: now that I think of it, I remember what I ran into last week when looking at it
[16:25] <bdx> skay: celery is interacted with by django, it usually in your django codebase that you will import and call to celery
[16:26] <bdx> skay: as such, I figured it was just best to let celery run where the django app runs, and get installed as one of the django app deps
[16:26] <skay> bdx: aw. we are going to be deploying some non-django services
[16:26] <kwmonroe> hey lazyPower, what's your charmbox docker run --net param?  i have --net=bridge, and i thought i did that for reasons, but i can't remember them.  curious what you use.
[16:26] <skay> bdx: yeah, that is what we are doing with our django app
[16:26] <skay> roadmr: o/
[16:26] <lazyPower> kwmonroe - i've since removed that as i'm not using the 'local' provider.
[16:26] <lazyPower> kwmonroe - however, what that does is it places the container directly on the hosts networking bridge, instead of running behind a service NAT
[16:27] <roadmr> heya skay !
[16:27] <bdx> skay: yea, its just not something that is easily decoupled from the django application ... I've been on a mission to do so for a while, and the more I look at it, the more it just doesn't make sense to do so
[16:28] <bdx> skay: how are your other apps interacting with celery? from their native codebase?
[16:28] <skay> bdx: unknown yet, we are just starting to talk about moving some things out of our big django app in to smaller apps, some of which will be go
[16:29] <bdx> skay: usually calls to celery will happen from the applications code base
[16:29] <bdx> this is difficult to decouple
[16:29] <skay> bdx: before I JFDI making the actual service I want to spec out how we'll deploy in just enough detail to make sure I won't shoot us in the feet
[16:30] <skay> bdx: hmm, so I guess no charm
[16:30] <skay> or just a setting, like you said, and it can live int he same application container with whatever app
[16:30] <bdx> skay: I've charmed up a bunch of django apps that use celery
[16:30] <skay> bdx: we have one that does as well
[16:31] <skay> as I mentioned, I'd like to stop using the django admin for looking at the task queue
[16:31] <skay> I'm not sure that package is under active development (let me go find the github issue I remember)
[16:32] <kwmonroe> ack lazyPower.  that's good to know.  it explains why my charmbox network dies whenever i switch networks.  methinks natting might keep them alive.
[16:32] <Prabakaran> Hello Team, Is there any interface available @ interface.juju.solutions for apache vhost configuration?
[16:32] <lazyPower> Yeah, the only reason we did the --net=bridge was for the old local provider integration. Since we are primarily on juju2 these days, we should be able to remove that stanza from the alias and have a good time.
[16:33] <skay> https://github.com/celery/django-celery/issues/391
[16:33] <skay> and some other issues. tests failing with django 1.9, etc.
[16:34] <lazyPower> kwmonroe - at some point, in the distant future when we have -spare cycles- we should pair and hax on getting it functional with the lxd cloud, and see what that looks like
[16:34] <kwmonroe> sounds like a summit break-out
[16:34] <kwmonroe> see you in septiembre
[16:37] <bdx> skay: yea, looks like you are going to be dealing with a few different issues moving forward if you are trying to be on latest and greatest django/celery/etc/etc ..... if you want these thing to start in your direction  .... you have to be the change you want to see
[16:38] <bdx> skay: otherwise, just wait
[16:38] <skay> bdx: ha, I've got a django 1.6 app and want to get to at least LTS
[16:38] <skay> bdx: nod
[16:39] <kwmonroe> Prabakaran: i don't see anything related to vhost data currently.  it looks like the http interface only passes hostname/port.  the apache2 charm handles vhosts during it's config-changed hook (so for example, changing the apache2 port would update the defined vhost config with the new value)
[16:40] <bdx> skay: yea, I just ransacked throught a few django apps bringing them to latest and greatest, it was pretty rough to say the least
[16:40] <bdx> skay: your on the right track, map out the deps for everything, and where the different projects are at (check that the desired feature sets align)
[16:41] <lazyPower> kwmonroe - iirc the reverse proxy relation sets up a vhost, but you dont get to specify the vhost information. its a templated one shot reverse proxy config
[16:41] <lazyPower> so for example, if your hosting static assets out of s3, and want to rewrite anything in the /asset url, it doesn't currently support that.
[16:41] <bdx> skay: then just go throught and do a timeline appraisal (expected dates when critical issues/deps will be fixed)
[16:42] <lazyPower> so there's potential for a contribution there
[16:42] <bdx> skay: this will give you an overhead view of what/when/where/why/how, then you can start putting the pieces together, knowing which ones will play nice, and when, why
[16:43] <skay> bdx: nod
[16:45] <kwmonroe> yup, +1 lazyPower
[16:53] <Prabakaran> my requirment is to feed this vhost file http://pastebin.ubuntu.com/21160463/ to apache2 charm .. is it possible to do from my reactive code?  Continure with your magic juju :)
[17:40] <lazyPower> Thanks phy1729 for the quick response
[17:40] <lazyPower> appreciate the backup in case it happens again
[17:42] <aisrael> TIL: don't run `charm build` in your $HOME
[17:43] <aisrael> It doesn't do any damage, but it sure does take a long time to fail.
[17:43] <kwmonroe> lol
[17:43] <lazyPower> yuuuup
[17:43] <lazyPower> gotta love that shallow deep copy ;)
[17:43] <jcastro> balloons: tell me about this juju snap in the store
[17:43] <jcastro> can I whole hog replace the deb?
[17:43] <lazyPower> jcastro - iirc mattyw created that snap
[17:44] <jcastro> juju-nskaggs                            2.0-beta13                    nskaggs
[17:44] <jcastro> it looks brand new to me
[17:44] <mattyw> lazyPower, jcastro, I've put no juju snap in any store
[17:44] <lazyPower> ooo, ok. that was just prior work on the pi then
[17:45] <lazyPower> disregard my fallable memory
[17:45] <jcastro> yeah it's like less than a day old afaict
[17:45] <mattyw> lazyPower, I only ever built it for the pi
[17:46] <mattyw> lazyPower, I never put it in the store because there wasn't a store in those days ;)
[17:59] <kwmonroe> lazyPower: pr looks fine - want me to merge, or do you have other eyeballs on it?
[18:00] <lazyPower> go for it
[18:00] <kwmonroe> donezo
[18:20] <lazyPower> ta kwmonroe
[19:07] <kwmonroe> petevg: we're in a pickle.  the tox.ini in bigtop-base (https://github.com/juju-solutions/layer-apache-bigtop-base/pull/28) gets overridden by the base layer tox.ini.
[19:07] <kwmonroe> (https://github.com/juju-solutions/layer-basic/blob/master/tox.ini)
[19:08] <kwmonroe> this is bad petevg, because charms built with the bigtop base layer *will* get the ./tests/unit/* stuff from bigtop-base, but won't have the unit_test_reqs installed, so tox fails on all bigtop charms.
[19:08] <petevg> kwmonroe: That is bad :-/
[19:09] <petevg> kwmonroe: Do we have a way to exclude directories from being inherited in a layer?
[19:10] <kwmonroe> petevg: i think there's an ignores options.. i saw beisner mention that recently.  yo beisner, how does one use ignores in a layer?
[19:17] <kwmonroe> stand down beisner.  got it.
[19:17] <kwmonroe> petevg: pretty simple, http://paste.ubuntu.com/21178635/
[19:18] <petevg> kwmonroe: Cool. Will add it. Thx. :-)
[19:20] <petevg> kwmonroe: Just one quick question. When two layers contain a file, do you know how we handle the conflicts? I would expect layers to be able to overwrite files from a layer that they inherit from. But that would mean that layer-apache-bigtop-base's tox.ini would clobber the one from the base layer. And it sounds like the opposite is happening ...
[19:24] <kwmonroe> i agree with your expectation and observation petevg.  and i thought the layer ordering was fixed with https://github.com/juju/charm-tools/issues/218
[19:25] <petevg> kwmonroe: Interesting. Just to be safe, I think that I'm going to rename "tox.ini" to "tox-unit.ini", and add it to the ignore list.
[19:25] <petevg> We'll still be able to run tests with "tox -c tox-unit.ini"
[19:25] <kwmonroe> ah - cool petevg.  smells like a readme update too ;)
[19:26] <petevg> Just working on that now :-)
[19:27] <kwmonroe> petevg:  may want to add unit_test_reqs.txt to the ignore list while you're in there..
[19:27] <petevg> Done :-)
[19:29] <petevg> kwmonroe: Changes pushed. Going to spend some time doing some additional building/testing to make sure that things are okay, though.
[19:42] <petevg> kwmonroe: Everything looks good from my end. I can build charms, and the right stuff gets ignore from the bigtop base layer. lmk if you see any issues on your end.
[20:00] <kwmonroe> roger that petevg - thx!
[22:10] <mbruzek> ping bdx


[00:00] <ahoneybun> yep they took out wifi hotspot mhall119
[01:42] <mhall119> pd is probably pocket desktop
[01:42] <mhall119> ahoneybun: I don't think hotspot ever worked right on the Nexus 4
[01:42] <ahoneybun> it has not
[01:42] <ahoneybun> I knew they were going to remove it
[01:43] <ahoneybun> I really want to get a Nexus 7
[14:56] <Garheade> ahoneybun_: what version of nexus 7? I have a 2013 edition I might be willing to part with for the right price.
[15:14] <Garheade> Has anyone tried running Chrome on their ubuntu phone?
[15:39] <ahoneybun> Garheade: I do need the 2013 one for Ubuntu
[15:40] <ahoneybun> Garheade: I don't know of chrome on Ubuntu phone
[15:40] <ahoneybun> the ubuntu browser uses webkit thing that chrome uses
[16:05] <Garheade> ahoneybun: the n7 is currently running CM so its already unlocked. It's in really good condition but it doesn't have the original charger.
[16:06] <Garheade> 16gb/WiFi
[16:07] <Garheade> ahoneybun: I figured out the Chrome thing and it's basically a nope.
[16:07] <Garheade> as for the N7, how much are you looking to spend on it?
[19:47] <jck77> sup people!!! missed the ubuntu hour
[19:47] <jck77> :/


[07:01] <dholbach> good morning
[11:31] <trinikrono> good morning Ubuntu LoCos!
[20:26] <locodir-user> is this only a website to talk about team stuff


[00:36]  * JontheEchidna wonders where ScottK is
[00:36] <JontheEchidna> Want to show him this: http://imagebin.ca/view/fUA_BCW.html
[00:38] <Lex79> JontheEchidna: yesterday evening, jr says scottk was only in #ubuntu-women channel
[00:38] <Lex79> lol
[00:39] <JontheEchidna> lol?
[00:39] <Lex79> yeah, dunno why
[00:40] <Lex79> JontheEchidna: -*- Riddell wonders why scottk is in #ubuntu-women but not in here
[00:40] <Lex79> :)
[00:40] <JontheEchidna> hmm, seems to be only in #kde-devel and #quassel according to whois
[00:41] <JontheEchidna> maybe he's just taking a vacation from it all
[00:41] <Riddell> JontheEchidna: yes he is
[00:42] <JontheEchidna> and that's a good thing to do from time to time
[00:42] <JontheEchidna> Riddell: anywayz, I fix0r3d packagekit and it's now nicely sitting in binary new :)
[00:43] <Riddell> what needed fix0r1ng?
[00:43] <JontheEchidna> oh, it FTBFS'd in a few places
[00:45] <Riddell> fooey.  thakns
[00:46] <JontheEchidna> no prob
[01:01] <neversfelde> ha, Lex79, JontheEchidna and Riddell, I need your help :)
[01:01] <neversfelde> how do I skip dh_auto_test for debehlper in debian/rules
[01:02] <neversfelde> the manpage recommends to skip it, if it fails
[01:05] <JontheEchidna> maybe do an override on that and set it to do nothing?
[01:06] <neversfelde> JontheEchidna: how can I do this?
[01:06] <JontheEchidna> I think you do something similar in your minitube package with a few other dh things
[01:06] <JontheEchidna> for example:
[01:07] <JontheEchidna> override_dh_auto_configure:
[01:07] <JontheEchidna>         qmake-qt4 PREFIX=/usr
[01:07] <JontheEchidna> maybe try override_dh_auto_test:, but with nothing on the next line
[01:07] <neversfelde> yes, but how do I disable it completely
[01:07] <neversfelde> I'll try
[01:08] <JontheEchidna> I dunno if that's the proper way, or even if it'll work
[01:08] <JontheEchidna> worth a shot though I guess
[01:10] <Lex79> neversfelde: I found this http://svn.debian.org/wsvn/aqbanking/libgwenhywfar/trunk/debian/rules
[01:10] <Lex79> maybe dh build --after dh_auto_test
[01:12] <neversfelde> Lex79: thanks I will try it
[01:13] <neversfelde> btw what are we doing with kmymoney in lucid?
[01:13] <JontheEchidna> imo it'd probably be best to wait for a stable release before updating it to the KDE4 version
[01:14] <neversfelde> k
[01:14] <neversfelde> it is a LTS release, so probably best
[01:16] <neversfelde> on the other hand, we have to support it for 3 years, so KDE3 releases are a little bit outdated 2013
[01:20] <Lex79> it's not a problem since the world will finish in 21/12/2012 lol
[01:21] <neversfelde> rofl
[01:21] <JontheEchidna> Not unless Juliet has ended it next Tuesday :D
[01:23] <Lex79> btw for me the world finish with the last episode of Lost, when I will know the answer of "What lies in the shadow of the statue?"
[01:23] <Lex79> :)
[01:25] <neversfelde> Lex79: I like Lost, too. But it got a little bit confusing. I think I have to watch al episodes again
[01:25] <Lex79> yes, that's help
[01:25] <Lex79> http://lostpedia.wikia.com/wiki/Shadow_of_the_statue
[01:27] <JontheEchidna> I'll just have to sit down one summer and watch them all
[01:28] <Lex79> JontheEchidna: yes, I will do after the final season :) hope I can buy all seasons in blue ray, but I think it's much cost
[01:29] <Lex79> *much expensive
[01:29] <Lex79> :)
[01:29] <JontheEchidna> my mom bought the DVD for each series each year they came out (she's a fan too)
[01:29] <Lex79> uh great :)
[01:29] <neversfelde> JontheEchidna: a blank line after it helps, thanks
[01:29] <JontheEchidna> neat
[01:30] <Lex79> I think  dh build --after dh_auto_test it's for old debhelper
[01:30] <Lex79> but dunno exactly
[01:45] <neversfelde> so I have a working basket 2.0 package. I am going to ask upstream, if they want us to ship the new or the old version, now
[01:45] <nixternal> why do people insist on blaming everyone but themselves for not succeeding? why do people insist on staying inside the Linux/free software/open source bubble? Why? Why? Why?
[01:48] <neversfelde> nixternal: you mean your blog post about Yahoo?
[01:49] <nixternal> not only that, but also stuff from the past...I have been quiet on all of it, piecing it all together
[01:50] <neversfelde> mhh, I agree on 100% regarding your post, I commented that, but it seems to be gone
[01:50] <nixternal> spammer :p
[01:51]  * nixternal checks the filters
[01:51] <neversfelde> hehe
[01:51] <nixternal> ok, it should be there now...you were marked as a spammer
[01:51] <neversfelde> time to sleep gn8
[01:52] <nixternal> g'nite dude
[01:52] <nixternal> or spammer
[02:02] <JontheEchidna> could a core-dev retry the kpackagekit builds please?
[02:04] <jjesse> having fun nixternal?
[02:05] <nixternal> oh yes
[02:05] <nixternal> JontheEchidna: link me sweetheart
[02:06] <JontheEchidna> nixternal: https://edge.launchpad.net/ubuntu/+source/kpackagekit/0.5.4-0ubuntu1 Don't bother with ia64 or sparc yet, the build-deps aren't there.
[02:06] <JontheEchidna> but the new packagekit is published at least on i386, so it should build
[02:07] <nixternal> I want to break choqok over my knee
[02:07] <nixternal> is there a freakin' twitter/identi.ca app that doesn't crash everytime I post something?
[02:08] <nixternal> JontheEchidna: powerpc is good to go?
[02:08] <nixternal> doesn't matter, all but ia64 and sparc have been done :)
[02:09] <JontheEchidna> \o/
[02:09] <nixternal> ok, I need to eat, I am about to die I think
[03:47] <JontheEchidna> Closing 9 bugs in one upload is satisfying :)
[03:47] <JontheEchidna> not as epic as crimsun's PA upload though
[03:54] <shtylman> Riddell maco: sorry to hear about the chaos. Yea, I know about that bug. Its a long standing one that I have been unable to fix without breaking other things. Hopefully inspiration will come to me one day and I will resolve it... :/
[04:48] <maco> shtylman: the person claims that it works properly in openSUSE and Arch
[04:59] <shtylman> maco: I doubt that cause the same bug is in the bugzilla for go-oo/openoffice
[04:59] <maco> heh alrighty
[04:59] <shtylman> :)
[06:06] <nixternal> fyi, I got ScottK back...i tried to not do threats, but i had no choice...he will be happy that I am allowing him to keep his walker
[06:07] <ScottK> Just so I'll have something to beat you with.
[06:07] <nixternal> to heavy for your old ass to pick up :p
[07:20] <apachelogger> salut mes amis!
[08:13] <apachelogger> JontheEchidna: kdeutils all triaged out, fixed a bug in printer-applet on the way
[11:17] <jussi01> o/
[12:03] <JontheEchidna> apachelogger: neato
[12:03] <apachelogger> JontheEchidna: the bug was super ludicrous though ;)
[12:04] <apachelogger> KMessageBox.warning()
[12:06]  * JontheEchidna has to look through the bugmail now ;)
[12:09] <ghostcube> o{}o
[12:18] <jussi01> JontheEchidna: have fun with my bug reports from last night :)
[12:20] <JontheEchidna> jussi01: which one is that?
[12:21] <jussi01> JontheEchidna: bug 513912 Im guessing is the one youll be interested in:
[12:24] <Quintasan> WTF is with those CTCP requests coming from different channels?
[12:24] <jussi01> Quintasan: evilness.. hoping they are fixed with the new ircd tomorrow
[12:26] <Quintasan> How do I request a sync from Debian?
[12:26] <JontheEchidna> with requestsync :P
[12:26] <JontheEchidna> gotta go, no time to not be cheeky
[12:27] <Quintasan> :P
[12:28] <jussi01> !sync | Quintasan
[12:28] <Quintasan> jussi01: nvm, I forgot I'm running karmic :P
[12:29] <ghostcube> Quintasan you can try an +C mode for your nick if single requests or the ops woukld need an +R for this channel but sux a bit
[12:30] <Quintasan> +C does what?
[12:32] <Quintasan> hmm look like I will team up with Johnatan on bug tiriaging
[12:43] <Quintasan> :/
[12:44] <Quintasan> bug #513435 <--- how should I deal with this? file a bug on kde bugzilla or it's probably a problem with our packages?
[12:44] <Quintasan> I am able to reproduce on both Karmic and Lucid 4.3.95 packages
[12:55] <ryanakca> \sh: Offtopic, but, what happened to Leonov?
[12:58] <\sh> ryanakca: it's not dead...I'm lacking time right now for this project...but this will change in the next couple of weeks/months
[12:59] <ryanakca> \sh: ah, ok
[13:00] <\sh> if I had money, I would pay people to do implementations of my software ideas...;)
[13:05] <jussi01> ryanakca: no
[13:05] <jussi01> ryanakca: re -ops
[13:10] <ryanakca> jussi01: ok
[13:17] <ghostcube> Quintasan +C stops direct ctcp to you not through channels
[13:17] <ghostcube> :)
[13:39] <ScottK> Setting CTCP ignore rule on your Quassel also stops it.
[13:40] <seele> txwikinger: ping
[14:00] <Riddell> txwikinger: ping
[14:32] <txwikinger> Riddell: pon
[14:32] <txwikinger> Riddell: pong
[14:32] <txwikinger> seele: pong
[14:52] <genii> Does bugs.kde.org use same login as LP?
[14:52] <shadeslayer> genii: nope
[14:53] <shadeslayer> genii: unfourtunately, bugs.kde.org , techbase and userbase all have different login methods... i have 3 accounts myself :(
[14:55] <ScottK> Put slightly differently, fortunately bugs.kde.org does not use the man-in-the-middle protocol.
[14:55] <shadeslayer> hehe...
[14:56] <shadeslayer> you could say that :)
[14:58]  * ScottK always thought it was odd people liked a protocol which had as it's fundamental design principle a security attack.
[14:59]  * apachelogger is tha uber perl haxx0r
[15:17] <apachelogger> ScottK: btw https://bugs.launchpad.net/karmic-backports/+bug/513329
[15:18] <shadeslayer> apachelogger: :D
[15:18] <apachelogger> ScottK: do you still have a KDE 3 setup around?
[15:18] <shadeslayer> ill brb..
[15:18] <apachelogger> ScottK: oh and while we are at it https://bugs.launchpad.net/karmic-backports/+bug/513825 :D
[15:19] <ScottK> apachelogger: No.  You shoud have asked last month.  I still had a Dapper box then.
[15:19] <apachelogger> oh well, I suppose I'll just download dapper and vbox it
[15:19] <apachelogger> does one even get that thing for download still :D
[15:20] <Tm_T> apachelogger: 8.04.4 ?
[15:21] <Tm_T> or what it was
[15:21] <ScottK> apachelogger: Yeah, you'd want Hardy.
[15:21] <apachelogger> Tm_T: 6.06
[15:21] <ScottK> Tm_T: Actually 8.04.2 was the last update for Kubuntu.
[15:21] <apachelogger> ScottK: one could still get dapper from oldreleases.u.c :D
[15:22] <ScottK> apachelogger: First one approved, second one needs more info
[15:22] <Tm_T> ScottK: ah, true, .4 is only Ubuntu
[15:22] <ScottK> apachelogger: I'm not sure if they moved the images or not.
[15:22] <apachelogger> *shrug*
[15:22] <apachelogger> downloading hardy now
[15:23] <apachelogger> Riddell: please backport kmess 2.0.2-1 to karmic as per bug 513329
[15:24] <apachelogger> ScottK: thanks for the quick response :)
[15:43] <dholbach> hiya
[15:43] <dholbach> if seele turns up later on, can somebody tell her to show up in #ubuntu-classroom? thanks :)
[15:44] <ScottK> We can ask.
[15:44] <dholbach> super, thanks
[15:46] <seele> txwikinger: ping
[15:46] <txwikinger> seele: pong
[15:46] <dholbach> hiya seele!
[15:46] <txwikinger> hi dholbach
[15:46] <dholbach> hey txwikinger
[15:46] <seele> dholbach: yo
[15:46] <dholbach> how are you all doing?
[15:46] <txwikinger> not very well
[15:46] <dholbach> seele: if you can show up in #ubuntu-classroom I can op you there so you can speak later on
[15:47] <dholbach> txwikinger: still busy with the lawyers and everything?
[15:47] <txwikinger> yes
[15:47] <dholbach> that sucks :-(
[15:47] <dholbach> seele: muchas gracias!
[15:47] <txwikinger> yeah.. in particula because the other site cannot even abide by court orders
[15:47] <dholbach> urgh
[15:47] <seele> dholbach: 3 hours right? want to make sure i get the time zone conversion correct :P
[15:48]  * txwikinger thinks he is on the verge of a heart attack
[15:48] <apachelogger> seele: set your kde clock to alternate between local and UTC upon scrolling :P
[15:48] <seele> apachelogger: i can do that?
[15:48] <apachelogger> sure
[15:48] <dholbach> seele: sounds about right
[15:48] <dholbach> date; date -u   should give you the answer to
[15:48] <apachelogger> right click -> settings -> timeszones -> select utc
[15:49] <apachelogger> then when you scroll on your clock you swtich between local and utc
[15:49] <txwikinger> you can move over it and use the mouse wheel
[15:49] <apachelogger> or any other selected timezone
[15:49] <seele> apachelogger: oooh ho ho sweet
[15:56] <apachelogger> dholbach: you know, in the KDE world we barely pay the terminal a visit :P
[15:57] <dholbach> apachelogger: that explains the quality of packages
[15:57] <dholbach> apachelogger: just kidding ;-)
[15:57] <apachelogger> unless of course there is a terminal widget on the desktop where one can run a make on the Qt source, so one looks super busy ;)
[16:00] <apachelogger> weeh, vbox crash
[16:02] <apachelogger> one of the few things I like about KDE 3: the login sound we had was very smooth
[17:48] <genii> How to show Qt4 version?
[17:50] <Lex79> moc-qt4 -v
[17:50] <nixternal> qmake --version
[17:50] <Lex79> apt-cache policy libqt4-core
[17:50] <nixternal> lol
[17:50] <nixternal> dpkg -l libqt4-dev
[17:50] <nixternal> dpkg -l libqt4\* | grep \^ii
[17:50] <Lex79> others way?
[17:50] <nixternal> ;)
[17:50] <Lex79> lol
[17:50] <genii> Lex79: the apt-cache shows no version installed for -core or -gui
[17:51] <nixternal> qmake --version works well
[17:51] <nixternal> <<< nixternal@ShakaDoobie :: ~ :: 11:49.44 Fri Jan 29 2010
[17:51] <nixternal> >>> [1008] qmake --version
[17:51] <nixternal> QMake version 2.01a
[17:51] <nixternal> Using Qt version 4.6.0 in /usr/lib
[17:51] <genii> Hm. apparently i have no Qt installed
[18:20] <nixternal> i love how i never get these ctcp spams on oftc
[18:20] <ScottK> Almost never get netsplits either.
[18:21] <crimsun> then again, oftc doesn't seem to be as significant a target
[18:21] <ScottK> Could be.
[18:22] <nixternal> crimsun: that is because they are ran a little cleaner...maybe not as big as freenode, but they never have been controlled by people who shouldn't have been in control in the first place
[18:22] <nixternal> this all started in 2005 with lilo and it hasn't gone away since then
[18:23] <crimsun> nixternal: I don't doubt that there is an eighth layer involved, but scalability has always been an issue (even back in my dalnet/undernet/efnet days)
[18:23] <nixternal> efnet, man i used to be a huge troll on there
[18:24] <nixternal> we used to go in and bomb all political channels, all racist channels, all windows channels...it was so fun back then
[18:42] <Quintasan> hiho
[18:44] <daskreech> Hello
[19:13] <maco> i feel like i'm talking to the wall in -classroom
[19:13] <nixternal> you are :)
[19:15] <Quintasan> well, I'm there at least :P
[19:15] <ScottK> Kubuntu?  What is this "K" you spea of?
[19:15] <ScottK> spea/speak
[19:29] <maco> Quintasan: *flailing*
[19:41] <maco> Quintasan: i wish Riddell was online :(
[19:41] <maco> or nixternal
[19:41] <maco> no not him
[19:41] <maco> Nightrose:
[19:41] <Quintasan> :DD
[19:41] <ScottK> maco: If you need me to make up an answer to something, let me know.
[19:53] <Mamarok> maco: btw most of the KDE projects have channels on Freenode, too, so if questions arise in JJ, they can ask in the channels or in #kde-devel
[19:53] <maco> people in #kde-devel will likely direct them to the right place though, i think
[19:53] <Mamarok> I guess so, yes, devel is just sometimes very quite, especially during nighttime in Europe
[19:54] <Mamarok> else #kde is an alternative
[19:56] <Mamarok> also, Qt/C++ allows to do shorter code, the Qt framework is very powerful
[20:00] <maco> heheh
[20:01] <maco> pleia2 is all amused that seele passed it off to me and i got help from Nightrose
[20:01] <maco> someone in -chat asked if women like C++
[20:02] <Nightrose> well i definitely like it more than C
[20:02] <Nightrose> :D
[20:03] <maco> i dont know C++
[20:03] <maco> C is soooo much better with GLib than on its own though
[20:03] <Quintasan> well, time to get that icon bug reported
[20:04] <maco> oh blah. my list of things to learn this weekend is horribly long: algebra, trig, calculus, physics, pykde
[20:04] <Quintasan> @_@
[20:04] <ScottK> Right, rework the sequence
[20:05] <maco> well i'm taking calc-based physics this semester. i learned calculus 5yr ago, trig 6yr ago, and algebra never
[20:05] <maco> and i have to have a slightly working demo of my sign language program by 10 feb, and thats happening in pykde
[20:27] <Quintasan> how do I add link to this same bug tracked in KDE's bugzilla in LP?
[20:27] <Quintasan> I can't find that option :/
[20:28] <ScottK> also affects project
[20:37] <genii> Hm. When apport itself is crashing, what to do?
[20:37] <Quintasan> ScottK: urgh, what I'm supposed to put there? KDE doesn't work and the project search yields http://www.kde.org which doesnt' work too
[20:37] <ScottK> Quintasan: Source pacakge name.
[20:37] <ScottK> If that doesn't work, just feed it the url of the bug.  IIRC there's a spot for that.
[20:38] <Quintasan> ScottK: thanks :)
[20:40] <wind-rider> hi
[20:41] <wind-rider> today or yesterday the soprano-daemon package was changed to recommend the virtuoso-server
[20:41] <wind-rider> this was done to 'fix' https://bugs.launchpad.net/bugs/505653
[20:42] <wind-rider> but i think it is not fixed by only recommending - it should be made depending because KDE will complain about it until virtuoso is installed
[20:42] <ScottK> Virtuoso is optional for soprano.
[20:43] <ScottK> For KDE 4.4, IIRC, the only KDE component that requires it is kmail.
[20:43] <ScottK> kmail/kdepim
[20:43] <maco> there's a new kmail coming right?
[20:43] <maco> hmm i should upgrade so i can play with it!
[20:43] <wind-rider> ScottK: Strigi also complains about it
[20:43] <maco> wait... hrm... will kdepim lose my calendar and contacts if i upgrade? *suspicious*
[20:44] <wind-rider> ScottK: Nepomuk depends on it
[20:44] <wind-rider> ScottK: and akonadi depends on nepomuk for part of its functionality
[20:44] <ScottK> wind-rider: Yes and the only part of KDE 4.4 that it's needed for is the akonadi/kdepim stuff.
[20:44] <ScottK> Having it required for soprano would be wrong.
[20:45] <Quintasan> JontheEchidna: \o
[20:45] <wind-rider> ScottK: no, Strigi requires it too
[20:45] <ScottK> OK.  That's still not soprano
[20:45] <Mamarok> maco: not unlikely, you should export those
[20:45] <wind-rider> ScottK: every time I boot my laptop KDE complains about not having virtuoso
[20:45] <maco> meep!
[20:45] <ScottK> It may be that there should be some other component with a depends relationship, but not soprano.
[20:45] <Lex79> ScottK: soprano is build to depends on virtuoso. Soprano needs virtuoso backend to work
[20:45] <Mamarok> and the kaddressbook in the new KDEpim is a bit... strange
[20:46] <maco> Mamarok: i hope by release time there will be some conversion thingy so it doesnt get lost for everyone who upgrades?
[20:46] <ScottK> Lex79: It does?
[20:46] <wind-rider> ScottK: what would you propose, then?
[20:46] <wind-rider> ScottK: I would say soprano as virtuoso is a backend of soprano
[20:46]  * maco looks for screenshots
[20:46] <ScottK> I would propose Lex79 figure it out since he seems to understand it better than me.
[20:47] <Lex79> ScottK: if virtuoso is recommends, this means is on the CD ?
[20:47] <maco> Mamarok: why does it look like Outlook/Evolution? :( http://userbase.kde.org/File:Kontact_presentation_small.jpg
[20:47] <ScottK> Lex79: Yes.
[20:48] <wind-rider> Lex79, ScottK: why is it only 'recommending' it, then
[20:48] <Mamarok> maco: it always did, long before there was Evolution
[20:48] <Lex79> wind-rider: we need to investigate a bit
[20:48] <ScottK> So it can be removed if you don't want it.
[20:48] <wind-rider> it will only annoy the user if it is not there
[20:48] <Mamarok> maco: and that's how PIM software looks :)
[20:48] <wind-rider> soprano is useless without it
[20:49] <maco> Mamarok: but that calendar now looks much more evolution-y with that sidebar thingy
[20:49]  * ScottK goes out on a limb and predicts it's changeable.
[20:50] <wind-rider> Lex79: what does the choice depend on?
[20:50] <Quintasan> ScottK: hmm my friend is working on liblo and he filled a sync request, synces are made automatically or we have to do it by hand?
[20:50] <Mamarok> maco: there has been a sidebar before
[20:51]  * Quintasan can't find policy on syncing
[20:51] <maco> Mamarok: the bit with the todos and such? i never saw that before...do you mean in the kde3 version or something?
[20:51] <Lex79> wind-rider: maybe it's right that soprano depends on virtuoso, but we need to investigate before, ok?
[20:52] <wind-rider> Lex79: sure
[20:52] <Lex79> wind-rider: we have time to do that :)
[20:52] <Lex79> it's an easy change to do, if it needs
[20:52] <Mamarok> maco: I don't recall exactly, but there was a sidebar, maybe just not in all elements
[20:52] <wind-rider> Lex79: I was only wondering why it was chosen the way it is now - and if looks obvious to have it depending, why not?
[20:52] <Mamarok> remember*
[20:54] <Lex79> wind-rider: that changes is made by Riddell, maybe just forgot to do that
[20:54] <wind-rider> Lex79: ok, i'll add something to the bug report
[20:54] <Lex79> ok thanks
[20:55] <Quintasan> ScottK: urgh nvm, I found something
[21:08] <Quintasan> gosh this is though, can anyone clear something for me? I'm trying to do a sync, I file a bug at Launchpad, I have downloaded the source from Debian Experimental and confirmed it builds in Ubuntu, shall I mark it on LP and subscribe ubuntu-archive?
[21:08] <Quintasan> tough*
[21:16] <Quintasan> DAMN IT
[21:16] <Quintasan> why the hell they had to break heating once again
[21:24] <nixternal> heh, my niece took a pic of me and told me to pose, so I did...I don't smile for pics I don't think and I don't know why
[21:27] <JontheEchidna> could a core-dev sponsor bug 508073?
[21:39]  * ScottK looks
[21:45] <JontheEchidna> thanks
[21:45] <JontheEchidna> ScottK: I also wanted to show you this: http://imagebin.ca/view/fUA_BCW.html
[21:47] <ScottK> JontheEchidna: Nice.  I saw that bugmail yesterday.  Very important improvement.
[21:48] <nixternal> wtf does choqok crash 99.9% of the time after sending an update?
[21:48] <jjesse-netbook> no idea, i use the web pages more and more
[21:48] <jjesse-netbook> as it is a big piece of #%#%
[21:49] <nixternal> yes, yes it is
[21:49] <nixternal> gonna switch to gwibber I think
[21:49] <JontheEchidna> could be qt 4.6 crappiness, if this sort of thing didn't happen in 9.10
[21:50] <nixternal> it happens in everything
[21:50] <nixternal> 9.10, 10.10, 9.04, keep going
[21:50] <nixternal> openSUSE, Fedora, Arch, Debian, and Kubuntu
[21:50] <nixternal> it is like jjesse-netbook said, a big steaming pile of #%#%
[21:51] <nixternal> we got this little box thing right that does TV ratings, so I researched it a bit...blown away by the US' tv ratings
[21:52] <nixternal> Sara "I'm a dumb ass" Palin drew in more people for her debut on Fox News, than the Vikings and the State of the Union did...that is just insane...I want to cheat this box though, and make Playboy #1
[21:52] <neversfelde> a happy Kubuntu user and dev http://flavio.tordini.org/minitube-is-in-ubuntu-repositories :)
[21:53] <jjesse-netbook> i thought playboy was your #1 channel
[21:53] <jjesse-netbook> or skinamax
[21:53] <Quintasan> lol
[22:14] <ScottK> JontheEchidna: slangasek is going to sponsor it.
[22:22] <Quintasan> ScottK and JontheEchidna: got a second?
[22:26] <Sput> hmmm, my chokoq works fine
[22:26] <maco> swap your q and k
[22:26] <Sput> yeah, I tend to misspell that
[22:26] <maco> choqok works fine for me, mostly
[22:26] <maco> it crashes maybe once every couple days
[22:26] <Sput> anyway, I'm using development versions of everything, so whatever was buggy, it seems to be fixed meanwhile :)
[22:27] <maco> which is about how often quassel crashes...
[22:31] <Quintasan> urgh
[22:31] <Quintasan> ScottK, JontheEchidna or maco: mind checking http://pastebin.com/f523a1621 for any errors?
[22:32] <maco> Quintasan: did you intentionally lose all that documentation?
[22:33] <Quintasan> maco: it's a diff from debian probably
[22:33] <Quintasan> grr
[22:33] <Quintasan> this is giving me a headache
[22:33] <Quintasan> yes
[22:34] <Quintasan> this doc/ is dropped in debian and doc/html comes instead
[22:35] <maco> ok
[22:35] <maco> yeah reading merge diffs is like *stabby*
[22:35] <maco> sure, ooks fine to me
[22:35] <maco> *looks
[22:36] <maco> does it build? ;-)
[22:36] <crimsun> oh no, not /that/ package
[22:36] <crimsun> upstream already has official python bindings
[22:37] <crimsun> also, if the debdiff corrects the capitalisation of "API", why doesn't it correct the semantics in the summary? It's "Python bindings for ALSA".
[22:37] <maco> so youre saying "package unnecessary! EXTERMINATE!" ?
[22:37] <crimsun> it needs to die already, yes.
[22:37] <maco> (it's "be exterminated" not "die" where's the dalek in you?)
[22:37] <crimsun> no, I don't care to actively exterminate it
[22:38] <crimsun> I just want it to go away.   I don't know how to exacly deal with it
[22:40] <ari-tczew> so pyalsaaudio have to remove from archive?
[22:41] <Quintasan> crimsun: https://bugs.launchpad.net/ubuntu/+source/pyalsaaudio/+bug/514453
[22:41] <Quintasan> crimsun: shall I mark it as invalid and file a archive removal request?
[22:43] <crimsun> Quintasan: no, you shouldn't file such a request. It's legitimate FOSS, but my opinion (and upstream's) is that it is deprecated in favor of the official bindings.
[22:44] <Quintasan> crimsun: anything against updating it?
[22:44]  * Quintasan is seriously confused now
[22:46] <Riddell> maco: how was the talk?
[22:47] <crimsun> Quintasan: I have absolutely nothing against updating it as an Ubuntu maintainer.
[22:47] <crimsun> Quintasan: from an upstream developer point of view, I don't like it.
[22:48] <Quintasan> crimsun: okay, but I think you should consider asking for removal if it's deprecated
[22:48] <crimsun> Quintasan: I'll look at the bug report in 20 minutes, but I don't plan to merge it myself unless you're specifically requesting that I do so.
[22:49] <Quintasan> crimsun: well I'm not going to impose any work on you
[23:33] <Lex79> JontheEchidna: mail sent
[23:50] <Riddell> what a mess
[23:52] <Quintasan> Riddell: I can only agree


[01:05] <valorie> \o/
 KC election Poll done, and voting emails sent
 6/37 votes already
 12/37
 last year we had 19 + Aaaron
 ?
 @ahoneybun, You didn't vote, but then broke the tie afterwards. :P
 I voted this time.
 @ahoneybun, No hurricanes in Denver!
 Yep lol.