14:01:32 <mvollmer> #startmeeting
14:01:32 <zodbot> Meeting started Mon Mar 16 14:01:32 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:40 <andreasn_> mvollmer: sounds good, I'm having connection issues
14:01:42 <andreasn_> .hello andreasn
14:01:43 <zodbot> andreasn_: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:01:46 <mvollmer> .hello mvo
14:01:48 <dperpeet> .hello dperpeet
14:01:49 <stefw> .hello
14:01:49 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:01:52 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
14:01:53 <mvollmer> #topic Agenda
14:01:54 <zodbot> stefw: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
14:02:03 <jscotka> dperpeet, do you have some issue with that, should it be bigger or smaller?
14:02:16 <mvollmer> * New test infra merged
14:02:31 <dperpeet> jscotka, it was too big for my vm. I'll work it out, thanks.
14:02:34 <stefw> * GZIP compression and preferring non-minified resources
14:02:44 <stefw> * Reauthorization using a second login
14:02:44 <dperpeet> * Fedora 22
14:02:45 <mvollmer> * Oustanding metric PRs
14:02:57 <andreasn_> * iSCSI progress
14:02:58 <stefw> * Test day
14:03:01 <jscotka> dperpeet, ah, okay
14:03:37 <mvollmer> let's start, ok?
14:03:44 <andreasn_> sure
14:03:58 <mvollmer> #topic New test infra merged
14:04:02 <mvollmer> yay!
14:04:04 <mvollmer> :-)
14:04:05 <stefw> yay
14:04:08 <stefw> (!)
14:04:13 <mvollmer> so, now we have to live with it.
14:04:21 <andreasn_> \o/
14:04:49 <mvollmer> i am turning into a (bad) FreeIPA sysadmin...
14:05:21 <jscotka> perfect, mvollmer good job, thanks for lots of rewriting
14:05:30 <mvollmer> The FreeIPA server VM had some issues with its network, not sure about those...
14:05:44 <stefw> so do i understand right that jscotka is still running these new tests in the same way as the older ones?
14:05:51 <stefw> as one big script?
14:05:53 <stefw> no benefit yet?
14:05:58 <stefw> but that'll come shortly?
14:06:18 <mvollmer> jscotka, can you clarify?
14:06:27 <jscotka> stefw, yes, now it is running on similar infrastruture.
14:06:47 <mvollmer> jscotka, my understanding is that you just run ./test-avocado/run" on bare metal, very much what we do via hubbut.
14:06:57 <jscotka> benefit is, that now these test are ready to run everywhere
14:07:25 <stefw> ah ok, so you do run schedule them on a cluster individually
14:07:30 <jscotka> mvollmer, more less
14:07:34 <stefw> rather than just as a big shell script?
14:07:57 <jscotka> the most imporatnt part is that it is easy to rewrite "run" script for another environment
14:08:05 <stefw> aha
14:09:00 <jscotka> run script is now manages guest and other not so important stuff, what will be solved externally, and in "run" part could be only avocado run command
14:09:08 <mvollmer> I'd like to mention one open issue: screenshots and journals are hard to find now.
14:09:18 <mvollmer> but they are there.
14:09:23 <mvollmer> just no direct link.
14:09:34 <mvollmer> I tyoing with the idea of creating our own HTML report.
14:09:54 <stefw> yeah, that would be cool
14:10:04 <mvollmer> that shouldn't be difficult in principle, but it'll take some time that is better spend elsewhere now
14:10:04 <stefw> probably worth doing after we finish up the big items for Fedora 22, no?
14:10:14 <mvollmer> yeah
14:10:29 <jscotka> mvollmer, ideally via some transformation of XML via XSLT tepplate?
14:10:38 <mvollmer> the golden solution would of course be to improve the stock avocado report.
14:10:53 <mvollmer> jscotka, I dont think I want to touch that.
14:11:03 <mvollmer> just some python that reads the XML.
14:11:07 <jscotka> mvollmer, understand
14:11:09 <mvollmer> and maybe some files.
14:11:42 <mvollmer> so, what happens next with this?
14:11:43 <jscotka> mvollmer, yep, we can use Xunit output and add own links for example
14:11:50 <mvollmer> jscotka, are you porting more tests now?
14:11:57 <mvollmer> storage and network would be interesting
14:12:16 <jscotka> mvollmer, no, now I have plan to create library for add fake disc and NICs
14:12:22 <stefw> storage is most interesting, imo
14:12:23 <github> [cockpit] Armstrong1992 opened pull request #1921: Polish translations - Wip (master...master) http://git.io/hTef
14:12:25 <stefw> because we need to port that soon
14:12:42 <stefw> actually, that was a dumb observation of mine
14:12:45 <stefw> strike it from the record
14:12:50 <stefw> we already have a test covering storage
14:12:56 <jscotka> stefw, I have plan to do some general library to simulate these parts
14:13:23 <mvollmer> stefw, you mean the old test?
14:13:28 <stefw> yeah
14:13:39 <jscotka> stefw, I hope that it will be ready in 14 days. some general library, and then I can port storage tests
14:14:06 <mvollmer> ok, sounds good.
14:14:39 <mvollmer> jscotka, what about specifying the disks as some parameter to the tests`
14:14:41 <mvollmer> ?
14:14:48 <mvollmer> like we specify the IPA domain now?
14:15:20 <mvollmer> in other words, faking the disks wouldn't be part of the test setup, but part of the environment creation.
14:15:31 <mvollmer> is that the plan?
14:15:36 <jscotka> mvollmer, could be, but it needs more setup in "run" script, and then it is not easy to port this test to another environment
14:15:59 <jscotka> mvollmer, test itself uses some lib which create new disc for itself
14:16:08 <mvollmer> but it might be more meaningful
14:16:26 <mvollmer> when you can run the storage test on differenta hardware raids, say.
14:16:33 <jscotka> mvollmer, so my plan is have it in disc test, not as part of environment
14:16:41 <mvollmer> don't know, you have the experience.
14:17:13 <jscotka> mvollmer, yes, it could be, but it will be another test, what will work only somewhere, not everywhere
14:17:26 <mvollmer> yep
14:17:38 <mvollmer> ok, should we wrap up?
14:17:46 <stefw> y
14:17:54 <jscotka> yes
14:18:05 <mvollmer> I am watching the tests, strange things are happening, but mostly because I don't know enough...
14:18:35 <mvollmer> e.g., there is both named.service and named-pkXXX.service (for DNSSEC), and I was only looking at the former
14:18:58 <mvollmer> and was confused why it was masked, but that was ok, since the other was running, but I didn't see that, etc.
14:19:16 <mvollmer> ok.
14:19:17 <jscotka> mvollmer, it is probably freeIPA magic
14:19:39 <mvollmer> #topic GZIP compression and preferring non-minified resources
14:19:57 <stefw> I've posted a branch where we start to gzip the installed resources
14:20:02 <stefw> such as javascript, fonts ... so far
14:20:08 <stefw> and it reduces the size of the load drastically
14:20:25 <stefw> but more importantly, i wanted to highlight the differences in how the package file loading works
14:20:41 <stefw> if a non-minified, non-gzipped version of a resource is present, it is used
14:20:50 <stefw> and the gzipped or minified versions are ignored
14:21:14 <stefw> i've updated cockpit.spec in that branch, to put such data in the cockpit-debuginfo package
14:21:31 <stefw> so for general users, they can install that to make the sources meaningful (at the expense of data transfer, etc.)
14:21:49 <stefw> is this okay with everyone?
14:22:06 <stefw> in particular the presense of something in ~/.local/share/cockpit has no effect on whether minified vs. non-minified is used
14:22:35 <mvollmer> a normal "make install" installs both?
14:22:38 <stefw> yes
14:22:42 <mvollmer> ok
14:22:45 <stefw> you can do this to avoid that:
14:22:52 <stefw> make install DBGDIR=/tmp/marmalade
14:22:59 <stefw> or whatever, to put the debug files in a different directory
14:23:05 <mvollmer> right
14:23:12 <mvollmer> sounds good to me
14:23:18 <andreasn_> no objections
14:23:32 <stefw> as usual, this is all documented
14:23:32 <stefw> https://github.com/stefwalter/cockpit/blob/gzip-compression/doc/guide/packages.xml#L157
14:23:48 <stefw> there is also a bit of a tweak with regards to language negotiation coming for all of this
14:24:03 <stefw> and part of the work is in that branch
14:24:07 <stefw> you can see it in the docs
14:24:10 <stefw> linked above
14:24:12 <stefw> #info https://github.com/stefwalter/cockpit/blob/gzip-compression/doc/guide/packages.xml#L157
14:25:04 <stefw> that's it from me on that
14:25:05 <petervo> should we perfer gz to min?
14:25:11 <petervo> prefer*
14:25:18 <stefw> it's a good question
14:25:24 <stefw> i've generally preferred more readable files
14:25:37 <stefw> as i think those will be the ones that someone is going to be touching with their grubby fingers
14:25:50 <stefw> but i've not installed .min.js and .min.js.gz at the same time
14:26:13 <stefw> so this ends up being a theoretical question
14:26:21 <stefw> at least that's how i understand it.
14:26:23 <dperpeet> is there a chance distributing non-minified versions will help us get better bug reports?
14:26:31 <stefw> yes
14:26:46 <stefw> we could require cockpit-debuginfo for unstable builds perhaps?
14:26:54 <stefw> it would also slow things down though
14:26:54 <dperpeet> that would be helpful I think
14:27:03 <dperpeet> if people want bleeding edge, we want proper bug reports in return
14:27:13 <stefw> yeah, not a bad idea
14:27:19 <stefw> will look into that later
14:27:43 <stefw> in addition, remember that the cockpit-debuginfo package installs non-minified versions of *everything*
14:27:50 <stefw> even packages the user wouldn't otherwise have installed
14:27:57 <stefw> but it's a decent tradeoff i think
14:28:00 <stefw> rather than having N*2 packages
14:28:03 <mvollmer> yep
14:28:04 <dperpeet> acceptable
14:28:12 <stefw> the manifest.json ones only come in the non-debug packages
14:28:16 <stefw> s/ones/files/
14:28:26 <stefw> so the extra files are inactive
14:28:40 <stefw> k, that's it from me on that
14:29:25 <andreasn_> next topic?
14:29:39 <stefw> y
14:30:07 <mvollmer> yep
14:30:20 <mvollmer> #topic Reauthorization using a second login
14:30:39 <stefw> so i think this is important for the Fedora 22 protocol stability
14:30:48 <stefw> going forward, we want to support things like SSH public key authentication
14:30:58 <stefw> the current polkit reauthorization scheme cannot support this:
14:31:04 <stefw> https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
14:31:14 <stefw> for a while i've been thinking of a simpler version:
14:31:33 <stefw> https://github.com/cockpit-project/cockpit/pull/1917/files#diff-e2bf95bcddab07aadd9501e5d439a1fcR9
14:31:57 <stefw> basically when we need to prove to polkit (or sudo in the future) that the user is still valid, credentials still good, still present
14:32:04 <stefw> we do another login, whether via ssh or cockpit-session
14:32:16 <stefw> and that is used to reauthorize the user on the first session
14:32:36 <stefw> in theory this works with any type authentication
14:33:01 <stefw> as requested, i've documented how it would work
14:33:10 <stefw> and doing a bit of work on this today
14:33:12 <mvollmer> so the second login wouldn't run the bridge, but some other program?
14:33:24 <stefw> in theory it could run /usr/bin/true
14:33:30 <mvollmer> ahh, ok.
14:33:37 <stefw> although i was thinking perhaps 'cockpit-bridge --poke' would be less failure prone?
14:33:49 <mvollmer> hmm.
14:33:50 <stefw> or maybe /bin/sh -c "exit 0"
14:33:54 <stefw> would be best
14:34:18 <stefw> the magic happens in the pam stack
14:34:20 <mvollmer> my first thought was that the second login would actually run some code that signals back to the other session.
14:34:26 <stefw> yeah, that would be nice
14:34:28 <stefw> except it doesn't work
14:34:34 <stefw> because the code that does the signal needs to be root
14:34:58 <stefw> so the code runs in the pam stack
14:35:02 <mvollmer> right
14:35:02 <stefw> of either sshd or cockpit-session
14:35:25 <stefw> but mvollmer ... that does give me an idea
14:35:29 <stefw> of how this could be even simpler :)
14:35:32 <stefw> let me see ...
14:35:38 <mvollmer> otherwise it wouldn't really be a proof that this is a fresh login, right?
14:35:43 <stefw> mvollmer, exactly
14:35:52 <stefw> in fact things are already a bit tricky with sshd
14:36:00 <stefw> given the fact that you can run multiple sessions over a single authenticated sshd session
14:36:17 <stefw> you have to do things like using getenv("SSH_CONNECTION") to identify new auths/connections
14:36:24 <stefw> if you're in PAM_SERVICE 'sshd'
14:37:14 <stefw> at some point some of these relogins need to be threaded back through index.js
14:37:31 <stefw> and cause a /login in a hidden frame (eg: for browser GSSAPI to run)
14:37:39 <stefw> but i would like to just get the protocol bits worked out at this point
14:37:48 <stefw> anyway, all of this is a bit risky as far as:
14:37:49 <stefw> * time spent
14:37:57 <stefw> * changing security stuff so late before a release
14:38:19 <stefw> * not finishing the task completely (eg: SSH public key auth) and finding it doesn't work later
14:38:27 <mvollmer> yeah
14:38:57 <dperpeet> stefw, do you have a rough estimate for how it would take to finish up the task?
14:38:59 <mvollmer> the price to keep the old ways is that we need to keep some code in cockpit-ws?
14:39:21 <stefw> mvollmer, yes ... maybe not so bad?
14:39:22 * mvollmer doesn't have a very good picture of how this all works right now, unfortunately.
14:39:34 <mvollmer> stefw, no, that wouldn't be bad.
14:39:57 <stefw> dperpeet, depends what kind of scope
14:40:02 <stefw> ie: finish up SSH public key auth is a big task
14:40:05 <stefw> including UI
14:40:06 <stefw> etc.
14:40:09 <dperpeet> definitely with that
14:40:12 <dperpeet> 2-3weeks?
14:40:15 <stefw> yeah, likely
14:40:25 <stefw> 2-5 weeks
14:40:29 <stefw> lower upper bound
14:40:38 <dperpeet> then that pretty much ends the discussion: not reasonable for F22
14:40:54 <stefw> well ... so the idea was to do the minimal amount of work (not SSH public key reauth)
14:40:59 <stefw> er s/reauth/auth/
14:41:12 <stefw> but just the new reauthorization bit, which is the part that breaks the protocol
14:41:20 <stefw> which would take a lot less time
14:41:23 <stefw> but is risky
14:41:23 <dperpeet> but we would need to be sure it could work with ssh public key reauth eventually
14:41:30 <stefw> exactly
14:41:48 <dperpeet> spending a lot of time now to get it working... only to have to change it again is very risky
14:41:52 <stefw> indeed
14:42:22 <stefw> mvollmer, actually i think it's just this function
14:42:23 <stefw> https://github.com/cockpit-project/cockpit/blob/master/src/reauthorize/reauthorize.c#L733
14:42:27 <stefw> that would need to be kept on lifesupport
14:42:34 <stefw> and we could move it into src/ws/ somewhere
14:42:43 <stefw> if we supported both old/new
14:42:59 <mvollmer> right
14:43:02 <stefw> the "authorize" command in the protocol is designed so it can handle different kinds of reauthorization
14:43:26 <stefw> and this: https://github.com/cockpit-project/cockpit/blob/master/src/reauthorize/reauthorize.c#L200
14:43:26 <mvollmer> we don't have any known bugs with the current scheme, right?
14:43:28 <stefw> parse_salt()
14:43:31 <stefw> no
14:43:35 <stefw> it's been reviewed as well
14:43:37 <stefw> by security guys
14:43:38 <dperpeet> with more testing coming up, this might be a good "project" to be improved continuously as a wIP
14:44:07 <stefw> so talking through thish, i'm becoming convinced we should punt on this until later
14:44:26 <mvollmer> yeah, I would say it's a "nice to have" item for F22, but we can deliver it when it's ready.
14:44:38 <petervo> does that mean we back off the stable protocol guarantee
14:44:47 <stefw> i think it just means we carry more code around
14:44:49 <stefw> in order to keep that guarantee
14:45:10 <petervo> isn't that risky as well
14:45:24 <stefw> it *does* mean that if you use a new cockpit-ws against an old cockpit-bridge with public key auth
14:45:26 <stefw> then reauthorization would f ail
14:45:38 <stefw> just as it does now, except for we would have a UI that seemed to support public key auth, until it failed
14:45:55 <stefw> but i guess we need to check about capabilities of the bridge in the "init" protocol message
14:45:57 <stefw> and error out in that case
14:46:24 <dperpeet> I have to leave in about 5 minutes
14:46:33 <stefw> we can move to next point
14:46:52 <mvollmer> petervo, I think we can even require people to update within F22.
14:47:10 <stefw> i don't think that would be good
14:47:20 <andreasn_> #topic Fedora 22
14:47:25 <mvollmer> :)
14:47:41 <andreasn_> sorry, but had to hurry up since dperpeet is leaving soon
14:47:50 <dperpeet> last week we pushed talk about this to this week I believe
14:47:55 <mvollmer> oh, good, I missed that.
14:48:05 <dperpeet> I set up a F22 label on github: https://github.com/cockpit-project/cockpit/labels/Fedora22
14:48:25 <dperpeet> since we were abusing the stabilization milestone as a placeholder for that
14:48:47 <dperpeet> I'll sort through bugzilla issues a bit (started with stefw today) and add more issues
14:49:10 <andreasn_> I've e-mailed Ryan Lerch from Fedora to see if there is anything about the branding that needs changing for F22
14:49:24 <dperpeet> since subscriptions are merged and testing should be added for that soon as well, I will focus on issue triage and fixing things
14:49:40 <stefw> cool. anything you want people to do to propose stuff for Fedora22?
14:49:42 <stefw> just label it?
14:49:46 <dperpeet> if you see an issue that you think needs to be fixed for F22, don't hesitate to label it
14:49:54 * stefw sits back down
14:49:58 <dperpeet> :)
14:50:31 <mvollmer> right
14:50:36 <dperpeet> other than that I think we should do some looking at issues
14:50:43 <dperpeet> stefw has been volunteered for thatr
14:50:45 <mvollmer> i guess I need to move the tests to F22 sooner than later,
14:50:57 <stefw> yeah
14:51:08 <mvollmer> one last time the old way...
14:51:22 <stefw> i went through Fedora bugzilla and triaged all the issues, assigning stuff, commenting etc.
14:51:26 <andreasn_> so, subscriptions are obviosly not needed for fedora. That's it's own package that doesn't get installed on F22, right?
14:51:44 <andreasn_> so it doesn't show up in the menu etc
14:51:48 <dperpeet> technically anyone can use this for their product
14:51:49 <stefw> it's optional
14:51:52 <andreasn_> good
14:51:55 <stefw> you can install it if you want
14:51:56 <dperpeet> but it won't have a big impact
14:52:18 <andreasn_> right, just wanted to make sure it doesn't show up in the standard install
14:52:32 <andreasn_> by default
14:52:40 <andreasn_> cool
14:52:40 <stefw> it does on RHEL builds
14:52:50 <dperpeet> that's it from me on F22
14:52:51 <stefw> which you can get here: https://copr.fedoraproject.org/coprs/sgallagh/cockpit-preview/
14:52:57 <andreasn_> stefw: right, excellent
14:53:09 <dperpeet> we'll know more once the issues have been sorted a bit
14:53:12 * stefw suggests bumping "Test day" from the agenda
14:53:18 <stefw> until next time when dperpeet will be around
14:53:20 <mvollmer> ok
14:53:25 <dperpeet> I have to leave, sorry
14:53:29 <stefw> np
14:53:29 <andreasn_> later!
14:53:35 <mvollmer> o/
14:53:36 <dperpeet> bye
14:53:49 <mvollmer> #topic Oustanding metric PRs
14:54:07 <mvollmer> i have neglected them a bit...
14:54:13 <mvollmer> Should we have them in F22?
14:54:29 <andreasn_> it would be nice. How much time do we have?
14:54:31 <stefw> we should have graphs that work
14:54:36 <stefw> that's the minimum
14:54:42 <mvollmer> they make the graphs zoomable, use archives on the #server page, and switch the archives on/off.
14:54:54 <stefw> does your work on metrics-internal depend on this stuff?
14:55:06 <mvollmer> we have graphs, with poor archive control right now.
14:55:19 <stefw> including reworking other graphs to use the new metrics channel
14:55:22 <stefw> rather than cockpitd?
14:55:24 <mvollmer> stefw, I think not.
14:55:34 <stefw> because we can easily deliver this stuff in Fedora 22 as an update
14:55:51 <stefw> but the basic functionality of having all graphs work (even if some continue to use cockpitd) is important.
14:56:14 <mvollmer> i think the current zooming UI is too poor, actually.
14:56:22 <mvollmer> andreasn_, what do you think?
14:56:29 <andreasn_> mvollmer: too poor how?
14:56:44 <andreasn_> I'm fairly happy with it's current state
14:56:59 <mvollmer> it's the button bar with "1 week, 1 day, ... , 5 minutes" and < >.
14:57:20 <mvollmer> ahh, current = master
14:57:26 <andreasn_> ah, right
14:57:28 <mvollmer> metrics-zoom is pretty good.
14:57:38 <andreasn_> yeah, it was metrics-zoom I was thinking about
14:57:45 <andreasn_> master is not excellent compared to that
14:58:20 <mvollmer> stefw, found one issue: zomming in after reaching the minimum is very confusing.
14:58:35 <mvollmer> but that can be fixed easily, I think.
14:58:56 <mvollmer> so my vote is to finish metrics-zoom.
14:58:58 <stefw> well if it helps with finishing up the metrics-internal work
14:59:03 <stefw> then yeah i would suggest going for it
14:59:07 <andreasn_> right
14:59:34 <andreasn_> if we can get https://github.com/cockpit-project/cockpit/pull/1834 into F22 that would be cool too, but not the end of the world if it doesn't
14:59:35 <mvollmer> metrics-internal wont have archives, so these controls will not be shown for non-pcp graphs.
14:59:44 <andreasn_> right
14:59:52 <stefw> yeah, but the point is that metrics-internal is on the list of things that should be done for Fedora 22
14:59:55 <stefw> the other graphs stuff is not
15:00:09 <mvollmer> yep
15:00:22 <stefw> but sometimes you have intermingled commits, branches, etc... and it turns out that finish up the latter, would help with the former ....
15:00:22 <mvollmer> switching pmlogger on/off could be dropped.
15:00:24 <stefw> so you would know best
15:00:59 <andreasn_> will pmlogger and friends be installed by default on F22?
15:01:04 <stefw> no
15:01:13 <mvollmer> rebasing the pcp stuff on top of the internal stuff would be some work, but reasonable.
15:03:01 <mvollmer> ok, my recommendation is to merge #1816 (better zoom UI for those that enable pcp), but not to merge #1834 and #1839.
15:03:26 <andreasn_> makes sense
15:03:28 <stefw> makes sense
15:03:34 <mvollmer> #1834 is pcp for #server, and #1839 is pmlogger on/off.
15:03:42 <mvollmer> ok!
15:04:31 <andreasn_> next topic?
15:04:34 <stefw> yup
15:04:35 <mvollmer> #topic * iSCSI progress
15:04:47 <andreasn_> we're a bit over time, but that's probably ok
15:04:56 <stefw> fine with me
15:05:37 <andreasn_> ok, so short update on this. Met with Fabian and discussed late last week. Added some prior art to the wiki page and will create some mockups today or tomorrow
15:05:55 <andreasn_> if we can get this one right, it's a big win, because it's fairly painful to set up
15:06:11 <andreasn_> even more painful to set up a iscsi target, so maybe he'll work on that next :)
15:06:21 <andreasn_> so moving forward basically
15:06:23 <andreasn_> next?
15:06:40 <stefw> very cool
15:06:47 <andreasn_> oh, and he also had some updates about some dbus bindings of something that he wanted to share
15:07:05 <jscotka> mvollmer, andreasn_ I'll do that as part of testing process (simulation of devices (I'll create iSCSI targets))
15:07:14 <andreasn_> jscotka: excellent!
15:08:02 <mvollmer> #topic Open Floor
15:08:38 * stefw will work on fridex's bugs when i get a chance
15:08:51 <andreasn_> so last week hugsie from GNOME did a demo of easy firmware updates
15:09:08 <andreasn_> and some suggested Cockpit could have support for that too at some point
15:09:19 <andreasn_> so I promised to file an issue with more details
15:09:35 <andreasn_> but said that it probably wouldn't be on the roadmap anytime soon
15:10:03 <andreasn_> more info here https://github.com/hughsie/fwupd/blob/master/README.md
15:10:39 <mvollmer> it could be a external tool.
15:11:24 <stefw> yeah
15:11:33 <mvollmer> ok, all done?
15:11:37 <andreasn_> I think so, yeah
15:11:41 * mvollmer looks around the table
15:11:52 <petervo> it's based on appstream, so when / if we get all those dependency issues resolved it could be a possibility
15:12:08 <andreasn_> right
15:12:38 <mvollmer> i see this more as a general "does Fedora Server want this" question.
15:12:50 <mvollmer> once Fedora Server can do it, we can put a UI on top.
15:12:57 <andreasn_> yeah, I agree
15:13:03 <mvollmer> but I don't see us fighting all the dependency battles
15:13:19 <andreasn_> yeah
15:13:19 <stefw> i'll probably bring up the general software installation issue once Fedora 22 lands
15:13:27 <stefw> or rather 'maintenence free' updates issue
15:13:59 <andreasn_> package browsing, or just getting updates for whatever is installed?
15:14:23 <andreasn_> browsing/installation/uninstallation
15:14:47 <stefw> well, installation doesn't have the show stoppers that updates do
15:14:58 <stefw> because you can just yum install new stuff
15:15:01 <stefw> updating is the hard part
15:15:09 <stefw> that is, even if PackageKit drops the server case
15:15:31 <stefw> andreasn_, anyway if you talk to hughsie
15:15:46 <stefw> you need to remind him that we can't use PackageKit as is
15:15:54 <stefw> due to the dependencies
15:16:01 <andreasn_> what dependencies is it?
15:16:22 <andreasn_> that hurts us the most
15:16:24 <mvollmer> ok, let's end the meeting.
15:16:26 <stefw> libgdk_pixbuf-2.0.so.0
15:16:28 <mvollmer> #endmeeting