OpenSSH 8.7p1 in rawhide
by Dmitry Belyavskiy
Dear colleagues,
I recently added OpenSSH 8.7p1 to rawhide.
This version includes implementation of the SFTP protocol as the main
transfer protocol for the scp utility. In upstream, the SCP protocol is
used by default in the scp utility. The upcoming versions 8.9p1+ (version
8.8p1 is mostly a security release) are expected to use SFTP protocol by
default. This behavior (SFTP as a default transfer protocol for scp
utility) is backported to rawhide.
The same approach is planned for RHEL 9 GA,
Please let me know if you have any questions/problems.
Many thanks in advance!
--
Dmitry Belyavskiy
2 years, 5 months
I think we should stop building i686 packages we're not shipping
by Matthew Miller
This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
build stuff like libreoffice for i686, but then (mostly) don't ship it.
This seems like a waste of resources and time.
I know it's somewhat complicated (for example, there's actually a library
package in libreoffice, libreofficekit, so that gets plucked in to
multilib), and there's quite a lot to work out, but ... does this seem like
a good intended direction?
One immediate way to do this is to start adding `ExcludeArch: i686` to
"leaf" packages (I mean: to allow / encourage people to do that). But I
don't want to add _more_ cruft to the standard minimal spec file, so this
seems like the wrong direction. And I still think we want to keep multilib
for compatibility (hello, old games!). Could we do something clever in koji
instead?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 5 months
Fedora 💔 Java: The Death of Two SIGs
by Fabio Valentini
Good evening everybody,
Not sure why it's me who's writing this message, but somebody needs to do it.
Community maintenance of Java packages in Fedora is, for all intents
and purposes, dead. Mikolaj keeps a bare minimum of packages working
for the maven toolchain, but that's it. Fedora 35 will ship without
packages for the Eclipse IDE, and none of the Java applications I know
of are still in working order. While I had hoped that setting up a
"new" SIG and gathering members to shore up community maintenance of
the "extended core" Java stack, this effort fizzled out after mere
weeks.
"He's dead, Jim."
Now to the reason why I feel the need to beat a dead horse: I wonder
if the @java-maint-sig group should actually continue to exist (or
rather, be maintainer or bugzilla assignee for packages, because I
don't even know if FAS groups can be deleted). It seems that none of
the current members (I am no longer one of them) are active. Bugs,
including security issues with assigned CVE numbers, are collecting
dust. Packages get orphaned and retired one by one because they fail
to build or install.
At this point, I'm still the only person with the password for the
SIG's bugzilla account and the only administrator of the private
mailing list - just because I wouldn't even know who to hand those
things over to (fedora-infra?). There's nobody left, nobody is reading
the mailing lists. Only tumbleweeds are here.
Should the @java-maint-sig group be removed from any packages it is
still associated with? Should it be dissolved, and members be removed?
Should the remaining ruins that used to be packages be orphaned?
Retired? Buried? Forgotten?
I don't know.
Fabio
2 years, 5 months
co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd
Hi,
I added python-mailmerge to Fedora Linux as it was super important to
large parts of my work as FCAIC. In my current $dayjob I use it less
frequently, though I know of colleagues who still depend on it.
I'd love to find a maintainer to help me with it. There is a new
release pending, which I suspect will just be "build the rpm with new
code; test it; ship it" level effort. I am happy to hand the whole
thing off to someone or to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 5 months
Modularity: New modulemd-packager format for building modules
by Petr Pisar
Good news, module maintainers.
I'm relieved to announce an availability of the new module packaging format,
modulemd-packager, version 3.
Skip to "WHAT IS CHANGING" section to see the main message.
HISTORY
=======
Up to now, you wrote a YAML document in modulemd-v2 format
<https://raw.githubusercontent.com/fedora-modularity/libmodulemd/main/yaml...>:
document: modulemd
version: 2
data:
name: perl-DBI
stream: '1.643'
license:
module:
- MIT
dependencies:
- buildrequires:
platform: []
perl: []
requires:
platform: []
perl: []
buildopts:
rpms:
macros: |
%this_is_my_module 1
components:
rpms:
perl-DBI:
rationale: API
ref: f34
You built it and an output were multiple module builds, one for each
combination of a Fedora release and a perl stream. E.g. this matrix:
buildrequires:
platform: [f35, f34]
perl: [5.30, 5.32]
requires:
platform: [f35, f34]
perl: [5.30, 5.32]
was expaned into 4 unique builds by MBS, Module Build Service. Observe the
last, "random" value, context:
perl-DBI:1.643:3420210211145152:7f057cb7
perl-DBI:1.643:3420210211145152:a450835c
perl-DBI:1.643:3520210211145152:2c956793
perl-DBI:1.643:3520210211145152:e12b6f3a
These output modules used the same modulemd-v2 format. It was deemed that
having the same input and output format is a benefit.
WHY
===
But it turned out that DNF had difficulties to upgrade from an older version of
a module to a newer one. The problem was that DNF could not identify which
build upgrades which one. E.g. having a Fedora 35 system with these builds in
a repository:
1 perl-DBI:1.643:3520210211145152:2c956793 * this one is installed
2 perl-DBI:1.643:3520210211145152:e12b6f3a
3 perl-DBI:1.643:3520210212105947:ab395794
4 perl-DBI:1.643:3520210212105947:c39b3af3
DNF did not know whether to upgrade to the 3rd build or the 4th one. Both of
them have the highest version. But which one to use? Context value is no clue
here because it differs from the older builds. This happens when a module is
changing its build-requires. (Actually first we observed this on RHEL where
the platform changes with each minor RHEL release.) Run-time dependencies are
also of no help because they could also change. (We also observed this on
RHEL. Original design used run-time dependencies for the selection.)
Therefore DNF maintainers declared that this problem is undecidable and
requested a change in Modularity.
Modularity team together with DNF maintainers identified that a culprit is the
random nature of the context and decided to sacrifice a stream expansion for
making the context static and predictable. It was designed that the context
value will be fully in hands of the module maintainers who will be able freely
add, remove, and maintain a module upgrade path by the means of the context:
Context Context Context
A B
↓ ↓
Version 3520210211145152 3520210211145152
requires: perl:5.30 requires: perl:5.32 C (perl:5.34 added)
↓ ↓ ↓
Version 3520210212105947 3520210212105947 3520210212105947
(a new dep. requires: perl:5.30 requires: perl:5.32 requires: perl:5.34
added) requires: nginx:1.20 requires: nginx:1.20 requires: nginx:1.20
(perl:5.30 ended) ↓ ↓
Version 3520210930210943 3520210930210943
(nginx not requires: perl:5.32 requires: perl:5.34
req. anymore) ↓ ↓
WHAT IS CHANGING
================
Since there was no place for the contexts in the old module format, a new,
input-only format "modulemd-packager", version 3, was designed and implemented
in MBS and other tools. At the opportunity of the format change, some other
pet peeves of the old format were solved.
Changes in the format include:
New document type and version:
document: modulemd-packager
version: 3
A "module" middle-field removed from the "license" section:
license:
- MIT
A "dependencies" section replaced with a "configurations" section:
configurations:
- context: A
platform: f34
buildrequires:
perl: ['5.30']
requires:
perl: ['5.30']
- context: B
platform: f34
buildrequires:
perl: ['5.32']
requires:
perl: ['5.32']
- context: C
platform: f35
buildrequires:
perl: ['5.30']
requires:
perl: ['5.30']
- context: D
platform: f35
buildrequires:
perl: ['5.32']
requires:
perl: ['5.32']
The context value is a string and its alphabet and length is limited. All the
contexts must be unique among a module stream. The plaform field is a scalar
now. However, the stream values of the "buildrequires" and "requires"
dependencies are a list. Although the specification requires a single value.
A "buildopts" section was moved from /data to /data/configurations/*/context
section. Therefore it's specific to a context and should be repeated if needed
any time:
configurations:
- context: A
platform: f34
buildrequires:
perl: ['5.30']
requires:
perl: ['5.30']
buildopts:
rpms:
macros: |
%this_is_my_module A
- context: B
platform: f34
buildrequires:
perl: ['5.32']
requires:
perl: ['5.32']
buildopts:
rpms:
macros: |
%this_is_my_module B
And that's all.
The complete specification of modulemd-packager-v3 format is at
<https://raw.githubusercontent.com/fedora-modularity/libmodulemd/main/yaml...>.
WHEN
====
Modularity team started to work on the new format a year a ago, the
implementation was deployed to Fedora infrastructure few months ago and
I've been waiting with the announcement until fixing the most serious bugs.
That, I hope, happened last week.
In other words, you can start using the new format right now.
DO I HAVE TO MIGRATE MY MODULES?
================================
No, you don't have to. But Modularity people would like to see moving all
Fedora content there.
The old modulemd-v2 format is still supported by MBS.
DNF handles outputs of both of them (the output format is distinguished with
"static_context: true" field), but it behaves differently. With the old
format, DNF can produce weird warnings or errors. Especially when your module
is required by another module.
Will the old format be supporterd forever? I don't know.
Does have the new format some drawbacks? Yes, it has: It's longer than the
previous one. You need to update it for each new Fedora release. You cannot
run-require an unspecified (= any) module stream (perl:[]). (Though a DNF
maintainer says it should not be a problem.)
HOW TO MIGRATE
==============
Read the "WHAT IS CHANGING" section of this e-mail message. Follow the
specification if in doubts.
When migrating your modules, you will have to come up with the context value.
To preserve a compatibility with the old builds and to preserve the upgrade
path, I strongly recommend reusing the old context values. Use Koji
<https://admin.fedoraproject.org/pkgdb/package/MODULE/>, or MBS
<https://mbs.fedoraproject.org/module-build-service/2/module-builds/?name=...>,
or "dnf module info MODULE:STREAM" command to locate the lastest version of
the module, and pick a context matching the desired dependencies as depicted here:
# dnf -q module info perl-DBI:1.643
Name : perl-DBI
Stream : 1.643
Version : 3520210722203952
Context : e12b6f3a ------+
[…] |
Requires : perl:[5.32] ----+ |
platform:[f35] --+ | |
| | |
The new YAML file: | | |
| | |
data: | | |
configurations: | | |
- context: 'e12b6f3a' <----|-|-+
platform: f35 <----+ |
buildrequires: |
perl: ['5.32'] |
requires: |
perl: ['5.32'] <------+
buildopts:
You can validate your YAML files with
"modulemd-validator --type modulemd-packager-v3 FILE" command.
For a real example look at any perl* module. I've already migrated them. For
instance this commit
<https://src.fedoraproject.org/modules/perl-DBI/c/2200d21f0fab5295226d915c...>.
FEEDBACK
========
General help on modularity <devel(a)lists.fedoraproject.org>.
Modularity design issues <https://pagure.io/modularity/issues>.
Fedora MBS instance issues <https://pagure.io/fedora-infrastructure/issues>.
MBS implementation bugs <https://pagure.io/fm-orchestrator/issues>.
DISCLAIMER
==========
The examples in this document are simplified and sometimes redacted to
better illustrate the discussed topic.
I joined Modularity team way after designing this change. Therefore I cannot
guarantee that all data provided here are accurate.
I'd like to thank all the people who participated in this change and who
helped me to understand it. Especially Martin Curlej, Jaroslav Mracek,
Daniel Mach, and Mike McLean.
-- Petr
2 years, 5 months
F35 Change: Switch to WirePlumber as the PipeWire session manage
(late Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WirePlumber
== Summary ==
PipeWire currently uses a simple example session manager. This
proposal is to move to the more powerful WirePlumber session manager.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
PipeWire requires a session manager that at least needs to implements
the following features:
* create and configure detected devices in the system. This includes
audio cards, video and bluetooth devices.
* configure applications and route audio/video to/from them to the
devices and filters.
* keep track of prefered devices and volumes.
* move audio/video streams when devices appear and disappear.
PipeWire uses a simple example session manager with limited features
and configuration options. The proposal is to
move to WirePlumber.
WirePlumber is built on GNOME (GObject) technologies and has bindings
for most languages using GObject introspection.
WirePlumber allows one to implement many of the rules for setup and
configuration using small LUA scripts, which are
easier to maintain and customize. These are some of the functions that
are scriptable in LUA:
* setup and configuration of the devices and streams. This includes
deciding if devices and streams need to operate in 5.1 or stereo mode,
depending on the available devices.
* routing of the streams based on metadata of the streams (Roles) and
overall state of the system.
* volume/mute restore of devices and streams
== Benefit to Fedora ==
PipeWire currently uses a simple example session manager with mostly
hardcoded logic and rules. This proposal wants to replace the session
manager with a more advanced session manager, called WirePlumber.
WirePlumber brings to following improvements
* Drop-in replacement session manager for PipeWire, implements the
exact same features as the example session manager
* built with GObject, which provides a richer development experience
and adds bindings for most languages
* extensible with loadable modules
* scriptable policy using small lua scripts
* better integration with desktop settings
The main benefits will be that this session manager would allow for
more customization of the policy
and rules. Initially we aim for feature parity with the current
solution and work on more features
in the next releases.
== Scope ==
* Proposal owners:
This is a rather isolated changed. Instead of starting the
pipewire-media-session executable we would need to package
and start WirePlumber instead.
WirePlumber has been kept up to data with the features in the example
session manager and would need testing.
* Other developers: None. This is an isolated PipeWire change.
* Release engineering: A new systemd service will need to be activated
in the default install.
* 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 ==
Should not cause any change.
== How To Test ==
Experience should be the same as before. Retest all audio testcases.
== User Experience ==
Should not cause any visible change.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?): If the
feature can not be completed we continue using the existing
pipewire-media-session.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd
Hi,
While I still actively use gocryptfs, I am busy enough with my $dayjob
that I know I am not able to put enough time into maintaining it.
Right now this has been OK as they have stopped new releases while
they get v2.0 out the door. However, that will ship soon.
I'd love to get some help maintaining the main rpm and the 6
dependencies I have for it. I am happy to hand it all over to you or
to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 5 months
Orphaning the cura-lulzbot package set
by Tom Callaway
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.
Accordingly, I've orphaned the following packages:
* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot
~spot
P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
2 years, 5 months