libcdio soname bump in rawhide
by Adrian Reber
I will update libcdio to 2.1.0 next week in rawhide. As always, libcdio
comes with a new SO version.
The following packages have to be rebuilt and I will do the necessary
rebuilds:
cantata
cdw
clementine
gstreamer1-plugins-ugly-free
gvfs
kover
libcddb
libcdio-0:2.0.0-6.fc32.src
libcdio-paranoia
pcsxr
pragha
python-pycdio
qmmp
strawberry
tellico
whipper
xmms2
Adrian
3 years, 11 months
Announcing start of DNF 5 development
by Daniel Mach
Hello everyone,
I'm pleased to announce start of DNF 5 development. We are planning to
deliver a module stream or a COPR repo during Fedora 33 development for
early adopters and tool developers and we're hoping in getting a stable
version into Fedora 34.
More details follow.
We've managed to drop a lot of redundant code across the whole DNF stack
in the past years, but we have reached a point when it's nearly
impossible to consolidate the code any further without breaking the
API/ABI. Especially with PackageKit being dead[1], we can't move with
the old "libhif" API in libdnf, because making any bigger changes to
PackageKit is clearly out of scope.
[1]
https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-w...
That's why we decided to start working on a new version of the DNF
stack: DNF 5. And this is the plan:
Priorities
----------
1. Consistency, documentation and user experience is the top priority.
2. Compatibility on the command line level.
3. Compatibility on the API level.
Maintenance
-----------
The existing DNF 4 stack stays in the current Fedoras and Red Hat
Enterprise Linux 8. We'll keep maintaining it in dnf-4-master branches
on GitHub. PackageKit and rpm-ostree will stay on libdnf from the DNF 4
stack.
The existing Python API in DNF
------------------------------
The Python API in DNF stays. We'll do our best to keep it working. If
there is an incompatible change, we'll communicate and document it properly.
The new API in libdnf
---------------------
All business logic will move from DNF (Python) to libdnf (C++). This is
the only way to ensure that package managers work identically across the
whole distribution. We'll start with C++ API and auto-generated Python
bindings via SWIG. We'll focus on the Python bindings which are required
by DNF and we will do our best to provide bindings for Go, Perl5 and
Ruby as well. C API will be created later when the C++ API is stable. At
that moment rpm-ostree will be ported to the new C API.
hawkey
------
Hawkey Python API is going away and will be replaced with libdnf Python API.
DNF
---
DNF stays as the primary command-line package manager. The overall
functionality remains. We don't anticipate any negative impact of the
API rewrite on the end-users. We have built an extensive test suite
(over 1400 scenarios) that will help us to ensure that. The argument
parser and outputs may slightly change in some cases to provide a more
consistent user-experience. All such cases will be properly documented.
microdnf
--------
Microdnf is becoming important because it's part of many containers
due to its small footprint. We're getting feedback that users would
appreciate something closer to DNF. We'll focus on implementing a subset
of DNF's functionality and improving the user experience. 100% feature
parity with DNF is currently out of scope.
DBus service
------------
DNF team has decided to create a new DBus service replacing PackageKit
to provide an interface to GUI applications. It's probably going to take
a while because we're planning to start from scratch.
Roadmap (tentative)
-------------------
* Mar 2020 - making the bigger API changes, upstream code barely compiles
* May 2020 - COPR repo with first development snapshots
* Jun 2020 - F33 module available for early adopters and tool developers
* Oct 2020 - DNF 5 landing in F34 Rawhide
* Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora
3 years, 11 months
Current plan: Build python3, python3-libs etc. from python39 SRPM on
F33+
by Miro Hrončok
Hello Pythonistas.
(I've CC'ed the devel list for further exposure. But let's discuss this on
python-devel list please to avoid noise.)
We would like ro rename the "python3" component (SRPM) to "python39" to make
maintaining various Python versions in various Fedora versions easier.
The names of binary RPMs would be unchanged; you still do `dnf install python3`.
The change should only affect packagers of Python itself; not users or packagers
of software written in Python.
The only user-visible or general-packager-visible change is a different
component (SRPM) name.
Details follow.
Currently, we build the Python interpreters this way:
- the "main" Python 3 interpreter component is called python3
- it builds a couple of subpackages, like python3-libs or python3-devel
- the "alternate" Python 3 versions components are called python3X (python37,
python39...)
For example, Fedora 31 has:
- python36
- python3 (the "main" Python, which is 3.7.x)
- python38
- python39
(python37 is retired in f31, but present in Fedora versions where python3 != 3.7)
This makes updating the "main" Python fairly complicated. To upgrade from 3.7 to
3.8 in f32, we had to:
1) retire python38
2) upgrade python3 from 3.7 to 3.8 (this makes python3 obsolete python38)
3) re-introduce (unretire) python37
Such an update comes every few years:
- https://fedoraproject.org/wiki/Changes/Python3.7 (f29)
- https://fedoraproject.org/wiki/Changes/Python3.8 (f32)
- https://fedoraproject.org/wiki/Changes/Python3.9 (f33)
What's even more complicated is backporting patches across Fedora releases.
Assume there is an important upgrade/fix for Python 3.7 we wish to apply for all
Fedoras including stable. That currently means we need to apply the fix in:
- master branch of python37
- f32 branch of python37
- f31 branch of python3 (!)
- f30 branch of python3
While cherry-picking or merging patches between branches of one git repo is
quite straight-forward (the only major obstacle is the release and %chaneglog),
doing this across multiple git repos (and spec filenames) is very tedious and
error-prone (albeit possible).
With the 3.9 update approaching in Fedora 33, we would end up with the following
scheme when updating Python 3.8:
- master branch of python38
- f32 branch of python3 (!)
- f31 branch of python38 (!)
- f30 branch of python38
Apart from technological obstacles, this causes nontrivial cognitive overhead.
So far, I've been carrying that overhead myself, but others (who don't work on
the Fedora Python packages daily) always need my assistance with this, because
it's overly complicated and hard to understand without drawing pictures.
For this to be easier for us, while keeping the change minimal for others, we
have decided to retire the python3 component and only continue maintaining the
interpreters in "python3X" components. The names of "binary" packages remain
unchanged.
Before:
SRPM: python3
builds:
- python3
- python-unversioned-command
- python3-{libs,devel,tkinter,idle,test,debug}
- python3-debug{info,source}
After:
SRPM: python39
builds:
- python3 (unchanged)
- python-unversioned-command (unchanged)
- python3-{libs,devel,tkinter,idle,test,debug} (unchanged)
- python39-debug{info,source} (usually not installed by name)
To avoid further confusion, the "python3-libs" etc. packages will provide
"python39-libs" as well.
We plan to do this together with the Python 3.9 upgrade. I'll update the change
page after some feedback happens here.
The initial implementation is in:
https://src.fedoraproject.org/rpms/python39/pull-request/32
Here are other approaches we have considered:
Why not rename the packages to python39-libs etc. (and only provide python3-libs)?
This would be inconsistent with the way other Python 3 packages are called
(e.g. python39-setuptools). We consider that confusing.
The goal here is to make our work easier while introducing minimal changes to
our users and contributors.
Why not rename all the Python packages to python39-setuptools etc.?
This would create a mess upon distro boundary Python upgrades.
All python39-foo packages would need to obsolete all python38-foo packages.
Even if we add the obsoletes metadata to all the packages, it would prevent
users from having the two parallel stacks of Python installed on the same OS.
(We don't have such stacks in Fedora, but we intend to continue to make this
possible in third party repos, downstreams of Fedora or other systems built on
top or Fedora).
See also the "minimal changes" point above.
Why not package the alternate stacks as modular streams and keep everything
called just python3- (or even python-)?
1) The Python stacks are naturally parallel-installable. This would not be
possible if they were different streams of one module.
2) Vital system tools (dnf, anaconda, packaging tools) use Python, so the
"main" Python can't be in a module. (We could solve this by a separate
"platform Python" just for these system tools, but that makes everything more
complex and harder to work with -- the opposite of what this change is about.)
See also the "minimal changes" point above.
Why are you breaking the world once again?
Sorry if this breaks anything for you. Could you be as specific as possible?
We anticipate no changes in Fedora packages (other than python3/python39).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 11 months
Heads-up: RPM 4.16 alpha coming to rawhide
by Panu Matilainen
It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.
There aren't any big incompatibility bumps here, but to pave way for the
fancy new expression stuff, some dusty corners needed, well, dusting.
One of the discoveries was that rpm has accidentally long allowed
unquoted text to be used as a string in expressions. That is no longer
supported, you need to quote any strings in expressions.
Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16. You'll get an error message pointing to the right
direction, eg:
error: bare words are no longer supported, please use "...": python3 ==
python3
error: ^
error: airnef.spec:83: bad %if condition: python3 == python3
This is caused by the following line in that spec:
%if %python == python3
Just add double quotes to both sides and it'll work. This is backwards
compatible so you're not breaking anything by doing so, like mentioned
above this only ever worked by accident to begin with.
Other than that, there are a couple of things that might be of
particular interest to Fedora packagers: new expression features [1] (in
spec %if and macros) including but not limited to ternary operator (eg
%[1==0?"yes":"no"]) and parametric macro generators [2] for lightning
fast dependency generation. Oh, and dependency generators can now
optionally use MIME type instead of "file" magic string for file
classification.
Last but certainly not least, please do test the database stuff! We will
not be changing the default until several weeks from now (for
stabilization and coordination with infrastructure/rel-eng efforts), but
you can and should test locally:
# echo '%_db_backend sqlite' > /etc/rpm/macros.db
# rpmdb --rebuilddb
After that you'll be using sqlite rpmdb, and you shouldn't really notice
anything at all. Except that it's typically a little faster, and should
survive abuse in ways that BDB never did.
And as usual, please report anything odd.
[1] https://rpm.org/wiki/Releases/4.16.0 has some examples, more to follow
[2]
https://rpm.org/user_doc/dependency_generators#parametric-macro-generator...
- Panu -
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
3 years, 11 months
Orphaning owncloud and nextcloud
by James Hogarth
Hi all,
It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...
These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.
I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.
I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"
James
3 years, 11 months
rpminspect Jenkins is effectively down
by Tim Flink
I figured I would start a new thread instead of continuing on with the
old one.
The Jenkins instance running rpminspect has crapped itself for the
second time in less than a week and it's currently not processing the
rpminspect runs it should be.
There are also reports of missing rpminspect runs which likely stem
from the Jenkins issues.
I'm working on it and will send updates as things are fixed and skipped
runs are re-scheduled.
Tim
3 years, 12 months
Nvidia binary drivers fail to install on Fedora 32
by Ty Young
Either no one is testing Fedora 32 on Nvidia hardware or Fedora has
entered an entirely new level of salt. Attempting to install from
RPMFusion results in:
Mar 28 22:32:44 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[10990]: Building
/usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel
5.6.0-0.rc7.git1.1.fc33.x86_64
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: { echo
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-uvm/uvm_utils.o
/tmp/akmodsbuild.6qACAcgU/BUILD/nv>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ./tools/objtool/objtool orc
generate --module --no-fp --retpoline --uaccess
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: ld -m elf_x86_64 -z
max-page-size=0x200000 -r -o
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm.o
>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: { echo
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm/nvidia-drm.o
/tmp/akmodsbuild.6qACAcgU/BUILD/n>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make -f ./scripts/Makefile.modpost
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: sed 's/ko$/o/'
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/modules.order
| scripts/mod/modpost -i ./Module.>
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: FATAL: modpost: GPL-incompatible
module nvidia-drm.ko uses GPL-only symbol 'mutex_lock_nested'
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[2]: ***
[scripts/Makefile.modpost:93: __modpost] Error 1
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: *** [Makefile:1596:
modules] Error 2
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: Leaving directory
'/usr/src/kernels/5.6.0-0.rc7.git1.1.fc33.x86_64'
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: make: *** [Makefile:81: modules]
Error 2
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: error: Bad exit status from
/var/tmp/rpm-tmp.BkO4oE (%build)
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: RPM build errors:
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: cannot open Packages database
in /var/lib/rpm
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: user mockbuild does not exist
- using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: group mock does not exist -
using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: user mockbuild does not exist
- using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: group mock does not exist -
using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: user mockbuild does not exist
- using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: group mock does not exist -
using root
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: cannot open Packages database
in /var/lib/rpm
Mar 28 22:33:45 localhost.localdomain
rpm-ostree(akmod-nvidia.post)[16484]: Bad exit status from
/var/tmp/rpm-tmp.BkO4oE (%build)
No issues with Arch Linux. The driver is being blocked from being
installed purely for ideological reasons.
3 years, 12 months
Fedora 33 System-Wide Change proposal: Mark libdb as deprecated
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Libdb_deprecated
== Summary ==
This change should inform maintainers and developers about effort to
remove libdb in future.
== Owner ==
* Name: [[User:fjanus|Filip Januš]]
* Email: fjanus(a)redhat.com
== Detailed Description ==
We would like to remove libdb from Fedora in future, because
BerkeleyDB 6.x has a more restrictive license than the previous
versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
Nowadays Fedora uses the old version (5.3.28) and we can't update to
newer. Due to many projects have libdb dependency, we propose few
steps to complete removal. First step would mark libdb as deprecated
package in Fedora 33. Next steps in Fedora 35 would provide converting
tool for existing databases and mark libdb as orphaned.
== Benefit to Fedora ==
We would like to have most recent releases of components in Fedora,
which are supported by upstreams. But due to licence of BerkeleyDB we
need to hold old BerkeleyDB version in Fedora.
== Scope ==
* Proposal owners: Not needed for this change - only deprecation
* Other developers: Developers should prepare own projects(scripts,
programs, packages, ...) for the next change and for the complete
libdb removal.
* Policies and guidelines: Not needed for this change - only deprecation
* Trademark approval: Not needed for this change - only deprecation
== Upgrade/compatibility impact ==
This change hasn't direct impact onto actual dependencies. Purpose of
this change is inform and prepare people to future change which will
affect many components.
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Here] is short discussion from Fedora-devel list.
== User Experience ==
There is no change for users. Package is marked only as deprecated
package and behaves as before.
== Dependencies ==
*Libdb has many dependencies:
*389-ds-base
*apr-util-bdb
*bind-sdb
*bogofilter
*cld
*clisp
*cyrus-sasl-lib
*dsniff
*evolution-data-server
*exim
*heimdal
*iproute
*ipv6calc
*isync
*jabberd
*jigdo
*jigdo-gui
*kdesvn
*libetpan
*libopendkim
*libserf
*lizardfs-master
*mesos
*mod_dav_svn
*mod_perl
*mod_qos
*mod_security
*netatalk
*nmh
*nss_updatedb
*nvi
*opendkim
*openldap-servers
*opensips-db_berkeley
*opensmtpd
*pam
*pam_abl
*pam_ccreds
*perdition
*perl-BDB
*perl-BerkeleyDB
*perl-DB_File
*perl-eperl
*php-dba
*pl
*postfix
*python3-bsddb3
*rapidsvn
*redland
*reprepro
*rpm
*rsvndump
*sendmail
*sks
*spamprobe
*squid
*squidGuard
*subversion
*tqsllib
*trustedqsl
*webalizer
*xemacs
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
There is no upstream documentation, but
[[User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora|here]] is a list
of dependencies with some useful comments and
[[User:Pkubat/BerkeleyDB_alternatives|here]] some possible
alternatives.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 12 months