Qt 5.14 rawhide
by Damian Ivanov
Qt 5.14 is out since November.
I understand that it may not be suitable for 31 yet (why not? rebuilds?)
but at least should be in rawhide.
It contains a bunch of fixes regarding high dpi and other stuff where custom
patches were carried out by Fedora are fixed now upstream.
Can we have Fedora Rawhide with Qt.5.14 or at least some copr or easy
way to rebuild the Qt rpms as 5.14 using fedpkg or rpmrebuild?
Thanks!
Regards,
Damian
4 years, 3 months
New Package Process
by Steve Dickson
Hello,
I have a new contributor who wants to get
a package into Fedora.
The package is called "Flight Data Recorder"
https://github.com/oracle/fdr
It manages ftraces to record kernel data in way, when
there is a kernel crash, one can go back and "see" what
happen... It sounds very promising.... IMHO.
Now I've done this process a number of times
in the past... but not for a while and there
always seems to be a few new tweaks...
So could point me to the latest doc on
how to get a package in from a existing and
non-existing contributor. I would appreciated it.
tia,
steved.
4 years, 3 months
peek package
by Mattia Verga
The `peek` package has been approved in Fedora repositories [1], but it
doesn't even start without ffmpeg installed [2], which is not
distributed in Fedora repositories (but is available in rpmfusion):
$ peek
Error: Child process exited with code 1
Unable to create default screen recorder.
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather
confusing... I think this package should never have passed the review
process! It should really stay in rpmfusion repository.
Is this something allowed? Should I file a ticket against the package or
against fedora-infra to suggest its retirement?
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1709029
[2] https://github.com/phw/peek/issues/485
4 years, 3 months
Fedora 32 System-Wide Change proposal: Move fonts language Provides
to Langpacks
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
== Summary ==
Move `Provides: font(:lang=...)` from fonts packages into the
`langpacks` package,
giving predictable default fonts for language scripts.
=== Motivation ===
Currently fonts packages has auto-generated `font(:lang=...)`
provides, which can be used as a dependency identifier to satisfy font
coverage required for a certain language requirement. This is used by
GTK application to install missing fonts via PackageKit for example.
However in practice it has not been very useful since usually there
are assorted multiple fonts that provide the language coverage and so
an arbitrary fonts of unknown quality would get selected, so the
mechanism is not unreliable.
This change uses instead the default fonts chosen in `langpacks` for
each language, to give reliable predictable default fonts for each
language and improve the user application experience around fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
* Email: tagoh(a)redhat.com, pnemade(a)redhat.com
== Detailed Description ==
The language based metadata for fonts packages was introduced in
Fedora 11. The idea being to provide a mechanism to find and install
a font for missing glyphs through PackageKit and was useful for
minority languages which might be missing default installed fonts
packages. But the user experience was generally not terribly good.
Users cannot predict which fonts will be installed. This often leads
to poor fonts choices installed, particularly for languages with too
many available fonts such as English, since the first font found
lexically will be arbitrarily chosen with gurantee of quality or
expected style.
This random dependency resolution sometimes introduces highly
unexpected results too - for example a font from an external
repository may get chosen by chance. This would be particularly
problematic when composing ISOs, eg when including EPEL.
So this Changes proposal aims to improve the user experience around
font dependencies by moving the meta-provides the `langpacks` package
instead. Langpacks contains various dependencies to use for certain
languages, including dependencies for default fonts. so it will
resolve the above issues.
Specifically speaking, currently font provides are generated like this:
<pre>
$ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf
font(dejavusans)
font(:lang=aa)
font(:lang=ab)
...
</pre>
and at the build time, it is transformed to:
<pre>
Provides: font(dejavusans)
Provides: font(:lang=aa)
Provides: font(:lang=ab)
...
</pre>
After this proposal, the above result will be:
<pre>
Provides: font(dejavusans)
</pre>
and then add `Provides: font(:lang=...)` line to corresponding
sub-packages langpacks-core-*.
So asking for a font for a certain language through PackageKit will be
achieved by langpacks-core-* instead of a random font package.
== Benefit to Fedora ==
This proposal will provide reliable, predictable, and consistent font
dependencies.
== Scope ==
* Proposal owners:
** Update fontconfig to drop `font(:lang=...)` from the alias of the
formatter for `%{=pkgkit}`
** Add a line of `Provides: font(:lang=...)` to each
`langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
to be added to `langpacks-core-hi`.
* Other developers: Release Engineers needs to rebuild all fonts
packages with the updated fontconfig package.
* Release engineering: [https://pagure.io/releng/issue/9132 #9132]
* Policies and guidelines: None
* Trademark approval: None
== Upgrade/compatibility impact ==
Some packages may be installed after upgrading if corresponding
langpacks-core-* packages isn't yet installed.
== How To Test ==
# Check that langpacks-core-* provide corresponding `font(:lang=...)`
using `rpm -q --provides`.
# Check that fonts packages no longer provide `font(:lang=...)`.
# Check that langpacks-core-* pulls in the default expected font for
the language.
== User Experience ==
Users should see better fonts chosen for languages when they install a
font to cover a certain language script through PackageKit or through
font meta dependencies of other packages.
== Dependencies ==
All fonts packages
== Contingency Plan ==
* Contingency mechanism: proposal owners will revert all the changes
and rebuild all fonts packages to add back the provides.
* Contingency deadline: the beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 4 months
Big change to free maxmind GeoLite2 databases, limiting distribution
by Dave Dykstra
I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages
(e.g. geolite2-city-20191217) each month in order to distribute the free
maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened
down on the license for these data distributions and I think that Fedora
will no longer be able to distribute them. The databases may still be
downloaded for free, and they may be freely redistributed, but anybody
who does so must ensure that everybody that they distribute to updates
their database within 30 days after Maxmind updates them, and destroys
all old copies. Here's the blog entry where they announced the change,
late in December, effective the end of 2019, saying that they had to do
it because of privacy laws:
https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-...
Anybody may sign up for an account and free license key, but they have to
agree to The new End User License Agreement with the new stipulations.
https://www.maxmind.com/en/geolite2/eula
I welcome any suggestions for good alternative sources of geo IP data
that doesn't have these kinds of restrictions and also believes they can
adhere to the privacy laws without requiring a license key.
Dave
4 years, 4 months
[minimization] Feedback Pipeline feedback wanted
by Adam Samalik
The Minimization Objective[1] has been going on for a while. There are two
high-level goals: making things smaller, and keeping things smaller. On the
keeping smaller side, the team prototyped a service called Feedback
Pipeline [2] that monitors use cases for their installation size and
dependencies, including a size history. This will help us see bigger
changes in size for things the community cares about [3].
I already got some feedback from a few individuals I asked while developing
it, but I feel it's in a good enough state for a more broad feedback. So I
have a few questions:
1/ We plan to send weekly size updates to the devel list. Would that be
useful? What should they include?
2/ Regarding the use cases [4], especially the container ones, could people
please review and give feedback to those? Are all the packages there
actually required? I'm specifically looking at the "nss_wrapper" package
that drags in Perl and cmake which makes it huge.
3/ Are there any other use cases we should track? I'm sure there are!
4/ And a more general one: is there something you're working on that's
related Minimization? Please let me know.
Cheers,
Adam
PS: The service is a prototype, so please excuse if there are some rough
edges — like the history graph showing multiple values of the same color.
If you happen to be interested to contribute, I'd be glad to accept issues
(or even PRs!) in the repo [5].
[1] Objective: https://docs.fedoraproject.org/en-US/minimization/
[2] Feedback Pipeline: https://minimization.github.io
<https://minimization.github.io/reports/>\
[3] Things the community cares about: There is an initial list [4] of use
cases defined by the Minimization Team, and we're now looking for feedback
and suggestions for new ones.
[4] Use cases:
https://minimization.github.io/reports/view--use-cases-definitions.html
[5] Feedback Pipeline repo:
https://github.com/minimization/feedback-pipeline/
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
4 years, 4 months