16:13:18 <tibbs> #startmeeting fpc
16:13:18 <zodbot> Meeting started Thu Aug 16 16:13:18 2018 UTC.
16:13:18 <zodbot> This meeting is logged and archived in a public location.
16:13:18 <zodbot> The chair is tibbs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:13:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:13:18 <zodbot> The meeting name has been set to 'fpc'
16:13:18 <mhroncok> ok
16:13:23 <tibbs> #meetingname fpc
16:13:23 <zodbot> The meeting name has been set to 'fpc'
16:13:29 <tibbs> #chair tibbs
16:13:29 <zodbot> Current chairs: tibbs
16:13:33 <tibbs> #chair decathorpe
16:13:33 <zodbot> Current chairs: decathorpe tibbs
16:13:38 <tibbs> #chair ignatenkobrain
16:13:38 <zodbot> Current chairs: decathorpe ignatenkobrain tibbs
16:13:43 <tibbs> #chair mhroncok
16:13:43 <zodbot> Current chairs: decathorpe ignatenkobrain mhroncok tibbs
16:13:50 <tibbs> That should do it.
16:13:54 <mhroncok> thanks
16:14:00 <mhroncok> #topic Next meeting
16:14:12 * ignatenkobrain is volunteering
16:14:22 <ignatenkobrain> (to be a chair for next meeting)
16:14:22 <mhroncok> #action ignatenkobrain to run next week meeting
16:14:29 <tibbs> Thanks.
16:14:40 <mhroncok> #topic Open floor
16:14:44 <tibbs> Any other folks we can ping?
16:15:34 <mhroncok> orionp redi
16:15:51 <redi> oh hai
16:15:58 <tibbs> #chair redi
16:15:58 <zodbot> Current chairs: decathorpe ignatenkobrain mhroncok redi tibbs
16:16:05 <tibbs> That actually makes quorum.
16:16:33 <ignatenkobrain> ha!
16:17:19 <mhroncok> can we approve things with 5 votes?
16:17:22 <tibbs> Yes.
16:17:48 <redi> I've got my voting hat on
16:18:10 <tibbs> Only two tickets tagged as meeting received updates since the previous meeting three weeks ago.
16:19:12 <decathorpe> I updated the Source URL wiki page for the new GitLab things
16:19:18 <tibbs> Thanks for that.
16:19:20 <decathorpe> did anybody look at it?
16:19:40 <tibbs> My problem is that I have never used gitlab so I can't tell if anything is correct or not.
16:19:50 <tibbs> https://fedoraproject.org/wiki/Packaging:SourceURL
16:19:53 <decathorpe> (it works, I'm using it for my own packages)
16:20:03 <tibbs> https://fedoraproject.org/w/index.php?title=Packaging%3ASourceURL&type=revision&diff=523477&oldid=523390
16:20:19 <decathorpe> The page still needs work in the "git submodules" section, which I didn't touch
16:20:44 <redi> nobody should ever touch git submodules
16:21:17 <decathorpe> redi: agreed, but some packages use them ...
16:21:21 <tibbs> We could certainly consider extending the existing forge macros to simplify some of these cases.
16:21:51 <tibbs> And note that "some" packages using them doesn't really mean that they have to be in packaging guidelines.
16:22:12 <tibbs> If it's so many that there is benefit in standardization, then certainly.
16:22:40 <tibbs> If it's enough that packagers get it wrong often then it's worth considering.
16:22:40 <redi> decathorpe: the gitlab URL change looks right, just tested it with one of my projects hosted there
16:23:18 <tibbs> But otherwise I just wouldn't put such things into the actual guidelines.
16:23:34 <decathorpe> we could mention that the scheme should also apply to hosted gitlab instances, like gitlab.gnome.org
16:23:49 <decathorpe> tibbs: sure, that's only technicalities
16:26:22 <tibbs> Note that teh existing forge macros do support gitlab.
16:26:45 <decathorpe> yeah, but that's not an excuse for wrong information on the wiki page :)
16:27:13 <tibbs> Not sure what context that's in.
16:27:40 <tibbs> If you're talking about submodules, I was trying to say that we might just be better off removing that stuff entirely rather than trying to correct it.
16:27:55 <decathorpe> I agree
16:28:05 <mhroncok> I agree as well
16:28:47 <tibbs> Well I'm +1 to removing it.  We can always add it back later if it's really needed.
16:29:24 <redi> +1 to pretending submodules don't exist in the guidelines
16:29:37 <tibbs> What it talks about seems rather overcomplicated and since each project is going to be different I don't know if we could reasonably give a full treatment of it.
16:29:59 <tibbs> Well if ignatenkobrain agrees then we can just nuke the section.
16:30:10 <redi> if somebody figures out a consistent and sane way to recommend using them (that works for most packages) they can write a better guideline
16:30:11 <ignatenkobrain> +1
16:30:20 <decathorpe> +1
16:30:24 <decathorpe> I'll go ahead and remove it
16:31:44 <mhroncok> +1 (in case it's needed to be literal)
16:32:06 <decathorpe> done
16:33:18 <tibbs> #agreed We should remove the outdated "Git Submodules" section from Packaging:SourceURL (+5, 0, -0)
16:33:28 <tibbs> I assume that works.
16:33:48 <tibbs> .fpc 714
16:33:50 <zodbot> tibbs: Issue #714: let's kill file deps! - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/714
16:34:02 <tibbs> That one is still grinding around.
16:34:10 <decathorpe> tibbs: we just approved the Open Floor topic ;)
16:34:14 <ignatenkobrain> ah
16:34:16 <ignatenkobrain> so let me just to summarize from my POV
16:34:26 <tibbs> Ah, we agreed something.  Not sure the topic really matters.
16:34:33 <ignatenkobrain> as a FPC we should make a list of directories with "good" dependencies
16:34:51 <tibbs> Well, maybe.
16:34:57 <ignatenkobrain> that would be /usr/s?bin/* /etc/*
16:35:01 <ignatenkobrain> everything else people SHOULD NOT use
16:35:06 <tibbs> Is that actually up to us?  I thought it was hardcoded in various places in infrastructure.
16:35:07 <mhroncok> I'd say that it's on us
16:35:19 <ignatenkobrain> tibbs: it's partially on us
16:35:26 <mhroncok> but we can make a stand about what should be hardcoded
16:35:29 <nirik> Just to interject... what was the downside to just making createrepo_c include all those in the smaller repodata file?
16:35:43 <ignatenkobrain> nirik: which one is that?
16:35:49 <ignatenkobrain> which contains list of dirs in primary?
16:36:00 <tibbs> I thought that's how createrepo_c already worked.
16:36:13 <tibbs> But there is still confusion over what the actual lists are.
16:36:15 <nirik> it splits them now according to what dir they are in I thought?
16:36:30 <ignatenkobrain> tibbs: it's not confusion, it's hardcoded in createrepo_c
16:36:31 <tibbs> And also the question of libexec.
16:36:59 <tibbs> We don't have a lot to talk about if we're just going to document what createrepo_c does.
16:37:09 <ignatenkobrain> https://github.com/rpm-software-management/createrepo_c/blob/eb61dac3ca96f4bc240431011756397f9217c9cf/src/misc.h#L105-L118
16:37:23 <ignatenkobrain> right now, libexec is not included
16:37:27 <nirik> so why not have it not split them, instead it just looks all the filedeps in the repo and puts those in the 'smaller' one. I guess that breaks cross repo stuff.
16:37:29 <tibbs> ... /usr/lib/sendmail ?
16:37:54 <ignatenkobrain> so my proposal for us would be to document which files are in primary and say you MAY use them. everything else you SHOULD NOT
16:38:00 <ignatenkobrain> tibbs: historical reasons
16:38:17 <ignatenkobrain> nirik: yeah
16:38:19 <decathorpe> ignatenkobrain: "which files are in primary and say you MAY use them. everything else you SHOULD NOT" sounds reasonable
16:38:25 <mhroncok> nirik: because we want to ban soem crazy ones?
16:38:26 <tibbs> I know, but if we're going to pretend to clean it up then we should actually clean it up.
16:38:54 <nirik> ok, sure, but if it handled it in case it would be much nicer...
16:39:04 <tibbs> And also it seems to include anything in any directory that ends with "bin".
16:39:07 <mhroncok> nirik: we cannot say: we put everyhting form fedora in the "smaller one" and at the same time: what's not in "smaller one" should not be used in Fedora
16:39:24 <nirik> sure you can... while they get cleaned up. :)
16:39:43 <mhroncok> nirik: we would ahve no ground to remove any
16:39:59 <mhroncok> as if they are there now they would be in "smaller one" and hence approved
16:40:08 <ignatenkobrain> there is not much to clean up ,  there are ~30 packages doing Req: /usr/share/foo/bar/baz
16:40:43 <ignatenkobrain> also this would make fedora incompatible with the rest of the world
16:40:46 <ignatenkobrain> let's just stick with what createrepo_c does
16:40:51 <ignatenkobrain> (SUSE also uses createrepo_c IIRC)
16:40:54 <ignatenkobrain> also, this would need downstream patch of libsolv)
16:41:03 <ignatenkobrain> so just don't do it
16:41:24 <ignatenkobrain> let's document behavior of createrepo_c and say you MAY use what it includes, everything else you SHOULD NOT
16:41:39 <tibbs> So in order words, this isn't on us.  We can only document what the tool does and are not at liberty to change it.
16:41:57 <mhroncok> we may drive the change if we thing that the current list is wird
16:42:06 <mhroncok> for example, including anything that ends with /bin
16:42:14 <mhroncok> /usr/lib/sendmailor
16:42:19 <mhroncok> *or /usr/lib/sendmail
16:42:36 <decathorpe> we could ask for different patterns in createrepo_c?
16:42:54 <decathorpe> they seem ... arbitrary and, in the case of *bin/, wrong
16:43:04 <tibbs> Which we couldn't necessarily get if that breaks other distros.
16:44:06 <mhroncok> we might at least get the lsit as we would like it
16:44:19 <mhroncok> guideline approve what's in intersection of those
16:44:27 <tibbs> I still just don't get why this deserves so much discussion.  Clean up the packages which already violate our guidelines.  Maybe reword the current language in our guidelines to make them clearer if people are being confused by them.
16:44:33 <ignatenkobrain> tibbs: we still need to rephrase our page
16:44:39 <mhroncok> and talk to createrepo_c upstream + downstream about the reesoans fior the current list they ahve
16:44:45 <ignatenkobrain> yes, our words are confusing
16:44:54 <tibbs> So we can talk about that.
16:44:59 <tibbs> What would be less confusing?
16:45:20 <tibbs> "Packages SHOULD NOT include file deps outside of the following directories:" ?
16:45:23 <ignatenkobrain> right now if I understand we kinda prohibit any file dependencies
16:45:29 <ignatenkobrain> right?
16:45:30 <tibbs> No, it's a should not.
16:45:55 <mhroncok> Packages SHOULD NOT include file deps outside of the following directories: --- +1 to that
16:46:03 <tibbs> https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Dependencies
16:46:25 <tibbs> Says " Whenever possible you SHOULD avoid file and directory dependencies as they slow down dependency resolution and require the package manager to download file lists in addition to to regular dependency information. There are, however, times when other technical considerations outweigh these considerations. If the files or directories you need are prone to moving between packages of different names, it can be useful to depend on those files
16:46:27 <tibbs> directly. "
16:46:52 <ignatenkobrain> first paragraph is even wrong
16:46:55 <decathorpe> at worst, this is outdated, because dnf always downloads additional stuff
16:47:07 <ignatenkobrain> because they don't slow down anything
16:47:07 <tibbs> It was correct for yum; it could be correct for dnf one day.
16:47:09 <ignatenkobrain> so I would simplify to what tibbs said
16:47:16 <ignatenkobrain> second paragraph is good (about directory dependencies)
16:47:28 <ignatenkobrain> tibbs: it will download primary.xml anyway which already contains those files
16:47:41 <tibbs> In general guidelines don't need justification like "because it slows things down".
16:47:45 <ignatenkobrain> so even it gets corrected one day, that won't change our guidelines
16:47:53 * mhroncok is writing something up
16:48:01 <tibbs> You can probably tell that I wrote the second paragraph but not the first one.
16:48:20 <ignatenkobrain> await mhroncok_writeup
16:49:50 <mhroncok> RPM gives you the ability to depend on arbitrary files or directories instead of packages.
16:49:50 <mhroncok> Witch some package managers, this may slow down dependency resolution, except for files in special directories listed bellow.
16:49:50 <mhroncok> There are, however, times when other technical considerations outweigh these considerations. If the files or directories you need are prone to moving between packages of different names, it can be useful to depend on those files directly.
16:49:50 <mhroncok> Packages SHOULD NOT include file deps outside of the following directories:
16:49:50 <mhroncok> * ...
16:50:04 <mhroncok> (keep the second paragraph after the list)
16:51:02 <ignatenkobrain> can we just simplify to just one line which tibbs wrote?
16:51:15 <tibbs> We don't need the justification at all, really.
16:51:23 <ignatenkobrain> RPM gives you the ability to depend on arbitrary files or directories instead of packages.
16:51:23 <ignatenkobrain> Packages SHOULD NOT include file dependencies outside of the following directories:
16:51:24 <ignatenkobrain> ...
16:51:34 <mhroncok> that depends on whether we want rationae in there or just random rules people will ignore if they don't know the reasons
16:51:45 <tibbs> The latter, generally.
16:51:51 <mhroncok> ok
16:51:56 <mhroncok> in that case, what ignatenkobrain said
16:51:58 <mhroncok> +1
16:52:01 <tibbs> We can't include any rationale here which is actually going to be correct.
16:52:44 <tibbs> Because with the dnf we have today, it makes no difference.
16:52:54 <ignatenkobrain> probably we would want one line saying `If you call binary from directories above, you SHOULD use file dependency"
16:52:58 <decathorpe> I'd like it to mention that this is due to hardcoded entries in createrepo_c. (Not as rationale, just as explanation for the somewhat arbitrary list)
16:53:06 <ignatenkobrain> so that if we move binary somewhere, it doesn't break packages
16:53:06 <tibbs> ignatenkobrain: I would rather disagree with that.
16:53:19 <ignatenkobrain> tibbs: why?
16:53:20 <tibbs> I mean, we want people to depend on gcc, not /usr/bin/gcc.
16:53:48 <ignatenkobrain> yes, but at the same time we don't want ppl to depend on python3-grokmirror, but rather on /usr/bin/grok-pull
16:54:01 <tibbs> I disagree.  We do want people to depend on the package.
16:54:08 <ignatenkobrain> because recently binary got moved from python2 to python3 which broke some packages; )
16:54:12 <mhroncok> ignatenkobrain: I agree, but let's create a separate ticket for this
16:54:20 <tibbs> Yes, things move and then there is work to do.
16:54:29 <mhroncok> it's congtroversial topic and should not block this one
16:54:39 <ignatenkobrain> mhroncok: fine with me
16:54:58 <ignatenkobrain> so vote on my 3 lines from above?
16:55:32 <tibbs> +1 but we do need to actually fill in the list.
16:56:01 <mhroncok> +1 and we fill in the list later
16:56:02 <ignatenkobrain> - /usr/bin/*
16:56:02 <ignatenkobrain> - /usr/sbin/*
16:56:03 <ignatenkobrain> - /etc/*
16:56:09 <ignatenkobrain> this would be my proposal to that
16:56:23 <tibbs> I still think there is a use case for /usr/libexec/*.
16:56:23 <mhroncok> no sandmail then?
16:56:27 <ignatenkobrain> even it doesn't include ALL directories createrepo_c pulls in, it's LOGICAL
16:56:42 <ignatenkobrain> tibbs: I agree, but now we can't put it
16:56:48 <tibbs> Indeed.
16:56:49 <mhroncok> tibbs: I agree, but apparently, we decided not to include it now, maybe we can fix createrepo first and add this later
16:56:51 <ignatenkobrain> until we change createrepo_c
16:57:09 * decathorpe shrugs
16:57:21 <tibbs> And now you see why I think this is premature.
16:57:32 <ignatenkobrain> redi: decathorpe vote?
16:57:56 <tibbs> Well, actually we can put anything we want in this list.
16:58:02 <mhroncok> :D
16:58:14 <decathorpe> +1 (adding a comment that this list of dirs is derived from createrepo_c would be nice though)
16:58:17 <tibbs> Because it doesn't matter what createrepo puts in the smaller metadata.  dnf will download all of it anyway.
16:58:18 <mhroncok> UNLIMITED POWER!
16:58:37 <ignatenkobrain> redi: ?
16:58:50 <redi> just catching up ...
16:59:15 <ignatenkobrain> redi: my proposal was on 16:51 UTC
16:59:30 <tibbs> This change makes zero technical difference to anything.  We're just cleaning up the language here.
16:59:34 <redi> +1
16:59:47 <redi> yup
17:00:01 <tibbs> And in any case, FESCo could make a different decision.
17:00:27 <ignatenkobrain> tibbs: so it makes us +5
17:00:39 <tibbs> Because in case everyone isn't aware, there is a parallel fesco ticket.
17:01:09 <tibbs> #agreed New language for https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Dependencies (+5, 0, -0)
17:03:11 <ignatenkobrain> just to give you context why /usr/libexec is not there from my POV: libexec is redhat-ism and other people use $prefix/lib for this purposes (e.g. systemd) but we have a lot of stuff in /usr/lib which actually should be in /usr/share
17:03:25 <ignatenkobrain> so including libexec is not actually full solution to problem
17:03:42 <ignatenkobrain> erlang guys already moved their noarch code into /usr/share, I hope we can move our python stuff there at some point too
17:03:44 <ignatenkobrain> but anyway, I think we are out of time
17:03:44 <tibbs> libexec rather predates redhat, I think.
17:03:49 <ignatenkobrain> anyone has anything else?
17:04:19 <tibbs> Please double check that the last comment in https://pagure.io/packaging-committee/issue/714 is correct and I'll get it written up.
17:04:37 <mhroncok> ignatenkobrain: it's backed by FHS
17:05:12 <mhroncok> tibbs: outside of the following directories + the asterisks -> consusing
17:05:16 <mhroncok> I'd remoe them
17:05:29 * limburgher is late.
17:05:44 <mhroncok> limburgher: justa  bit
17:05:44 <limburgher> Super late.
17:06:21 * ignatenkobrain sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/oQiCdfmMBwgWleiklmjYpunv >
17:06:29 <mhroncok> (or is it just bad markdown?)
17:06:40 <ignatenkobrain> so full solution to createrepo would be including both lib and libexec, but this is impractical
17:06:43 <ignatenkobrain> so we would need to do some serious work before... or implement it partially
17:06:57 <ignatenkobrain> anyway, irrelevant at this point
17:07:22 <ignatenkobrain> so, any other topics?
17:07:30 <decathorpe> I have two questions
17:07:31 <ignatenkobrain> I would rather not to rathole on this
17:07:38 <tibbs> Sorry, there was a line at my door all of a sudden.
17:07:41 <ignatenkobrain> tibbs: agree with mhroncok about asterisks
17:07:44 <ignatenkobrain> decathorpe: go ahead!
17:08:05 <tibbs> Removed asterisks and trailing slashes.
17:08:34 <decathorpe> 1) anybody else experiencing local and COPR mock issues with rawhide build roots? I get GPG errors for two days now
17:08:51 <tibbs> Yes, everyone.
17:08:56 <mhroncok> for /etc is it anything in it or just direct? i.e. /etc/a/b/c/d/a/b/f/g/foo.stuff is still ok?
17:09:05 <decathorpe> tibbs: ok, good
17:09:08 <ignatenkobrain> tibbs:  btw, SUSE entirely prohibited deps on anything outside of those dirs (your package just doesn't build)
17:09:11 <ignatenkobrain> mhroncok: anything under /etc
17:09:21 <mhroncok> decathorpe: https://bugzilla.redhat.com/show_bug.cgi?id=1618442
17:09:34 <tibbs> mhroncok: The createrepo_c code earlier was just a string prefix match.
17:09:49 <mhroncok> ok
17:09:56 <decathorpe> ignatenkobrain: ah, thanks
17:10:40 <tibbs> I sincerely wish we could fail builds for more violations.
17:10:41 <decathorpe> 2) tibbs, thanks for merging my redhat-rpm-config pull request - can I get a build containing that change in f27/8/9 too? it's only on rawhide right now. should I submit new pull requests for those releases?
17:11:12 <mhroncok> tibbs: yes please
17:11:46 <decathorpe> This is one of the things that will hopefully let us move forward on the forge stuff
17:16:31 <mhroncok> I will eventually need to go
17:16:43 <decathorpe> me too, I'm hungry :D
17:16:54 <mhroncok> I'm just tired
17:18:21 <tibbs> Sorry, more people at the door.
17:18:23 <mhroncok> tibbs: are you there?
17:18:26 <mhroncok> oh
17:18:35 <tibbs> I think we're done here, but any chair can end the meeting.
17:18:49 <mhroncok> there was a question from decathorpe
17:19:16 <decathorpe> It's not that important, since nim isn't updating his draft anyway
17:19:21 <tibbs> decathorpe: This was the forge thing?  I will backport and submit updates and overrides today.
17:19:32 <decathorpe> that's awesome. thank you!
17:19:40 <tibbs> Getting that documented and guideline-d is going to fall to us.  I have it on my list.
17:19:57 <decathorpe> me too. used the macros for some packages already.
17:20:21 <tibbs> So have I.  It works well but there is some weirdness that I still need to work through.
17:20:28 <decathorpe> true
17:21:20 <tibbs> And unfortunately the fedora-release package has a typo which I'm trying to get fixed.  If it was fixed, the forge macros wouldn't need to modify %dist.
17:21:47 <tibbs> At least not in F29+.
17:22:18 <tibbs> Anything else?  I fear another line will form at my door soon.
17:22:27 <decathorpe> not from me. thanks :)
17:22:32 <tibbs> The semester starts Monday so it's busy around here.
17:22:56 <tibbs> Well, everyone, thanks for coming!
17:23:00 <tibbs> #endmeeting