Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net.
Local time information (via. uitime):
================= Day: Thursday ==================
2019-08-15 09:00 PDT US/Pacific
2019-08-15 12:00 EDT --> US/Eastern <--
2019-08-15 16:00 UTC UTC
2019-08-15 17:00 BST Europe/London
2019-08-15 18:00 CEST Europe/Berlin
2019-08-15 18:00 CEST Europe/Paris
2019-08-15 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2019-08-16 00:00 HKT Asia/Hong_Kong
2019-08-16 00:00 +08 Asia/Singapore
2019-08-16 01:00 JST Asia/Tokyo
2019-08-16 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followups =
#topic #902 Cleanup & enhance spec files
.fpc 902
https://pagure.io/packaging-committee/issue/902
#topic #904 Caret versioning
.fpc 904
https://pagure.io/packaging-committee/issue/904
#topic #907 Which %__foo macros for executables are acceptable?
.fpc 907
https://pagure.io/packaging-committee/issue/907
#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909
#topic #914 Automatic R runtime dependencies
.fpc 914
https://pagure.io/packaging-committee/issue/914
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:33 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-28/fpc.2020-05-2…
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:33)
* Schedule (geppetto, 16:05:22)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject…
(geppetto, 16:05:24)
* 982 Fonts packaging stopped working etc. (geppetto, 16:06:15)
* ACTION: tibbs will merge redhat-rpm-config PR and see if anyone
complains (geppetto, 16:34:19)
* ACTION: ignatenkobrain to blame geppetto if redhat-rpm-config
maintainers will not be happy with tibbs merge (ignatenkobrain,
16:43:30)
* #977 Get new members? (geppetto, 16:46:45)
* Open Floor (geppetto, 16:52:46)
Meeting ended at 16:55:57 UTC.
Action Items
------------
* tibbs will merge redhat-rpm-config PR and see if anyone complains
* ignatenkobrain to blame geppetto if redhat-rpm-config maintainers will
not be happy with tibbs merge
Action Items, by person
-----------------------
* geppetto
* ignatenkobrain to blame geppetto if redhat-rpm-config maintainers
will not be happy with tibbs merge
* ignatenkobrain
* ignatenkobrain to blame geppetto if redhat-rpm-config maintainers
will not be happy with tibbs merge
* tibbs
* tibbs will merge redhat-rpm-config PR and see if anyone complains
* ignatenkobrain to blame geppetto if redhat-rpm-config maintainers
will not be happy with tibbs merge
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* geppetto (82)
* tibbs (41)
* ignatenkobrain (30)
* decathorpe (27)
* zodbot (13)
* limburgher (1)
* mhroncok (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Hello Python packagers.
After touching the %python_provide topic in:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj…
I have realized several things I don't like about %python_provide:
1) It must be used conditionally (it is not defined in python-srpm-macros).
That means you always wrap it in %{?python_provide:...} in order to have a
"valid" specfile even when the macro is not yet defined (e.g. during SRPM
creation in Koji or on a packager's machine without python-rpm-macros installed).
2) You cannot use it with arbitrary versions. Suppose you package python3-foo
1.0 but you want to provide python3-bar 2.0 for some reason -- this is not very
common, but it happens. %python_provide only takes the "name" as an argument,
always using %{?epoch} %{version} and %{release}.
3) You need to both add a virtual provide + use the macro. Suppose you want to
provide python3-pkg_resources from python3-setuptools. Currently, you need to add:
Provides: python3-pkg_resources = %{version}-%{release}
%{?python_provide:%python_provide python3-pkg_resources}
4) When used with (sub)package name, it generates a duplicate dependency on
Fedora 33+ (and an rpmlint error).
5) It produces Obsoletes, but that might no longer be necessary nor desired.
6) Broken expectations about %_isa. It used to add %_isa provides based on wrong
data, it no longer does that (except on old releases and EPELs), can be used
manually with name%{?_isa}, but not on the old releases.
7) Undocuemnted error handling (e.g. the macro expands to nothing when used with
pypy-foo, but errors when used with foo).
Hence, I was thinking (for the sake of backwards compatibility) to provide a new
mechanism to do this and preserve the old macro as is, deprecating it in Fedora
36-ish, actually maybe removing it once RHEL 9 goes EOL (or never, which is
basically the same from today's perspective).
The new macro should solve the problems from above, my current (quick, untested)
ideas are:
1) Define the macro in python-srpm-macros. No need to use it conditionally. We
can backport it to EPEL 8 and define a "stub" macro in EPEL 7 and 6. (An if we
start using the macro only after Fedora 30 goes EOL, we can make the macro
behave consistently across all Fedora versions.)
2) Accept version identifier as an optional argument, use %{?epoch} %{version}
and %{release} as default. (See for example %{pypi_source} on how this can be done.)
3) Make the macro also produce the provide for the given name and document that.
E.g. when you call it with python3-pkg_resources, it also provides
python3-pkg_resources (not only python-pkg_resources etc.).
4) Make it so that for given arguments, the macro will only expand to something
once per build. Hence when you use it with package name, the automatic provides
won't re-add the same provide again. This also means you cannot have 2 different
(sub)packages provide the same name-version-release, but that shall be very very
very uncommon need and can always be workarounded somehow if needed.
5) No obsoletes with the new macro. Packagers use manual obsoletes when desired.
6) Document clearly that there is no %{?_isa} (and there is no "backwards
compatibility" load to carry). When absolutely desired, packagers can call the
macro with %{name}%{?_isa}.
7) Support arbitrary names. Only provide the given name and nothing else if not
"recognized".
As a bonus, I think the current if-elif-elif-elif-elif code can be replaced with
lua patterns (imagine regex).
As always, this leaves us with the name problem, but I'd very much like to use
%python_provides (note the s). The only problem I see is that it is likely to be
mistaken for the old one, but IMHO it shouldn't really hurt that much.
Usage example:
%package -n python3-setuptools
%python_provides python3-pkg_resources
Resulting provides:
python3-setuptools = 46.6.6-6.fc33
python-setuptools = 46.6.6-6.fc33
python39-pkg_resources = 46.6.6-6.fc33
python3-pkg_resources = 46.6.6-6.fc33
python-pkg_resources = 46.6.6-6.fc33
python39-pkg_resources = 46.6.6-6.fc33
Another example:
%package -n python3-pillow
%python_provides python3-PIL 1.1.6-100
Resulting provides:
python3-pillow = 7.1.1-1.fc33
python-pillow = 7.1.1-1.fc33
python39-pillow = 7.1.1-1.fc33
python3-PIL = 1.1.6-100
python-PIL = 1.1.6-100
python39-PIL = 1.1.6-100
Dummy when used with package name:
%package -n python3-pip
%python_provides python3-pip
Provides:
python3-pip = 20.0.2-1.fc33
python-pip = 20.0.2-1.fc33
python39-pip = 20.0.2-1.fc33
(all of them only once)
Any name is OK:
%python_provides wroom 666
Provides:
wroom = 666
What do you think?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Sharing this in case others find it useful. There is a way to have IPython-like
RPM Lua interactive console for easier debugging of RPM Lua:
https://eng.hroncok.cz/2020/05/14/ilua-rpm-console
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
So this weeks meeting was full of other things, but we only need one
more +1 on this:
https://pagure.io/packaging-committee/issue/963
...current +1 are:
churchyard
james
limb
decathorpe
...so if you aren't on the above list, please give it a quick look and
help out the mono people.
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:06 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-21/fpc.2020-05-2…
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:06)
* Open Floor (geppetto, 16:08:14)
* #982 Font packaging stopped working in rawhide/F33 (geppetto,
16:16:39)
* ACTION: nim to provide SRPM that worked before and does not work
with new RPM. (geppetto, 16:48:13)
* ACTION: nim to revert usage of %new_package because that is breaking
fonts packages for future patch breakage (geppetto, 16:48:48)
* ACTION: FPC will review provided SRPM and figure out how to proceed
from there, pushing back on rpm maintainers etc. if needed
(geppetto, 16:49:18)
* ACTION: ignatenkobrain to clean up the tickets around this and keep
just one place for discussion (ignatenkobrain, 16:57:47)
Meeting ended at 17:36:08 UTC.
Action Items
------------
* nim to provide SRPM that worked before and does not work with new RPM.
* nim to revert usage of %new_package because that is breaking fonts
packages for future patch breakage
* FPC will review provided SRPM and figure out how to proceed from
there, pushing back on rpm maintainers etc. if needed
* ignatenkobrain to clean up the tickets around this and keep just one
place for discussion
Action Items, by person
-----------------------
* ignatenkobrain
* ignatenkobrain to clean up the tickets around this and keep just one
place for discussion
* nim
* nim to provide SRPM that worked before and does not work with new
RPM.
* nim to revert usage of %new_package because that is breaking fonts
packages for future patch breakage
* **UNASSIGNED**
* FPC will review provided SRPM and figure out how to proceed from
there, pushing back on rpm maintainers etc. if needed
People Present (lines said)
---------------------------
* nim_ (104)
* geppetto (90)
* ignatenkobrain (50)
* mhroncok (42)
* decathorpe (20)
* zodbot (14)
* tibbs (10)
* limburgher (6)
* nim (4)
* petersen (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:18 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-14/fpc.2020-05-1…
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:19)
* Schedule (geppetto, 16:06:07)
* #pr-#954 Prohibit use of `rpm` command from specfile. (geppetto,
16:07:43)
* ACTION: ignatenkobrain to open RFE for mock to populate lua table
with package versions in chroot (ignatenkobrain, 16:16:08)
* LINK:
https://src.fedoraproject.org/rpms/gdb-heap/blob/master/f/gdb-heap.spec#_30
(mhroncok, 16:18:13)
* LINK:
https://src.fedoraproject.org/rpms/perl-Math-Calc-Units/blob/master/f/perl-…
I want a drink (mhroncok, 16:20:34)
* ACTION: Propose a standard alternative and ban querying rpm from
inside .spec (+1:5, 0:0, -1:0) (geppetto, 16:32:55)
* #pr-#942 Recommend storing changelog entries in separate file.
(geppetto, 16:33:19)
* LINK: https://pagure.io/packaging-committee/pull-request/942
(geppetto, 16:33:30)
* #pr-#947 Deprecate Old Style Dependency Generators (geppetto,
16:39:51)
* LINK: https://pagure.io/packaging-committee/pull-request/947
(geppetto, 16:39:55)
* LINK:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
(mhroncok, 16:48:11)
* ACTION: mhroncok to look at how python can get fixed for automatic
lib provides (geppetto, 17:05:46)
* ACTION: decathorpe will help mhroncok (geppetto, 17:07:33)
* ACTION: tibbs agrees to fix everything else :) (geppetto, 17:14:27)
* ACTION: turn the %filter macros to error to avoid silent failures,
we ban them (+1:5, 0:0, -1:0) (geppetto, 17:17:20)
Meeting ended at 17:21:28 UTC.
Action Items
------------
* ignatenkobrain to open RFE for mock to populate lua table with package
versions in chroot
* Propose a standard alternative and ban querying rpm from inside .spec
(+1:5, 0:0, -1:0)
* mhroncok to look at how python can get fixed for automatic lib
provides
* decathorpe will help mhroncok
* tibbs agrees to fix everything else :)
* turn the %filter macros to error to avoid silent failures, we ban them
(+1:5, 0:0, -1:0)
Action Items, by person
-----------------------
* decathorpe
* decathorpe will help mhroncok
* ignatenkobrain
* ignatenkobrain to open RFE for mock to populate lua table with
package versions in chroot
* mhroncok
* mhroncok to look at how python can get fixed for automatic lib
provides
* decathorpe will help mhroncok
* tibbs
* tibbs agrees to fix everything else :)
* **UNASSIGNED**
* Propose a standard alternative and ban querying rpm from inside
.spec (+1:5, 0:0, -1:0)
* turn the %filter macros to error to avoid silent failures, we ban
them (+1:5, 0:0, -1:0)
People Present (lines said)
---------------------------
* mhroncok (55)
* geppetto (52)
* tibbs (41)
* ignatenkobrain (37)
* decathorpe (33)
* zodbot (15)
* Defolos (10)
* nils (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
In this change:
https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
We have advised the following:
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" <paths>
To fix the shebangs.
-p preserves timestamps
-n prevents creating ~backup files
-i specifies the interpreter for the shebang
Now we have new features and we ultimately want this for the best experience:
pathfix.py -pni %{python3} -ka %{py3_shbang_opts_nodash}
-k keeps existing flags
-a adds our flags (if not already there)
%py3_shbang_opts_nodash is derived from %py3_shbang_opts
This is very tedious copypasta.
I propose we macronize this as follows:
We create %py3_shebang_flags. By default, it is the same as %py3_shbang_opts
without dash to avoid confusion, but it can be overridden. Note the proper "e"
in the name.
We create %py3_shebang_fix:
pathfix.py -pni %{__python3} -k%{?py3_shebang_flags:a %py3_shebang_flags}
Usage:
%prep
%autosetup
%py3_shebang_fix .
Or:
%install
...install stuff...
%py3_shebang_fix %{buildroot}%{python3_sitearch} %{buildroot}%{_bindir}/*
As a side not, is it possible to have conditonal expansion not expand on empty
macro?
E.g. this works:
%undefine py3_shebang_flags
%{?py3_shebang_flags:a %py3_shebang_flags} -> nothing
But this does not:
%global py3_shebang_flags %{nil}
%{?py3_shebang_flags:a %py3_shebang_flags} -> a
If not, we'll advise the users to undefine when they want "empty flags".
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok