koji builder status
by Kevin Fenzi
Greetings.
I just thought I would share a short status update on koji builders with
everyone. As many of you know, we like to keep the Fedora koji builders
on the current most recent stable Fedora release. This is to make sure
we have compatible rpm, etc to build rawhide and all our stable updates.
TLDR summary: All Fedora koji builders are now on Fedora 31 and are
using only python3 (the hub is still python2 however).
Due to a bug in the linux kernel on armv7, we never upgraded to Fedora
30 when it was released, so builders stayed on Fedora 29 for the last
cycle. Happily that bug was tracked down and fixed and I have been
moving them to Fedora 31 for the past month or so.
Normally it doesn't take to long to reinstall everything (Thanks
ansible!) but this time it's been a longer road due to: New aarch64
hardware that needed racking/cabling/setup (many thanks to Smooge for
getting this done), firmware updates for most all hardware, RHEL8
reinstalls for virthosts that run buildvm's, and many other items.
We still have pending:
* Some more aarch64 hardware to bring online early in the new year.
* A bug around armv7 buildvm's with more than 24GB memory. While thats
being investigated all the buildvm-armv7 instances have just 24GB
memory.
* A bug around power9 hosts, causing our cloud/container image builds to
fail. This was thought fixed, but doesn't seem to be yet.
* Daily db dumps still cause slowness, likely in the new year we will
schedule an outage and patition the problem tables.
A few stats:
155 total enabled builders
47 x86_64 builders
32 ppc64le builders
32 aarch64 builders
27 armhfp builders
24 s390x builders
Around 10,000 builds a month.
Close to 1.1 million builds since fc6 days
Happy building.
4 years, 4 months
Re: devel Digest, Vol 190, Issue 187
by Jeff Law
On Thu, 2019-12-19 at 22:14 +0000, devel-
request(a)lists.fedoraproject.org wrote:
Igor,
> Send devel mailing list submissions to
>
> It would be very nice to get more specific analysis data. Like running
> some benchmarks of big applications, size comparisons (of binaries and
> libraries) and compile time.
Jan (from SuSE) probably has the best data on this.
http://www.ucw.cz/~hubicka/slides/opensuse2018-e.pdf
https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural...
I don't have his 2019 Cauldron slides which discuss the most recent
improvements. I'll put those links into the change proposal.
>
> > This change also brings us back on-par with SuSE who enabled LTO by
> > default for their free distribution earlier in 2019.
>
> You probably should have said openSUSE rather here.
Yea, openSUSE is more appropriate here. I'll update that.
>
> > == Scope ==
> > * Proposal owners:
> > The primary change is to redhat-rpm-config to add LTO to the default
> > compile/link flags as well as a conditional which allows easy opt-out
> > on a package by package basis. Additionally the post-build scripts
> > need to strip the LTO bytecodes from any installed .o/.a files.
>
> What does that mean? Which post-build scripts are needed and where
> that needs to be done? How does it affect build time?
There's one post-build script which strips the LTO bytecode.
Essentially it's just like stripping debug info or the static symbol
table (like we already do), except we have to apply it to all the .o/.a
files. The openSUSE guys already have these bits, odds are we'll just
copy 'em.
I wouldn't expect the stripping to be noticeable on the build time.
LTO itself will certainly make things slower at build time.
>
> > Additionally, we know there are many packages with configure scripts
> > that are compromised by LTO. I have tweaks to the %configure macro in
> > redhat-rpm-config which fixes the vast majority of these problems with
> > a few simple sed scripts on the generated output. Like the basic
> > support for injecting the LTO flags, this will require coordination
> > with the redhat-rpm-config maintainers. Packages which call configure
> > directly and have compromised tests will need a one line change to
> > their .spec files to fix their configure scripts.
>
> "simple sed scripts" are probably not so simple :)
There's 5 sed scripts I'm using within %configure. Trust me, that's
dramatically easier than trying to fix every package with broken
configure scripts -- particularly when some of those configure files
were built with versions of autoconf that are 12+ years old. Only two
of the 5 sed scripts are, IMHO as a non-sed person, complex. This
avoids the need to fix several hundred packages.
There's certainly some straggler packages that have configure bits that
are unique to those packages rather than shared across many packages.
Those I expect we'll just fix on a per-package basis (it's measured in
a dozen or two in the end I suspect).
I have a tester which allows me to build all the Fedora binary
packages. So I build once with gcc-10+LTO, capture the generated
config.h files, then build again with the standard gcc-9 compiler.
Then the resultant config.h files are compared. If there's any
differences, the build is failed.
>
> > Some packages will need to opt-out of using LTO at this time. The
> > most common case are packages that use symbol versioning or toplevel
> > ASM statements. While there is a new mechanism to make LTO work with
> > symbol versioning, I don't think any packages have been updated to use
> > that mechanism. This will require a one line change to 50-75 packages
> > (my script to find these is still running).
>
> Hmm, I think we have bunch of packages (more than 75 of them) which
> use symbol versioning. Would be useful to give some links in the
> change proposal to "how to update to use that mechanism".
Yup. I've already got a (growing) list of 'em. I've got ~50 on my
list and ~125 failures still to evaluate.
Ideally the opt-out mechanism for a package's .spec file would look
like:
%undefine _lto
Simple enough? :-)
Jeff
4 years, 4 months
Need access to build in copr.fedorainfracloud.org
by Gobinda Das
Hi,
I am Gobinda Das, working at Redhat india as a senior software engineer.
Now I want to take the build responsibility for below projects as (sac)
left redhat who use to take care build.
Projects are: gluster-ansible,gluster-ansible-cluster,
gluster-ansible-features, gluster-ansible-infra,
gluster-ansible-maintenance, gluster-ansible-repositories and gdeploy
I have already created an copr account
username: godas
email: godas(a)redhat.com
Please help me to get CoprDistGit and build access etc.
--
Thanks,
Gobinda
4 years, 4 months
Unannounced soname bump: xen-libs (xen)
by Adam Williamson
It seems a new xen-libs build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1423669
was done by mayoung yesterday. This bumped the sonames of several
libraries, all the ones with the upstream version in their soname
(libxenctrl, libxenfsimage, libxenguest, libxenlight, libxenstat,
libxlutil). This broke qemu's dependencies, which caused the
Workstation live to stop building, which broke the last Rawhide
compose:
https://pagure.io/releng/failed-composes/issue/706
Please remember to announce soname bumps ahead of time so this kind of
problem can be avoided. Thanks.
Mohan is rebuilding qemu at present. I'll do a quick check for
any other dependent packages that need rebuilding.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 4 months
Orphaned python-trimesh
by Miro Hrončok
I've orphaned python-trimesh.
I couldn't keep up with the upstream release cadence and nothing seems to
require it.
Will gladly keep co-maintaining if somebody takes it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 4 months
xournalpp available for testing
by Luya Tshimbalanga
Hello team,
Xournal++, a spiritual successor of xournal (the original author even
recommended it) is now available in the testing repository:
https://bodhi.fedoraproject.org/updates/?packages=xournalpp
Please give karma to quickly make it available on the stable release.
The good part is both xournal and xournalpp can coexist.
Thanks in advance
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
4 years, 4 months
rawhide protobuf update with new soname
by Adrian Reber
I prepared a protobuf upgrade from 3.6 to 3.11 in rawhide. It comes with
a soname update and requires its dependencies to be rebuilt.
I tested it all in copr and most of the packages are rebuilding except
for the following packages:
* dynafed - compile error:
In file included from /builddir/build/BUILD/dynafed-1.5.1/src/UgrMemcached.pb.h:23,
from /builddir/build/BUILD/dynafed-1.5.1/src/LocationInfo.cc:21:
/usr/include/google/protobuf/io/coded_stream.h:842:16: error: macro
"Error" requires 2 arguments, but only 1 given
842 | uint8* Error() {
| ^
* community-mysql:
there is a simple upstream patch to fix the compile error but the test
fails in copr with:
Failed to connect to systemd notification socket named /run/systemd/nspawn/notify. Error: 'Permission denied'
Does not sound like it is related to the protobuf update
* mumble - compile error:
In file included from BanEditor.cpp:36:
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
| ^
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
| ^
Global.h:142:11: error: expected ',' or '...' before '(' token
142 | #define g (*Global::g_global_struct)
|
* paraview - cmake failure:
CMake Error at CommandLineExecutables/CMakeLists.txt:77 (get_property):
get_property could not find TARGET pthread. Perhaps it has not yet been created.
* fts: No matching package to install: 'activemq-cpp-devel'
* kismet: error: Invalid version (double separator '-'): 2019-08-GIT: pkgconfig(kismet) = 2019-08-GIT
Most of the errors do not sound protobuf related.
I want to do the protobuf upgrade in rawhide on Monday, 2019-12-09, just
after the rawhide compose has finished to be able to rebuild all
dependencies before the next compose.
Please let me know if you want to rebuild your package yourself or if
you see other problems with the protobuf upgrade.
Adrian
4 years, 4 months
No pthread on s390x?
by Richard Shaw
This error only happens on s390x...
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:393
(_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindThreads.cmake:220
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
/usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:73 (find_package)
/usr/lib64/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:233
(_qt5_UiTools_process_prl_file)
sources/cmake_helpers/helpers.cmake:21 (find_package)
sources/pyside2/CMakeLists.txt:159 (collect_optional_modules)
-- Configuring incomplete, errors occurred!
https://koji.fedoraproject.org/koji/taskinfo?taskID=39567395
On other platforms the last check succeeds. I've never run into this before.
Ideas?
Thanks,
Richard
4 years, 4 months
