== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
== Owner ==
* Name: [[User:panovotn| Patrik Novotný]]
<!-- Include you email address that you can be reached should people
want to contact you about helping with your change, status is
requested, or technical issues need to be resolved. If the change
proposal is owned by a SIG, please also add a primary contact person.
* Email: panovotn(a)redhat.com
Fedora Program Manager
I've noticed that someone created a flatpak build for one of my packages (feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has 2.7.0. I've been trying to update the flatpak build, but not much luck here. The documentation is pretty verbose, but seems to miss some crucial steps and nothing really works.
I've been following https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/tutorial/
Specifically, I've typed the following commands:
# dnf install flatpak-module-tools fedmod
$ fedpkg clone modules/feedreader
$ cd feedreader
$ fedmod fetch-metadata
Up until here everything seems to check out and download correctly, but then when I do:
$ flatpak-module local-build --install
2019-01-31 17:11:52,388 - MainThread - moksha.hub - WARNING - Cannot find qpid python module. Make sure you have python-qpid installed.
Traceback (most recent call last):
File "/usr/bin/mbs-manager", line 11, in <module>
load_entry_point('module-build-service==2.12.2', 'console_scripts', 'mbs-manager')()
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 189, in manager_wrapper
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417, in run
result = self.handle(argv, argv[1:])
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386, in handle
res = handle(*args, **config)
File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216, in __call__
return self.run(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 154, in build_module_locally
username, handle, str(stream), skiptests, optional_params)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line 386, in submit_module_build_from_yaml
return submit_module_build(username, None, mmd, optional_params)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line 486, in submit_module_build
mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous, default_streams)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", line 345, in generate_expanded_mmds
current_mmd, default_streams, raise_if_stream_ambigous)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", line 276, in get_mmds_required_by_module_recursively
module_build_service.errors.UnprocessableEntity: None of the base module (platform) streams in the buildrequires section could be found
error: mbs-manager build_module_locally failed
error: log: None
From this error message, it's unclear to me what I need to install. feedreader.yaml has:
so I've tried to do 'dnf install flatpak-runtime' but the package doesn't seem to be available.
Next, I thought I'd try building it in koji. Not sure how to do that, the docs are fairly vague, mentioning 'git push origin master' but I don't have anything really to push, the existing git doesn't seem to refer to package versions or anything. I figured that maybe it somehow magically connects it to dist-git rpms/feedreader and gets the sources there so I've tried just 'fedpkg module-build' without pushing anything to modules/flatpak, but that fails again with the familiar missing buildrequires error:
$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
None of the base module (platform or bootstrap) streams in the buildrequires section could be found
Is the flatpak building actually working for anyone? What am I doing wrong? How do I specify what version to actually build?
== Summary ==
Firefox is going to run natively on Gnome Wayland session and won't
use XWayland/X11 Gtk+ backend. This change affects Gnome only and
won't be enabled for other Wayland compositors (KDE Plasma, Sway).
== Owner ==
* Name: [[User:stransky| Martin Stransky]]
* Email: <stransky(a)redhat.com>
* Product: Spins / Workstation
* Responsible WG: Desktop
== Detailed Description ==
Firefox with native Wayland backend has been available for last two
Fedora releases as an optional package. It grown over the time and we
can deploy it now as a default to bring all Wayland benefits to Fedora
== Benefit to Fedora ==
Running Firefox natively on Wayland is generally faster and smoother
on Wayland enabled sessions like Gnome Wayland and better supports
HiDPI displays (respects desktop scale) .
== Scope ==
* Proposal owners: Firefox already uses Wayland as a default backend
on Fedora 30 / Gnoma Wayland session.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
** List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Run Firefox on Gnome Wayland session and check any issues you may see.
== User Experience ==
* Faster Firefox run on Gnome Wayland session
* Smoother font rendering compared to non-Wayland Firefox version
* Honor display scale, better user experience on HiDPI and semi-HiDPI desktops.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Switch back default X11 backend.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? product No
== Documentation ==
* Mozilla Firefox Wayland Bug tracker:
* Mozilla release calendar: https://wiki.mozilla.org/RapidRelease/Calendar
Fedora Program Manager
The Modularity Team has published an updated policy regarding changing
module defaults and submitting Fedora Changes .
instead of: "Packagers must submit a Fedora Change when changing module
it now says: "Packagers should submit a Fedora Change when changing module
defaults based on their best judgement."
That brings it much closer to how we handle major changes in traditional
Will be working on bringing exiv2-0.27.0 to rawhide over the coming days. Includes both abi and minor api changes.
Tracking progress in
in case anyone's aware of incompatibilities, can block that bug. Thanks.
According to repoquery, affected packages include:
$ dnf repoquery --whatrequires 'libexiv2.so.26()(64bit)' --repoid=rawhide
This outage is a replacement of an earlier one in December which had to be
There will be an outage starting at 2019-02-02 13:00 UTC,
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
date -d '2019-02-02 13:00UTC'
Reason for outage:
Various switches at the colocation are needing updates and reboots to get
latest firmware working. While the outage should not take the entire 2
hours, it is being blocked out in case there are problems which are not
realized and need backing out or other changes.
all build services
most web services
copr and all other cloud services.
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
Stephen J Smoogen.
Hi Folks. My name is Samuel and I have been a user of Fedora for about 7 years now. I am a systems engineer co-maintaining my company's patching infrastructure, working closely with carlwgeorge. I use Fedora as my main workstation with special interest in both exotic display and audio configurations. I've had a lot of enjoyment tinkering with Fedora over the past few years using it as my workstation at the office along with the trials that come along with maintaining it as new releases become available. I currently run Fedora 28 on a few devices and plan on upgrading them to 29 over the next few months.
Recently I've been working to get a piece of software known as "fpart" integrated into Fedora and eventually EPEL that I'd be looking to use to solve some automation tasks I deal with on a semi-regular basis. I can pull down the source and build it on my own but I'd prefer to take a cleaner approach of creating proper rpms and go through the process of getting them approved and released within the distribution itself along with maintaining the package as newer releases become available.
At this point I'm looking for sponsorship to move to the next step of getting the package integrated; working with carlwgeorge I was able to clean up the package to approval status in the following bugzilla:
I would be appreciative of any sponsors willing to assist with these endeavors. Thanks.
Hi Fedora devs,
My name is Gergely Gombos. I've been using Fedora for about 1.5 years
and I'm a software developer. I like the FOSS philosophy and using a lot
I'm looking for a sponsor, and my first RPM package is
"pulseaudio-module-bluetooth-aptx" and its dependency "libldac".
The original project <https://github.com/EHfive/pulseaudio-modules-bt> -
yet to be merged into upstream Pulseaudio - provides awesome audio
quality for Bluetooth headsets via aptX, AAC and LDAC codecs. This is
something that is hard to set up even on Windows! And this package works
seamlessly on Linux.
Originally this was in a COPR repo, with >100 downloads, but it got
deleted due to legal reasons (ffmpeg build dependency). So I hope it
will find a new home in RPMFusion since Fedora users are waiting for it.
One of its dependencies is the LDAC library *libldac* which may be
eligible for the Fedora repos. The library has an Apache v2 license but
Sony may have patented the algorithm - it requires licensing for
I've spent quite a lot of time figuring out how RPM packaging works and
get this working and (hopefully) conforming to the guidelines - I
appreciate your review and help.
And of course if this project succeeds, I'm more than happy to take part
in further packaging projects. :)
libldac - #1671064 <https://bugzilla.redhat.com/show_bug.cgi?id=1671064>