On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski <orion(a)nwra.com> wrote:
>
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > <code>%cmake</code> macro will be adjusted (<code>-B</code> parameter)
> > to use separate build folder (already standardized
> > <code>%{_vpath_builddir}</code> macro). Additionally,
> > <code>%cmake_build</code>, <code>%cmake_install</code> and
> > <code>%ctest</code> macro will be created (and backported to the older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobrain(a)fedoraproject.org, besser82(a)fedoraproject.org,
> > ngompa13(a)gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From <code>cmake.1</code>:
> >
> > <pre>
> > To maintain a pristine source tree, perform an out-of-source build by
> > using a separate dedicated build tree. An in-source build in which the
> > build tree is placed in the same directory as the source tree is also
> > supported, but discouraged.
> > </pre>
> >
> > The other part of the change is introduction of additional macros is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > ==== <code>%cmake</code> + <code>%(make|ninja)_(build|install)</code> ====
> >
> > There are multiple paths to complete the migration:
> >
> > * Add <code>-C "%{_vpath_builddir}"</code> to the <code>%(make|ninja)_*</code>
> > * Replace <code>%(make|ninja)_build</code> and
> > <code>%(make|ninja)_install</code> with <code>%cmake_build</code> and
> > <code>%cmake_install</code> respectively
> > * Redefine vpath builddir <code>%global _vpath_builddir .</code> to
> > continue performing in-source builds (and optionally converting to the
> > <code>%cmake_*</code>)
> >
> > Depending on the package, one of these options may be used to adapt to
> > this change.
> >
> > ==== <code>%cmake -B builddir</code> +
> > <code>%(make|ninja)_(build|install) -C builddir</code> ====
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build packages
> > that <code>BuildRequires: cmake</code> in a side tag, analyze failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all affected
> > packages, there might be some cases where package is already FTBFS so
> > the fix can't be performed. Other package maintainers will have to fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible. However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the recommendations
> > noted in this Change.
>
> What's the plan for EPEL8/7 compatibility?
>
I need to talk to EPEL folks about how to handle this. I'm not sure
exactly what strategy we should take here. I could override the macros
entirely with epel-rpm-macros, which is probably the easiest way to do
it.
--
真実はいつも一つ!/ Always, there's only one truth!
The following Fedora EPEL 6 Security updates need testing:
Age URL
8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-713ebad0a1 golang-1.13.14-1.el6
8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d1b24a2a25 snmptt-1.4.2-1.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
mozilla-https-everywhere-2020.5.20-1.el6
qpid-proton-0.31.0-3.el6
Details about builds:
================================================================================
mozilla-https-everywhere-2020.5.20-1.el6 (FEDORA-EPEL-2020-1aa81038ca)
HTTPS enforcement extension for Mozilla Firefox
--------------------------------------------------------------------------------
Update Information:
Sorry for the late update everyone. Laptop decided to die for a couple months.
- EASE HTTP Once CSS fix - Allow users to whitelist hosts from the option page -
EASE mode fixes for locale issue - Fetch Test Prep, TLS 1.2 update - Fetch Test
Prep, Updated check rules script - Fix options page appearance on Firefox when
dark mode is on - Dark mode adjustments - Reverting Onboarding page for the time
being - Patch for whitelisting rules and EASE mode issue - Double rule load
patch in update channels - Fix minor JS and UX issues
--------------------------------------------------------------------------------
ChangeLog:
* Fri Jul 31 2020 Russell Golden <niveusluna(a)fedoraproject.org> - 2020.5.20-1
- EASE HTTP Once CSS fix
- Allow users to whitelist hosts from the option page
- EASE mode fixes for locale issue
- Fetch Test Prep, TLS 1.2 update
- Fetch Test Prep, Updated check rules script
- Fix options page appearance on Firefox when dark mode is on
- Dark mode adjustments
- Reverting Onboarding page for the time being
- Patch for whitelisting rules and EASE mode issue
- Double rule load patch in update channels
- Fix minor JS and UX issues
* Tue Jul 28 2020 Fedora Release Engineering <releng(a)fedoraproject.org> - 2019.11.7-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jan 29 2020 Fedora Release Engineering <releng(a)fedoraproject.org> - 2019.11.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1809025 - mozilla-https-everywhere EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1809025
[ 2 ] Bug #1814134 - mozilla-https-everywhere-2020.5.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814134
--------------------------------------------------------------------------------
================================================================================
qpid-proton-0.31.0-3.el6 (FEDORA-EPEL-2020-2fe96ee806)
A high performance, lightweight messaging library
--------------------------------------------------------------------------------
Update Information:
Added rubygem-qpid_proton package.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 29 2020 Irina Boverman <iboverma(a)redhat.com> - 0.31.0-3
- Added rubygem-qpid_proton sub-package
--------------------------------------------------------------------------------