It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...
These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.
I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.
I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"
a new version rpkg-1.58 and fedpkg-1.37 is released.
Currently, Fedora 30 packages are in the stable repository, feel free to
try other waiting distributions in Bodhi.
Numerous features and improvements (as well as bugfixes) includes:
- Improvements for scratch module builds
- Allow passing arguments to “mbs-manager build_module_locally”
- Remove the ability to parse a module’s branch
- Permit setting arbitrary rpm macros during build
- Ignore specific files in a cloned repository
- Pass specific arguments to “mock”
- Added “depth” argument to "git clone"
- Watch multiple module builds
- Show module build links in output from command module-build
- Add the ability to configure multiple regex expressions
- Add “retire” command supporting both packages and modules
- Import srpm without uploading sources
- Ignore any specified profile when finding the Flatpak build target
- Added update-docs script
- And other fixes and small improvements
- Ignore files in a cloned repository
- Enable shell completion for module scratch builds
- Show hint when Pagure token expires
- Include possible distprefix in “–define dist” for Forge-based packages
- Other small fixes
More specific changelog (web documentation):
rpkg is available from PyPI.
Thanks to all contributors.
A fonts packaging policy rewrite proposal has been pushed to FPC today:
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
there is still no F30 package with the right keys.
Can we *please* send out the FN+1 and FN+2 keys a month before branching,
to *all* releases of Fedora, so we can avoid this pointless scramble?
Too many people (like also me) try to use samba-dc on fedora for deploy
a production AD DC controller, without know that MIT kerberos is
experimental and some useful things cannot work (es. win to win
An recent last example:
> On 01/11/2019 22:23, Vex Mage wrote:
> > The script is expecting dpkg however this is a Red Hat
> > derived distro (Fedora Server.)
> Where did you get the Samba packages from ?
> If they are the default OS packages, then you should stop using
> them, they use MIT kerberos and are experimental.
There is many approach for resolve this issue:
a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos.
b) Produce a samba alternative package version (like, for example,
firefox-x11) build it with Heimdal Kerberos (es samba-hk-*)
c) Stop enable DC on Fedora, like RH/Centos do.
d) Notify users at the end of the installation that Fedora Samba DC is
e) Solve the problems that make MIT kerberos experimental and put us in
a position to ask for help on the samba team.
f) ... some other proposal ?
What is the best approach chosen by Fedora ?
(inviato dal mio Linux Fedora 31 Workstation)
Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha
> Hi Sandro,All,
> Can I upgrade the tools on existing VM , or it requires a fresh one? Best
If you have oVirt windows guest tools already installed suggestion is to
uninstall it before installing this new installer.
> Best Regards,
> Strahil Nikolov
> On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
> as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
> Drivers installer using the open source framework WiX.
> Thanks to the virtio-win maintainer, the new installer is not shipped
> anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
> Windows ISO
> Please give it a run on your testing environment / testing VMs and let us
> know about your experience at devel(a)ovirt.org.
> Sandro Bonazzola
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
> Red Hat EMEA <https://www.redhat.com/>
> <https://www.redhat.com/>*Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.*
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
<https://www.redhat.com/>*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
I got nerdslipped and I ahve created some HTML only mockup of a thing that I
find very useful. A Fedora Packager Dashboard.
You can find the early mockup at:
The idea is to collect some data about your packages and present them in some
nice form. Such data would be gathered by plugins. Examples on the mockup:
- active updates
- active buildroot overrides
- open PRs
- orphaned or broken depnddencies
- FTBFS (from koschei)
Ideas not included in the mockup:
- running Koji builds
Let me know what you think. I can work on this on the backend level (plugin
architecture design, gathering data, cache...) but even copy pasting HTML from
Bodhi to present the mockup was very painful for me, so if we want this,
somebody with more fronted experience would need to help.
== Summary ==
Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
symlinks are managed by update-alternatives.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The gcc package currently installs symlinks to /usr/bin/cc and
/usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
respectively. For this change, the gcc package will be modified so
that update-alternatives creates and manages these symlinks.
In addition to modifying the gcc package, the clang package will be
modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
will have a lower priority than the gcc alternatives, so that by
default, gcc will provide the /usr/bin/cc and /usr/bin/c++
The clang package currently has a run-time dependency on gcc, so this
ensures that gcc will always provide the default implementation,
because it's impossible to install clang without gcc.
The only way users will be able to change the /usr/bin/cc or
/usr/bin/c++ implementations will be by explicitly using the
== Benefit to Fedora ==
Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
the default C/C++ compilers. Being able to easily swap out these
implementation will provide a lot of flexibility within Fedora for
doing things like:
* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate
packages to new compiler flags or to capture statistics about compiler
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.
== Scope ==
* Proposal owners: The proposal owner will implement the necessary
changes in the gcc and clang packages.
* Other developers: The gcc maintainers will be responsible for
reviewing and approving changes to the gcc package.
* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
CI tests will be added to the gcc package to ensure that /usr/bin/cc
and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
installed. There will also be a CI test added to the clang package to
ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
clang is installed.
== User Experience ==
This change will give users a much better way to experiment using
other compilers for their own development. They will be able to
easily switch between different compilers without having to modify
their projects build system or make non-standard changes to their
== Dependencies ==
This change has no other dependencies besides the changes to the gcc
and clang packages.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal Owner
will revert changes made to gcc and clang packages and rebuild.
* Contingency deadline: If the changes are not complete by 2 weeks
before the mass rebuild, then we will consider postponing to the next
Fedora release and back out any changes that were made.
* Blocks release? No
* Blocks product? None
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
update-alternatives. If you would like to change these symlinks to
point to another compiler, like clang, for example, you can use these
`update-alternatives --set cc /usr/bin/clang`
`update-alternatives --set c++ /usr/bin/clang++`
He / Him / His
Fedora Program Manager