[07:29] <sinean> installed fglrx and fglrx-amdcccle, driver is fine but no catalyst control center (from xorg edgers ppa) linux mint 16 cinnamon x64 stock kernel
[07:40] <tjaalton> we don't support mint
[07:41] <tjaalton> go ask the mint folks
[07:44] <sinean> k
[07:47] <tjaalton> edgers folks tend to hang here though, on and off
[12:37] <21WAB8FNS> there are new patches now that enable opengl on radeonsi cards, any idea when new mesa is pushed forward?
[12:38] <tjaalton> trusty has 10.1
[12:38] <tjaalton> opengl is already "enabled"
[12:42] <21WAB8FNS> well the patches are posted t oday
[12:42] <21WAB8FNS> today
[12:45] <tjaalton> so hope that 10.2 will have them
[13:25] <ricotz> tjaalton, trusty has 10.0.1 ;), 10.1 is git master
[13:26] <tjaalton> hah, true
[13:26] <tjaalton> silly versions


[01:59] <wrst> happy spinning DJOmnifrog
[02:02] <Unit193> DJFroggin'
[02:02] <DJOmnifrog> :D
[02:02] <Unit193> OmniDJ.
[02:02] <Unit193> wrst: Howdy again.
[02:02] <DJOmnifrog> I was supposed to be off 2 minutes ago but the next DJ didn't show
[02:10] <wrst> DJOmnifrog: that seems to be a resounding theme with you :)
[02:10] <wrst> Unit193: having a good night?
[02:10] <wrst> DJOmnifrog = responsible adult
[02:12] <DJOmnifrog> it does
[02:13] <Unit193> Having to stick around after the job, yes.
[02:13] <DJOmnifrog> might be another 2 hour, who knows
[02:14] <DJOmnifrog> playing Whitesnake now
[02:16] <wrst> Unit193: everyone likes staying after work... that's living the dream!
[05:15] <Unit193> http://assets.amuniversal.com/9cfe2180fbdc013017b5001dd8b71c47 Ahahahahahahaha!  Yes, so very true! :P
[05:15] <Unit193> chris4585: Howdy.
[05:16] <chris4585> Unit193, salutations


[12:53] <zul> BenC: ping
[12:54] <zul> ...if you arent watching football
[01:13] <infinity> BenC: Yeah, I could do with another fgrlx version bump.  I'll prepare it today.
[03:08] <BenC> zul:games over, skins won
[03:08] <BenC> zul: what's up?
[03:18] <zul> BenC: whats with the ubuntu-edgy gits
[03:33] <infinity> zul: Tollef fixed some arch includes in your xen git tree, apparently.  Mind doing an upload of that, so xen-restricted-modules doesn't FTBFS?
[03:34] <zul> infinity: sure
[03:34] <zul> oh btw the new git archive is http://dev.laptop.org/git.do?p=projects/ubuntu-xen-2.6.17;a=summary
[03:35] <infinity> Not much plan here to do anything with it.  I was only fixing xen-r-m for you, out of the kindness of my heart (or because I was bored yesterday; pick one)
[03:36] <zul> i would like to think its kindness but im picking bored :)
[03:41] <infinity> In the future, try to remember to use the LRM orig.tar.gz for XRM... Uploading 90 MB to make a few K of fixes was unfun. :)
[03:41] <infinity> (I'll rev XRM for you when I bump fglrx in LRM)
[03:41] <zul> thanks
[03:42] <zul> sorry...wont happen again
[03:43] <infinity> Is your git tree synced with the main kernel?
[03:44] <infinity> If so, I was wondering if it might not be a bad idea to artificiall bump your ABI to match, so people know that the xen kernels have the same set of fixes/drivers.
[03:44] <infinity> If the source isn't even close to common, then don't do that, obviously. :)
[03:45] <zul> no it hasnt been synced up yet unforuntaely..
[04:24] <BenC> zul_: ubuntu-edgy gits are where edgy kernel is coming from now
[04:24] <BenC> I'm taking some time to merge ubuntu-2.6 to latest kernel
[04:24] <BenC> start getting out some daily builds early for bleeding edgy fools like me :)
[04:25] <BenC> 2.6.19 development is probably going to lead out about 2 months into our next release, so I want to get a head start...have packages ready the day edgy+1 opens up
[04:25] <BenC> plus make packages available for jbailey and doko for edgy+1 toolchain
[05:34] <fabbione> BenC: ping?
[06:33] <fabbione> BenC: dude.. you didn't pull the PROM_CONSOLE patch in 10.25...
[06:33] <fabbione> we need that to fix the CPU softlookups on NIagara
[01:21] <tonfa> is there a reason for using git instead of quilt/quilt-like for the ubuntu kernel tree ?
[01:21] <tonfa> I see other distro are using a quilt like process
[01:22] <tonfa> and that way you can cleanly see the different features they added
[01:24] <infinity> Much easier to cherry-pick changes from upstream with git.
[01:25] <tonfa> but couldn't it be converted to a patch ?
[01:25] <infinity> "it"?
[01:25] <tonfa> cherry-pick is just patch importing + 3-way merge, right
[01:25] <tonfa> the cherry-picked changeset
[01:26] <infinity> You want a massive "ubuntu" patch to see against the upstream kernel, or you want every one of our patches broken out?
[01:26] <infinity> The latter is a serious pain, because then you can't easily use git anymore to merge as both we and upstream move.
[01:26] <zul> infinity: could you kick 3.0.3~rc1 in the butt its still stuck in binary-new
[01:26] <tonfa> that's the same workload as akpm
[01:26] <infinity> (for instance, Ben is currently merging our 2.6.17 with upstream's 2.6.19... Much simpler without dealing with hundreds of patches outside of git)
[01:27] <tonfa> quilt pop -a  ; update to upstram ; quilt push -a
[01:27] <tonfa> *upstream
[01:27] <infinity> Erm, no.  You're not quite grasping it.
[01:27] <tonfa> you will have to resolve conflicts during the push, of course
[01:28] <infinity> If you have a revision history that says "I pulled changeset 1234 from 2.6.18", and 2.6.19 has the same in its history, the merge is seamless.  If we have a bunch of patches, we have to hand-merge them or examine each one to see if we should discard it.
[01:28] <infinity> The latter is far more effort, for very little gain.
[01:28] <infinity> zul: I'll poke it in a sec.  I've been pitti's bitchs with mangling security builds for a while.
[01:29] <zul> infinity: coolio...thanks
[01:30] <infinity> zul: Are you going to give me an unbroken xen-source-2.6.17? :P
[01:31] <zul> i just uploaded it last night
[01:31] <zul> argh...it timed out on me..
[01:31] <zul> yeah ill upload it again
[01:31] <infinity> Kay.  xen-3.0 processed.
[01:32] <zul> thanks..
[01:40] <tonfa> infinity: but you can first drop all the backports, when merging to the upstream version
[01:41] <zul> right im off to work
[01:43] <infinity> tonfa: This implies we only have one upstream.
[01:43] <tonfa> what is the other upstream ?
[01:43] <infinity> tonfa: We merge patches from all over, and prefer to merge from git repos that all merge to<->from linus, so it all sort of self-resolves (with exceptions, of course)
[01:44] <tonfa> so upstream is linus-2.6
[01:44] <infinity> tonfa: We're certainly not just backporting from one branch, is my point.
[01:45] <infinity> Anyhow, not much point in arguing it, the decision was made during the dapper cycle, it's worked well for us, I don't think Ben (who has to do the majority of the work) is itching to switch.
[01:45] <tonfa> ok, I understand that it makes the work easier for you
[01:46] <tonfa> (but not necessarly for other people, distro)
[01:46] <infinity> yes, we're aware that patch-digging becomes a bit more difficult.
[01:46] <infinity> But that's not really our number one goal either.
[02:11] <tonfa> utrace looks interesting for implementing apport
[02:44] <zul> god...i love monday mornings dns died at work
[02:45] <BenC> fabbione: ping
[02:59] <zul> BenC: ping
[03:03] <BenC> zul: pong
[03:06] <zul> BenC: the kernel-package patch i was talking about is at http://<IP_ADDRESS>/ubuntu/kernel-package-debdiff.patch
[03:13] <BenC> zul: thanks
[03:15] <AnAnt> there is a bug in the kernel I think
[03:15] <AnAnt> when I insert my MMC card it doesn't get mounted
[03:15] <AnAnt> I have to manually modprobe tifm_sd
[03:17] <BenC> mmc layer isn't very hotplug friendly
[03:18] <AnAnt> huh ?
[03:18] <AnAnt> BenC: but it used to work in 2.6.15 when I patched the kernel
[03:19] <AnAnt> BenC: I patched the kernel for MMC4
[03:19] <AnAnt> it was a couple of lines only
[03:19] <AnAnt> I don't think that this patch did anything to hotplug, and it worked in Dapper
[03:20] <BenC> by hotplug I mean that the drivers either provide the right information so that hotplug knows to load the module, or it loads the module itself
[03:21] <BenC> tifm wasn't in dapper, IIRC
[03:21] <AnAnt> hmm
[03:21] <AnAnt> so it won't be fixed at stable release ?
[03:24] <ivoks> hi
[03:26] <zul> BenC: i could upload the fix if you want
[03:38] <fabbione> BenC: pong
[03:50] <fabbione> BenC: i need to take my son out for a walk. will try to pass by later
[03:59] <AnAnt> zul: the fix you talk about is for the MMC ?
[04:00] <zul> wha?
[04:00] <AnAnt> zul: nevermind
[04:00] <zul> i need the context
[04:02] <zul> BenC: what are the chances of getting xen into the edgy+1 kernel?
[04:02] <zul> i mean i can do the necessary grunt work though
[04:05] <BenC> zul: Well, I'm starting from scratch on the edgy+1 kernel
[04:05] <BenC> I want to take a different route with some of the stuff we've been doing
[04:05] <tonfa> BenC: will you consider using a queue of patches ?
[04:05] <BenC> mainly, I want all our external drivers in an ubuntu/ sub directory to keep things cleaner
[04:05] <BenC> tonfa: no
[04:06] <tonfa> ok
[04:06] <zul> BenC: ah ok so what like debian is doing now
[04:06] <BenC> tonfa: But the subdirectory for our custom drivers will make it easier to diff things and such
[04:06] <BenC> s/custom/third-party/
[04:06] <zul> heh well let me know when you have something and i can beat it in
[04:07] <BenC> there's way too many conflicts when I go from one major version to another
[04:22] <Keybuk> BenC: we've never mounted /proc/bus/usb with special permissions to give other people write access
[04:22] <Keybuk> that would be bad
[04:27] <fabbione> BenC: re
[04:28] <BenC> Keybuk: I don't disagree with the permissions, but I disagree that doing it that way would solve the problem
[04:28] <BenC> fabbione: where can I pull your kenrel upload changes from?
[04:28] <fabbione> BenC: the patch is the same as the one i did send via email to you and davem.
[04:29] <fabbione> i had to do the upload without git, because you created the edgy branch and i wasn't sure from which one you did release 10.24
[04:29] <BenC> fabbione: most likely from edgy? :)
[04:29] <fabbione> BenC: kernel.org/git doesn't show any history for that branch.. only 2 commits
[04:29] <fabbione> that's why...
[04:29] <fabbione> otherwise i would have done it :)
[04:30] <fabbione> i admit i got confused
[04:30] <BenC> no problem
[04:30] <fabbione> but i can resend you the debdiff
[04:30] <BenC> you did use the .orig.tar.gz, right?
[04:30] <fabbione> yes
[04:30] <BenC> excellent
[04:30] <fabbione> i used apt-get source
[04:30] <fabbione> + the patch + changelog
[04:30] <fabbione> of course mv debian/abi/foo to match the upload
[04:31] <fabbione> no more no less
[04:31] <Keybuk> BenC: which problem?
[04:37] <BenC> Keybuk: The problem where vmware can't access USB devices
[04:37] <Keybuk> I've no idea what vmware does to that directory
[04:37] <Keybuk> then they had that problem with dapper
[04:37] <BenC> it reads/writes to the dev entries
[04:37] <Keybuk> dapper didn't give anything other than root access to them
[04:38] <BenC> I'm not arguing that
[04:38] <Keybuk> the fix is easy
[04:38] <Keybuk> make vmware look in /dev/bus/usb first
[04:38] <Keybuk> and then the user running vmware will have permission to write to any usb devices that the user has permission to write to
[04:39] <BenC> if vmware were configurable to do that, we wouldn't be discussing this :)
[04:39] <BenC> I personally don't care either way, and I'm not pushing for a real fix
[04:39] <Keybuk> the whole point of our relationship with vmware is that we can get them fix this kind of thing, no?
[04:40] <BenC> I'm just saying that if proc/bus/usb gets mounted like you are saying, there's no point in doing so
[04:40] <Keybuk> the reason /dev/bus/usb was *invented* was this problem - giving non-root users access to usb devices
[04:40] <BenC> I'm out of the loop on this
[04:40] <BenC> like I said, I'm just pointing out that it's useless to mount it with 0600 perms if it's not going to help
[04:41] <BenC> I'm not saying mount it with other perms, just don't mount it at all if the security issues are the case
[04:41] <Keybuk> haven't people claimed that mounting it (with the default 644 perms) fixes it?
[04:41] <BenC> yes, it does
[04:41] <Keybuk> how does that fix it?
[04:41] <Keybuk> it can't write to the devices still
[04:41] <BenC> err, well not really
[04:41] <BenC> 644 allows vmware to see the device, but not use it
[04:43] <Keybuk> ok
[04:43] <Keybuk> doesn't vmware just use its kernel modules of doom to do this kind of thing?
[04:44] <BenC> Keybuk: how does one get perms for /dev/bus/usb/ devices?
[04:44] <Keybuk> /etc/udev/rules.d
[04:44] <BenC> Keybuk: no, it doesn't use the kernel module since the internal API changes a lot more than the userspace one does
[04:44] <Keybuk> e.g. /etc/udev/rules.d/45-libgphoto2.rules
[04:46] <BenC> I wish dev/bus/usb had a devices file, we could just bind mount it
[04:48] <Keybuk> we could probably fake one :p
[04:48] <Keybuk> have a udev rule that updates it every time a usb device is added or removed
[04:48] <Keybuk> reads from sysfs
[04:48] <Keybuk> and writes out the file
[04:49] <zul>  /win 11
[04:49] <zul> oops
[04:49] <BenC> probably easier to just mount usbfs somewhere hidden, bind mount /dev/bus/usb to /proc/bus/usb and copy the file when usb devices are added or removed
[04:51] <BenC> for some reason my vmware has started running slow as balls
[04:52] <BenC> loadavg is 0.00, and vmware is crawling
[04:52] <BenC> Keybuk: copying the file and bind mount dev/bus/usb to proc/bus/usb seems to let vmware see the device
[04:53] <BenC> I'm trying to test if it actually can use it after I manually changed the perms
[04:57] <Atthar> hi room
[04:58] <Atthar> i want to download linux driver for my modem, what is kernel of 6.06 LTS version?
[04:59] <BenC> Atthar: uname -a
[05:00] <Atthar> im in windows now!
[05:00] <zul> its 2.6.15
[05:02] <Atthar> tnx, but plz see this page: http://www.linuxant.com/drivers/hsf/full/downloads-ubuntu-x86.php i need full number of kernel
[05:02] <BenC> Atthar: that's why you need to use that command: uname -a
[05:03] <BenC> or atleast uname -r
[05:03] <Atthar> ok, tnx BenC
[05:03] <BenC> there are at least 5 different kernels types (flavours) in dapper x86, and depending on if you have the latest kernel version, at least 4 revisions
[05:05] <Atthar> ok, firs i will install the ubuntu and then use uname -a, tnx and good luck :)
[05:07] <BenC> Keybuk: also, why do you want to make proc/bus/usb 0600, when the devices under dev/bus/usb are 0664?
[05:07] <Keybuk> I don't suggest making it anything?
[05:07] <Keybuk> it'd probably be whatever the default is
[05:07] <Keybuk> which appears to be 0644
[05:08] <BenC> your first email said 600
[05:08] <BenC> devmod=600 is what you sent
[05:08] <Keybuk> oh, maybe I was on crack for that one
[05:09] <BenC> Keybuk: I think the bind mount and coping of the devices list is going to be our best bet if you are willing to implement it
[05:09] <Keybuk> where to mount it though?
[05:10] <BenC> hide mount usbfs somewhere with really strict perms, and bind mount dev/bus/usb to proc/bus/usb, copying the devices file on events
[05:10] <BenC> dev/bus/usb/.usbfs ?
[05:12] <Keybuk> *nods*
[05:12] <Keybuk> can do that in mountdevsubfs
[05:17] <tonfa> what was linux-meta ?
[05:17] <tonfa> (that's mentionned in : https://wiki.ubuntu.com/KernelTeam)
[05:19] <BenC> tonfa: linux-meta is a set of meta packages that makes sure you always have the latest kernel and associated packages with it
[05:20] <tonfa> ok, thanks
[05:27] <AnAnt> I removed the quiet option to get boot messages
[05:28] <AnAnt> the problem is that it corrupts the scroll bar
[05:28] <AnAnt> is there a way to change the position in which the boot messages appear ?
[05:28] <BenC> more of a question for #ubuntu
[05:28] <AnAnt> I'm talking about Edgy not Dapper
[05:28] <BenC> remove the splash option too
[05:29] <AnAnt> BenC: but I won't get splash screen then ?
[05:29] <BenC> dapper or edgy, it's still an issue of #ubuntu...not kernel related :)
[05:29] <AnAnt> oh
[05:29] <BenC> AnAnt: nope
[05:29] <AnAnt> BenC: nope = I won't get splash screen ?
[05:29] <BenC> correct
[05:30] <AnAnt> thanks
[06:25] <Keybuk> BenC: devmode only takes effect for the devices themselves, not for the "devices" file
[06:27] <BenC> Keybuk: right
[06:27] <BenC> devices file is the listmode= option
[06:28] <BenC> there's {dev,bus,list}{uid,gid,mode}
[06:28] <BenC> dev is the files, bus is the subdirs, and list is the "devices" file itself
[06:28] <Keybuk> so we could just symlink it :)
[06:30] <Keybuk> drwxr-xr-x 2 root root  40 2006-10-02 17:29 .usbfs/
[06:30] <Keybuk> drwxr-xr-x 2 root root  80 2006-10-02 08:21 001/
[06:30] <Keybuk> drwxr-xr-x 2 root root  60 2006-10-02 08:21 002/
[06:30] <Keybuk> drwxr-xr-x 2 root root  60 2006-10-02 08:21 003/
[06:30] <Keybuk> lrwxrwxrwx 1 root root  14 2006-10-02 17:30 devices -> .usbfs/devices
[06:30] <Keybuk> ah, sub-mounts don't follow bind mounts
[06:30] <Keybuk> boo
[06:34] <BenC> Keybuk: Ah, true
[06:35] <BenC> link it to /dev/bus/usb/.usbfs/devices directly would work too
[06:35] <Keybuk> link which to?
[06:35] <Keybuk> oh, I see
[10:03] <zul> right later
[10:29] <poptones> hello?
[10:40] <gnomefreak> is there a known issue with nvidia-glx working on -10-386 and not -10-generic?
[10:43] <jldugger> how bad is it that "modprobe toshiba_acpi" segfaults?
[12:05] <gnomefreak> who works with nvidia-glx in here?


[07:06] <dholbach> good morning
[08:23] <Laney> hey
[08:23] <Laney> tumbleweed: seeded-in-ubuntu seems sad: IOError: [Errno socket error] [Errno 111] Connection refused
[08:39] <wgrant> Laney: Apologies, some maintenance on that host took a bit longer than expected.
[08:39] <wgrant> It's been back for a while now
[08:39] <Laney> Works now
[08:40] <Laney> thanks for the boot
[14:00] <bregma> hey folks, I have a package I want to NEW into universe but I'm confused about the next step to take: I filed an RFP, I have a branch ready and built in a PPA, so what's next?
[14:13] <mfisch> bregma: you need a sponsor, let me get back to you about next steps in 15 mins if thats ok
[14:14] <bregma> I'm nothing if not patient
[14:14] <Laney> I assume it can't go to Debian?
[14:16] <bregma> someone else has got a Debian ITP, but he's not likely to find a sponsor there, he hasn't been in contact with upstream, he hasn;t responded to my queries, and I'm aiming to get this particular package in early in the Trusty cycle with an eye to getting it in main
[14:17] <bregma> if and when it gets into Debian, we can start synching then
[14:20] <dholbach> jtaylor, not sure if you tweet, but I noticed that you replied on a couple of keepass2 bugs - do you know what to reply to https://twitter.com/DigitalGrinch/status/391572684372328448?
[14:20] <mfisch> debian is the best route to take if possible bregma
[14:21] <mfisch> does anyone know if the "Packaging branch status" field when branching is supposed to be accurate?
[14:21] <mfisch> Wesnoth says CURRENT but it's got a lucid version in bzr
[15:10] <shadeslayer> stgraber: thanks for sbuild-launchpad-chroot :)
[15:11] <stgraber> hehe, np, I figured it'd be useful to quite a few other developers ;)
[15:11] <shadeslayer> yeah, I recently found out that pbuilder allows shipping files in /usr/local while sbuilder craps out and for the longest time I didn't understand why
[15:12] <shadeslayer> subtle differences in pbuilder and sbuilder apparently
[15:12] <shadeslayer> so its nice to have something is even closer to launchpad in terms of building stuff :D
[15:45] <cjwatson> shadeslayer: No, it has nothing to do with sbuild (which is not spelled sbuilder).  It's more likely that you have pkgbinarymangler installed in your sbuild chroot.
[15:45] <cjwatson> shadeslayer: Since the pkgsanitychecks script in pkgbinarymangler enforces this check.
[15:45] <shadeslayer> oh
[15:45] <shadeslayer> dh_builddeb.pkgbinarymangler: dpkg-deb --build debian/mintsources .. returned exit code 1
[15:46] <shadeslayer> indeedly
[16:47] <mfisch> and to answer my own question, wesnoth is current because it was renamed to wesnoth-1.10 after lucid, both trees are current.


[01:16] <BionicMac> Testing out the RC 18.04 iso install. Clean looking installer. My first rodeo with Xubuntu. I think Xubuntu found a home on my old workhorse IBM ThinkCentre P4. Nice.
[14:51] <metalbiker> hey guys, i was just wondering if it's possible to have an option to make any open window just show an icon instead of the whole bubble/button/label.
[14:52] <metalbiker> or maybe a dot/dash over the icon of the open window
[14:52] <metalbiker> sort of like what gnome does
[15:11] <krytarik> metalbiker: https://docs.xfce.org/xfce/xfce4-panel/tasklist
[15:15] <metalbiker> krytarik: thank you for the link. i'll check it out right now.
[15:16] <metalbiker> where's that option found krytarik?
[15:17] <metalbiker> i'll dig around and see if i can find it.
[15:18] <krytarik> Going through the panel settings directly is one way - otherwise it's a bit finicky to get to the Window Buttons settings.
[15:21] <metalbiker> krytarik: cool. i'll take that route then. lol
[15:47] <new> can i mount a smb share using Thunar?
[15:49] <new> when i enter smb://servername/Share_name
[15:50] <new> I get " Failed to open "File System"."
[16:31] <kj4> hello! does anyone know how to blacklist 4k display resolution?
[17:33] <metalbiker> krytarik: i found the option to turn off those labels and wow! what a difference that makes! thanks for your help!and everything's running great. 18.04's a badass release!
[17:34] <metalbiker> krytarik: oh, i do have another question. why's there two wifi icons in the indicator portion of the panel?
[23:45] <RoadRunner> Attempting rescue from live cd. When start xubuntu live cd (16.04) get a black screen with a question "Select CD-ROM Boot type:" and choices: "1." & "2." with no text description next to the numbers.  What does each choice say?
[23:58] <vivus> RoadRunner: sounds like a BIOS option


[00:29] <RzR> kwwii: I started to gather resources about dark themes bugs at http://rzr.online.fr/q/dark I'll keep you informed if it matters
[00:37] <kwwii> RzR: let me take a look at that, 1s
[00:38] <kwwii> RzR: that looks like a good start
[00:38] <kwwii> RzR: I am sure that we can add to that
[00:38] <kwwii> _MMA_ knows quite a few places
[00:39] <kwwii> the important thing is that is has to be done in concert with the gnome people upstream or it will never work
[00:39] <kwwii> much like the 2D panel icon stuff
[00:39] <kwwii> anyway, I was almost in bed
[00:40] <RzR> well i am about to go on vacations for 10 days
[00:40] <kwwii> tomorrow is a holiday here...see you soon
[00:40] <kwwii> hehe
[00:40] <kwwii> holidays are lovely
[00:40] <kwwii> keep in touch, I think it is an interesting idea
[00:40] <RzR> i'll think about moving this draft somewhere more appropriate
[00:41] <kwwii> the wiki would be a good place
[00:41] <RzR> but it'll takes time
[00:41] <kwwii> sure
[00:42] <RzR> well that's a long fight against photons :)
[00:42] <RzR> but darkness will win it's sure
[00:45] <kwwii> lol, right
[00:54] <RzR> jezz
[00:54] <RzR> i just reported a bug on wireshark
[00:55] <RzR> and there is a patch already
[00:55] <RzR> this sound promising
[00:56] <kwwii> time for sleep here, 2am...see you soon
[00:57] <RzR> same here
[00:57] <RzR> CET
[00:57] <RzR> see ya
[00:57] <RzR> kwwii: last question ?
[00:58] <RzR> kwwii: is it ok to forward darkmen here ?
[00:58] <_MMA_> Who or what is that?
[00:59] <RzR> darthemes users / bug hunters
[01:00] <_MMA_> damianvila: You not using Linux? :) Unless Miranda now has a nix client. :P
[01:01] <_MMA_> RzR: "darthemes" I'm sorry. I'm not up on that term.
[01:01] <RzR> we talked about it few hours ago
[01:01] <RzR> see
[01:01] <RzR> http://rzr.online.fr/q/dark
[01:03] <_MMA_> RzR: I think it's best you head up this.
[01:03] <_MMA_> If you make this channel a point of contact, people should look for you.
[01:04] <RzR> or other pple intressed into eye candy ...
[01:04] <_MMA_> Im not sure exactly what you're trying to accomplish.
[01:05] <_MMA_> Just making apps more "dark theme" compliant?
[01:05] <RzR> yes
[01:05] <_MMA_> Then you need to be the point of contact.
[01:05] <_MMA_> Otherwise people will come in looking for answers and people here will have no clue.
[01:06] <RzR> ok if it doesnt ruin my life i can manage this
[01:06] <_MMA_> Well then honestly I wouldn't start something and dump it here if you can head it up.
[01:06] <_MMA_> s/can/can't
[01:07] <RzR> no actually i dont know if this topic is interessing pple or not
[01:07] <RzR> and I cant run a irc desk 24*7
[01:08] <_MMA_> Then I wouldn't make this channel or mailing list a point of contact.
[01:08] <RzR> but I remove the irc references on my page ..
[01:08] <RzR> the point of contact is me actually
[01:09] <_MMA_> Sure. I just said don't make it just the channel. :)
[01:10] <RzR> it never was
[01:10] <_MMA_> "RzR: kwwii: is it ok to forward darkmen here ?" That implies you wanted to. I just said not to. ;)
[01:12] <RzR> the job will be fun when pple start complaining  about closed source applications :)
[01:13] <_MMA_> RzR@#ubuntu-artwork is fine but you said you didn't have the time to be here. So that actually a little unfair to people reading you wiki and to people here. Honestly if you don't have the time I wouldn't start this.
[01:14] <damianvila> Hi _MMA_ and everybody
[01:14] <damianvila> No, not on Ubuntu right now. Using XP actually
[01:15] <_MMA_> damianvila: I loved Miranda. I wish I could still use it.
[01:16] <damianvila> _MMA_: Fact is, when you want to fine tune a CSS, you better have good acces to all the browser engine, and I have it easy using XP for that
[01:17] <RzR> _MMA_: ok I understand no pb , you might be busy with other project too
[01:17] <damianvila> Yep. Adjusting some CSS for a popular site here in Spain :-)
[01:18] <RzR> _MMA_: BTW, I am thinking now, transparents icons on dark background may cause trouble too no ?
[01:23] <damianvila> So, what's going on here? Do we have the default theme for Intrepid yet? :-D
[01:24] <_MMA_> RzR: Correct.
[01:24] <_MMA_> damianvila: I get ya.
[01:25] <_MMA_> Brown=poop
[01:25] <_MMA_> Blue WTW!!
[01:25] <damianvila> lol
[01:25] <_MMA_> ;)
[01:26] <damianvila> I have a cool *alternative* idea for wallpapers, but I need to discuss it with Troy first :-P
[01:26] <_MMA_> pfftt... What does he know.
[01:26] <damianvila> lol
[01:27] <damianvila> How's Studio doing?
[01:31] <damianvila> Gimmmmme the default!!!!!! I want the defaaaaaault!!!!! lol
[01:35] <damianvila> D-E-F-A-U-L-T
[01:35] <_MMA_> damianvila: Studio is going well.
[01:35] <damianvila> Find out what it means to me...
[01:35] <_MMA_> Kinda takin' a break ATM.
[01:36] <damianvila> Oh!, cool
[01:36] <_MMA_> You sir, are not Aretha Franklin. ;)
[01:36] <damianvila> lol
[01:36] <damianvila> ;-)
[01:37] <damianvila> D-E-F-A-U-L-T
[01:37] <_MMA_> damianvila: We're waiting on the Intrepid stuff to get in place for the technical bits. I have some ideas art-wise.
[01:37] <damianvila> Take care, kwwii lol
[01:37] <_MMA_> But not anything solid yet. Ill do that after UDS.
[01:41] <damianvila> Any hints so far from sabdfl about what he wants (art-wise) for Intrepid?
[01:41] <_MMA_> Won't likely happen 'till after UDS.
[01:41] <damianvila> K
[01:41] <_MMA_> So 3 weeks or so.
[01:42] <damianvila> Where is it? (UDS)
[01:43] <_MMA_> Prague
[01:44] <damianvila> Oh! If they ever make one in Madrid I could attend... :-P
[01:44] <_MMA_> They did. (I think)
[01:45] <damianvila> Really?
[01:45] <_MMA_> Thought so. I'm gonna go to Dublin after Prague to hang out with Luis. (another Spaniard)
[01:46] <damianvila> Cool
[01:47] <_MMA_> damianvila: He was that guy we realized was like a block or 2 from you.
[01:47] <damianvila> I want to travel to Germany sometime. Czech Republic too.
[01:47] <_MMA_> Germany would be cool.
[01:47] <damianvila> _MMA_: Oh!, yes, I remember him.
[01:48] <_MMA_> Yeah. He got a job with Sun in Dublin.
[01:48] <_MMA_> Well, paid internship rather.
[01:48] <damianvila> Nice
[05:29] <troy_s> _MMA_: 67 MESSAGES!   Well.  So your estimate would be spot on.    Got not whitespace?
[07:40] <coz_> so anything new?  what wasnt in hardy is going to be worked on for Intrepid?
[10:41] <phoenix24_> Hi
[10:41] <phoenix24_> _MMA_,  ping
[10:42] <phoenix24_> kwwii, ping
[10:42] <phoenix24_> Is there a tools that automatically generates the gnome themes ?
[10:43] <phoenix24_> or one that allows users to customize those imported themes ?
[10:45] <thorwil> good morning nand
[10:47] <nand> thorwil: good morning!
[10:47]  * thorwil is at the drawing board
[10:48] <nand> is it national holiday day for you too?
[10:48] <nand> cool :)
[10:48] <thorwil> jepp
[12:27] <coz_> good day all
[14:58] <mysterycool> Hello.
[14:59] <mysterycool> When ubuntu developers say that we can submit our work, what kind of "work" do they mean?
[14:59] <mysterycool> I mean like, in what format? Ideas, sketches etc..?
[14:59] <thorwil> yes yes, that too
[15:00] <mysterycool> what do u mean that too
[15:00] <mysterycool> ?
[15:00] <mysterycool> :s
[15:00] <mysterycool> What do they exactly want us to submit?
[15:01] <thorwil> mysterycool: depends on what you want to work on and how far is developed
[15:01] <mysterycool> hmm, so u mean I could suggest ideas etc..?
[15:01] <thorwil> mysterycool: you sure can. but you know that basic ideas are cheap and plenty, right? ;)
[15:02] <mysterycool> erm...
[15:02] <mysterycool> XD
[15:02] <mysterycool> and btw, whats the UTC time anyway? :S
[15:02] <mysterycool> i mean, what timezone does it follow?
[15:03] <thorwil> mysterycool: it's the zero timezone, the mother, the origin, the center of the timezone universe, where everything starts
[15:03] <mysterycool> o_O
[15:03] <mysterycool> u mean greenwich timezone? XD
[15:03] <thorwil> yes, for all i know they are identical
[15:03] <thorwil> formerly known as GMT
[15:04] <mysterycool> yes
[15:05] <_MMA_> I *think* there is a time of year where they are an hour out of sync but I can't remember for sure.
[15:05] <mysterycool> hmm
[15:05] <mysterycool> shoot, lost today's meeting =[
[15:06] <thorwil> which one?
[15:06] <thorwil> _MMA_: i would like to punch all the people responsible for daylight savings time :>
[15:07] <_MMA_> :P
[15:07] <mysterycool> XD
[15:07] <mysterycool> :p
[15:07] <mysterycool> lol
[15:07] <mysterycool> XD
[15:08] <_MMA_> Couldn't that have been on 1 line? ;)
[15:08] <mysterycool> details XD :p
[15:53] <kwwii> btw, today is a holiday here so I am not around :p
[15:54] <_MMA_> kwwii: <insert smart-ass comment here>
[15:55]  * _MMA_ doesn't have his creative wit happening today.
[15:59] <thorwil> just today?
[16:04] <_MMA_> Yes.
[16:12] <kwwii> what is all the talk of _MMA_ having a supposed wit? nonsense!
[16:13] <_MMA_> kwwii: Aren't you supposed to be drinkin' a beer or something?
[16:14] <kwwii> I just rode 15 miles on my bike, no thanks on the beer
[16:15] <kwwii> actually, I just lit the fire in the grill
[16:15] <kwwii> we gonna have us a bar-b-q :-)
[16:18] <_MMA_> kwwii: Nice.
[16:50] <cody-somerville> _MMA_, Did you see my latest blog post?
[16:50] <_MMA_> I think it's safe to assume if its on Planet most people would. :)
[16:51] <nand> thorwil: hey, thanks! I answered on the ML
[16:51] <cody-somerville> _MMA_, :P
[17:04] <saltedlight> hello :)
[17:06] <coz_> hello all
[17:09] <_MMA_> hi
[17:14] <bersace> :(
[17:14] <bersace> seems that a lot of people are use to build linux artwork by copying proprietary os policy :(
[17:15] <saltedlight> :))
[17:15] <saltedlight> at least they do not use windows tools for that... or am i wrong? :))
[18:01] <coz_> saltedlight,  for artwork creating?  I use windows tools
[18:02] <DanaG> Too bad there's no equivalent of "SkinStudio" for GTK themes.
[18:08] <gaurav_> can i see some of the stuff you guys have created?
[18:08] <gaurav_> see what i'm up against, heheh
[18:10] <_MMA_> Some of mine: https://wiki.ubuntu.com/UbuntuStudio/Artwork
[18:11] <_MMA_> thorwil: You done any metacity hacking?
[18:38] <thorwil> _MMA_: nope
[18:41] <_MMA_> np. I got it sorted anyway. I needed to remove the app menu usually in the top left.
[19:19] <_MMA_> Can one override button_layout in Metacity with settings metacity-theme-1.xml?
[19:43] <_MMA_> damianvila: You ever hack on Metacity?
[19:45] <damianvila> No, frankly speaking, I'm just a designer, I don't have lots of technical knowledge and only deal with technical details if I'm obligued to.
[19:45] <_MMA_> Ok. :)
[19:47] <damianvila> I have enough knowledge so as to know what's possible and what not, but I get bored if I delve into technicalities :-P
[19:47]  * _MMA_ is delving into technicalities.
[19:48] <damianvila> That's why I tend to have lots of friends who know how to code :-D
[19:48] <_MMA_> Nice resource: http://developer.gnome.org/doc/tutorials/metacity/metacity-themes.html
[19:50] <damianvila> Wow!, cool!
[19:50] <damianvila> Doesn't look too difficult at all.
[19:50] <damianvila> In fact, I work a lot with XML at my work.
[19:50] <_MMA_> Makes looking at one you're working with easier to understand.
[19:51] <damianvila> Yep
[19:51] <damianvila> You know if it's difficult to add a tab to the GNOME Theme manager?
[19:52] <damianvila> Like they did with the "Effects" Compiz tab for Ubutu?
[19:52] <damianvila> *Ubuntu
[19:52] <_MMA_> damianvila: I think it requires writing C code. Would be a patch to the source.
[19:53] <damianvila> _MMA_: Oh!, i supposed it involved something like that :-P
[19:53] <damianvila> Have to talk to the GNOME guys then...
[19:55] <_MMA_> damianvila: Im really just guessing. :) I wouldnt think it was python or something.
[19:56] <damianvila> OK :-)
[23:45] <marcusrussi> where is the website for the theme that's in development?
[23:46] <marcusrussi> like for intrepid?
[23:56] <damianvila> https://wiki.ubuntu.com/Artwork/Incoming/Intrepid


[00:10] <niemeyer> davecheney: Will do
[00:15] <davecheney> niemeyer: ty
[00:16] <niemeyer> davecheney: The NewConfig branch seems polluted by an undeclared pre-req
[00:16] <niemeyer> davecheney: https://codereview.appspot.com/6209092/diff/10001/environs/ec2/ec2.go?column_width=80
[00:16] <davecheney> yeah, only open.go and open_test.go
[00:16] <davecheney> I will resubmit it once SetConfig is landed
[00:16] <niemeyer> davecheney: Ok, it'd be nice to get the diff fixed
[00:17] <davecheney> if you coudl take a cursory glance at environs/open{,_test}.go
[00:17] <davecheney> that is the only part changed
[00:17] <niemeyer> davecheney: It looks good
[00:18] <davecheney> its not a big change, just exposing the EnvironConfig before it gets passed to Open
[00:18] <niemeyer> davecheney: Yeah, it looks fine if that's all, but it'd be nice to clean up the diff before getting it in
[00:18] <davecheney> i will certainly do that
[00:21] <niemeyer> davecheney: Cool, should be a trivial LGTM after that
[09:32] <TheMue> morning
[09:44] <fwereade> heya TheMue
[09:49] <rogpeppe> TheMue, fwereade: yo!
[09:51] <TheMue> rogpeppe, fwereade: Heya
[09:51] <fwereade> rogpeppe, heyhey
[09:51] <rogpeppe> fwereade: i bet this weather is just what you're used to... were you really pining for a bit of old-fashioned english drizzle? :-)
[09:52] <fwereade> rogpeppe, well, it *is* really nice for about 10 minutes
[09:52]  * rogpeppe likes a bit of rain too
[09:52] <rogpeppe> but not for months on end :-)
[09:52] <fwereade> rogpeppe, after that I start to congratulate myself for moving ;)
[09:55]  * TheMue sits again on the veranda, right now 27°C and wonderful sun.
[10:20] <TheMue> So, short break, have to bring daughter to work.
[10:20] <Aram> morning.
[10:24] <fwereade> hey ra
[10:24] <fwereade> hey Aram
[11:25]  * davecheney waves to rogpeppe
[11:25]  * rogpeppe waves to davecheney
[11:25]  * rogpeppe waves to davechen1y
[11:25] <davecheney> so, how would you like to manage this merge ?
[11:26] <rogpeppe> davecheney: good question. if the ImageSpec->instanceSpec stuff can go in today, it would be quite nice if i could do them both at once.
[11:26] <davecheney> how is imagespec looking ?
[11:26] <rogpeppe> davecheney: i've spent... too much time pissing around with splitting up branches and merging and remerging
[11:26] <davecheney> f'yeah, i'm over reqs
[11:27] <rogpeppe> davecheney: it should be good to go, but it needs gustavo's go ahead because i'm not quite sure what he wants in the doc comments.
[11:27] <davecheney> that is cool
[11:27] <rogpeppe> davecheney: it should be less important now that i've unexported the types.
[11:27] <davecheney> i'm happy to wait for those two to go in
[11:27] <davecheney> then I'll merge and adjust as needed
[11:27] <davecheney> gostavo has LGTM in principal the various bits
[11:27] <rogpeppe> davecheney: thanks.
[11:27] <davecheney> i'm sad that the proxy idea didn't get up
[11:28] <davecheney> but at the end of it I couldn't offer a strong enough argument over Environ.SetConfig
[11:28] <rogpeppe> davecheney: i think it made sense. but i suppose it only makes sense when the provider has no state
[11:28] <davecheney> possibly if there was going to be more than one PA
[11:28] <davecheney> once we have somethig working
[11:29] <davecheney> i'll hvae another crack at introducing the proxy idea
[11:29] <davecheney> as a way of seperating concerns
[11:29] <rogpeppe> davecheney: i quite liked the "return a proxy within ec2" idea
[11:29] <davecheney> I was thinking proxy.(*proxyEnviron).SetConfig(config)
[11:29] <davecheney> which would reload it on command
[11:30] <davecheney> which might resolve gustavo's concerns about control
[11:30] <davecheney> from my vantage point, the Environs themselves contain almost no state
[11:30] <rogpeppe> davecheney: i was thinking type Proxy struct {env environs.Environ}
[11:30] <davecheney> yup
[11:30] <davecheney> or even
[11:31] <davecheney> type Proxy struct { environs.Environ }
[11:31] <rogpeppe> davecheney: and then environs.config.Open returns Proxy{ec2environ}
[11:31] <davecheney> but that has visilibity problems
[11:31] <davecheney> anyway, i'll wait til we have something that works
[11:31] <rogpeppe> davecheney: yeah, i think you want to be sure that all methods are reimplemented
[11:31] <davecheney> rather than spinning on this
[11:32] <rogpeppe> davecheney: yeah, the current thing will work.
[11:33] <davecheney> from my POV I need some commands to do some functional testing on the PA
[11:33] <davecheney> but I was wondering how jujuc is coming along ?
[11:33] <rogpeppe> davecheney: it needs more stuff.
[11:34] <davecheney> from a quick look at the supercommand stuff
[11:34] <rogpeppe> davecheney: i'm sure fwereade will be cranking out more commands soon though
[11:34] <davecheney> i can add extra commands to the framework pretty simply
[11:34] <rogpeppe> davecheney: by "functional testing" you mean ad-hoc testing?
[11:34] <davecheney> I basically need to invoke, addmachine and remove machine
[11:34] <davecheney> in another window
[11:34] <rogpeppe> davecheney: can't you write tests that use the State methods to do that?
[11:35] <davecheney> i also need to figure out how to hook the provisioning command up to StateTest so I can do unit tests against dummy with it
[11:35] <rogpeppe> davecheney: i tend not to do any ad-hoc testing, but maybe that's wrong. that was always the only method i ever used, in previous lives...
[11:36] <davecheney> i've found there is value in doing both
[11:36] <davecheney> for example I wrote a quick SOCKS over ssh proxy
[11:36] <davecheney> then left that running on the open internet for a day to load test the ssh client code
[11:36] <rogpeppe> davecheney: these days i tend to put the effort i would spend on thinking of ad hoc tests into thinking of reusable tests
[11:37] <rogpeppe> davecheney: there's definitely room for functional testing, but even then i think there's value in scripting it.
[11:37] <rogpeppe> davecheney: and until we have a framework for that, maybe we should just spend time writing unit tests as good as we can think of.
[11:38] <davecheney> of course, hence the need for simple cli tools to push the state around so I can watch the PA recact to it
[11:39] <rogpeppe> davecheney: i think i'd just hook them both up to the same zk and use the state methods and check that the pa reacts in the correct way.
[11:39] <rogpeppe> davecheney: perhaps using the dummy provider so you can read actions as they take place.
[11:39] <davecheney> yup, i'm not sure how much of that harness exists atm
[11:40] <davecheney> i know environs/jujutest does some of it
[11:40] <rogpeppe> davecheney: cmd/juju does a certain amount of it.
[11:40] <rogpeppe> davecheney: really, i think it would be nice if the dummy provider could be configured to start zk
[11:41] <rogpeppe> davecheney: then we get an almost-complete environment for testing.
[11:41] <davecheney> i'll look into that
[11:41] <davecheney> i don't think it does that at the moment
[11:41] <rogpeppe> davecheney: it doesn't
[11:41] <rogpeppe> davecheney: it shouldn't be hard though, particular with the recent refactoring of it i've done.
[11:41] <davecheney> in fact I think it works the opposite, it waits for the juju/testing to make a zk
[11:41] <davecheney> indeed
[11:41] <davecheney> i'll look at it tomorrow
[11:43] <davecheney> rogpeppe: can you chain req branches ?
[11:43] <rogpeppe> davecheney: yeah
[11:44] <davecheney> ie propose a, propose b -req a, propose c -req b
[11:44] <rogpeppe> davecheney: although it's a hassle, because once you've changed the base, you have to remerge all the subsequent branches in the chain
[11:44] <davecheney> yes, that doth blow
[11:45] <rogpeppe> davecheney: but tbh, it's not as bad as it was. you really only need to remerge when you come to actually submit the next branch.
[11:45] <davecheney> i'm looking forward to phase of th eproject when we've got something we can itterate on
[11:45] <rogpeppe> davecheney: definitely.
[11:45] <davecheney> when I was building the platform at atlassian we got a prototype working very quickly
[11:45] <rogpeppe> davecheney: i'm just about to propose a branch that gets the go tools and runs them on the server side, BTW
[11:46] <davecheney> but then there was a big gap of nearly 2 months before we got the next version working
[11:46] <rogpeppe> davecheney: we've already got a prototype - the python version...
[11:46] <davecheney> rogpeppe: nice
[11:46] <davecheney> rogpeppe: the first version of the atlassian platform was three desktops that we built by hand
[11:46] <davecheney> but the next version took a long time because we decided to build all the automation first
[11:47] <davecheney> but, once it was running itteration was very fast
[11:47] <rogpeppe> davecheney: i think that the Go version will be nice to iterate on when we've got it up.
[11:47] <davecheney> yup
[11:47] <rogpeppe> davecheney: i'm quite happy with how the overall structure is turning out
[11:48] <rogpeppe> davecheney: slight misgivings about the whole necessity of the State abstraction, as you pointed out, but i'm ok with it.
[11:49] <davecheney> rogpeppe: tell me more
[11:50] <rogpeppe> davecheney: i think it was you that suggested that all of state could be represented more compactly by a simple parent/child/attribute abstraction.
[11:51] <davecheney> I was thinking that I would like it if I could as the topology for a watcher, rather than the way watchers are quite chummy with the zk nodes themselves
[11:51] <rogpeppe> s/as the/ask the/ ?
[11:52] <davecheney> ya
[11:52] <davecheney> for the particular example of wtching machines
[11:52] <davecheney> I want the ability to subscribe to a part of the toploogy
[11:52] <davecheney> what we have now works fine
[11:52] <rogpeppe> davecheney: +1
[11:52] <davecheney> watch /topology, then parse the full thing
[11:53] <davecheney> but given that the State already has the whole topology as a data structure
[11:53] <davecheney> it would make sense that it could push data to any watcher directly
[11:53] <davecheney> but I wonder if gustavo has plans for the topology
[11:53] <davecheney> as it is a crutch for the limitations of zk
[11:53] <rogpeppe> davecheney: i think the eventual idea is that we push all of state behind a server API
[11:54] <davecheney> at which point all the watchers are going to be pub/sub kind of things
[11:54] <rogpeppe> davecheney: then we don't have to worry about atomic changes to the topology because the server can mediate that
[11:54] <rogpeppe> davecheney: exactly
[11:54] <davecheney> speaking of Environs
[11:55] <rogpeppe> davecheney: it's interesting to think about what level we might want the server API
[11:55] <davecheney> I was going to try a branch that removes the requirement to pass state.Info to Environ.StartInstance
[11:55] <rogpeppe> davecheney: how would the new instance know how to connect to the state then?
[11:55] <davecheney> rogpeppe: i hope it looks like a URL tree
[11:55] <davecheney> pretty much the same as the zk topology
[11:55] <davecheney> but with REST calls that you can subscribe to changes to a path and it's children, etc
[11:55] <rogpeppe> davecheney: yeah, but what level of abstraction are the URLs?
[11:56] <davecheney> without giving it any thought
[11:56] <rogpeppe> davecheney: i dunno. i was wondering about something higher level.
[11:56] <davecheney> i think the URL's should look like the current ZK path
[11:56] <davecheney> but that is without giving it any serious consideration
[11:56] <rogpeppe> davecheney: i don't think so, actually. i think that constrains the possibilities to db optimisation.
[11:56] <rogpeppe> s/to db/for db/
[11:57] <rogpeppe> davecheney: higher level API gives more scope for changing the impl behind the scenes
[11:57] <rogpeppe> davecheney: anyway... back to ground level
[11:57] <davecheney> yeah
[11:57] <rogpeppe> davecheney: how does StartInstance work without having a StateInfo?
[11:57] <rogpeppe> s/does/would/
[11:58] <davecheney> there is a StateInfo method on the Environ itself
[11:58] <davecheney> ergo, it already knows it's state
[11:58] <davecheney> err, state.Info
[11:58] <rogpeppe> davecheney: not necessarily. i wanted to keep open the possibility that one environ might connect to a state from elsewhere.
[11:58] <rogpeppe> davecheney: there's no essential connection between a state and a given environ.
[11:59] <rogpeppe> davecheney: for instance, at some point in the future, we want to have the possibility of several environments using the same "bootstrap" node.
[12:00] <fwereade> rogpeppe, hmm, my reading of that had been that they'd still be separate states despite all happening to coexist within the same zookeeper (there's a chrooty thing for ZK, right?)
[12:00] <fwereade> rogpeppe, it feels to me like a state is pretty strongly associated with an environ
[12:01] <davecheney> fwereade: i agree
[12:01] <davecheney> so either Environ gets closely bound to a state.Info, or is completely abstracted from it
[12:01] <davecheney> either way, the requirement to pass state.Info in StartInstance will go away
[12:02] <fwereade> rogpeppe, davecheney: yeah, that param definitely feels wrong to me
[12:02] <davecheney> fwereade: rogpeppe i'm guessing it's there to pass details to the machine agent on how it can find the ZK and bootstrap itself so to speak ?
[12:03] <rogpeppe> davecheney: yes, at least that. i'm trying to remember the other scenarios.
[12:03] <davecheney> or to say it another way, how it can build and Environ that matches that of the Provisioning Agent that created it
[12:03] <fwereade> davecheney, rogpeppe: sorry, I'm confused... doesn't the environ already know its own state info?
[12:03] <davecheney> fwereade: yes, it must, because there is this method
[12:04] <davecheney> Environ.StateInfo
[12:04] <rogpeppe> fwereade: only if you've bootstrapped it.
[12:04] <davecheney> rogpeppe: i'm happy with that restriction, the PA doesnt' run til bootstrapping is complete, unless i'm mistaken
[12:04] <rogpeppe> fwereade: but you could reasonably have an environ that you hadn't bootstrapped, but were using with a provisioning agent and a state from somewhere else, i think.
[12:04] <fwereade> rogpeppe, ok, but if you haven't bootstrapped it you don't have a state: you just know that there *will* be one on localhost once bootstrap is complete
[12:05] <davecheney> rogpeppe: ah, i see what i'm missing
[12:05] <davecheney> bootstrapping uses Environ.StartInstance to start machine(0)
[12:06] <rogpeppe> davecheney: actually, it uses startInstance; slightly different.
[12:06] <davecheney> still, possibly a strategic nil could be passed, suggesting, use whatever state you have internally
[12:07] <rogpeppe> part of the problem is we don't want to pass the ec2 secret key in the cloudinit script
[12:07] <fwereade> davecheney, rogpeppe: it feels to me like bootstrap is the special case, and it's misleading to expose those details to the outside world
[12:07] <davecheney> i concur
[12:08] <rogpeppe> hmm, i think it feels quite clean actually. we explicitly tell the new machine how to connect to the juju state.
[12:08] <rogpeppe> it's always going to need to do that, i think.
[12:08] <fwereade> rogpeppe, but the environ is so closely tied to the state that it feels wrong to have to tell it again
[12:09] <rogpeppe> fwereade: i don't see the coupling as that close actually.
[12:10] <fwereade> rogpeppe, Environ.StateInfo implies otherwise, to me
[12:10] <rogpeppe> fwereade: i like the idea of being able to have the machines in a single environ controlled by multiple states, for example.
[12:11] <fwereade> rogpeppe, sure, that has potential: but I'm pretty sure that's not what we're implementing right now :p
[12:11] <fwereade> rogpeppe, would you say that Environ.StateInfo was a misstep that we should remove?
[12:11] <davecheney> fwereade: rogpeppe it appears to me that if the environ has a StateInfo method, then it knows it's own state, so StartInstance shuldn't need to be told a stateinfo
[12:12] <fwereade> davecheney, exactly so
[12:12] <davecheney> on the other hand, if the envion shuldn't need to know about the stae, then the StateInfo method is misleading
[12:12] <rogpeppe> davecheney: no, i don't think an environ does know its own state
[12:12] <davecheney> as it stands, it's not a big deal to do si, _ := environ.StateInfo(); environ.StartInstance(99, si)
[12:12] <rogpeppe> davecheney: the private keys are not accessible to an environ for example
[12:13] <davecheney> rogpeppe: then what is returned from environ.StateInfo() is not actually useful then ?
[12:13] <davecheney> oh, hang on
[12:13] <davecheney> i'm talking about stateInfo, which is just a pretty connection string to find zookeepers
[12:15] <fwereade> davecheney, I must have missed something; how does that change things?
[12:16] <davecheney> fwereade: 22:12 < rogpeppe> davecheney: the private keys are not accessible to an environ for example
[12:16]  * rogpeppe is thinking
[12:16] <davecheney> ^ i interprited that to mean more than it did
[12:16] <fwereade> davecheney, ah, cool, thanks
[12:16] <rogpeppe> davecheney: yeah, and i'm not sure i meant what i said.
[12:17] <davecheney> fwereade: rogpeppe i'm sure this is over simplifying this, but for the privisioning, machine and unit agents
[12:17] <davecheney> to get up and running
[12:17] <davecheney> all then need to know is the argument they are passed to jujud, and a stateinfo, which is really just a string passed to --zookeeper-servers
[12:18] <fwereade> davecheney, yes, essentially
[12:18] <davecheney> and so, Environ.StartInstance() is shorthand for 'start a new machine, and run this daemon passing these arguments'
[12:18] <fwereade> davecheney, the PA also needs to know the environ, and the UA/MA need to know what U/M they's acting for
[12:18] <davecheney> yeah, there is clearly more too it than I just glossed over
[12:19] <davecheney> but from the point of view of 'how do I find zookeeper so I can watch stuff'
[12:19] <rogpeppe> davecheney: one issue is the possibility that we need a different internal vs external IP address. i'm not *sure* that the environ is in a good place to know which to use.
[12:20] <fwereade> davecheney, sure, understood
[12:20]  * fwereade thinks
[12:20] <davecheney> rogpeppe: for the short term (read ec2 and workalikes) I think we can use the assumption that all machiens in the same environment areusing the same network
[12:20] <rogpeppe> davecheney: what about the juju client?
[12:21] <fwereade> davecheney, it still seems to me that the fact that there's a different ZK address is an incredibly minor aspect of the things that are different when starting the first node
[12:21] <davecheney> rogpeppe: good point, i don't have an answer to that, other than saying we probably need two state.Info's
[12:21] <davecheney> external and internal
[12:21] <davecheney> or something that clearly identifies external (as in not inside the environment) and internal (that are)
[12:21] <davecheney> otherwise we'll go mad with the permutations
[12:22] <rogpeppe> davecheney: how does a machine know if it's internal or external?
[12:22] <davecheney> jujuc == external, jujud == internal
[12:22] <davecheney> as a start
[12:22] <fwereade> davecheney, so it feels wrong to push that one specific difference up to that level while leaving the others implicit
[12:22] <fwereade> davecheney, wait, what?
[12:23] <davecheney> but trying to make one connectino string serve two masters sounds worse
[12:23] <davecheney> rogpeppe: as I understand it, all machines are internal; the are inside the environment
[12:23] <rogpeppe> currently StateInfo returns the external address.
[12:23] <davecheney> if ec2 lets that work, then it's a solved problem for now
[12:23] <rogpeppe> davecheney: the difficulty is that Environ is used by the client as well as the cloud machines
[12:24] <rogpeppe> davecheney: i think the connection methods are different too. i'm not sure we use ssh between cloud machines.
[12:25] <davecheney> ahh, so the reason StartInstance takes a state.Info is to allow us to construct an 'internal' connection string
[12:25] <rogpeppe> davecheney: that's certainly one reason, yes.
[12:26] <fwereade> davecheney, rogpeppe: hmm... except when bootstrapping, the state info comes from an Instance, right?
[12:27] <fwereade> davecheney, rogpeppe: which already knows both internal and external addresses
[12:27] <rogpeppe> fwereade: no, it comes from the private storage
[12:27] <fwereade> rogpeppe, how did it get there?
[12:27] <rogpeppe> fwereade: it was put there at bootstrap time.
[12:27] <fwereade> rogpeppe, if not from the Instance constructed on bootstrap
[12:27] <rogpeppe> fwereade: at that time we don't know the DNS addresses of the instance.
[12:28] <davecheney> rogpeppe: fwereade reviewing state/open.go, State info has a slice of addresses to connect to, is that what you mean by internal and external ?
[12:28] <fwereade> rogpeppe, wait, you just said the information was put in provider storage at bootstrap time
[12:28] <rogpeppe> fwereade: the instance id only
[12:29] <fwereade> davecheney, no, the slice is all ZKs; internal/external is just about what address we use to connect to a ZK or group thereof
[12:29] <rogpeppe> so... if i understand the general idea, we could have ...
[12:29] <fwereade> rogpeppe, ok, and the instance id is used at some point to get an Instance, from which we get the public address and discard the private?
[12:30] <rogpeppe> one mo, tel call
[12:30] <fwereade> rogpeppe, ...and we're now discussing how we go about reacquiring the private address?
[12:30] <rogpeppe> fwereade: yeah
[12:30] <fwereade> rogpeppe, it seems to me that the trouble is in throwing away half the information in the first place
[12:31] <rogpeppe> so... if i understand the general idea, we could have a "local" argument to StateInfo which determines which info to get.
[12:31] <rogpeppe> 'cos we can't get rid of StateInfo entirely, right?
[12:32] <rogpeppe> so we're suggesting that StartInstance call StateInfo(local) inside itself, rather than taking an explicit state.Info arg?
[12:33] <fwereade> rogpeppe, perhaps something like that: I haven't thought it through entirely
[12:33] <davecheney> rogpeppe: i'd like to try that
[12:33] <fwereade> rogpeppe, but it feels like a potentially fruitful avenue
[12:33] <rogpeppe> i don't really see the point. i don't think it'll make anything significantly simpler
[12:33] <davecheney> or at least have StartInstance(314, nil) as a sentinal for 'pass whatever state.Info you know/makes sense/sounds best'
[12:34] <davecheney> rogpeppe: as it sounds like the reason StartInstance takes a state.Info is to facilitate bootstrapping
[12:34] <fwereade> davecheney, doesn't StartInstance imply non-bootstrap in the first place?
[12:34]  * davecheney shrugs
[12:35] <rogpeppe> fwereade: yes
[12:35] <fwereade> davecheney, rogpeppe: I'm not bothered what we pass to startInstance, but I'm concerned about dirtying up StartInstance when in practice it will *always* be called with nil... won;t it?
[12:35] <fwereade> davecheney, rogpeppe: ... or  .StateInfo
[12:35] <fwereade> davecheney, rogpeppe: depending on how we do the details
[12:36] <rogpeppe> fwereade: it means that StartInstance will have to read the provider local storage each time, i think.
[12:36] <davecheney> fwereade: or to put it another way, if the PA has to call StartInstance when it sees a machine appear in the topology, what is it supposed to use for that argument
[12:36] <davecheney> at this moment the only thing it can use is the value from a.Conf.StateInfo
[12:37] <davecheney> which comes from the jujud super command framework
[12:37] <fwereade> davecheney, rogpeppe: how does the same argument not apply to Environ.StateInfo?
[12:37] <davecheney> fwereade: that is an intersting one
[12:37] <rogpeppe> fwereade: if the caller already has a StateInfo, it can pass that to StartInstance each time.
[12:37] <davecheney> the PA is connected to a state.State
[12:38] <davecheney> it find a *ConfigNode by watching /enviornment, and passes that to environs.NewEnviron
[12:38] <davecheney> and gets an Environ
[12:38] <rogpeppe> if at some point we want to be able to adjust the set of database machines at runtime, it will be good to be able to do that through the existing state.
[12:38] <davecheney> what that environ.StateInfo() returns is a damn good question
[12:39] <rogpeppe> davecheney: the bucket will be configured in the attributes it passes to SetConfig
[12:39] <rogpeppe> davecheney: and that's what StateInfo will use to return the state.Info
[12:39] <fwereade> rogpeppe, we surely will at some stage... in which case surely the right answer *is* to read it every time
[12:40] <fwereade> rogpeppe, but this seems essentially orthogonal to the question of whether it needs to be passed to StartInstance
[12:40] <rogpeppe> fwereade: i'm not sure. i think the provider storage is good for bootstrap, but we can use other means when we're up and running.
[12:41] <rogpeppe> fwereade: bootstrap and client connections, of course.
[12:41] <rogpeppe> fwereade: there's no way of *watching* provider storage, i think
[12:41] <fwereade> rogpeppe, I thought you said bootstrap didn't use StartInstance
[12:42] <fwereade> rogpeppe, davecheney: oh hell, EOD, got to go to the bank :(
[12:42] <rogpeppe> BTW the provider state is written *after* the bootstrap node is successfully started.
[12:42] <fwereade> rogpeppe, davecheney: hope I wasn't just muddying the waters for you
[12:42] <rogpeppe> fwereade: no, it's all good stuff
[12:42] <fwereade> rogpeppe, I know; don't get current significance though
[12:43] <davecheney> +1
[12:43] <rogpeppe> fwereade: it means that the bootstrap node doesn't necessarily have access to the provider state when it starts.
[12:43] <rogpeppe> of course in practice with ec2, it's so slow that it will in fact.
[12:44] <fwereade> rogpeppe, but we bake the stateinfo into cloud-init regardless
[12:44] <rogpeppe> fwereade: we can't do that if we can't pass it in to StartInstance
[12:45] <rogpeppe> fwereade: because StartInstance will, of necessity, retrieve the state info from the provider storage bucket
[12:45] <fwereade> rogpeppe, but the environ *knows* it's bootstrapping, and it fully controls the cloud-init, and it *knows* it's starting a ZK and relevant agents on that instance, and hence it *knows* that it can use localhost
[12:45] <fwereade> rogpeppe, and did I misunderstand about StartInstance not actually being used to bootstrap anyway?
[12:46] <rogpeppe> fwereade: i'm not sure that the Environ knows that it's on a bootstrap node.
[12:46] <davecheney> if I can interrupt for a moment
[12:46] <rogpeppe> davecheney: please do
[12:47]  * fwereade listens
[12:47] <davecheney> is the reason we're saying 'we can't just let the Environ pass what it' thinks is it's state info to any new machine via StartInstance' is because it might have 'localhost' as its zk host ?
[12:47] <rogpeppe> davecheney: that's not the only reason.
[12:47] <rogpeppe> davecheney: the reason we were just talking about was that there's more than one source for a StateInfo
[12:48] <rogpeppe> davecheney: it might come from the provider storage; or it might come from being passed into the cloudinit script.
[12:48] <davecheney> rogpeppe: but from the POV of the PA, there is only one stateinfo
[12:48] <davecheney> their are many, but this one belongs to the PA
[12:48] <rogpeppe> davecheney: yeah, the one that's passed on the command line
[12:48] <fwereade> davecheney, rogpeppe: I do actually have to go now; ttyl :)
[12:48] <rogpeppe> fwereade: k
[12:48] <davecheney> kk
[12:48] <rogpeppe> fwereade: c u tomorrow
[12:49]  * rogpeppe also has to go to lunch soon
[12:49] <davecheney> fair enough, lets wrap up
[12:49] <davecheney> from what i've read today, the best course of action is to not change naything
[12:49] <davecheney> the PA calls environ.StartInstance(999, a.Conf.StateInfo)
[12:50] <davecheney> we'll revisit it later, if necessary
[12:50] <rogpeppe> davecheney: i *think* that's good. i'm open to the idea of a change, but in this case i'm not sure it helps much.
[12:51] <rogpeppe> davecheney: passing in StateInfo explicitly means the environ doesn't need to care how we got it.
[12:52] <rogpeppe> davecheney: which i *think* is a reasonable separation of concerns. but please keep on considering alternatives!
[12:52] <rogpeppe> right, lunch!
[12:53] <rogpeppe> davecheney: see you tomorrow, i hope, if i get up early enough.
[13:09] <davecheney> rogpeppe: kk, i'll catch you on the next rotation
[13:54] <andrewsmedina> rogpeppe: hi
[13:55] <andrewsmedina> rogpeppe: I sent another review
[13:58] <rogpeppe> andrewsmedina: thanks. i'll take a look.
[14:03]  * niemeyer waves
[14:03] <rogpeppe> niemeyer: yo!
[14:07] <rogpeppe> andrewsmedina: LGTM
[14:07] <andrewsmedina> rogpeppe: thanks \o/
[14:08] <rogpeppe> niemeyer: i updated https://codereview.appspot.com/6188068/ to unexport the types and change the docs. hopefully should be better now.
[14:09] <niemeyer> rogpeppe: Cool, thanks
[14:09] <niemeyer> rogpeppe: Agreed regarding it going out of the ec2 package eventually
[14:09] <niemeyer> rogpeppe: We don't have to do that now, but let's just watch out to lead the code towards making them sensible there (it's already going in that direction it seems)
[14:10] <rogpeppe> niemeyer: will do.
[14:14] <TheMue> niemeyer: Moin and thx for the reviews.
[14:14] <niemeyer> rogpeppe: It actually feels like going backwards a bit
[14:15] <rogpeppe> niemeyer: oh?
[14:15] <niemeyer> rogpeppe: All those field name changes will have to go back again in the next branch that does the actual switch over
[14:15] <niemeyer> rogpeppe: The way we have colseries and colServer also feels quite awkward
[14:15] <niemeyer> rogpeppe: These names should be internally consistent
[14:16] <rogpeppe> niemeyer: i'm not sure. it's only the instance contraint that will have to change
[14:16] <rogpeppe> niemeyer: colseries is my mistake - a global replace too enthusiastic!
[14:16] <niemeyer> rogpeppe: Ah, phew
[14:16] <niemeyer> TheMue: Heya!
[14:16] <niemeyer> TheMue: np
[14:16] <rogpeppe> niemeyer: i think that instanceSpec will remain private
[14:16] <rogpeppe> niemeyer: and instanceConstraint will be significantly different
[14:17] <niemeyer> rogpeppe: I'm tempted to suggest moving the InstanceConstraints to environs right now
[14:17] <rogpeppe> niemeyer: so i don't mind it being private now
[14:17] <niemeyer> rogpeppe: If it will be significantly different, we're doing it wrong
[14:17] <rogpeppe> niemeyer: can we leave it as it is - i've got three upstream branches that i'm juggling on top of this one
[14:17] <rogpeppe> niemeyer: then i can do the constraints stuff later
[14:18] <niemeyer> rogpeppe: Yep, sure
[14:20] <niemeyer> rogpeppe: Done
[14:20] <rogpeppe> niemeyer: thanks a lot
[14:20] <niemeyer> rogpeppe: np
[14:46] <rogpeppe> niemeyer: remind me again how i can get the full revision id for the current branch out of bzr, please.
[14:46] <rogpeppe> niemeyer: my google-fu has deserted me
[14:46] <niemeyer> rogpeppe: revision-info should do
[14:46] <rogpeppe> ah!
[14:47] <rogpeppe> niemeyer: i was trying revno and info
[14:47] <niemeyer> rogpeppe: revision-info --tree is relevant in some cases
[14:47] <rogpeppe> revno -v should do it, i reckon
[14:51] <smaddock> bcsaller: ping
[15:12] <niemeyer> Lunch, biab
[16:08] <niemeyer> TheMue: ping
[16:08] <TheMue> niemeyer: pong
[16:08] <niemeyer> TheMue: yo
[16:08] <niemeyer> TheMue: Would you mind if we at least delayed the addition of that method?
[16:09] <niemeyer> TheMue: It feels like an awkward interface to me.. I can't see what this method is offering that we can't do with the other methods we have
[16:09] <TheMue> niemeyer: So far I've got no problem. The original is used two or three times (beside the tests).
[16:09] <niemeyer> TheMue: So it'd be awesome if we could keep that out while we figure the answer for that
[16:09] <TheMue> niemeyer: So I'll see when I reach this point.
[16:10] <niemeyer> TheMue: I'm sure it's used, but I think we have a better interface that may enable its original use case withou tit
[16:10] <andrewsmedina> niemeyer: https://codereview.appspot.com/6099051/
[16:10] <niemeyer> andrewsmedina: Neat, will give it a final pass
[16:10] <TheMue> niemeyer: OK, so I'll kick it with the next proposal.
[16:11] <niemeyer> TheMue: Cheers, please ping me once you're done.. I suspect it's ready for going in, and will check as soon as you push
[16:11] <niemeyer> andrewsmedina: Why network.Subnet has no xml tag?
[16:14] <andrewsmedina> niemeyer: its only used to create a new net
[16:16] <andrewsmedina> niemeyer: this attribute is not returned in the xml generated by virsh
[16:19] <niemeyer> andrewsmedina: Cool
[16:22] <niemeyer> andrewsmedina: The tests will fail without root, right?
[16:29] <andrewsmedina> niemeyer: wrong
[16:29] <niemeyer> andrewsmedina: Ah, you're faking the whole thing.. hmmm
[16:29] <niemeyer> andrewsmedina: That's both nice, and not'''
[16:30] <andrewsmedina> niemeyer: yes...
[16:30] <niemeyer> andrewsmedina: Either way, we can move forward like that and address it later
[16:30] <niemeyer> andrewsmedina: It's better then the opposite I guess
[16:31] <andrewsmedina> niemeyer: but it was the only way that I found not to change the network configuration of the machine on which the tests have been run
[16:32] <niemeyer> andrewsmedina: Yeah, that's what I mean.. your approach is better than being *just* on the other side of the fence
[16:32] <niemeyer> andrewsmedina: At some point in the future, once that's all working well, we can add some extra tests to *optionally* guarantee that it works for real
[16:32] <niemeyer> andrewsmedina: Or maybe not.. external functional tests would deal with that too
[16:32] <niemeyer> andrewsmedina: Either way, you have a review with a few trivialities, and LGTM
[16:33] <niemeyer> andrewsmedina: Please ping me once these are done and I'll submit
[16:33] <niemeyer> andrewsmedina: (rog had a trivial too)
[16:33] <andrewsmedina> niemeyer: ok
[16:33] <andrewsmedina> niemeyer: what trivial rog had?
[16:33] <niemeyer> andrewsmedina: It's in the CL
[16:33] <andrewsmedina> where?
[16:34] <niemeyer> andrewsmedina: https://codereview.appspot.com/6099051/diff/15001/environs/local/network.go#newcode92
[16:34] <niemeyer> andrewsmedina: Also part of the LGTM mail he sent
[16:36] <andrewsmedina> niemeyer: I will work on these issues
[16:43] <andrewsmedina> brb
[16:50] <TheMue> niemeyer: ping, propose is in.
[16:59]  * hazmat lunches
[17:00] <rogpeppe> niemeyer: this should be trivial: https://codereview.appspot.com/6257043/
[17:05] <niemeyer> TheMue: Cheers
[17:05] <niemeyer> rogpeppe: Cool
[17:06] <rogpeppe> niemeyer: as should this: https://codereview.appspot.com/6249049/
[17:07] <rogpeppe> niemeyer: and the one after that is the important one... just doing final amazon test now before proposing
[17:08] <niemeyer> rogpeppe: LGTM on first
[17:08] <rogpeppe> niemeyer: thanks a lot
[17:09] <niemeyer> rogpeppe: LGTM on second too, thanks
[17:09] <niemeyer> TheMue: Going through it now
[17:09] <rogpeppe> niemeyer: lovely jubbly, ta
[17:09] <TheMue> niemeyer: great, thx
[17:23] <rogpeppe> niemeyer: here's the boy: https://codereview.appspot.com/6245048
[17:23] <rogpeppe> niemeyer: i tried to split it up more, but it wasn't having any of it (too much interdependency)
[17:23] <rogpeppe> niemeyer: if it's any consolation, the code ends up 200 lines *shorter* after this CL...
[17:24] <rogpeppe> niemeyer: gotta go now.
[17:24] <niemeyer> rogpeppe: Super, thanks a lot
[17:24] <rogpeppe> niemeyer: i'll be quite excited if this goes in
[17:25] <rogpeppe> niemeyer: see ya tomorrow
[17:25] <niemeyer> rogpeppe: Well it will certainly go in
[17:25] <niemeyer> rogpeppe: Cheers
[17:26] <rogpeppe> niemeyer: well, you might say it's too big or just wrong or something :-)
[17:26] <niemeyer> rogpeppe: I can't anticipate that, but the concept of the feature we want for sure
[17:42] <niemeyer> TheMue: Sorry, ended up sidelined by other conversations.. back to the review
[17:42] <TheMue> niemeyer: np
[17:43] <niemeyer> TheMue: "It's allowed today in endpoint.py. Maybe it's an error there too?"
[17:43] <niemeyer> TheMue: I believe it is.. can you please drop it so that we can be sure about what's going in?  If we find issues, it'll be a nice insight
[17:44] <TheMue> niemeyer: Ok, will be dropped.
[17:46] <niemeyer> TheMue: "// /topology node in ZooKeeper.s"
[17:46] <niemeyer> TheMue: Extra "s" at the end, topology.go line 46
[17:47] <niemeyer> TheMue: LGTM with these sorted. Thank you!
[17:47] <niemeyer> TheMue: Review delivered for the record too
[17:49] <TheMue> niemeyer: Thanks. The s may be from saving without ctrl. ;)
[17:55] <niemeyer> TheMue: Hehe, I know how these go :)
[18:02] <TheMue> niemeyer: Sh.., had to leave computer, "accident" here. My wife lost her earring into the plughole. *sigh*
[18:06] <niemeyer> TheMue: Wow, what/
[18:06] <niemeyer> ?
[18:06] <niemeyer> TheMue: Oh, ok
[18:07] <niemeyer> TheMue: Did you pick it up?
[18:36] <niemeyer> robbiew: Is it meeting time?
[18:37] <robbiew> yesss!...one sec
[18:38] <robbiew> g+ invite sent
[18:39] <niemeyer> Cheers
[18:58] <TheMue> niemeyer: So, final propose before LGTM. And the earring has to wait, I had to bring my daughter to before. Tasks when the kids grow. ;)
[18:59] <niemeyer> TheMue: Cool :)
[18:59] <niemeyer> TheMue: With robbiew, will check it right afterwards
[19:05] <TheMue> niemeyer: Fine, so I can submit it later or as my first task tomorrow morning.
[19:08] <niemeyer> TheMue: LGTM
[19:09] <TheMue> niemeyer: Great, thx. A good step for the end of the day.
[19:09] <niemeyer> TheMue: +1, very happy to see this going n
[19:09] <niemeyer> in
[19:10] <TheMue> niemeyer: Me too.
[20:57]  * hazmat likes the new golang book
[20:58] <hazmat> the mark summerfield one
[21:30] <niemeyer> hazmat: Good to hear
[21:30] <niemeyer> hazmat: Haven't checked it out yet
[21:34] <hazmat> niemeyer, i've read some of his others pyqt.. etc.. he's a good author
[21:41] <niemeyer> davecheney: Good morning
[21:41] <niemeyer> hazmat: Yeah, haven't read those, but I did see his name around books for a while
[21:42] <davecheney> niemeyer: morning
[21:42] <niemeyer> davecheney: Had to put https://codereview.appspot.com/6229046/ back to WIP unfortunately.. a race was introduced in the latest change
[21:42] <davecheney> yup
[21:42] <davecheney> i'll address that now
[21:55] <niemeyer> I'm heading off to dinner.. will be back later to review rog's latest goodness
[21:57] <davecheney> ok
[23:05] <robbiew> davecheney: ping
[23:07] <andrewsmedina> niemeyer: I sent the new proposal
[23:08] <davecheney> robbiew: ack
[23:08] <davecheney> i should be on skype
[23:10] <robbiew> davecheney: cool...one sec
[23:27] <davecheney> niemeyer: out for review: https://codereview.appspot.com/6244053


[06:03] <Kilos> morning superfly and others
[06:03] <superfly> hi Kilos
[06:12] <Kilos> Maaz, coffee on
[06:12]  * Maaz starts grinding coffee
[06:14] <Kilos> Maaz, hurry
[06:14] <Maaz> Hey! Kilos Patience is a virtue,
[06:16] <Maaz> Coffee's ready for Kilos!
[06:16] <Kilos> yay
[06:16] <Kilos> Maaz, ty
[06:16] <Maaz> Enjoy Kilos
[06:16] <Kilos> bbl
[13:13] <sakhi_> life would be so easy if there was a command to upgrade from 10.04 LTS 32 bit to 64bit but I guess its not at the OS leyer.
[14:35] <Mezenir> hi hi
[14:38] <zeref> herro
[15:50] <superfly> sakhi: there is one way, but you need to be a psychopath to want to even try
[15:58] <tumbleweed> superfly: how's that package?
[15:59] <superfly> tumbleweed: no further than when we last looked at it
[15:59] <tumbleweed> pish :P
[15:59] <superfly> I think I needed to correct the license as a first step
[15:59] <superfly> just been busy fixing bugs for this weekend's release
[16:01] <tumbleweed> yeah, releases come first
[16:54] <Mezenir> what package is that ?
[17:11] <zeref> lolz, just realised, i've never used the software center
[17:21] <superfly> Mezenir: one of my open source projects, http://openlp.org/
[17:21] <superfly> Mezenir: I want to get it into Debian, and thereby also into Ubuntu
[17:30] <rossouwap> Mezenir, you there?
[17:31] <Mezenir> yeah
[17:31] <Mezenir> hows it going
[17:32] <rossouwap> cool - saw a press release from Mozilla today that you may be interested in
[17:32] <Mezenir> haha
[17:32] <Mezenir> yeah
[17:32] <Mezenir> saw that
[17:32] <Mezenir> on slashdot
[17:32] <rossouwap> ;)
[17:32] <Mezenir> good news all around
[17:32] <Mezenir> i guess its a way for google to gain good publicity
[18:02] <Kilos> eveningsupand others
[18:03] <Kilos> eish
[18:03] <Kilos> try again
[18:03] <Kilos> evening superfly and others
[18:04] <superfly> hi Kilos!
[18:04] <superfly> oom, ek het goeie nuus
[18:04] <Kilos> vertel
[18:04] <superfly> zak sal 'n boetie of 'n sussie kry volgende jaar
[18:05] <Kilos> w00t
[18:05] <Kilos> waar kry jy die tyd
[18:05] <Kilos> hehe
[18:05] <Kilos> o op vakansie
[18:05] <Kilos> veels geluk
[18:05] <superfly> ;-)
[18:06] <superfly> thanks oom
[18:07] <Kilos> congrats mrs_fly_
[18:07] <Kilos> how come her nick got a tail superfly
[18:08] <Kilos> thank heavens for tab complete
[18:08] <superfly> Kilos: dunno, netsplits or something
[18:08] <mrs_fly_> Thanks Oom Kilos!
[18:08] <Kilos> lol
[18:08] <Kilos> everything of the best young lady
[18:09] <Kilos> look after yourself  now and make the fly do all the work
[18:42] <Kilos> night all. sleep tight
[19:40] <tumbleweed> marcog: hrm, maybe see you in may: http://uds.ubuntu.com/
[19:47] <marcog> tumbleweed: cool :)
[19:48] <marcog> everyone seems to be passing through here, it's crazy
[19:48] <marcog> not that i'm complaining at all :P
[19:49] <marcog> if you want a place to crash at any time, we've got a couch in our place in mountain view
[19:52] <tumbleweed> thanks, probably won't, but not even thinking that far ahead right now
[20:05] <marcog> lol, just after that another friend tells me plans to come by in feb
[20:14]  * nuvolari sigh
[20:14] <nuvolari> any LaTeX users around?
[20:14] <nuvolari> whoot! Congratulations superfly + mrs_fly_ :D
[20:15] <superfly> thanks nuvolari
[20:16]  * nuvolari rephrase: any LaTeX users around that created customisations of beamer themes around?
[20:17] <tumbleweed> I've customised themes, but not beamer
[20:17] <tumbleweed> marcog: you ever customised beamer?
[20:18] <tumbleweed> superfly: oh, indeed, congrats
[20:18] <superfly> thanks tumbleweed :-)
[20:19]  * tumbleweed .sister just popped a sprog
[20:19] <tumbleweed> the first of our generation
[20:19] <tumbleweed> (well, in the family, and excluding cousins)
[21:01] <marcog> tumbleweed: nope