Re: Please tests your packages in rawhide

Negative. Take a look at the contents of http://koji.rpmfusion.org/koji/taskinfo?taskID=424877  You can see the macros *did* in fact work just fine. The build instead failed because our pod2man macro didn't work out-of-source. This has been fixed and will be part of the next release. Thanks, Andy ------------------------------------------------------------------------ *From:* Leigh Scott <leigh123linux(a)gmail.com&gt; *Sent:* Wednesday, August 5, 2020 7:24 AM *To:* rpmfusion-developers(a)lists.rpmfusion.org <rpmfusion-developers(a)lists.rpmfusion.org&gt; *Subject:* Re: Please tests your packages in rawhide   On 05/08/2020 13:01, Andrew Bauer wrote: > For the zoneminder package, I switched to %cmake3_build and > $cmake3_install. For this case, cmake3 macro is needed, rather than > cmake, to force the use of cmake3 on el7.  > > Despite comments from other sources to the contrary, no further > changes were required. As of yesterday, these macros work on el7, > el8, f32, and f33. It failed on f33 and will be totally broken on f32, f31 and el8 http://koji.rpmfusion.org/koji/taskinfo?taskID=424877 You have to force the new macros for f32 and f31 with %undefine __cmake_in_source_build el8 cmake is too old and only uses the old macros. > > Thanks, > Andy > > > ------------------------------------------------------------------------ > *From:* FeRD <ferdnyc(a)gmail.com&gt; <mailto:ferdnyc@gmail.com> > *Sent:* Wednesday, August 5, 2020 5:47 AM > *To:* RPM Fusion developers discussion list > <rpmfusion-developers(a)lists.rpmfusion.org&gt; > <mailto:rpmfusion-developers@lists.rpmfusion.org> > *Subject:* Re: Please tests your packages in rawhide >   > > On Wed, Aug 5, 2020 at 1:22 AM Gary Buhrmaster > <gary.buhrmaster(a)gmail.com <mailto:gary.buhrmaster@gmail.com>> wrote: > > On Wed, Aug 5, 2020 at 4:20 AM FeRD <ferdnyc(a)gmail.com > <mailto:ferdnyc@gmail.com>> wrote: > > > I haven't merged my changes back beyond master yet, but the > impression I got was, at least once F33 is released, I could. No? > > Your interpretation is the same as mine.   > > > Thanks, Gary, for all of the enlightening details. It all sounds > almost suspiciously reasonable and sensible, so I'll be guardedly > optimistic while I wait for the other shoe to drop. 😉 > > It's vaguely /possible/ there could be an OpenShot release before F33 > makes it out the door, and I'll need to run new builds on F32. At > which point, I'll have to thread all of the expected conditional > logic into the spec files, so that I can merge master backwards to > the current release branches in the absence of that backported New > Design™. > > But that's, like, a soft maybe at BEST. Since I'm not > currently /expecting /to do any new builds for the next couple of > months, I figured I'd hang back until (hopefully) the backports are > ready, at which point I can just merge the new specfile back down the > line. That feels like True Laziness, and I think Larry Wall would > approve. > > But if Leigh or any of the other project organizers prefer to have > the conditionals in there now, "just in case" the updated specs might > be needed to build on older releases, I'm perfectly happy to set > things up that way for however long we're in this limbo period > between the two build setups. Then the legacy commands can be dropped > out again easily enough. > > > _______________________________________________ > rpmfusion-developers mailing list -- rpmfusion-developers(a)lists.rpmfusion.org <mailto:rpmfusion-developers@lists.rpmfusion.org> > To unsubscribe send an email to rpmfusion-developers-leave(a)lists.rpmfusion.org <mailto:rpmfusion-developers-leave@lists.rpmfusion.org> _______________________________________________ rpmfusion-developers mailing list -- rpmfusion-developers(a)lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-leave(a)lists.rpmfusion.org