Orphaning a bunch of my packages (part 2 of X)
by Raphael Groner
Hi,
unfortunately I have to orphan my packages psi+ (incl. psi as a base where co-maintainer) and trojita as well.
psi+ - XMPP client
trojita - e-mail client for IMAP
Please feel free to pick them if you still think there's any usefulness in Fedora. Both packages didn't get updates since ages because upstream uses strange development models, there are also some open bugs for both packages.
Regards
Raphael
3 years, 8 months
Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
by Ben Cotton
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.
== How To Test ==
# Grab the new cmake RPM from the Koji sidetag (TBC)
# Try to build package that uses <code>%cmake</code>,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro
== User Experience ==
The end-users (non-packagers) will not notice any changes.
== Dependencies ==
There are around 1100 RPMs in Fedora that depend on CMake at
build-time. All proposal owners are provenpackagers so they are able
to commit necessary fixes. No external dependencies.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will adjust macros to not do
out-of-source builds by default, but will preserve newly created macro
(essentially to bring them to the targeted state of older supported
Fedora releases).
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
The only place that needs to be adjusted is packaging guidelines.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Non responsive packager: rfairley
by Pierre-Yves Chibon
Good Morning Everyone,
I have been trying to contact packagers without a proper bugzilla account
associated with their FAS email for a while now. The first email to devel-announce
is from June 13th [1].
This is a requirement for packagers which is mentioned at:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Cr...
Since then a number of packagers have fixed their situation but that user did not.
Currently I see:
rfairley is maintaining modules/afterburn
rfairley is maintaining modules/fedora-coreos-pinger
rfairley is maintaining modules/zincati
rfairley is maintaining rpms/console-login-helper-messages
rfairley is watching rpms/ostree
rfairley is watching rpms/rpm-ostree
rfairley is maintaining rpms/rust-afterburn
rfairley is maintaining rpms/rust-assert-json-diff
rfairley is maintaining rpms/rust-coreos-installer
rfairley is maintaining rpms/rust-cpio
rfairley is maintaining rpms/rust-envsubst
rfairley is maintaining rpms/rust-fail
rfairley is maintaining rpms/rust-fedora-coreos-pinger
rfairley is maintaining rpms/rust-liboverdrop
rfairley is maintaining rpms/rust-libsystemd
rfairley is maintaining rpms/rust-pipe
rfairley is maintaining rpms/rust-progress-streams
rfairley is maintaining rpms/rust-prometheus
rfairley is maintaining rpms/rust-readwrite
rfairley is maintaining rpms/rust-try_or
rfairley is maintaining rpms/rust-vmw_backdoor
rfairley is maintaining rpms/rust-zincati
I am hereby starting the non-responsive procedure for that user.
Does someone know how to contact them?
Failing to contact them, I will be asking FESCo to orphan the packages.
Thanks in advance for your help,
Pierre
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
3 years, 8 months
Fedora flatpaks on non-x86 architectures
by John Doe
Hello!
I am looking for the place where Fedora flatpaks are built, as explained here: https://docs.fedoraproject.org/en-US/flatpak/concepts/#_oci_images
I could find a koji task that builds one: https://koji.fedoraproject.org/koji/buildinfo?buildID=1520683 - and there we can observe in orchestrator.log:
2020-06-04 10:16:48,929 platform:- - atomic_reactor.plugins.check_and_set_platforms - INFO - Checking koji target for platforms
2020-06-04 10:16:48,991 platform:- - atomic_reactor.plugins.check_and_set_platforms - INFO - Koji platforms are ['aarch64', 'armv7hl', 'i686', 'ppc64le', 's390x', 'x86_64']
2020-06-04 10:16:48,992 platform:- - atomic_reactor.plugins.check_and_set_platforms - WARNING - No cluster found for platform 'armv7hl' in reactor config map, skipping
2020-06-04 10:16:48,992 platform:- - atomic_reactor.plugins.check_and_set_platforms - WARNING - No cluster found for platform 'i686' in reactor config map, skipping
2020-06-04 10:16:48,992 platform:- - atomic_reactor.plugins.check_and_set_platforms - WARNING - No cluster found for platform 'aarch64' in reactor config map, skipping
2020-06-04 10:16:48,992 platform:- - atomic_reactor.plugins.check_and_set_platforms - WARNING - No cluster found for platform 'ppc64le' in reactor config map, skipping
2020-06-04 10:16:48,992 platform:- - atomic_reactor.plugins.check_and_set_platforms - WARNING - No cluster found for platform 's390x' in reactor config map, skipping
And I would want to add a "cluster", for ppc64le in particular, but aarch64 would be good too. This is for Fedora Silverblue specially.
Any help is welcome!
Thank you!
3 years, 8 months
use of 'date' in rpm .spec %define concats add'l str chars?
by PGNet Dev
on F32,
date +FORMAT,
date +%Y%m%d_%H%M%S
returns
20200703_105351
as expected.
in an rpm .spec, if I define
%define _build_timestamp %( date +%Y%m%d_%H%M%S )
and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of any of rpmbuild/mock build/@COPR etc, it appears as
'20200703_105351OURCE'
?????
Simply changing the define to
%define _build_timestamp %( date +%Y%m%d_%H%M%S | head -c 15 )
'fixes' the problem, and use of %{_build_timestamp) correctly returns
'20200703_105351'
Is this a bug in rpmbuild or date? Or a problem in my usage?
3 years, 8 months
Non responsive packager: usercont
by Pierre-Yves Chibon
Good Morning Everyone,
I have been trying to contact packagers without a proper bugzilla account
associated with their FAS email for a while now. The first email to devel-announce
is from June 13th [1].
This is a requirement for packagers which is mentioned at:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Cr...
Since then a number of packagers have fixed their situation but that user did not.
Currently I see:
usercont is maintaining rpms/colin
usercont is maintaining rpms/conu
usercont is maintaining rpms/packit
usercont is maintaining rpms/python-docker
usercont is maintaining rpms/python-ogr
usercont is maintaining rpms/rudesocket
I am hereby starting the non-responsive procedure for that user.
Does someone know how to contact them?
Failing to contact them, I will be asking FESCo to orphan the packages.
Thanks in advance for your help,
Pierre
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
3 years, 8 months