Self Introduction: John Kacur
by John Kacur
Hello. My name is John Kacur
I'm a real-time developer with Red Hat, who I've been with for over 11 years.
Before that I worked for approximately 8 years with IBM on the compiler team.
I am the upstream co-maintainer of rt-tests that includes cyclictest
for real-time latency testing.
I am also the upstream co-maintainer of rteval that tests the ability
of hardware to run the real-time kernel.
I am also the RH packager of the above packages.
I am also an upstream co-maintainer of tuna, python-schedutils and
python-linux-procutils, and the RH packager of these packages as well.
There are probably a few other things that are relevant, but the most
important ones are listed above.
I have mostly been a lurker when it comes to Fedora development, but
hopefully that will change soon!
John Kacur
3 years, 5 months
EOL and Obsoletes in Modularity
by Martin Curlej
Hi,
EOL and Obsoletes were planned as a feature of Modularity. The feature
should enable to set shorter/longer life cycles on Modules than the OS
release. The initial idea was to set this information in the disgit
metadata of a Module. As time went by the requirements have changed.
From my point of view right now it seems that this information should not
be a part of the module (disgit, repository metadata). It is prone to human
error when we leave this in the hands of a packager. So this would need a
review of Engineering to be reliable.
Next is that a lot of 3rd parties like to handle the EOL and Obsoletes of
packages/modules by other means, which makes this redundant. Also, as the
release cycle of Fedora is so fast, I am not sure this is a necessary
feature at all
I spoke to people in the community and I got mixed information/opinions, so
I want to open a discussion about this feature. So WDYT? Is this necessary
for Fedora? If yes, how should we handle this?
--
Martin Curlej
Software Engineer, Product Owner
Modularity
Red Hat
<https://www.redhat.com>
mcurlej(a)redhat.com
<https://red.ht/sig>
3 years, 5 months
Retiring ntp
by Miroslav Lichvar
I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.
The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.
I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.
In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.
Thoughts?
--
Miroslav Lichvar
3 years, 5 months
Deprecating SCP
by Jakub Jelen
Hi Fedora users!
Over the last years, there were several issues in the SCP protocol,
which lead us into discussions if we can get rid of it in upstream [1].
Most of the voices there said that they use SCP mostly for simple ad-hoc
copy and because sftp utility does not provide simple interface to copy
one or couple of files back and forth and because of people are just
used to write scp rather than sftp.
Some months ago, I wrote a patch [2] for scp to use SFTP internally
(with possibility to change it back using -M scp) and ran it through
some successful testing. The general feedback from upstream was also
quite positive so I would like to hear also opinions from our users.
It still has some limitations (missing -3 support, it will not work if
the server does not run sftp subsystem, ...), but it should be good
enough for most common use cases.
Today, I set up a copr repository with the current openssh from Fedora +
the patch [2] for anyone to test and provide feedback, either here on
the mailing list, or in the github PR according to ones preferences.
I am looking for any kind of feedback from the idea through the
usability, implementation. Is this something you would like to see in
Fedora soon? Do you have something against this? Is your use case missing?
[1]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html
[2] https://github.com/openssh/openssh-portable/pull/194/
[3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/
Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
3 years, 5 months
What happened to quality debuginfo?
by Michael Catanzaro
Hi,
Since upgrading to Fedora 33, I notice gdb no longer prompts me to
install missing debuginfo packages. Full backtraces contain no member
variables or line numbers and are not very useful for debugging
problems. For example:
(gdb) bt full
#0 0x00007ffff7b65a0f in poll () at /lib64/libc.so.6
#1 0x00007ffff7e7c865 in g_socket_condition_timed_wait () at
/lib64/libgio-2.0.so.0
#2 0x00007ffff7e7d2e3 in g_socket_connect () at /lib64/libgio-2.0.so.0
#3 0x00007ffff7e83ad3 in g_socket_client_connect () at
/lib64/libgio-2.0.so.0
#4 0x00007ffff7e8401b in g_socket_client_connect_to_host () at
/lib64/libgio-2.0.so.0
#5 0x000000000040128b in main ()
In F32 and earlier releases, gdb would print a 'dnf debuginfo-install'
command to use to install all necessary debuginfo, and that would at
least usually work. What has changed?
Michael
3 years, 5 months
making download of filelists.xml(.zck) trigger on demand
by clime
Hello!
First of all, I don't really know what I am talking about here but I
noticed the `dnf update` operation downloads among other things
`filelists.xml` (optionally compressed by zchunk, thanks Jonathan
Dieter!!!) and I remember there was a thread on devel mailing quite
some time ago by Zbyszek from which I understood this data is only
needed when filesystem paths are used as package requirements or when
a fs path is specified as direct argument to `dnf install`. Could we
then, please, trigger download of this file only if and when needed
and not sooner? It seems to take more than half of the total download
size e.g. for fedora-32-updates repo so it could improve repodata
download times quite significantly. Again, I don't really know what I
am talking about here but this came to my mind recently so I wanted to
write it down just in case it would be possible :).
Thank you very much
clime
3 years, 5 months