16:00:14 <jforbes> #startmeeting FESCO (2017-07-07)
16:00:14 <zodbot> Meeting started Fri Jul  7 16:00:14 2017 UTC.  The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:14 <zodbot> The meeting name has been set to 'fesco_(2017-07-07)'
16:00:14 <jforbes> #meetingname fesco
16:00:14 <jforbes> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:14 <jforbes> #topic init process
16:00:14 <zodbot> The meeting name has been set to 'fesco'
16:00:14 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:00:20 <jsmith> .hello jsmith
16:00:21 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:00:24 <dgilmore> hola jforbes
16:00:24 <jforbes> .hello jforbes
16:00:24 <kalev> .hello kalev
16:00:25 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:00:28 <nirik> morning everyone.
16:00:28 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:01:09 <maxamillion> .hello maxamillion
16:01:10 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:02:56 <jforbes> Well, that's quorum at least
16:03:04 <jforbes> This should be a really short meeting today
16:03:27 <maxamillion> jforbes: I just sent something to the list for inclusion, I'll bring it up during open floor
16:03:56 <jforbes> #topic #1725 F27 System Wide Change: Enable TRIM pass down to encrypted disks
16:03:57 <jforbes> .fesco 1725
16:03:57 <jforbes> https://pagure.io/fesco/issue/1725
16:03:58 <zodbot> jforbes: Issue #1725: F27 System Wide Change: Enable TRIM pass down to encrypted disks - fesco - Pagure - https://pagure.io/fesco/issue/1725
16:04:35 <jforbes> This was punted last week waiting for some answers
16:05:21 <maxamillion> there wasn't any discussion on the mailing list and I don't see the questions listed in the ticket
16:05:31 <maxamillion> who was supposed to follow up with the Change Owner?
16:05:38 <jforbes> I hadn't seen anything, but I wasn't at the meeting last week to know exactly what the deal was there
16:06:03 <jsmith> Unfortunately, I missed last week as well...
16:06:17 * nirik isnt sure what we were waiting on there either... I was/am +1 to the change.
16:07:35 <jforbes> AGREED: Proposal: Request more infromation about the security impact of this change, more technical details (including real numbers on performance impact), and raw evidence of "vast majority of users" wishes (questionaires, user studies, etc)
16:07:42 <jforbes> That was from last weeks minutes
16:07:46 <maxamillion> yeah, that was it
16:07:46 <kalev> sorry, I was missing last week, but +1 as well
16:08:05 <maxamillion> jforbes: crap, that means it was my fault ... I should have updated the ticket and I didn't
16:08:08 <maxamillion> sorry
16:08:15 <jforbes> maxamillion: you didn't update any of them :)
16:08:30 <maxamillion> jforbes: I sure didn't :/
16:08:48 <jforbes> no biggy, but since I wasn't here, I don't know what the real concerns were. I don't see anything concerning in the change
16:09:08 <jsmith> I'm generally +1 for the change -- not sure we really need a user impact study
16:09:12 <maxamillion> jforbes: the concerns were that this goes against upstream's recommendations and there's little evidence as to why it is
16:09:29 <maxamillion> I'm -1 on this one
16:09:31 <nirik> which upstream?
16:09:51 <maxamillion> nirik: I believe jwb was mentioning it goes against kernel upstream
16:09:57 <maxamillion> I would have to check the logs
16:10:36 <nirik> yeah, but.. "Changing the kernel default is of the table due to risk of data corruption with some TrueCrypt configurations involving hidden volumes. "
16:11:39 <maxamillion> the first line of the change says it's going to change the kernel default
16:11:59 <nirik> override... not change.
16:12:12 <nirik> the default is still the same, it just overrides it in /etc/crypttab
16:12:20 <maxamillion> the override doesn't impose the same issue?
16:12:30 <jforbes> Override for specific types of volumes
16:12:40 <maxamillion> just a sec, I'm reading last week's logs
16:13:10 <nirik> the override is placed there by anaconda when you install.
16:13:22 <nirik> it can be pretty sure it's not making a truecrypt hidden volume. ;)
16:14:01 <maxamillion> this line stands out from last week's logs -> 16:54:46 <jwb> i read that as "it's not safe for upstream, but screw it!"
16:14:34 <maxamillion> I don't see a clear reason or advantage for changing the default here
16:14:47 <maxamillion> at least not as written
16:15:02 <nirik> well, those people who want better i/o can... those who don't can ignore it.
16:15:18 <maxamillion> nirik: ?
16:15:49 <jforbes> maxamillion: last week we said we would ask them to clarify, considering that most of the people who were here last week are not this week, and we never asked the change owner for follow up, I would recommend that we do so and see if we get a response
16:15:52 <nirik> it enables TRIM/discards... you still need to run fstrim or whatever to use that. If you don't it doesn't matter
16:16:22 <nirik> If there's people who have questions they should ask them of change owners for sure...
16:16:31 <jforbes> But yeah, this change doesn't actually do anything but enable the functionality to work if you happen to try it
16:16:47 <maxamillion> right, which leads the question "why?"
16:17:03 <maxamillion> if you have to change something anyways, can't you just change that first?
16:17:32 <nirik> makes it easier? There are several steps... or at least there used to be
16:18:33 <maxamillion> if I'm the only one who objects, I'm willing to take the collective opinion of other FESCo members into account and I won't block the change .... maybe I'm missing something or don't fully understand the motivations for the change
16:18:42 <jforbes> And it is very hard to convert an existing volume, you would have to do it when you create if you know about it
16:18:51 <nirik> crypttab, lvm config, something with initramfs... can't recall
16:18:51 <maxamillion> I also really dislike the large generalizations made in the Change about "What our users want"
16:19:27 * nirik is fine with waiting, but this time people with questions should make sure and ask them. ;)
16:20:07 <maxamillion> yeah, I'll go update the ticket now
16:20:22 <jforbes> Those are indeed questionable. But the change itself is pretty straightforward. While the wording that jwb objected to is bad, it is clarified later in the change
16:20:52 <maxamillion> erm
16:21:06 * nirik notes also truecrypt is dead
16:21:15 <maxamillion> we can vote, if I'm the only hold out then I won't block, I trust everyone
16:21:44 <jsmith> I'm fine waiting another week if we think we can get some more detailed answers
16:21:59 <maxamillion> which ever y'all want to do
16:22:07 <maxamillion> I'm good either way
16:22:47 * jforbes notes we approved this for f26 and it get pushed back
16:23:25 <jforbes> It was only pushed back because it required installer changes that seemed late
16:23:40 <maxamillion> +1
16:24:19 * nirik doesn't care either way either... I won't be here next week, but I can +1 in ticket.
16:24:33 <jforbes> Okay, should we vote on the proposal, or are there really outstanding questions that can't be answered from old fesco logs? https://bugzilla.redhat.com/show_bug.cgi?id=1421596
16:24:52 <maxamillion> go ahead and vote
16:25:33 <jforbes> Okay Proposal: F27 System Wide Change: Enable TRIM pass down to encrypted disks is approved
16:25:41 <jforbes> +1 here
16:25:43 <kalev> +1
16:25:47 <nirik> +1
16:26:00 <jsmith> +1
16:26:05 <maxamillion> +1
16:26:16 <jforbes> #agreed F27 System Wide Change: Enable TRIM pass down to encrypted disks is approved
16:26:59 <jforbes> #topic Many packages are not following the Guidelines for bundled libraries
16:27:09 <jforbes> .fesco 1734
16:27:10 <zodbot> jforbes: Issue #1734: Many packages are not following the Guidelines for bundled libraries - fesco - Pagure - https://pagure.io/fesco/issue/1734
16:27:19 <jforbes> https://pagure.io/fesco/issue/1734
16:27:58 <maxamillion> I opened this one, I didn't realize so many packages were doing that and I'm curious if 1) we care to do anything about it? ... 2) if we do, what's the appropriate path forward to resolve?
16:28:17 <kalev> maxamillion: I see you've linked https://bugzilla.redhat.com/show_bug.cgi?id=1467322#c9 , what's wrong with the suggestion in that comment? It seems to follow exactly what the guidelines say, or am I misreading something?
16:29:41 <nirik> I thought the guidelines wanted a version? but I guess if something never had a release...
16:30:08 <maxamillion> kalev: the guidelines specifically require a <version> and neither of those suggestions provides one
16:30:14 <jforbes> There is a possibility of doing a git revision or similar in place of a version.  Everything uses scm of some sort
16:30:15 <jsmith> Personally, I'm concerned about it -- do we have an idea on the scope?  What does "so many packages" mean?
16:30:18 <maxamillion> and in the event there is no version, the git hash is the next best thing
16:30:27 <maxamillion> jforbes: right
16:30:36 <maxamillion> jforbes: a git revision is at least a version
16:30:56 <jforbes> about as specific a version as you can get actually
16:31:39 <maxamillion> jsmith: I don't have an exact number but on my machine I'm getting 101 out of this -> rpm -q -a --provides| grep bundled | grep -v '=' | wc -l
16:31:48 <maxamillion> jsmith: I don't know how far/wide that's spread
16:32:04 <jsmith> maxamillion: Sounds like a significant number...
16:32:27 <jsmith> Mass bug filing?
16:32:33 <jsmith> Other ideas on how to remediate?
16:32:48 <jsmith> (assuming, of course, we choose to try to fix it)
16:32:57 <kalev> I am not sure it's really a problem that needs addressing. As long as packages have the provides they are reasonably easy to track, and not sure a version adds that much info there
16:33:01 <nirik> 244 of those in rawhide repo
16:33:20 <nirik> kalev: the point of that is to allow fixing say security issues.
16:33:24 <maxamillion> kalev: source code auditing
16:33:29 <maxamillion> nirik: +1
16:33:35 <jsmith> kalev: When trying to fix a security issue, the version is *very* important
16:33:49 <nirik> libpng 1.2 and older has horrible bug... if they said they were based on 1.1 we would know they were affected, if they don't say we have to look at each one
16:33:50 <jforbes> I might recommend that this be brought to the FPC and the guidelines change to specify version or commit reference or similar
16:34:20 <kalev> aha, good points, I concede
16:34:24 <linuxmodder> otherwise you are stuck doing package-$RELEASE_DATE which is mroe of a pain kalev
16:35:08 <jforbes> My only concern in drawing a line in the sand in this meeting, is the ticket is literally 2 hours old. Very few people have even seen it or had a chance to comment
16:35:32 * kalev nods.
16:35:32 <maxamillion> jforbes: totally fair, I'm open to leaving this for long-term discussion if needed, I just wanted to get it on the radar
16:35:39 <nirik> yeah, I'd say a devel list thread is the way to start... see if there's interest in fixing these or some situation where no version is ok
16:36:11 <jforbes> maxamillion: I don't know that "long term" discussion is the right course, I wouldn't want it to fall off the radar. I think it is an issue that needs to be addressed
16:36:38 <jsmith> Proposal: Wait two weeks for discussion on the mailing list, and then vote
16:36:55 <jforbes> +1 jsmith
16:37:00 <maxamillion> +1 jsmith
16:37:12 <jsmith> In the meantime, ask FPC to consider clarification on what constitutes a version....?
16:37:45 <kalev> in my personal opinion, git release should be semantically part of version and not release as it is in fedora right now
16:38:15 <kalev> and that should be a good enough version for bundled provides as well
16:38:16 <jforbes> Oh, I think we can even propose what constitutes a version. Don't think there is anything out there that doesn't have either a version or revision of some sort
16:38:30 <kalev> some fonts might have?
16:38:41 <kalev> I've seen zip tarballs with just font files
16:38:51 <kalev> without any metadata added
16:39:44 <jforbes> kalev: git commit as a version isn't always best. There is a bug in kernel 4.11 is a lot easier for people to track down than a bug in git revision a351e9b9fc24e982ec2f0e76379a49826036da12
16:40:30 * kalev nods. I was just saying that in the absence of a numbered version, a git revision should be a good enough replacement
16:40:31 <jforbes> Anyone else want to vote on jsmith's proposal
16:40:47 <kalev> sure, +1 to the proposal
16:41:07 <jsmith> I'm obviously +1 for my own proposal
16:41:11 <maxamillion> jsmith: does FPC have a pagure space or somewhere to file a ticket? or should I just email the list?
16:41:14 <jforbes> nirik?
16:41:36 <nirik> sure, more discussion is fine.
16:41:39 <linuxmodder> they should have a pagure space maxamillion
16:41:41 <nirik> I don't know what we would vote on really.
16:42:07 <jforbes> #agreed Wait two weeks for discussion on the mailing list, and then vote
16:42:20 <jforbes> maxamillion: do you plan to initiate that discussion?
16:42:25 <maxamillion> jforbes: I do
16:42:42 <jforbes> #action maxamillion will initiate discussion on the mailing list
16:43:00 <dgilmore> +1 to jsmith
16:43:04 <jforbes> #topic next weeks chair
16:43:36 <jforbes> Any takers?
16:43:42 * nirik will not be here next week
16:44:21 * kalev likely won't be here either next week
16:44:28 <kalev> I should be back regularly the week after
16:44:46 <maxamillion> if nobody can, I'll take it again even though I said I wouldn't for a while ...
16:45:16 <jforbes> maxamillion: you had the last couple, I will do it again next week
16:45:46 <maxamillion> jforbes: thanks!
16:46:02 <jforbes> #info jforbes will chair next weeks meeting
16:46:07 <jforbes> #topic open floor
16:46:22 <maxamillion> should that discussion about bundled libs go to devel@?
16:46:37 <kalev> yes, definitely
16:46:41 <jforbes> maxamillion: I believe so, and copy fpc?
16:46:57 <maxamillion> +1
16:46:59 * nirik nods. yes
16:47:36 <jforbes> Okay, if no one has anything else, I will close out in 2 minutes
16:48:50 * dgilmore will not be at the next two meetings
16:49:09 <jsmith> Thanks jforbes.... thanks everyone.
16:49:21 * jsmith will be here next week, but not the week after
16:49:34 <jforbes> Yay summer!
16:49:39 <jforbes> #endmeeting