Please clarify master vs main vs rawhide branches
by Steven A. Falco
I see that the master to main conversion has happened. I'd like to know the recommended way to deal with that.
Currently, I'm doing:
git fetch --all
git remote prune origin
git remote set-head origin -a
git checkout main
The above sets origin/HEAD to rawhide
Question 1: Is that the right set of steps, or is there a better way to update my local repos?
Question 2: For the packages I maintain, should I put changes in main or rawhide? Should I keep main and rawhide in sync?
Steve
3 years
Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Power4kPageSize
== Summary ==
On ppc64le, the kernel is currently compiled for 64k page size.
This change proposes using the more common 4k page size.
Some HPC workloads may be disadvantaged slightly. Workstation users
are likely to encounter fewer bugs.
Some things, like the AMD Radeon GPU drivers, firmware or related
code, appear to be completely non-functional on the 64k page size.
Insufficient upstream developers are testing such issues on this
architecture.
== Owner ==
* Name: [[User:pocock|Daniel Pocock]]
* Email: daniel(a)pocock.pro
== Detailed Description ==
== Feedback ==
Discussed several times on devel,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
latest here]
[https://forums.raptorcs.com/index.php/topic,248.msg1852.html
discussed upstream in the Raptor forum]
== Benefit to Fedora ==
Better first impression for users of ppc64le workstations.
Users can focus on reporting ppc64le bugs without being sidetracked by
page size bugs.
== Scope ==
* Proposal owners: [[DanielPocock]]
* Other developers: please volunteer by adding your name here
* Release engineering: [https://pagure.io/releng/issue/9939 #9939]
** wait for 5.12 kernel, verify that it includes the Btrfs patches for
arbitrary 4k / 64k sector size, independent of the page size
** create a kernel with 4k page size to run on the ppc64le build servers
** ensure the default kernel RPM in the distribution has 4k page size
** perform the mass rebuild running on the 4k page size
** create an installer ISO based on the revised kernel with 4k page size
* Policies and guidelines: no, as it is an arch-specific issues, most
other architectures already have a 4k page size
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: none of the current objectives relate to
this change
== Upgrade/compatibility impact ==
If the user has already formatted their root filesystem with Btrfs and
a 64k sector size, they need to be using a Fedora kernel that supports
both 4k and 64k. This is anticipated in a future kernel release, 5.12
and will hopefully be ready for F34 or
F35[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje....
== User Experience ==
New GPUs are more likely to just work on this non-x86 architecture, as
long as the latest firmware, mesa, llvm are also used.
Btrfs, the default filesystem, will use the sector size identical to
the running kernel's page size. As the 4k page size is more common,
this will ensure Btrfs filesystems created on ppc64le hosts can be
used on x86 and other hosts without hassle.
== Dependencies ==
All RPMs must be rebuilt on a server running the final page size (4k)
== Contingency Plan ==
* Contingency mechanism: Prepare a kernel with the original 64k
config, install it on the build server, rebuild all the packages for
this architecture
* Contingency deadline: whenever the last time for a full rebuild or
kernel change is possible
* Blocks release? Yes, full rebuild of all packages must be completed
before release
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years
Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok
Recently I've reported some Big Endian related test failures to an
upstream project [0].
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
Any tips?
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI [1]
Any better tips? Thanks
[0] https://github.com/mikedh/trimesh/issues/249
[1]
https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architectu...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years
Meaning of Size Directories
by Sergio Belkin
Hi,
Tools such as ls or stat report the size of a directory. Of course it is
not the content size.
stat -c %s /home/sergio/.config
6550
What does 6550 mean in btrfs context?
Thanks in advance!
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
3 years, 1 month
What to do about EPEL package branch with no active maintainer?
by Henrik Nordström
I recently took over Radare2 maintenance for Fedora after it was
orphaned, and now noticed it is also packaged in EPEL-8.
I am not in a good position to actively maintain the EPEL-8 release. I
am not an EPEL user, no interest in EPEL, and and not very comfortable
with doing "blind" maintenance by simply merging changes from fedora
and and hope for the best.
The question is then what should be done with the stale and known
broken EPEL branch of the package? Just let it bitrot further?
Anyone who wants to maintain the EPEL-8 branch of Radare2?
Or co-maintain the Fedora version?
Regards
Henrik
3 years, 1 month
Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally
compatible implementation
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.
== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.
== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
closer to the experience of other operating systems.
* Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
and the management into separate processes. This makes it possible
to better integrate with
the other system components or swap out the default policy for a
highly customized one (such as
for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience
and configuration of the
audio infrastructure with better integration throughout the system.
* Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as
JACK. JACK application should run with comparable performance even
in low-latency situations.
* Security
PipeWire enforces per client security. Object visibility and the
actions on them can be
configured independently per client. This makes it possible to
enforce a security policy for
sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
block them from interfering with other applications.
* Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more
flexible and distributed nature of the design of PipeWire should
encourage more new features
and use-cases.
== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.
* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by
default but can be activated
with paprefs. this includes TCP and RTP transport of audio.
* make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
* easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
anymore.
Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:
* latency reporting: useful to align streams
* freewheeling: used when rendering a project
* jackdbus: used by some tools to manage the graph
== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.
After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as
usual. Check out a website with a video chat test page
(bluejeans.com/111).
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience ==
In general, users should not be able to see any change when using
PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes
the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will
be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.
== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
[https://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md...
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md]...
to use/test)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 1 month
F34 gdm login prompt goes crazy when a fingerprint reader with no
enrolled prints is present
by Hans de Goede
Hi Benjamin, Ray,
I noticed this problem while dogfooding F34, I'm fully up2date as of today.
Today's gdm update did help in making the problem more clear.
What happens is that as soon as I press enter / click my main user in gdm,
the password entry box keeps getting updated (and clearing its content)
every 1 - 2 seconds with a "failed to authenticate with fingerprint"
(or something like that) briefly showing below the password entry box
every time it gets cleared.
After a non-fixed amount of tries it stops doing this and only then I
can successfully login. The same happens on the lock screen of gnome-shell,
except that there it never stops doing this.
The "failed to authenticate with fingerprint" is new as of todays
gdm update, before this it was just "failed to authenticate". Now that
I know fprintd is involved I've masked fprintd and that works around this.
As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen,
with the "Linux" fingerprint firmware installed by fwupd. I don't think
I have ever enrolled a fingerprint, which might be part of the problem,
but in that case it should really just act as if there is no fingerprint
reader present.
The login dialog / fprintd should certainly _not_ repeatedly show the
error IMHO even showing it once would be wrong here, but it would be
a big improvement.
Let me know if you need any logs, want a bugzilla for this, or if there
is anything else which I can do to help debug this.
Regards,
Hans
3 years, 1 month
Status update for the new AAA system
by Aurelien Bompard
Hey folks!
As you've probably heard before, we're upgrading our authentication system to something that is based on FreeIPA.
Here's a quick status report on that initiative. We're currently in an integration phase, figuring out the smaller details of configuration and infrastructure setup before we switch production.
- The infra team wants to do a couple things that FreeIPA does not support out of the box, like enforcing 2FA for specific services such as sudo, so we need to think about how we want to do it.
- Also, using kinit with 2FA tokens proved to be more complex than we'd like it to be.
- We're trying out a more continuous approach to importing accounts, because a full run takes 3 days and during the migration we'll want to run the import script without having a 3 days downtime.
- We also have to do some FreeIPA performance tuning, because we have something like 120k accounts and the default configuration is not appropriate for that amount of data, especially when we want to list all groups or worse, all users.
To sum it up, we're currently working on integration and migration preparation. We need to fix these issues before we go to prod, but it's a bit difficult to say how long it's going to take (especially with perf tuning, fix one perf issue and there can be another one right behind).
One sure thing is that it's better to have these issues now rather than after the switch to prod.
Cheers!
Aurélien
3 years, 1 month
OCaml 4.12
by Jerry James
Richard, I see that the OCaml 4.12 release is not expected to happen
until next week, after the beta freeze:
https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294
Some of my OCaml packages are currently not installable, due to the
dynlink hiccup, I think. Rather than enter beta freeze with them in
this state, I would like to rebuild them. I was thinking about
proceeding with the updates needed for OCaml 4.12, since I have to
build these packages anyway, and the updated versions also work with
OCaml 4.11. As a reminder, these are the updates:
- ocaml-base: 0.14.0 -> 0.14.1
- ocaml-migrate-parsetree: 1.8.0 -> 2.1.0
- ocaml-ppxlib: 0.15.0 -> 0.22.0
- ocaml-bisect-ppx: 2.5.0 -> 2.6.0
- ocaml-tyxml: apply this pull request to switch to ppxlib:
https://github.com/ocsigen/tyxml/pull/271
- ocaml-lwt: 5.3.0 -> 5.4.0
- ocaml-ppx-deriving: 5.1 -> 5.2.1
- ocaml-ppx-optcomp: 0.14.0 -> 0.14.1
- ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2
- ocaml-sedlex: 2.2 -> 2.3
- ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1
- ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2
- Retire ocaml-ppx-tools-versioned
along with a number of other package builds just to fix dependencies.
That would also simplify things for you when OCaml 4.12 is released,
as all of these updates would already be in place. What do you think?
Also, I would like to update ocaml-ocamlgraph to version 2.0.0 at some
point. The only Fedora consumers are frama-c and ocaml-dose3. The
current version of frama-c can already be built with either ocamlgraph
1.x or 2.x. The version of ocaml-dose3 in Fedora (5.0.1) cannot be
built with ocamlgraph 2.x. However, upstream has moved here:
https://gitlab.com/irill/dose3
and released a 6.x series that supports ocamlgraph 2.x.
Unfortunately, there are issues with moving to version 6.x. First,
and easiest, the new versions depend on camlbz2 and parmap, neither of
which are in Fedora. I've put together spec files for those two and
can submit them for review if nobody else wants to do so. Second,
upstream removed support for RPM in this commit:
https://gitlab.com/irill/dose3/-/commit/e656b5783f1fc5fd75e0e2716b0a40aca...
I don't know why. The commit message does not give a reason, and this
change is not mentioned in the project changelog. I assume RPM
support is important for the Fedora build of ocaml-dose3. I don't
know what the best approach is to resolve this issue, but it is
blocking the ocamlgraph update. Any thoughts on the matter are
appreciated.
Regards,
--
Jerry James
http://www.jamezone.org/
3 years, 1 month
Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
== Summary ==
This Change will move Fedora git repositories to use "main" as the
default git branch instead of "master". Specific repositories will be
manually moved and default git branch for new projects will be set to
use "main".
The Fedora Community strives to be open and welcoming. Some language
around our git repositories is dated and could be more inclusive. Many
git repositories currently use "master" as the default branch. This
Change will move many repositories (see below) to use a "main" branch
as default. This small bit of naming adjustment is in-line with
Fedora's vision for free and open source software built by inclusive,
welcoming, and open-minded communities.
== Owner ==
* Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
[[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
[[User:till| Till Maas]]
* Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
mboddu(a)bhujji.com, opensource(a)till.name
== Detailed Description ==
The Fedora Project controls a number of git repositories. This change
will move the default branch (that is, the git branch used when
nothing is specified) from 'master' to 'main'. Existing git clones
will need to pull to get the changed default branch. Existing Pull
Requests against the 'master' branch will need to be rebased against
the 'main' branch. Documentation will be updated.
== Benefit to Fedora ==
The Fedora Project will be a more welcoming place for new contributors.
== Scope ==
This change will take place in a number of phases:
=== Phase0 - 2020-12-14 ===
A guide will be published to explain how maintainers/project
managers can change the default
branch on pagure.io, which they can then do based in their projects desires.
=== Phase1 - 2020-12-15 ===
The following repos will be switched:
src.fedoraproject.org/flatpacks/*
pagure.io:
releng
releng/*
fedora-comps
fedora-kickstarts
fedora-infrastructure
fedora-lorax-templates
fedora-mediawikitheme
fedora-packager
fedora-infra/*
infra-docs
koji-fedmsg-plugin
workstation-ostree-config
pungi-fedora
github.com
fedora-infra/*
=== Phase2 - 2021-01-13 ===
src.fedoraproject.org/*
pagure.io default for new projects will be changed to 'main'
* Proposal owners:
Switching all above listed projects git repos to use 'main'
Deleting the 'master' branch
Announcing when changes have been made on devel-announce / other lists.
* Other developers:
Other developers are encouraged to change their upstream projects
on pagure.io, github or gitlab.
* Release engineering:
Releng will adjust any scripts that assume 'master' branch to use
'main' instead. The list includes and maybe few more
[https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
update-critpath.py]
[https://pagure.io/releng/blob/master/f/scripts/block_retired.py
block_retired.py]
[https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
update-docs.sh]
[https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
find_unblocked_orphans.py]
[https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
mass-rebuild-second-run.py]
[https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
adjust-eol.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
create-new-release-branches.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
create-branch.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
adjust-eol-all.py]
[https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
check-unretirement.py]
[https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
mass-rebuild-special.py]
[https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
need-rebuild.py]
[https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
distgit-branch-unused.py]
[https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
create-new-release-branches.py]
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Users with old checkouts will need to update their git configuration
or re-clone repositories that have changed before they can see any new
changes.
Repos used to build content for docs.fedoraproject.org can change the
default git branch, but the Antora module version (in `antora.yml`)
should remain `master` pending support for alternate "unversioned"
versions upstream.
== How To Test ==
# git clone <one of the listed repositories>
# cd <repositoryname>
# git branch
should return: `* main`
== User Experience ==
Users and developers will see more welcoming language and that the
fedora project expended effort to be more welcoming to them.
== Dependencies ==
none
== Contingency Plan ==
* Contingency mechanism: Revert repositories, scripts, and docs back
to the unwelcoming 'master'
* Contingency date: 2020-01-13
== Documentation ==
A short guide on how to change this for pagure.io will be produced.
== Release Notes ==
Many git repositories used to create Fedora releases were moved to use
a 'main' branch instead of a 'master' branch. The Fedora Project
envisions a world where everyone benefits from free and open source
software built by inclusive, welcoming, and open-minded communities.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 1 month