In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed.
Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
So we're in freeze for Fedora 37 Beta now, and the first go/no-go
meeting should be on September 8.
It would be really great if we can get the validation tests run now so
we can find any remaining blocker bugs in good time to get them fixed.
Right now the blocker list looks short, but there are definitely some
tests that have not been run.
You can use the testcase_stats view to find tests that need running:
For each validation test set (Base, Desktop etc.) it shows when each
test was last performed. So you can easily look for Basic and Beta
tests that have not yet been run. We need to run all of these.
You can enter results using `relval report-results`, or edit the
summary results page at
https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a
redirect link which will always point to the validation results page
for the currently-nominated compose, which right now is 20220826.n.0.
Sumantro will be running a validation 'test week' starting on
Wednesday, so you can drop by the Fedora Test Day room on
chat.fedoraproject.org to hang out with other testers and get any help
you need in testing. See
for that announcement.
IRC: adamw | Twitter: adamw_ha
> Am 30.08.2022 um 19:14 schrieb J Beard <jas_beard(a)hotmail.com>:
> I thought our meetings were the 1st and 3rd weeks in a month. Or did I miss understand?
Yes, you are right!
=== Next meeting is Sept. 7 ====
=== No meeting on August 31 ====
I’m sure having to stop the notification in federal, when I configured the calendar. But obviously something went wrong.
Hey folks! I apologize for the wide distribution, but this seemed like
a bug it'd be appropriate to get a wide range of input on.
There's a bug that was proposed as an F37 Beta blocker:
it's quite an old bug, but up until recently, the summary was
apparently accurate - dnf would run out of memory with 512M of RAM, but
was OK with 1G. However, as of quite recently, on F36 at least (not
sure if anyone's explicitly tested F37), dnf operations are commonly
failing on VMs/containers with 1G of RAM due to running out of RAM and
There's some discussion in the bug about what might be causing this and
potential ways to resolve it, and please do dig into/contribute to that
if you can, but the other question here I guess is: how much do we care
about this? How bad is it that you can't reliably run dnf operations on
top of a minimal Fedora environment with 1G of RAM?
This obviously has some overlap with our stated hardware requirements,
so here they are for the record:
that specifies 2GB as the minimum memory for "the default
installation", by which I think it's referring to a default Workstation
install, though this should be clarified. But then there's a "Low
memory installations" boxout, which suggests that "users with less than
768MB of system memory may have better results performing a minimal
install and adding to it afterward", which kinda is recommending that
people do exactly the thing that doesn't work (do a minimal install
then use dnf on it), and implying it'll work.
After some consideration I don't think it makes sense to take this bug
as an F37 blocker, since it already affects F36, and that's what I'll
be suggesting at the next blocker review meeting. However, it does seem
a perfect candidate for prioritized bug status, and I've nominated it
I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.
IRC: adamw | Twitter: adamw_ha
# F36 Blocker Review meeting
# Date: 2022-08-29
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat
Hi folks! We have 4 proposed Beta blockers and13 proposed Final
blockers to review, so let's have a review meeting.
If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F36 can be found on the
For more information about the Blocker and Freeze exception process,
check out these links:
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
Have a good weekend and see you Monday!
IRC: adamw | Twitter: adamw_ha
In order to determine if the issue is something in my localhost or in the instructions, I have made available a project
in gitlab containing my ansible playbook. The url for https access s/b: https://gitlab.com/jwhimpel/wildfly-ansible.git
. The url for ssh access s/b: email@example.com:jwhimpel/wildfly-ansible.git .
You will need to go into inventories/testing/host_vars and modify the subordinate directory to the fdqn of the ansible
target host. Inside the newly renamed directory, you will need to add userid and passwords in vars.yml. A shell script
to run the playbook is provided.
I am trying to configure wildfly to use ssl via the instructions found at:
It's the Obtain a certificate from Let's Encrypt command to jboss-sh.cli that errors out for me. PS: You will need to
run the jboss-cli.sh command as root to gain access to the wildfly instance.
I've looked in:
In the wildfly logs are generic error messages but that's not enough for me to figure out what went wrong with certbot
trying to get the certificates.
If you can or cannot get the jboss-sh.cli commands to work properly, please let me know via the list.
Bonus points if you can point me to the source code for jboss-cli.sh so that I can see how the command and options
passed to certbot are generated.
PS: I'm a noob at gitlab, so if you have issues, let me know and I'll see what I can do to resolve them.
Again, for everyone's convenience, a brief summary of our IRC meeting right here.
For greater details see meetbot
== Summary: ==
== Full log: ==
=== Follow up actions ===
DONE pboy will create a next version of the techn. spec. containing our agreements on July 20.
Link: • https://docs.fedoraproject.org/en-US/server-working-group/docs/server-tec...
(See next Topic)
No further open actions.
=== Final decision about an updated Fedora Server Technical Specification ===
It was consensus, that the document is not immutable and thus change be changed later if ideas for improvements surface later. Therefore, a decision now and start with the next tasks.
agreed: WG agrees about the techn.spec. in the current version, with alt. 1 for section 1.2 and editorial adaptations as discussed today.
=== Using Ansible to install and configure Wildfly ===
This is a key component of our "Supported by Ansible“-project (Server Roles), which has taken a back seat to everyday issues for far too long.
jwhimpel has developed a playbook where currently there is still a problem with Letsencrypt certificates to be fixed.
Action: jwhimpel will provide access to the playbook on GitHub so we can re-play the installation and test it.
==== PLEASE NOTE: NEXT MEETING Sept. 7, 2022. ====
Due to calendar displacements, we have 5 Wednesdays again in August, so our 2-week rhythm is out of sync again. It implies: The next meeting is **in 3 weeks**!
NEXT MEETING: September 7, 2022 - #fedora-meeting 17:00 UTC
(3 weeks ahead instead of 2)