[00:17] <ochosi> bluesabre: we should check what else we want to get done for 18.04
[00:17] <ochosi> just to be sure
[00:17] <ochosi> as time is slowly running out
[00:17] <bluesabre> indeed
[00:18] <bluesabre> will probably tidy up the bp tomorrow or so
[00:18] <bluesabre> and plan a meeting for next week
[00:18] <ochosi> two weeks till feature freeze...
[00:18] <ochosi> and we also need a decision on gtk-theme-config
[00:19] <bluesabre> yeah
[00:19] <bluesabre> need to test your code on that still
[00:19] <ochosi> yup, should be easy
[00:19] <ochosi> despite the obvious error in the script
[00:21] <bluesabre> probably looking at new stable releases for exo, parole, and xfce4-pulseaudio-plugin in the next 2 weeks
[00:21] <bluesabre> and menulibre
[00:21] <bluesabre> gonna be busy :D
[00:23] <bluesabre> as for now, going to be not-busy
[00:23] <bluesabre> back tomorrow!
[00:26] <ochosi> sounds good
[00:26] <ochosi> we should get all that we can into 18.04 :)
[00:28] <Unit193> Don't forget xfdesktop patch.
[00:28] <bluesabre> yes
[00:29] <bluesabre> Hopefully we can get eric back on that
[00:29] <bluesabre> The existing patch looks complicated, and the lightdm patch looks more complicated
[04:32] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: exo 0.12.0 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-exo-0-12-0-released-tp50654.html (by Sean Davis-6)
[05:44] <flocculant> Unit193: ok is it?
[05:44] <Unit193> Seems fine, though didn't use the upgrader tool.
[05:46] <flocculant> :)
[05:50] <Unit193> And I finally got libxfce4iu in too. :P
[05:50] <Unit193> ui
[05:50] <flocculant> yea saw thaat in -proposed so grabbed it :)
[05:51]  * flocculant still gnashes teeth at missing open terminal option on desktop menu
[05:52] <Unit193> There was something on that..
[05:53] <Unit193> https://git.xfce.org/xfce/xfdesktop/commit/?id=4c77522252500818869654832594a2d38c3dc291
[05:55] <flocculant> I guess I could git build it
[05:57] <Unit193> Shouldn't that be exo though?
[05:57] <flocculant> no idea tbh
[05:57] <flocculant> pretty much given up on things now
[06:56] <Unit193> :/
[08:16] <Unit193> flocculant: Soo...Any way I can make this better?
[18:18] <jalt> Hi, is there a new target release date for Xubuntu 16.04.4 ISO? Alternatively, is there a daily or dev ISO I can download? http://cdimage.ubuntu.com/xubuntu/xenial/daily-live/current/ might be it but it still says 16.04.3. Lastly, is there a public tracker where I can see the blockers for the release?
[19:33] <flocculant> jalt: good timing
[19:33] <flocculant> I just read a mail on the ubuntu-release mailing list, 16.04.4 set for 1st March
[19:33] <jalt> oh
[19:34] <jalt> https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004287.html
[19:34] <jalt> thanks for the pointer flocculant
[19:36] <flocculant> jalt: no problem :)
[19:36] <jalt> is the /xenial/daily-live/current iso the future 16.04.4?
[19:37] <jalt> i have a little iso remastering script for unattended installation and would like to test it. i don't expect breakages, but you never know...
[19:37] <flocculant> jalt: seems so - built today - obviously it could possibly change between now and 1/3/2018 but it'd usually just be apt update/upgrade to get to the 'actual' release
[19:39] <jalt> thanks again flocculant. anything particularly juicy planned for xubuntu 18.04? and i mean xubuntu specific.
[19:40] <flocculant> not that I'm aware of - and I should be aaware
[19:41] <flocculant> mostly we're still getting gtk3 stuff from Xfce - given that 18.04 is LTS we're more aiming for stability, the cycle(s) after 18.04 are likely to see more
[21:46] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: thunar-media-tags-plugin 0.3.0 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-thunar-media-tags-plugin-0-3-0-released-tp50669.html (by André Miranda)
[22:41] <bluesabre> Suppose I should document the interesting bits
[22:53] <bluesabre> If we act quick, approval for core/base might be much easier right now http://www.omgubuntu.co.uk/2018/02/ubuntu-18-04-minimal-install-option
[22:53] <bluesabre> bbl


[08:15] <Sweet5hark> Goooood morning, desktoppers!
[08:16] <Sweet5hark> You write C or C++? You want to have opinionated discussions with your compiler? Or just be scared by what "undefined behaviour" really means? Read this: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
[08:16] <Sweet5hark> desrt: as discussed yesterday ^^
[08:30] <Laney> seb128: some new comments in https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1437633
[08:30] <Laney> if you're interested
[08:30] <seb128> Laney, I am, thanks
[08:45] <ochosi> Sweet5hark: ouch, that really *is* scary
[08:50] <Sweet5hark> ochosi: hrhr, yeah -- an unrelated bug might cause your guards to be happily optimized away ...
[08:53] <ochosi> Sweet5hark: yeah, i'm trying to forget that again now so that i can continue to live happily (more or less)
[08:54] <Sweet5hark> also: you put your best coders on the security relevant code and they do all h. but then your less experienced coders use that code and since you
[08:56]  * desrt drops https://wiki.gnome.org/RyanLortie/BugsInC
[08:56] <Sweet5hark> also: you put your best coders on the security relevant code and they do all the checks and guards. And then your less experienced coders use that code, have undefed behaviour around it, and since its inlined, the guards/checks get optimized out ....
[09:01] <ogra_> Laney, seb128 ...
[09:01] <ogra_> phablet@ubuntu-phablet:~$ sudo whoopsie-preferences
[09:01] <ogra_> Could not write configuration: Failed to create file '/etc/whoopsie.LRHGXX': Read-only file system
[09:01] <ogra_> Lost the name: com.ubuntu.WhoopsiePreferences
[09:02] <ogra_> that is with the fix ... that cant really work :/
[09:02] <ogra_> talking about bug 1437633
[09:03] <ogra_> could we move the file to /etc/whoopsie/whoopsie ?
[09:03] <ogra_> or some such
[09:08] <Laney> ogra_: read like 5 lines above your sentence :-)
[09:08] <ogra_> Laney, ah, heh, i'm blind
[09:08] <Laney> are you talking about the rtm or the vivid version?
[09:08] <Laney> vivid I guess
[09:08] <ogra_> rtm is dead
[09:08] <Laney> nice
[09:08] <Laney> NICE
[09:09] <ogra_> (unless there is somethin super critical found)
[09:09] <Laney> so I didn't work on the vivid implementation & assume Seb is looking at it
[09:09] <Laney> wait for him I guess
[09:09] <ogra_> but then only a fix for that one thing would land ... else we'll wait for vivid stabilization now
[09:15] <Sweet5hark> desrt: all those are resolved in C++11 at least, #justsayin'
[09:28] <desrt> larsu: can you take a glance at https://bugzilla.gnome.org/show_bug.cgi?id=744282 before i push?
[09:29] <desrt> since nobody really properly reviewed this yet -- only tested it
[09:29] <larsu> desrt: new dotty record!
[09:29] <larsu> desrt: I mean: sure, no problem
[09:30] <desrt> larsu: sounds like i pinged at a good time ;)
[09:32] <Sweet5hark> larsu: di da dotty (sing this to the melody of schni schna schnappy)
[09:32] <larsu> shit. instant earworm
[09:32] <larsu> THANKS Sweet5hark
[09:33] <desrt> sure glad i didn't get this when i'm a kid
[09:33] <larsu> desrt: you're sentence didn't made any sense grammatic
[09:33] <desrt> i know
[09:33] <desrt> i knew it as i was typing it
[09:33] <desrt> was too lazy to fix it
[09:34] <larsu> I didn't get this as a kid either
[09:34] <larsu> it's not that old
[09:35] <larsu> "which is nice" <-- actual fragment from desrt's commit message
[09:36] <Sweet5hark> we totally need a commit message of the year competition
[09:37] <larsu> desrt: setting GPtrArray.pdata directly is smelly
[09:44] <desrt> there is no API to do that
[09:44] <desrt> but i could change it to run over the array and dup it after i free the ptrarray
[09:44] <desrt> but.... why?
[09:44] <desrt> smell-avoidance?
[09:45] <Sweet5hark> doesnt gcc have a deodorant plugin for smell avoidance?
[10:38] <seb128> ogra_, yeah, it's annoying, whoopsie edit the file in a safe way, e.g to the create a new file and rename way
[10:38] <seb128> ogra_, which of course doesn't work with our ro fs
[10:39] <ogra_> right, that is fine as ling as we can do it in a subdir
[10:39] <ogra_> *long
[10:39] <ogra_> (which i actually thought it did ... i understood /etc/whoopsie to be a dir in your patch)
[10:45] <seb128> ogra_, so maybe my patch is wrong, it's a file
[10:45] <seb128> ogra_, I though you could list specific files in writable-paths
[10:45] <ogra_> seb128, yes, you can ...
[10:45] <seb128> k, so it's a file
[10:45] <ogra_> but for atomic writes you would need /etc writable
[10:45] <seb128> I guess we would need to change whoopsie then
[10:45] <seb128> to write to a subdir
[10:46] <ogra_> yeah
[10:47] <seb128> it's a bit suboptimal that we need to change whoopsie just to workaround design limitation of our ro images
[10:47] <seb128> we need a proper overlayfs ;-)
[10:48] <seb128> bregma, could somebody from your team look at bug #1405349? I guess that's one for andyrock (I would ping him but he's not on IRC it seems?)
[10:59] <mhall119> bregma: http://summit.ubuntu.com/uos-1505/meeting/22447/user-documentation-for-unity-8/
[11:07] <seb128> happyaron, what's the status of https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1439202 ?
[11:08] <happyaron> seb128: cannot determine which side is wrong yet, but traces down to glib...
[11:08] <seb128> happyaron, you have desrt 1.5m away from you if needed ;-)
[11:08] <happyaron> yep, :)
[11:09] <happyaron> seb128: will deal with that a bit later, struggling with canonistack atm
[11:09] <seb128> k, thanks
[11:10] <happyaron> it's stucking my instance, hope it won't get swallowed
[11:18] <ogra_> seb128, why would you add that patch to systemd ? systemd isnt used on phones
[11:19] <seb128> ogra_, I said a similar change to whoopsie, to rename the file in /etc/writable rather than /etc
[11:19] <ogra_> oops,, sorry
[11:19] <ogra_> yeah
[11:29] <Riddell> didrocks: what is ubuntu-desktop-next?
[11:30] <didrocks> Riddell: it's the experimental unity8 image we had in the past, I guess the first image was about 18 months ago
[11:31] <didrocks> Riddell: are you going to review my changes? :)
[11:35] <Riddell> didrocks: I wouldn't trust myself to be able to :)
[14:40] <Sweet5hark> pitti: about bug 1443667, the cause of this is http://anonscm.debian.org/cgit/pkg-openoffice/libreoffice.git/commit/?h=debian-experimental-4.4&id=b0002aad6276ac1f21828e5bea1d4c319a345b58 which has been around since libreoffice 4.4.0 and _rene_ says "its only a dir, so dpkg shouldnt care" ...
[14:42] <Sweet5hark> ... never seen that happen for an update here either. Sure can add a B/R, but am unsure on how to verify the fix ...
[14:43]  * Sweet5hark should maybe try a manual update sequence to trigger this.
[14:43] <pitti> Sweet5hark: does that also apply to an utopic->vivid upgrade, or only intra-vivid?
[14:46] <Sweet5hark> pitti: I assume it might also affect utopic->vivid. change was in the first version of 4.4.0.
[14:47] <Sweet5hark> pitti: But in that case it should have possibly affected every update from libreoffice 4.3 to 4.4, so I wonder if this is some kind of heisenbug.
[14:48] <pitti> Sweet5hark: it depends on the unpack order really
[14:49] <Sweet5hark> pitti: yep, that makes it so much "fun" ...
[14:53] <Sweet5hark> pitti: heh. _rene_ now wants to put the symlink back to -common, while keeping the dir in -core. (change was done for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775150 btw)
[14:53] <pitti> Sweet5hark: hm; please don't keep replacing dirs with symlinks or vice versa, that confuses dpkg
[14:55] <Sweet5hark> pitti: well, if I wouldnt sync from debian, there wouldnt be any symlinks and wild moving around of dirs anyway.
[14:56]  * Sweet5hark isnt a fan of this symlinking and moving either.
[14:57]  * ogra_ is looking forward to a snap/click of openoffice ... that will never have such issues :)
[15:00] <Sweet5hark> ogra_: thats true. because there will never be any updates of openoffice anyway. security or otherwise.
[15:01] <ogra_> Sweet5hark, so you plan to stop maintaining it ?
[15:02] <Sweet5hark> I stopped maintaining openoffice four years ago ...
[15:04] <ogra_> lol
[15:04] <ogra_> my brain stopped switching to the right name years ago too it seems
[15:04] <ogra_> sorry :)
[15:05] <Sweet5hark> ogra_: np
[15:05]  * Sweet5hark now carries on with breaking libreoffice ...
[15:07] <Sweet5hark> pitti: sooo, I agreed with _rene_ that we just add a replaces vs. -common for -core. Is the breaks: really needed? Neither _rene_ nor me see a reason for that.
[15:08] <pitti> Sweet5hark: it might work without, it's just standard practice so that apt unpacks the newer version of the broken package first
[15:08] <pitti> but if you try to replace a symlink with a dir you need a preinst anyway, and hten definitifely a breaks
[15:09] <Sweet5hark> pitti: nono, we are not replacing the dir with a symlink
[15:09] <pitti> (not sure which way aroud you changed things, only following with half a brain cell)
[15:13] <Sweet5hark> pitti: /usr/lib/libreoffice/share/uno_packages moved from -common (in 4.3) to -core (in 4.4). _rene_ assumed the dir to be empty (and thus needing no replaces:), but its not as there is a symlink called "cache" in it.  So just adding a "Replaces: libreoffice-common (<< $ver)" in libreoffice-core should make this work out.
[15:15] <Sweet5hark> heh, as it goes there is a Replaces: in there already anyway, just needs the version bumped ...
[16:08] <Sweet5hark> seb128: http://people.canonical.com/~bjoern/vivid/4.4.2/libreoffice_4.4.2-0ubuntu2_source.changes no l10n update needed, no sign-all needed
[16:16] <seb128> Sweet5hark, uploaded
[16:19] <Sweet5hark> seb128: thx
[16:19] <seb128> Sweet5hark, yw!


[00:00] <SpamapS> haha
[00:00] <jimbaker> i'm pretty much convinced that Twisted is the best choice for this in the python frameworks
[00:00] <SpamapS> It drives me *batty*
[00:02] <jimbaker> SpamapS, oh sure, it definitely does do that
[00:03] <jimbaker> i personally think that we could write equally robust and deterministic tests using threaded code, along with some conventions. the advantage over twisted would being able to use any arbitrary library. but we would have to come up with some good conventions that at the end of the day do look like go
[00:04] <SpamapS> Go is a nice idea.. but at what point do you stop forward progress to rewrite in it?
[00:05] <jimbaker> SpamapS, progress is so slow right now because testing is currently too hard
[00:05] <jimbaker> so i think that answers it for me
[00:05] <SpamapS> I found it rather easy to do tests for LXC.. but.. thats because I made LXC block.
[00:06] <jimbaker> SpamapS, correct. blocking is much easier to work with. that's why i mentioned using threads. (i was thinking of the paper you shared)
[00:08] <SpamapS> Yeah it pretty much blows up all of the arguments I've heard for event based programming
[00:11] <jimbaker> the inline callbacks model and how it supports coroutines through a trampoline basically gives us what we want there, except that constantly need to remember our calling conventions. so stuff randomly blows up if we forget. and we lose the stack.
[00:12] <jimbaker> in comparison goroutines are very nice
[00:13] <SpamapS> Whats the obsession w/ concurrency in a single process? I honestly can't see more than 1000 things happening at any one time in any one of the agents or clients... thats well within the capabilities of multi-processing.
[00:16] <jimbaker> well, i'm quite certain that multiprocessing would be the wrong way to architect it
[00:16] <jimbaker> we have i/o concurrency here
[00:16] <jimbaker> so not compute bound
[00:20] <kirkland> m_3: around?
[00:24] <_mup_> ensemble/robust-hook-exit r291 committed by<EMAIL_ADDRESS>[00:24] <_mup_> Doc strings and comments about exit vs end
[00:25] <_mup_> ensemble/robust-hook-exit r292 committed by<EMAIL_ADDRESS>[00:25] <_mup_> Merged trunk
[00:39] <_mup_> ensemble/robust-hook-exit r293 committed by<EMAIL_ADDRESS>[00:39] <_mup_> PEP8
[00:43] <_mup_> ensemble/trunk r286 committed by<EMAIL_ADDRESS>[00:43] <_mup_> merge robust-hook-exit [r=niemeyer,hazmat][f=810808]
[00:43] <_mup_> Distinguishes between a process exits and the process has closed its
[00:43] <_mup_> file descriptors, so that hook output is captured properly without
[00:43] <_mup_> unnecessarily waiting on misbehaving hooks with child processes that
[00:43] <_mup_> haven't closed their FDs.
[00:46] <jimbaker> negronjl, fix released into trunk
[00:47] <negronjl> jimbaker:  Thanks man
[00:47] <jimbaker> negronjl, cool, hopefully this works well as we expect for cloudfoundry
[01:40] <_mup_> ensemble/states-with-principals r299 committed by<EMAIL_ADDRESS>[01:40] <_mup_> integrate principal creation/group management into relevant domain states (service, unit, machine)
[01:42] <hazmat> jimbaker, i think the greenlet approach might be a bit nicer
[02:06] <jimbaker> hazmat, the problem i see with that is you cannot switch across threads with greenlets. but it's required to use different threads when working with ZK (or at least the current c api)
[02:07] <jimbaker> obviously it can be made to work, but so much of the greenlet advantage is seen when using switch
[02:28] <m_3> kirkland: hey man... ssup?
[02:49] <hazmat> jimbaker, you can definitely switch across threads with greenlets
[02:49] <hazmat> jimbaker, you can wait on another greenlet to finish and capture its return value and you can yield control of a thread
[03:16] <sidnei> SpamapS, do you happen to be around?
[03:44] <jimbaker> hazmat: http://packages.python.org/greenlet/#greenlets-and-python-threads - "Greenlets can be combined with Python threads; in this case, each thread contains an independent "main" greenlet with a tree of sub-greenlets. It is not possible to mix or switch between greenlets belonging to different threads."
[03:50] <SpamapS> sidnei: here now, sup?
[03:51] <sidnei> SpamapS, oh, was checking #736216, then i realized i enabled proposed but never actually installed the package from proposed.
[03:51] <_mup_> Bug #736216: bzr crashed with error in _curl_perform(): (28, 'SSL connection timeout at 298225') connecting to Launchpad <amd64> <apport-crash> <error-reporting> <https> <natty> <running-unity> <verification-needed> <Bazaar:Invalid> <Launchpad itself:Invalid> <bzr (Ubuntu):Invalid> <curl (Ubuntu):Fix Released> <bzr (Ubuntu Maverick):Invalid> <curl (Ubuntu Maverick):In Progress> <bzr (Ubuntu Natty):Invalid> <curl (Ubuntu Natty):Fix Committed>
[03:52] <sidnei> incidentally seems like niemeyer was hitting it today with bzr
[03:54] <SpamapS> sidnei: Cool. bzr has a micro-release exception, so not all the bugs have to be verified. The package just has to sit in -proposed for 7 days and pass the test suites.
[03:55] <sidnei> SpamapS, yes, but the bug is in curl, and bzr is affected due to python-pycurl linking against libcurl3-gnutls
[03:55] <SpamapS> OH
[03:57] <sidnei> anyway, i enabled proposed but forgot to install the upgrade from proposed until today. seems like the updated package fixes the problem, but i will leave landscape-client running overnight and check the logs in the morning to be real sure.
[13:51]  * hazmat wonders if his diy nas will boot
[14:01] <jcastro> SpamapS: good luck today on your talk, knock em dead!
[14:02] <kooolhead11> hi all
[14:04] <kim0> hazmat: I'm interested to know more about ur nas
[14:07] <hazmat> kim0, nutshell. recycling old diy desktop (core2duo + 4g ram), into a cooler master centurion 590 case, a pair of 5x3 drive cages, and 8 port sata controller, i'm pretty set on a zfs setup at this point (freenas), although i'm going to see if i can test btrfs before i do. sadly my first problem just cropped, need an add on video card, no mb graphics.
[14:09] <kim0> hazmat: was just checking out btrfs since I converted my /home to that (getting too many bad sectors lately). so btrfs can't raid5/6 yet, no working fsck, and no raid conversion yet. Otherwise, seems functional :)
[14:10] <niemeyer> Good mornings!
[14:11] <kim0> Morning
[14:11] <fwereade> niemeyer: heyhey
[14:16] <hazmat> kim0, i have hopes for btrfs, and keeping check in on the dev, but it still seems a bit experimental for trustworthy storage.. i'm planning on using  raidz2 (3 drive fail to loose data) mode of zfs across eventually 14 drives (starting with 6 atm), in two vdevs of 5-7 each
[14:17] <kim0> yeah although fedora is switching to it, I think it's too early to trust it with family photos :)
[14:19] <SpamapS> jcastro: thanks.. I may still change the pics if I have some time.. but for now.. its lolcats ftw
[14:19] <jcastro> SpamapS: heh, when in doubt, go with what you know
[14:19] <kim0> hehe
[14:50] <niemeyer> hazmat: Physical drivers?
[14:50] <niemeyer> hazmat: Physical drives?
[14:51] <hazmat> niemeyer, 6 atm (5 2tb, 128 gb ssd from old laptop).. total capacity is 14 with the 8-port sata card (not raid) and 6 mb sata slots
[14:53] <hazmat> as far as picking a sata controller with good foss driver support, i found this blog post very helpful.. http://blog.zorinaq.com/?e=10
[14:53] <fwereade> hey all, I'm confused about something
[14:54] <hazmat> niemeyer, re security discussion from yesterday, let me know when you've got time to pick it back up..
[14:54] <hazmat> fwereade, what's up?
[14:54] <fwereade> you know we get authorized keys and send them to instances... what do we actually use them for?
[14:54] <fwereade> I thought we were meant to be doing all communication via ZK?
[14:54] <hazmat> fwereade, ssh into the machine
[14:54] <niemeyer> hazmat: Ok.. I have time right now, but I think I'd like to spend some more time with it if you don't mind, so that I can be more helpful.
[14:54] <fwereade> is it only a sort of emergency damn-I've-screwed-up channel
[14:55] <niemeyer> hazmat: I've thought further about the problem yesterday, and have some ideas, but these ideas have holes still
[14:55] <hazmat> fwereade, we use that for the debug hooks command and ssh, and in future scp
[14:55] <hazmat> niemeyer, i've got a nice solution
[14:55] <niemeyer> hazmat: I need to stand next to a white board for a moment
[14:55] <fwereade> hazmat: ah, cool
[14:55] <niemeyer> hazmat: Oh, what's that?
[14:55] <fwereade> hazmat: thanks :)
[14:55] <hazmat> fwereade, np
[14:56] <hazmat> niemeyer, well first.. i think its useful to think of the topology as an identity db, not particularly relevant to the solution.. but most sequence nodes don't have identity prior to their existance in the topology
[14:57] <hazmat> for example look at a failure mode for creating a machine, it leaves an unused sequence node
[14:57] <niemeyer> hazmat: Ok
[14:57] <hazmat> niemeyer, so in particular, i just backed off doing acls for these nodes at creation time, and instead update the acl using policy rules after they've been added
[14:58] <hazmat> to the topology
[14:58] <niemeyer> hazmat: Yeah, that was the direction of my thinking as well
[14:58] <niemeyer> hazmat: Have you figured what's the problem with this too?
[14:59] <hazmat> niemeyer, haven't run into anything yet, do you foresee an issue?
[14:59] <niemeyer> hazmat: Yeah.. what's the reason why we create the entry before putting it in the topology?
[14:59] <hazmat> niemeyer, ah.. yes there is a gap i did notice that
[15:00] <hazmat> before we apply acls
[15:00] <niemeyer> hazmat: Right, we're going back to the original problme
[15:00] <hazmat> niemeyer, not really
[15:00] <niemeyer> hazmat: Why not?
[15:01] <hazmat> niemeyer, the one acl that the standard policy can put forth is an owner policy, which free us from worrying about an acl security gap, so we can modify it post topology add.
[15:02] <niemeyer> hazmat: THe reason why we create the entry before putting it in the topology is because once the topology is touched agents will notice that and will act accordingly
[15:02] <hazmat> niemeyer, as to your question of why create before topology, so we can have an atomic update of the topology which drives  identity/rel watches and that's its reflective of what's present
[15:02] <niemeyer> hazmat: So to make it "atomic" we change the topology once the system is ready to take it
[15:02] <niemeyer> hazmat: If we change in the suggested way, we'll put in the topology something that is not usable
[15:02] <hazmat> niemeyer, yeah.. the gap
[15:02] <hazmat> hmm
[15:05] <hazmat> niemeyer, so that brings up back to nodes should have identity upon creation via contents, but that's complicated as well for the named principal which is going to be reference the sequence value
[15:06] <niemeyer> hazmat: Yeah, I feel like this is an ugly hack we shouldn't dive into
[15:06] <hazmat> niemeyer, alternatively we could write support for the new zk multi-node api into the libzk and zkpython
[15:06] <hazmat> niemeyer, yeah.. i'd prefer to avoid content sniffing as well
[15:07] <hazmat> bummer
[15:07] <hazmat> yeah.. a whiteboard sounds good
[15:07] <hazmat> and some coffee
[15:08] <niemeyer> hazmat: I think your suggestion is going into the right direction.. let's just ponder for a second on the new problem that arrives from that.  I have a vague idea, just need to see if it's reasonable or not.  Give me a few minutes to brainstorm on this
[15:10] <hazmat> niemeyer, so the failure modes on these from a topo conflict are pretty much non-existant
[15:10] <hazmat> its just a retry
[15:11] <hazmat> the sequence nodes are guaranteed unique
[15:12] <hazmat> we could have a local topology for the policy to utilize before saving it to the final topology, effectively making the acl update part of the topo change function, that finishes prior to return contents
[15:12] <hazmat> s/finishes/modifies the acl prior to returning the topology contents
[15:14] <hazmat> hmm.. it also needs to do the otp there, as the rules will likely reference
[15:15] <niemeyer> hazmat: Why?
[15:15] <niemeyer> hazmat: The OTP doesn't have to change
[15:15] <niemeyer> hazmat: on every iteration of the retry, that is
[15:15] <jcastro> jamespage: hey do you think it's feasable to replace pad.ubuntu.com with -lite deployed via ensemble? That would be a nice dogfood for next UDS.
[15:16] <jamespage> jcastro: hmm - maybe; its quite bleeding edge ATM and requires stuff which is not in the archive
[15:16]  * jcastro nods
[15:16] <jamespage> jcastro: will probably hit the 'is-it-packaged' challenge
[15:17] <jcastro> yeah but if we have an ensemble formula we should stop caring about that right?
[15:17] <jamespage> jcastro: :-)
[15:17] <jamespage> jcastro: well the formula pull in and builds quite a few bits and pieces not from Ubuntu
[15:18] <jcastro> I thought that was a feature, but yeah, I can see that.
[15:18] <jamespage> jcastro: just pushed an initial version of the formula BTW
[15:18] <jcastro> jamespage: I saw, that's what prompted me to ask.
[15:19] <jcastro> well, we can certainly dogfood it during ensemble team events. :)
[15:19] <jamespage> don't try it with haproxy yet......
[15:19] <jamespage> but works OK with a mysql backend
[15:19] <jcastro> ok
[15:19] <jcastro> yeah this is one of those that just will demo great and let people try it immediately.
[15:21] <jamespage> agreed
[15:39] <hazmat> niemeyer, true the otp identity is stable and doesn't ref the topology.
[15:47] <_mup_> ensemble/debug-log-relation-settings-changes r275 committed by<EMAIL_ADDRESS>[15:47] <_mup_> Merged trunk and resolved conflicts
[16:12] <robbiew> m_3: hey...did you ever hear back from the MediaWiki folks?
[16:17] <m_3> robbiew: nopw
[16:17] <m_3> I'll bug Ryan again
[16:18] <robbiew> m_3: cool...I think SpamapS was planning on stopping by the offices...but not sure when
[16:18] <m_3> yeah, #wikimedia-tech's quiet at the moment... no sign of ryan
[16:19] <robbiew> probably OSCon related
[16:19] <m_3> hopefully
[16:19] <m_3> it's still early
[16:27] <niemeyer> Lunch time
[17:45] <niemeyer> fwereade: ping
[17:59] <hazmat> bcsaller, jimbaker, fwereade, niemeyer weekly meeting?
[18:00] <bcsaller>  trying g+ again?
[18:02] <niemeyer> +1
[18:05] <niemeyer> jimbaker: ping?
[18:24] <jimbaker> niemeyer, hi
[18:30] <jimbaker> niemeyer, so is this g+ meeting happening?
[18:32] <niemeyer> jimbaker: Yeah, it's rolling
[18:32] <niemeyer> jimbaker: We'll invite you
[18:32] <jimbaker> niemeyer, ok
[18:32] <niemeyer> jimbaker: What's your gmail address
[18:52] <m_3> SpamapS: break a leg!
[18:53] <SpamapS> :)
[18:54] <SpamapS> t minus 3 hours 16 minutes
[18:54] <SpamapS> err
[18:54] <SpamapS> 4 hours
[18:54] <m_3> time to enjoy the conf
[18:55] <SpamapS> s/enjoy/document/ ;)
[18:55] <m_3> niemeyer: please add me to the right lp group to edit the ensemble.ubuntu.com wiki when you get a chance
[18:55] <niemeyer> m_3: Done
[18:55] <m_3> thnsk
[19:18] <jimbaker> fyi<EMAIL_ADDRESS>[19:45] <hazmat> niemeyer, one problem i have with current review queue stackand security.. the fixes for security-rules depend depend on stuff latter in the stack.
[19:45] <hazmat> the rules are standalone as is, so i think addressing some of the comments, and then moving forward with the rest of it, till a latter point in the branch stack probably makes the most sense
[19:46] <niemeyer> hazmat: How do you mena?
[19:47] <niemeyer> hazmat: When there is a dependency chain like this, the natural thing to do is to review them in order, apply comments in order, and merge in order
[19:47] <niemeyer> hazmat: Jumping back and forth will make things more complex
[19:49] <hazmat> niemeyer, right.. security rules are an integration piece though, i'm doing integration work and branches right now, but the rest of the branches in the stack that's part of review, including those that follow security-rules are implementation focused. some of them may contain fixes that will be needed to finish up security-rules. currently its standalone, effectively unused (though tested), but unfortunately merged into the rest of the implementati
[19:49] <hazmat> on stack of branches
[19:50] <hazmat> i guess its doable as is, it might just be a while till everything gets merged, which means i'll have a lot of pending branches
[19:50] <niemeyer> hazmat: Yeah, that's why I say that when the dependency has been introduced and they are in a chain, the natural thing to do is to apply reviews and move forward
[19:50] <niemeyer> hazmat: My suggestion is to get the bottom of the stack, fix it, and merge it
[19:50] <niemeyer> hazmat: and so on
[19:50] <hazmat> niemeyer, yeah.. its an artificial dependency at this point which is going to hold up the merge of the other 4 branches in review
[19:50] <niemeyer> hazmat: and then move forward with everything in trunk
[19:51] <niemeyer> hazmat: It is, but it's there..
[19:51] <niemeyer> hazmat: The problem you have is that you're trying to push things forward while there are reviews pending
[19:52] <niemeyer> hazmat: If you take care of the branches that are in review and get them merged, the problem disappear
[19:52] <niemeyer> s
[19:54] <hazmat> niemeyer, perhaps.. the real problem is that its an unrelated branch, which introduced before the implementation of other features, ie. an artifical dependency... i probably shouldn't have pushed it to review.. but i wanted to get feedback on the approach... not a big deal, it can be redressed in the current process.
[20:26] <jcastro> any idea what could cause this? http://pastebin.ubuntu.com/653982/
[20:27] <jcastro> oh nevermind
[20:27] <jcastro> it's that minute delay thing
[20:40] <fwereade> gents, I'm very sorry I missed you
[20:41] <fwereade> in my defence, it did start almost 2 hours after the theoretical end of my day
[20:42] <niemeyer> fwereade: Not a problem.. we were entirely aware of that
[20:43] <niemeyer> fwereade: We decided to go forward just because we've been missing it again and again..
[20:43] <niemeyer> fwereade: We should do another one tomorrow, or very soon anyway, with you
[20:43] <fwereade> niemeyer: anything I should know from it?
[20:43] <niemeyer> fwereade: Nothing critical to what you've been doing.. hazmat is sending notes to the list
[20:43] <niemeyer> fwereade: Btw,
[20:43] <fwereade> niemeyer: cool
[20:43] <niemeyer> fwereade: Just as a note for the start of your day tomorrow
[20:44] <niemeyer> fwereade: It looks like some of the branches you've been pushing for review are missing part of the workflow
[20:44] <niemeyer> fwereade: They're not showing in the Kanban
[20:44] <niemeyer> fwereade: No rush, but worth checking early tomorrow so they get into the review flow
[20:44] <fwereade> niemeyer: hmm, lack of bugs perhaps?
[20:45] <niemeyer> fwereade: Quite possibly
[20:45] <niemeyer> fwereade: Or not assigned to the right milestone
[20:45] <niemeyer> fwereade: Or not in progress.. or.. :)
[20:45] <fwereade> niemeyer: hmm, probably all 3 for most of them
[20:45] <niemeyer> fwereade: Again, no big deal.. just worth checking
[20:45]  * fwereade looks shifty
[20:45]  * hazmat lol
[20:45] <fwereade> niemeyer: cheers :)
[20:45] <niemeyer> fwereade: Sorry for missing you on the meeting
[20:46] <fwereade> niemeyer: no worries :)
[20:46] <niemeyer> fwereade: I hope we automate that at some point.. I'm conscious this procedure is too heavy
[20:47] <fwereade> niemeyer: it's sweetness and light compared to what I'm used to :)
[20:48] <fwereade> niemeyer: however, I think what I'm used to gave me a mild phobia of kanban boards
[20:48] <niemeyer> LOL
[20:48] <fwereade> niemeyer: you'd almost think the software was written by anti-agile activists, it seemed to make a point of putting you off
[20:48] <niemeyer> fwereade: "Wait.. I see you've pushed too branches in a row.. why are you doing things so fast!?"
[20:49] <fwereade> niemeyer: haha
[20:54] <_mup_> Bug #817732 was filed: can't communicate with an orchestra server running cobbler <Ensemble:New> < https://launchpad.net/bugs/817732 >
[20:55] <niemeyer> bcsaller: re. the order of things on LXC, some vague ideas:
 1) Make multiple units work on a single machine across the board (no LXC)
 2) Make local deployments work with one or multiple units (no LXC)
 3) Make LXC work to deploy units
[20:55] <niemeyer> bcsaller: Of course, each of these can be split further
[20:55] <bcsaller> yeah
[20:55] <niemeyer> bcsaller: But these high-level steps feel like making things more manageable
[20:56] <bcsaller> sounds like a good place to start
[20:57] <_mup_> Bug #817735 was filed: cobbler system names can change <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817735 >
[21:00] <hazmat> bcsaller, i'm writing up meeting notes, is your next post-config item spec for containers or co-location?
[21:00] <bcsaller> yes
[21:00] <hazmat> "or" }
[21:00] <hazmat> ?
[21:00] <hazmat> bcsaller, both?
[21:00] <bcsaller> of, well, specs for both, but co-location is first
[21:00] <hazmat> bcsaller, cool, thanks
[21:01] <_mup_> Bug #817736 was filed: FileStorage interface is inconsistent <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817736 >
[21:03] <_mup_> Bug #817738 was filed: duplicated code in ec2 LoadState and SaveState operations <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817738 >
[21:05] <_mup_> Bug #817739 was filed: no FileStorage implementation for orchestra <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817739 >
[21:08] <_mup_> Bug #817740 was filed: orchestra provider can't discover running zookeepers  <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817740 >
[21:10] <_mup_> Bug #817743 was filed: orchestra provider can't launch an instance that does anything useful <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/817743 >
[21:16] <fwereade> niemeyer: btw, re: orchestra development strategy
[21:17] <fwereade> niemeyer: you're absolutely right about the shadow-trunk, that's a nicer model for future work
[21:18] <fwereade> niemeyer: but I think I'm missing something: how does that help us help us transition the code already in adres' branch?
[21:18] <fwereade> niemeyer: well, I guess it doesn't have to
[21:18] <fwereade> niemeyer: it's just that it works, and I'd prefer to transition the working ocde smoothly if I can
[21:19] <fwereade> niemeyer: ...and as soon as I say it in public, it seems much dumber than it did in my head
[21:20] <fwereade> with one more branch (in progress), I think we'll have something that's a viable base for RoAkSoAx to branch from
[21:23] <niemeyer> fwereade: There's no way to transition his work into something compatible with trunk in a mergeable way besides doing it piece by piece
[21:25] <fwereade> niemeyer: yep, I think you're right, it just seems like a shame :)
[21:26] <niemeyer> fwereade: Spikes are spikes.. we have to recognize them by the benefit they provide, but transitioning from a spike into a stable implementation takes known pain
[21:27] <fwereade> niemeyer: and, to be fair, less total pain than "it works? SHIP IT!"
[21:27] <niemeyer> fwereade: Exactly
[21:30]  * fwereade has an uncomfortable feeling he may have quoted directly from someone at his first job
[21:31] <robbiew> lol
[22:00] <SpamapS> crazy idea
[22:00] <SpamapS> we should have a "sneakernet" provider
[22:00] <SpamapS> all it does is create nodes in zookeeper...
[22:01] <SpamapS> and feed you back admin credentials to spawn machine agents
[22:01] <SpamapS> that way you can join existing machines to ensemble
[22:07] <niemeyer> SpamapS: As a first step, defining a formula for an external service would probably work
[23:05] <robbiew> SpamapS:  done your talk yet?
[23:09] <adam_g> robbiew: starts in 2 min
[23:10] <robbiew> adam_g: ah...how's the attendance?
[23:11] <robbiew> I noticed it was still in the OS track b/c of the previous upstart topic
[23:11] <robbiew> not cloud :/
[23:40] <_mup_> ensemble/debug-log-relation-settings-changes r276 committed by<EMAIL_ADDRESS>[23:40] <_mup_> Fixed faulty merge