Fedora 33 Self-Contained Change proposal: Default animated background
for Fedora Workstation
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
== Summary ==
Fedora Workstation 33 uses animate background as default.
== Owner ==
* Name: [[User:luya| Luya Tshimbalanga]]
* Email: luyaATfedoraproject.org
* Product: Workstation
== Detailed Description ==
Starting from Release 33, Fedora Workstation uses default animated
background as a visual showcase. Spins and lab maintainers running on
desktop environment unable to support animated wallpaper will be able
to select a different frame from the default (and variant) background.
== Benefit to Fedora ==
Fedora Workstation will showcase its animated background seamlessly as default.
Does this improve specific Spins or Editions?
Design Suite Labs, which is based from Workstation, and
Fedora Silverblue will take advantage of its change. Other Spins and
Labs will remains unaffected unless their respective maintainers wish
to use the default animated background.
== Scope ==
* Proposal owners:
Fedora Workstation may need a slight increase of its ISO file size in
order to implement the animated backgrounds which are in PNG format.
Each frame from animation will be selectable from the Background
Settings.
* Other developers: N/A (not a System Wide Change)
* Release engineering: Possibly a slight increase of ISO file.
* 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 ==
N/A (not a System Wide Change)
== User Experience ==
Users will notice an animation of the default background related to
the time of the day.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert to the default static background
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 12 months
libgps soname bump (gpsd-3.20)
by Miroslav Lichvar
A new version of gpsd is ready to be build in rawhide. This is a
second attempt. It now bumps the libgps soname. Per repoquery the
following packages have a dependency on libgps and will need a
rebuild:
collectd
direwolf
foxtrotgps
marble
plasma-workspace
qlandkartegt
vfrnav
viking
Some packages already carry a patch for the new libgps API. Some will
need to be fixed. I've uploaded the patches here:
https://mlichvar.fedorapeople.org/tmp/gpsd
vfrnav doesn't build for me due to a C++ issue, so I'm not sure if the
gps fix is complete.
If a proven packager could add/merge the patches and rebuild all
the packages, please me know. Otherwise, I'll rebuild gpsd sometimes
next week and let the maintainers fix their packages.
Thanks,
--
Miroslav Lichvar
3 years, 12 months
Highlights from the latest Copr release 2020-06-10
by Pavel Raiskup
Hello!
On Jun 10, 2020, a new Copr release landed production. Related client tooling
updates are here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-390cce74d6
https://bodhi.fedoraproject.org/updates/FEDORA-2020-f90873700f
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3b8c2778f1
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-feca133c66
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8449e5d605
Here is the list of visible changes, and new features:
- Increased build task throughput. The VM spawner is more flexible now.
First, we don't allocate that many workers if they are not actually
needed, but more importantly the upper limit for concurrently running
workers has risen to 140 (including all architectures), previously we
had ~70. We'll see how things go from the backend perspective, but it is
expected that we'll go even higher (waiting for a new HW in the new
Fedora lab, cheaper VM instances in the future, etc.). So the numbers will
likely change; this is to make clear the current state of things.
- Copr project "runtime" dependencies were implemented. Newly you can
specify set of repositories your project depends on. Such repositories
will be installed together with the copr project repo file (e.g., by
'dnf copr enable YOU/YOUR_PROEJCT'). Those repositories can be other
project in Copr or some 3rd party repository. This is very similar to
build-time dependencies implemented long time ago. Take a look at
blog post:
https://fedora-copr.github.io/posts/runtime-dependencies
- There's now more fair build scheduler. Previously, no matter whether the
"background" attribute was set or not for the build - once builder was
allocated for a concrete copr user - copr never terminated the builder
as long as the user kept filling the build queue with new tasks (and it
blocked the quota for others). Newly, there's a limit of at most
eight consecutive builds or 30 minutes for one user (sandbox) on one
builder and the builder is immediately terminated - which gives a chance
to assign new builders to others' tasks (which have a higher priority at
that point).
- Copr-cli supports batch build delete feature:
$ copr-cli delete build_id [build_id ...]
Please use this instead of requesting removal of each build_id
separately - it will be much faster because you will save the copr
backend useless createrepo_c runs after each request.
- We also implemented a priority queue algorithm for Action tasks
(non-build tasks, e.g., forking, build/project deleting, etc.). This
should solve several issues when the action queue gets temporarily too
large to process immediately; namely the delayed "initial createrepo"
action problem that previously caused an ugly build failures in freshly
created copr projects.
- Cancel build feature was fixed, and the "cancel" request should reliably
release all occupied builder machines (allowing them to be re-used, or
terminated).
- Users are not allowed to disable chroot in a project that has some
running builds against the disabled chroot. The running builds need to
be canceled first. This change as done to avoid inconsistencies between
frontend/backend, and wasted builder quota on useless tasks.
- More space for /var/cache/mock directory, so repeated builds on the same
machine won't face the ENOSPC error on mock caches. Considering that
each builder can only do at most eight builds (then terminated), this
problem should be finally fixed.
Happy building!
Pavel
3 years, 12 months
Fedora 33 System-Wide Change proposal: LLVM 11
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LLVM-11
== Summary ==
Update all llvm sub-projects in Fedora to version 11.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 11, and there
will be a soname version change for the llvm libraries. Compatibility
packages clang10 and llvm10 will be added to ensure that packages that
currently depend on clang and llvm version 10 libraries will continue to
work.
Also, changing in this update is the compatibility package naming. The .0
will be dropped from the package name, so the compatibility packages will
be called llvm10 and clang10 instead of llvm10.0 and clang10.0.
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan any
packages that are no longer used.
** Request a f33-llvm side-tag from Release Engineering.
** Build llvm10 and clang10 into the side-tag.
** When the upstream LLVM project releases version 11.0.0-rc1 (2020-7-15),
package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f33 branch date.
** Continue packaging newer release candidates into rawhide and f33 until
the final release is complete (~2020-8-26)
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will need
to update their spec files to depend on the clang10 and llvm10
compatibility packages if they want to rebuild their package and it does
not work with LLVM 11 yet. The key point here is that spec file changes
are only needed if a package is going to be rebuilt after LLVM 11 is added
to Fedora. The compatibility packages will ensure that already built
packages continue to work.
* Release engineering: [https://pagure.io/releng/issues/9535]
* 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 ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM 11.
== User Experience ==
Users will benefit from new features and bug-fixes in the latest version of
LLVM.
== Dependencies ==
This change can be made without updating any other packages. However, as
mention before, packages that need to use LLVM 10 will need to update their
spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) If there are major
problems with LLVM 11, the compatibility package provide a way for other
packages to continue using LLVM 10. In the worst case, we could always
revert LLVM back to LLVM 10, but this would only happen if their were an
unprecedented amount of problems.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 11:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 12 months
Fedora 33 System-Wide Change proposal: Zanata Removal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Zanata_removal
== Summary ==
While most Fedora project migrated to Weblate, the old translation platform
still exists and needs to be removed (the community shouldn't have to go to
multiple place to contribute, and nobody assume Zanata maintenance).
== Owner ==
* Owner: the [[L10N]] group ({{fpchat|#fedora-i18n}})
* Primary contact: [[User:jibecfed|Jean-Baptiste Holcroft]]
* Email: [
https://lists.fedoraproject.org/archives/list/trans@lists.fedoraproject.org/
localization mailing list]
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences suffices to
explain the goal, but the more details you can provide the better. -->
We created a migration page to follow projects migration from Zanata to
Weblate: [[L10N Move to Weblate]].
Remaining projects should either: migrate to Weblate or move to another
translation platform.
== Feedback ==
Weblate configuration: unless your team knows Weblate, Jibecfed will do
first configuration and make you admin of your project so you can add more
components.
Pull request support for Pagure: it is unlikely this features lands in
Weblate before Zanata removal. Suggestion is to allow
https://pagure.io/user/weblatebot for commits.
Some project requiring Sign-off:
https://docs.weblate.org/en/latest/admin/licensing.html#signed-off-by
Reducing translation impact in your repository:
* you can configure weblate's components to save po files without any line
number, saving many useless commits if you do frequent pot updates
* you can configure weblate's components to squash commits per author to
limit the number of commits
== Benefit to Fedora ==
This makes the distribution more efficient:
* translators have one single place for translating, and get many
interesting features (alerts, comments, etc.)
* newcomers can directly translate without approval
* maintainer have less automation to do (po updates, etc.)
* reduce complexity (all in one place) & infrastructure costs
== Scope ==
* Proposal owners: continue to answer questions from upstream projects and
translators
* Other developers:
** if we created a ticket for you, answer it. It may require you to change
your l10n/i18n automation (likely) and git repositories (unlikely).
** if not, open a ticket to l10n team: https://pagure.io/fedora-l10n/tickets
* Release engineering: [https://pagure.io/releng/issue/9537 #9537]
* Policies and guidelines: No
* Trademark approval: No
== Upgrade/compatibility impact ==
This impact upstream projects, not the delivered operating system.
Worse case scenario: less translations reach upstream.
== How To Test ==
Project is in readonly in https://fedora.zanata.org
Project exists in Fedora Weblate: https://translate.fedoraproject.org
Modification done in Fedora Weblate can be seen in upstream repository.
== User Experience ==
This improve the experience of users that don't speak English correctly
(90% of the world, source CLDR + Wikipedia) or not at all (80% of the
world, source CLDR + Wikipedia)
== Dependencies ==
None (this doesn't impact packaging)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) No contingency,
Zanata won't be kept any longer, we already gave 6 more month to let
project migrate at their own pace to the new system
* Contingency deadline: none
* Blocks release? No
== Documentation ==
* [[L10N/Translate_on_Weblate|How to translate on Weblate?]]
* List of Weblate file formats support:
https://docs.weblate.org/en/latest/formats.html
* Weblate's FAQ: https://docs.weblate.org/en/latest/faq.html
* Weblate evolves fast, reading changes is interesting:
https://docs.weblate.org/en/latest/changes.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 12 months
Wondering what to do with fritzing versioning
by Artur Iwicki
A few days ago I adopted fritzing and fritzing-parts, which were orphaned by their original maintainer.
I looked at the package and at the upstream project and noticed a few things:
- Looking at the releases page for the app [1], upstream stopped doing releases manually and relies on a
Continuous Delivery service. This is fine by itself, but at the same time, upstream switched to
using the Continuous Delivery build ID as the main unique identifier for releases - and now there are
two releases [2], [3] with the same semver. I suppose this may happen again in the future, so my thought was to
use a combination of semver and the CD-build-ID as the Version: of the Fedora package, something like `0.9.4.CD498`.
- Looking at the releases page for the parts repository [4], upstream stopped bothering with git tags
quite some time ago. The "build & release" script [5] that upstream uses just pulls the latest commit
from the fritzing-parts repository when doing a build.
So now I'm just wondering:
1) Does the versioning scheme for the main package make sense?
2) For the fritzing-parts package, should I package the commit matching the official release
(e.g. version CD-498 was released on 2019-12-01, so pick the 2019-11-24 commit from fritzing-parts,
since that was "latest" at time of build), or don't care for synchronizing these and just go with the latest commit?
The latter approach is easier, but I worry about potential backwards-incompatible changes.
3) For the fritzing-parts package, should I keep the semver and go with `semver-release.DATEgitCOMMIT`,
or switch to `DATE-release.gitCOMMIT`? The latter option makes sense, but I'm not too keen
about changing the versioning scheme.
If someone's willing to share their thoughts and advice, I'll be grateful.
A.I.
[1] https://github.com/fritzing/fritzing-app/releases
[2] https://github.com/fritzing/fritzing-app/releases/tag/CD-498
[3] https://github.com/fritzing/fritzing-app/releases/tag/CD-415
[4] https://github.com/fritzing/fritzing-parts/releases
[5] https://github.com/fritzing/fritzing-app/blob/cb7c9cc452d11bd8fe26e67048e...
3 years, 12 months
