Re: [retitled] Fedora wiki and code tags
by Alessio
On Aug 4, 2020 8:31 AM, "John M. Harris Jr" <johnmh(a)splentity.com> wrote:
>
> That somebody doesn't like something doesn't mean that they don't respect
> those who made it.
Ok. Maybe we are going OT.
But excuse me John: words matter. Saying "it sucks" is not equal to "I don't like it".
A.
3 years, 7 months
Need a package review (aml)
by Bob Hepple
Hi,
The upstream author of wayvnc (a VNC server for Wayland) has split
some code out into a separate tiny package (aml) for which I'm waiting
to get a review request done, since 28th July.
I'm blocked from packaging the new release wayvnc-0.2.0 until that one
is done and I need to get that new version out as it has a fix for the
FTBFS errors on rawhide/f33.
Sorry if this is the wrong place to ask for this - I see people
offering review swaps but I don't think I'm authorised to do reviews.
Anyways, if anyone can do me a review, I'll be ever grateful. It's a
very small, simple package.
The bugzilla is here: https://bugzilla.redhat.com/show_bug.cgi?id=1861216
Thanks
Bob
3 years, 7 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, 7 months
Orphaning fst
by Erich Eickmeyer
Hello all,
fst is a VST bridge for Windows VST plugins for wine only for i686 and
hasn't seen a commit since 2011-01-31[1]. With the F33 mass rebuild, the
day finally has come where fst is FTBFS due to bit rot.
Since there are newer solutions now, such as Carla, that do a good job
of bridging, I don't see any reason for this package to be maintained
anymore. Honestly, it should probably be retired.
[1] https://repo.or.cz/w/fst.git
----
Erich Eickmeyer
Fedora Jam Maintainer
3 years, 7 months
ghc-cryptonite LTO failure on s390x
by Elliott Sales de Andrade
Hi,
The build for ghc-cryptonite failed in the mass rebuild [1] and a
later rebuild by me [2], but only on s390x. The failure appears to be
LTO related. This doesn't appear to affect many other Haskell
packages. (I've found one seemingly-related failure in
ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard
macros that should pass consistent flags, etc., so I'm not sure what
more information I can provide.
What happens is that ld.gold warns about mixed LTO/non-LTO:
[ 1 of 131] Compiling Crypto.Cipher.DES.Primitive (
Crypto/Cipher/DES/Primitive.hs,
dist/build/Crypto/Cipher/DES/Primitive.p_o )
/usr/bin/ld.gold: warning: incremental linking of LTO and non-LTO
objects; using -flinker-output=nolto-rel which will bypass whole
program optimization
and then errors out because of many LTO mismatches like:
/tmp/ghc794663_0/ghc_19.c:11:19: error:
warning: type of
‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
does not match original declaration [-Wlto-type-mismatch]
11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
| ^
|
11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
| ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
note: type ‘StgWord’ should match type ‘struct CostCentre’
44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
| ^
|
44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
| ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
note: ‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
was previously declared here
|
44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
| ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
|
44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
| ^
followed by inlining failures:
/usr/include/bits/string_fortified.h: In function ‘fill_segment’:
/usr/include/bits/string_fortified.h:59:1: error:
error: inlining failed in call to ‘always_inline’ ‘memset’:
function body can be overwritten at link time
59 | __NTH (memset (void *__dest, int __ch, size_t __len))
| ^
|
59 | __NTH (memset (void *__dest, int __ch, size_t __len))
| ^
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=47957210
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=48322376
--
Elliott
3 years, 7 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, 7 months