14:02:13 <mvollmer> #startmeeting Weekly Meeting
14:02:13 <zodbot> Meeting started Mon Oct 31 14:02:13 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:13 <zodbot> The meeting name has been set to 'weekly_meeting'
14:02:19 <mvollmer> .hello mvo
14:02:20 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:02:34 <mvollmer> #topic Agenda
14:02:39 <mvollmer> * UDisks2
14:03:38 <stefw> * Debian and Ubuntu
14:06:12 <mvollmer> alright, let's start :-)
14:06:37 <mvollmer> let's do Debian and Ubuntu first, I think that will lead to UDisks
14:06:41 <sgallagh> /me lurks
14:06:50 <mvollmer> #topic Debian and Ubuntu
14:08:01 <stefw> ok, so as part of the goal
14:08:06 <stefw> "Actually Deliver Cockpit"
14:08:24 <stefw> i've been steadily chewing away on things related to Debian and Ubuntu
14:08:34 <stefw> that includes, as mvollmer said, the Udisks support
14:08:48 <stefw> building the network manager stuff
14:08:54 <stefw> actually running the tests more broadly
14:09:02 <stefw> and running all the integration tests on ubuntu 16.04
14:09:14 <stefw> i've also interacted with some would be packagers, about the Node build dependencies
14:09:40 <stefw> One of the suggestions that came up is to package the Node build dependencies in a separate tarball
14:10:01 <stefw> I'd be amennable to that, as long as our other packagers, such as RHEL and Fedora are okay with it too.
14:10:33 <stefw> To clarify ... we've been over the point before that the inclusion of node_modules/ is similar to the inclusion of an autotools m4/ directory
14:10:42 <stefw> or a configure file
14:11:00 <stefw> these are predigested, included, tools that facilitate building the tarball
14:11:09 <mvollmer> (except way bigger?)
14:11:13 <stefw> yup
14:11:27 <mvollmer> i like that way of looking at it
14:12:02 <dperpeet> as long as we package them, so that downstream packagers have all the stuff they need to build the packages without pulling from online sources, I'm ok with this
14:12:18 <stefw> dperpeet, that's related to the two tarballs instead of one, right?
14:12:23 <dperpeet> yes
14:12:35 <stefw> and would i include dist/ and node_modules/ in the second tarball?
14:12:38 <mvollmer> would we allow the distro to override some of the tools?
14:12:53 <stefw> mvollmer, in package.json and bower.json
14:13:00 <mvollmer> i.e., it's in our tarball, but during build the one from a Debian package is actually used
14:13:01 <stefw> i've made sure to lock down the versions quite tightly
14:13:14 <stefw> if they want to override and diverge from the versions
14:13:21 <stefw> then either they can:
14:13:34 <stefw> a) talk with upstream and get us to change the version number, so we can test it properly
14:13:35 <stefw> or
14:13:38 <stefw> b) keep both pieces
14:13:52 <stefw> ie: when it breaks, keep both pieces
14:14:09 <mvollmer> yeah
14:14:19 <dperpeet> stefw, if we don't include node_modules, we might not be able to reproduce the build results, right?
14:14:31 <stefw> RHEL doesn't include nodejs
14:14:39 <stefw> so it won't make use of node_modules
14:14:41 <stefw> it'll make use of dist/
14:14:53 <stefw> so very likely we should continue to include dist/ in our original tarball
14:15:01 <dperpeet> well, I listed one en lieu of writing both
14:15:10 <dperpeet> I think dist would be ok
14:15:11 <stefw> and perhaps include node_modules/ and lib/*/ in the other tarball
14:15:43 <stefw> in other words ... one should be able to configure && make with the main tarball
14:16:06 <stefw> but if you want to 'make clean' or apply a patch that needs rebuilding of some parts of the javascript ... then you'll either need the second tarball
14:16:14 <dperpeet> yes
14:16:17 <dperpeet> that sounds right
14:16:19 <stefw> or you'll need to pull the deps from npm and/or bower again
14:16:32 <dperpeet> configure + make working with just the main tarball is a good bar
14:16:34 <dperpeet> do we test that?
14:16:35 <mvollmer> (nitpick: make clean should work, no?)
14:16:48 <stefw> mvollmer, not on a system that doesn't have nodejs, no
14:17:02 <stefw> it deletes stuff that is distributed in the tarball
14:17:09 <mvollmer> i mean, that's the "API": make clean goes back to after configure
14:17:12 <stefw> and needs nodejs to regenerate itself
14:17:18 <mvollmer> make distclean goes back to after untar
14:17:31 <stefw> yeah, sadly that's been poluted by the idea that code comes from git
14:17:34 <mvollmer> make maintainer-clean goes back further
14:17:38 <stefw> and there are two distinct 'make' workflows
14:17:51 <stefw> but if we want to get all fancy, i'm not against patches that make what you describe happen
14:17:52 <mvollmer> right
14:18:04 <mvollmer> yeah, I am not sure I care enough, actually. :-)
14:18:07 <stefw> after merging such a patch, we can post on cockpit-devel to make sure it's clear
14:19:38 <stefw> so are we good on this? I think it's a fail that we didn't more aggressively package for Debian and/or Ubuntu earlier
14:19:43 <stefw> oh one more thing about Debian
14:19:51 <stefw> people have been complaining that our Debian repository is hosted with https
14:19:58 <stefw> and Debian doesn't have support for that by default
14:20:05 <stefw> https://github.com/cockpit-project/cockpit/issues/5275
14:20:24 <stefw> so i've put the repo in another location hosted by the Openshift cloud
14:20:38 <stefw> and i've produced patches to our release scripts
14:20:40 <stefw> to push there
14:20:46 <stefw> https://github.com/cockpit-project/cockpit/issues/5275#issuecomment-257247018
14:20:49 <stefw> any objections?
14:21:05 <stefw> you can see the changed line here: https://github.com/cockpit-project/cockpit-project.github.io/pull/48/files
14:21:16 <stefw> i continue to push to both, so people with the old line will continue to work
14:21:39 <mvollmer> sounds good to me
14:21:56 <dperpeet> sounds good, I'll review
14:22:21 <petervo> installing software without https seems really sketchy
14:22:29 <stefw> yeah except its signed
14:22:33 <stefw> what actually is sketchy
14:22:38 <stefw> is the fact that we document the key id
14:22:41 <stefw> on a non-https page
14:22:44 <dperpeet> :D
14:22:44 <stefw> so that's the next thing we need to fix
14:22:51 <stefw> http://cockpit-project.org/running.html
14:22:55 <stefw> we need that to be https hosted
14:23:11 <stefw> should we talk about that later though? perhaps a bit off topic? I do have one more Debian related topic
14:23:26 <mvollmer> yes, please
14:23:40 <stefw> I'd like to target Debian Jessie
14:23:51 <stefw> by our tests and our repo
14:23:55 <stefw> if it is possible
14:23:58 <stefw> has anyone tried, and given up?
14:24:34 <stefw> because this is about making this useful to real users ... and until we have it actually included in debian, i'd like to target what users are actually running
14:24:45 <stefw> not what they're going to be running next
14:25:16 <mvollmer> back then I started with debian 8
14:25:36 <mvollmer> and then switched to unstable along the way when it become clear that this is what we target first
14:25:50 <stefw> right, it's not bad to test against debian-unstable (too?)
14:25:53 <mvollmer> jessie is 8?
14:25:56 <stefw> yup
14:25:58 <stefw> 8.6 currently
14:26:15 <mvollmer> no, we should test both
14:26:27 <mvollmer> or "testing"
14:26:52 <dperpeet> I think our biggest issue was with storaged vs udisks
14:26:57 <dperpeet> but that seems less of a problem now
14:27:20 <mvollmer> yes
14:27:26 <mvollmer> well... :-)
14:28:07 <stefw> yes i agree
14:28:17 <stefw> again targetting what's actually on the system, and what real users have installed, for better or worse
14:28:24 <stefw> we have two efforts that go in parallel
14:28:30 <dperpeet> I think for daily dev it would be nicer to target jessie
14:28:37 <stefw> 1. Having cockpit present UI for the system, and its characteristics
14:28:38 <dperpeet> fewer unrelated failures, hopefully
14:28:39 <stefw> and
14:28:44 <stefw> 2. making that system better, integrated, finished
14:28:51 <dperpeet> unstable is... unstable
14:29:02 <stefw> dperpeet, yes it's like developing against rawhide
14:29:05 <stefw> well not *that* bad
14:29:10 <dperpeet> not quite :)
14:29:11 <stefw> but at the very least like updates-testing
14:29:15 <stefw> which we don't do
14:29:20 <stefw> for better or worse
14:29:21 <dperpeet> but I think targeting jessie would be better for us, also
14:29:47 <github> [cockpit] dperpeet pushed 19 new commits to master: https://git.io/vXqis
14:29:47 <github> cockpit/master 20d7493 Stef Walter: subscriptions: Fix Coverity warning and clearer code...
14:29:47 <github> cockpit/master f59ca05 Stef Walter: test: Fix use of TEST_DATA by multiple unix users...
14:29:47 <github> cockpit/master 2a39af3 Stef Walter: base1: The cockpit.css is a legacy CSS script to include...
14:30:40 <stefw> ok, well i'll see step by step what that means
14:31:10 <stefw> in summary I've made this trello card: https://trello.com/c/Fl2ayBli/385-milestone-debian-and-ubuntu
14:32:33 <dperpeet> I think this might be worth noting on the mailing list
14:32:41 <stefw> ok
14:32:46 <github> [cockpit] stefwalter pushed 7 new commits to master: https://git.io/vXqiM
14:32:46 <github> cockpit/master d339f9c Marius Vollmer: storaged: Add version comparison utility...
14:32:46 <github> cockpit/master 7157dff Marius Vollmer: storaged: Fall back to UDisks2 if Storaged isn't available...
14:32:46 <github> cockpit/master 95d8aae Marius Vollmer: storaged: Don't touch fstab or crypttab with older UDisks2...
14:32:50 <dperpeet> as a place to track things
14:32:58 <dperpeet> and that it's serious
14:33:56 <stefw> good idea
14:35:51 <mvollmer> alright, next?
14:35:57 <stefw> y
14:36:04 <mvollmer> #topic UDisks2
14:36:25 <stefw> Support is merged :D
14:36:27 <mvollmer> so, as part of the previous topic I am looking at using UDisks2 instead of storaged
14:36:42 <mvollmer> stefw, yes, I saw that! :-)
14:37:53 <mvollmer> what can I say, having to use UDisks2 doesn't make me super happy :-)
14:38:19 <dperpeet> will we try to get the patches that went into storaged also into udisks2?
14:38:28 <mvollmer> i had a brief chat with Martin Pitt, and he mentioned that udisks doesn't realy have a maintainer, and we should merge/replace with storaged
14:39:09 <mvollmer> so i guess we know where we are going, we just have to move the pieces on the board to make it happen
14:39:26 <stefw> yeah that makes sense
14:39:33 <stefw> so essentially we're reaching backwards in time with udisks2 support
14:39:42 <mvollmer> yeah
14:39:45 <stefw> an older version of the API
14:39:53 <stefw> rather than having an alternative
14:40:11 <mvollmer> and knowing that we can move forwards makes it feasible to just turn off features
14:40:17 <mvollmer> instead of reimplementing them in javaScript
14:40:52 <mvollmer> back in the day, one principole for the storaged API was "one click, one method call"
14:41:21 <mvollmer> so that something that looks like one operation doesn't end up being half done just because the user closed the browser
14:41:32 <stefw> that's a good point
14:41:47 <mvollmer> that's why there is CreatePartitionAndFormat
14:42:10 <mvollmer> the alternative would be to have separate operations in the UI, CreatePartition and Format
14:42:12 <stefw> is it worth posting these explanations on cockpit-devel and summarizing why udisks2 support was added, what's not included, and going forward -> storaged
14:42:25 <mvollmer> yes, also for ourselves
14:43:56 <mvollmer> so, I guess I keep talking with Martin about merging storaged and udisks
14:44:27 <stefw> yeah that would be cool
14:46:42 <mvollmer> alright
14:47:45 <mvollmer> #topic Open fllor
14:49:52 <stefw> If anyone has any pull requests they would like for the next release, rebase and mark (or ask someone to) mark with the 'priority' tag.
14:59:23 <petervo> stefw, inline svg fails due to csp
14:59:35 <petervo> relax csp? or use pngs?
15:00:19 <stefw> that's strange
15:00:29 <stefw> csp is already relaxed on the login page
15:00:53 <dperpeet> is this for open floor or unrelated?
15:01:15 <petervo> no one said anything for 10 mins
15:01:21 <petervo> i figured openfloor was done
15:01:26 <dperpeet> mvollmer, hasn't ended the meeting yet
15:07:15 <dperpeet> #endmeeting
15:07:39 <stefw> petervo, i have no problem doing svg with CSP
15:07:46 <stefw> in the login screen
15:07:50 <stefw> so i'll do a commit for you
15:09:36 <mvollmer> yep
15:09:40 <mvollmer> #endmeeting