16:00:18 <geppetto> #startmeeting fpc
16:00:19 <zodbot> Meeting started Thu May 14 16:00:18 2020 UTC.
16:00:19 <zodbot> This meeting is logged and archived in a public location.
16:00:19 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:19 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #meetingname fpc
16:00:19 <zodbot> The meeting name has been set to 'fpc'
16:00:19 <geppetto> #topic Roll Call
16:00:38 <ignatenkobrain> .hello2
16:00:39 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <igor.raits@gmail.com>
16:00:45 <mhroncok> hello
16:00:46 <geppetto> #chair ignatenkobrain
16:00:46 <zodbot> Current chairs: geppetto ignatenkobrain
16:00:46 <nils> siddharthvipul, imagine it's a Cantuccio, you can keep them for months if stored in a dry place :)
16:00:48 <geppetto> #chair mhroncok
16:00:48 <zodbot> Current chairs: geppetto ignatenkobrain mhroncok
16:00:57 <geppetto> ignatenkobrain: Hey, how's it going?
16:01:37 <ignatenkobrain> geppetto: not bad, just struggling to find time to work on Fedora things :)
16:02:07 <decathorpe> .hello2
16:02:08 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
16:02:55 <tibbs> Hey, folks.
16:03:07 <geppetto> #chair decathorpe
16:03:07 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok
16:03:10 <geppetto> #chair tibbs
16:03:10 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok tibbs
16:06:07 <geppetto> #topic Schedule
16:07:06 <geppetto> Eh, it's the same it has been for a couple of weeks … https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/SN5YY2W262ZOZRBGQFOHWFI27HOECFX5/
16:07:43 <geppetto> #topic #pr-#954 Prohibit use of `rpm` command from specfile.
16:08:08 * Defolos is against that…
16:08:25 <decathorpe> .fpc 954
16:08:31 <zodbot> decathorpe: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:08:32 <ignatenkobrain> Defolos: did you see comment from pmatilai? :)
16:08:49 <ignatenkobrain> decathorpe: hey! don't break zodbot!!
16:08:57 <ignatenkobrain> I still want to receive my karma+
16:08:57 <Defolos> ignatenkobrain: don't think I have
16:08:58 * decathorpe goes home
16:09:50 <ignatenkobrain> Basically calling `rpm` from the spec is dangerous and is not recommended by RPM upstream
16:10:34 <Defolos> ok
16:10:45 <mhroncok> I don't like us forbid something without a viable alternative
16:10:50 <decathorpe> I think especially with BDB → SQLite transition this would lead to all kinds of issues :(
16:10:52 * Defolos is no longer against that
16:11:05 <Defolos> still, I'd like an alternative
16:11:18 <Defolos> essentially %requires_eq, but without calling rpm
16:11:25 <ignatenkobrain> mhroncok: there IS alternative. you can ask maintainers of foo to add RPM macro which will encode version as a macro. problem solved.
16:11:29 <decathorpe> mhroncok: is this stuff only ever used for querying package versions?
16:12:18 <ignatenkobrain> if you need some specific build of some package, you are doing something wrong
16:12:33 <ignatenkobrain> so like if you build against llvm 10, you should not require llvm-libs = 10.0.0-1.fc33
16:12:49 <ignatenkobrain> instead you should require (llvm-libs >= 10.0.0 with llvm-libs < 11.0.0) or something similar
16:12:57 <Defolos> in my case I've needd that because upstream is kinda nuts in this regard
16:13:02 <geppetto> ignatenkobrain: Eh, requiring the specific version you built against is sometimes the easiest thing to do
16:13:06 <tibbs> I think I tried to get this type of usage banned in the guidelines well over a decade ago.
16:13:11 <decathorpe> ignatenkobrain: yeah that would be an obvious solution ... something like `%echo %{version} > /usr/lib/rpm/macros.d/macros.%{name}` in the "parent" package?
16:13:25 <mhroncok> right
16:13:28 <mhroncok> but.. :(
16:13:47 <ignatenkobrain> decathorpe: yes, as one option.
16:13:48 <Defolos> it doesn't really scale
16:14:01 <Defolos> and it requires you to convince someone else to add that to their spec
16:14:02 <decathorpe> how many packages need this in fedora? 2?
16:14:02 <tibbs> Definitely +1 to banning it now.  Of course, they're just guidelines so....
16:14:22 <ignatenkobrain> decathorpe: I think 1 or 2
16:14:37 <ignatenkobrain> actually 1
16:14:41 <ignatenkobrain> samba :)
16:14:46 <decathorpe> then ban it and use macros for the 1 (or 2) packages that really need it. problem solved :shrugs:
16:14:57 <Defolos> ccls for f30 and f31
16:15:18 <geppetto> Yeh, I'm 100% fine with the solution not scaling
16:15:22 <ignatenkobrain> well, I was querying rawhide set
16:15:29 <tibbs> I do think it reasonable that mock might populate a lua table with everything it installed into the chroot, in case something really needs to get at it.  It's not that hard to drop a lua file in the right place in the chroot.
16:15:42 <ignatenkobrain> tibbs: +1
16:16:08 <ignatenkobrain> #action ignatenkobrain to open RFE for mock to populate lua table with package versions in chroot
16:16:20 <mhroncok> 19 packages in fedora call %(rpm...
16:16:26 <geppetto> That woul donly run lua at build time right? Not install time?
16:17:12 <mhroncok> %global rpm49 %(rpm --version | perl -p -e 's/^.* (\\d+)\\.(\\d+).*/sprintf("%d.%03d",$1,$2) ge 4.009 ? 1 : 0/e' 2>/dev/null || echo 0)
16:17:15 <mhroncok> oh my god
16:17:18 <ignatenkobrain> geppetto: yes, but you need it only for build time, because for install all macros are already expanded
16:17:21 <ignatenkobrain> mhroncok: lol, perl-RRD-Simple.spec
16:17:22 <ignatenkobrain> 2:%global rpm49 %(rpm --version | perl -p -e 's/^.* (\\d+)\\.(\\d+)\\.(\\d+).*/sprintf("%d.%03d%03d",$1,$2,$3) ge 4.009 ? 1 : 0/e' 2>/dev/null || echo 0)
16:17:49 <tibbs> Of course, if something wants to run rpm in %post or something, that would be a separate horror.
16:18:13 <mhroncok> https://src.fedoraproject.org/rpms/gdb-heap/blob/master/f/gdb-heap.spec#_30
16:18:55 * decathorpe will not look at those links because is already sad due to Java packages
16:19:08 <mhroncok> so the versions people query are: ppp, rpm, man-pages, glibc, mpich
16:19:11 <geppetto> decathorpe++
16:19:11 <zodbot> geppetto: Karma for decathorpe changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:19:32 <geppetto> I'm kind of surprised rpm doesn't have version macros already
16:19:38 <decathorpe> geppettoo: what was that for?
16:20:08 <geppetto> decathorpe: Too much Java needs a Karma boost
16:20:22 <decathorpe> mhroncok: so I guess storing versions for 5-6 packages in macros isn't too bad?
16:20:29 <decathorpe> geppetto: oh, thanks
16:20:34 <mhroncok> https://src.fedoraproject.org/rpms/perl-Math-Calc-Units/blob/master/f/perl-Math-Calc-Units.spec#_2 I want a drink
16:20:49 <mhroncok> decathorpe: let's do it first? ban it after?
16:21:15 <ignatenkobrain> people should not query RPM for version
16:21:19 <ignatenkobrain> simply should not, fullstop here
16:21:24 <ignatenkobrain> I mean RPM rpm ;)
16:22:19 <tibbs> libc will just tell you its version if you run it.  But sadly %libdir/libc.so is a linker script and you have to actually find the version.
16:22:43 <ignatenkobrain> so we are down to ppp_version, glibc_version, man-pages, openssl, mpich...
16:22:46 <decathorpe> Proposal: Propose a standard alternative method of keeping track of versions, and ban querying rpm from inside .spec files because of crazy prevention
16:23:08 <ignatenkobrain> decathorpe: +1, also I already took action to open mock RFE
16:23:10 <geppetto> tibbs: In that page of output?
16:23:29 <geppetto> tibbs: Also doesn't tell you the release.
16:23:56 <geppetto> decathorpe: +1
16:24:34 <tibbs> geppetto: the glibc version is in the first line.  The package release, though.... it's troubling if you would need it.
16:30:47 <geppetto> Ok, any more votes on decathorpe's proposal?
16:31:50 <mhroncok> +1
16:31:57 <tibbs> +1 in case if wasn't obvious.
16:32:15 <geppetto> Ok, I think that's it …
16:32:31 <decathorpe> yeah +5 with 5 people present is ... MVP?
16:32:55 <geppetto> #action  Propose a standard alternative and ban querying rpm from inside .spec (+1:5, 0:0, -1:0)
16:33:19 <geppetto> #topic #pr-#942 Recommend storing changelog entries in separate file.
16:33:30 <geppetto> https://pagure.io/packaging-committee/pull-request/942
16:34:15 <ignatenkobrain> hmm, do we have that macro already?
16:34:21 <mhroncok> the rpmdev-bumpspec problem is a bummer
16:34:25 <mhroncok> %autorel is in stagging
16:34:29 <mhroncok> *staging
16:35:19 <tibbs> I think it's too early to recommend this.
16:35:31 <ignatenkobrain> anyway, I am against this. We should come up with some better way of generating changelog for packages, and for sure not having people to do this.
16:35:34 <ignatenkobrain> so -1 from me.
16:35:55 <decathorpe> tibbs: yeah I don't think this is ready / a good idea yet
16:39:49 <geppetto> Ok, moving on
16:39:51 <geppetto> #topic #pr-#947 Deprecate Old Style Dependency Generators
16:39:55 <geppetto> https://pagure.io/packaging-committee/pull-request/947
16:41:10 <decathorpe> sounds good to me
16:42:02 <ignatenkobrain> +1
16:42:09 <geppetto> I'm fine with the idea … but I don't want to just ban them and turn the old macros off
16:42:21 <geppetto> some kind of "here is how to migrate" kind of doc would be nice.
16:42:49 <tibbs> I don't remember when these were deprecated.
16:43:20 <mhroncok> I'm +1 on this. this is old cruft
16:43:30 <mhroncok> even if RPm doesn't deprecate them, we should
16:43:43 <tibbs> Because if EL6 still needs them then there might be pushback.
16:43:57 <mhroncok> if there is pushback, we kill this in November
16:44:48 <tibbs> At the least, it means you have to check for those macros being wrapped in old-distro-specific %if blocks instead of just grepping.
16:45:36 <tibbs> But certainly it's old stuff that needs to go away.  I'd just like to know if there is any live release where it might still be needed.
16:46:04 <mhroncok> IIRC EPEL6 needs this
16:48:11 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K3NLDLK4XVARTSROC6XVKNVW72BMMHYE/
16:49:20 <tibbs> So I wonder what would die if we just stopped defining %filter_setup and friends.
16:49:25 <geppetto> mhroncok: I assume that's still basically the same?
16:49:40 <geppetto> tibbs: You mean in Fedora?
16:49:41 <mhroncok> geppetto: I haven't checked, but I assume the same
16:51:38 <tibbs> redhat-rpm-config has a block of macros which reference an old draft guideline that, if you follow the link, gets you to the current guidelines which don't mention those macros at all.
16:52:11 <tibbs> "Generic auto req/prov filtering macros"
16:53:39 * geppetto nods
16:53:53 <geppetto> mhroncok: Any chance you could run the thing in that email on current Fedora?
16:54:29 <mhroncok> geppetto: for the old macros?
16:55:01 <tibbs> I assume that was just for python stuff, and the true problem is worse.
16:55:07 <geppetto> mhroncok: yeh
16:55:11 <mhroncok> tibbs: yes.
16:55:18 <mhroncok> 73 packages  have %filter_setup
16:55:22 <mhroncok> not sure if conditionalized thou
16:55:42 <tibbs> But if we jut nil out %filter_setup, I wonder what actually breaks.
16:55:45 <mhroncok> sorry, just 69
16:55:52 <mhroncok> the other 4 was %% in changelog
16:57:03 <mhroncok> we could...
16:57:31 <mhroncok> change %filter_ macros to call the new macros
16:57:39 <mhroncok> and %filetr_setup to do nothing
16:58:35 <mhroncok> or wqe could just procide a way to convert it and ban it, but let it be until epel6 dies
16:58:52 <ignatenkobrain> I would prefer to just replace them with error
16:59:00 <mhroncok> or that
16:59:01 <mhroncok> heh
16:59:15 <ignatenkobrain> also, guidelines apply only to Fedora and EPEL can have their own thing
16:59:16 <decathorpe> ignatenkobrain: replace them with a lua script that prints "Igor removed this"
16:59:18 <mhroncok> we culd ban them now and replace them with error after epel6 dies
16:59:53 <tibbs> The problem is that if you call %filter_setup at all, you turn off the dependency generator completely.
16:59:58 <ignatenkobrain> decathorpe: please contact /dev/null if you want to use this macro :)
17:00:05 <decathorpe> exactly
17:00:45 <tibbs> There is a lot of potential for weird silent breakage, though.
17:01:22 <decathorpe> well, either way, maintainers will have to deal with those macros
17:01:30 <tibbs> So this is probably better done by making use of the macro an error and having everything coordinated via a change process.
17:01:44 <geppetto> Eh, I guess the same place I started ... I'm fine on voting for something that has a migration plan, but just turning it off seems like a bad idea.
17:01:44 <mhroncok> I agree
17:01:56 <decathorpe> yup, tibbs++
17:02:06 <mhroncok> BTW why do we actually generate provides for .so files in nonstandard paths?
17:02:15 <tibbs> We don't these days, do we?
17:02:19 <mhroncok> most of the usage of thos macros could just die if we don't
17:02:22 <ignatenkobrain> we don't
17:02:28 <mhroncok> tibbs: we still do, but it has to eb called lib
17:02:45 <mhroncok> /usr/lib64/python3.8/site-packages/foo.so -> no provide
17:02:45 <geppetto> I thought even that got fixed for scls?
17:02:51 <mhroncok> /usr/lib64/python3.8/site-packages/libboo.so -> provide
17:02:55 <tibbs> Of course the problem is that "nonstandard path" is subject to change by anything you might put in /etc/ld.so.conf.d, so....
17:03:01 <geppetto> Hmm, maybe scls turn it off?
17:03:15 <mhroncok> maybe it needs to start with /usr/lib(64)?
17:03:29 <mhroncok> tibbs: but does that justify automatic provides?
17:03:32 <decathorpe> I definitely needed to do this for wingpanel plugins: https://src.fedoraproject.org/rpms/wingpanel-indicator-datetime/blob/master/f/wingpanel-indicator-datetime.spec#_1
17:03:39 <decathorpe> those are named libPLUGIN_NAME.sp
17:03:57 <tibbs> mhroncok: I don't think so, but I suspect this is behavior that can't really be changed now.
17:04:19 <mhroncok> tibbs: well. ok :D
17:04:33 <tibbs> So many of these specfiles are just so old.
17:04:50 <mhroncok> I will persuit a way to exlude python dirs at least by default, so pyrthon packages can get rid of this for good
17:05:18 <geppetto> mhroncok++
17:05:18 <zodbot> geppetto: Karma for churchyard changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:05:30 <mhroncok> proposal:
17:05:44 <mhroncok> we turn the %filter macros to error to avoid silent failures, we ban them
17:05:46 <geppetto> #action mhroncok to look at how python can get fixed for automatic lib provides
17:05:51 <mhroncok> this is coordianted via a fedora change process
17:06:05 <decathorpe> proposal ++
17:06:15 <tibbs> +1 to that.
17:06:33 <mhroncok> decathorpe: want to drive this together with me?
17:06:40 <geppetto> As long as someone is going to help people with the fallout who are like "wtf do I do now", I'm +1
17:06:59 <decathorpe> mhroncok: more work, yey
17:07:00 <tibbs> libxsmm uses filter_setup to remove dependencies generated by documentation.
17:07:05 <tibbs> I wonder how common that is.
17:07:09 <decathorpe> :D
17:07:15 <mhroncok> tibbs: shebang depndencies?
17:07:31 <decathorpe> shouldn't those not get generated anymore
17:07:32 <tibbs> %filter_from_requires /\/bin\/.*sh$/d
17:07:33 <geppetto> #action decathorpe will help mhroncok
17:07:58 <tibbs> These packages need to be built with and without %filter_setup defined to %nil, and their dependency lists compared.
17:08:43 <tibbs> I count 99 packages that contain %filter_setup.
17:09:16 <decathorpe> mhroncok: doing some test builds in COPR should do?
17:09:17 <tibbs> And several packages seem to expect that %filter_setup just won't be defined in newer releases.
17:10:19 <mhroncok> tibbs: %{?filter_setup}
17:10:23 <mhroncok> Ok, I count 99
17:10:25 <mhroncok> 93
17:11:01 <mhroncok> 97, omg, doesn'T matter ~100
17:11:06 <tibbs> There seems to be a block of code copied around that has "RPM 4.8 style" and "RPM 4.9 style" blocks, with the assumption that you tell which is which by whether %filter_setup is defined.
17:11:18 <mhroncok> :D
17:11:42 <decathorpe> tibbs: take torch with you when you decend into those depths, please
17:13:21 <tibbs> Anyway, it should be relatively obvious why this is bad (disabling the dependency generator should be enough) and it's only a hundred packages so fixing it should be doable with a bit of effort.
17:14:06 <geppetto> Ok
17:14:27 <geppetto> #action tibbs agrees to fix everything else :)
17:15:25 <geppetto> I kind of assume we are at +5 though
17:15:53 <ignatenkobrain> I think so
17:16:46 <tibbs> Making sure it's not needed for python should cut the numbers down a bit.  A number of Perl things use it too, and apache modules.
17:16:56 <geppetto> Yeh
17:17:10 <tibbs> %filter_requires_in %{_docdir}
17:17:14 <tibbs> I see that a bit as well.
17:17:20 <geppetto> #action turn the %filter macros to error to avoid silent failures, we ban them (+1:5, 0:0, -1:0)
17:17:40 <tibbs> Seems smarter just to not install executable documentation at all.
17:18:00 <geppetto> yeh, like chmod -x -r docs
17:18:08 <decathorpe> wasn't there already a change to the macros to not generate dependencies for things in docdir?
17:18:23 <decathorpe> (seems to remember something from last year)
17:18:47 * mhroncok has to go now, sorry
17:19:12 <tibbs> I don't see anything like that, except that the perl macros add %_docdir to __*exclude_from.
17:19:23 <geppetto> mhroncok: yeh, we are almost 20 minutes over
17:19:28 <ignatenkobrain> decathorpe: rpm already does not do so IIRC, but I might be wrong
17:19:33 <decathorpe> huh ... I must misremember
17:19:52 <tibbs> But only if you call %perl_default_filter, of course.
17:20:07 * ignatenkobrain sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ltzcnrjuoLnVHeTEdFjhiwkW >
17:20:09 <tibbs> ANyway, I'm just rambling.  I think we've done enough.
17:20:26 <ignatenkobrain> been there since rpm-4.14.0-rc1
17:20:30 * geppetto nods … ok, I'm going to close
17:20:36 <decathorpe> oh so I do remember correctly
17:20:42 <decathorpe> thanks geppetto!
17:21:19 <geppetto> Thanks everyone … got a bunch done this week. Keep staying safe etc.
17:21:28 <geppetto> #endmeeting