devel June 2022

devel@lists.stg.fedoraproject.org

201 participants
282 discussions

Fedora-Cloud-36-20220604.0 compose check report
by Fedora compose checker 04 Jun '22

04 Jun '22

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220603.0): ID: 1288822 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288822 ID: 1288830 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288830 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Re: Self Introduction: Yizheng Xie
by Michel Alexandre Salim 03 Jun '22

03 Jun '22

Welcome (again) Yizheng! On Fri, 2022-06-03 at 21:56 +0000, Yizheng Xie via devel wrote: > Hello, Fedora developer community! > > My name is Yizheng Xie (Fedora Project Username: yizhengxie). > Currently I am a Production Engineer Intern in Meta Kernel Team, > specifically in Linux Userspace projects. I am a first-year master > student in Boston University in Computer Science. My software > engineering skills are most solid in Python, Java, C++ and Golang. > > I will work on Rust Packaging Tooling this summer under the > guidance from Michel (Fedora Project Username:salimma). I am > happy to continue contributing as a package maintainer after my > internship! > Great having you here (both at Fedora and at Meta)! I sponsored Yizheng as a packager - he'll be co-maintaining some packages to get experience with packaging - and will be mentoring him throughout the process. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

1 0

F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
by Ben Cotton 03 Jun '22

03 Jun '22

https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This Change makes it so that Fedora Linux systems installed on legacy x86 BIOS systems will get GPT partitioning by default instead of legacy MBR partitioning. This makes x86 BIOS installs more similar to x86 UEFI installs. == Owner == * Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide Cavalca]], [[User:Salimma| Michel Alexandre Salim]], [[User:Chrismurphy| Chris Murphy]] * Email: ngompa13(a)gmail.com, dcavalca(a)fb.com, michel(a)michel-slm.name, chrismurphy(a)fedoraproject.org == Detailed Description == Once implemented, Anaconda will create a GPT disk table on non-partitioned disks or when the disk is being completely reset when Fedora x86 install/live media is booted in BIOS mode. == Benefit to Fedora == This simplifies our default code path by using the same partitioning scheme as UEFI systems and aligns us more to how Fedora variants that are delivered as disk images, which all use a similar setup. It also paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS installs to enable future conversion to UEFI boot or emulated UEFI boot on legacy BIOS. This is a step toward a longer transition to eventually eliminate direct BIOS boot support, as identified in the discussion for [[Changes/DeprecateLegacyBIOS|the rejected Change to deprecate BIOS support in Fedora Linux 37]]. == Scope == * Proposal owners: ** Submit code changes to Anaconda to use GPT by default on BIOS systems ([https://github.com/rhinstaller/anaconda/pull/4104 gh#rhinstaller/anaconda#4104]) * Other developers: ** Anaconda developers need to review and merge the pull request * Release engineering: [https://pagure.io/releng/issue/10796 #10796] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (not needed for this Change) == Upgrade/compatibility impact == There will be no impact for existing Fedora Linux systems that upgrade. We will not convert the partitioning on upgrade. However, some very old systems have buggy EFI implementations that do not handle legacy BIOS boot on GPT well, and on those systems, users will need to request Anaconda to create a legacy MBR partition table by using <code>inst.mbr</code> on the boot command-line. == How To Test == Currently, users can test by booting Fedora media on BIOS systems with the <code>inst.gpt</code> option to try installing Fedora Linux on a legacy BIOS boot system with a GPT disk. After the change is merged and released, this behavior will be the default, and <code>inst.mbr</code> would be required to go back to the previous behavior. == User Experience == In general, there should nothing materially changing for users. If users look at the disk with <code>fdisk</code> or <code>parted</code>, they'll see a GPT disk instead of an MBR one and a BIOS boot partition will be present, which stores the GRUB boot code on a GPT disk. == Dependencies == This is isolated to Anaconda and is principally dependent on getting the changes into Anaconda. == Contingency Plan == * Contingency mechanism: Revert the change in upstream Anaconda * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == The upstream documentation will be updated as part of the change in Anaconda. == Release Notes == Fedora Linux now uses GPT (GUID Partition Table) partitioning by default for x86_64 systems that use legacy BIOS instead of UEFI. This brings a more modern method of partitioning disks and aligns closer with UEFI-based installations, which already use GPT partitioning. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 16

Self Introduction: Yizheng Xie
by Yizheng Xie 03 Jun '22

03 Jun '22

Hello, Fedora developer community! My name is Yizheng Xie (Fedora Project Username: yizhengxie). Currently I am a Production Engineer Intern in Meta Kernel Team, specifically in Linux Userspace projects. I am a first-year master student in Boston University in Computer Science. My software engineering skills are most solid in Python, Java, C++ and Golang. I will work on Rust Packaging Tooling this summer under the guidance from Michel (Fedora Project Username: salimma). I am happy to continue contributing as a package maintainer after my internship! Thank you! Yizheng

1 0

F37 proposal: Erlang 25 (Self-Contained Change proposal)
by Ben Cotton 03 Jun '22

03 Jun '22

https://fedoraproject.org/wiki/Changes/Erlang_25 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update Erlang/OTP to version 25. == Owner == * Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]] * Email: lemenkov(a)gmail.com, erlang(a)lists.fedoraproject.org, bowlofeggs(a)fedoraproject.org, jcline(a)fedoraproject.org == Detailed Description == Upgrade Erlang to version 25 which brings a lot of changes. Just a few highlights [https://www.erlang.org/blog/my-otp-25-highlights/ from many]: * [https://www.erlang.org/blog/parallel-signal-sending-optimization/ The Many-to-One Parallel Signal Sending Optimization]. * [https://www.erlang.org/blog/type-based-optimizations-in-the-jit/ Type-Based Optimizations in the JIT]. * New 'maybe' operator. * The JIT now supports the AArch64 (ARM64) architecture. * Better support for perf and gdb. * Better error reporting in some cases. Aside from this, we plan to further improve quality of Erlang and related packages. These are shortcomings we want to address: * Finish switching to rebar3 as a main build tool and deprecate rebar2. ** Improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging Guidelines]] according to this switch and promote it as the official guideline. * Every daemon written in Erlang has its own logging solution which doesn't use neither syslog nor Journald. We should start switching them to unified logger. * We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus erlang-dbus] library or any other recent implementations.. * SELinux rules for main Erlang applications (Ejabberd, CouchDB, RabbitMQ) are still outdated or missing. == Benefit to Fedora == Fedora users, both developers and end-users, will have visible benefits from using Fedora-provided packages. Namely: * Improved scalability and robustness. * Much easier developing and debugging. == Scope == * Proposal owners: ** [https://bugzilla.redhat.com/show_bug.cgi?id=2055490 Upgrade Erlang to the latest version (25.0)]. ** Every Erlang daemon's systemd unit should require epmd.socket. ** Upgrade outdated packages: *** {{package|riak|Riak}} **** {{package|riak|Riak}} has has been retired. We have to re-add it back. *** {{package|ejabberd|Ejabberd}} *** {{package|rabbitmq-server|RabbitMQ}}. *** {{package|couchdb|CouchDB}} **** {{package|riak|CouchDB}} has has been retired. We have to re-add it back. ** {{package|erlang-rebar3|rebar3}} ** Package GDB macros for easier coredump debugging (see also [https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]). * Other developers: N/A * Release engineering: TBA * Policies and guidelines: ** We should promote officially [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging Guidelines]]. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * Binaries compiled with Erlang 22 and older are no longer compatible. == How To Test == * Ensure that high-grade Erlang applications are still working: {| border="1" |- | '''Name''' || '''Tested''' |- | {{package|couchdb}} || {{no}} (package was retired :( ) |- | {{package|ejabberd}} || {{no}} |- | {{package|elixir}} || {{no}} |- | {{package|rabbitmq-server}} || {{no}} |- | {{package|riak}} || {{no}} (package was retired :( ) |- | {{package|wings}} || {{no}} |} * Collect feedback from volunteers regarding their experience with this Erlang/OTP version == User Experience == Users will get more robust, scalable, and fast Erlang applications. == Dependencies == The following packages must be rebuilt: NIF-libraries. == Contingency Plan == * Contingency mechanism: None necessary. Instead of falling back to the previous version we should fix existing packages in order to help the Community. We should also monitor upstream development process for potentially discovered issues and proactively apply patches (as we already did with [[Features/Erlang_R14|Erlang R14]], [[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang R16]], [[Changes/BetterErlangSupport|Erlang 17]], [[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]], [[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]], [[Changes/Erlang_22|Erlang 22]], [[Changes/Erlang_23|Erlang 23]], and [[Changes/Erlang_24|Erlang 24]]). It should be noted that this change consists from an independent or loosely coupled smaller changes. If we fail to deliver some changes in time, we should reschedule these exact changes to the future Fedora release while keeping already implemented ones. * Contingency deadline: N/A * Blocks release? N/A * Blocks product? N/A == Documentation == * [https://www.erlang.org/news/157 Erlang/OTP 25.0 release notes] == Release Notes == Erlang/OTP 25.0 is available in Fedora 37. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 Change: Replace jwhois package with whois for Fedora Workstation (Self-Contained Change proposal)
by Ben Cotton 03 Jun '22

03 Jun '22

https://fedoraproject.org/wiki/Changes/Replace_jwhois_with_whois_in_Fedora_… == Summary == Fedora Workstation product core group includes `jwhois` package. Replace it with `whois` package which is more actively developed. == Detailed Description == `Fedora Workstation product core` group includes `jwhois` package. Its last commit is [http://www.gnu.org/software/jwhois/ from 2015]. Users having issues with certain TLDs and the solution is usually manually editing the `/etc/jwois.conf` file. `whois` package is [https://github.com/rfc1036/whois more actively maintained] and doesn't have those issues. == Benefit to Fedora == Users will have a better experience querying `whois` information for a domain. == Scope == * Proposal owners: * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == * Run `rpm -q --whatprovides whois` * It should print `whois-*` == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * 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 == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

3 2

Help with go spec file
by Mark E. Fuller 03 Jun '22

03 Jun '22

Hi all, I'm fairly new to go and am looking to make a spec file and build jsonnet (https://github.com/google/go-jsonnet/, https://jsonnet.org/) The go2rpm utility has proven very helpful, but there appear to be two irregularities with building this package that I don't know offhand how to address (including from reading https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/) 1) What is the preferred way to ignore (or remove) unnecessary BUILD.bazel files? There is one in cmd/ which is obviously not a buildable command, and so this results in an error in the naive use case. 2) How should nested folders in cmd/ be built? Here, again, the basic template throws an error since cmd/internal contains no *.go files, only a BUILD.bezel file and a nested cmd directory. Thank you all, fuller -- Mark E. Fuller, Ph.D. fuller(a)fedoraproject.org fuller(a)stossrohr.net @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60

2 1

CPE Weekly Update – Week 22 2022
by Lenka Segura 03 Jun '22

03 Jun '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) Week: May 30st to June 3rd 2022 If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update--week-22-2022/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-2022-06-01.pdf Update ------ ### Fedora Infra * Got to the bottom of an issue causing python38 modules to not be available in the epel8 buildroot * Bunch of reinstalling of openqa workers to help AdamW isolate a lockup issue. Still ongoing. * Moved some more ocp3->ocp4 apps. * Tracked down a https push segfault on src.fp.o to the new jq package in rhel 8.6 (downgraded and filed bug) * Got internetx02 (new donated hw replacement for 01) installed with rhel9. * New ipsilon release! Many thanks Abompard! (dedicated otp field, email or login works, and more) ### CentOS Infra including CentOS CI * Artifacts storage node replacement for CI (ready/deployed but to be announced in wider communication plan) https://pagure.io/centos-infra/issue/605 * CBS/koji proxy/settings tuning due to introduced change for gitlab (breaking some builds/tests) https://pagure.io/centos-infra/issue/782 * Roadmap for CentOS CI move to EC2 (working on communication plan) * Business as usual (mirrors proposals, tags) * Blocked: * Git.centos.org (waiting on EXD) * Stream storage migration (waiting on IT) ### Release Engineering * F34 is going EOL in one week * glibc update broke ostree updates in f36, more info https://pagure.io/releng/issue/10816 * Business as usual ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Initial push of c8s packages to gitlab. * New Content Resolver feature: it's now showing repo per package in views. * Fedora ELN: Repositories are now closer to CentOS Stream, the Everything repository has been replaced with Extras which contains the packages not explicitly included in the other Variants. ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Client CLI (almost there) * Migration Preparations ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * Business as usual * Continued work on noggin-messages and datanommer-models ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * This week we have 5863 (+99) packages, from 2672 (+6) source packages * amavis installation from epel9 problem resolved by backporting upstream patch to switch dependency from libidn to libidn2 * Backported java_arches macro from Fedora to epel9 * Working on a method for enabling CRB repository when epel-release is installed * Deployed fix for some CRB module packages not showing up in the epel8 buildroot, but it caused too many non-default module packages to be included so it had to be rolled back. * Retired lmdb-epel since lmdb-devel was added to RHEL8/RHEL9. Later discovered that some users still depend on the lmdb subpackage (even though nothing in EPEL requires it), so the package was unretired to provided just that subpackage on epel8 only. Kindest regards, CPE Team

1 0

Fedora-Cloud-34-20220603.0 compose check report
by Fedora compose checker 03 Jun '22

03 Jun '22

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220602.0): ID: 1288571 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288571 ID: 1288579 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288579 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

[Test-Announce] Kernel 5.18 Test Week 2022-06-05 through 2022-06-11
by Sumantro Mukherjee 03 Jun '22

03 Jun '22

Hey All, I would like to invite all of you to participate in the Kernel 5.18 Test week is happening from 2022-06-05 to 2022-06-11. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat for question and discussion. BTW, we have the fedora community survey happening[2] and the election happening too[3] Needless to say, you will get a badge for participating in all activities talked about in this email! [0] http://fedoraproject.org/wiki/Test_Day:2022-06-05_Kernel_5.18_Test_Week [1] https://testdays.fedoraproject.org/events/136 [2] https://discussion.fedoraproject.org/t/2022-fedora-community-survey/39569 [3] https://elections.fedoraproject.org/ -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED _______________________________________________ test-announce mailing list -- test-announce(a)lists.fedoraproject.org To unsubscribe send an email to test-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://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro… Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2022