There will be an outage starting at 2018-07-02 21:00UTC, which will
last approximately 4 hours.
To convert UTC to your local time, take a look at
date -d '2018-07-02 21:00UTC'
Reason for outage:
There have been a set up of updates for EL7 and Fedora requiring
reboots of infrastructure. We will be rebooting the Build and remote
systems outside of PHX2 on this day.
All build and cloud services may be up or down during the outage
window. Various proxies will not be available and fedorapeople will be
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
Stephen J Smoogen.
Hello, I am the maintainer of nextcloud-client.
I am writing to ask for help in maintaining nextcloud-client.
Actually nextcloud-client is just a nextcloud themed version of
The new nextcloud-client instead is still at a very alpha state.
We used to be 5 maintainers, but after months of co-maintainers being
unresponsive, I removed them, otherwise people could think that there
are plenty of people working on the package.
The package needs to be updated to lastest owncloud-client version and
there is also the need for starting working on a new spec file for the
next generation nextcloud client .
What has changed in the last month to affect building shared libraries
I tried to rebuild libxsmm in rawhide, after changing the spec to use
python2 explicitly, and it failed with
/usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 against symbol `libxsmm_crc32_u64' can not be used when making a shared object; recompile with -fPIC
The sources are compiled with -fpic and it's x86_64 only, so -fPIC
v. -fpic shouldn't matter as I understand it.
I went back and tried to rebuild the version which built last month
(https://koji.fedoraproject.org/koji/buildinfo?buildID=1061191) and it
now fails as above. See
I'd be grateful for hints.
I somehow wound up owning python-sphinx_rtd_theme, I think probably because
I was the first person to attempt to do a build that needed it. :-)
Anyhow, I am not at all sure that I am competent to be the maintainer. I
need some advice. There is a new upstream version available, 0.4.0. I am
looking at it right now, and my attempts at unbundling fonts from this
package seem to be unraveling.
Three font families are bundled: fontawesome, Roboto Slab, and Lato. We
have all 3 of these in Fedora, but the problem is that this package wants
the web versions of these fonts, too. We have fontawesome-fonts-web, but
we do not have .eot, .woff, or .woff2 files available for the other 2
fonts, so far as I am able to determine. Since the .ttf files of those
fonts are not byte-equivalent to the ones we ship ... I'm not sure what is
safe to do here. I am not any kind of font expert.
The upstream tarball is here:
Any advice on how to deal with those fonts is most welcome. Any offers
from someone more competent than me to maintain this package would be
I have just gotten the python-pyopengl package to a state where it
builds in the f29-python side tag, but will have to orphan the package
from this point on, as I just don't have the spare cycles to work on
it moving forward.
The package is pretty dead upstream, with the last proper release
being 2014. The package was largely inactive since, apart a brief
flurry of activity on github in February of this year.
At this point, folks should consider migrating to using the
ModernGL bindings instead, as these are much easier to use, and
upstream is very active, and support for later OpenGL versions is
In order to get the package to build for Python 3.7 I had to:
1. Rebuild all Cython generated .c files
2. (1) above required adding some .pxd files missing from the tarball release
3. Rename two modules that were called "async.py" to "async_.py" since
async became a keyword in Python 3.7.
So, at this point the Fedora package has even had to diverge from the
(dormant) upstream API. In addition, the scripts used to generate the
python bindings have bit rotted over the years and will only run with
So, if you're interested in maintaining this package, please do grab it.
I'm forwarding this request for help here since it seems there is no
one available on Fedora games.
The strange thing about this issue is that on F27 everything is fine (the
spec file is the same).
Thanks in advance,
---------- Forwarded message ----------
From: Andrea Musuruane <musuruan(a)gmail.com>
Date: Sat, Jun 23, 2018 at 9:27 PM
Subject: gcompris-qt: help needed
To: Fedora Games <games(a)lists.fedoraproject.org>
I'm gcompris-qt maintainer.
gcompris-qt was fine until I upgraded to F28.
After that, it seems the program is no longer able to shows some graphics.
Even a fresh install on a VM shows the same behaviour.
Activity menu icons are not shown even though you can select a group
blindly clicking on an empty box in upper part of the screen. Then related
activities are shown but again without icons and with an textual
description. Even inside an activity some graphics are not shown.
The program shows no error and it seems it does not complain about anything
Any help is really appreciated.
= Proposed System Wide Change: Make BootLoaderSpec the default =
* Javier Martinez Canillas <javierm at redhat dot com>
* Peter Jones <pjones at redhat dot com>
Use BootLoaderSpec fragment files by default to populate the
bootloaders boot menu entries.
== Detailed description ==
Boot Loader Specification (BLS)] defines a scheme and file format to
manage boot loader configuration for each boot option in a drop-in
directory, without the need to manipulate bootloader configuration
files. These drop-in directories are the standard on Linux nowadays,
so the goal is to also extend this concept for boot menu entries.
This is especially important in Fedora because the same bootloader is
not used in all architectures. GRUB 2 is used in most of them, but
there are others such as zipl for s390x and Petitboot for ppc64le. Not
all bootloaders have the same configuration file format, so there is a
need for an indirection level and per bootloader specific logic to
edit these configuration files, when adding or removing a boot entry.
The current component that does this work is grubby, that has support
for all the different bootloader configuration file formats and
manipulates them on kernel installation or uninstallation. Besides
manipulating the bootloader configuration files, grubby also does
other things like running dracut to create an initial ramdisk image.
Fedora already has a lot of infrastructure in place to not require
modifying bootloader configuration files for boot menu entries. The
BootLoaderSpec and drop-in BLS fragments can be used instead, and the
kernel-install script can do any additional task that is currently
done by grubby. The kernel-install script has a pluggable design that
uses a drop-in directory for scripts to extend its functionality. So
if needed, any bootloader specific logic can be implemented as
With this setup the bootloader configuration could be static and not
modified after installation.
The missing piece was the lack of BLS support on all the supported
bootloaders, but all of them have support to parse BLS fragments now.
So we can default to install BLS files on kernel installation and drop
== Scope ==
* Proposal owners:
** Generate BLS snippets at kernel build time and ship in the kernel packages.
** Make kernel-install scripts to copy the BLS, kernel and initramfs
images and do any architecture specific task.
** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
menu entries from the information in BLS files.
** Have a grubby wrapper for backward compatbility that manipulates BLS files.
** Modify packages that use grubby to instead install BLS fragments
** Make sure this is all properly documented in release-notes, etc.
* Other developers:
** The anaconda developers will need to review and merge the patches
to change the default to BLS.
** Test and watch for regressions.
* Release engineering:
RelEng review ticket: https://pagure.io/releng/issue/7572
** List of deliverables:
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
No changes needed.
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
lots of times, I see name "copr", "Copr", or "COPR" used somewhere but it's
almost never used correctly for the given context. So I would like to make
it clear, what's the correct way to write it down to get the meaning right.
"Copr" or "COPR" = service providing space for community projects
"copr" or "Copr project" = a single community project
So there are two variants how to refer to service ("Copr" and "COPR").
And there are two variants how to refer to a singular project ("copr" and
----- (minor additional notes to be ignored) -----
When referring to a singular project, just saying "copr" is enough. "co"
stands for "community", "pr" stands for "project".
When you write down "Copr project", it literally means "Community projects
project" so it's a bit redundant to write it down that way.
If you liked to refer to the Fedora instance of Copr service, you would
write "Fedora Copr".
If you liked to ignore the previous rule or made it nice for typography,
you would write "fedora copr" like our logo does. This is also good for IRC.
I don't really mind how people write it down but I think it's good to
provide at least some guide in case somebody needs to think about this :).