[00:01] <bluesabre> anybody around?
[00:01] <bluesabre> brainwash: poke
[00:02] <ochosi> bluesabre: sorry, already heading to bed
[00:02] <bluesabre> ooh!
[00:03] <bluesabre> quick, link to lid-close bug
[00:03] <ochosi> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1303736
[00:03] <bluesabre> yay, thanks!
[00:03] <ochosi> (just bookmark this page: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-14-04-point-1 )
[00:04] <bluesabre> finished with adjusting the patch, will upload the package in a few
[00:04] <ochosi> sweet
[00:04] <ochosi> did you test it?
[00:04] <bluesabre> not yet
[00:04] <ochosi> okeydokey
[00:04] <bluesabre> again, issue doesn't affect me
[00:04] <ochosi> this is extremely weird
[00:04] <ochosi> i wonder how it can and cannot affect anyone with a laptop
[00:04] <ochosi> it should be consistent
[00:04] <bluesabre> race condition most likely
[00:05] <ochosi> the only thing i *can* imagine is that your computer is "too fast"
[00:05] <ochosi> and older ones fail
[00:05] <bluesabre> brand new gaming laptop :)
[00:05] <ochosi> yeah
[00:06] <ochosi> i guess if this works for "most" ppl, we should SRU it
[00:06] <ochosi> (as i said, some of the testers were obviously mistaken)
[00:06] <ochosi> anyway, let's continue at the meeting
[00:06] <ochosi> gotta hit the hay
[00:07] <bluesabre> seeya ochosi
[00:07] <ochosi> seeya!
[00:07] <ochosi> and thanks for the patch!
[01:23] <bluesabre> ochosi: patched xfpm and light-locker-settings pushed to xubuntu-dev ppa
[04:41] <Unit193> bluesabre: There's some updates to be done to the xubuntu-artwork package, want to fix them?
[05:20] <Unit193> ochosi: Oh, so are we having another version of xubuntu-community-artwork?
[06:17] <ochosi> Unit193: depends, i personally don't want to invest the time for another call and the follow-up work, i have enough on my plate this cycle i guess...
[06:17] <ochosi> so if somebody else from the team wants to take that on, we can do another version, otherwise we can just ship the same wallpapers again
[06:18] <ochosi> (knome: i just said "wallpapers" ^ , in case you don't have that on your highlight-list ;))
[06:21] <Unit193> Fine by me, so we don't have them.
[06:21] <elfy> I week in the job - excuses already :p
[06:22] <ochosi> heh
[06:22] <ochosi> that's an excuse from my other job though (artwork-lead)
[06:22] <ochosi> (the one i've been doing for a few years)
[06:23] <Unit193> "I would, but :effort:"
[06:23] <ochosi> running the new call wouldn't be hard, but there's a bit maintenance and follow-up work
[06:23] <ochosi> hehe
[06:24] <ochosi> elfy: bluesabre uploaded an improved version to the xubuntu-dev PPA (xfpm+ll), could you give that a spin?
[06:24] <ochosi> i gotta run off until the meeting
[06:25] <elfy> ochosi: yep
[06:25] <ochosi> thanks!
[06:26] <ochosi> i hope it works so we can get this over with :)
[06:29] <ochosi> bbl
[07:00] <elfy> ochosi bluesabre - upgraded to new xfpm/lls - still works for me
[08:29] <brainwash> ochosi: do we already know that light-locker-settings is not in sync with the .desktop files before hitting the apply button for the first time?
[08:30] <brainwash> I remember reading about this here
[08:30] <brainwash> would be bug 1306917
[09:03] <knome> ochosi, lets see if we really want that.
[09:03] <bluesabre> o.-
[09:03] <knome> hey bluesabre
[09:03] <knome> you still or already awake?
[09:03] <bluesabre> woke up just to be here, ochosi should feel loved
[09:04] <bluesabre> !team | Wake up!
[09:05] <Unit193> It's 5am, no.
[09:05] <knome> hmm
[09:05] <knome> yeah, still an hour to go ;)
[09:05] <slickymasterWork> lol
[09:05] <bluesabre> oh
[09:05] <bluesabre> damn clock
[09:05] <knome> bluesabre, GO BACK TO BED ;)
[09:05] <slickymasterWork> !team | ~morning
[09:05] <bluesabre> DST is not my friend
[09:05] <slickymasterWork> bluesabre, don't poke Unit193 ;)
[09:06] <bluesabre> "Let sleeping dogs lie"?
[09:17] <brainwash> bluesabre: did you want to ask me sth?
[09:17] <bluesabre> I did, but ochosi popped up and answered
[09:18] <brainwash> ok
[09:19] <brainwash> elfy: did you also test with xscreensaver?
[09:20] <elfy> brainwash: no - why would I?
[09:21] <ochosi> brainwash: yes, that is something we also want to fix at some point
[09:21] <brainwash> elfy: isn't it obvious? :)
[09:22] <elfy> not at all - we don't seed xscreensaver
[09:22] <ochosi> elfy: for upgraders, i'd prefer if we don't break xscreensaver
[09:22] <ochosi> but yeah, primary goal is fixing the situation for clean installs with light-locker
[09:22] <brainwash> and many have returned to xscreensaver
[09:22] <elfy> then someone should say something
[09:22] <elfy> somewhere were people can find it easily ;)
[09:22] <brainwash> ok, please do it then/now :)
[09:23] <ochosi> brainwash: "many" of a vocal minority though. we don't know anything about the majority of xubuntu users...
[09:23] <ochosi> elfy: yeah, as it's a secondary goal, i wanted this to be tested first with light-locker
[09:23] <ochosi> in fact it should work fine with xscreensaver
[09:23] <brainwash> it's the no.1 workaround mentioned by users
[09:23] <ochosi> because those users can switch back to the old behavior
[09:24] <ochosi> by flipping an xfconf switch in xfpm
[09:24] <elfy> brainwash: it's the no 1 workround mentioned by the noisy ones
[09:25] <brainwash> and the silent ones will use it
[09:25] <elfy> the noisy ones want all sorts of things that they aren't going to get
[09:25] <bluesabre> well, if they remove the light-locker package, light-locker-settings should be removed as well
[09:26] <ochosi> bluesabre: yeah, but the setting is a hidden one and if lls modified it, they have to change it back by hand
[09:26] <bluesabre> I see
[09:26] <ochosi> the best thing would be if xscreensaver worked with that logind-suspend too
[09:26] <ochosi> if it does, then we have no problem
[09:26] <bluesabre> gotcha
[09:27] <ochosi> but since up to now we had xfpm handle that, i don't know whether it does work this way
[09:27] <ochosi> frankly, this is all a bit messy and very very confusing
[09:27] <ochosi> even for me...
[09:27] <ochosi> every time i have to really focus in order not to forget how things should work exactly
[09:27] <ochosi> i guess i should write a process diagram or something
[09:27] <bluesabre> I'm just trying to keep up
[09:28] <elfy> bluesabre: join the club ...
[09:28] <ochosi> yeah, i'll start something, give me a minute (or two)
[09:32] <ochosi> http://dpaste.com/3QJ3PF1/
[09:32] <ochosi> does this help^ ?
[09:33] <ochosi> (another note: i don't know yet how things work with xscreensaver, but the save bet is to always go for option 2) as that is the "old behavior")
[09:35] <ochosi> bluesabre: ^
[09:35] <bluesabre> so, "lock on suspend" TRUE, "inhibit logind" FALSE
[09:36] <bluesabre> "lock on suspend" FALSE, "inhibit logind" TRUE?
[09:37] <ochosi> yeah
[09:38] <ochosi> there's a side-effect though, all the other events (power-button, suspend-button) will also be handled by logind in case 1)
[09:38] <bluesabre> gtk-inspector is built in with gnome 3.14, and can be activated with a key combo... we might want to block that combo in the greeter when the time comes http://blogs.gnome.org/mclasen/2014/05/15/introducing-gtkinspector/
[09:38] <bluesabre> ok, I'll update the patch now.
[09:39] <brainwash> ochosi: please no side effects :P
[09:39] <ochosi> brainwash: you can always come up with a better patch ;)
[09:39] <bluesabre> that side effect already exists though, right?
[09:40] <brainwash> no
[09:40] <ochosi> in the old, more hacky patch it doesn't
[09:40] <bluesabre> I see
[09:40] <ochosi> there only the lid-event is inhibited
[09:40] <ochosi> or not inhibited
[09:40] <ochosi> (to be more exact)
[09:40] <ochosi> so shipping the hacky patch would be fine if it works with xscreensaver too
[09:41] <brainwash> but how can you sru the patch if it breaks something which has been fixed previously?
[09:41] <bluesabre> because power buttons are minor in comparison to losing work
[09:41] <brainwash> lid-close event
[09:42] <ochosi> i'll test now with xscreensaver...
[09:42] <brainwash> xfpm won't inhibit it anymore and run the action specified via the settings dialog
[09:42] <brainwash> or?
[09:42] <brainwash> this is really confusing
[09:43] <bluesabre> I'll quickly push the tweaked lls
[09:44] <brainwash> so the user selects "do nothing on lid close", but the system will suspend due to logind being in command again
[09:44] <ochosi> brainwash: yeah, so stop spreading confusion! :)
[09:44] <brainwash> xD
[09:44] <elfy> ochosi: anything I need to do with xscreensavr - other than install it and purge ll/lls ?
[09:44] <brainwash> just doing my job.. brainwashing people
[09:44] <ochosi> hehe
[09:44] <ochosi> yeah,i never thought of it that way ;)
[09:45] <ochosi> elfy: install it and disable ll, that should suffice
[09:45] <ochosi> brb (hopefully)
[09:46] <elfy> mmm
[09:46] <elfy> that just comes back to the desktop with no password
[09:46] <ochosi> yeah, seems like it
[09:47] <elfy> that wfm - when people complain - we can tell them to install ll/lls as that's what we're using now :p
[09:48] <brainwash> what about the normal Xfce session?
[09:48] <elfy> no idea brainwash - I use THAT as often as I suspend in real life ;)
[09:50] <ochosi> ok, i'm trying with the less hacky patch now
[09:50] <ochosi> bluesabre: i'll test now and control the settings by hand, just to be sure ;)
[09:51] <brainwash> I mean we don't want fix and break something at the same time
[09:51] <bluesabre> yeah, that usually comes with issues
[09:51] <bluesabre> why is the normal Xfce session usually so messed up?
[09:51] <brainwash> it is?
[09:51] <brainwash> the xfce4 package does not depend on ll, but still uses xfpm
[09:51] <bluesabre> usually it messes with my panel layout, font rendering, and other things
[09:51] <bluesabre> ochosi: good, the package probably won't be live for a while
[09:54] <ochosi> bluesabre: hmmm
[09:55] <ochosi> either there's a problem in the package with the patch, or there's something wrong with the patch
[09:55] <ochosi> g_object_set_property: object class 'XfpmXfconf' has no property named 'inhibit-logind'
[09:56] <ochosi> disclaimer: so the xfpm package 1.2.0-3ubuntu5~trusty~ppa2 doesn't work
[09:56] <bluesabre> there might be something missing
[09:57] <bluesabre> the branch was ahead of the 1.2.0 release
[09:57] <ochosi> but it confirms my suspicion
[09:57] <bluesabre> so the diff only applied to where it was at the time
[09:57] <ochosi> that xscreensaver isn't listening to logind, but needs to be called specifically by xfpm/xfsession on suspend
[09:58] <bluesabre> so there might be something that is needed that was committed between 1.2.0 and that branch
[09:59] <bluesabre> I'll do some testing and figure out if something is missing
[09:59] <ochosi> right
[09:59] <ochosi> http://dpaste.com/3XQKDF1/
[10:00] <knome> meeting time :)
[10:00] <ochosi> so this is how things are according to my findings and testing so far
[10:00] <ochosi> yup
[10:00] <ochosi> !team | meeting-time!
[10:01] <slickymasterWork> o/
[10:01] <ochosi> #startmeeting
[10:01] <meetingology> Meeting started Fri May 16 10:01:10 2014 UTC.  The chair is ochosi. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[10:01] <meetingology> Available commands: action commands idea info link nick
[10:01] <ochosi> hi everyone, just to know for sure, who's around?
[10:01] <knome> o/
[10:01] <slickymasterWork> o/
[10:01] <bluesabre> \o
[10:01] <elfy> o/
[10:02] <ochosi> ok, just a small disclaimer, i'm still learning all this bot-business ;)
[10:03] <ochosi> let's start with what's left from last time and update those items
[10:04] <ochosi> knome: you had quite a few action-items from last time, want me to name them all or just wanna update them now?
[10:04] <knome> all are done
[10:05] <ochosi> i also ran the call for technical lead, so i guess the only open issue left is systemd ETA
[10:07] <ochosi> #topic Open action items
[10:09] <elfy> I hate driving the bot too ochosi ;)
[10:09] <ochosi> #action Team: When is systemd landing?
[10:09] <meetingology> ACTION: Team: When is systemd landing?
[10:09] <ochosi> any news on that?
[10:09] <Unit193> ochosi: Define "landing"
[10:09] <ochosi> elfy: sorry, i should've prepared better
[10:09] <ochosi> Unit193: well, i guess there are two interesting aspects
[10:10] <elfy> ochosi: now worries - just letting you know I'd not be doing any differently :)
[10:10] <elfy> s/no
[10:10] <ochosi> 1) when will utopic have a functioning systemd stack that we can test/use
[10:10] <ochosi> 2) will utopic already fully switch to systemd
[10:10] <elfy> 1 - now
[10:10] <ochosi> elfy: please #info ;)
[10:10] <Unit193> ochosi: 1. It's in repo and usable.  2. It's not without quirks.  3. Not all service files are there, a couple ubuntu things only have upstart jobs.  4. Might not be default this cycle.
[10:11] <ochosi> meh, #info folks :)
[10:11] <elfy> :p
[10:11] <elfy> #info systemd is in repo and usable - with quirks
[10:12] <elfy> #info not all service files are there
[10:12] <Unit193> I can name modemmanager and whoopsie.
[10:12] <elfy> #info no concrete idea of when it will be default
[10:12] <brainwash> but how does this affect xubuntu-desktop?
[10:13] <ochosi> i'm not entirely sure
[10:13] <ochosi> from what i remember, upstart user-sessions can still be run
[10:13] <ochosi> not sure what happens to e.g. the indicators
[10:13] <ochosi> brainwash: wanna investigate that?
[10:13] <Unit193> user sessions are still upstart.
[10:13] <brainwash> isn't it too early?
[10:13] <ochosi> (or: does someone else know)
[10:14] <ochosi> brainwash: why would it be too early?
[10:14] <ochosi> the full stack is there and usable
[10:14] <brainwash> I mean the upstart user session
[10:14] <brainwash> if it will stay or go
[10:15] <elfy> quote from pitti's blog "To clarify, there is nofixed date/plan/deadline when this will be done, in particular it might well last more than one release cycle. So we’ll “release” (i. e. switch to it as a default) when it’s read"
[10:15] <ochosi> ok
[10:15] <ochosi> that can obviously happen any cycle then
[10:15] <ochosi> guess we need to follow the status of systemd in unity
[10:15] <Unit193> There's two blueprints to follow on that.
[10:15] <elfy> seems so
[10:16] <ochosi> we could link those to one of our blueprints
[10:16] <ochosi> just to keep them on the radar
[10:16] <elfy> that makes sense
[10:16] <ochosi> elfy: blueprint-master, wanna #action that? :)
[10:17] <elfy> if you like :)
[10:17] <Unit193> There's info on trello.
[10:17] <elfy> Unit193: yep - thanks :)
[10:17] <ochosi> #action elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar
[10:17] <meetingology> ACTION: elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar
[10:17] <elfy> ochosi: which xubuntu blueprint :)
[10:18] <elfy> we're missing a dev one ?
[10:18] <ochosi> elfy: wait, i thought *you* are the master of blueprints? ;)
[10:18] <elfy> oh no ;)
[10:18] <elfy> I just built them for you :p
[10:18] <ochosi> hehe
[10:19] <ochosi> i think we oughta link it to the features blueprint
[10:19] <ochosi> there wasn't a separate development blueprint in the 14.04 cycle, iirc
[10:19] <elfy> ok :)
[10:19] <elfy> yea - just looked at 14.04
[10:19] <ochosi> righty, so let's wrap this part up
[10:19] <ochosi> or are there any more things wrt systemd?
[10:20] <ochosi> #Team updates
[10:20] <ochosi> are there any team updates?
[10:20] <elfy> not from me
[10:20] <ochosi> neither from me :)
[10:20] <slickymasterWork> neither from me
[10:20] <ochosi> s/neither/nor/
[10:21] <bluesabre> #info: menulibre 2.0.4 in unstable and utopic, will sru back into trusty next week
[10:21] <ochosi> cool
[10:21] <bluesabre> fixes a bunch of knome's bugs
[10:21] <knome> #info knome has a CSS update pending on IS/pleia2
[10:21] <bluesabre> and the menu corruption
[10:22] <ochosi> bluesabre: do you know whether our 1.8.5 greeter is synced to utopic already? (was in debian 9 days ago)
[10:22] <knome> that is, my part is done
[10:23] <ochosi> hm, doesn't seem like it is in utopic already
[10:23] <bluesabre> doesn't seem like it
[10:23] <bluesabre> I'll see whats holding it up
[10:23] <bluesabre> probably stuck in m-o-m
[10:24] <ochosi> #action bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty
[10:24] <meetingology> ACTION: bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty
[10:24] <ochosi> any other team updates?
[10:24] <elfy> ochosi: you can mark my action item as done :p
[10:25] <ochosi> elfy: i guess you can do that yourself :) thanks!
[10:25] <ochosi> if only all action items would be done so quickly ;)
[10:25] <ochosi> (i guess we just need to assign them all to elfy)
[10:25] <ochosi> ok, carrying on
[10:25] <bluesabre> # action bluesabre to SRU menulibre-2.0.4 back to trusty
[10:25] <bluesabre> #action bluesabre to SRU menulibre-2.0.4 back to trusty
[10:25] <meetingology> ACTION: bluesabre to SRU menulibre-2.0.4 back to trusty
[10:26] <ochosi> ah, more items bluesabre?
[10:26] <bluesabre> just attaching to my #info from before
[10:26] <elfy> #info features blueprint has links to systemd blueprints
[10:26] <bluesabre> I'm done
[10:26] <ochosi> ok, ty
[10:26] <ochosi> #topic Announcements
[10:27] <ochosi> #info ochosi ran a call for Xubuntu technical lead on the mailinglist, there'll be a vote on the nominees in approximately two weeks at a meeting
[10:27] <ochosi> any other announcements or shall we start the discussions?
[10:28] <knome> #info knome handed ochosi over they keys to LP teams
[10:29] <ochosi> ok, anything else?
[10:29] <knome> no that i can think of
[10:29] <elfy> not from here
[10:29] <bluesabre> nope
[10:29] <ochosi> #topic Discussion
[10:30] <ochosi> #subtopic Create a testing PPA common to -team
[10:30] <knome> ftr, i should probably be under -dev
[10:30] <knome> *it
[10:30] <ochosi> we've already started using the xubuntu-dev PPA for testing
[10:30] <slickymasterWork> +1 on that knome
[10:31] <ochosi> but i was wondering whether it would be helpful or too much if we had one PPA per release
[10:31] <knome> especially now that -team has the other privileges right (no access to LP team admin)
[10:31] <ochosi> e.g. trusty-staging (for stuff we want to SRU)
[10:31] <ochosi> or utopic-staging (for stuff that we want to get uploaded)
[10:31] <knome> one per purpose sounds good to me
[10:31] <ochosi> elfy: ^ ?
[10:31] <elfy> logically that sounds right
[10:31] <slickymasterWork> it does makes sense
[10:32] <knome> unless it's a lot of work
[10:32] <elfy> that ^^
[10:32] <knome> (it isn't)
[10:32] <ochosi> bluesabre: what do you think?
[10:32] <elfy> I'm happy to go with the flow on this
[10:32] <bluesabre> we'll just need micahg to create the PPAs, then members of xubuntu-dev can push packages to it
[10:32] <ochosi> knome: so one per purpose = xubuntu-staging (holding the bugfixes for all releases)
[10:32] <knome> ochosi, probably better to do it per release/purpose
[10:33] <knome> ochosi, as you already kind of proposed...
[10:33] <ochosi> yup, just wanted to make sure
[10:33] <elfy> just one thought here
[10:33] <bluesabre> team members can also contribute packages and simon and I can sponsor them
[10:33] <knome> bluesabre, i'd argue ~xubuntu-project-lead should own ~xubuntu-dev
[10:33] <ochosi> we can also do an additional PPA with new applications we're considering to include
[10:33] <elfy> if we've got a trusty one I assume that stuff that's been dealt with will be removed once it's released properly?
[10:33] <ochosi> (only if they aren't in the repos, obviously)
[10:34] <ochosi> elfy: yeah
[10:34] <ochosi> same goes for any other release
[10:34] <bluesabre> knome: that would be a good, sustainable idea
[10:34] <knome> elfy, or just get obsolete (newer version number in archive)
[10:34] <ochosi> if stuff to utopic has been uploaded, it'll be removed
[10:34] <elfy> ok
[10:34] <ochosi> is "-staging" a clear enough suffix?
[10:34] <ochosi> any other ideas?
[10:35] <knome> for SRU's, it can be trusty-sru(-staging)
[10:35] <ochosi> well, the question is will we really have so many packages that it justifies having a separate SRU PPA
[10:35] <knome> as long as the name is communicated to the QA team, it's ok :P
[10:35] <knome> wlel,
[10:35] <knome> *well
[10:36] <bluesabre> trusty-proposed, utopic-proposed?
[10:36] <knome> i think it would be a good idea to have that, because then person X could install trusty and the -sru PPA
[10:36] <bluesabre> (following in step with upstream)
[10:36] <knome> and see if there are still high-impact bugs that need fixing
[10:36] <knome> mixing -proposed there might be just confusing
[10:36] <elfy> bluesabre: I'd rather not give people any chance of accidentally enabling standard proposed
[10:36] <knome> "i have the -proposed archive enabled"
[10:36] <knome> "which?"
[10:36] <bluesabre> ah
[10:37] <bluesabre> fair points
[10:37] <ochosi> mhm, i agree, proposed is probably confusing
[10:37] <ochosi> we can also call it -bugfix
[10:37] <elfy> staging works for me
[10:37] <knome> that's ambiguous ;)
[10:37] <knome> either -staging or -sru or -sru-staging
[10:37] <knome> but see my point for a separate SRU PPA
[10:37] <elfy> knome: +1 to that and the thinking
[10:38] <ochosi> sure, i agree it *might* be useful, but that's mostly interesting for trusty
[10:38] <ochosi> as it is LTS, we might want to SRU more to it
[10:38] <knome> sure, we could have -sru PPAs for LTS releases only or so
[10:39] <ochosi> ok, so let's create a trusty-staging, utopic-staging and trusty-SRU ppa?
[10:39] <elfy> yep
[10:39] <bluesabre> question
[10:39] <ochosi> packages that have been tested from trusty-staging can be moved to trusty-SRU
[10:39] <ochosi> bluesabre: shoot
[10:39] <bluesabre> ok
[10:39] <knome> ...i'd probably make that trusty-sru-staging
[10:39] <bluesabre> that answered it
[10:39] <ochosi> ok :)
[10:39] <knome> though not every update is SRU
[10:39] <bluesabre> maybe trusty-updates?
[10:40] <knome> updates is a used name as well
[10:40] <ochosi> humm, again with the confusion :)
[10:40] <knome> so yeah, using -staging everywhere is a good idea
[10:40] <ochosi> ok, let's wrap this up, we have a few more things to discuss
[10:41] <ochosi> knome: can i create those PPAs with my current LP rights or does micahg have to set them up?
[10:41] <knome> i don't know
[10:41] <knome> i never was involved with the -dev team
[10:41] <bluesabre> only admins can create PPAs
[10:41] <knome> but again, i'd argue ~xubuntu-project-lead should own ~xubuntu-dev
[10:41] <ochosi> #action ochosi to investigate and set up trusty-staging and utopic-staging PPAs
[10:41] <meetingology> ACTION: ochosi to investigate and set up trusty-staging and utopic-staging PPAs
[10:41] <knome> tech lead can be an admin
[10:42] <knome> xpl necessarily doesn't need to be
[10:42] <ochosi> let's discuss the -sru PPA again when it becomes necessary?
[10:42] <ochosi> or shall we just create it as well for trusty only
[10:42] <knome> yep
[10:42] <knome> let's discuss it when we need it and when micah is around
[10:42] <ochosi> ok
[10:43] <knome> since he's the owner/admin
[10:43] <ochosi> #info A PPA specifically SRUs shall be discussed with micahg
[10:43] <ochosi> elfy: i guess next up we could either talk trello or ML proposal by knome, any preference from your side?
[10:44] <knome> not from me
[10:44] <elfy> well - not much to say about trello tbh - it's all been said previously :)
[10:45] <ochosi> elfy: ok, so the idea is to use trello *additionally* to blueprints?
[10:45] <elfy> for detail when it's necessary for other's to know that detail
[10:45] <knome> ochosi, want to #topic?
[10:46] <ochosi> #subtopic Use Trello
[10:46] <knome> to me it looks like trello boards can be useful for subteams
[10:46] <knome> eg. the qa team/people can cooperate via those
[10:46] <ochosi> elfy: so we would link the trello pages in blueprints?
[10:46] <ochosi> or how would that work
[10:47] <elfy> ochosi: I guess that would work
[10:47] <elfy> but if some do and some don't then it's pretty much a dead end
[10:47] <ochosi> yeah
[10:47] <ochosi> as you can see from this scenario, it might lead to a slightly increased administrational overhead if we use 2 systems :)
[10:47] <elfy> and if sub-teams do - there's not really any cohesiveness
[10:48] <ochosi> but if the gain justifies it, it's ok
[10:48] <elfy> I'd say
[10:48] <elfy> if we do it then - we'd be better to have a 'team' board - at least then people can see the whole picture
[10:49] <elfy> subteams if they want to have a board of their own could link it in the team one
[10:49] <knome> how would that differ from the status site?
[10:49] <elfy> what staus site?
[10:49] <ochosi> won't we get a huge gigantic picture if we do one for team?
[10:49] <knome> status.ubuntu.com
[10:49] <elfy> knome: that shows as much detail as the blueprint
[10:50] <ochosi> elfy: yeah, i see your point on being able to add comments/detail
[10:50] <knome> so you want a whole picture with all the details?
[10:50] <ochosi> but the problem is, having that in one huge trello page will probably also be overwhelming
[10:50] <ochosi> what do other members of the team think on this? slickymasterWork? bluesabre?
[10:50] <elfy> you know what - I haven't got the energy for this - just take it off the agenda
[10:50] <knome> i know some teams have used the bluepring whiteboards previously
[10:51] <elfy> I really don't care anymore
[10:51] <knome> it's not exactly trello though...
[10:51] <knome> because no edit locks and stuff
[10:51] <slickymasterWork> I really felt that trello was a good asset to -qa during the T cycle
[10:51] <bluesabre> trello is handy, as long as the links are discoverable
[10:52] <ochosi> suggestion: what if we set up a trello board for all the current blueprints items so we see how it would look in action?
[10:52] <slickymasterWork> at least I rely more on trello than on the -qa blueprint
[10:52] <knome> ochosi, that's a good idea
[10:52] <ochosi> i'm ok with trying this for one cycle and then evaluating it
[10:53] <ochosi> so seeing whether administration has increased significantly and how ppl feel about using it
[10:53] <ochosi> one thing is important though: i still want blueprints to be updated, because those *do* help, with bugreports linked etc they have features that trello doesn't have
[10:53] <ochosi> elfy: would you be ok with this ^?
[10:54] <elfy> ochosi: the QA blueprint was kept up to date in the last cycle ;)
[10:54] <slickymasterWork> yes
[10:54] <ochosi> sure, just saying that using trello would still mean we have to keep the other (slow, clunky) website up to date too ;)
[10:55] <ochosi> you can't just eat the fresh sandwich and let the old one rot
[10:55] <elfy> it didn't really add much to my workload tbh - and the QA blueprint had probably more on it than any of the others
[10:55] <ochosi> ok, great
[10:55] <knome> ochosi, wait, are you upbringing us now? ;)
[10:56] <elfy> ochosi: well - I can set it up if you want - just want people to get an account if they've not got one
[10:56]  * knome eats the fresh sandwich
[10:56] <ochosi> elfy: that'd be great. then send an email to the mailinglist about it?
[10:56] <ochosi> i'd personally like to vote on it, if you're ok with this
[10:57] <ochosi> ideally we could give ppl a chance to vote via the mailinglist too, this time
[10:57] <elfy> ochosi: that's fine with me of course
[10:57] <elfy> BUT
[10:57] <elfy> can we deal with the m/l and make it moderated first :p
[10:57] <ochosi> hehe
[10:57] <ochosi> well that's the next topic
[10:57] <elfy> :p
[10:58] <ochosi> #action elfy to set up a trello "master" board for -team and send an email about it to the mailinglist
[10:58] <meetingology> ACTION: elfy to set up a trello "master" board for -team and send an email about it to the mailinglist
[10:58] <elfy> after we decide to use it or not :)
[10:58] <ochosi> #info the team will vote on the trello board after it has been set up
[10:58] <elfy> oh right
[10:58] <ochosi> #subtopic Mailinglist/s
[10:58] <elfy> I thought you wanted to do that the other way round?
[10:59] <ochosi> err, how?
[10:59] <ochosi> first set it up, then let ppl test it
[10:59] <ochosi> then vote, no?=
[10:59] <elfy> mmm
[10:59] <ochosi> we can still let ppl vote on the mailinglist anyway, btw
[10:59] <elfy> would it not be better for us to vote first - and then do the work?
[10:59] <ochosi> it was done already for the XPL election
[10:59] <elfy> I'm easy either way though :)
[11:00] <ochosi> yeah, but not all of -team might've used trello before
[11:00] <knome> i'd argue it's hard to take an informed vote unless you've seen how it'd turn out
[11:00] <elfy> ok - makes sense
[11:00] <ochosi> i think it could be good for an informed decision to see it in action
[11:00] <knome> ...
[11:00] <knome> is it echoing in here?
[11:00] <ochosi> but i understand it's work...
[11:00] <knome> we don't have too many work items on blueprints yet
[11:00] <ochosi> ok, let's get on the mailinglists
[11:00] <elfy> ochosi: yea - ok - I'll get it set up soon and then go from there
[11:00] <knome> https://lists.ubuntu.com/archives/xubuntu-devel/2014-May/010193.html
[11:00] <ochosi> (as we're already going overtime)
[11:01] <ochosi> thanks elfy
[11:01] <knome> overtime? who specified the meeting lasted for an hour? :P
[11:01] <elfy> bert
[11:01] <ochosi> #info knome sent a proposal for mailinglists to the mailinglist
[11:01] <knome> ;)
[11:01] <ochosi> (i like the repetition there ;))
[11:01] <knome> ^ link above
[11:01] <ochosi> knome: well, link it?
[11:01] <knome> i did already
[11:01] <ochosi> the bot picks it up that way?
[11:02] <knome> yep
[11:02] <ochosi> oh, great, wasn't sure
[11:02] <ochosi> so, any thoughts on this proposal?
[11:02] <ochosi> bluesabre, slickymasterWork, elfy ?
[11:02] <ochosi> others?
[11:02] <knome> i think it's the awesomest proposal ever
[11:02] <elfy> I'm happy with it
[11:02] <elfy> I'd not go as far as knome though :p
[11:02] <slickymasterWork> I strongly give a +1 on knome's proposal
[11:02] <bluesabre> I agree with it
[11:03] <ochosi> yup, i'm also +1 on it
[11:03] <elfy> and I've got a +0.99
[11:03] <knome> on a more serious note, if it doesn't work, it's not a huge thing to revert
[11:03] <ochosi> should we have a formal vote?
[11:03] <elfy> ochosi: I think so
[11:03] <knome> we have no quorum
[11:03] <knome> so it'd have to continue on the mailing list
[11:03] <slickymasterWork> yeah, so it's logged~
[11:03] <elfy> and then take it to the list for team to vote
[11:03]  * elfy types slower ...
[11:03] <ochosi> ok, let's start here and let the others vote on the ML
[11:04] <ochosi> #vote Should we implement knome's proposal in our development mailinglist?
[11:04] <meetingology> Please vote on: Should we implement knome's proposal in our development mailinglist?
[11:04] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[11:04] <elfy> +1
[11:04] <meetingology> +1 received from elfy
[11:04] <ochosi> +1
[11:04] <meetingology> +1 received from ochosi
[11:04] <slickymasterWork> +1
[11:04] <meetingology> +1 received from slickymasterWork
[11:04] <knome> +1
[11:04] <meetingology> +1 received from knome
[11:04] <jjfrv8> +1
[11:04] <meetingology> +1 received from jjfrv8
[11:04] <ochosi> oh hey jjfrv8 :) didn't see you there
[11:04] <elfy> oooh a lurker :p
[11:04] <knome> o hai jjfrv8 :)
[11:04] <ochosi> bluesabre?
[11:04] <slickymasterWork> jjfrv8, o/
[11:04] <bluesabre> +1
[11:04] <meetingology> +1 received from bluesabre
[11:05] <ochosi> #endvote
[11:05] <meetingology> Voting ended on: Should we implement knome's proposal in our development mailinglist?
[11:05] <meetingology> Votes for:6 Votes against:0 Abstentions:0
[11:05] <meetingology> Motion carried
[11:05] <knome> heh:)
[11:05] <elfy> lol
[11:05] <ochosi> knome: so much for not having a quorum :p
[11:05] <knome> well we don't
[11:05] <ochosi> wait, how many are we? crap :)
[11:05] <ochosi> we need two more
[11:05] <knome> 14
[11:05] <knome> yep
[11:05] <slickymasterWork> where's Unit193?
[11:05] <elfy> ochosi: shame you can set votes required in here
[11:05] <ochosi> fell asleep maybe...
[11:06] <slickymasterWork> lol
[11:06] <elfy> then it wouldn't have passed :)
[11:06] <ochosi> #action ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal
[11:06] <meetingology> ACTION: ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal
[11:06] <knome> do we want to allow private voting? :P
[11:06] <elfy> perhaps that should be added to the bot in here - it's likely to happen everytime we vote on anything
[11:06] <ochosi> nah
[11:07] <knome> lderan!!!
[11:07] <ochosi> (that was directed at knome, not elfy)
[11:07]  * knome gathered
[11:07] <elfy> ochosi: I guessed too :p
[11:07] <ochosi> ok, we have two more discussion-topics
[11:07] <ochosi> i have to run in 10-15mins though
[11:07] <ochosi> just saying...
[11:07] <knome> heh
[11:07] <knome> btw
[11:07]  * slickymasterWork also
[11:07] <elfy> both mine - both quick
[11:08] <knome> #votesrequired <count>
[11:08] <knome> Specifies the number of votes needed until the vote will pass. Example: #votesrequired 2 means you either need an aggregate of +2 or -2 to pass.
[11:08] <ochosi> oh, :)
[11:08] <ochosi> #subtopic Planning for milestone images
[11:08] <ochosi> elfy: you got the floor
[11:08] <elfy> So - we need to make a decision on whether to go with Alpha's or not this cycle
[11:08] <elfy> or one of them
[11:09] <ochosi> any pros/cons from your side?
[11:09] <elfy> I'd suggest I'll mail -team once we've got m/l moderated (or not)
[11:09] <ochosi> that's ok
[11:09] <elfy> not really - I just need to know as early as possible
[11:09] <ochosi> i'm fine with that
[11:09] <ochosi> shall we just make it an action item and move on?
[11:09] <elfy> yep - wfm
[11:10] <ochosi> #action elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?)
[11:10] <meetingology> ACTION: elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?)
[11:10] <ochosi> #subtopic Assistive tech testing
[11:10] <elfy> assistive tech is currently on the Settings Manager - I AM removing it from that test
[11:11] <elfy> the question is - do we need to actually test that or not - if not all I need do is remove it - if we do I'll need to build a test for it
[11:11] <ochosi> what does/did the test do?
[11:11] <ochosi> test the settings manager itself or the subdialogs?
[11:11] <bluesabre> gotta run, bbl
[11:11] <elfy> I spoke to Nick Skaggs - it seems that Ubuntu only test the install screen reader - no other tests done
[11:12] <ochosi> bluesabre: ttyl!
[11:12] <elfy> ochosi: it tests sticky keys and the like
[11:12] <slickymasterWork> and mouse emulation
[11:12] <elfy> http://packages.qa.ubuntu.com/qatracker/testcases/1574/info
[11:12] <elfy> last section of that
[11:13] <ochosi> right
[11:13] <elfy> it does need to be removed from Settings Manager - but whether we test it or not is the issue for me
[11:13] <ochosi> frankly, i don't have a strong opinion on this
[11:13] <elfy> if there's something wriong with it - we'd not be fixing it
[11:14] <ochosi> is that generally a rule for testcases, that we test stuff that we'd also fix
[11:14] <ochosi> ?
[11:14] <elfy> not as such
[11:14]  * ochosi is a bit out of the loop with QA
[11:14] <ochosi> i'd trust you as QA lead or others more involved in QA to discuss this and take an informed decision
[11:14] <elfy> we try to test things that we use - this is just a hang on in the wrong place
[11:15] <elfy> ok - well as I said I WILL be removing it - today :p
[11:15] <ochosi> ok :)
[11:15] <elfy> I'm easy to build a new testcase if needed
[11:15] <ochosi> sounds good to me
[11:15] <ochosi> wanna #info or Ã¤action that?
[11:16] <elfy> I'll talk more to Nick
[11:16] <ochosi> ok
[11:16] <elfy> not really a need - I got the bug - and the MP waiting for me to send :)
[11:16] <ochosi> ok
[11:16] <ochosi> so we can move on?
[11:16] <elfy> yep - I'm good now thanks :)
[11:16] <ochosi> ok, thanks elfy  :)
[11:17] <ochosi> #topic Schedule next meeting
[11:17] <ochosi> as discussed previously, we could cycle meeting times this cycle
[11:17] <ochosi> so the next meeting could be at a different time of the day
[11:17] <ochosi> i'm still happy that this worked so well and so many of you showed up today
[11:17] <ochosi> so thanks everyone!
[11:17] <elfy> ochosi: so how about this
[11:18] <elfy> cycle it through team leads -  team name alphabetically
[11:18] <elfy> puts QA at the end :p
[11:18] <ochosi> haha
[11:18] <ochosi> meh, artwork, i need to do the first one ;)
[11:18] <ochosi> that was your plan all along, right?
[11:18] <elfy> lol
[11:18] <ochosi> we could cycle through team leads and the respective team lead
[11:18] <ochosi> 1) decides on the meeting time
[11:19] <ochosi> 2) chairs the meeting
[11:19] <slickymasterWork> lol, I'm hanging by a thread on the one after artwork
[11:19] <elfy> :p
[11:19] <elfy> that makes some sense - and people can call ad-hoc ones as is normal when needed
[11:19] <ochosi> so i can do another meeting at a different time of the day
[11:19] <knome> sounds like a good plan
[11:20] <ochosi> question is whether next week is too early
[11:20] <slickymasterWork> I gotta run now, will be back after lunch
[11:20] <elfy> and XPL can call general meeting when he wants to
[11:20] <ochosi> the 2 weeks rhythm worked fine in 14.04, no?
[11:20] <elfy> ochosi: appeared to
[11:20] <knome> we had a one week interval at some point
[11:20] <elfy> and we'll have other avenues more useful - m/l without distraction
[11:20] <knome> near the end at least
[11:20] <ochosi> mhm
[11:21] <ochosi> meh, i also wanted to discuss blueprints and ppl starting to fill them up
[11:21] <ochosi> too late now
[11:21] <elfy> ochosi: m/l :D
[11:21] <ochosi> #action ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle
[11:21] <meetingology> ACTION: ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle
[11:21] <elfy> I assume you'll be doing what the last one did - talk to leads about blueprints
[11:22] <ochosi> yeah, i'm considering to wait with that until the mailinglist is closed
[11:22] <ochosi> blueprints are a dangerous mailinglist topic in terms of getting unasked responses
[11:22] <ochosi> (Ã  la: "please implement *this*, this is sooo important.")
[11:23] <ochosi> i'll announce the next meeting time at some point then
[11:23] <ochosi> need to check my calendar...
[11:23] <elfy> ok
[11:23] <ochosi> guess that's it
[11:23] <ochosi> #endmeeting
[11:23] <meetingology> Meeting ended Fri May 16 11:23:41 2014 UTC.
[11:23] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-05-16-10.01.moin.txt
[11:23] <ochosi> thanks everyone!
[11:23] <elfy> thanks ochosi
[11:24] <ochosi> ok, gotta go, have a nice day everyone!
[11:24] <elfy> cya ochosi
[11:24] <ochosi> seeya elfy
[11:26] <knome> meeting minutes are up
[11:32] <elfy> ty knome
[11:46] <elfy> knome: you got time to look at a MP?
[11:48] <elfy> or slickymasterWork
[11:48] <elfy> https://code.launchpad.net/~elfy/ubuntu-manual-tests/1319137/+merge/219822
[11:48] <elfy> bbiab
[12:28] <slickymasterWork> elfy, on it
[12:33] <slickymasterWork> elfy: https://code.launchpad.net/~elfy/ubuntu-manual-tests/1319137/+merge/219822
[12:33] <slickymasterWork> done
[12:35] <elfy> ty slickymasterWork :)
[12:35] <slickymasterWork> np elfy, my pleasure
[12:36] <elfy> :)
[12:38] <elfy> all synced now
[12:38]  * elfy wanders off again for a while
[14:20] <jjfrv8> elfy, my Trello account name is @jjfrv8
[14:21] <elfy> jjfrv8: added you - assume it's jjfrv8 :)
[14:22] <jjfrv8> elfy, got it. Thanks.
[14:22] <elfy> :)
[14:22] <ochosi> elfy: re: team board, currently it seems to only hold links to the blueprints, is that what it should be?
[14:23] <ochosi> or is it simply not complete yet?
[14:23] <elfy> ochosi: yea, I'd say it was up to those in teams to do what they want with their lists - only way they'll know if it works for them
[14:24] <ochosi> right, but how are you planning to handle the qa list then?
[14:24] <elfy> I'm not at all sure ...
[14:25] <ochosi> :)
[14:25] <ochosi> well you should set an example for others, otherwise how would they know how they can benefit? (assuming that some havent used trello before)
[14:26] <elfy> I might just add people to the QA one
[14:27] <elfy> if I add the QA lists to the team board it'll seem like a hostile takeover :p
[14:31] <ochosi> heh, no it might actually look like it should, no?
[14:32] <elfy> ok - help for trello works \o/
[14:33] <elfy> moved all the QA lists to the team board
[14:35] <elfy> ochosi: well sort of, depends how many lists sub-teams decide they need :)
[14:36] <ochosi> humm, that's a bit what i was afraid of to be honest
[14:36] <ochosi> that you cannot easily collapse these lists
[14:36] <ochosi> so if we want "the full overview", it'll be huge
[14:37] <ochosi> otherwise we might just end up with what knome mentioned earlier, boards per team
[14:37] <elfy> which was why I left QA seperate - so if someone needs to know something specific look there
[14:38] <elfy> mmm
[14:38] <elfy> let me think
[14:38] <ochosi> right, i presumed there was a nice way to get this "full overview", i thought you mentioned that as something you'd want in the meeting, but i might misremember that
[14:39] <ochosi> (the ideal solution would be a better, user-friendlier launchpad i guess)
[14:39] <elfy> that's probably a convergence of me not explaining and others thinking I meant something else :p
[14:41] <ochosi> well at least it means that it makes sense to set trello up so others really understand what it means to use it :)
[14:41] <elfy> just playing on the QA one
[14:41] <elfy> now that it's empty :p
[14:43] <ochosi> eheh
[14:54] <elfy> ochosi: played with that - ripped it apart - left some notes so people can see how filtering works
[15:02] <brainwash> ochosi: reassign bug 1310264 to xubu default settings and apply the proposed workaround?
[15:13] <ochosi> brainwash: i'm +1 on that as my comment suggests, i just have a few other things to do right now, can you take care of it? (link it to the utopic features blueprint and re-assign it to x-d-s)
[15:13] <brainwash> oh, so no chance to get it in for trusty?
[15:14] <brainwash> it's a bit tricky I guess
[15:16] <ochosi> well even if we SRU it to trusty, it needs to go through utopic
[15:16] <ochosi> so we should target that first anyhow
[15:16] <brainwash> yes, but we could leave it assigned to the trusty blueprint, or?
[15:17] <brainwash> changes will be carried on to utopic anyway
[15:20] <ochosi> you can leave the bugreport linked to the 14.04.1 blueprint, but i'd want it to be assigned to utopic features too
[15:21] <brainwash> ok
[15:22] <ochosi> ty
[15:22] <brainwash> bug 1024482 too? it's the missing busy cursor problem caused by the greeter
[15:22] <brainwash> feature or bugfix?
[15:23] <ochosi> give me a minute (or a few), haven't seen that one yet
[15:23] <brainwash> the linked debian report explains the problem better
[15:25] <ochosi> ok, will look at that
[15:25] <ochosi> just gotta finish something else first...
[15:26] <brainwash> sure
[15:28] <brainwash> ali1234: is your mwm hints patch still needed for gtk 3.12?
[15:29] <brainwash> maybe I'm just confused about what's going on
[15:41] <elfy> ochosi brainwash - I'm going to assume I had a glitch or something with parole, reinstalled since - cpu usage appears to be normal http://pastebin.com/dcGcxWTJ
[15:42] <brainwash> elfy: same audio file?
[15:43] <elfy> brainwash: that's a few audio files
[15:43] <elfy> and it doesn't matter if it's the same file - it wasn't just one - and if you think I'd remember which out of 36k music files it was ...
[15:44] <brainwash> ah ok
[15:44] <elfy> :)
[15:45] <elfy> sigh - bluesabre - that ping was supposed to be for you ^^ :)
[15:45] <elfy> sorry brainwash - I wondered what blue sabre was doing here this time of the day lol
[15:47] <brainwash> :D
[15:47] <ochosi> elfy: i told them before one of them should change nicks :D
[15:47] <elfy> ha ha ha
[15:47] <brainwash> bluesabre did
[15:48] <brainwash> maybe he forgot about it again
[15:48] <elfy> elopio thinks I should change mine - no chance :p
[15:53] <knome> brainwash, you could just /nick brainwashed
[15:53] <brainwash> I'm not brainwashing myself
[15:54] <ochosi> or s/brainwash/brainwasher/
[15:55] <brainwash> maybe
[15:55] <brainwash> but only for 1 day :)
[17:25] <ali1234> brainwash: don't know/don't care
[17:26] <ali1234> i have no interest in supporting gnome's poor design decisions
[19:13] <andrzejr> what is the package name of the app-menu indicator triggering #1181134?
[19:13] <andrzejr> https://bugs.launchpad.net/ubuntu/+source/xfce4-indicator-plugin/+bug/1181134


[02:30] <mup> PR snapd#9556 closed: tests: testing new fedora 33 image <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>
[07:09] <zyga-x240> good morning mvo
[07:10] <zyga-x240> mvo: I had a look at the changes to the export manager but ended up just going to sleep yesterday; I think today may be better as lately we are sleep deprived by Lucy who is going through the 2-yo hyperactivity phase
[07:11] <mup> PR snapd#9664 closed: spread: disable unattended-upgrades on ubuntu <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9664>
[07:14] <mvo> good morning zyga-x240
[07:14] <mvo> zyga-x240: no worries! thanks for letting me know
[07:22] <mup> PR snapd#9652 closed: o/servicestate: unlock state before calling wrappers in doServiceControl <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9652>
[07:23] <zyga-x240> mvo: I saw that the uboot bug was addressed
[07:24] <zyga-x240> mvo: I understand this unblocks gadget updates across the pi lineup
[07:24] <zyga-x240> mvo: and that this was an additional blocker for uc20
[07:24] <mvo> zyga-x240: yeah, it's pretty good
[07:24] <mvo> zyga-x240: I need to check if we have updated pi/edge already
[07:25] <mvo> zyga-x240: but the debs got udpated, once that is in we will look into fixing it on a broader scope
[07:25] <zyga-x240> mvo: the debs got updated yes
[07:26] <zyga-x240> please note that while great, this makes the pi break on the dbt skew
[07:26] <zyga-x240> only fresh installs are okay
[07:26] <mvo> zyga-x240: yes, we are working on this too
[07:26] <zyga-x240> but it's inevitable
[07:26] <zyga-x240> I know, that's really cool
[07:26] <mvo> zyga-x240: and there is work to use piboot so that we have proper a/b boot with dtbs, so it's advancing on all fronts
[07:26] <mvo> (also not as fast as I wish we would go)
[07:27] <zyga-x240> mvo: I heard about that as well, but I was not sure if that has already started to approach snapd side
[07:27] <zyga-x240> will it be another bootloader variant in our code or will there be some middleware-like abstraction via hooks
[07:28] <mvo> zyga-x240: I think it will be bootloader like
[07:28] <mvo> zyga-x240: maybe a variant of uboot, i.e. if uboot finds config.txt then it will behave slightly differently
[07:28] <mvo> zyga-x240: but the details are not clear yet, we are still in the prototype phase for this
[07:30] <zyga-x240> mvo: I recall that there was some resitence from the pi foundation to help us in any way that would require code changes
[07:31] <zyga-x240> mvo: do you know how A/B or try mode boot will work?
[07:31] <mvo> zyga-x240: dave told me he tested it from pi3 onward
[07:31] <mvo> zyga-x240: but *maybe* we loose the pi2 :(
[07:31] <mvo> zyga-x240: not sure yet, also this seems to be super recent firmware changes
[07:31] <zyga-x240> ah, that's reassuring then
[07:32] <zyga-x240> perhaps it is an improvement to the boot process
[07:32] <zyga-x240> any kind of conditionality or writable state accessible from the native bootloader is sufficient
[07:32] <zyga-x240> but you know that :)
[07:32] <zyga-x240> I hope they changed their minds on it
[07:33] <mborzecki> morning
[07:33] <zyga-x240> hey mborzecki
[07:33] <mborzecki> finally got my tires swapped to the winter set
[07:33] <mvo> zyga-x240: I think they did but we helped them with that AIUI
[07:34] <mvo> good morning mborzecki
[07:34] <zyga-x240> mborzecki: just in time for global warming ;-)
[07:34] <mborzecki> zyga-x240: haha right
[07:34] <mborzecki> mvo: hey
[07:34] <zyga-x240> mborzecki: I really wish we have a month of -5 to -10 and lots of snow
[07:34] <zyga-x240> I miss that from my childhood
[07:34] <mvo> mborzecki: when you have a few cycles, could you please look at 9497 ? hopefully straightforward
[07:34] <mborzecki> zyga-x240: no thanks ;) you're free to enjoy winter in canada though
[07:35] <mborzecki> mvo: sure
[07:35] <zyga-x240> mborzecki: could as well be a screen saver unless I'm there :)
[07:35] <mvo> zyga-x240: or move to minessota
[07:35] <mvo> zyga-x240: the cold there is quite impressive
[07:35] <zyga-x240> mvo: my new boss tries to move me to Italy instead ;-)
[07:36] <zyga-x240> I wish we had that magic house with a handle that can open in four different ways, to go to four different places
[07:36] <mborzecki> zyga-x240: tbh this sounds quite nice
[07:36] <zyga-x240> a house by the sea, a house in the mountains, in big city and that big black void IIRC
[07:36] <mborzecki> zyga-x240: move to the south and enjoy the all year round cycling season
[07:36] <zyga-x240> (I love that movie)
[07:37] <zyga-x240> mborzecki: well, now I'd be happy if lucy stopped running around at 1AM every day :)
[07:37] <zyga-x240> I guess that will pass
[07:38] <mvo> zyga-x240: it will pass and in 10y happen again ;)
[07:38] <mvo> zyga-x240: or maybe 15y
[07:38] <zyga-x240> mvo: yeah but when she has her own room that's okay :D
[07:39] <mvo> zyga-x240: heh … good point!
[07:39] <zyga-x240> mvo: I will look at patching spread soon
[07:39] <zyga-x240> I'm split between a fork and proper upstream cooperation
[07:40] <zyga-x240> I'm going to add new backends to it
[07:40] <zyga-x240> mainly to use a muxpi-exposed ad-hoc new API as "cloud"
[07:40] <zyga-x240> initially a 1-1 but later 1-n model (one host talking to a number of configured muxpi's over lan, each exposing some real hardware and features)
[07:40] <zyga-x240> I guess time will tell, I haven't touched this yet
[07:45] <mvo> zyga-x240: nice, looking forward to that
[07:45] <mvo> zyga-x240: more spread development is most welcome
[08:03] <mborzecki> fun thing i noticed in the serial log of a failed test: ` Error syncing keystore file /usr/share/secureboot/updates/dbx/dbxupdate_x64.bin`
[08:04] <zyga-x240> interesting :)
[08:07] <pstolowski> morning
[08:07] <zyga-x240> hey pawel :)
[08:07] <pstolowski> heya
[08:20] <mvo> hey pstolowski !
[08:21] <pstolowski> o/
[08:27] <mborzecki> pstolowski: hey
[08:27] <mborzecki> somehow debug logs in #9640 make no sense
[08:27] <mup> PR #9640: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>
[08:31] <pstolowski> mborzecki: hey; merge master, this will fix lxd-services-smoke failure
[08:33] <mborzecki> pstolowski: it's the test changed by the PR, the debug output makes no sense, things which should have been there given the environment variables are not present
[08:33] <mborzecki> it's as if the env variables are not set, or something overwrites them
[08:36] <pedronis> mborzecki: nested.sh might overwrite some stuff?
[08:37] <mborzecki> pedronis: it sets some things but it should not overwrite NESTED_{ENABLE_TPM,ENABLE_SECURE_BOOT,BUILD_SNAPD_FROM_CURRENT}
[08:38] <mborzecki> pedronis: otoh, the debug output suggest that NESTED_BUILD_SNAPD_FROM_CURRENT was not set, because the gadget snap was most likely not repacked
[08:39] <pedronis> mborzecki: remember that there is some form of image caching
[08:40] <pedronis> maybe it's bugggy in terms of reusing things even if they were built with different params ?
[08:40] <mborzecki> pedronis: this is a manual test and supposedly nothing ran before it
[08:40] <mvo> pedronis: I re-read your comments on 9667 again this morning - is https://github.com/snapcore/snapd/pull/9667/files#diff-3dedbc3a1986cf905aca293ca6d16560d297253859ecaa8bcea2b7dab7143b3cR1360 what you suggested?
[08:40] <mup> PR #9667: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>
[08:41] <pedronis> mvo: yes, that looks like what I had in mind
[08:41] <mvo> pedronis: nice, let me add tests then
[08:41] <pstolowski> mborzecki: fwtw we do set NESTED_IMAGE_ID in some manual/ tests
[08:42] <pedronis> mborzecki: spread bug?  I suppose you should sprinkle "env" calls around
[08:51] <pedronis> mvo: ask my review again in it when you think it's ready
[08:56] <mvo> pedronis: I just added tests, so a quick look would be good
[08:56] <mborzecki> mvo: what shall we do with #9633?
[08:56] <mup> PR #9633: github: run nested suite when commit is pushed to release branch <Run nested> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9633>
[08:57] <pedronis> mvo: I put it back into my queue
[09:17] <mvo> pstolowski: could you please have a look at 8943 when you have some spare cycles?
[09:17] <pstolowski> mvo: yes
[09:17] <mvo> \o/
[09:21] <pstolowski> it has conflict though
[09:22] <pstolowski> jamesh: hey, can you merge master ^ if still around?
[09:23] <jamesh> pstolowski: doing it now.
[09:24] <pstolowski> ty
[09:34] <jamesh> pstolowski: I've pushed up a fix for the merge conflict.  Thanks for looking into this.
[09:45] <pstolowski> jamesh: thanks, i'll get to it shortly
[09:52] <mup> PR snapd#9497 closed: usersession/agent: have session agent connect to the D-Bus session bus <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9497>
[09:52] <mup> PR snapd#9641 closed: o/servicestate: preserve order of services on snap restart <Bug> <Services ⚙> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9641>
[09:56] <mborzecki> funny how that core20-save test works just fine when running on google from local spread :/
[10:19] <pedronis> mborzecki: I see some issues with #9659
[10:19] <mup> PR #9659: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9659>
[10:23] <mborzecki> pedronis: hm good catch label != "" and empty mode, looks like it would hit an internal error in cmd_initramfs_mounts in that case, and other call sites ignore the label and just look at the mode
[10:31] <mborzecki> heh, gorename just paniced on me when trying to rename KernelCommandLineKeyValue
[10:34] <mborzecki> backtrace --> https://paste.ubuntu.com/p/zcywxYtfB6/
[10:45] <vidal72[m]> jamesh: is this still needed for snap? https://github.com/flatpak/xdg-desktop-portal/pull/443
[10:45] <mup> PR flatpak/xdg-desktop-portal#443: Don't use AppArmor to detect snap confined clients <Created by jhenstridge> <https://github.com/flatpak/xdg-desktop-portal/pull/443>
[10:46] <jamesh> vidal72[m]: yeah.  We'd like to get that in.
[10:46] <jamesh> vidal72[m]: I can look at rebasing if that'd help
[10:47] <vidal72[m]> it may help yes
[10:54] <jamesh> vidal72[m]: sorry for not being more active on this.  I got swamped with other work, and it wasn't clear what would have been needed to get it landed back then.
[11:05] <mborzecki> pedronis: i've updated #9659
[11:05] <mup> PR #9659: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9659>
[11:20] <mborzecki> mvo: are you updating #9667 or should i push the tweaks there?
[11:20] <mup> PR #9667: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>
[11:37] <pedronis> mborzecki: thx, will look in a bit
[12:08] <mup> PR snapd#9661 closed: osutil/disks: add DiskFromName to get a disk using a udev name <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9661>
[12:09] <pedronis> mborzecki: reviewed
[12:20] <mborzecki> pedronis: thanks, added a proposal of a name for that var in a comment
[12:24] <ijohnson> morning folks
[12:24] <ijohnson> mborzecki: are you working on addressing pedronis' feedback on 9659
[12:24] <ijohnson> ?
[12:28] <mborzecki> ijohnson: yeah
[12:29] <ijohnson> k, thank you !
[12:32] <pedronis> mvo: I reviewed #9656
[12:32] <mup> PR #9656: devicestate: support "storage-safety" defaults during install <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9656>
[12:33] <pedronis> degville: ijohnson: ^ there's a log message there where native speaker input could be valuable
[12:33] <ijohnson> sure I can have a look
[12:35] <ijohnson> responded
[12:36] <pedronis> mborzecki: thx, better but I proposed a slight tweak on the name, sorry. mostly is unclear if "mock" is relevant there or not
[12:38] <pedronis> ijohnson: thanks, your message sounds good to me
[12:39] <ijohnson> pedronis: mvo: did y'all see my comment in the SU doc about the uc20 regression?
[12:39] <degville> pedronis: ijohnson: me too, although I'm trying to think of something other than 'due', as it could imply prefer-unencrypted was unintentionally set.
[12:39]  * ijohnson has no strong attachment to the word "due"
[12:40] <pedronis> ah, language is hard
[12:40] <pedronis> ijohnson: yes, sounds something to discuss in the standup
[12:40] <degville> turtles all the way down.
[12:40] <ijohnson> pedronis: ok
[13:00]  * pstolowski lunch
[13:34] <mvo> mborzecki: \o/ for updating 9667
[13:35] <mvo> pedronis: thanks for the review!
[13:38] <pedronis> pstolowski: is #9409 ready for re-reviews?
[13:38] <mup> PR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>
[13:38] <mup> PR snapd#9667 closed: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9667>
[13:43] <mup> PR snapd#9670 opened: devicestate: make checkEncryption fde-setup hook aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/9670>
[13:46] <pstolowski> pedronis: yes
[13:49] <pedronis> pstolowski: ok, I put it back into my queue
[13:53] <mup> PR snapd#9660 closed: gadget/gadget.go: allow system-recovery-{image,select} as roles in gadget.yaml <Needs Samuele review> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9660>
[14:21] <mup> PR snapcraft#3381 opened: multipass build provider: check if instance exists before deleting <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3381>
[14:30] <mborzecki> pstolowski: pushed a commit with NESTED_IMAGE_ID to #9640
[14:30] <mup> PR #9640: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>
[14:37] <pedronis> pstolowski: are you blocked right now?
[14:38] <mup> PR snapd#9659 closed: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9659>
[14:39] <ijohnson> \o/
[14:39] <mvo> thanks ijohnson !
[14:40] <ijohnson> thanks for merging mvo!
[14:41] <pstolowski> pedronis: not really; but i think i won't start new validation sets PR until existing ones are ok'ed?
[14:41] <pedronis> pstolowski: mostly asking if a re-review of the client one can wait tomorrow?
[14:42] <pstolowski> pedronis: yes that's fine. when you ack the client api bit then i'll update the second existing PR to match
[14:51] <mvo> 8929 needs a second review, should be relatively easy I hope
[14:54]  * cachio lunch
[16:16] <pstolowski> looking
[16:28] <pstolowski> +1
[16:45] <jdstrand> amurray: would you ming giving https://github.com/snapcore/snapd/pull/9263 a final review from security? (I commented on the base decl and removal of device-tree only)
[16:45] <mup> PR #9263: interfaces/fpga: add fpga interface <Needs Samuele review> <Needs security review> <Squash-merge> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/9263>
[16:54] <ijohnson> .........................................
[16:55] <ijohnson> why does uboot.go refer to the u-boot bootloader as "uboot", but gadget.yaml requires "u-boot"
[16:55]  * ijohnson sighes heavily
[16:55] <ijohnson> pedronis: I could use some help here if you have some time
[16:55] <ijohnson> not sure which we should re-name
[16:55] <pedronis> ijohnson: none
[16:56] <pedronis> I'm not quite sure why it matters
[16:56] <ijohnson> I suppose I could just silently alias "u-boot" as "uboot"
[16:56] <pedronis> ijohnson: I fear I'm missing something here
[16:56] <ijohnson> well firstly the names are inconsistent which is just unfortunate as a fact of matter
[16:57] <pedronis> kind of yes
[16:57] <ijohnson> secondly, I am trying to do the ForGadget thing which uses the name of the bootloader from the gadget.yaml to know which bootloader it should try
[16:57] <pedronis> that's the part I don't get
[16:57] <pedronis> why the gadget.yaml
[16:57] <pedronis> that was not what we discussed
[16:57] <ijohnson> mmm
[16:57] <pedronis> maybe is needed for lk
[16:57] <pedronis> but is not what we discussed
[16:58]  * zyga-mbp looks at https://github.com/snapcore/snapd/pull/9546
[16:58] <ijohnson> so if we don't use gadget.yaml how do we know what bootloader is in a given extracted gadget tree ?
[16:58] <mup> PR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>
[16:58] <pedronis> ijohnson: we look at the .conf file, as we did before
[16:58] <ijohnson> are we supposed to just grep for all "*.conf" files and see which one matches ?
[16:59] <ijohnson> I guess we could do that, it feels again like we are guessing since folks could put whatever .conf they want there in addition to uboot.conf
[16:59] <pedronis> ijohnson: the change I had in mind was very simple
[16:59] <ijohnson> for example
[16:59] <pedronis> ijohnson: but that's how things worked already
[16:59] <pedronis> we are not trying to change how that works
[17:00] <ijohnson> I guess I was just trying to make that nicer since it feels silly how much guessing we end up doing
[17:00] <pedronis> we are just changing the implementaion details
[17:00] <pedronis> ijohnson: well it changes the mechanics quite a bit
[17:00] <pedronis> probably not a good thing to do before 22
[17:00] <pedronis> at this point
[17:01] <ijohnson> pedronis: did you mean not a good thing to do before 20 ?
[17:01] <pedronis> no, I mean, if we want to change the mechaninics of detecting the gadget
[17:01] <pedronis> bootloader
[17:01] <pedronis> that would be a core 22 thing
[17:01] <pedronis> at this point
[17:02] <ijohnson> ok sure I will just go do the silly grep thing
[17:02] <pedronis> ijohnson: is not a grep thing
[17:02] <pedronis> ijohnson: maybe we should have a quick chat
[17:02] <ijohnson> sure
[17:03] <ijohnson> I'm in the SU
[17:07] <zyga-mbp> hey King_InuYasha
[17:59] <mup> PR snapd#9671 opened: release: snapd 2.48 <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9671>
[18:00] <zyga-mbp> mvo +1
[18:19] <mup> PR snapd#9671 closed: release: snapd 2.48 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9671>
[18:24] <mvo> thanks zyga-mbp
[18:24] <zyga-mbp> :-)
[18:24] <zyga-mbp> I should really thank you instead
[18:25] <mvo> cachio: snapd snap in beta for everything but arm*
[18:26] <mvo> cachio: core as well, arm will come in ~1h or so
[18:27] <cachio> mvo, nice
[18:27] <cachio> perfect, validation already started
[18:27] <mvo> cachio: \o/
[18:27] <mvo> thanks!
[18:27] <cachio> mvyaw
[18:27] <cachio> mvo, yaw
[18:39] <mup> PR snapd#9672 opened: vendor: update secboot repo to avoid including secboot.test binary <Created by mvo5> <https://github.com/snapcore/snapd/pull/9672>
[18:52] <mup> PR snapcraft#3382 opened: project loader: purge dead code in Config <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3382>
[19:07] <mvo> cachio: arm is now also ready in beta
[19:09] <cachio> mvo, perfect
[19:09] <cachio> thanks
[19:10] <cachio> I'll write in the docs with the results
[19:11] <mvo> ta!
[19:13] <ijohnson> mvo: approved 9672
[19:13] <mvo> ijohnson: \o/
[19:14] <mvo> ijohnson: thanks, I closed/reopened because I forgot the "run-nested" label :/
[19:15] <ijohnson> ah right
[19:52] <pedronis> for clarity, that brings in also https://github.com/snapcore/secboot/pull/108
[19:52] <mup> PR secboot#108: Make AddEFISecureBootPolicyProfile less strict <Created by chrisccoulson> <Merged by chrisccoulson> <https://github.com/snapcore/secboot/pull/108>
[19:53] <ijohnson> yes I looked at the diff in secboot and it looked "safe" to me
[21:35] <mup> PR snapd#9662 closed: bootloader/many: return error from ConfigFile and new* functions <UC20> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9662>
[21:35] <mup> PR snapd#9673 opened: bootloader/many: rm ConfigFile, add Present for indicating presence of bloader <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9673>
[23:11] <amurray> jdstrand: security review done on https://github.com/snapcore/snapd/pull/9263
[23:11] <mup> PR #9263: interfaces/fpga: add fpga interface <Needs Samuele review> <Needs security review> <Squash-merge> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/9263>
[23:12] <jdstrand> amurray: thanks!
[23:51] <mup> PR snapd#9674 opened: bootloader/lkenv: mv v1 to separate file, include/lk/snappy_boot_v1.h: little fixups <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9674>
[23:56] <mup> PR snapd#9675 opened: bootloader/lkenv: add v2 struct + support using it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9675>


[09:59] <rogpeppe> i'm taking another swap day today, BTW
[10:00] <mattyw> rogpeppe, I don't remember allowing that
[10:00] <rogpeppe> mattyw: oh
[10:00] <rogpeppe> mattyw: in which case i guess i'll just have to kill you
[12:58] <smoser> hey. whats the state of the null /none/manual provider ?
[12:58] <smoser> is that in 1.16 ?
[13:37] <natefinch> smoser: the manual provider is in 1.16 but it's not really ready for primetime. There's still some bugs around it.
[13:38] <smoser> natefinch, thats ok.
[14:52] <smoser> hey....
[14:52] <smoser> http://paste.ubuntu.com/6324341/
[14:52] <smoser> that seems to imply that "Due to needing newer versions of LXC the local provider does require a newer kernel than the released version of 12.04. Therefore we install Linux 3.8 from the LTS Hardware Enablement Stack"
[14:53] <smoser> which is declared as fact at https://juju.ubuntu.com/docs/config-local.html
[14:53] <smoser> is incorrect
[14:53] <smoser> can we have that doc fixed please ?
[14:53] <smoser> or someone point me to why that statement exists  (hazmat?)
[14:56] <natefinch> smoser: I don't know the exact details, but we've definitely seen problems with 12.04.  Not only the old LXC but also the old MongoDB.  Are you sure you're not already running the newer kernel on that machine?
[14:57] <smoser> natefinch, i'm using the cloud archive
[14:57] <smoser> which is the solution designed by CTS for some supportable solution of juju on 12.04
[14:59] <smoser> ie, that is probably what doc should suggest.
[15:00] <natefinch> smoser: yeah, it sounds like the doc is just out of date.  I haven't really kept up on the exact nuances of the local provider, which is my only hesitation.  definitely we should make sure the documentation is accurate and suggests the least painful way to get it running on 12.04
[15:12] <hazmat> smoser, not sure why that verbiage appeared.
[15:13] <hazmat> smoser, specifically around manual provider it works, but you need to manually remove the $JUJU_HOME/environments/$manual_env_name.jenv to destroy/reset it
[15:14] <hazmat> and it leaves juju stuff on the machines in question..
[15:14] <hazmat> smoser lp:juju-core/docs
[15:38] <hazmat> smoser, there are performance issues with older kernels (including 3.8) and container networking that have been documented, not sure its relevant in this context though
[15:40] <smoser> hazmat, hallyn was unaware of such issues
[15:40] <smoser> so links to such documentation might be useful.
[15:41] <hazmat> smoser, i saw it referenced by the docker  community last month re this thread https://groups.google.com/forum/#!msg/docker-user/txAd5BiVapU/AfXvssMqkr4J
[15:42] <smoser> i think performance of veth is probably not a good enough reason to sugges tsomeone use a HWE kernel that is not necessary otherwise.
[15:42] <smoser> at least without citing that as the reason
[15:42] <smoser> HWE kernels have real drawbacks, forcing you to upgrade or lose security updates earlier than 12.04 LTS kernel.
[16:04] <sinzui> natefinch, do you have time to review two small branches that backport fixes to 1.16.1? https://codereview.appspot.com/18610043/ and https://codereview.appspot.com/18640043/
[16:06] <natefinch> sinzui: sure
[16:09] <natefinch> sinzui: the first one already got a LGTM from jam, so that's fine. I can lgtm the other one.
[16:15]  * sinzui thinks his review emails are being eaten again
[16:20] <hatch> any word on a fix for the lxc/apt issue coming down the pipe? I'd really like to demo the GUI next week on lxc :)
[16:25] <sinzui> hatch is this the node problem?
[16:26] <hatch> sinzui: when I try and deploy the gui it fails with some apt-get stuff
[16:27] <hatch> I was told it was an lxc bug
[16:27] <hatch> happens on 12.04 and 12:10 with the most recent juju-core
[16:28] <sinzui> hatch, these are the bugs that I want to close today/tomorrow with a release https://launchpad.net/juju-core/+milestone/1.16.1
[16:29] <sinzui> hatch, there aren't any bugs about lxc reported that also speak of apt
[16:29] <hatch> ahh ok so that doesn't help unfortuately....I don't know what the true cause of it is, it could be lxc related and not juju related
[16:29] <sinzui> all apt bugs relate to firewalls in fact.
[16:30] <hatch> hmm ok I'll try and get some more information and file a formal bug so that someone can tell me one way or another if it's juju related or not
[16:31] <sinzui> I am sure it is a bug and maybe even reported. We want to tag it juju-gui so that I can drive a fix for it
[16:45] <hatch> sinzui: looks like after doing some updates after the sprint it's working again, so something must have landed to fix it :)
[16:46] <sinzui> okay hatch. If you do have bugs you care about, tag then with juju-gui so that I can arrange for fixes right away
[16:46] <hatch> will do thanks!
[18:38] <hazmat> smoser, re hwe sounds reasonable to me, i don't have any insight into why we doc'd hwe kernels for precise, we're not using any lxc functionality that's only later kernel rels afaics. the delta might be related to  lxc userspace tooling and how  a newer version of that interacts with older kernel versions, dunno.
[19:54] <sodre> hello. I am facing some issues with juju on an Openstack private cloud. Could someone explain point to some documentation on that ?
[19:55] <sodre> I am running Havana deployed on top of MAAS
[19:57] <sodre> hi Thumper, can you help me ?
[19:57] <thumper> maybe, what's your problem?
[19:58] <sodre> I am trying to run Juju on top of a Havana
[19:58] <sodre> on a private cloud.
[19:58]  * thumper thinks
[19:58] <thumper> is your problem django?
[19:58] <sodre> I've deployed Havana using Juju/MAAS. But now I am having issues deploying VMs on top of Havana using juju.
[19:58] <thumper> ISTR that there is an issue with dependencies
[19:59] <thumper> MAAS needing one version and havana needing another
[19:59] <sodre> a version of Juju ?
[19:59] <thumper> no
[19:59] <thumper> djanog
[19:59] <thumper> but when juju deploys a machine
[19:59] <thumper> it adds the cloud-tools archive
[20:00] <thumper> which then installs a version of django that havana can't use
[20:00] <thumper> this is a known bug and something we are going to try to work around
[20:00] <thumper> but not sure of the fix just yet
[20:00] <thumper> does this sound like your problem may be related to that?
[20:01] <sodre> okay. What is the side effect of that django bug? My issue right now is that Juju cannot bootstrap _on top of_ Havana.
[20:01] <sodre> Havana, seems to behave just fine by itself.
[20:01] <thumper> I'm not entirely sure what the side effect it, just that it doesn't work
[20:01] <thumper> this could be it
[20:01] <thumper> IF it is the same issue
[20:02] <thumper> what stage does it fail?
[20:02] <sodre> after I setup my environments.yaml file to point to my Havana install
[20:02] <sodre> I call juju bootstrap.
[20:02] <sodre> it uploads all the tools to Swift/RadosGW
[20:02] <sodre> then the following error comes up:
[20:02] <thumper> can you see that the machine has started? can you ssh to it?
[20:03] <sodre> 2013-10-29 19:47:26 ERROR juju supercommand.go:282 cannot start bootstrap instance: index file has no data for cloud {RegionOne http://m1basic-05.vm.draco.metal.as:5000/v2.0} not found
[20:03] <thumper> ok... that sounds like something else
[20:03] <thumper> maybe
[20:03] <sodre> I think so.
[20:03] <thumper> so... perhaps this is simple stream related
[20:04] <sodre> how do people usually load up their images into a Private OpenStack install for using with Juju?
[20:04] <thumper> we now use simple streams to find the instances
[20:04] <sodre> exactly...
[20:04] <thumper> I don't know
[20:04] <thumper> wallyworld may be able to help when he starts in a few hours
[20:04] <thumper> as he did a lot of the simplestream stuff
[20:04] <sodre> okay.
[20:04] <thumper> sodre: which TZ are you in?
[20:04] <sodre> I'm on EST
[20:05] <thumper> so already 5pm?
[20:05]  * thumper looks at the date applet
[20:05] <sodre> 4:05
[20:05] <thumper> oh, no falling back just yet
[20:06]  * thumper thinks
[20:06] <thumper> gah, TZ confused again
[20:06] <thumper> anyway...
[20:06] <sodre> :)
[20:06] <thumper> wallyworld is in brisbane, AU
[20:06] <sodre> okay...
[20:06] <thumper> and not likely to start for a few hours
[20:06] <thumper> or stry smoser
[20:06] <thumper> s/stry/try/
[20:06] <sodre> Let me pm him.
[20:07] <thumper> sodre: he is in this channel
[20:07] <thumper> smoser: <sodre> how do people usually load up their images into a Private OpenStack install for using with Juju?
[20:07] <thumper> smoser: any idea?
[20:08] <sodre> ahh.. got it
[20:08] <sodre> I haven't used IRC in such a long time.
[20:09] <thumper> I understand, before working at canonical I hadn't used irc at all
[20:10] <thumper> ok, not quite at all, but very briefly
[20:11] <sodre> Do most people at canonical work from home ?
[20:12] <smoser> ah. sodre yes most people work from home.
[20:12] <smoser> the suggested way to load images into glance is at https://code.launchpad.net/~smoser/simplestreams/example-sync
[20:13] <sodre> that is nice. I guess there is always development going ton.
[20:13] <sodre> Alright, let me clone that branch.
[20:22] <thumper> smoser: thanks
[20:26] <sodre> thanks thumper and smoser... I am still trying to get it to work... I'll be back soon.
[20:26] <thumper> sodre: good luck
[21:09] <sodre> smoser: are you still available ?
[21:10] <smoser> not really
[21:10] <smoser> qiuck....
[21:10] <sodre> for some reason the PUT requests are going itno /swift/simplestreams instead of swift/v1/simplestreams
[21:10] <sodre> any idea why that would be ?
[21:11] <sodre> Also, running swift from the command-line places things in the correct place.
[21:13] <smoser> unm...
[21:13] <smoser> i'm not sure.
[21:14] <smoser> that code there *is* used in production
[21:14] <smoser> so it is known working
[21:14] <sodre> okay. I am using radosgw, maybe it should default to v1
[21:16] <sodre> I'll give the code a quick read. Maybe I can figure out why it is not giving placing the v1 in PUT.
[21:37] <bigjools> wallyworld_: just for you: http://www.git-tower.com/blog/git-cheat-sheet/
[21:38] <wallyworld_> :-(
[21:38] <thumper> troll!
[21:39] <bigjools> like a boss
[21:39] <bigjools> I was using git yesterday as one of my home projects uses it
[21:40] <bigjools> hadn't been in for a while and needed to pull a particular branch to compile
[21:40] <bigjools> took me 45 minutes to work out how
[21:40] <bigjools> winning!
[21:40] <bigjools> who knew you had to pull *everything* and then "checkout"
[21:41] <bigjools> wallyworld_: I am low on coffee.  If you could stop by the local bean on the way over that'd be awesome
[21:41] <wallyworld_> it will cost you
[21:41]  * bigjools bends over
[21:42] <wallyworld_> it's on the wrong side of the road so it will cost you a lot
[21:42]  * thumper covers his eyes
[21:42] <thumper> there are children in this channel
[21:42]  * wallyworld_ unips
[21:42]  * bigjools goatses
[21:42] <thumper> WORK CHANNEL!!
[21:42] <bigjools> thumper: there sure are!
[21:42]  * thumper cracks a whip
[21:49] <sodre> wallyworld_: do you work on simplestreams as well ?
[21:50] <wallyworld_> the juju side of things, yes
[21:50] <sodre> I have a question :)
[21:50] <wallyworld_> sure
[21:51] <sodre> I am trying to use sstream-mirror-glance, but the URLs it gives to the swift client lacks the /v1  part.
[21:52] <sodre> e.g. when I run it, I get the following error
[21:52] <sodre> Container PUT failed: http://m1basic-04.vm.draco.metal.as:80/swift/simplestreams 405 Method Not Allowed
[21:53] <sodre> However, if I  run ' swift post simplestreams '
[21:53] <sodre> everything goes fine.
[21:54] <sodre> I have logs from the Swift back-end as well, if you would like to see them.. +3lines.
[21:54] <wallyworld_> sodre: i have no knowledge of the lp:simplestreams project and associated tools. i just do the juju-core lib
[21:54] <wallyworld_> which is a separate codebase written in Go
[21:54] <sodre> got it
[21:55] <wallyworld_> sorry :-(
[21:55] <sodre> np
[21:55] <wallyworld_> but it does seems perhaps there is a bug there
[21:56] <sodre> yeah, in the Swift log, it shows that the sstream-mirror-glance code did a PUT /swift/simplestreams
[21:56] <sodre> while the swift CLI, did a POST followed by a PUT /swift/v1
[22:06] <sodre> at least I found out why... the code in simplestreams/openstack.py strips the version out :)
[22:07] <sodre> no I wonder why they are doing that.
[22:08] <wallyworld_> good question :-)
[22:28] <sodre> wallyworld_ : The simplestreams images are getting loaded into glance after I commented out the "strip_versions" call.
[22:28] <wallyworld_> \o/
[22:28] <sodre> now I have another question which you might be able to help.
[22:29] <sodre> I am trying to deploy juju on top of Havana.
[22:29] <sodre> Havana itself seems to be working okay, i.e. I can launch CirrOS
[22:29] <sodre> create Networks, assign floating ips, etc...
[22:31] <sodre> let me clean up my bootstrap version
[22:34] <sodre> so I have sourced my admin-openrc.sh
[22:34] <sodre> I ran juju bootstrap
[22:34] <sodre> and then at the end I get the following error.
[22:34] <sodre> ERROR juju supercommand.go:282 cannot start bootstrap instance: index file has no data for cloud {RegionOne http://m1basic-05.vm.draco.metal.as:5000/v2.0}
[22:35] <sodre> I imagine that happens because it did a get for /swift/v1/admin-juju/streams/v1/index.json
[22:35] <sodre> and it failed.
[22:37] <sodre> how do I tell Juju to find /streams/v1/index.json in a different container ?
[22:49] <wallyworld_> sodre: you set the tools-url config option if you want to get simplestreams metadata from a non-default container
[22:50] <sodre> okay...  let me try taht.
[22:50] <wallyworld_> or, ensure the index file you are using has metadata for RegionOne and your endpoint
[22:50] <wallyworld_> sodre: actually
[22:50] <wallyworld_> not tools-url
[22:51] <wallyworld_> you want image-metadata-url for images
[22:51] <wallyworld_> i think that's what it can't find
[22:51] <wallyworld_> if it complains about tools, you need tools-url
[22:52] <thumper> Time to go and hit something, more emails after lunch
[22:52]  * thumper -> gym
[22:52] <sodre> okay.
[22:56] <sodre> humm... not yet...
[22:57] <sodre> I'll play with it once I get home.
[22:57] <sodre> ttyl
[22:59] <sinzui> wallyworld_, do you understand what went wrong in this azure bootstrap. I see evidence that abentley's CI testing has placed current tools in juju-dist/testing/tools, but I don't see how out environments could collide and break: http://pastebin.ubuntu.com/6326844/
[23:00]  * wallyworld_ looks
[23:04] <wallyworld_> sinzui: i've not seen that error before. it looks like it is failing to load image metadata from cloud-images.canonical.com
[23:04]  * sinzui ponders setting image-metadata-url: http://cloud-images.ubuntu.com/releases
[23:04] <wallyworld_> that may work, let me check the code
[23:04] <sinzui> wallyworld_, okay. I think so too. I am not testing changes yet :) This was a stable deploy for an upgrade test
[23:06] <wallyworld_> sinzui: btw, trunk has all the changes except for the --public option with sync tools (but you can create the json file for that by hand in the interim). i hope to land today in any case
[23:06] <sinzui> okay
[23:07] <sinzui> wallyworld_, I was starting the blessing/cursing of 1.16 r1977. Once the stable is updated, I was going to return to automate releases
[23:07] <wallyworld_> rightio
[23:07] <sinzui> damn. image-metadata-url did change anything
[23:08] <wallyworld_> did not?
[23:09] <sinzui> hmm, maybe the sjson is the issue
[23:09] <sinzui> 1.16 shouldn't be looking at it yet
[23:10] <sinzui> well there is evidence that the sjson is understood, but I don't think it is 100% vetted
[23:11] <wallyworld_> 1.16 should use sjson if it is there
[23:11] <adam_g> does anyone know what the status of the juju side of https://bugs.launchpad.net/maas/+bug/1239488 ?
[23:11] <_mup_> Bug #1239488: [SRU] Juju api client cannot distinguish between environments <verification-done> <MAAS:Fix Released by julian-edwards> <maas (Ubuntu):Triaged> <maas (Ubuntu Saucy):Fix Committed> <https://launchpad.net/bugs/1239488>
[23:13] <wallyworld_> sinzui: the above bug will be fixed with the 1.16 release you are doing now, right?
[23:14] <sinzui> I don't think so wallyworld_ The bug does not claim to affect juju, let alone have a bug targeted to the 1.16.1 release
[23:14] <sinzui> These are the bug fixes we want to close https://launchpad.net/juju-core/+milestone/1.16.1
[23:15] <wallyworld_> there were juju changes to fix that maas env bug
[23:15] <adam_g> sinzui, i was told there was a corresponding juju change for the multi-tenant usage to actually work, have not been able to find what that buig is, tho
[23:15] <wallyworld_> bigjools: ^^^^^?
[23:15] <wallyworld_> you made changes to juju-core right?
[23:16] <bigjools> yes
[23:16] <wallyworld_> was the branch linked to a bug?
[23:16]  * bigjools digs
[23:16] <adam_g> are those released ?
[23:16] <wallyworld_> not yet i don't think
[23:17] <bigjools> https://bugs.launchpad.net/juju/+bug/1081247
[23:17] <_mup_> Bug #1081247: maas provider releases all nodes it did not allocate [does not play well with others] <maas-provider> <pyjuju:Triaged> <juju-core:Fix Committed by julian-edwards> <juju-core 1.16:Fix Committed by rogpeppe> <MAAS:Invalid> <https://launchpad.net/bugs/1081247>
[23:17] <adam_g> bigjools, thanks
[23:17] <bigjools> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1229275
[23:17] <_mup_> Bug #1229275: [maas] juju destroy-environment also destroys nodes that are not controlled by juju <maas-provider> <theme-oil> <pyjuju:Triaged> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Committed by rogpeppe> <juju-core (Ubuntu):Triaged> <maas (Ubuntu):Triaged> <juju-core (Ubuntu Saucy):Triaged> <maas (Ubuntu Saucy):Triaged> <https://launchpad.net/bugs/1229275>
[23:17] <bigjools> also that, but it has the same branches linked
[23:20] <adam_g> sinzui, when is 1.16.1 due?
[23:22] <wallyworld_> bigjools: that bug is against the wrong projevt
[23:23] <wallyworld_> that may be why sinzui  didn't see it
[23:23] <bigjools> wallyworld_: ha!
[23:23] <wallyworld_> to include it for the next 1.16 release
[23:23] <bigjools> wallyworld_: it does have a juju-core task
[23:23] <wallyworld_> oh, so it does
[23:23] <bigjools> I invalidated pyjuju
[23:24] <bigjools> does this url make you feel better? https://bugs.launchpad.net/juju-core/+bug/1081247
[23:24] <_mup_> Bug #1081247: maas provider releases all nodes it did not allocate [does not play well with others] <maas-provider> <pyjuju:Invalid> <juju-core:Fix Committed by julian-edwards> <juju-core 1.16:Fix Committed by rogpeppe> <MAAS:Invalid> <https://launchpad.net/bugs/1081247>
[23:24] <wallyworld_> yes :-)
[23:24]  * wallyworld_ relocates, bbiab
[23:24]  * bigjools prepares for his arrival
[23:25]  * bigjools chuckles, evilly
[23:27] <sinzui> sorry bigjools wallyworld_ I had to jump into a hangout.
[23:27] <bigjools> no worries sinzui
[23:27] <sinzui> I am not rushing the 1.16.1 release. I can wait for a critical bug fix. I just need to know what needs merging