After upgrade of one of my servers to F33, I noticed that I can not ssh to
one of my other servers running Debian 9 system (relatively freshly EOLed,
I need to do something about it). On F33 I always need to:
$ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host
The changes in Fedora packages led me to:
Which led me to:
I'm curious about the effects of the change. It claims that RSA 2048 >= should
stay accepted by DEFAULT, and from what I can tell the host server key seems to
be RSA 2048 (at least that's what is generated by default on Debian 9):
$ ssh-keygen -l -f ssh_host_rsa_key.pub
2048 SHA256:<...> root@debian-9-host (RSA)
Can anyone translate to me if this is really expected or a bug? Effect is that
Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure about
the supported Debian 10, and the key quality there).
I would like to present a Kubernetes Development SIG.
I initially thought of an "operator SIG" but I think a wider SIG about
programming components and services with Kubernetes APIs and internal
components made more sense (inspired by the "Programming Kubernetes" book).
I am using some of the fields/titles described in this document  as the
SIG: Kubernetes Development
A SIG for people interested in using, developing, extending kubernetes for
Fedora components and services.
Name: Leonardo Rossetti (lrossett)
Benefit to Fedora
Development Experience and Learning
A place to exchange and discuss kubernetes development design and patterns.
Extending kubernetes is not that straightforward so this SIG would be a
good place to learn more about it.
Kubernetes can be extended in the following areas:
* Kubectl Plugins
* Custom API Servers
* Custom Controllers / Operators
The Operator SDK  is the shining new framework when developing custom
kubernetes controllers nas has become a popular tool for packaging and
deploying applications in kubernetes.
Some Fedora services and components could leverage the usage of an operator
(as we are doing with MBBOX ) but other services could be deployed via
operators as well and even the mbbox operator could be split into smaller
The SIG could also be a place for sysadmins and ops engineers to discuss
the challenges, practices and tooling of monitoring, deploying and running
operators, api servers and other related kubernetes components in
 - https://fedoraproject.org/wiki/Changes/EmptyTemplate
 - https://github.com/fedora-infra/mbbox
 - https://github.com/operator-framework/operator-sdk
Senior Software Engineer,
Red Hat <https://www.redhat.com>
Hi. There is an ongoing problem with conflicting build-ids in chromium
and chromium-freeworld :
> Error: Transaction test error:
> file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
> file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64
There is no clear idea why it happens, but my assumption is that due to
the fact of building with the same source code (with similar patches),
some generated shared libraries are the same which generates conflict(s).
The quick look at the algorithm for build-id generation  doesn't
answer my question what exactly is taken into account for their
generation and more precisely is there is way to add some "fuzz" (having
different buildroots doesn't help) to distinguish those libraries.
To wrap up:
1. Is there a better way to deal with the aforementioned build-id
conflicts than disable their generation on one side (with "%global
2. Maybe my assumption about the same generated shared libraries is
wrong and there is something else what can be done to fix the root problem?
 - https://bugzilla.redhat.com/show_bug.cgi?id=1869037
 - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743
 - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758
P.S. There are cases where it would be best to have those two packages
installed simultaneously .
https://blog.solidsoft.pl/ - Working code is not enough
It's been a while (6 months?) since I ran a python program that uses a
100% cpu core for hours. The last time I ran it, the task would migrate
from core to core to core, every second or so. I could see it doing so
in the various tops.
Now, it runs on only one core, and doesn't move.
This is more efficient from a computing perspective because there
aren't as many task switches, but it means that the core that is
running gets very hot. Since the rest of the cores are idle, I would
like to switch back to the previous behavior for this reason. Can
someone tell me how?
PS I'm copying devel in case this isn't a kernel issue, and also
because my posts to the kernel list just seem to disappear into the
As many of you know, Fedora has an EOL policy that roughly tl;drs to:
"Fedora N goes to End of Life 4 weeks after Fedora N+2 Final Release (GA)."
The document also says:
> Branches for new packages in the SCM are not allowed for distribution X after
> the Fedora X+2 release and new builds are no longer allowed.
I've recently discovered that for 10+ years, this was interpreted as:
1. at release of Fedora N+2, new dist-git branches for N are no longer allowed
2. 4 weeks later, Fedora N is EOL
When I was told this, I found it very surprising. Mostly because we usually only
ever announce the actual EOL deadline and I've never seen an announcement that
says: "From now on, no new packages for Fedora N are possible."
But also because it doesn't really make sense to me. I can imagine a case when a
bug in Fedora N can be fixed by adding a new package (for example when we
accidentally introduce a new dependency) and I don't understand why this should
not be possible between Fedora N+2 release and Fedora N EOL. Understandably many
packagers might decide to WONTFIX at that point ("It's going EOL in couple weeks
anyway"), but if they choose to fix, we should allow them to do so.
Similarly, before Fedora N is EOL, it is considered supported, and a need to
introduce a new package to a supported Fedora version IMHO is valid, regardless
of the approaching EOL.
So, my question is: Should we fix the document to describe the long standing
practice more understandably, or should we change the practice to allow new
dist-git branches until the actual EOL?
The functionality offered by the vtun package has been completely
subsumed by openssh, since at least with version 8.0. I've switched
to using openssh, and no longer have the need and resources to take
care of vtun.
Free to a good home, or ready for retirement.