[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  vhnecoa: JanC ubot5 Spads ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  giyyecemsa: ralsina sayakb ubuntulog ▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  tvkitc: verterok higgins ubot5 ▄▄▄▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  svpnag: sayakb ralsina Spads â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  impxm: mthaddon` higgins ubot5 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  knixldqz: ubuntulog ralsina mthaddon` â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  mfmmpsxv: siel Spads verterok ▄▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  vzsayv: higgins pjdc ubuntulog ▄▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  leuerpokjq: ubot5 siel Spads â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  aiwqk: ubot5 mthaddon` ralsina ▄▄▄▄▄▄▄▄▄▄
[23:47] <SaDIkaElG5O5IB> ▄▄▄▄▄▄▄▄▄▄▄▄▄ IRC.SUPERNETS.ORG #SUPERBOWL SUPERBOWL PARTY RIGHT NOW LIVE CHATTING AND PLAY BY PLAY COMMENTARY GOING ON NOW!! ASK CHRONO FOR DETAILS!!  qlhaan: Spads ralsina JanC ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄


[12:55] <eylul> hi Ross
[12:55] <eylul> there is like half an hour to our meeting time but do tag my name when everyone is here :)
[13:05] <Rosco2> Hi eylul, all ready - just going for a cup of tea :-)
[13:06] <eylul> *has just done that :D*
[13:08] <OvenWerks> coffee
[13:09] <OvenWerks> black
[13:09] <OvenWerks> (609 AM here)
[13:11] <eylul> :D
[13:11] <OvenWerks> Did anyone see Paul Davis' talk at LAC?
[13:11] <eylul> Not yet
[13:11] <eylul> do you have the link?
[13:11] <eylul> *is trying to finish the daily editbacklog post before the meeting*
[13:12] <OvenWerks> https://youtu.be/tZbMfyBGPKo?t=8594
[13:13]  * OvenWerks did not watch it live
[13:33] <OvenWerks> That was promising
[13:34] <OvenWerks> good morning sakrecoer
[13:34] <sakrecoer> Greegins OvenWerks :)
[13:34] <sakrecoer> Good to read you! :)
[13:35] <eylul> hi Sakrecoer
[13:35] <Rosco2> hi sakrecoer !
[13:35] <eylul> I don't know if Kryten is coming at this hour
[13:36] <eylul> but since ovenwerks is short on time, maybe we can start now
[13:36] <sakrecoer> hi Rosco2 and eylul
[13:36] <sakrecoer> yes!
[13:36] <OvenWerks> I am not short on time. have about 1.5 hours
[13:36] <OvenWerks> but since I am up...
[13:36] <eylul> ohh! sorry :D
[13:37] <eylul> but lets start. so umm Sakrecoer *hands the microphone*
[13:37] <sakrecoer> hrm hrm.. 1-2 1-2 mic check
[13:38] <eylul> :D
[13:39] <sakrecoer> so my work ate me.
[13:39] <eylul> *nods*
[13:40] <sakrecoer> it's been incredibly intense for me. I'd spent the last 15 years working max 50%, and now i am way over 100% so i simply cannot catch up with US
[13:40] <sakrecoer> i feel quite bad for not saying anything earlier...
[13:42] <sakrecoer> backlog piled up, and after a while it ended up in some kindof feedback loop, where i wouldn't really dare joinging in, becuase i hadn't joined in for so long...
[13:43] <sakrecoer> i would like to be able to contribute again, but i cannot tell when that would be possible. of course, if i did come back to help it would be on your terms
[13:45] <OvenWerks> this is all volunteer... lots of people do almost nothing for months
[13:45] <OvenWerks> We are all on add a bit when we have time
[13:47] <Rosco2> Yeah - there are more tasks than people. As long as we have a few goals and a task list, anyone can pick up a task when they have time
[13:47]  * eylul agrees with what ovenwerks said
[13:47] <OvenWerks> Anyway, I repulled -controls and then dropped my latest stuff on top.
[13:48] <eylul> yay Ovenwerks! :)
[13:48] <sakrecoer> i've got the impression lots of stuff have happened to -controls :)
[13:48] <OvenWerks> There are two scripts: /usr/sbin/ubuntustudio-system and /usr/bin/ubuntustudio
[13:49] <OvenWerks> /usr/bin/ubuntustudio-controls is the second :P
[13:49] <OvenWerks> sakrecoer: I had to basically start over
[13:49] <sakrecoer> wow!
[13:49] <OvenWerks> The original is run wholely as root
[13:50] <OvenWerks> we can not do any audio settings from root because jack runs as user
[13:52] <eylul> :)
[13:52] <OvenWerks> So now /usr/sbin/ubuntustudio-system does rtaudio fix, cpu gov set, intel boost control and can stop/start cron
[13:53] <Rosco2> Do you think there will be something ready for us to play with soon?
[13:54] <OvenWerks> So far -system seems to do all the right things. I have simplified the rtaudio setup from searching for a user login and setting it to audio and controlling memcontrol, into all one ting
[13:54] <OvenWerks> Rosco2: My goal is to get things back to what -controls can do now and then push
[13:55] <sakrecoer> sounds fair
[13:55] <eylul> guys this is very important discussion that I am glad we are having but maybe we should discuss leadership transition while we have sakrecoer here? :)
[13:55] <Rosco2> yep
[13:55] <eylul> *feels bad interrupting*
[13:55] <Rosco2> :-)
[13:56] <OvenWerks> So far the CPU governor and intel boost control works from the GUI
[13:56] <sakrecoer> thank you eylul. i also have a few hours today, so its fine :)
[13:56] <sakrecoer> but you are right we should talk about it today
[13:57] <OvenWerks> When I get the rtaudio fix working from the gui too, I will remove the exess GUI stuff and release
[13:57] <sakrecoer> i like the ideas you put forward on the list Rosco2
[13:57] <sakrecoer> oops.. i got mixed up sorry OvenWerks, go on
[13:57] <OvenWerks> Thats it no problem
[13:57] <OvenWerks> (this is irc)
[13:58] <sakrecoer> hehe
[13:59] <eylul> :D
[13:59] <sakrecoer> so what do you reckon i should do with my launchpad privilidges? i don't think there is any repo where i am the sole admin
[14:00] <OvenWerks> I would suggest that because we are few with little time, that we start some of the polishing stuff for artwork for the next LTS now.
[14:00] <OvenWerks> sakrecoer: there is no harm leaving them as is.
[14:00] <sakrecoer> ok :)
[14:01] <Rosco2> I think there is only Ubuntu Studio Core wher there is only Len & set as admin
[14:02] <Rosco2> But if Set is still around at least part time I don't see the issue
[14:02] <eylul> it might be best to add you in too rosco2
[14:04] <sakrecoer> yes, if it can accelerate or facilitate your work Rosco2 i think that is a good idea.
[14:04] <Rosco2> Well I don't think it slows anyone down
[14:04] <sakrecoer> good to read that :)
[14:04] <Rosco2> It would only if we were creating new teams etc
[14:05] <eylul> isn't core also used to add new members in?
[14:05] <eylul> *has actually very little knowledge of what these accesses entails*
[14:06]  * OvenWerks has access but has not checked either
[14:06] <eylul> also does core membership affect our ability to speak on behalf of the team to larger ubuntu community on behalf of ubuntustudio
[14:06] <eylul> because that turned out to be a bit of a problem while sakrecoer was away
[14:06] <Rosco2> Just checked - US COre is the administrator of US devel
[14:06] <sakrecoer> there is a risk that my membership expires, isn't it?
[14:07] <sakrecoer> no, its set to never expire.
[14:07] <Rosco2> But then Len should have the power to administrate subteams
[14:08] <sakrecoer> i think Len has those powers
[14:08] <Rosco2> what I meant :-)
[14:08] <sakrecoer> :)
[14:08] <OvenWerks> I think zequence left me with whatever he had.
[14:09] <sakrecoer> it seems i am the owner. I'm have mixed feelings about it.
[14:10] <sakrecoer> i certainly trust you guys, but it gives me lots of accountability for stuff that i'm not really involved with anymore...
[14:10] <sakrecoer> or at the moment
[14:11] <sakrecoer> if you get my pidoes that make sense?
[14:11] <eylul> *nods*
[14:11] <OvenWerks> I think that would be true for any of us
[14:11] <sakrecoer> good point OvenWerks
[14:13] <sakrecoer> we have a lot of teams in launchpad..
[14:13] <Rosco2> Well most launchpad stuff can be managed by members of the dev team I suspect
[14:14] <Rosco2> Only rarely is the power of the COre team required
[14:14] <OvenWerks> it would not hurt to spread that around a bit more though
[14:15] <Rosco2> I suppose most importantly we should agree to what we should do to avoid Set receiving too many mails becasue his name is everywhere
[14:15] <eylul> *nods*
[14:15] <sakrecoer> Rosco2: thank you! although, i think i can live with that :) i have good filters. but maybe to save some electricity...
[14:16] <OvenWerks> I was going to say, I don't think it is that much. (I think I see them all too)
[14:16] <Rosco2> Yeah most contacts probably come to the list or IRC
[14:17] <sakrecoer> and maybe i'm not the best guy to contact for inquires and such..
[14:18] <OvenWerks> sakrecoer: you should feel free to pass messages on to someone better at it.
[14:19] <OvenWerks> leading means knowing who to forward to
[14:20] <eylul> Ovenwerks I think it is less issue of knowing, more an issue of having time and brainspace to do the forwarding
[14:21] <sakrecoer> these guys reach out a few month back: http://www.openinventionnetwork.com/ but i'm pretty sure its the only time it happened via my private lin
[14:21] <OvenWerks> true..
[14:21] <sakrecoer> eylul: yes
[14:21] <eylul> also being the contact point. Kryten and I couldn't get anywhere with website issue in part I assume because communication wasn't going through a designated lead etc
[14:21] <sakrecoer> fortunately, as mentioned, i haven't got more
[14:21] <sakrecoer> good point eylul
[14:22] <sakrecoer> and i have to say, you should really be promoted somehow eylul. <3
[14:22] <Rosco2> +1
[14:23] <eylul> :D I would be happy to help as much as I can especially with the communication
[14:23] <eylul> but it is important I think that it isn't one person, if at all possible
[14:24] <sakrecoer> +2
[14:24] <sakrecoer> :)
[14:24] <eylul> when I am at a conference or residency (as happened in february) I am MIA, no helping it..
[14:24] <eylul> which is primary reason why I think council idea needs to be implemented (because every single one of us are in same boat)
[14:25] <Rosco2> Yes - unless Set is willing to carry on, or someone else violently wants to take over :-)
[14:25] <sakrecoer> i agree. how do we make that change reflect through out the community and our tool-set
[14:26] <OvenWerks> That was my earlier comment that more people could be added to core
[14:27] <eylul> Rosco2 that would require somebody who has enough TIME to want to do a power grab. XD
[14:27] <Rosco2> One of us (even me) could draft someting based on Xubuntu
[14:27] <eylul> *nods at Ovenwerks
[14:27] <Rosco2> Who would want to be core/council?
[14:27] <eylul> wait, we have an option to NOT be in it? :P
[14:28] <sakrecoer> haha
[14:28] <OvenWerks> anyone who has been around for over a year could be added
[14:28] <Rosco2> So we all turned up and we are stuck with it :-)
[14:28] <OvenWerks> The main thing is not to add someone who just shows up
[14:28] <eylul> agreed
[14:28] <eylul> one year or one release?
[14:29] <eylul> one release cycle*
[14:29] <sakrecoer> Hotel California of FOSS
[14:29] <OvenWerks> :)
[14:29] <eylul> Rosco2: yep
[14:29] <sakrecoer> agreed
[14:29] <Rosco2> 1 year goes so fast - it is probably about right
[14:30] <eylul> you guys do realize this pretty much means we are all stuck with this for a year
[14:30] <eylul> right?
[14:30] <eylul> (just checking)
[14:30] <eylul> :D
[14:32] <OvenWerks> I don't think that is quite what was said. The year is the one past. All of us have "life" first
[14:32] <sakrecoer> yes
[14:32] <eylul> Ovenwerks: what I mean is that we don't have anyone, right now who is active except everyone here, MAYBE luke and kryten
[14:33] <eylul> and that next person won't be eligible until next year
[14:33] <OvenWerks> We actually have more people here than we did a few years ago
[14:33] <eylul> that is true
[14:33] <Rosco2> We could ask them if those two if they want in
[14:33] <eylul> *nods*
[14:34] <Rosco2> Should core tam have a limit?
[14:34] <OvenWerks> Luke is a watcher. He will make suggestions, but likely not do anything that requires inet access from a known source
[14:34] <eylul> who else.. cfhowlett too I suppose although I haven't heard from them recently.
[14:34] <sakrecoer> the thing with core team is that it is quite a bit of power over quite a bit of people's OS:es...
[14:35] <OvenWerks> sakrecoer: yes, but, what I have seen here is not people making wierd and wonderful changes.
[14:35] <sakrecoer> cfhowlett is extremely active on the facebook PR tools for ubuntu studio
[14:35] <Rosco2> I am mixed about it. Of course people outside of core can still have important roles
[14:35]  * OvenWerks probably comes closest to that...
[14:36] <OvenWerks> Rosco2: it is more about backup than anything
[14:36] <eylul> ok can somebody explain what exactly does core-team entail.
[14:36] <eylul> what are the accesses,
[14:37] <eylul> what being member of gives in terms of power (outside the said accesses)
[14:37] <Rosco2> it sort of owns all the other us teams
[14:37] <sakrecoer> it's the launchpad mothership of ubuntu studio, the team from which everything else stems. afaiu
[14:37] <Rosco2> People can be kicked out - added etc
[14:37] <OvenWerks> Which is still just access stuff
[14:38] <sakrecoer> *nods*
[14:38] <Rosco2> Yes - in my mind the core team were the "coucil" - but it doesn't haver o be
[14:38] <Rosco2> have to be
[14:39] <eylul> if membership access goes through the core team, it is a beneficial thing for all of the council (or at least enough) to have. to be able to promptly add (and remove -if ever needed, which I hope not) members
[14:39] <OvenWerks> Rosco2: I think you are involved in Ubuntu outside of just Studio, is that correct?
[14:40] <eylul> (in terms of remove, don't think kicking somebody off  a team, first thing i can think is somebody getting hacked and another one of us removing them in a hurry so that they can get it fixed, then adding them back etc)
[14:40] <Rosco2> Not really - I sometimes try and look after packages I work on in Debian.
[14:40] <eylul> (in terms of adding, not losing volunteers)
[14:40] <Rosco2> But in Ubuntu it is mostly US
[14:40] <OvenWerks> ok
[14:41] <Rosco2> By the way - i looked at Cadence
[14:41] <Rosco2> Alessio had started packaging it in Debian Multimedia
[14:41] <sakrecoer> i see Rosco2 and eylul fit in core
[14:41] <OvenWerks> if Cadence was included it would have to be a somewhat stripped version
[14:41] <Rosco2> Should I try and pick it up again?
[14:41] <sakrecoer> maybe krytarik is interested too?
[14:42] <Rosco2> OK ovenwerks, I will ask separately
[14:42] <eylul> sakrecoer I don't know. i hope?
[14:42] <OvenWerks> Sorry I was thinking of Carla. Carla would be much more useful than cadence
[14:43] <OvenWerks> Rosco2: A lot of what we are planning with -controls would do tha same as cadence and the two might clash
[14:43] <eylul> (having carla by default would be amazing!)
[14:44] <Rosco2> Thats why I asked - I could also try Carla - but I know that will be harder
[14:44]  * OvenWerks tried packaging carla and gave up.
[14:45] <Rosco2> I will have a go - hopefully others in DMT will help too
[14:46] <sakrecoer> \o/
[14:46] <OvenWerks> The debian packaging tools expect the application to be built with certain tools to be easy. Other ways can be done, but the packager has to have a lot more packaging foo than I am ever likely to have
[14:46] <Rosco2> From memory - build system waf was a pain
[14:47] <Rosco2> and also expecting to link with certain libraries which is against the Debian way
[14:47] <OvenWerks> carla doesn't waf, I don't think, but doesn't use auto tools either
[14:47] <Rosco2> library version I meant
[14:48] <OvenWerks> Rosco2: also carla.lv2 (and any other plugin) should be built static
[14:48] <Rosco2> that is sacrilidge in Debian
[14:48] <OvenWerks> Then debian is broken
[14:48] <eylul> *nods* is a direct PPA something we could consider, for things that are not directly possible to package for debian?
[14:49] <OvenWerks> A packaging system shold not be based on religion
[14:50] <Rosco2> :-)
[14:50] <OvenWerks> eylul: yes we could do that
[14:50] <eylul> godot has been running into a similar problem
[14:50] <eylul> we could even get help from existing developers of some of these in that case
[14:50] <Rosco2> Yes - I think we could have a ppa for non-debian sourced packages and also backports
[14:50] <Rosco2> becasue backports necer get sponsored at the moment
[14:51] <Rosco2> it is all about snaps
[14:51] <eylul> (is that why kubuntu have a backports ppa?)
[14:51] <OvenWerks> snaps for plugins or anything that loads plugins will not work
[14:51] <Rosco2> What is happening with my fingers?
[14:51] <eylul> :D
[14:52] <Rosco2> snaps are about containment
[14:52] <OvenWerks> snaps will not work for a jack client either I think.
[14:52] <eylul> well down the line snaps can support plugins etc, but yeah in short it doesn't work quite for our needs for many things (tagging elopio)
[14:52] <Rosco2> plugins are the exact opposite
[14:52] <eylul> (so that he can see this part as it might be helpful for them)
[14:53] <Rosco2> I read about a pulseaudio snap recently
[14:53] <Rosco2> We would need a jack one, then .....
[14:53] <OvenWerks> Rosco2: the jackd2 and jackd1 packages should include the "include" files (-dev) part f things.
[14:54] <OvenWerks> if pulse is snapped badly enough, we may have to just drop pulse
[14:55] <Rosco2> My time has been limited to play with snaps - so I stick to normal packages for now
[14:55] <OvenWerks> speaking of which, pulseaudio's jack bridge is my next project when I am happy with -controls
[14:55] <eylul> :D
[14:56] <eylul> (the nice things about snaps, PPAs etc is that.. we don't have to choose one)
[14:56] <eylul> (we can have apps in as snaps and I expect down the line apps like krita might go that route when the issues get ironed out)
[14:56] <eylul> (and audio software migth still be in PPA based solutions)
[14:56] <OvenWerks> Rosco2: if pulse becomes snapped, will there still be a deb?
[14:57] <Rosco2> Yes
[14:57] <OvenWerks> Rosco2: do you know if it is possible to spec deb over snap in seeds?
[14:57] <Rosco2> I am not sure it is even possible to seed snaps yet
[14:58] <OvenWerks> \o/
[14:58] <sakrecoer> i noticed krita now has appimages http://appimage.org/
[14:58]  * OvenWerks hopes snaps go the way of upstart and unity
[14:59] <Rosco2> They are good for gettng unpackaged stuff out there
[14:59] <Rosco2> And for upstreams to control what is distibuted
[14:59] <OvenWerks> I would guess tha
[15:00] <eylul> rosco2 *nods*
[15:00] <OvenWerks>  To be honest, I know and agree there is a plce for snap packaging. I kind of feel like it has been pushed as the solution to everything
[15:00] <eylul> it makes sense for easier to build servers etc
[15:01] <eylul> we need modular solutions for a bit less experienced people to safely run things
[15:01]  * OvenWerks server is still 14.04
[15:01] <eylul> but yeah for things like audio it might never be ok. and that is ok?
[15:02] <sakrecoer> to me its ok :)
[15:02] <sakrecoer> haha
[15:02] <eylul> (and make no mistake, we need easier ways to self-host mini servers for individuals)
[15:02] <OvenWerks> in a lot of ways, a snap is another way of building a static binary
[15:03] <eylul> *nods*
[15:03] <Rosco2> Yes - saves the problem of supporting multiple versions of all the libraries you depend upon
[15:03] <OvenWerks> in fact, if I could deploy a static binary using a snap it may be worth while
[15:04] <Rosco2> And as everything is contained - you can run it on whatever version of Ubuntu
[15:04] <Rosco2> Which is why I think backports have not had much attention lately
[15:04] <OvenWerks> The ardour.org downloadable binaries include their own version of gtk2... which is why they run everywhere.
[15:06] <Rosco2> Bit of a security nightmare for distributions though.
[15:06] <eylul> how so Rosco2?
[15:06] <Rosco2> Then you have to patch for vunerabilities in multiple places
[15:06] <OvenWerks> Anyway, my time is up. I need to get going
[15:07] <eylul> well through isn't the whole point that the execution of those libraries is limited to the context of that software packaged? (plus assuming team of the software can fix that fast enough, without relying on distro to distribute it)
[15:07] <eylul> ok before ovenwerks go
[15:07] <eylul> what are our steps forward in terms of council etc
[15:08] <sakrecoer> hehe
[15:08] <Rosco2> Back to business
[15:08] <eylul> or we can update ovenwerks if he needs to go now I suppose but..
[15:08] <eylul> lets sort this out
[15:08] <eylul> ok..
[15:09] <eylul> so rosco2 you mentioned drafting something based on xubuntu?
[15:09] <eylul> 2) how many people do we want to cap the council at, if we need cap
[15:09] <eylul> 3) how will we handle initial selection
[15:09] <Rosco2> Can do
[15:09] <eylul> 4) who do we need to inform on ubuntu side when a decision is made?
[15:10] <Rosco2> Community Council I suppose?
[15:10] <sakrecoer> eylul: community council i think
[15:10] <sakrecoer> :)
[15:10] <eylul> I see
[15:11] <eylul> sakrecoer I think you need to be the one to inform them in that case
[15:11] <Rosco2> 3) I suppose all of us & maybe ask the other mentioned privately?
[15:11] <eylul> sounds good to me
[15:11] <Rosco2> I mean ask off list, those that we menioned earlier
[15:11] <eylul> yup
[15:12] <Rosco2> Krytarik etc.
[15:12] <sakrecoer> ok, i can write to the CC
[15:13] <eylul> ok
[15:13] <Rosco2> 2) maybe a random generator and rotate per release?
[15:13] <eylul> ahaha
[15:13] <eylul> maybe first ask if anybody would actually LIKE to step down before doing that?
[15:13] <Rosco2> Actually I misread 2
[15:13] <sakrecoer> Like ancient Greece, Rosco2 :)
[15:14] <sakrecoer> half the parlament was randomly slected (among the right cast though lol)
[15:14] <eylul> no it is a good idea if we have new people who want to join in and old people who don't want to leave although we should make sure that we have at all times one expert tech person (so Rosco2 and Ovenwerks, or at least one of them unless they really need to leave for a while - please don't? :D)
[15:14] <Rosco2> I was talking about a nominal head
[15:14] <eylul> aaah
[15:15] <sakrecoer> aaah!
[15:15] <sakrecoer> haha
[15:15] <eylul> lol
[15:15] <eylul> err
[15:15] <Rosco2> At least that is what Xubuntu did
[15:15] <eylul> does it matter who the head is?
[15:15] <Rosco2> no - that is what I meant with the rotation
[15:15] <eylul> lol
[15:16] <Rosco2> IRC £$%%^&
[15:16] <eylul> rosco2 I was going to nominate you as the head
[15:16] <eylul> but why not
[15:16] <eylul> random works too
[15:16] <eylul> XD
[15:17] <sakrecoer> :)
[15:17] <eylul> (for the first round I mean)
[15:18] <Rosco2> Happy to volunteer for the first round if it is easier and OK with all
[15:18] <sakrecoer> i'd vote for you eylul not that i think Rosco2 wouldn't be good at it, but we really need all he can give on the packaging, and i hope ia m right assuming you enjoy doing that Rosco2 ..?
[15:19] <eylul> I assume that with council I can take most of the communication issue off of rosco2 and ovenwerks and everyone else
[15:19] <Rosco2> Also happy with that Set - I have some work to do to get upload rights
[15:19] <eylul> but it might be better to have somebody who has been around long enough time as first lead (as nominal the role is)
[15:19] <sakrecoer> true, both of you.
[15:19] <eylul> (also my life while not quite as drastic as sakrecoer's situation, has been going on a weird direction)
[15:20] <eylul> lol ok
[15:20] <eylul> maybe rosco2 had the right idea with random number generator
[15:20] <sakrecoer> yes :D
[15:20] <Rosco2> :-)
[15:20] <eylul> lets just do that because otherwise we will keep offering each other leadership all night
[15:20] <eylul> XD
[15:20] <sakrecoer> hahaha
[15:22] <Rosco2> Well - we could wait until we have everything drafted and do a quick vote between us then?
[15:22] <sakrecoer> that is fair to me :)
[15:23] <sakrecoer> i mean... not to me personaly. but it sounds good :)
[15:23] <eylul> sounds good
[15:23] <eylul> can we do the vote over email?
[15:23] <eylul> and put a deadline?
[15:23] <sakrecoer> yes!
[15:23] <sakrecoer> please, lets set a date :D
[15:23] <eylul> Kryten is the only one who doesn't use the ML
[15:24] <eylul> so not sure what to do about that but.. I can ask him to make an exception, once :D
[15:24] <eylul> ok so rosco drafts it
[15:24] <Rosco2> Next Sunday?
[15:24] <eylul> for drafting?
[15:25] <Rosco2> For finalising
[15:25] <eylul> ok
[15:25] <eylul> then we do a vote.. 48 hours sounds good?
[15:25] <Rosco2> Hopefully I can draft by md-week depending on wotk
[15:25] <Rosco2> Sure
[15:25] <eylul> Rosco2: don't hesitate to let me know if you need a second set of eyes on  it
[15:26] <sakrecoer> super!!
[15:26] <eylul> email, or (I also have tox, for voice chat)
[15:26] <sakrecoer> you rock guys!
[15:26] <Rosco2> I will probably send to all of us by email for a quik review
[15:26] <eylul> that sounds good to me
[15:26] <sakrecoer> excellent!
[15:26] <Rosco2> Very productive today!
[15:26] <eylul> do we email the rest of the candidates after voting the council idea?
[15:27]  * sakrecoer getting all nostalgic... i've missed y'all
[15:27] <eylul> we missed you too sakrecoer, :)
[15:27] <Rosco2> +1
[15:27] <eylul> :)
[15:28] <sakrecoer> <3
[15:28] <Rosco2> Thanks all - better go and see the family for what is left of the weeked
[15:28] <eylul> yeah dinner time here
[15:29] <sakrecoer> ok!
[15:29] <sakrecoer> thanks everyone!
[15:29] <sakrecoer> read ya next sunday!
[15:29] <Rosco2> Wish I could jump to AMerican time for the rest of the weekend
[15:29] <sakrecoer> haha!
[15:29] <eylul> :D
[15:29] <eylul> wait rosco2 where ARE you?
[15:29] <eylul> (if you don't mind me asking)
[15:29] <Rosco2> Denmark these days
[15:29] <eylul> ohhh!
[15:30] <eylul> damn I was in copenhagen in feb.
[15:30] <eylul> :)
[15:30] <eylul> anyway
[15:30] <eylul> ok I am off see you all next sunday
[15:30] <Rosco2> Let us know next time - see you all
[15:31] <eylul> will do.
[15:31] <eylul> bye
[20:20] <OvenWerks> krytarik: there was a meeting earlier if you are interested in all our gab you should be able to find it: https://irclogs.ubuntu.com/2017/05/21/%23ubuntustudio-devel.html
[20:20] <krytarik> Yes, I read all of it already.
[20:20] <OvenWerks> cool


[01:04] <mup> PR snapcraft#1367 closed: catkin plugin: add support for ROS Lunar <Created by kyrofa> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1367>
[02:34] <mup> PR snapcraft#1332 closed: cli: provide a whoami command <Created by sergiusens> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1332>
[04:55] <mup> PR snapcraft#1363 closed: tests: use pyramid as a router for the fake servers <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1363>
[05:40] <mup> PR snapd#3517 opened: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>
[07:36] <fgimenez> good morning mvo, i'm already running the core-revert stable -> edge -> stable test but it seems to get stuck after the first refresh, this will be addressed by snapd#3517, is that correct?
[07:36] <mup> PR snapd#3517: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>
[07:45] <fgimenez> mvo: the error i get is "Jun 23 07:15:00 localhost snap[1685]: cannot open cookie file /var/lib/snapd/cookie/snap.network-managercannot stat /var/lib/snapd/seccomp/bpf/snap.network-manager.networkmanager.bin: No such file or directory"
[08:10] <fgimenez> mvo: fwiw we got a new edge core built from the edge ppa this morning, maybe there are bits in there that shouldn't be part of 2.26.last
[08:52] <mvo> fgimenez: thank you, I was able to reproduce, the cookie error is a red herring, the real issue is that we have a race, I think #3517 will fix it
[08:58] <fgimenez> mvo: great thank you, let me know if i can be of any help
[09:00] <mvo> fgimenez: no worries, I just need reviews
[09:13]  * zyga waves from Poland
[09:16] <mvo> zyga: welcome home!
[09:16] <zyga> mvo: hey, thank you :)
[09:17] <zyga> how are things?
[09:17] <zyga> I'm pretty sleepy but eager to wake up, the plane was delayed by two hours and departed after midnight...
[09:17] <zyga> but it's all behind us now, the day awaits
[09:17] <mup> PR snapd#3516 closed: asserts: implement FindManyTrusted as well <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3516>
[09:17] <mvo> zyga: things are good
[09:18] <mvo> zyga: if you want to review stuff, 3517 might be an interessting one
[09:18] <zyga> yes, I think that's a good use of my time today
[09:18] <mvo> zyga: 3512 as well
[09:18] <mvo> zyga: I think I will merge the shellcheck ones with a single reivew only, those are pretty mechanical and tests ar efine
[09:19] <mvo> zyga: 3514 is an easy win
[09:20] <zyga> mvo: am I reading 3512 right that it will re-exec tools on distros that don't reexec?
[09:20] <zyga> mvo: I think this is very undesirable and will break if used today
[09:20] <mup> PR snapd#3511 closed: tests: shellcheck improvements for unit tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3511>
[09:21] <mvo> zyga: unless I made a mistake it should not do this. it will look at the running snapd, if that is re-execed it will use the reexecd path
[09:21] <zyga> mvo: ah, ok, let me read that in detail
[09:21] <zyga> mvo: but that should be good
[09:21] <mup> PR snapd#3514 closed: wrappers: add SyslogIdentifier to the service unit files <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3514>
[09:21] <pstolowski> zyga, hey! :)
[09:22] <mvo> zyga: the code could actually be even simpler, it could just always use $dirname("/proc/self/exe")+tool-name
[09:22] <pstolowski> fgimenez, ping
[09:22] <mvo> zyga: but I think that would break some tests so the way its written now should be ok
[09:22] <zyga> pstolowski: hey :)
[09:22] <zyga> mvo: mmmm, indeed
[09:22] <fgimenez> hey pstolowski and zyga :)
[09:22] <zyga> hey fgimenez :)
[09:23] <zyga> mvo: nice way to solve the current symlink issue btw
[09:23] <pstolowski> fgimenez, hey, advice needed
[09:23] <fgimenez> zyga: how was your trip?
[09:23] <mup> PR snapd#3509 closed: tests: shellcheck improvements for tests/nested tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3509>
[09:24] <mvo> zyga: thank you!
[09:24] <fgimenez> pstolowski: sure, how can i help?
[09:25] <pstolowski> fgimenez, i'd like to create a spread test for revert-hook that I implemented; looking at our revert spread test, we use test-snapd-tools from the store and then switch to the fake store to simulate refresh, so that we can revert. but for my test I need a new custom snap with revert hook inside
[09:26] <pstolowski> fgimenez, so question is, how to do that with minimum hassle
[09:27] <zyga> fgimenez: exhausting, the trafic on costa brava was very heavy in anticipation of the holidays
[09:27] <zyga> fgimenez: the plane was delayed because of thunderstorms in France
[09:27] <zyga> fgimenez: plus lots of stress with packing everything on the very last moment
[09:28] <zyga> fgimenez: but it's all over now so that's all behind me :)
[09:29] <fgimenez> pstolowski: we have been creating the test snaps required by specific tests and, when needed, uploading them to the store under the shared account, i think in this case that should be the right thing to do
[09:31] <pstolowski> fgimenez, sounds good. I think it would be fine to add this new hook to test-snapd-tools; this hook will be a simple one liner that e.g. drops a file somewhere so I can verify it was run. what do you think?
[09:31] <fgimenez> zyga: that's the spirit! :) happy to hear that all went well after all, also tonight is "noche de san juan", good moment to burn the old and embrace new things :)
[09:32] <pstolowski> fgimenez, btw, i'm going to Spain for my vacation in ~3 weeks, reportedly close to where zyga lived ;)
[09:34]  * zyga stops reviews for a moment and goes to make coffee
[09:34] <fgimenez> pstolowski: it's a very beautiful place, you'll enjoy for sure :)
[09:35] <pstolowski> fgimenez, :)
[09:37] <fgimenez> pstolowski: about test-snapd-tools i'd personally prefer to have an specific snap for this test, something like test-snapd-with-configure, test-snapd-with-revert in this case, so that the purpose of each one is clear
[09:37] <niemeyer> Heya
[09:38] <pstolowski> fgimenez, ok, fine by me
[09:38] <pstolowski> niemeyer, hey!
[09:38] <pstolowski> fgimenez, do we use our tests/lib/snaps/ as a source for building these snaps for the real store?
[09:39] <niemeyer> zyga: Happy to hear the move went fine, despite the unavoidable stress it entails :)
[09:41] <zyga> niemeyer: hey!
[09:41] <zyga> niemeyer: yes, it's all good now
[09:41] <zyga> niemeyer: kids are running around the place re-discoveing early childhood items
[09:44] <mvo> zyga: 3464 probably needs a merge of master to make spread work
[09:45] <oSoMoN> what happens when a snap previously published in the store with strict confinement gets an update that declares classic confinement? will the update be applied silently?
[09:49] <ppisati> 'Snap 'ubuntu-core' for 'powerpc' cannot be found in the 'edge' channel.'
[09:49] <ppisati> we have a ppc64el ubuntu-core but no powerpc? how come?
[10:02] <mvo> zyga: a quick look at 3517 would be great, then I can (hopefully) merge and get a new core over lunch for the nested tests
[10:12] <zyga> mvo: ack, looking
[10:13] <zyga> mvo: I have spotty network here, I need to fix it (after the sprint) so don't feel discouraged if I dissapear for a moment
[10:16] <niemeyer> zyga: Lots of nostalgia :)
[10:16] <niemeyer> mvo: Just trivials on snapd#3512
[10:16] <mup> PR snapd#3512: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <https://github.com/snapcore/snapd/pull/3512>
[10:17] <mvo> niemeyer: nice, thank you
[10:17] <mvo> ppisati: I think we don't have powerpc because we can not (or could not back then) build snaps for powerpc
[10:18] <niemeyer> mvo: np, review queue looks quite nice today actually :)
[10:18] <niemeyer> fgimenez: Didn't we decide to drop the static tests from within Travis?
[10:19] <niemeyer> mvo, fgimenez: Btw, any more issues on Linode?
[10:19] <niemeyer> It's sort of amazing that we managed to have a bug on our end and a bug on their end on the same week
[10:19] <mvo> niemeyer: linode was fine for me in the last few hours
[10:19] <mvo> (including last night)
[10:19] <niemeyer> mvo: Phew
[10:20] <fgimenez> niemeyer: afaik they are moved to a spread task let me check
[10:20] <niemeyer> fgimenez: That's what I thought as well, but looking through logs recently they seemed to be back
[10:21] <fgimenez> niemeyer: i've seen some authentication errors like "ssh error 2017-06-22 16:39:58 Discarding linode:debian-unstable-64 (Spread-04), cannot connect: cannot connect to linode:debian-unstable-64 (Spread-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"
[10:21] <mvo> niemeyer: indeed :)
[10:21] <zyga> mvo: two nitpicks on 3517
[10:21] <niemeyer> fgimenez: Ok, but that's from yesterday.. there was a real bug on the Linode side this time around
[10:21] <niemeyer> fgimenez: They fixed it late yesterday
[10:22] <mvo> sure, I will reply inline, thanks a bunch
[10:22] <fgimenez> niemeyer: great, about the static checks they are currently run here https://github.com/snapcore/snapd/blob/master/tests/unit/go/task.yaml#L17
[10:22] <mvo> zyga: atoi(getenv("not-exist")) will segfault :) atoi crashes when oyu feed it a NULL
[10:23] <fgimenez> niemeyer: and travis only runs spread https://github.com/snapcore/snapd/blob/master/.travis.yml#L22
[10:23] <zyga> mvo: I meant under the first if
[10:23] <zyga> mvo: just on the line I commented
[10:23] <niemeyer> fgimenez: Okay, it must have been some old code that hasn't merged back from master in a while then
[10:23] <niemeyer> fgimenez: Thanks for checking
[10:23] <zyga> mvo: or just use variables and be less fancy, I wanted to avoid the repeated getenv and atoi
[10:24] <mvo> zyga: aha, ok
[10:24] <mvo> zyga: I'm inclinded to merge and do a followup mostly to avoid waiting for the tests again, is that ok with you?
[10:24] <mvo> zyga: i.e. when I return from lunch I want to have a new core snap :)
[10:25] <zyga> mvo: certainly, I can follow up as well if you want
[10:25] <zyga> mvo: small bite for the troubled voyager
[10:25] <mvo> zyga: sure, even better
[10:25] <fgimenez> niemeyer: np, thank you, another weird error from linode this morning "cannot boot linode:ubuntu-16.04-32 (Spread-50): linode disk /dev/sda not ready to boot. Please contact support." https://travis-ci.org/snapcore/spread-cron/builds/246018927#L669
[10:25] <mup> PR snapd#3517 closed: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3517>
[10:27] <niemeyer> FFS
[10:27] <niemeyer> fgimenez: This is the CI infra bug week
[10:28] <fgimenez> niemeyer: :) and the ssh issue seems to be still around, this build has it and is currently running https://travis-ci.org/snapcore/snapd/builds/246132571#L908
[10:29] <zyga> niemeyer: about that, did you see those scaleway 128GB ram 64 core VMs that are on sale now?
[10:29] <zyga> niemeyer: I wonder if we could get really solid arm server spread tests this way
[10:29] <niemeyer> fgimenez: Thanks, will look into the console to see if it's the same issue and reopen the ticket
[10:29] <zyga> niemeyer: not pi-like tests, just serious arm server snapd
[10:29] <niemeyer> zyga: The problem with arm is that in general we want to test the actual device
[10:30] <zyga> niemeyer: it _is_ the actual device, this is not the old arm but the new big-iron arm that is not device specific
[10:30] <niemeyer> zyga: That's why those magic SD muxes are so interesting
[10:30] <zyga> niemeyer: modern x86_64 server
[10:30] <zyga> niemeyer: just with arm now :)
[10:30] <niemeyer> zyga: Sorry, I don't get the point
[10:31] <zyga> niemeyer: we test x86 extensively in VMs
[10:31] <zyga> niemeyer: and we test arm on hardware (IOT devices)
[10:31] <niemeyer> zyga: Do you mean this 128GB RAM and 64 core server is actually a Raspberry Pi behind the scenes?
[10:31] <niemeyer> :P
[10:31] <zyga> niemeyer: but we don't have any automated ARM tests like we do for x86 because we don't have arm server hardware (with virtualization and everything)
[10:32] <zyga> niemeyer: I'm saying we could run the very same suite of tests we use on x86 VMs on that arm system for better coverage
[10:32] <niemeyer> zyga: Yeah, and that's what I meant above
[10:32] <zyga> plus, it's beefy and on sale
[10:32] <zyga> niemeyer: arm is not just the pi's
[10:32] <niemeyer> zyga: The problem is that this doesn't really solve the question of whether the supported devices are broken or not
[10:33] <zyga> niemeyer: yes and I'm not saying it does
[10:33] <niemeyer> zyga: Yes, it's one more testing platform, that will need custom kernels, custom gadgets, custom everything
[10:33] <zyga> niemeyer: no, no custom kernels
[10:33] <niemeyer> zyga: Unless someone is working with us to support that, we can't just add more platforms
[10:33] <zyga> niemeyer: arm servers use one kernel
[10:33] <zyga> niemeyer: all acpi and standards based like x86 servers
[10:33] <niemeyer> zyga: That hasn't been my experience with anything arm
[10:34] <zyga> niemeyer: because you deal with non server hardware
[10:34] <niemeyer> zyga: Ok, so which of our kernels will this use?
[10:34] <zyga> niemeyer: stock ubuntu kernel for aarch64
[10:35]  * zyga has to fix his wifi, signal dropping every few seconds
[10:35]  * zyga -> brb
[10:37] <niemeyer> zyga: Okay, so classic Ubuntu rather than Ubuntu Core
[10:41] <zyga> niemeyer: yes, I'd start with that
[11:09]  * Chipaca ~> lunch
[11:13] <zyga> mvo: https://github.com/snapcore/snapd/pull/3518
[11:13] <mup> PR snapd#3518: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
[11:14] <mup> PR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
[11:14] <mvo> zyga: ta
[11:15] <Vamsi> Hi. I had previously asked about a web app store for snaps. And I was suggested to use snapweb. I am facing a problem with snapweb though. I am able access my Ubuntu desktop using the web app store on a browser on the same PC. But I am unable to access my raspbery pi (running on ubuntu core) from the browser on the PC :|
[11:15] <mup> PR snapd#3519 opened: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3519>
[11:15] <Vamsi> Also if it helps, both the PC and the pi are on the same network.
[11:17] <zyga> Vamsi: what kind of error are you seeing?
[11:17] <zyga> mvo: +1
[11:18] <zyga> mvo: consider merging my branch too if we lost that slot anyway
[11:18] <mvo> zyga: ta
[11:18] <Vamsi> zyga: the browser says that the accsess token is invalid.
[11:19] <zyga> Vamsi: I see
[11:19] <zyga> unfortunately I don't know much about snapweb internals
[11:19] <Vamsi> but it accepts the access token from the PC though.
[11:21]  * Chipaca ~> really lunch
[11:22]  * zyga knows the feeling very well Chipaca  :)
[11:24] <zyga> mvo: reviewed 3512
[11:24] <zyga> mvo: let me know if you want me to change that
[11:24] <zyga> mvo: otherwise I'll work on base updates
[11:30] <mup> PR snapd#3520 opened: asserts: add enterprise-store assertion type <Created by atomatt> <https://github.com/snapcore/snapd/pull/3520>
[11:34]  * zyga focuses on base snaps
[12:16] <niemeyer> fgimenez: "In this case there was a problem with how the host was reserving disk space while creating new disks. However, one of our administrators was able to fix the problem, and it shouldn't occur again in the future."
[12:17] <fgimenez> niemeyer: \o/ ? not sure if that souds really well :)
[12:17] <niemeyer> fgimenez: I think it's fine :)
[12:18] <niemeyer> Yesterday the response was "The previous message yesterday was "It looks like this one was a fluke. I've been able to thaw out the same image on your Linode just fine. Please let us know if it happens again and we'll be glad to look into it further."
[12:18] <jacekn> hello. Is https://bugs.launchpad.net/snapd/+bugs the right place for snapd bugs? I filed one yesterday but nobody was subscribed to it and it's still in "New" state
[12:18] <niemeyer> Which is less fine :)
[12:19] <niemeyer> jacekn: If you want quick feedback, the forum is the best place to report issues and discuss them
[12:21] <jacekn> niemeyer: ack. In this case it looks like a bug so I reported it. It's not super critical
[12:22] <jacekn> niemeyer: but is https://bugs.launchpad.net/snapd/+bugs the right place or there is somewhere else I should be reporting bugs?
[12:22] <niemeyer> jacekn: If it's about snapd, that's the right place
[12:22] <jacekn> great, thanks for confirmation
[12:23] <niemeyer> np
[12:26] <jacekn> niemeyer: that location looks dead BTW, there are many old bugs that were not even triaged
[12:26] <niemeyer> jacekn: I really mean it when I said the forum is the place to discuss and get quick feedback
[12:27] <jacekn> niemeyer: as in you prefer people to open forum threads about bugs rather than file them in LP?
[12:29] <niemeyer> jacekn: As in that's where all the daily activities happen, and that's where we discuss issues most frequently.. if you file a bug in Launchpad, it's tracked and will be eventually looked at, but there are many more eyes in the forum every single day
[12:29] <niemeyer> jacekn: If you want to talk about the bug today, please open a forum thread
[12:31] <mup> PR snapcraft#1376 opened: options: fix s390 kernel arch <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1376>
[12:33] <ogra_> ppisati, wow, do we ever exect to support s390 UbuntuCore installs ?
[12:33] <ogra_> expect
[12:34]  * ogra_ thinks s390x and ppc64el should simply not be built by the plugin by default ... it is unlikely that anyone will ever actually boot UbuntuCore on such systems
[12:34] <ogra_> (kernels that is)
[12:34] <jacekn> niemeyer: thanks for explaining. I don't want/need to talk about the bug, totally happy to wait. I wanted to make sure that LP bug tracking was not dead (because that's what it may look to people without context abotu forums)
[12:34] <mup> PR snapcraft#1377 opened: kernel plugin: add default targets per powerpc, ppc64el and s390x <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1377>
[12:34] <xnox> ogra_, our contracts says different =)
[12:35] <ogra_> xnox, you mean there will be people booting off an UbuntuCore image natively ?
[12:35] <xnox> ogra_, and core is very much usable in kvm / openstack on both s390x and ppc64el.
[12:35] <xnox> ogra_, yes.
[12:35] <ogra_> wow
[12:35] <niemeyer> jacekn: It's not dead, but it's not well maintained today either, as you've noticed. That's something we need to fix.
[12:37]  * ogra_ notes that he just triaged two snapd bgs that were filed today ... definitely not dead, just not moving super fast since many issues are resolved in forum discussions before even becoming actual bugs
[12:44] <Chipaca> pedronis: question about aliases: in the json you get from the store, is the 'target' the name of the app?
[12:44] <pedronis> Chipaca: which json?
[12:45] <Chipaca> pedronis: ah, maybe this doesn't come to you as json yet
[12:45] <Chipaca> but in the declaration itself i guess?
[12:45] <pedronis> Chipaca: it's in the assertion
[12:45] <pedronis> is not json
[12:45] <Chipaca> that'd explain why a quick search didn't find me the json bits of this :-)
[12:45] <Chipaca> pedronis: ok. I'll be getting a list of aliases from the store, in json
[12:46] <pedronis> ok
[12:46] <Chipaca> pedronis: [{"name": "foo", "target": "bar"}, ...]
[12:46] <pedronis> but that's unrelated to how we do aliases
[12:46] <pedronis> for actually installed snaps
[12:46] <pedronis> those comes from the signed snap-declaration
[12:46] <Chipaca> pedronis: right, this is for command-not-found, ie for non-installed snaps
[12:46] <pedronis> I know nothing about that (atm)
[12:46] <Chipaca> ok
[12:47] <pedronis> but yes, internall we keep things as name, taget
[12:47] <pedronis> I mean in the internally in the store
[12:47] <Chipaca> pedronis: and target is the app name?
[12:47] <pedronis> yes
[12:47] <Chipaca> ok
[12:47] <pedronis> it's a plain app name
[12:48] <pedronis> not snap.app
[12:48] <Chipaca> just double-checking with nessita_ that things are sane :-)
[12:48] <Chipaca> that's fine, it'll be "inside" a snap
[12:48] <Chipaca> {"package_name": "some-snap", "aliases": [...]}
[12:48] <Chipaca> so i'll know the snap :-)
[12:50] <mvo> fgimenez: yay, good news. the nested core-revert test seems to be working now with current edge
[12:51] <fgimenez> mvo: \o/ wonderful news!!! congrats for all the hard work
[12:51] <fgimenez> mvo: shall i start with the full validation?
[12:57] <mvo> fgimenez: some smoke testing for edge with the core revert would be great, or just an independant re-run, I need to get this all backported to 2.26, then we can do te real validation
[13:01] <fgimenez> mvo: sure, i have the core revert already running locally, in fact it was started automatically too by spreadcron when the new core was detected but  it was killed because of the time restriction https://travis-ci.org/snapcore/spread-cron/builds/246175108
[13:02] <fgimenez> i'll run some additional smoke tests
[13:27] <fgimenez> cachio: we are still getting create-key timeout errors, have all the fixes landed? https://travis-ci.org/snapcore/spread-cron/builds/246175157
[13:29] <cachio> fgimenez, ouch
[13:29] <cachio> fgimenez, it is failing to restart the service
[13:32] <cachio> fgimenez, the manual was working better than the automatic restart
[13:35] <cachio> did you merge your branch with the latest changes in master?
[13:35] <cachio> fgimenez,
[13:37] <fgimenez> cachio: yes, this is executed from the current master
[13:38] <fgimenez> cachio: https://github.com/snapcore/spread-cron/blob/snapd-core-i386-edge/run-checks
[13:38] <cachio> fgimenez, ok, thanks for the info, I'll research more
[13:39] <fgimenez> cachio: ok thx
[13:41] <jdstrand> mvo: nice speed improvement in https://github.com/snapcore/snapd/pull/3502. Thanks for doing that PR (fyi, I commented)
[13:41] <mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
[13:43] <zyga> jdstrand: hey
[13:43] <zyga> jdstrand: greetings from Poland :)
[13:44] <jdstrand> zyga: hi! :) nice to be back?
[13:46] <zyga> jdstrand: it's a big change in our lives, not sure yet :)
[13:46] <jdstrand> mvo: I also notice https://github.com/snapcore/snapd/pull/3504 isn't committed yet. isn't it needed to truly test the revert regression that the bpf fixes?
[13:46] <mup> PR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>
[13:46] <zyga> jdstrand: thank you for the review on the cleanup, I'll follow up shortly
[13:46] <jdstrand> zyga: oh, permanently? wow
[13:46] <jdstrand> zyga: thanks you for doing it :)
[13:46] <zyga> jdstrand: yes, all our stuff is packed into ~60 boxes now
[13:46] <zyga> jdstrand: (most haven't arrived yet)
[13:47] <jdstrand> some quick example code went through as is and then I missed the NULL checks :\ that's why we have more than one reviewer! :)
[13:47] <zyga> jdstrand: yep, it's always possible to miss something
[13:48] <zyga> jdstrand: but I'm very happy with the changes towards precompiled bpf
[13:48] <jdstrand> zyga: does this mean you will attend (in part or in whole) the Warsaw sprint?
[13:48] <zyga> jdstrand: it's going to be safer and faster
[13:48] <zyga> jdstrand: I plan to but I didn't talk to JamieBennett about it yet
[13:48] <zyga> jdstrand: if anything I'll drop by to get a coffee and say hi :)
[13:48] <jdstrand> zyga: if you do, we can visit (I'll be there)
[13:48] <fgimenez> mvo: core-revert succeeded with the edge core snap \o/ I'm currently generating images for running the full suite on them, will keep you posted
[13:48] <zyga> jdstrand: I'd never miss the only sprint in warsaw :)
[13:48] <jdstrand> hehe :)
[13:49] <zyga> jdstrand: that's great to hear :-) I'll show you around Warsaw (except I need to catch up after 6 years of living in Spain)
[13:49] <jdstrand> fgimenez: note my above question to mvo re https://github.com/snapcore/snapd/pull/3504
[13:49] <mup> PR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>
[13:52] <fgimenez> jdstrand: aha thanks, good to know, all seems to be working fine now fwiw, anyway will keep running it in a loop to try to catch racy results
[13:55] <jdstrand> fgimenez: I guess there was the netlink revert failure that never had the policy reverted. I don't know if you are testing that snap, but if you are, then that PR isn't strictly needed to demonstrate the fix
[13:56] <mvo> jdstrand: hey, thanks for the review of 3502. re 3504 - our test also failed without the reverts, but I agreee, we should do the test with that one merged too. we had a failure with bluez that hit exactly the same issue so I'm quite confident that the fix is there. but then, I'm much in favour of double checking :)
[13:57] <mvo> jdstrand: it needs a second review, then it can go in
[13:58] <jdstrand> mvo: yeah, I just remembered netlink wasn't reverted
[13:58] <fgimenez> jdstrand: exactly, the test includes bluez, which was failing after revert with "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process", with the current core at edge this problem is gone
[13:58] <jdstrand> ok, perfect
[13:58] <jdstrand> perhaps zyga would want to peek at 3504 :)
[14:01] <mup> PR snapd#3519 closed: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3519>
[14:43] <niemeyer> It's getting to that point where I type "snap install blah" and then wonder why nobody has snapped blah yet
[15:19] <mup> PR snapcraft#1378 opened: Integration tests for snap command with target arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1378>
[15:26] <mvo> fgimenez: hm,hm, it looks like #3519 got merged 4h ago but its not part of the snapd-vendor branch (and hence not in the ppa) yet, any idea?
[15:26] <mvo> fgimenez: can I manually trigger this?
[15:29] <fgimenez> mvo: mm maybe the build after merging on master didn't succeed, the sync is done after merge + green build
[15:30] <fgimenez> mvo: i'll check, anyway you can retrigger from #mupmock on tg, this will get the current master no matter if the test passed or not, let me show you
[15:40] <mup> PR snapd#3521 opened: snap-seccomp: make sure snap-seccomp writes the bpf file atomically <Created by mvo5> <https://github.com/snapcore/snapd/pull/3521>
[15:41] <fgimenez> mvo: i got two errors executing the suite from master on the latest edge http://paste.ubuntu.com/24933366/, if you could take a look that would be great, i'm trying to reproduce both of them now
[15:42] <mvo> fgimenez: thanks, 2017/06/23 16:52:12 Error executing external:ubuntu-core-16-64:tests/main/server-snap:goServer :  is strnage, no denials or anything
[15:44] <mvo> fgimenez: the snapd-notify is hopefully fixed with 3515
[15:44] <mvo> cachio: could oyu please check 3515 why the testsuite fails?
[15:44] <fgimenez> mvo: ok thx, i'll focus on server-snap:goServer then
[15:45] <mvo> Chipaca: 3521 is something for you, the best thing is that we probably caught it via one of the tests :)
[15:45] <mvo> (spread tests)
[15:54] <fgimenez> mvo: it fails consistently, adding -v to the nc call i get "nc: connect to ip6-localhost port 8081 (tcp) failed: Cannot assign requested address", the session is open in case you want to get anything else
[15:54] <mvo> fgimenez: is the service itself running?
[15:56] <fgimenez> mvo: yep, it's up and listening on 8081 http://paste.ubuntu.com/24933471/
[16:07] <fgimenez> mvo: i think this is probably related to the changes to the way we manage ipv6 when /etc/gai.conf is not writable http://paste.ubuntu.com/24933600/
[16:08] <mvo> fgimenez: aha, puhhh, that a) makes sense b) means I did not break it .)
[16:09] <fgimenez> mvo: yep :) http://paste.ubuntu.com/24933635/ i'll prepare a PR for fixing it
[16:09] <mvo> fgimenez: I broke master bug 35212 should fix that
[16:09] <mup> Bug #35212: unable to compose messages <Mozilla Thunderbird:Fix Released> <mozilla-thunderbird (Ubuntu):Fix Released by adconrad> <https://launchpad.net/bugs/35212>
[16:10] <fgimenez> mvo: thx, np
[16:12] <fgimenez> mvo: anyway, it won't affect the backport to 2.26, we didn't have any changes related to /etc/gai.conf there
[16:29] <mup> PR snapd#3522 opened: tests: do not disable ipv6 on core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3522>
[16:52] <mup> PR snapcraft#1374 closed: tests: set up the spread execution in linode <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1374>
[17:04] <mup> PR snapcraft#1379 opened: blank version not allowed in snapcraft.yaml <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1379>
[17:16] <mup> PR snapcraft#1380 opened: release changelog for 2.32 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1380>
[17:44] <mup> PR snapd#3523 opened: tests: fix for create-key task to avoid rng-tools service ramains alive <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3523>
[18:11] <mup> PR snapd#3524 opened: asserts,overlord/devicestate: allow and support serials signed by a trusted authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3524>
[18:25] <mup> PR snapd#3522 closed: tests: do not disable ipv6 on core systems <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3522>
[18:41] <mup> PR snapcraft#1381 opened: tests: install pyramid in autopkg integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1381>
[19:29] <cachio> mvo, sorry for the delay
[19:30] <cachio> the 3515 is failing due to the reboot error
[19:30] <cachio> mvo, it is one of the most difficult tests to fix
[19:32] <cachio> mvo, it always happens on ubuntu-core-16-64 and the issue is that after the core image is created and the system rebooted, the machine does not start anymore
[19:35] <cachio> mvo, I also pushed a fix for the create-key issue, this should be the final one
[19:44] <mvo> cachio: nice, thank you
[19:44] <cachio> mvo, if you can retrigger it should be fine
[19:44] <mvo> cachio: yeah, I noticed the that the ubuntu-core-16-64 issue is tricky
[19:44] <mvo> cachio: sure, let me do that
[19:45] <cachio> mvo, then if you can trigger also 3523
[19:46] <cachio> if failed because of the snapd-notify
[19:46] <cachio> it failed
[19:48] <mvo> cachio: sure thing
[19:49] <mvo> cachio: I can not (easily) retrigger autopkgtests, we need to ignore those for now. sorry for that
[19:54] <cachio> mvo, np
[20:15] <mup> PR snapd#3525 opened: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3525>
[20:59] <cachio> niemeyer, could yo please take a look to Spread-14
[20:59] <cachio> in the console
[20:59] <cachio> niemeyer, <IP_ADDRESS>
[21:01] <cachio> niemeyer, in case it is powered off, could yo uplease try to start it and see the screen output?
[21:14] <mup> PR snapcraft#1381 closed: tests: install pyramid in autopkg integration tests <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1381>


[09:53] <magicaltrout> can i tell a reactive charm to not execute a block until all the units are in the same state?
[09:54] <magicaltrout> kjackal: you'll know the answer to that
[09:55] <kjackal> Hi magicaltrout
[09:55] <kjackal> let me think...
[09:56] <kjackal> magicaltrout: ok so, here is how you can do that. You can have a relation of peer type among the service units
[09:57] <kjackal> you should then make sure the units set the correct state within the interface implementing the peer relation
[09:59] <magicaltrout> ah right yeah, so just plonk in a "we're all ready for the next step" state in my interface
[09:59] <kjackal> for example, when you enter the correct stare you do something like this inside the interface: "remove_state('wrong.state') set_state('correct.state')"
[10:00] <kjackal> then inside the reactive part you should have something like @when_not('peers.in.wrong.state') def do_whatever: ....
[10:01] <kjackal> Let me think....
[10:01] <kjackal> So there might be another way to do that
[10:01] <kjackal> You could you the leader layer
[10:02] <kjackal> the leader should be gathering info on the state of the units and the units should ask the leader if all of them are in the right state
[10:03] <kjackal> I am sure this solution with the leader is doable, but I do not have it in my head right now, I will need to do ome research on this
[10:03] <kjackal> magicaltrout: ^
[10:03] <kjackal> magicaltrout: any comment on the referendum?
[10:03] <magicaltrout> yeah i'm just looking at stub 's github page thanks kjackal
[10:04] <magicaltrout> yeah, fucking shit
[10:04] <magicaltrout> anyway
[10:04] <magicaltrout> not great, the uk has had better days
[10:06] <kjackal> in the bigdata world the need of coordination among units is a bad sign, and is usualy outsorced to services like zookeeper. I am sure you already know that
[10:06] <magicaltrout> DC/OS has an immutable configuration for whatever reason
[10:06] <magicaltrout> so they expect all masters to be up and running before installing the config on them
[10:07] <magicaltrout> i'm sure there is a way to do it on the fly, but they don't document it. So, spin up the masters, wait for all the ip's to be addressable and then run the config setup
[10:17] <stub> magicaltrout: The problem you might trip over is that you don't know when all the units have actually joined the peer relation. You can detect all units that have joined so far are in a particular state, but you don't know how many more nodes are yet to be provisioned and join.
[10:17] <magicaltrout> yeah i know stub I was just mulling that over
[10:19] <stub> magicaltrout: The approach I use is have the leader set itself up as a stand alone unit, and as other units join have them grab a lock (using the coordinator layer) and have them join one at a time.
[10:20] <kjackal> yes stub is right.  Question for you stub, how do you know if you will have 4 or 5 masters for example?
[10:20] <stub> Assuming your service can dynamically scale out like that
[10:20] <kjackal> does the leader know upfront the exact number of masters that should join?
[10:21] <magicaltrout> the 2nd option i have is just to figure out how to make the DC/OS masters scaleable but they lock down the setup reconfig so I  need to reverse engineer their installer :)
[10:21] <magicaltrout> the other idea I had for simplicity was just to dump it all in an action
[10:21] <magicaltrout> that would at least get it going quicker ;)
[10:21] <stub> kjackal: Unless it is specified by the user in configuration ('I want 3 masters' or 'there will be at least 10 nodes'), then the leader has no way of knowing how many units are expected to join.
[10:22] <stub> kjackal: So the leader will need to make a decision, starting with 1 master since it is standalone, and revise this decision as more units join.
[10:23] <kjackal> stub: understood, yes the leader needs to know or guess the number of masters
[10:33] <magicaltrout> on the bright side... my new 4k monitor just turned up
[10:33] <magicaltrout> might need to buy a 2nd one now
[11:04] <kjackal> magicaltrout: I think next step should be to get  3 more 4k monitors so that you would make an 8k!
[11:04] <magicaltrout> kjackal: I have a thunderbolt 3 port
[11:05] <magicaltrout> which drives dual hdmi
[11:05] <magicaltrout> plus a hdmi port on the laptop
[11:05] <magicaltrout> so.......
[11:05] <kjackal> do you turn your back on a challenge?
[11:05] <magicaltrout> hehe
[11:05] <magicaltrout> only britain staying in the EU
[11:49] <magicaltrout> one thing I do know
[11:49] <magicaltrout> today is a really bad day to get paid in USD.....
[13:03] <icey> lots of aws service failures this morning
[15:09] <dannf> arosales, beisner : ICYMI - there's a mongodb build for z now - https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1595242/comments/1
[15:09] <mup> Bug #1595242: mongodb xenial s390x packages are needed (blocks ceilometer) <s390x> <uosci> <mongodb (Ubuntu):New> <ceilometer (Juju Charms Collection):New> <ceilometer-agent (Juju Charms Collection):New> <mongodb (Juju Charms Collection):New> <https://launchpad.net/bugs/1595242>
[15:18] <arosales> dannf: very cool. OpenStack is still blocked until we can put this into a charm
[15:18] <arosales> dannf: I am working with marcoceppi to work on this which we should hit by end of June, but OpenStack won't be able to consume till post that
[15:20] <dannf> arosales: i pasted a link to my MP for mongodb that used a ppa for arm64 into that bug
[15:36] <beisner> dannf, arosales - awesome.  look forward to revisiting :)
[15:39] <arosales> dannf: https://launchpad.net/~ubuntu-s390x-community/+archive/ubuntu/mongodb is the latest correct?
[15:45] <arosales> dannf: also think for the pointer to the MP for the ARM enablment in mongo
[15:48] <arosales> kjackal: sorry for being dense here but what steps am I missing @ http://paste.ubuntu.com/17806346/ to reproduce  https://bugs.launchpad.net/juju-core/+bug/1593185
[15:48] <mup> Bug #1593185: In lxd the containers own fqdn is not inclused in /etc/hosts <addressability> <hours> <lxd> <lxd-provider> <network> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1593185>
[16:00] <dannf> arosales: yep, that's the latest (and only) :)
[16:02] <kjackal> arosales: Ok, you deployed the ubuntu. The bug is that you cannot "ping juju-1706c4-0"
[16:02] <lazyPower> cory_fu - got a sec to chat about https://github.com/juju-solutions/charmbox/pull/40 ?
[16:02] <kjackal> let me try to find my repro of the bug
[16:02] <cory_fu> lazyPower: Sure
[16:03] <lazyPower> cory_fu - just to be clear on intent, we want this to target devel, and only land in devel.
[16:03] <lazyPower> and this is to reduce the divergence of those two branches?
[16:03] <arosales> dannf: thanks
[16:04] <lazyPower> i think this only effects mbruzeks PR that was made slightly before this pr, but this looks pretty sane.
[16:04] <arosales> kjackal: that does fail for me, but does that break models?
[16:04] <cory_fu> lazyPower: Yes, that branch (new-devel) should *replace* devel and then devel should remain only that single commit different from master and be constantly rebased up to master
[16:04]  * arosales doesn't ping hostnames if I can ssh to them
[16:05] <kjackal> arosales: http://pastebin.ubuntu.com/17395368/
[16:05] <arosales> but if inter charm communication is broke, then that is a huge issue
[16:05] <lazyPower> cory_fu - ok, makes sense. I'll start getting this landed and ping if any additional questions crop up. I'm more interested in making sure I was reading the directions clearly :)
[16:06] <kjackal> arosales: yes, for a few minutes the connection using the fqdn is broken
[16:07] <kjackal> arosales: from what dimitern told me there is a dhcpclient that is firing for no good reason and it breaks the resolution
[16:08] <kjackal> AFAIU adding the hostname on the etc/hosts file will cause the dhcpclient process not to fire
[16:10] <kjackal> arosales: our discussion is here: https://irclogs.ubuntu.com/2016/06/16/%23juju-dev.txt at around 10:00
[16:11] <arosales> kjackal: ok let me see if hadoop-processing works here in lxd
[16:12] <arosales> it inter charm communication works, agreed it is a bug, but perhaps not as huge a blocker as I initially thought
[16:14] <kjackal> arosales: I know for certain kafka start-up is failing because of this bug, petevg can confirm this because he hit this bug when reviewing the kafka charm
[16:15] <petevg> Yep. Can confirm.
[16:15] <petevg> I was able to reproduce consistently, too.
[16:16] <petevg> Should I leave a comment on a ticket?
[16:18] <arosales> kjackal: is you latest charm https://jujucharms.com/u/bigdata-dev/kafka/trusty or https://jujucharms.com/u/bigdata-dev/apache-kafka/trusty or should I build from layers?
[16:18] <kjackal> https://jujucharms.com/u/bigdata-dev/kafka/trusty  is the latest BT kafka
[16:19] <kjackal> you should relate that kafka charm to openjdk and apache-zookeeper
[16:20] <arosales> kjackal: ok
[16:20] <arosales> kjackal: thanks
[16:20] <arosales> I'll post my info to the bug, and I work to follow up next week with the juju team
[16:20] <kjackal> note that you have to be fast enough (or the machine slow enough) so that the dhcp client wont finish
[16:20] <arosales> at least its on the target milestones though just need to be sure it gets to a release soon
[16:29] <jcastro> anyone know where I can find the juju log if debug-log doesn't work?
[16:31] <petevg> jcastro: if you got to a point where a unit was deployed, you can do "juju ssh <service>/<unit>", and then look in /var/log/juju/
[16:31] <petevg> If you don't have a working unit, you can try doing "juju deploy --debug <charm>"
[16:31] <jcastro> nope, the instance launches and the container immediately stops and is removed, so I think it has something to do with provisioning the container
[16:32] <petevg> Hmmm ... If you do a deploy with the --debug flag, do you get any output that hints at what might be going wrong?
[16:34] <jcastro> http://paste.ubuntu.com/17808709/
[16:34] <jcastro> I can launch instances just fine from the lxc command line
[16:37] <petevg> jcastro: hmmm. That looks normal to me. I'm afraid that you're bumping up against the limits of my knowledge. Does anyone else have any ideas as far as troubleshooting goes?
[16:41] <jrwren> jcastro: what does `juju status --format yaml` say?
[16:45] <jcastro> aha!
[16:45] <jcastro> more information
[16:45] <jcastro> http://paste.ubuntu.com/17809286/
[16:48] <jrwren> jcastro: but lxc launch starts an  instance ok?   i'm not familiar with lxd forkstart and how juju starts lxd instances.
[16:49] <jcastro> yeah, mannual launching works, so it's this forkstart that must be the issue
[16:49] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1577524
[16:49] <mup> Bug #1577524: Error calling ''lxd forkstart juju-machine-2-lxd-0 /var/lib/lxd/containers             /var/log/lxd/juju-machine-2-lxd-0/lxc.conf'': err=''exit
[16:49] <mup> status 1'' <ci> <deploy> <intermittent-failure> <juju-release-support> <lxd> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1577524>
[16:50] <jrwren> jcastro: and the container is already gone? can you `lxc info --show-log juju-5c3262-0` ?
[16:50] <jcastro> nope, the container comes up and goes away long before I can do that
[16:51] <jcastro> aha, the units log to /var/log/lxd and those are still there, going to go dig
[16:54] <jcastro> jrwren: can you pastebin me the results of your: lxc profile show juju-default
[16:55] <jcastro> the error in the logs was a networking one related to the modified template I was using to get openstack running on lxd
[16:56] <jrwren> jcastro: its pretty empty. http://paste.ubuntu.com/17809808/
[17:05] <jcastro> that appears to have fixed me up!
[17:28] <jrwren> WOOT!
[17:33] <xilet> so I have asked about this a few different ways, but I am still unclear and the documentation is.. lacking.  With juju 2.0 how do I tell a container what device(s) it can access on the hardware it is running on?  I can't find any way to tell it to use '/dev/sdb1' or allow access to '/dev/ttyUSB0' or such. I can do it with lxc but I know that is replaced with lxd.
[17:37] <cory_fu> jcastro, tvansteenburgh: I'm hitting the same problem testing wiki-simple with the new mysql that I was seeing before: It's not honoring the setup: directive in the mysql charm's tests.yaml file.  That means it had nothing to do with me testing it with local: in the bundle before, because I'm using cs: now
[17:37] <cory_fu> The "it" in this case is bundletester.  I'm wondering if it's only honoring tests.yaml from the bundle itself?
[17:38] <tvansteenburgh> cory_fu: please file a bug on bt with steps to repro
[17:56] <cory_fu> tvansteenburgh: Actually, I jumped the gun.  The problem isn't BT.
[17:57] <cory_fu> marcoceppi: You're going to love this.
[17:57] <cory_fu> marcoceppi: Going to need another fix to mysql.  >_<
[17:58] <cory_fu> My bad
[18:11] <cory_fu> I'm also running up against the '==' length error from `pip3 list` that's due to an older lib version in trusty which is causing 00-setup to fail.  Does anyone recall what lib caused that issue and if there's a good way to fix it?
[18:11] <cory_fu> For reference: http://pastebin.ubuntu.com/17813844/
[18:14] <cory_fu> marcoceppi: Should I just remove this check altogether and always try to install PyMySQL?  https://github.com/marcoceppi/charm-mysql/blob/master/tests/setup/00-setup#L33
[18:15] <cory_fu> 00-setup now gets called before each case (e.g., charm proof, make lint, etc) so I wanted to minimize network traffic
[18:17] <cory_fu> Actually, it looks like it doesn't do network traffic if it's already present, so yes, I should just remove it
[18:21] <marcoceppi> cory_fu: do what you must, I support any change
[18:22] <cory_fu> marcoceppi: https://github.com/marcoceppi/charm-mysql/pull/1
[18:23] <marcoceppi> cory_fu: ta
[18:24] <marcoceppi> man, I really want a post commit push process for github now
[18:24] <marcoceppi> like, commit, build/test, push to norevision/development channel
[18:25] <cory_fu> marcoceppi: Yeah, +1
[18:25] <marcoceppi> cory_fu: published
[18:26] <marcoceppi> cory_fu: I wonder if travis could do this. Like with a travis plugin
[18:26]  * marcoceppi investigates
[18:28] <cory_fu> marcoceppi: Huh.  Why'd it go from 52 to 54?
[18:28] <marcoceppi> cory_fu: it actually was 53 at one point
[18:29] <cory_fu> Not when I looked at it.  I think you might have forgotten to publish 53.  I saw you mention that it had gone up again but still saw it at 52 and just didn't say anything
[18:29] <cory_fu> Anyway, it's sorted now
[18:32] <marcoceppi> cory_fu: I also want to find a way to notify bundle owners
[18:32] <marcoceppi> like "mysql has been incremented to 54, please check yo bundles bro"
[18:32] <cory_fu> Indeed
[18:33] <cory_fu> Shouldn't be very difficult.  The store has a list of bundles using a given charm rev
[18:34] <marcoceppi> yeah, and we know owners and bug urls
[18:34] <marcoceppi> I should be able to do if gh || lp - open a bug from bundlebot
[18:35] <marcoceppi> first, figure out travis
[18:40] <cory_fu> marcoceppi: Ok, I'm super pissed at the mysql charm right now
[18:40] <marcoceppi> cory_fu: y u do dis
[18:41] <cory_fu> marcoceppi: http://pastebin.ubuntu.com/17815449/
[18:42] <cory_fu> So, the test has the max connections that it is testing hard-coded, but the bundle deploys with a different number.  So the charm test and the bundle are incompatible
[18:42] <cory_fu> Actually, the bundle gives -1 so there is no way the test will work
[18:43] <marcoceppi> cory_fu: which bundle, yours?
[18:43] <cory_fu> wiki-simple
[18:44] <marcoceppi> weird, shouldn't the test run the configure?
[18:44] <marcoceppi> OIC
[18:44] <marcoceppi> it's set prior to setup, so it's not executed live
[18:45] <cory_fu> So I guess I could fix it by removing reset: false
[18:45] <marcoceppi> cory_fu: this should fix it in MySQL
[18:45] <marcoceppi> http://paste.ubuntu.com/17815662/
[18:45]  * marcoceppi tests
[18:49] <marcoceppi> cory_fu: this, I think, is the fix
[18:49] <marcoceppi> https://github.com/marcoceppi/charm-mysql/pull/2
[18:49] <marcoceppi> cory_fu: going to test the bundle with my version
[18:56] <marcoceppi> cory_fu: what flags are you using on bundletester?
[18:56] <cory_fu> -vlDEBUG -b bundle.yaml
[18:57] <cory_fu> marcoceppi: I also have these changes pending: http://pastebin.ubuntu.com/17816358/
[18:58] <cory_fu> (The seemingly no-ops are eol-whitespace deletes)
[18:58] <marcoceppi> cory_fu: I have a few as well
[18:58] <cory_fu> marcoceppi: Still getting the max connections error
[18:59] <cory_fu> tvansteenburgh1: Is there a way to make BT not delete the tmp directory for a charm being tested as part of a bundle so I can verify it's using the right change?
[18:59] <cory_fu> I guess I can breakpoint
[19:01] <cory_fu> Odd.  Second time through (with already deployed charms, to add the breakpoint), it passed the config check.  grr
[19:04] <lazyPower> cory_fu - https://hub.docker.com/r/jujusolutions/charmbox/builds/byulnqrh6s44sovbabborg/  new charmbox:devel is being built from your branch work. Thanks for submitting that
[19:04] <cory_fu> lazyPower: Sweet.  I'm looking forward to not having to manually install bundletester and make every time now.  ;)
[19:05] <cory_fu> (Not that they work with the current betas >_<)
[19:05] <lazyPower> cory_fu - make sure it got everything you wanted... i had to manually merge due to conflicts
[19:05] <cory_fu> o_O
[19:05] <lazyPower> well, you targeted master not devel
[19:06] <lazyPower> then left explicit instructions this was to be applied against devel
[19:06] <lazyPower> soooo *throws confetti*
[19:06] <cory_fu> Oh noooooooooo!
[19:06] <lazyPower> do i need to back this out?
[19:06] <cory_fu> lazyPower: I said it should *replace* devel, not merge into it!
[19:06] <lazyPower> ah ok
[19:06] <lazyPower> welp easy enough
[19:06] <lazyPower> 1 sec incoming fix, disregard that build as its garbage
[19:06] <cory_fu> :)
[19:07] <cory_fu> lazyPower: The whole point of that commit is to keep the devel branch as *exactly* 1 commit different from master.  Then, any changes that need to happen should go in master and the devel branch is then rebased against master
[19:08] <lazyPower> no i got the principal
[19:08] <lazyPower> i just botched the instructions
[19:08] <cory_fu> Ok, sure
[19:08] <cory_fu> But yeah, my intention was just to delete the whole of the current devel (or move it to old-devel if you want to preserve it for some reason) and replace it with the new-devel
[19:10] <lazyPower> https://hub.docker.com/r/jujusolutions/charmbox/builds/bnoyhnumjzrrrfp2gn3emiy/
[19:10] <lazyPower> that should make a bit more sense then :)
[19:11] <cory_fu> lazyPower: Build failed.  :(
[19:11] <cory_fu> Very strange
[19:12] <cory_fu> marcoceppi: I'm getting intermittent failures on that stupid max connections test.  :(
[19:12] <marcoceppi> of all the stupid configuration options to test, it has to be /that one/
[19:12] <lazyPower> cory_fu pip install directive failed
[19:12] <lazyPower> i'll pull it local and get it building before we submit to the builders again
[19:13] <marcoceppi> cory_fu: I'm waiting for my tests to finish, then I'm going to make better tests
[19:14] <marcoceppi> cory_fu: I don't need to test that MySQL knows how to handle max connections, I just need to test the damn file got written
[19:14] <cory_fu> Yeah, +1
[19:14] <marcoceppi> make tests great again
[19:15] <cory_fu> marcoceppi: Mind if I just hand wiki-simple off to you, then, so I can get back to some Bigtop stuff I've been neglecting?
[19:15] <marcoceppi> cory_fu: uh, sure
[19:15] <cory_fu> So confident.  :p
[19:17] <cory_fu> marcoceppi: Actually, I'll go ahead and update wiki-simple with mysql-54 without reset: false so that you don't have to worry about the bundle
[19:19] <marcoceppi> cory_fu: don't we want reset: false?
[19:19] <marcoceppi> I know I do
[19:20] <cory_fu> Yeah, we do, because it'll make the bundle tests faster
[19:21] <cory_fu> Also, I'm pretty sure that max-connections test is racey anyway, so nevermind, I'll leave the bundle to you after all
[19:21] <cory_fu> Or you can just let me know when you've fixed up mysql and I'll update the bundle then
[19:21] <cory_fu> Whatever
[19:25] <marcoceppi> cory_fu: cool
[19:32] <lazyPower> cory_fu - it appears upgrading pip befor einstalling the deps resolves the build failure
[20:49] <magicaltrout> blimey
[20:49] <magicaltrout> its taken all day to figure out how to make the DC/OS masters scale dynamically
[20:49] <magicaltrout> but i think I've finally solved the problem
[20:49] <magicaltrout> \o/
[20:49] <lazyPower> magicaltrout nice :)
[20:50] <magicaltrout> they make their configs immutable
[20:50] <lazyPower> not an easy task from what i've gleaned
[20:50] <magicaltrout> which is a *right* pain in the backside
[20:50] <magicaltrout> their offical advice if you want to add more masters is to tear down what you have and rebuild
[20:50] <lazyPower> seriously?
[20:50] <magicaltrout> yeah
[20:51] <lazyPower> welp, i'm happy we wont have that in the README
[20:51] <magicaltrout> but your masters should be pretty static, so its not a huge deal
[20:51] <magicaltrout> but
[20:51] <lazyPower> three cheers for magicaltrout
[20:51] <magicaltrout> if your nodes fail and stuff
[20:51] <magicaltrout> then eventually you'd run out of masters
[20:51] <lazyPower> are they not running any kind of consensus on the leaders?
[20:52] <lazyPower> k8s has the same limitations, but its trivial to add a replica of the apiserver/scheduler-manager
[20:52] <magicaltrout> its probably an *enterprise* feature ;)
[20:52] <lazyPower> in our current model the only downside is the PKI
[20:52] <magicaltrout> although i've not found it their either
[20:53] <magicaltrout> but its only a bunch of zookeeper backed stuff
[20:53] <magicaltrout> so i'm not sure why its so static
[20:53] <magicaltrout> surely thats part of the point of ZK?
[20:54] <lazyPower> That sounds right, but ive only interfaced with ZK in terms of big data deployments, and didn't fully understand what it brought to the table
[20:59] <magicaltrout> its just distributed configuration management, nothing special but makes sure all your nodes stay in sync
[20:59] <magicaltrout> which these days is pretty important
[21:00] <magicaltrout> also though with DC/OS they have something called Exhibitor
[21:00] <magicaltrout> which appears to come from netflix
[21:01] <magicaltrout> which seems to ensure ZK is running and stuff
[21:01] <magicaltrout> which seems a bit weird
[21:01] <cory_fu> jcastro: So, I've updated wiki-simple with the latest mysql and verified the tests all pass.  I see that cs:~jorge/bundle/wiki-simple (stable) has Write: charmers (because it was promulgated) but only you have read or write perms to the unpublished channel, so you'll have to push (or grant to me or charmers)
[21:01] <magicaltrout> its like the old who's monitoring the monitoring scenario
[21:01] <marcoceppi> jcastro: where is the upstream source for wiki-simple? did you make a gh repo for it?
[21:01] <cory_fu> marcoceppi: Yes
[21:02] <cory_fu> marcoceppi: https://github.com/juju-solutions/wiki-simple
[21:02] <marcoceppi> nice
[21:04] <magicaltrout> 20GB of Virtual Box VMs to debug dcos locally
[21:04] <magicaltrout> good job I bought a new laptop
[21:07] <magicaltrout> cory_fu / lazyPower help me out its been a few weeks. I need a list of all IP's for a service
[21:07] <magicaltrout> I also need to update all units in my service if a new unit is added
[21:07] <magicaltrout> in python/reactive
[21:07] <magicaltrout> can you point me at some code
[21:13] <magicaltrout> or anyone else....
[21:14] <cory_fu> magicaltrout: If I understand you correctly, you want something like https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L39 (ignore dismiss_joined, that's a bad pattern and should be removed) or possibly something like https://github.com/juju-solutions/interface-namenode-cluster/blob/master/peers.py#L49
[21:14] <cory_fu> resolve_private_address is defined here: https://github.com/juju-solutions/jujubigdata/blob/master/jujubigdata/utils.py#L427
[21:15] <cory_fu> hookenv.unit_private_ip() is poorly named because it usually won't actually return an IP, but sometimes will
[21:15] <magicaltrout> ah yeah the freaky conversations stuff i  remember now
[21:16] <cory_fu> magicaltrout: Usage would be something like https://github.com/juju-solutions/bigtop/blob/zookeeper/bigtop-packages/src/charm/zookeeper/layer-zookeeper/lib/charms/layer/zookeeper.py#L70
[21:16] <magicaltrout> okay and to keep it all in sync i don't need to wire it up, i just need to check for changes i guess
[21:16] <cory_fu> Though the RelationBase stuff would be better served by getting your instance from a @when decorator
[21:17] <cory_fu> magicaltrout: Checking for changes like https://github.com/juju-solutions/bigtop/blob/zookeeper/bigtop-packages/src/charm/zookeeper/layer-zookeeper/reactive/zookeeper.py#L50
[21:18] <magicaltrout> yeah thanks a lot cory_fu
[21:18] <magicaltrout> looks spot on
[21:18] <cory_fu> magicaltrout: Sorting of lists is important with data_changed, FYI
[21:18] <magicaltrout> hmm k
[21:18] <cory_fu> Glad I could help.  I'm about to head out, tho, so further questions will have to be directed at kwmonroe ;)
[21:18] <magicaltrout> i can sort ip addressed like usual ?
[21:19] <magicaltrout> addresses
[21:19] <cory_fu> Sure
[21:19] <cory_fu> If you're curious how data_changed works, it's pretty simple: https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/helpers.py#L168
[21:19] <magicaltrout> cool, kwmonroe is about as useful as a chocolate fireguard....
[21:19] <cory_fu> lol
[21:19] <kwmonroe> mmmm, chocolate
[21:19] <magicaltrout> hehe
[21:20] <magicaltrout> alright, i should be good, i've used that pattern somewhere else so i should be able to figure it out
[21:20] <magicaltrout> thanks cory_fu
[21:20] <magicaltrout> finally get this stuff pushed to the charm store
[21:21] <magicaltrout> before my country goes bankrupt and our internet turns into  something akin to north korea
[21:23] <lazyPower> #brexitproblems
[21:23] <magicaltrout> hehe
[21:24] <magicaltrout> i'm  moving to scotland
[21:24] <lazyPower> I think i'm going to aim for Nova Scotia, and wherever I land in between will be fine with me.
[21:25] <magicaltrout> or sealand.... lazyPower i  could take over sealand and you could be my only minion whilst i'm king of the fort
[21:25] <lazyPower> i mean, sure, but i'm a terrible minion
[21:25] <magicaltrout> hehe
[21:25] <lazyPower> i'm a minion with megalomania
[21:25] <magicaltrout> i do like Nova Scotia
[21:25] <magicaltrout> i'm reigniting the discussion of moving with the mrs whilst she's in a state of wild depression over whats happened ;)
[21:26] <magicaltrout> Canada is great plus their PM is cool  and  knows his shit
[21:26] <lazyPower> It certainly is putting uncertainty in my moving plans as well
[21:26] <magicaltrout> that said, I did like the  Obama / Fallon slow jam the other day
[21:26] <lazyPower> I was going to head over to the UK and AirBNB it for a month or two closer to fall...
[21:26] <magicaltrout> that would be so bad in the UK
[21:27] <magicaltrout> lazyPower: in all honest  unless the bottom falls out of the economy nothing will happen  for ages
[21:27] <magicaltrout> so i wouldn't worry about changing  plans, just worry about the exchange rate ;)
[21:28] <magicaltrout> although technically today I got a 10% pay rise on NASA stuff without doing  anything :)
[21:29] <lazyPower> nice ^5
[21:29] <magicaltrout> and there is another  devops day in Ghent I'm  sure jcastro would like you to attend in October ;)
[21:31] <lazyPower> magicaltrout - if you dug arctic life, i'm jammin out a playlist i made in the seattle airport lounge now. http://<IP_ADDRESS>:8000/listen.m3u
[21:34] <magicaltrout> hold on , i shall stab some buttons and have a listen
[21:34] <lazyPower> buttonstabbing++
[21:36] <magicaltrout> you're either giving me an incorrect  ip or you're behind a firewall
[21:36] <magicaltrout> i lie
[21:36] <magicaltrout> i can't type
[21:36] <lazyPower> nah my girl is connected on that link. should be g2g if you're plugging it into a shoutcast compliant player
[21:37] <lazyPower> i'll have to make it a point to setup the pirate radio again so its got an html5 player
[21:38] <magicaltrout> cool i'm  in
[21:40] <magicaltrout> such a pain in the balls that Sonos doesn't let  you add new radio stations on a phone/tablet else I'd have you streaming over my hifi ;)
[21:52] <lazyPower> I hear ya. I just tore down all my audio gear in the house. I was kind of weepy when all that started coming down, because it got really real at that point.
[21:53] <magicaltrout> awww
[21:53] <magicaltrout> kwmonroe: i might have been a big harsh earlier... i need a tip ;)
[21:58] <magicaltrout> cory pointed me to that peer releation side of the interface, and my understanding of relations is master <-> slave type stuff, but I'm after all the IP addresses of the units in the same service not related to each other via add-relations
[21:58] <magicaltrout> just units that coexist via add-unit
[22:00] <lazyPower> magicaltrout - so does the charm have a peer relationship? if so, you can scrape it from that. Thats the only way you'll get all service IP's of deployed charms units.  I do something very similar in the etcd 'cluster' interface.
[22:00] <magicaltrout> well thats what cory pointed me to, but as I don't relate anything I'm not sure how that would work
[22:00] <magicaltrout> for example, juju deploy dcos-master
[22:00] <lazyPower> peering is implicit when you add-unit. they automagically get that relationship added.
[22:00] <magicaltrout> juju add-unit dcos-master
[22:01] <magicaltrout> ah
[22:01] <magicaltrout> hmm
[22:01] <lazyPower> also running support between cuts :P
[22:01] <magicaltrout> hehe
[22:01]  * lazyPower flex's
[22:01] <magicaltrout> told you kwmonroe was as much use as a chocolate fireguard
[22:01] <lazyPower> between you and cory_fu he gets that all the time
[22:01] <magicaltrout> hehe
[22:03] <magicaltrout> first christmas related email of the year \o/
[22:04] <lazyPower> in june?
[22:04] <lazyPower> lolwut
[22:05] <magicaltrout> yup
[22:05] <magicaltrout> it has santa on and everything
[22:06] <kwmonroe> hello magicaltrout.  i trust i've left you waiting long enough.  watch the harshies next time.  anyway, the zk quorum relation that cory pointed you to should be what you need.. https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L39
[22:07] <magicaltrout> yeah i didn't realise there was an auto peer relationship in the background
[22:07] <magicaltrout> mystery solved
[22:07] <kwmonroe> and like lazyPower said, it's implicit, so you'd create a method on that relation that returned a list of all peer ip addrs
[22:07] <kwmonroe> ah
[22:07] <kwmonroe> well, i shall stop re-explaining :)
[22:08] <kwmonroe> also, it's important to note that "auto peering" may not always work.. the charm that you want to peer needs to specify a peer relation in its metadata.yaml.
[22:09] <kwmonroe> ... which corresponds to an interface with a peers.py, etc, etc, blah, blah.
[22:09] <magicaltrout> i love the way everyone at canonical always caveats anything i ever want to do with "may not always work" :P
[22:09] <kwmonroe> why can't you just be happy with mediawiki?  you're always throwing new wrenches and acronyms in our shiny.
[22:10] <magicaltrout> hehe
[22:10] <magicaltrout> well i'm on a mission to finish off a bunch of the ones i've started
[22:10] <magicaltrout> saiku will be done as soon as we ship 3.9, DCOS just needs master <-> master support, PDI just needs Hadoop pluggability
[22:11] <kwmonroe> and, to be clear, when i said it "may not always work", what i should have said is "it will never work unless your charms has a peer relation in the metadata.yaml; it will always work easy peasy if you do it right."
[22:11] <magicaltrout> time to clean up all the charms i've started
[22:11] <kwmonroe> nice!
[22:12] <kwmonroe> lmk if/when you're hooking pdi up to hadoop.  we can walk through the hadoop-plugin relation, which will probably just work right out of the box. ;)
[22:12] <magicaltrout> hehe.  Yeah I need to investigate the PDI side of it. Pentaho devs say "oh you just add the libs", personally i'm more pessimistic
[22:12] <magicaltrout> we shall see
[22:12] <kwmonroe> cool
[22:13] <lazyPower> after this list i'm going to drop into some new stuff i picked up from Pooldor (a belgium artist who'm i've become quite infatuated with recently)
[22:13] <magicaltrout> not.... artist infactuation!
[22:13] <lazyPower> *Poldoore
[22:13] <kwmonroe> lazyPower: i've hacked into your m3u.  thanks for the tunes this fine friday!
[22:14] <magicaltrout> hehe
[22:14] <lazyPower> kwmonroe aww yeee bruddah
[22:14] <lazyPower> glad you could make it
[22:15] <magicaltrout> i'd also like to port scispark in the not too distant future kwmonroe to try and entice the JPL guys a bit mor
[22:15] <magicaltrout> e
[22:16] <kwmonroe> sweet magicaltrout!  maybe they'll give you another raise ;)
[22:16] <kwmonroe> it's what 'merica does when we feel bad for other countries.
[22:16] <magicaltrout> hehe
[22:16] <magicaltrout> i'll speak to donald
[22:16] <magicaltrout> he's up in scotland making a tit of himself
[22:17] <kwmonroe> lol.  i expect nothing less.
[22:17] <magicaltrout> told the scottish that its a  great day for the uk when scotland backed staying in the EU massively
[22:17] <magicaltrout> good work Donald!
[22:27] <magicaltrout> liking this track lazyPower
[22:27] <magicaltrout> good work
[22:27] <lazyPower> All Poldoore my friend. no lazy intervention on this perfection
[22:28] <magicaltrout> hehe
[22:32] <lazyPower> by far an away my favorite jam he's done
[22:32] <lazyPower> this rocks my car on every road trip in 2016 so far :)
[22:33] <magicaltrout> yeah this is some cool stuff, i'll be looking it up next week
[22:33] <magicaltrout> thats part of the problem working at home
[22:33] <lazyPower> Thanks for letting me share :)
[22:33] <magicaltrout> i have music on all day
[22:33] <magicaltrout> finding new stuff is always hard
[22:33] <lazyPower> i really do dig getting to alienate people with my taste in music
[22:35] <magicaltrout> urgh monday sucks, trip into london and a 9pm SFO meeting
[22:35] <magicaltrout> *bork*
[22:36] <magicaltrout> oh well tunes for the train at least!
[22:37] <lazyPower> http://poldoore.bandcamp.com/
[22:37] <lazyPower> ;)
[22:37] <lazyPower> i should get an affiliate link, get me on the insider track to getting pre-release jams
[22:52] <magicaltrout> right i'm offski, got some cricket to umpire in the morning... I know you americans don't understand that concept....
[22:52] <magicaltrout> thanks for the tunes lazyPower!
[22:53] <lazyPower> Thanks for tuning in magicaltrout o/ have a good weekend


[02:58] <astraljava>
[13:52] <thebishop> i know this is off topic, but does ubuntu use any software for managing test plans and hosting unit tests w/ scripts?
[14:32] <fader> thebishop: checkbox and jenkins for managing/executing tests, test cases are stored in the wiki I believe
[14:32] <fader> You might get better answers than I can provide on the Ubuntu QA mailing list :)
[14:34] <thebishop> fader, that's already helpful
[14:36] <thebishop> maybe i just need to use wiki for my project.  what i have in mind is a wiki-like interface for documenting the whole test plan outline, with each section having links to the detailed test steps/objectives/results/etc, and a built-in repository for automation/scripts
[14:37] <thebishop> wiki basically does what i want, but i was hoping a test-specific package maybe with a dashboard view graphing test results and stuff
[14:37] <fader> Yeah, a wiki would probably work well for that, at least until you need to scale way up
[14:38] <fader> thebishop: There's a jenkins dashboard here if you want to see how it looks: https://jenkins.qa.ubuntu.com/
[14:39] <fader> Though I can't tell you much more than the URL.  No idea how to set one up :)
[14:39] <thebishop> fader, yeah, this is a cool ui, but jenkins seems more geared as a continuous integration build server with some automated tests
[14:39] <fader> Indeed
[14:40] <thebishop> we already have a build server, and what i'm looking for is really just managing test cases
[14:40] <fader> Yeah, no idea there, sorry :/
[14:40] <thebishop> don't even need issue tracking, since we already have Trac
[14:40] <thebishop> fader, that's cool, i wasn't aware of jenkins or checkbox before
[14:54] <thebishop> fader, have you seen the Sikuli project?
[14:55] <thebishop> it's a pretty impressive gui-automation IDE that works through OCR on screenshots
[14:55] <thebishop> cross-platform :)
[14:56] <fader> thebishop: I have, actually :)  When I was on the Ubuntu QA team we took a look at it and discussed using it, but decided not to
[14:57] <thebishop> fader, yeah? what were the cons?
[14:57] <fader> Mostly because we already had a project (written by ara) doing something similar but more Linux-centric called "mago"
[14:57] <thebishop> yeah i just read about mago
[14:57] <fader> IIRC the cons for us were that it required installation of the JRE, so it wasn't very useful for testing the default desktop or for install/ISO testing
[14:58] <fader> Whereas mago and preseeding could do that testing with a much lower footprint and do it faster
[14:58] <fader> Don't get me wrong, we though it was a really cool tool and one we wanted to keep an eye on.  It just wasn't the right fit for our specific testing needs at that time
[14:59] <fader> I think I still have a VM somewhere with my sikuli playground on it :)
[14:59] <thebishop> i see
[14:59] <thebishop> i can understand how it wouldn't be ideal for those cases
[14:59] <thebishop> but man, it's ridiculously better than any gui-automation i've used in the past, including some pretty expensive solutions
[15:01] <fader> Yeah, it's a really slick tool
[18:02] <Janusman> question: I successfully found out how to get an All-in-one PC working (Lenovo C205) with Natty. Where should I share this?
[23:49] <goshawk> hi
[23:49] <goshawk> i'm testing oneiric beta 1 server and i found that if the server has a power-cut, when it's powered on it stucks on grub menu by default
[23:50] <goshawk> i think it's a thing people do not want
[23:50] <goshawk> on a server
[23:58] <goshawk> anyone ?
[23:58] <goshawk> should i file a bu ?
[23:58] <goshawk> bug ?