16:00:04 <maxamillion> #startmeeting FESCO (2017-07-21)
16:00:04 <zodbot> Meeting started Fri Jul 21 16:00:04 2017 UTC.  The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'fesco_(2017-07-21)'
16:00:04 <maxamillion> #meetingname fesco
16:00:04 <zodbot> The meeting name has been set to 'fesco'
16:00:04 <maxamillion> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:04 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:00:07 <maxamillion> #topic init process
16:00:09 <maxamillion> .hello maxamillion
16:00:10 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:00:20 <nirik> morning
16:00:46 <jforbes> .hello jforbes
16:00:47 <ignatenkobrain> .hello ignatenkobrain
16:00:47 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:00:50 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:01:17 <kalev> .hello kalev
16:01:18 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:40 <Rathann> .hello rathann
16:02:40 <zodbot> Rathann: rathann 'Dominik Mierzejewski' <dominik@greysector.net>
16:03:55 <maxamillion> alright, that's quorum ... let's get to it, we've got a lot on the agenda today
16:04:04 <maxamillion> #topic Follow Ups
16:04:04 <maxamillion> #topic #1741 - F27 System Wide Change: Graphical Applications as Flatpaks
16:04:07 <maxamillion> .fesco 1741
16:04:08 <zodbot> maxamillion: Issue #1741: F27 System Wide Change: Graphical Applications as Flatpaks - fesco - Pagure - https://pagure.io/fesco/issue/1741
16:04:10 <maxamillion> https://pagure.io/fesco/issue/1741
16:04:28 <maxamillion> so this is the big ticket item for the day, it's left over from last week and there's been a *LOT* of discussion on devel list
16:04:49 <jforbes> Heated discussion even
16:05:02 <kalev> soooo, there was a lot of discussion about this one on the mailing list and I haven't read all of it
16:05:20 <maxamillion> jforbes: indeed
16:05:40 * nirik nods
16:06:11 <kalev> one thing that several people pointed out was that they'd much prefer rpm level granularity as opposed to flatpak's bundled approach
16:06:37 <maxamillion> so I'm still reading ... I'm like 2/3 through the thread but I kind of have the gist right now of concerns, some valid, some just conflicting idealogical opinions about software packaging and distribution
16:06:50 <kalev> I think this is a valid concern, but something that nobody is actually proposing of changing here -- nobody is taking rpms away, it's just that flatpaks would be produced in parallel
16:07:00 <kalev> and rpms would continue to be produced as they are for the foreseeable future
16:07:25 <jforbes> Owen made a nice summary yesterday though
16:07:32 <nirik> right. this is just to help get the pool of flatpaks larger so we know more about how popular/well they will work
16:07:33 <maxamillion> kalev: it was discussed in thread that rpms wouldn't be distributed at some point in the future for software that's released as flatpaks and we would potentially loosen the restriction on rpm packaging in the future
16:07:52 <kalev> so in my opinion, _adding_ flatpak in parallel to rpms doesn't really make anyone's life worse, but it does make it possible for the workstation wg to experiment with the new approach
16:07:56 <maxamillion> jforbes: link?
16:08:11 <kalev> maxamillion: right, but that's only for the future, not something that's in scope for the current proposal
16:08:41 * kalev notes that the whole Workstation WG is behind the flatpak idea and putting resources into it
16:09:10 <maxamillion> kalev: fair
16:09:27 <jforbes> hold on, trying to find it in the web interface
16:09:35 <maxamillion> kalev: yeah, the workstation WG willing to back it up with work cycles is definitely worth noting
16:09:41 <maxamillion> jforbes: +1
16:09:43 <kalev> mclasen: are you around, by any chance? we've got a flatpak discussion here
16:09:48 <maxamillion> jforbes: I just figured we'd link it for posterity
16:10:00 <mclasen> kalev: where ?
16:10:04 * nirik notes if you have a list post in your mail reader, look for the X-archived-at header and it will have a link to that post on the web.
16:10:09 <kalev> mclasen: here in this channel
16:10:23 <mclasen> oh, here
16:10:31 * mclasen reads backlog
16:10:40 <maxamillion> nirik: oh, nice
16:11:21 <jforbes> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ABWHDCTSPNCMOJYYTT4UZ3HCWVGCNLSR/
16:11:34 <mclasen> kalev: any concrete question for me ?
16:11:39 <maxamillion> jforbes: thanks
16:11:50 <kalev> mclasen: nope, just wanted your attention if you want to add something
16:12:22 <jforbes> nirik: nifty
16:12:39 <Rathann> in my opinion, Flatpak is not ready for prime time yet
16:12:55 <mclasen> maxamillion: the wg doesn't really have work cycles to spend, but there's several people on the desktop team that work on flatpak and related infrastructure
16:13:09 <nirik> but is making flatpaks from rpms and playing with that model 'prime time' ?
16:13:26 <maxamillion> mclasen: hrmmm ... alright
16:13:32 <kalev> it's just part of getting ready for 'prime time', without actually starting to do this we'll never get ready
16:13:42 <kalev> nirik: ^^
16:13:43 <Rathann> it lacks quite a few features (rpm -ql and -V equivalents) and it doesn't check dependencies at uninstall time
16:14:03 <maxamillion> Rathann: +1
16:14:04 <nirik> kalev: yes, I agree, I was just asking Rathann.
16:14:09 <maxamillion> Rathann: that is a concern for me as well
16:14:15 <mclasen> Rathann: those are nice and concrete requests that could be easily handled
16:14:21 <mclasen> it does check dependencies, though
16:14:33 <Rathann> mclasen: only upon installation
16:14:37 <maxamillion> Rathann: however, at the same time, we can't do that stuff with container images (docker, rkt, et al) either
16:14:49 <Rathann> I opened a bug upstream about the lack of checking at uninstall time
16:14:50 <mclasen> do you have a concrete example of what it is not doing ?
16:14:52 <maxamillion> so I'm not sure how much I want to be a stickler about that point
16:15:07 <Rathann> mclasen: yes, I'll give it in a moment
16:15:18 <mclasen> a reference to the issue would be sufficient, thanks
16:15:32 <Rathann> anyway, I'm not opposed to this proposal given the answers I got in the devel thread
16:16:08 <Rathann> but I'd like some assurances that the issues I raised will be fixed in some reasonable time frame
16:16:26 <Rathann> mclasen: https://github.com/flatpak/flatpak/issues/925
16:16:58 <mclasen> oh, I see
16:16:58 <kalev> Rathann: ahh, you mean uninstalling a runtime should also prompt to uninstall any apps using it?
16:17:04 <puiterwijk> mclasen: just uninstalled a base platform, and now: error: runtime/org.kde.Platform/x86_64/master not installed
16:17:11 <puiterwijk> (on flatpak run org.fedoraproject.MediaWriter/x86_64/master )
16:17:15 <mclasen> we can at least add a warning
16:17:18 <Rathann> kalev: well, that's what dnf would do
16:17:28 <Rathann> rpm won't even allow this without --nodeps
16:17:31 <mclasen> currently, it defaults to doing what rpm -e --nodeps gives you
16:17:35 <Rathann> yup
16:18:49 <Rathann> I was mostly concerned with bundled stuff not being tracked (and the metadata inside manifest.json files is barely sufficient), but Owen said it'd be tracked using PDC
16:19:14 <Rathann> mclasen: also, https://github.com/flatpak/flatpak/issues/282
16:19:28 <Rathann> and https://github.com/flatpak/flatpak/issues/532
16:20:11 <mclasen> sure, there's some imperfections in the commandline ux
16:20:14 <Rathann> compared to the above, https://github.com/flatpak/flatpak/issues/925 looks trivial (though still annoying)
16:20:30 <mclasen> but I don't think we really need to dive into them individually here
16:20:39 <Rathann> well you wanted specific examples ;)
16:20:58 <mclasen> for the workstation use case, gnome-software is meant to be the primary point where users manage applications
16:21:17 <kalev> I think nobody here disagrees that flatpak is sitll in active development and there's more things to fix, but we're actively working on them
16:21:28 <mclasen> Rathann: thanks for the specific examples!
16:21:44 <Rathann> I posted them in the devel thread, but probably got lost in the noise
16:21:58 <Rathann> and you're welcome
16:22:26 <otaylor_> The goal of this change proposal is to get to the point where we know what we need to fix for Flatpaks created from Fedora RPM content - I'm sure there will more things to fix with that too!
16:23:11 <maxamillion> otaylor_: so just to level set, this proposal does not remove the rpm distribution of the software that's being put into flatpaks, correct?
16:23:33 <Rathann> are you sure you have enough time in F27 schedule?
16:23:51 <Rathann> I'd feel more comfortable if this was postponed to F28
16:23:55 <otaylor_> maxamillion: It does not - that's not part of this at all. This is only enabling.
16:24:17 <Rathann> otaylor_: thanks for the detailed answers in the devel thread, by the way
16:24:33 <otaylor_> Rathann: I'm not 100% confident no, there's contingency in the proposal for when we have to punt, but it's top priority for some of us to work on, and we're working as hard as we can
16:24:40 <Rathann> you convinced me this is not a bad proposal as some people make it to be
16:25:02 <maxamillion> otaylor_: +1 - however, it's possible that some of the software will need to be patched in order to work in flatpaks?
16:26:10 <otaylor_> maxamillion: In general, to work as an unsandboxed flatpak very little patching is needed - an app can do something sufficiently strange to notice (poking around in /proc, say), but generally, if an app is portable and supports installation in different prefixes, it will just work
16:26:32 <Rathann> I'm a bit worried there's a design flaw in Flatpak (the use of /app as %{_prefix}) that will make it difficult or impossible to build some software without heavy patching
16:26:40 <otaylor_> to make an app work sandboxed generally requires application modification unless it is very simple - but that's really upstream work and not packager work
16:26:42 <Rathann> which upstreams frown upon frequently
16:26:44 <maxamillion> otaylor_: alright
16:27:10 <otaylor_> Rathann: Very little software hardcodes /usr - at least at the application level - if you are trying to build grub or something, that's different!
16:27:34 <Rathann> but if the sole use case for flatpaks is leaf-node graphical applications, then it should be fine
16:27:52 <otaylor_> Most application developers, after all, don't build their application and install it in /usr to test it out
16:27:57 <kalev> on rpm level, there's probably some spec files that need changing from %files /usr to %files %{_prefix} or so, but that shouldn't be hard
16:28:12 <otaylor_> Rathann: that is the the sole intended target, yes.
16:28:14 <maxamillion> Rathann: that does concern me a little, but at the same time I feel like %{_prefix} should be able to be set to whatever you want and if there's a hard requirement upstream for that to be set to something then that's non-portable
16:28:16 <ignatenkobrain> having /usr in specfiles is wrong anyway, so..
16:28:29 <Rathann> right
16:28:40 <maxamillion> ignatenkobrain: +1
16:28:55 <ignatenkobrain> maxamillion: since it is optional for packagers, I am +1 for this change (even I'm not planning to use flatpaks)
16:29:07 <ignatenkobrain> and it *will* improve upstream / fedora packages
16:29:49 <Rathann> otaylor_: it'd be good if you could address the treatment of bundled and duplicated binaries in and between runtimes and flatpaks
16:30:05 <Rathann> on the proposal page
16:30:27 <Rathann> or on Flatpak wiki page
16:30:45 <maxamillion> Rathann: +1
16:30:46 * otaylor_ looks
16:31:18 <Rathann> anyway, I'm +1 to the change
16:31:23 <otaylor_> Rathann: Sorry, I'm not finding that.
16:31:32 <otaylor_> Oh, ah, I see what you mean
16:31:42 <otaylor_> You want me to expand on it in the wiki pages
16:31:45 <otaylor_> I'll definitely do that
16:31:49 <Rathann> otaylor_: yes, thank you
16:31:59 <maxamillion> alright, are there any more concerns that people would like discussed before we vote?
16:32:36 * nirik is +1 to the change
16:32:42 * kalev is +1 to the change as well
16:32:43 <nirik> jwb was/is +1 in ticket
16:32:49 * jforbes is +1 as well
16:33:22 * maxamillion is +1 to the change as proposed and based on responses from change owners to concerns raised
16:33:28 <maxamillion> Rathann: ?
16:33:38 <Rathann> yes, +1
16:34:19 <Rathann> and I'm keeping my fingers crossed that all the promised stuff is successfully implemented
16:34:38 <maxamillion> #agreed - APPROVED: F27 System Wide Change: Graphical Applications as Flatpaks (+1:6, +0:0, -1:0) (Includes a +1 in ticket from absense FESCo member)
16:34:50 <maxamillion> #topic New Business
16:34:50 <maxamillion> #topic #1736 - Don't automatically close security bugs on Fedora EOL
16:34:51 <maxamillion> .fesco 1736
16:34:51 <maxamillion> https://pagure.io/fesco/issue/1736
16:34:52 <zodbot> maxamillion: Issue #1736: Don't automatically close security bugs on Fedora EOL - fesco - Pagure - https://pagure.io/fesco/issue/1736
16:36:11 <maxamillion> thoughts from the group?
16:36:23 <nirik> this seems reasonable in some cases
16:37:01 <Rathann> I agree
16:37:28 <jforbes> I can't think of a case where it doesn't seem reasonable.  Maintainers should be able to confirm that CVEs are addressed in a newer version
16:37:34 <puiterwijk> Also, on the categorizing part, I think that Red Hat product security does a good job with that, with attaching the Fedora bugs to tracker CVE bugs
16:37:35 <maxamillion> yeah, fair enough ... auto-closing the bug on package update is easy enough via bodhi
16:37:44 <maxamillion> puiterwijk: +1 - thanks
16:37:44 <nirik> well, if say only f24 is affected and it goes eol...
16:38:23 <puiterwijk> nirik: I think that that's also encoded in the prodsec tracker bugs. So we could probably look at using that info
16:38:25 <maxamillion> nirik: yeah, that's also a concern because it can add burned on the maintainer
16:38:36 <maxamillion> puiterwijk: ah, good to know
16:38:53 <nirik> yeah, I was just looking for what we could use here...
16:39:03 <jforbes> Yeah, didn't think about that, since kernel continuously rebases, our CVEs are across Fedora releases
16:39:13 <nirik> but we don't need to figure it out here, we can just agree and implement it somehow before program manager runs scripts
16:39:32 * maxamillion is +1 to the change
16:39:36 <kalev> in some cases, I think it's reasonable to close old bugs when the packager hasn't done that
16:39:39 <kalev> like, for example, a package is kept up to date in F25+ but and has all the security issues fixed, and then there's a security issue filed against F24
16:39:42 <kalev> seems reasonable to automatically close the F24 issue then
16:39:51 <Rathann> right
16:40:12 <puiterwijk> For example, https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-8638 (one that I happened to have open), lists the exact affected versions
16:41:07 <jforbes> Then again, the burden shouldn't be that large. Unless you are the PHP maintainer or something, you probably don't have a mass of CVEs at any given time
16:41:46 * nirik notes you can also search closed bugs.
16:43:03 <nirik> so I guess I am +1 to something here, but not sure what... perhaps we could ask program manager how scripts might deal with this?
16:43:08 <nirik> I am not sure where those scripts live
16:44:07 <ignatenkobrain> I thought it's Santa going and manually closing bugs ;)
16:44:29 <maxamillion> someone want to make a proposal?
16:45:33 <nirik> proposal: wait another week, ask for input from program manager and what work needs to be done with EOL scripts
16:45:50 <kalev> +1 to nirik's proposal
16:45:58 <maxamillion> +1 to nirik's proposal
16:46:08 <jforbes> +1 nirik
16:46:10 <Rathann> looks sensible, +1 to nirik's proposal
16:46:21 * nirik is +1 to his own proposal to be clear
16:46:27 <maxamillion> #agreed wait another week, ask for input from program manager and what work needs to be done with EOL scripts (+1:5, +0:0, -1:0)
16:46:42 <maxamillion> #topic #1737 - Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28
16:46:45 <maxamillion> .fesco 1737
16:46:46 <zodbot> maxamillion: Issue #1737: Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 - fesco - Pagure - https://pagure.io/fesco/issue/1737
16:46:47 <maxamillion> https://pagure.io/fesco/issue/1737
16:46:52 <maxamillion> #topic #1748 - F27 System Wide Change: No More i686 Kernels
16:46:52 <maxamillion> .fesco 1748
16:46:53 <maxamillion> https://pagure.io/fesco/issue/1748
16:46:53 <zodbot> maxamillion: Issue #1748: F27 System Wide Change: No More i686 Kernels - fesco - Pagure - https://pagure.io/fesco/issue/1748
16:47:08 <maxamillion> I wanted to put these together because they seem directly related and one might negate the other
16:47:19 <kalev> looks like the i686 SIG is being formulated
16:47:42 <jforbes> Right, 2 things here
16:48:13 * nirik still sees only 2 people on the wiki page, but yeah... will see if it takes.
16:48:16 <jforbes> First, the no more i686 kernels change should be F28, and I think it is completely dependent on the SIG
16:48:54 <maxamillion> alright
16:48:55 <jforbes> If the community is really willing to put in the effort for a successful i686, I would certainly be supportive of it continuing
16:49:01 <Rathann> jforbes: +1
16:49:10 <maxamillion> so let me backup, we'll address the SIG first
16:49:18 <maxamillion> #topic #1737 - Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28
16:49:21 <maxamillion> .fesco 1737
16:49:22 <zodbot> maxamillion: Issue #1737: Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 - fesco - Pagure - https://pagure.io/fesco/issue/1737
16:49:23 <maxamillion> https://pagure.io/fesco/issue/1737
16:49:39 <jforbes> I can't +1 this enough
16:49:51 <kalev> makes sense, but how is "functional" defined?
16:49:56 <maxamillion> kalev: +1
16:50:14 <nirik> right, we need a bar for them to meet
16:51:46 <jforbes> What I would like to see is similar to what we see in arm and power. We get bug fixes before we even know that a bug exists. That means people actually following and working with upstream.
16:52:09 <nirik> how about: f27 i686 images that would be release blocking in x86_64 meet all the release critera?
16:52:32 <kalev> I think nirik's target is easier to meet and certainly easier to _measure_ in fedora land
16:53:16 <kalev> and that may lead to proactive fixes in the future when the i686 SIG people get accustomed with kernel development
16:53:20 <nirik> but it's a pretty high bar... since they would need to do all the testing, triaging and then tracking down fixes.
16:53:46 <jforbes> Well, that is generally what happens now, it's just that we end up doing the work.
16:54:43 <maxamillion> jforbes: which is a problem for the future
16:54:45 <maxamillion> jforbes: yes?
16:54:52 <jforbes> maxamillion: yes
16:55:10 <maxamillion> I figured as much
16:56:17 <smooge> oh hello
16:56:19 <jforbes> While we can ignore non blockers, etc until upstream fixes them, release blockers/build issues/etc all have to be taken care of.
16:56:27 <maxamillion> jforbes: right
16:56:28 <nirik> anything we come up with we should get interested parties to agree with. ;)
16:56:32 <maxamillion> alright, so is a proposal on the table to be voted on?
16:56:38 <smooge> sorry I didn't realize this was on the agenda for today. do I need to say anything here?
16:57:01 <jforbes> smooge: Do you have a proposal for the fefinition of "funcional SIG"?
16:57:06 <jforbes> definition even
16:57:38 <smooge> I have a defenestration
16:58:02 <jforbes> So you wish to throw the SIG out of the window?
16:59:44 <smooge> well if it is doesn't become functional. I think that Matthew's outline was a good first idea. I expect he was wanting push back on what the FESCO thought of that or better idea of numbers
16:59:59 <smooge> I can put more info into the ticket and have that put in for next weeks meeting?
16:59:59 <maxamillion> Proposal: Request criteria for what a "functional SIG" means in a measurable way
17:00:29 <jforbes> +1 maxamillion
17:00:41 <nirik> sure. We need such critera.
17:00:41 <Rathann> +1
17:00:51 * maxamillion is +1
17:01:02 <smooge> should council, mattdm or me provide that criteria?
17:01:35 <kalev> not sure, but someone needs to come up with that as we failed here in this meeting :)
17:01:41 <nirik> well, I think it should be a consensus
17:01:44 <maxamillion> nirik: +1
17:02:22 <maxamillion> kalev: +/- 1 to the proposal?
17:02:31 <kalev> +1
17:02:51 <kalev> I think nirik's idea above that i686 needs to meet all release criteria made sense, but if kernel developers feel it is not enough, then I think we need something else
17:02:57 <maxamillion> #agreed Proposal: Request criteria for what a "functional SIG" means in a measurable way (+1:5, +0:0, -1:0)
17:03:11 <maxamillion> alright, back to the other one
17:03:11 <maxamillion> #topic #1748 - F27 System Wide Change: No More i686 Kernels
17:03:11 <maxamillion> .fesco 1748
17:03:12 <maxamillion> https://pagure.io/fesco/issue/1748
17:03:13 <zodbot> maxamillion: Issue #1748: F27 System Wide Change: No More i686 Kernels - fesco - Pagure - https://pagure.io/fesco/issue/1748
17:03:44 <kalev> shouldn't we wait for the outcome of the previous ticket before dealing with this one?
17:03:47 <maxamillion> jforbes: so, should this be pushed to f28? (and contingent on some criteria from the i686 SIG?
17:03:51 <jforbes> So this one needs to go away, it should be refiled for F28 provided the SIG doesn't become funcitonal
17:03:59 * kalev agrees.
17:04:03 <Rathann> Proposal: postpone #1748 to F28 pending the outcome of #1737
17:04:32 <nirik> +1
17:04:36 <maxamillion> +1
17:04:44 <jforbes> +1
17:04:48 <kalev> +1
17:05:16 <maxamillion> Rathann: safe to assume a +1 from you?
17:07:39 <Rathann> +1
17:07:51 <maxamillion> #agreed Proposal: Proposal: postpone #1748 to F28 pending the outcome of #1737 (+1:5, +0:0, -1:0)
17:07:54 <maxamillion> errr
17:07:55 <maxamillion> #undo
17:07:55 <zodbot> Removing item from minutes: AGREED by maxamillion at 17:07:51 : Proposal: Proposal: postpone #1748 to F28 pending the outcome of #1737 (+1:5, +0:0, -1:0)
17:08:01 <maxamillion> #agreed Proposal: postpone #1748 to F28 pending the outcome of #1737 (+1:5, +0:0, -1:0)
17:08:04 <maxamillion> typo :)
17:08:12 <maxamillion> #topic #1743 - F27 System Wide Change: NSS Default File Format SQL
17:08:12 <maxamillion> .fesco 1743
17:08:12 <maxamillion> https://pagure.io/fesco/issue/1743
17:08:13 <zodbot> maxamillion: Issue #1743: F27 System Wide Change: NSS Default File Format SQL - fesco - Pagure - https://pagure.io/fesco/issue/1743
17:08:35 <nirik> +1 here
17:08:52 <maxamillion> +1 here
17:08:54 <kalev> I have no idea about the implications, but I trust the NSS maintainers
17:08:54 <kalev> +1
17:08:59 <jforbes> +1
17:09:45 <maxamillion> Rathann: ?
17:10:08 <puiterwijk> Do note that this might mean some configurations of software might "break" as far as users are concerned if the app uses the defaults: any keys/certificates would suddenly "disappear" as far as the user would see.
17:10:44 <Rathann> I wonder if anything depends on the dbm-style filenames
17:10:56 <Rathann> i.e. cert8.db vs. cert9.db
17:11:22 <Rathann> anyway, mostly +1
17:11:45 <Rathann> I'd like to see a list of packages dependent on NSS identified
17:12:03 <maxamillion> puiterwijk: really?
17:12:09 <Rathann> but since that's a simple query away
17:12:22 <puiterwijk> maxamillion: yeah, because if the app defaulted to dbm before, certs and keys are imported there.
17:12:27 <maxamillion> erm
17:12:31 <maxamillion> yeah, alright ...
17:12:32 <puiterwijk> If they suddenly switch to SQL, it will no longer read those.
17:12:43 <Rathann> puiterwijk: change proposal says NSS does one-time on-the-fly migration automatically
17:12:57 <Rathann> unless the application explicitly specifies dbm:
17:13:15 <puiterwijk> Rathann: ah, I did not see that. Nice, it doesn't do that now :)
17:13:33 <maxamillion> right, I hadn't thought of the situation where the explicit dbm specification would be a thing, I just saw migration and was good
17:13:33 <puiterwijk> (was just speaking from experience, as I've been bitten by this myself when a piece of software decided to change on themselves)
17:13:51 <Rathann> By changing the default, all applications that currently use the DBM file format, will automatically be migrated to the SQL file format. NSS has the ability to discover if a storage location (a directory) contains the DBM file format. If configured to use the modern SQL format, NSS will automatically perform a one-time conversion from the DBM to the SQL format.
17:14:08 <puiterwijk> Rathann: yeah, saw that now. Never mind me then :-)
17:14:45 <maxamillion> alright
17:15:03 <maxamillion> Rathann: so "mostly +1" == +1 ?
17:15:04 <puiterwijk> (though there will likely be some edge cases like when you already have both in the same directory, but well, that's software for you)
17:15:19 <Rathann> maxamillion: yes, +1
17:15:22 <maxamillion> #agreed F27 System Wide Change: NSS Default File Format SQL (+1:5, +0:0, -1:0)
17:15:40 <maxamillion> #topic #1744 - F27 System Wide Change: NSS signtool deprecation
17:15:40 <maxamillion> .fesco 1744
17:15:41 <maxamillion> https://pagure.io/fesco/issue/1744
17:15:41 <zodbot> maxamillion: Issue #1744: F27 System Wide Change: NSS signtool deprecation - fesco - Pagure - https://pagure.io/fesco/issue/1744
17:16:42 <kalev> I wonder if a better way to deprecate would be to just move it to a subpackage?
17:18:31 <ignatenkobrain> kalev: I think this is common practice to put under /unsupported/ directory
17:18:41 <nirik> well, there's lots of ways to do it... but I'm +1 to however nss folks want to do that.
17:18:53 <Rathann> upstream bug suggests it might be possible to enhance signtool (https://bugzilla.mozilla.org/show_bug.cgi?id=1345528#c3)
17:18:58 <jforbes> kalev: I think the eventual goal is for it to go away all together, seems odd to create a new package to get rid of
17:19:01 <puiterwijk> Personally, as a developer with scripts, I would be confused if stuff suddenly disappears. Maybe it's an idea to ask for a deprecation warning first in current releases?  (or at least put a binary that prints a warnings in place of it when they move)
17:19:04 <Rathann> without breaking compatibility, that is
17:19:07 <ignatenkobrain> I mean NSS guys do it a lot
17:20:03 <maxamillion> I think puiterwijk's point is a good one
17:20:08 <puiterwijk> I think a binary that prints "signtool is no longer supported, but read  $here for more info" and exit 1 is a nicer way than just moving things away
17:20:20 <kalev> I think I agree with puiterwijk
17:20:41 <jforbes> puiterwijk: as a developer with scripts, the move might make you actually check to see why it is not there, vs ignoring the output because your script still works
17:21:08 <puiterwijk> jforbes: that's why I'm saying the exit 1 to still error out :). I'm not saying we should just work, but do print a sane error/warnings
17:21:17 <kalev> but removing it from the default installation seems like a worthwhile goal as well -- putting it into subpackage that is no longer installed by default would achieve that
17:22:17 <kalev> if it's moved to /unsupported/ subdirectory but kept in nss-tools, then people are still going to get it with default install
17:22:27 <puiterwijk> (do note: from a personal point of view, I'm totally in favor of removing any easy use of insecure stuff. I just would like a deprecation message instead of a "command not found")
17:23:21 <ignatenkobrain> does it mean we can ask NSS maintainers to fix existing "unsupported-tools" thing?
17:23:53 <puiterwijk> jforbes: also because when you search for signtool on $search_engine, you are very likely to first find 9 pages of Microsoft's signtool.exe before you ever would get to the Fedora change page
17:24:22 <jforbes> puiterwijk: figured an rpm -ql would be more efficient than google
17:25:07 <puiterwijk> jforbes: sure, true. But I don't think everyone will know in which package signtool is located if it gets installed by default on older releases
17:25:32 <puiterwijk> (to me, "signtool" doesn't shout "nss!" from the name)
17:25:35 <kalev> I have to drop off from irc now, sorry guys, my time's up
17:26:03 <maxamillion> alright, if we lose kalev then we lost quorum and will have to cut the agenda there
17:27:02 <ignatenkobrain> well, I think you still can review RPM 4.14
17:27:07 <ignatenkobrain> because 2 members voted in ticket
17:27:15 <maxamillion> yeah, alright
17:27:22 <ignatenkobrain> (https://pagure.io/fesco/issue/1747)
17:28:00 <ignatenkobrain> obviously, I can't force you. but would be happy if you will review it ;)
17:28:11 <maxamillion> actually, two of them have votes in ticket
17:28:25 <jforbes> +1
17:28:57 <maxamillion> #info We will revisit this next week as we just lost FESCo Quorum and will only cover tickets with votes in ticket by absent FESCo members for the duration of the meeting
17:28:59 <puiterwijk> Do note that Kalev already voted on the NSS issue.
17:29:09 <maxamillion> puiterwijk: oh?
17:29:27 <puiterwijk> At least, just after you #topic'ed it, he sent a +1
17:29:27 <maxamillion> puiterwijk: I don't see a vote
17:29:38 <puiterwijk> Might be that that doesn't ocunt without a proposal, sorry in that case
17:29:54 <maxamillion> yeah, we'll just revisit for good measure
17:30:02 <maxamillion> #topic #1746 - F27 System Wide Change: Reduce Initial Setup Redundancy
17:30:03 <maxamillion> .fesco 1746
17:30:03 <maxamillion> https://pagure.io/fesco/issue/1746
17:30:03 <zodbot> maxamillion: Issue #1746: F27 System Wide Change: Reduce Initial Setup Redundancy - fesco - Pagure - https://pagure.io/fesco/issue/1746
17:30:17 <maxamillion> +1
17:31:17 <jforbes> +1
17:31:24 <Rathann> I think there was a concern that it'll be possible to end up with an installed system with no root access
17:31:57 <nirik> +1
17:33:15 <maxamillion> Rathann: oh?
17:34:20 <Rathann> until gnome-ininitial-setup runs, there will be no user account
17:34:52 <Rathann> and root account is disabled (passwordless)
17:34:58 <Rathann> if I understand things correctly
17:36:04 <maxamillion> Rathann: yeah, I think this is attempting to follow along in what other popular distro and operating systems are doing which does leave root passwordless by default
17:36:34 <Rathann> I'm +1 in general to removing redundancy, just worried about the possible side effects
17:37:00 <jforbes> Note this is limited in scope to workstation
17:37:27 <maxamillion> Rathann: I mean, it's effectively the same as the old way this was done with the first-startup service
17:38:17 <otaylor_> Rathann: If initial setup doesn't run, then a root login doesn't really help an (average) user much to get to the intended working system. Creating that first user is an essential installation step.
17:39:46 <maxamillion> Rathann: so +/- 1?
17:41:56 <Rathann> +1
17:42:07 <maxamillion> #agreed APPROVED: F27 System Wide Change: Reduce Initial Setup Redundancy (+1:5, +0:0, -1:0) (Including a +1 vote from the ticket)
17:42:18 <maxamillion> #topic #1747 - F27 System Wide Change: RPM 4.14
17:42:18 <maxamillion> .fesco 1747
17:42:18 <maxamillion> https://pagure.io/fesco/issue/1747
17:42:19 <zodbot> maxamillion: Issue #1747: F27 System Wide Change: RPM 4.14 - fesco - Pagure - https://pagure.io/fesco/issue/1747
17:42:31 <ignatenkobrain> \o
17:43:25 <jforbes> +1 here
17:43:27 <maxamillion> +1 here
17:43:27 <nirik> +1
17:44:00 <maxamillion> Rathann: ?
17:45:05 <ignatenkobrain> there is one mistake in proposal.. Contingency deadline... it is set to Alpha, but since F27 we don't have Alphas anymore ;) but I will fix it
17:46:26 <maxamillion> ignatenkobrain: +1
17:47:10 <Rathann> the Test plan sounds strange
17:47:13 <Rathann> what does it mean?
17:47:19 <maxamillion> Rathann: in what way?
17:47:53 <Rathann> "Testing is done in full operation."
17:47:58 <Rathann> what does that mean?
17:48:48 <ignatenkobrain> it means that everyone test it all the time
17:49:09 <sgallagh> .hello sgallagh
17:49:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:49:14 <ignatenkobrain> there is nothing special to test, RPM is core of system. everyone who use system, use RPM... =)
17:49:15 <Rathann> oh and one more thing, will packages built using rpmbuild 4.14 continue to work on RHEL7 and 6?
17:49:17 <sgallagh> Sorry for my long absence
17:49:27 <ignatenkobrain> Rathann: if they don't use RPM 4.14 features, yes
17:49:32 <ignatenkobrain> same as we have today
17:49:34 <Rathann> assuming one doesn't use weak or rich deps
17:49:37 <Rathann> oh, good
17:49:46 <maxamillion> I have to leave in 11 minutes
17:50:07 <Rathann> +1
17:50:12 <ignatenkobrain> =)
17:51:33 <maxamillion> Rathann: so what would you like to see added to this to resolve your concerns?
17:51:55 <maxamillion> need something more than silence to know how to move forward
17:52:07 <jforbes> maxamillion: he +1ed
17:52:23 <maxamillion> jforbes: I thought that was to me needing to leave
17:52:30 <Rathann> hehe, no
17:52:33 <maxamillion> bah!
17:52:33 <Rathann> +1 to the change
17:52:35 * maxamillion fail
17:52:38 <maxamillion> Rathann: thanks! :D
17:52:45 <maxamillion> #agreed APPROVED: F27 System Wide Change: RPM 4.14 (+1:5, +0:0, -1:0) (Including a +1 vote from the ticket)
17:53:04 <maxamillion> #topic Next week's chair
17:53:05 <maxamillion> #info jsmith volunteered last week to chair next week's meeting
17:53:07 <Rathann> ignatenkobrain: please document how to create RHEL6/7 compatible pkgs
17:53:18 <maxamillion> #topic Open Floor
17:53:50 <ignatenkobrain> Rathann: same as today. I think I mentioned it on page "Using some of the new feature will break forward compatibility.  Packages using these features will not be able be build or be installed  on older Fedora versions. Backward compatibility is expected to be  maintained. "
17:53:58 <Rathann> ah
17:54:01 <Rathann> that's fine then
17:54:10 <Rathann> it's there, yes
17:55:00 <maxamillion> anyone have anything for Open Floor?
17:55:15 <ignatenkobrain> not me
17:55:37 * nirik has nothing off hand
17:55:48 <ignatenkobrain> actually probably you can point me to some page whhich describes procedure of tickets creation by PM for FESCo
17:55:52 <maxamillion> alright, I'll give it 2 minutes and close up shop
17:56:04 <maxamillion> I don't know
17:56:04 <ignatenkobrain> because I have one more change, it was announced by wrangler but there is still no FESCo ticket
17:56:18 <sgallagh> ignatenkobrain: Which one is that?
17:56:26 <ignatenkobrain> sgallagh: https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries
17:57:12 <ignatenkobrain> I thought it is supposed to be submitted to FESCo after 7 days since announcement, but it's already more
17:57:27 <ignatenkobrain> but I wasn't able to find more information
17:57:28 <sgallagh> It is, but the Wrangler forgot to open the ticket
17:57:40 <sgallagh> The usual wrangler is on PTO, so it probably got overlooked
17:58:30 <sgallagh> Proposal: Accept the Change, as it's basically a proposal to do all the legwork for packaging guidelines, etc.
17:58:50 <maxamillion> sgallagh: +1
17:59:01 <jforbes> sgallagh: +1
17:59:04 <nirik> /me reads
17:59:36 <nirik> +1
18:00:12 <maxamillion> #info https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries
18:00:24 <maxamillion> Rathann: ?
18:01:37 <Rathann> ah
18:01:47 <sgallagh> +1 for the record
18:02:20 <Rathann> why does it need the "with" operator?
18:02:26 <Rathann> in RPM
18:02:44 <maxamillion> ignatenkobrain: ^
18:02:49 <ignatenkobrain> Rathann: because we *expect* to have in some cases 3 version of same crate to be available and 1 of which should be installed in buildroot.
18:03:02 <Rathann> ok
18:03:02 <ignatenkobrain> there is *no way* to do this $today
18:03:08 <ignatenkobrain> I mean to choose proper version
18:03:25 <Rathann> won't it work with two (Build)Requires: lines?
18:03:33 <ignatenkobrain> there are some bugs in RHBZ against RPM about "version range" syntax.
18:03:43 <Rathann> i.e. Requires: foo >= 1.0 and Requires: foo < 2.0
18:03:50 <ignatenkobrain> it can pull 2 packages instead of one and all of them are non matching
18:03:54 <ignatenkobrain> you have foo 0.9 and foo 3.0
18:03:58 <ignatenkobrain> it will pull this two
18:04:04 <ignatenkobrain> but not 1.x
18:04:45 <ignatenkobrain> this was also put on rel-eng radar some time ago (they have announced that they will try to make it, rich deps, work for f27 timeline)
18:05:15 <Rathann> well, I'm +1 to Rust in Fedora
18:05:18 <ignatenkobrain> so this problem is not new and people hit this from time to time
18:05:18 <ignatenkobrain> :)
18:05:20 <ignatenkobrain> Rathann: thanks!
18:05:29 <maxamillion> same, I'm a fan of rust
18:06:03 * ignatenkobrain notes maxamillion on #fedora-rust
18:06:06 <Rathann> ignatenkobrain: can you show me the case where what I said doesn't work?
18:06:26 <maxamillion> #agreed APPROVED: Packaging Rust applications and libraries (packaging guidelines (+1:5, +0:0, -1:0)
18:06:34 <maxamillion> alright, anything else for Open Floor?
18:06:55 <ignatenkobrain> Rathann: https://bugzilla.redhat.com/show_bug.cgi?id=1389871, https://bugzilla.redhat.com/show_bug.cgi?id=1287594
18:07:17 <ignatenkobrain> citing vondruch from one bug
18:07:30 <ignatenkobrain> BuildRequires: rubygem(minitest) >= 5.1.0
18:07:30 <ignatenkobrain> BuildRequires: rubygem(minitest) <= 5.3.1
18:07:30 <ignatenkobrain> DEBUG util.py:393:   rubygem-minitest                    noarch  5.8.1-1.fc24          build   42 k
18:07:30 <ignatenkobrain> DEBUG util.py:393:   rubygem-minitest4                   noarch  4.7.0-5.fc23          build   43 k
18:08:04 <maxamillion> I'm going to close up shop in 2 minutes if there's nothing else
18:08:08 <Rathann> right, reading that, thanks
18:08:22 <sgallagh> maxamillion: Thanks for picking up the chair today.
18:08:39 <maxamillion> sgallagh: sure thing, it's been a marathon :)
18:08:45 <maxamillion> oh
18:08:51 <maxamillion> #info maxamillion won't be at FESCo meeting next week
18:09:04 <maxamillion> I have a family thing to attend and I won't be online that day
18:10:02 <maxamillion> #endmeeting