Orphaning lizardfs
by Jonathan Dieter
I've just orphaned lizardfs. Lizardfs is a clustered network
filesystem that has very efficient small file / metadata performance,
but hasn't seen any upstream point releases since the end of 2017 and
now FTBFS in the latest mass rebuild.
Jonathan
1 year, 1 month
Fedora CoreOS Meeting Minutes 2023-02-01
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-01/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-01/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-01/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:31:05 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-01/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:31:10)
* Action items from last meeting (dustymabe, 16:36:06)
* ACTION: dustymabe to verify that booting a compressed kernel on
ppc64le works (dustymabe, 16:37:37)
* tracker: Fedora 38 changes considerations (dustymabe, 16:40:55)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1357
(dustymabe, 16:41:00)
* ACTION: jlebon/dustymabe to ask bgilbert if we should create some
process for testing newer versions of golang early for our various
projects that use it (dustymabe, 16:47:24)
* for golang 1.20 we don't foresee any problems, but we should
pro-actively test before hand to make sure there are no surprises
(dustymabe, 16:48:07)
* we think this should be a transparent update for us (dustymabe,
16:51:02)
* this should be transparent to us. If any problems arise it should
happen at rpm build time. (dustymabe, 16:52:21)
* we don't ship perl (dustymabe, 16:53:10)
* should be transparent to us, no changes for us to make (dustymabe,
16:54:36)
* we don't ship fonts, this won't apply to us (dustymabe, 16:56:48)
* ACTION: dustymabe create a new ticket for us to decide how we want
to handle the shutdown timeout change (dustymabe, 17:03:06)
* we will need to consider the shutdown timeout change and if we want
to accept it or add our own configuration override. (dustymabe,
17:03:30)
* this change should be picked up by us transparently; no active
changes for us to make (dustymabe, 17:06:41)
* nothing for FCOS to do specifically but the maintainers of the
packages we own may choose to update (dustymabe, 17:10:14)
* we don't ship flatpak; no change for us (dustymabe, 17:11:02)
* we don't ship libpinyin (dustymabe, 17:12:35)
* this is another variant of Fedora (dustymabe, 17:12:57)
* we don't ship imagemagick (dustymabe, 17:13:07)
* this is another variant of Fedora (dustymabe, 17:13:13)
* LINK:
https://github.com/coreos/coreos-assembler/blob/9fa3aaf93e44a53a4f5b27f15...
(jlebon, 17:16:07)
* This change is specific to anaconda. (dustymabe, 17:17:20)
* we don't ship python-pyramid (dustymabe, 17:18:32)
* this is another variant of Fedora (dustymabe, 17:18:55)
* we don't ship this package (dustymabe, 17:20:14)
* we don't ship this package (dustymabe, 17:20:18)
* we don't ship this package (dustymabe, 17:20:22)
* we don't ship this package (dustymabe, 17:20:26)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1391
(dustymabe, 17:21:35)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1394
(dustymabe, 17:21:45)
* we need to make some changes to allow suid ssh-keygen and also
migrate existing permissions on host keys for upgrading systems
(dustymabe, 17:22:24)
* open floor (dustymabe, 17:29:29)
* the splash page revamp has had some further edits/suggestions:
https://discussion.fedoraproject.org/t/44632/18 (dustymabe,
17:30:40)
* ACTION: jlebon to take our concerns about host key permission
migration script failure to sshd package maintainer (dustymabe,
17:33:25)
Meeting ended at 17:44:23 UTC.
Action Items
------------
* dustymabe to verify that booting a compressed kernel on ppc64le works
* jlebon/dustymabe to ask bgilbert if we should create some process for
testing newer versions of golang early for our various projects that
use it
* dustymabe create a new ticket for us to decide how we want to handle
the shutdown timeout change
* jlebon to take our concerns about host key permission migration script
failure to sshd package maintainer
Action Items, by person
-----------------------
* dustymabe
* dustymabe to verify that booting a compressed kernel on ppc64le
works
* jlebon/dustymabe to ask bgilbert if we should create some process
for testing newer versions of golang early for our various projects
that use it
* dustymabe create a new ticket for us to decide how we want to handle
the shutdown timeout change
* jlebon
* jlebon/dustymabe to ask bgilbert if we should create some process
for testing newer versions of golang early for our various projects
that use it
* jlebon to take our concerns about host key permission migration
script failure to sshd package maintainer
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (152)
* jlebon (37)
* zodbot (17)
* darknao (17)
* spresti[m] (5)
* jmarrero (4)
* aaradhak[m] (1)
* aaradhak (1)
* marmijo[m] (1)
* jbrooks (1)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
1 year, 1 month
libhackrf soname bump
by Steven A. Falco
libhackrf has updated from 0.7.0 to 0.8.0 in rawhide.
No dependent packages depend on the exact version, so nothing else should need rebuilding. Tested with CubicSDR and gnuRadio.
Steve
1 year, 1 month
-fno-omit-frame-pointer does not work as advertised
by Kevin Kofler
Hi,
to those who are pushing the -fno-omit-frame-pointer change: Are you aware
that neither that flag nor even -mno-omit-leaf-frame-pointer actually
guarantee that every leaf function is going to carry a frame pointer, as
required for your backtraces?
See for yourself:
https://godbolt.org/z/TjzTsWoWT
The only way to get GCC to generate a frame pointer for this function is to
not use any optimization at all (-O0, or just leave the flags empty, which
unfortunately defaults to -O0 in GCC).
I have tried:
* just -O2
* -O2 -fno-omit-frame-pointer
* -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
and all of them produce just imul+mov+ret, which means that an unwinder
based purely on frame pointers will NOT be able to locate the caller of this
function if the profiler snapshots it in the middle.
Another issue is that even if the function does have a frame pointer, it
takes time to set up the frame pointer (push rbp; mov rbp, rsp), and it also
needs to be popped at the end (pop rbp) before returning (ret), so a
randomly sampled snapshot can always happen to be taken in the short time
window where the frame pointer is not ready, which will also lead to the
caller being unable to be located. This inherently makes purely frame-
pointer-based unwinding unreliable.
Frame pointers sound like a simple solution to unwinding, but they are not.
They are no complete replacement for unwinding information.
Kevin Kofler
1 year, 1 month
What should we do about "shopping list" groups in comps?
by Adam Williamson
Hey folks!
I've sort of happened into doing some maintenance of fedora-comps over
the last few years. Something that bugs me while working on this is how
many "shopping list" groups we still have. I'm talking about things
like the network-server group:
<id>network-server</id>
<_name>Network Servers</_name>
<_description>These packages include network-based servers such as DHCP, Kerberos and NIS.</_description>
<default>false</default>
<uservisible>true</uservisible>
<packagelist>
<packagereq type="optional">389-ds-base</packagereq>
<packagereq type="optional">ahcpd</packagereq>
<packagereq type="optional">amanda-server</packagereq>
<packagereq type="optional">babeld</packagereq>
<packagereq type="optional">cobbler</packagereq>
<packagereq type="optional">dhcp-relay</packagereq>
<packagereq type="optional">dhcp-server</packagereq>
<packagereq type="optional">dnsmasq</packagereq>
<packagereq type="optional">freeradius</packagereq>
...etc etc...
I'd define a "shopping list" group as one based around a vague theme
and whose packages are all (or almost all) optional - it's clearly not
a group that's meant to be installed as a whole, or as a part of a
system deployment. These groups were instead designed as lists to pick
individual packages from, in the old anaconda installer interface that
let you do individual package selection (this is, what, a decade or so
ago now?), and in software installation apps that similarly let you
pick packages from the comps groups.
Neither GNOME Software nor KDE Discover uses these "shopping list"
groups. (The older GNOME tool that preceded Software did, I think;
again, that was years ago now). However, dnfdragora (which is the main
package manager on some smaller desktops, and may still be installed on
KDE alongside Discover by default, I'm not sure) *does* - you can
browse by comps group (and 'category', which are collections of comps
groups intended for this purpose, different from the 'environments'
used by anaconda) in dnfdragora. Maybe some other GUI packaging tools
do as well, I'm not sure of any others to check.
It does not appear to me like anyone besides me does much maintenance
on these groups. For instance, I don't think anyone but me has touched
the network-server group since 2019.
These are the groups I'd identify as "shopping list groups":
cloud-infrastructure
directory-server
dns-server (one 'default' package)
editors
education
ftp-server (one 'mandatory' package)
games (the games spin does not use this group, it has its own list)
graphical-internet
graphics
legacy-network-server
libreoffice-development
network-server
neuron-modelling-simulators
news-server (one 'mandatory' package)
office
server-cfg (one 'default' package)
sound-and-video
text-internet
window-managers
there are a few other groups that don't fit strictly into the
definition but are still of rather dubious usefulness, like the 'web-
server' group which is rather stuck in the 2000s (including php, php-
ldap, php-mysqlnd, squid and webalizer by default - is this how anyone
"deploys a web server" these days?) Being stuck in the 2000s is kind of
a defining feature of these groups - any time you see a vaguely modern
package, it's probably been put there by me, replacing something that
got orphaned. Otherwise most of them seem to have been defined back
then and rarely or never updated since. (Another example: the last time
the 'games' group was updated by anyone but me was 2017, adding one
game; the last update before that seems to have been in 2013).
So, I'm wondering what folks think we should do with these. We could,
of course, just get rid of them. But perhaps they are still of value to
someone? Is anyone still "package shopping" via dnfdragora or some
other tool, using these groups? Does anyone want to step up and
actively 'own' some of them for maintenance? Any other thoughts?
Thanks folks!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1 year, 1 month
Self Introduction: Tomi Lähteenmäki
by Tomi Lähteenmäki
Hi all,
My name is Tomi Lähteenmäki and I have recently got my first package
review request [1] reviewed.
I got my first touch to Linux on vocational school and since then I
have been an user for a bit over decade now. For past two years I have
been running Fedora both at work and personal laptop/desktop.
Professionally I have been working with embedded systems running Linux
(doing stuff ranging from kernel configuration to software development
and DevOps).
My interests are mostly around software development with C/C++ for
embedded systems or desktops running Linux. I'm always happy talk
anything Linux related :)
As I'm new packager I'm still looking for a sponsor. But I'm looking
forward to contribute more, especially around Mobility related things
as I own PinePhone, which inspired my first package review request.
-Tomi
[1] <https://bugzilla.redhat.com/show_bug.cgi?id=2151289>
1 year, 1 month