17:00:03 <geppetto> #startmeeting fpc
17:00:03 <zodbot> Meeting started Thu Jan 31 17:00:03 2019 UTC.
17:00:03 <zodbot> This meeting is logged and archived in a public location.
17:00:03 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:03 <zodbot> The meeting name has been set to 'fpc'
17:00:03 <geppetto> #meetingname fpc
17:00:04 <geppetto> #topic Roll Call
17:00:04 <zodbot> The meeting name has been set to 'fpc'
17:00:10 <mhroncok> hi
17:00:16 <geppetto> #chair mhroncok
17:00:16 <zodbot> Current chairs: geppetto mhroncok
17:00:52 <ignatenkobrain> .hello2
17:00:53 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
17:01:07 <geppetto> #chair ignatenkobrain
17:01:07 <zodbot> Current chairs: geppetto ignatenkobrain mhroncok
17:01:12 <ignatenkobrain> I probably won't be able to stay long =(
17:01:28 * limburgher here
17:01:39 <geppetto> #chair limburgher
17:01:39 <zodbot> Current chairs: geppetto ignatenkobrain limburgher mhroncok
17:02:05 <geppetto> ignatenkobrain: ok
17:03:07 <redi> hi
17:03:23 <geppetto> #chair redi
17:03:23 <zodbot> Current chairs: geppetto ignatenkobrain limburgher mhroncok redi
17:03:35 <geppetto> Hey, redi … you are number 5 :)
17:03:41 <geppetto> So I'll start at 5 past
17:03:45 <redi> alrighty
17:06:20 <geppetto> we got a couple of tickets today, so have something to look at
17:06:29 <geppetto> #topic Schedule
17:06:34 <geppetto> #link https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
17:06:48 <geppetto> #topic  #845 Wiki deprecation status
17:06:53 <geppetto> .fpc 845
17:06:55 <zodbot> geppetto: Issue #845: Wiki deprecation status - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/845
17:07:40 <mhroncok> that summarizes as "work still needed", right?
17:08:34 <geppetto> I think so … tibbs wanted it on the agenda, but neither he nor decathorpe are here :(
17:08:43 <limburgher> Hmm.
17:08:51 <limburgher> I was just talking to tibbs. . .
17:10:11 <decathorpe> hi, sorry for being late
17:10:19 <limburgher> Six demerits.
17:10:30 <tibbs> Hey, folks.
17:10:32 <tibbs> SUper busy day.
17:10:33 <limburgher> And an essay on Charlemagne.
17:10:38 <limburgher> Same
17:10:49 <tibbs> Yeah, the wiki stuff is just a worklist.
17:10:56 <geppetto> #chair tibbs
17:10:56 <zodbot> Current chairs: geppetto ignatenkobrain limburgher mhroncok redi tibbs
17:11:01 <geppetto> #chair decathorpe
17:11:01 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok redi tibbs
17:11:17 <geppetto> tibbs: Ok, I'll move on
17:11:23 <tibbs> The one meeting question
17:11:27 <geppetto> #topic  #848 Clarify the use of path macros with respect to build dependencies
17:11:31 <geppetto> .fpc 848
17:11:32 <zodbot> geppetto: Issue #848: Clarify the use of path macros with respect to build dependencies - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/848
17:11:37 <tibbs> was whether people care about how we do redirects.
17:11:45 <tibbs> Can bring that up later.
17:12:38 <mhroncok> I'd prefer the direct one
17:12:42 <mhroncok> history is in git
17:13:07 <ignatenkobrain> generally I agree that using %{_bindir}/foo in specs is problematic
17:13:15 <ignatenkobrain> although I don't really like hardcoding /usr/bin everywhere
17:13:27 * geppetto nods … the text seems ok, although I'd drop the part in brackets
17:13:27 <ignatenkobrain> I think we need something like %{system_bindir}
17:13:40 <geppetto> ignatenkobrain: Why?
17:13:52 <ignatenkobrain> so that depending on different %{_prefix}, spec file would still work
17:14:04 <geppetto> Why not just use /usr directly?
17:14:16 <tibbs> Why not just trust PATH?
17:14:32 <tibbs> Who puts /usr/bin/cp in their specfiles?
17:14:34 <decathorpe> for scripts, trusting PATH is enough
17:14:45 <decathorpe> I think this is about BuildRequires
17:15:22 <tibbs> We do generally prefer depending on packages, not specific paths.
17:15:30 <redi> hmm, I understood it was about finding executables in the path, not naming build requirements by a path
17:15:38 <tibbs> I'm not sure I've ever seen BuildRequires: %_bindir/whatever.
17:15:41 <redi> "to locate files from build dependencies"
17:16:06 <redi> i.e. you have BR: foo and then in the %build want to run an executable provided by package foo
17:16:08 <tibbs> To be fair, both issues are valid considerations.
17:16:12 <redi> yeah
17:16:40 <mhroncok> BuildRequires: %{_bindir}/whatever. is on a lot of packages
17:16:47 <redi> and neither should use %{_bindir}
17:16:50 <tibbs> Yep, just checked; that's quite bizarre.
17:16:57 <decathorpe> is there a Provide for binaries? like "binary(foo)"?
17:17:00 <tibbs> There's basically no reason to do that.
17:17:03 <ignatenkobrain> so actually depending on a binary is good
17:17:05 <tibbs> There isn't, but there could be.
17:17:13 <ignatenkobrain> there can be executable(foo)
17:17:14 <decathorpe> that would solve the problem
17:17:20 <ignatenkobrain> and also function(foo) for shell scripts
17:17:23 <ignatenkobrain> I can work on this
17:17:29 <tibbs> Well one thing at a time, but sure.
17:17:30 <ignatenkobrain> I believe that something like that is done in ALT linux
17:17:34 <geppetto> that seems like a lot of provides
17:17:42 <redi> "binary" isn't a good name if it's a python/perl/ruby program
17:18:07 <limburgher> Executable is more generally applicable.
17:18:09 <tibbs> Actually being able to depend on executable(foo) would solve a number of number of issues.
17:18:10 <redi> although I should take that up with /usr/bin ;-)
17:18:19 <tibbs> So, yeah, can we see how feasible that is?
17:18:35 <decathorpe> I guess it could be automatically generated for executable files in PATH?
17:18:51 <tibbs> Yes, RPM could do that pretty easily I'd think.
17:18:51 <ignatenkobrain> define PATH ;)
17:19:06 <geppetto> ignatenkobrain: /usr/bin /usr/sbin ;)
17:19:10 <ignatenkobrain> the thing is that it's duplicatin metadata
17:19:12 <tibbs> In a fixed set of directories which RPM developers choose.
17:19:14 <ignatenkobrain> you already have /usr/bin /usr/sbin in primary.xml
17:19:24 <ignatenkobrain> so depending on paths is very fast
17:19:32 <geppetto> Not in dnf
17:19:41 <ignatenkobrain> even in dnf
17:19:52 <ignatenkobrain> again, those filelists in primary.xml
17:19:59 <tibbs> Main problem I see is that an executable of the same name can exist in more than one directory.
17:20:17 <ignatenkobrain> /usr/bin and /usr/sbin at the same time?
17:20:22 <ignatenkobrain> that shouldn't be a big deal
17:20:34 <decathorpe> that should hopefully be in the same package
17:20:40 <tibbs> Yes, it used to be common for things using consolehelper.
17:20:45 <tibbs> "hopefully".
17:20:45 <mhroncok> if that is provided by 2 or more packages
17:20:54 <mhroncok> then let it be provided by more packages
17:21:10 <tibbs> Still, I think it's a good idea to explore.  Nothing you do with RPM will be completely free of corner cases.
17:21:14 <mhroncok> if there are troubles, the buildrequires can be switched to a specific one of those
17:22:26 <tibbs> Also, this has the interesting possibilities when paired with dependency generation (and even the automatic build dep generation).
17:22:42 <mhroncok> right
17:23:42 <mhroncok> this will however enlarge the repo metadata by a huge amount
17:24:24 <mhroncok> I remember people arguing about providing deprecated() to be bad becasue of that and we have 17 deprecated packages, but will hve thousands of executables()
17:26:12 <decathorpe> zchunk metadata should fix that
17:26:23 <tibbs> And that would simply be part of any investigation that is done.
17:26:46 <tibbs> We can't nix a good idea because someone might complain.  Better to explore the idea.
17:27:54 <decathorpe> +1
17:28:50 <mhroncok> sure
17:28:51 <limburgher> Agreed.
17:28:54 <mhroncok> this was more of a note
17:30:44 <mhroncok> any action item from this?
17:30:56 <tibbs> ignatenkobrain mentioned that he would look into it.
17:31:05 <tibbs> I will follow along but I'm still short on time.
17:31:17 <mhroncok> (18:17:22) ignatenkobrain: I can work on this
17:31:25 <ignatenkobrain> you depend on pkgconfig()
17:31:31 <ignatenkobrain> which can be provided by multiple packages
17:31:53 <ignatenkobrain> and so far it was not a concern
17:31:54 <ignatenkobrain> so how come that depending on a file is concern now?
17:32:24 <tibbs> Sorry, what's the context?
17:33:00 <tibbs> The concern in this ticket isn't about depending on a file, it's about depending on the definition of %_bindir, basically.
17:39:15 <mhroncok> this goes nowhere
17:39:56 <tibbs> I thought we were done but then ignatenkobrain asked his question and I don't know how to answer it.
17:40:42 <mhroncok> I don't think he was following the dicussion
17:40:54 <mhroncok> (18:19:59) tibbs: Main problem I see is that an executable of the same name can exist in more than one directory.
17:41:00 <mhroncok> is what i think he was responding too
17:41:02 <mhroncok> to
17:41:09 <ignatenkobrain> sorry, I need to go and I'll try to write something up to the ticket
17:41:16 <mhroncok> ignatenkobrain: thanks
17:42:17 <redi> I have to go too, need to pick up the kid
17:43:02 <mhroncok> should we move on or cancel this?
17:44:02 <decathorpe> if there's nothing urgent, I'm fine with continuing this next week
17:44:09 <limburgher> Same
17:44:12 <geppetto> #topic Open Floor
17:44:31 <geppetto> Well nothing to move on to, afaik
17:44:37 <geppetto> I won't be around next week
17:44:56 <geppetto> So if ignatenkobrain or mhroncok want to run, then you can try that
17:45:23 * mhroncok looks into calendar
17:45:27 <geppetto> Anything else to talk about?
17:45:50 <limburgher> I have nothing.
17:45:52 <tibbs> I'm pretty much out.
17:45:54 <decathorpe> nope
17:46:05 <geppetto> tibbs: Did you want to mention something about 845?
17:46:07 <mhroncok> #action mhroncok to run the meeting next week
17:46:10 <tibbs> Just finding and fixing broken pages.  We can all do that.
17:46:19 <geppetto> mhroncok++
17:46:19 <zodbot> geppetto: Karma for churchyard changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:46:35 <geppetto> tibbs: Ok :)
17:46:36 <tibbs> For 845, the only question was whether we should simply do hard redirects from wiki pages to the new pages.
17:46:49 <mhroncok> tibbs: yes please
17:46:51 <tibbs> Right now the pages that I've completed are empty with a link at the top.
17:47:06 <geppetto> That's just to keep the history?
17:47:11 <tibbs> Hard redirects means that someone can't easily look at the old content.  That doesn't bother me.
17:47:25 * geppetto nods … I'm not bothered either way
17:47:37 <geppetto> redi: Any opinions on which is better?
17:49:34 <tibbs> I can always just undo it if someone complains.
17:49:40 * geppetto nods … fair enough
17:49:54 <geppetto> I guess do it then, if you want
17:50:11 <tibbs> RIght now the history is useful to see pages which were mangled by the conversion.
17:50:28 <tibbs> But I won't set up redirects until the new pages have been checked for errors.
17:50:39 <tibbs> And there are absolutely loads of them.
17:52:05 <geppetto> ok
17:52:53 <geppetto> Looks like that's it then
17:52:57 <geppetto> See you in a couple of weeks
17:53:00 <geppetto> #endmeeting