devel January 2023

devel@lists.fedoraproject.org

219 participants
292 discussions

Future of BIOS RAID support in the installer
by Vojtech Trefny 17 Jun '23

17 Jun '23

Hi, I am planning to change how we support BIOS RAID (sometimes also called Firmware or Fake RAID) in the installer in the future. I plan to go through the official Fedora change process for Fedora 38, but I'd like to get some feedback first. We are currently using dmraid to support these types of RAIDs in blivet[1] (storage library the Anaconda installer uses) and we would like to replace it with mdadm. The main reason is that dmraid is no longer actively maintained, but it will also mean one less dependency for the installer (we use mdadm for the software RAID support) and one less service running during boot (dmraid-activation.service). The potential issue here is that mdadm doesn't support all BIOS RAID types. mdadm supports only Common RAID Disk Data Format standard[2] (DDF) and Intel Matrix Storage Technology (IMSM) so by switching to mdadm we would remove support for some of the older formats that existed before DDF was standardized. I am not sure how many people are still using these older RAIDs and the main reason for sending this email is to find out. So if you are using a BIOS RAID on your system, can you check what kind? You can find out simply by checking the filesystem type on the underlying disk(s) reported by for example `lsblk -f`. Types supported by mdadm are "ddf_raid_member" and "isw_raid_member". Types supported only by dmraid are "adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member", "lsi_mega_raid_member", "nvidia_raid_member", "silicon_medley_raid_member" and "via_raid_member". So if you have one of the latter ones and you'd be impacted by this change, please let me know so we can reconsider this change. Note that this would affect only the installation process, I know some external and NAS drives use BIOS RAID and these won't be affected, dmraid is not being removed from the repositories (at least I am not aware of this right now, some distributions are already planning to remove dmraid completely). [1] https://github.com/storaged-project/blivet [2] https://www.snia.org/tech_activities/standards/curr_standards/ddf Regards Vojtech Trefny vtrefny(a)redhat.com

4 3

RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller 12 Jun '23

12 Jun '23

Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? * see http://fedora.riscv.rocks/koji/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

20 40

Self Introduction: Andreas Vögele
by Andreas Vögele 05 Jun '23

05 Jun '23

Hello Fedora developers, I'm Andreas from Stuttgart in Germany. I'm a system administrator and software developer, who moved his computers to Fedora about a year ago. I've written a handful of Perl modules that I package at the Open Build Service and Copr. I'd like to maintain some of these modules directly in Fedora. In the past, I maintained ports of other software at SlackBuilds.org and OpenBSD. Occasionally, I contribute patches to free software projects. I enjoy programming in C, Perl and recently Kotlin. Kind regards, Andreas

3 2

Review request for oclock package (orphaned since F35)
by Globe Trotter 14 May '23

14 May '23

Hello, Anyone willing to review this request for a recently (>8 weeks) orphaned package? https://bugzilla.redhat.com/show_bug.cgi?id=2025138 Happy to review in return.

7 25

memtest86plus v6.00
by Richard W.M. Jones 10 May '23

10 May '23

Earlier discussion: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg169800.html Current memtest86+ 5.x requires non-UEFI, which makes it increasingly irrelevant to modern hardware. memtest86 forked into a proprietary product some time ago. However there is hope because upstream memtest86+ 6.00 is (a) open source and (b) seems to work despite the large warnings on the website: https://memtest.org/ Note this new version is derived from pcmemtest mentioned in the thread above which is only indirectly derived from memtest86+ 5.x and removes some features. So my question is are we planning to move to v6.00 in future? I did attempt to build a Fedora RPM, but it basically involves removing large sections of the existing RPM (eg. the downstream script we add seems unnecessary now and the downstream README would need to be completely rewritten). It's probably only necessary to have memtest.efi be installed as /boot/memtest.efi and although it won't appear automatically in the grub menu, it can be accessed by a trivial two line command. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

7 8

Conflicting build-ids in nekovm and haxe
by Andy Li 07 May '23

07 May '23

Hi list, Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901 Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode). I'm not sure how to resolve it. Please advice. Best regards, Andy

5 6

HEADS UP: tesseract-5.3.0 landing in rawhide with soname bump
by Sandro Mani 06 Apr '23

06 Apr '23

Hi I'll be landing tesseract 5.3.0 in rawhide, building it in the f38-build-side-61405 side tag, along with the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract zathura-pdf-mupdf Thanks Sandro

3 4

F38 proposal: Noto CJK Variable Fonts (Self-Contained Change proposal)
by Ben Cotton 15 Mar '23

15 Mar '23

https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts 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 == Switch the default Noto CJK fonts for Chinese, Japanese and Korean from static to variable fonts. == Owner == * Name: [[User:pwu| Peng Wu]] * Email: pwu(a)redhat.com == Detailed Description == In order to reduce the font size in Noto CJK fonts, we plan to switch to use the variable fonts by default. # Split the google-noto-cjk-fonts package into google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts, and provide the variable fonts in google-noto-sans-cjk-vf-fonts and google-noto-serif-cjk-vf-fonts. # Drop several sub packages which are not installed by default from the google-noto-cjk-fonts package. ## Like google-noto-sans-cjk-*-fonts, google-noto-sans-*-fonts, google-noto-sans-mono-cjk-*-fonts, google-noto-serif-cjk-*-fonts and google-noto-serif-*-fonts # Install the Noto CJK Variable Fonts by default. Fedora Copr for testing: https://copr.fedorainfracloud.org/coprs/pwu/noto-cjk/ == Feedback == == Benefit to Fedora == The variable fonts will reduce the disk space usage and live image size compared to the static fonts. {| class="wikitable" |+ RPM Size |- ! Size (bytes) !! Noto Sans CJK !! Noto Serif CJK |- | Static Fonts || 130674365 || 181621033 |- | Variable Fonts || 64613100 || 56924710 |} == Scope == * Proposal owners: ** Package four font packages for Noto CJK fonts ** Retire google-noto-cjk-fonts in Fedora rawhide ** Switch to install variable fonts by default in fedora-comps and langpacks ** Submit pull request to lorax templates to use google-noto-sans-cjk-fonts in the boot.iso * Other developers: * Release engineering: * 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 == When upgrade, the variable fonts will be installed by default. == How To Test == * Please upgrade to Fedora 38 or rawhide to get the latest fonts * Install the variable fonts: google-noto-sans-cjk-vf-fonts and google-noto-serif-cjk-vf-fonts ** Check the google-noto-sans-cjk-ttc-fonts and google-noto-serif-cjk-ttc-fonts packages are replaced * Then use CJK locales to check if the new fonts have any problem == User Experience == This new variable fonts will reduce the disk space usage and live image size. == Dependencies == == Contingency Plan == * Contingency mechanism: Use the static fonts by default - google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts * Contingency deadline: N/A * Blocks release? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == This new variable fonts will reduce the disk space usage and live image size. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

4 6

Retiring Bottles in favor of Flatpak provided by upstream
by Sandro 14 Mar '23

14 Mar '23

Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee

20 37

Release rpkg-1.65 and fedpkg-1.43
by Ondrej Nosek 14 Mar '23

14 Mar '23

Hi all, a new version rpkg-1.65 together with fedpkg-1.43 are released containing both features and bugfixes. Currently, all supported packages are present in stable repositories. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.65.html https://docs.pagure.org/fedpkg/releases/1.43.html Both released (rpkg & fedpkg) versions need to be installed together, they contain some changes incompatible with older packages. Centpkg also requires the newest version of rpkg. Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.65-2.el7&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 https://bodhi.fedoraproject.org/updates/?packages=fedpkg&page=1 rpkg is also available from PyPI. Thanks to all contributors. Regards

5 11

← Newer
1
2
3
4
5
6
7
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2023