Today I've attempted to run "dnf upgrade".
It has the following in it:
protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
Enabling module streams:
I don't consider this behavior adequate for a released Fedora version.
As a maintainer of dependent packages (Cura stack) I have tested and built it
against the nonmodular protobuf. What just happened here and how do I track it down?
dnf doesn't even tell me what module is this in. I suppose eclipse.
However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
I was recently bit by a bug, which was caused by a mismatch between texlive-biblatex and biber. The technical side is not so important, only so much that they need each other in a pretty specific version, which is not reflected on the rpm level.
What I found weird is that you can't comment on an update, which is already pushed to stable. A lot of users are only hit by a bug, once it reaches stable and then you don't have any possibility to highlight a bug report or an issue with this update. I would like to have the possibility to add such an information to an update, which introduced the issue.
Also I would like to ask if it is possible for important updates, like the texlive one to increase the stable karma. It really depends which mirrors you are using and if you are unlucky the updates get pushed to stable, before it reaches updates-testing for you and then again there's nothing to add, once it's pushed.
Builds will start soon into a side tag (f32-build-side-14856), and
then if everything goes OK I will merge it into Rawhide.
This version should have fixed RISC-V support which is broken
currently (and requires some extremely difficult to backport fixes -
we already tried that and gave up, so upgrading to OCaml 4.09 is the
only solution if you want fixed RISC-V support).
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: <pbrezina(a)redhat.com>
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
=== Solution Step by Step ===
==== Step 1) Provide a unified way to read if nullok is enabled or not ====
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
==== Step 2) Fix passwd -d ====
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
==== Step 3) Fix AccountService ====
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
==== Step 4) Fix Desktop Environments ====
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
==== Step 5) Update PAM configuration to disable nullok by default ====
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)? Is a mass rebuild required? include a link to the releng
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
He / Him / His
Fedora Program Manager
When installing Fedora 31 on a system, I noticed that anaconda defaulted
to US/Pacific for the time zone, rather than the correct US/Central.
I'm on a Google Fiber connection, and when I check Fedora's service at
https://geoip.fedoraproject.org/city I get the info for their HQ in
Mountain View. I'm pretty sure I got my proper location in the past.
What geoIP service is Fedora using for this? When I check MaxMind's
site, they give the correct info for both my IPv4 and IPv6 addresses
(which BTW the Fedora geoIP lookup doesn't have a v6 address so only
I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
and that DB has the correct info.
Chris Adams <linux(a)cmadams.net>
First, done anyone have a working version of the script? Google returns the
github page which hasn't been updated in 3 years and currently fails trying
to import the 'fedora_cert' module.
Secondly, how is this not in a package yet? It's an extremely useful tool
for determining if initiating the non-responsive maintainer process.
Dear David Abdurachmanov,
I have seen your presentation about fedora bootstrap on RV64, it was very
nice presentation actually. I am planning to boot a RISC-V Fedora on QEMU
Emulator, but I want to do some changes in fedora distro. Fedora distro
without compressed instruction support require for me, for this I have
written some steps where I can do changes. This steps completely I have
taken from your presentation. Please correct my steps whether I am going in
correct way or not ? I am new to fedora as well as bootstrap process.
1. Installing QEMU (In x86 fedora host PC)
2. Installing GNU cross compiler tool chain (In this step I have installed
tool chain *https://github.com/riscv/riscv-gnu-toolchain
<https://github.com/riscv/riscv-gnu-toolchain> *(RV64IMAFD support) in
fedora 86 host PC).
3. Install Berkly bootloader (In this step I have installed bootloader
<https://github.com/riscv/riscv-pk>* in fedora x86 host pc).
4. Linux kernel + basic rootfs (In this step taken Linux kernal from
<https://www.kernel.org/>* and cross compiled with above tool chain,
created basic rootfs).
From Here I am not understanding the steps
5. Cross compile and Install "RPM" packages and dependencies (where I can
get RPMs and dependencies list, after cross compiling RPMs whare I have to
6. Install pre build RPMS (no idea about this step).
7. Rebuild RPMS from SRPMs natively (no idea about this step).
8. Install the new RPMS (no idea about this step).
9. Build stage4 image (no idea about this step).
Please correct my steps and give the solutions for step (5-9).
The elections for FESCo for Fedora 31 have concluded, and the results
are shown below.
FESCo is electing 5 seats this time.
A total of 273 ballots were cast, meaning a candidate
could accumulate up to 2184 votes (273 * 8).
The results for the elections are as follows:
# votes | name
1490 | Miro Hrončok
1350 | Kevin Fenzi
1115 | Zbigniew Jędrzejewski-Szmek
879 | Fabio Valentini
877 | David Cantrell
868 | Justin Forbes
813 | Randy Barlow
534 | Pete Walter
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
For results of other elections, see the Community Blog post:
He / Him / His
Fedora Program Manager
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
says that I need to patch application (if it does not have config
file) to use "PROFILE=SYSTEM" as the argument to the cipher list.
However, when I was looking into the library which uses this function
(rust-openssl), I found following piece of code:
/// Creates a new builder for TLS connections.
/// The default configuration is subject to change, and is
currently derived from Python.
pub fn builder(method: SslMethod) -> Result<SslConnectorBuilder,
let mut ctx = ctx(method)?;
Then I looked at CPython and found that it does this:
/* Ignored in SSLContext constructor, only used to as
#define PY_SSL_DEFAULT_CIPHER_STRING SSL_DEFAULT_CIPHER_LIST
And then it just ignores call to SSL_CTX_set_cipher_list().
So my question would be: Should I patch rust-openssl to use
PROFILE=DEFAULT or I should just remove that call entirely? It is not
very clear to me from the guidelines. Also since I want to get this
upstream, which option is more portable?