python-mimeparse fails to build in Koji for the epel8-playground target:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43923150
from build.log (as an aside, Koji often prompts to look at root.log even when that's not where the error lies, weird):
error: line 48: Unknown tag: %python_provide: ERROR: python3-mimeparse not recognized.
but builds fine with the same spec for epel8:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1492466
Interestingly, building in mock with the epelplayground-8-x86_64 configuration works!
fedpkg srpm mock -r epelplayground-8-x86_64 ./python-mimeparse-1.6.0-13.el8.src.rpm
In Mock, the macro expansion works fine:
``` <mock-chroot> sh-4.4# rpm -E '%python_provide python3-mimeparse'
<mock-chroot> sh-4.4# rpm -q python-rpm-macros python-rpm-macros-3-37.el8.noarch ```
Is the epel8-playground builder somehow using an different version of python-rpm-macros? Happy to file a bug if I know where this should go.
Thanks,
On 4/29/20 6:58 PM, Michel Alexandre Salim wrote:
<mock-chroot> sh-4.4# rpm -q python-rpm-macros python-rpm-macros-3-37.el8.noarch
Is the epel8-playground builder somehow using an different version of python-rpm-macros? Happy to file a bug if I know where this should go.
root.log says epel8-playground is fetching python-rpm-macros-3-38, while my Mock is using 3-37, but if the CentOS AppStream build is comparable to the RHEL build, the only difference is this:
❯ diff -ru 37 38 diff -ru 37/usr/lib/rpm/macros.d/macros.python 38/usr/lib/rpm/macros.d/macros.python --- 37/usr/lib/rpm/macros.d/macros.python 2020-04-29 19:49:02.558205301 -0700 +++ 38/usr/lib/rpm/macros.d/macros.python 2020-04-29 19:49:13.547141007 -0700 @@ -5,7 +5,7 @@ # the macro %py_build() %{expand:\\ CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\ - %{__python} %{py_setup} %{?py_setup_args} build --executable="%{__python2} %{py_shbang_opts}" %{?*} + %{__python} %{py_setup} %{?py_setup_args} build --executable="%{__python} %{py_shbang_opts}" %{?*} sleep 1 }
Intrigued,
On 30. 04. 20 3:58, Michel Alexandre Salim wrote:
Is the epel8-playground builder somehow using an different version of python-rpm-macros? Happy to file a bug if I know where this should go.
I have an active buildroot override for epel8 epel-rpm-macros:
https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10
There has been no sync to playground since. See https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Might this be relevant? python-rpm-macros come from RHEL, not EPEL, in 8. No idea what's wrong.
On 4/30/20 1:46 AM, Miro Hrončok wrote:
On 30. 04. 20 3:58, Michel Alexandre Salim wrote:
Is the epel8-playground builder somehow using an different version of python-rpm-macros? Happy to file a bug if I know where this should go.
I have an active buildroot override for epel8 epel-rpm-macros:
https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10
There has been no sync to playground since. See https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Might this be relevant? python-rpm-macros come from RHEL, not EPEL, in 8. No idea what's wrong.
I'm not sure, I'll try and compare the two root.log more closely, thanks.
Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch? This whole deep dive started when one of my package didn't build in playground, and tracing its missing dependencies I'm noticing more packages where the epel8 branch is somehow fully synced with master and so never contains package.cfg and never builds for epel8-playground...
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch?
There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground.
The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default.
-- Petr
On 5/1/20 1:10 AM, Petr Pisar wrote:
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch?
There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground.
Right, but if some package repos are missing packages.cfg and the maintainer does not build it separately for epel8-playground, it is a terrible experience for other packages depending on this missing package -- everytime the maintainer submits an epel8 build, the epel8-playground target will report a build failure.
The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default.
That seems to be the case for packages branched normally (fedpkg request-branch). *However* I've seen some packages where the epel8 branch and master branch are identical -- not sure how it happens, maybe the committer has force-push permission? Or is there a way to request that a branch be cloned from another branch instead of created from scratch?
On Fri, May 1, 2020 at 10:49 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On 5/1/20 1:10 AM, Petr Pisar wrote:
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch?
There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground.
Right, but if some package repos are missing packages.cfg and the maintainer does not build it separately for epel8-playground, it is a terrible experience for other packages depending on this missing package -- everytime the maintainer submits an epel8 build, the epel8-playground target will report a build failure.
The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default.
That seems to be the case for packages branched normally (fedpkg request-branch). *However* I've seen some packages where the epel8 branch and master branch are identical -- not sure how it happens, maybe the committer has force-push permission? Or is there a way to request that a branch be cloned from another branch instead of created from scratch?
I prefer my EPEL branches to be this way when possible. And it's simple enough to do
fedpkg clone <package> cd <package> fedpkg switch-branch epel8 git merge master fedpkg push
Nothing fancy about it, as long as you are the maintainer of the epel branch.
Troy
On Fri, May 01, 2020 at 10:48:54AM -0700, Michel Alexandre Salim wrote:
On 5/1/20 1:10 AM, Petr Pisar wrote:
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch?
There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground.
Right, but if some package repos are missing packages.cfg and the maintainer does not build it separately for epel8-playground, it is a terrible experience for other packages depending on this missing package -- everytime the maintainer submits an epel8 build, the epel8-playground target will report a build failure.
There was no 'rule' but the intent was everyone would keep the package.cfg and build for both. If they were not making any playground changes, they didn't need to commit anything, and fedpkg build would just build for both epel8 and epel8-playground.
The problem is that the packages.cfg commit annoys everyone who does a 'merge origin/master' because it's not on the master branch, so they delete it to get their workflow back.
I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8.
Failing that, we could just look at dropping playground if it's not useful for people.
The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default.
That seems to be the case for packages branched normally (fedpkg request-branch). *However* I've seen some packages where the epel8 branch and master branch are identical -- not sure how it happens, maybe the committer has force-push permission? Or is there a way to request that a branch be cloned from another branch instead of created from scratch?
There's no force-push allowed. They likely just deleted it and are merging master over it.
kevin
On 5/1/20 12:39 PM, Kevin Fenzi wrote:
There was no 'rule' but the intent was everyone would keep the package.cfg and build for both. If they were not making any playground changes, they didn't need to commit anything, and fedpkg build would just build for both epel8 and epel8-playground.
The problem is that the packages.cfg commit annoys everyone who does a 'merge origin/master' because it's not on the master branch, so they delete it to get their workflow back.
I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8.
Failing that, we could just look at dropping playground if it's not useful for people.
Yeah, having epel8-playground automatically inherit from epel8 would solve a lot of issues, it seems. I personally don't mind merging from master -- I don't want to build every Fedora revision for EPEL -- but I can understand how some maintainers might prefer otherwise.
The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default.
That seems to be the case for packages branched normally (fedpkg request-branch). *However* I've seen some packages where the epel8 branch and master branch are identical -- not sure how it happens, maybe the committer has force-push permission? Or is there a way to request that a branch be cloned from another branch instead of created from scratch?
There's no force-push allowed. They likely just deleted it and are merging master over it.
Interesting. Could you help take a look at - python-mimeparse - python-testscenarios
and help figure out how epel8 and master end up sharing a history?
Thanks,
On 01. 05. 20 21:39, Kevin Fenzi wrote:
I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8.
As a drive-by epel contributor, this would work so much better for me.
epel-devel@lists.fedoraproject.org