13:00:26 <stickster> #startmeeting Workstation WG
13:00:26 <zodbot> Meeting started Mon Jun 19 13:00:26 2017 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:26 <zodbot> The meeting name has been set to 'workstation_wg'
13:00:29 <stickster> #meetingname workstation
13:00:30 <zodbot> The meeting name has been set to 'workstation'
13:00:32 <stickster> #topic Roll call
13:00:34 <stickster> .hello pfrields
13:00:35 <mclasen> .hello mclasen
13:00:35 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
13:00:38 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:01:02 <stickster> juhp kalev rdieter ryanlerch ping
13:01:09 <kalev> .hello kalev
13:01:09 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
13:01:12 * stickster searches for a few other folks
13:01:39 <mclasen> cschalle walked in a few minutes ago, let me scare him up
13:01:59 <stickster> #chair rdieter mclasen kalev juhp ryanlerch
13:01:59 <zodbot> Current chairs: juhp kalev mclasen rdieter ryanlerch stickster
13:02:03 <stickster> thanks mclasen
13:02:11 <otaylor> .here otaylor
13:02:15 <stickster> #chair otaylor
13:02:15 <zodbot> Current chairs: juhp kalev mclasen otaylor rdieter ryanlerch stickster
13:03:43 * cschalle hi
13:04:23 <stickster> #chair cschalle
13:04:23 <zodbot> Current chairs: cschalle juhp kalev mclasen otaylor rdieter ryanlerch stickster
13:04:28 <stickster> o/  hola everyone
13:04:49 <kalev> morning
13:05:00 <stickster> #info Agenda (not ordered): https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting
13:05:21 <stickster> So what I'm going to try to do is pick the least complex/controversial things to start with, so we don't run out of time
13:05:26 <juhp_> hi
13:05:46 <stickster> I have to finish by :55 to moderate another meeting next hour. So... without further ado...
13:05:59 <stickster> #topic Removing at
13:06:01 <stickster> #link https://pagure.io/fedora-workstation/issue/19
13:06:49 <otaylor> This was something that walters requested to match what they've done for Atomic Host.
13:06:52 <kalev> google-chrome not properly expressing its at dependency seems like a good enough reason to keep it installed for now
13:06:54 <ryanlerch> .hello ryanlerch
13:06:55 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
13:07:15 <mclasen> seems wrong for chrome to need at in the first place
13:07:37 <juhp_> right
13:08:12 <kalev> I don't disagree, but would be good to fix chrome before we break it, I think
13:08:17 <stickster> otaylor: thanks for digging up the background for Chrome, finally I had a random brain cell firing that was worthwhile. google-chrome-stable is on this system and it turns out that it depends on at the right way
13:08:40 <stickster> kalev: So... it looks like this is solved. I just tried 'dnf remove at' and it wants to remove google-chrome-stable. So I reckon chrome isn't a problem
13:08:46 <kalev> ahh, perfect!
13:08:54 <otaylor> His take was that with ostree we're moving so that /etc and /usr are read-only at run-time, and we could eventually sign their contents (as I understand it), so it's harder for malware to make things persistent at the *root* level (though obviously trivial at a user level)
13:09:13 <otaylor> I think it's a fairly minor step towards enhanced security, but it is one.
13:09:52 <otaylor> I *don't* think that 'at' usage at the command line is at all common. But that's going from personal experience - so I at least wanted to gather a wider set of personal experience here :-)
13:10:05 * mclasen hasn't used at in decades
13:10:23 * kalev hasn't used it recently either.
13:10:58 <juhp_> I can't really remember when I last used
13:11:06 <misc> :me used it 2 weeks ago
13:11:07 <otaylor> As was pointed out in the google-chrome spec file, at is listed in the lsb as a required command - though obviously if atd isn't running, that's sort of pointless
13:11:26 <otaylor> (and we don't enable atd by default)
13:11:40 <juhp_> the chrome lsb dep also seems heavy :(
13:11:46 <otaylor> Uh
13:11:47 <otaylor> $ rpm -q --whatrequires /usr/bin/at
13:11:49 <otaylor> redhat-lsb-core-4.1-34.fc26.x86_64
13:12:13 <otaylor> so I guess that means that this is also a proposal to remove redhat-lsb-* from the workstation
13:12:35 <otaylor> Which might be a bit drastic.
13:13:01 <kalev> is it actually in the default workstation install?
13:13:14 <kalev> I thought google-chrome-stable just dragged it in through dependencies
13:13:26 <otaylor> You can't persistently across reboot *enable* atd (systemctl enable atd) without writing to /etc - so that's some argument that at is not actually a persistence vector
13:13:33 <stickster> kalev: Yeah, chrome requires 'lsb' and not 'at'
13:13:45 <mclasen> I don't think there is a srong reason for us to ship the lsb stuff by default
13:14:00 <juhp_> chromium seems to have pretty sane deps
13:14:05 <juhp_> mclasen, nod
13:14:05 <kalev> stickster: right, I mean, otaylor was saying that removing at means removing lsb; I was just questioning if we actually ship the lsb stuff
13:14:53 <otaylor> kalev/stickster: True - it got installed when I installed google-chrome (yay gnome-software for removing my need to think about that manually!)
13:15:04 <stickster> otaylor: does the idea that /etc and /usr are read only at runtime mean that one can no longer add services to an ostree based install?
13:15:05 <juhp_> atom requires redhat-lsb-core too ;)
13:16:18 <otaylor> stickster: Mmm, honestly not sure how much '/etc is read only at runtime' is a current thing or somtehing that walters is planning. I haven't noticed it using a ostree system
13:16:29 <juhp_> It's a shame that these third party rpms tend to be lowest dominator in terms of deps
13:16:53 <otaylor> stickster: But *until* it's read-only removing at doesn't meaingfully improve defense against persistence, which was the argument for removing at
13:16:54 <stickster> at least they're requiring what they need, that's at least in the right direction
13:17:26 <juhp_> yep true
13:17:52 <juhp_> I don't have atd installed
13:17:57 <otaylor> Anyways - my vote here is +1 to remove at from the default install, but expect that it's going to be pulled in anyways on a lot of systems by chrome
13:17:58 <stickster> otaylor: cschalle: I wonder if we could convince Google to rely on a systemd timer and fall back to at for other distros?
13:18:15 <stickster> otaylor: I'm still OK to remove it as well
13:18:18 <juhp_> stickster, +1
13:18:22 <juhp_> otaylor, +1
13:18:48 <stickster> (might as well take a vote, the rest of this is somewhat academic)
13:18:50 <mclasen> yes, recommending systemd replacements seems like a good idea
13:18:54 <stickster> so far +3 for
13:18:56 <otaylor> stickster: Harder thing is to get them to remove the lsb dep because they probably need that to get at on other systems
13:19:04 <juhp_> otaylor, right
13:19:28 <mclasen> +1 from me too
13:19:31 <juhp_> it might not just be for at
13:19:34 <kalev> sure, +1, I am not opposed to removing it either
13:19:39 <juhp_> +1
13:20:07 <stickster> otaylor: sure, that's how they got it on *our* system IIUC
13:20:18 <cschalle> stickster, we could try, I will ask the devs to reach out
13:20:19 <stickster> cschalle: ryanlerch: opinions?
13:20:28 <cschalle> ?1
13:20:30 <cschalle> +1
13:20:54 <juhp_> cool, certainly worth raising it with them anyway
13:22:10 <stickster> #agreed +6, -0: remove at from default install, since chrome will pull it in anyway atm
13:22:26 <stickster> #action cschalle ask devs to contact Google about using a systemd timer for their cleanup bits
13:22:31 <ryanlerch> sorry for being slow, +1 from me
13:22:34 <cschalle> stickster, done :)
13:22:43 <stickster> #info REVISED: +7, -0 on above vote
13:22:45 <otaylor> cschalle:  Specifically, the replacement is 'systemd-run' - probably how it should be refernced
13:22:57 <stickster> kalev: do you want to do the honors of removal?
13:23:09 <kalev> sure, let me do that
13:23:16 <stickster> #action kalev fix up distro/comps stuff to make it happen
13:23:25 <otaylor> kalev: https://pagure.io/fedora-comps/pull-request/134
13:24:05 <stickster> Oh, we've got a PR already, awesome.
13:24:18 <kalev> ahh, great
13:24:34 <stickster> #topic F26 Final blockers
13:24:37 <stickster> #link https://pagure.io/fedora-workstation/issue/20
13:25:15 <stickster> adamw sent a note to list about this earlier. One of the three blockers is already resolved (ended up WORKSFORME, iirc)
13:25:25 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1404285
13:25:47 <kalev> we also have a new proposed gjs blocker as of today morning, https://bugzilla.redhat.com/show_bug.cgi?id=1462444
13:25:47 <stickster> #info gnome-documents bug, moved out of gjs by catanzaro
13:25:55 <stickster> oh, ugh
13:26:04 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1340203
13:26:47 <stickster> #info GOA issue, seems to have popped up intermittently as blocker beforfe
13:26:53 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1462444
13:27:27 <otaylor> Isn't clear how much debarshi has investigated the goa issue from the bug
13:27:31 <stickster> #info gjs issue prevents GNOME Shell login
13:27:59 <mclasen> session live-cycle is on halfline's list in principle
13:28:21 <mclasen> but he's been stuck in rhel and with a glibc thing that was deemed blocker material
13:29:17 <stickster> mclasen: would both 1340203 and 1462444 fall into halfline's purview, then?
13:29:51 <otaylor> stickster: Not  1462444
13:30:20 <stickster> ISTR I've seen a bunch of gjs stuff that points back to sqlite3DbMallocRawNN()
13:30:34 <stickster> not sure what that portents
13:30:56 <otaylor> If it's *actually* reproducible, I can look at it today - though judging from the small number of dups, I'm not too hopeful
13:31:46 <otaylor> (I have zero experience with the newer gjs versions, but I don't think anybody else on the desktop team does either)
13:31:48 <stickster> mclasen: Should 1340203 be assigned over to Ray?
13:32:09 <stickster> sorry, *halfline* to be exact
13:32:23 <mclasen> I don't think assigning bugs does much of anything, tbh
13:33:07 <cschalle> stickster, assign it to halfline for now and mclasen and I will follow-up and figure out what to do there
13:33:08 <otaylor> if it's reproducible, then https://bugzilla.redhat.com/show_bug.cgi?id=1462444#c13 indicates that it is bisectable, so shouldn't be too hard to get to bottom of
13:33:11 <stickster> Well, that's debatable, but not here and now please. At a minimum, it tells QA who's a good person to talk to
13:34:07 <otaylor> The gnome-documents crash looks like a tracker issue
13:34:16 <stickster> #action stickster reassign BZ 1340203 to halfline
13:34:24 <stickster> #action cschalle follow up on BZ 1340203
13:34:38 <otaylor> mclasen: does anybody have experience with tracker internals?
13:34:52 <kalev> garnacho does
13:34:54 <mclasen> garnacho is the best person to look at that
13:35:37 * stickster not familiar with that nick
13:36:55 <stickster> otaylor: can you follow up on this one?
13:37:09 <mclasen> I can do it
13:37:22 <stickster> Sounds good
13:37:29 * stickster reminds everyone they also have #hashtag power to assign things to themselves to move this meeting faster
13:37:47 <stickster> #action mclasen assign BZ 1462444 to garnacho and follow up
13:38:08 <stickster> And that leaves 1404285, gnome-documents bug
13:38:37 <otaylor> stickster: No
13:38:39 <otaylor> stickster: there's confusion there
13:38:51 <stickster> otaylor: deconfusify please! :-D
13:39:08 <otaylor> I'll take 1462444 - mclasen was volunteering to follow up with Carlos Garnacho about the gnome-documents bug
13:39:10 <stickster> gotcha
13:39:12 <stickster> #undo
13:39:12 <zodbot> Removing item from minutes: ACTION by stickster at 13:37:47 : mclasen assign BZ 1462444 to garnacho and follow up
13:39:37 <stickster> #action mclasen assign BZ 1404285 to garnacho and follow up
13:40:10 <stickster> OK, got those mixed up -- we're left with 1462444 which is related to gjs + Shell login
13:40:21 <stickster> #action otaylor follow up on BZ 1462444
13:40:30 <stickster> *whew* Now we can move on.
13:40:51 <juhp_> :)
13:41:00 <stickster> #topic Workstation repository
13:41:03 <stickster> #link https://pagure.io/fedora-workstation/issue/17
13:42:08 <stickster> cschalle: I think this was the issue about third party repository, where I think we detoured into trying to subpackage, not sure if that was still the plan, or keep fedora-workstation-repos
13:43:15 <cschalle> yeah the sugestion was to make it a subpackage, that said I did update the 3rd party packing proposal to clearly state that the WS working group (or another other working group) could maintainer their own file here. So once that is approved by council that could be our 'fix'
13:43:15 <stickster> IIRC this was where finishing the third party policy was supposed to come in handy
13:43:19 <stickster> *jinx
13:43:31 <kalev> I think the executive summary here is that once upon a time releng expressed strong preference to having all .repo files come from fedora-repos and then sgallagh suggested we do the same here
13:44:20 <sgallagh> kalev: For the record, I have since realized that we relaxed that requirement somewhat, so ship what you need to.
13:44:22 <stickster> Right, although that bottlenecks Yet Another Thing on the rel-eng team which already has challenges trying to keep up with bigger needs from modularity, et al.
13:44:30 <stickster> sgallagh: Thanks for popping in, that's helpful
13:44:31 <sgallagh> we == FESCo
13:44:33 <kalev> ahh, thanks sgallagh
13:44:49 <stickster> OK, I'll try to record this well in the issue tracker, too
13:44:59 <stickster> seems like we go forward with f-ws-repositories
13:45:03 <sgallagh> kalev: The source of confusion was mainly due to FESCo's ruling not getting recorded properly.
13:45:11 <cschalle> ok, so lets leave this item until the council has had a chance to review and hopefully approve updated 3rd party writeup
13:45:20 <stickster> #info sgallagh advises that we should be able to keep our own repo package
13:45:27 <sgallagh> ack
13:45:42 <stickster> #action cschalle to have Council review 3rd-party repo policy
13:45:56 <stickster> #action stickster make sure this is clearer in ticket so we don't run round in circles
13:46:08 <stickster> Anything else we should record on this one?
13:46:40 <stickster> moving on then
13:46:44 <stickster> #topic Packaging guidelines for app independence
13:46:48 <stickster> #link https://pagure.io/fedora-workstation/issue/13
13:47:16 <stickster> I think the WG approved this last time, according to minutes... the action I had pending was mclasen was going to talk to hughsie about the changes in Software we discussed
13:47:20 <stickster> mclasen: any status on that?
13:49:51 <stickster> ok, in court terms I can file for a continuance on this one ;-)
13:50:11 * mclasen hangs his head in shame
13:50:27 <mclasen> I'm going to talk to hughsie right now
13:50:59 <stickster> mclasen: no shame required, only so many cycles in a week
13:51:14 <stickster> we'll continue that to the next meeting, not an issue
13:51:24 <stickster> #topic Any other (admin) business
13:52:24 * stickster holds the door for a minute
13:54:27 <stickster> OK, enjoy your week everyone!
13:54:32 <stickster> Thanks for coming :-)
13:54:35 <stickster> #endmeeting