[Bug 2165302] New: F38FailsToInstall: perl-Clownfish-CFC
https://bugzilla.redhat.com/show_bug.cgi?id=2165302 Bug ID: 2165302 Summary: F38FailsToInstall: perl-Clownfish-CFC Product: Fedora Version: rawhide Status: NEW Component: perl-Clownfish-CFC Assignee: ppi...@redhat.com Reporter: fti-b...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Blocks: 2117177 (F38FailsToInstall,RAWHIDEFailsToInstall) Target Milestone: --- Classification: Fedora Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ Your package (perl-Clownfish-CFC) Fails To Install in Fedora 38: can't install perl-Clownfish-CFC: - nothing provides libcmark.so.0.29.0()(64bit) needed by perl-Clownfish-CFC-0.6.3-19.fc38.x86_64 If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-38-x86_64 --config-opts mirrored=False install perl-Clownfish-CFC P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks! Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2117177 [Bug 2117177] Fedora 38 Fails To install Tracker -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2165302 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sun, Jan 29, 2023 at 12:23:49AM +0100, Fabio Valentini wrote:
> On Sun, Jan 29, 2023 at 12:03 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote:
> > > On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > >
> > > > This is indeed a shortcoming in the rpm symbol dependency generation
> > > > scheme.
> > >
> > > Is it though? I'm probibly reading this too quickly and missing
> > > something, but isn't the underlying problem here that nghttp2 changed
> > > abi and didn't change soname? If they had, soup would have kept the
> > > older version around, or asked to upgrade both libsoup and libnghttp2?
> >
> > No. libnghttp2 added one symbol, and (correctly, i.e. following the usual
> > practice), it changed the suffix from .so.14.23.0 to .so.14.24.1. (The last
> > number is bumped when the implementation of existing symbols changes, the
> > middle
> > one when when new symbols are added, and the first one when an incompatible
> > change happens, i.e. symbols are removed or changed incompatibly. Lower
> > numbers
> > are reset to zero whenever a higher one changes.) The SOVERSION
> > corresponds to
> > the major number and does not change in the case under discussion.
> >
> > As Gordon wrote, our rpm dependency generation logic does not care about the
> > minor or patch numbers.
>
> If I understand things correctly, this is not entirely true. RPM
> generates a dependency for the soname / soversion, and some projects
> include not only X, but all of X.Y.Z in that, which RPM will happily
> generate Provides / Requires for (whether that's a nice thing to do
> for an upstream project or whether that's a bug in their build systems
> I leave as an exercise to the reader).
That is all true. But it's probably not a good idea to for the upstream
projects to do that, because the SONAME is used to load the library at runtime.
(*)
If the SONAME changes, all programs and libraries linking to that library
need to be recompiled/relinked. This would essentially defeat the shared library
system.
(*) Or more precisely speaking, when a library is installed in the file system,
a symlink is created to the real name (e.g. libcurl.so.4.8.0) from the embedded
SONAME. Subsequently, a program that wants a given SONAME is run, the dynamic
linker looks for the SONAME in the file system and finds the symlink
(libcurl.so.4 in this case) and uses that. IIUC, the SONAME isn't actually
checked again. So SONAME is _not_ used at runtime directly, but it's still used
to set things up so that the library is found.
Earlier, when a program is being compiled, a similar indirection happens. The
compiler/linker is given a library name (e.g. -lcurl) and uses that to locate
the library as %{_libdir}/libcurl.so, reads the SONAME (libcurl.so.4) from that
file and saves the SONAME in the linked program.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] python3-qt5-webkit for EPEL 8
The python-qt5 package in RHEL 8 does not ship the webkit package. I'm
assuming that this is unlikely to be changed since qt5-qtwebkit isn't in
RHEL but is in EPEL.
I think I'm close to producing a python-qt5-epel package here [1] that
produces python3-qt5-webkit and would love to hear from people more
familiar with the package if this seems like it's reasonable/workable.
I think we're depending on the fact that the RHEL python3-qt5-devel
package does ship the WebKit sip files and that these would match up
with what this package ships.
It also just seems like webengine isn't in there, or I'm missing what's
needed to build it. I also don't need it for my purposes.
[1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/%global with_python3 1
%global python3_dbus_dir %(%{__python3} -c "import dbus.mainloop; print(dbus.mainloop.__path__[0])" 2>/dev/null || echo "%{python3_sitearch}/dbus/mainloop")
# enable/disable individual modules
# drop power64, it's not supported yet (than)
%ifarch %{?qt5_qtwebengine_arches}%{?!qt5_qtwebengine_arches:%{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el}
%global webengine 0
%endif
%global webkit 1
%global py3_sipdir %{_datadir}/sip/PyQt5
%global sip_ver 4.19.23
# see also https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQQ66XJSIT2FGTK2YQY7AXMEH5IXMPUX/
%undefine _strict_symbol_defs_build
Summary: PyQt5 is Python bindings for Qt5
Name:python-qt5-epel
Version: 5.15.0
Release: 3.0.1%{?dist}
License: GPLv3
Url: http://www.riverbankcomputing.com/software/pyqt/
Source0: https://files.pythonhosted.org/packages/8c/90/82c62bbbadcca98e8c6fa84f1a638de1ed1c89e85368241e9cc43fcbc320/PyQt5-%{version}.tar.gz
## upstreamable patches
Patch0: python-qt5_sipdir.patch
# support newer Qt5 releases
Patch1: PyQt5-Timeline.patch
#BuildRequires: pkgconfig(dbus-1)
BuildRequires: python%{python3_pkgversion}
BuildRequires: python%{python3_pkgversion}-sip-devel >= %{sip_ver}
%description
%{summary}.
%global __provides_exclude_from ^(%{_qt5_plugindir}/.*\\.so)$
%if 0%{?webengine}
%package -n python%{python3_pkgversion}-qt5-webengine
Summary: Python3 bindings for Qt5 WebEngine
BuildRequires: pkgconfig(Qt5WebEngine)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webengine}
%description -n python%{python3_pkgversion}-qt5-webengine
%{summary}.
%endif
%package -n python%{python3_pkgversion}-qt5-webkit
Summary: Python3 bindings for Qt5 Webkit
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webkit}
%description -n python%{python3_pkgversion}-qt5-webkit
%{summary}.
%prep
%setup -q -n PyQt5-%{version}
%patch0 -p1
%patch1 -p1
%build
PATH=%{_qt5_bindir}:$PATH ; export PATH
mkdir %{_target_platform}-python3
cp -a * %{_target_platform}-python3/ ||:
pushd %{_target_platform}-python3
%{__python3} ./configure.py \
--assume-shared \
--confirm-license \
--qmake=%{_qt5_qmake} \
%{?py3_sip:--sip=%{_bindir}/python3-sip} \
%{?py3_sipdir:--sipdir=%{py3_sipdir}} \
--enable QtWebKit \
--enable QtWebKitWidgets \
--verbose \
QMAKE_CFLAGS_RELEASE="%{optflags}" \
QMAKE_CXXFLAGS_RELEASE="%{optflags} `pkg-config --cflags dbus-python`" \
QMAKE_LFLAGS_RELEASE="%{?__global_ldflags}"
# --dbus=%{_includedir}/dbus-1.0/ \
%make_build
popd
%install
%make_install INSTALL_ROOT=%{buildroot} -C %{_target_platform}-python3
rm -r %{buildroot}%{_datadir} \
%{buildroot}%{_bindir} \
%{buildroot}%{python3_sitearch}/PyQt5*info \
%{buildroot}%{python3_sitearch}/PyQt5/__init__.py \
%{buildroot}%{python3_sitearch}/PyQt5/py* \
%{buildroot}%{python3_sitearch}/PyQt5/Qt.so \
%{buildroot}%{python3_sitearch}/PyQt5/uic
%if 0%{?webengine}
%files -n python%{python3_pkgversion}-qt5-webengine
%{python3_sitearch}/PyQt5/QtWebEngine.*
%{python3_sitearch}/PyQt5/QtWebEngineCore.*
%{python3_sitearch}/PyQt5/QtWebEngineWidgets.*
%endif
%files -n python%{python3_pkgversion}-qt5-webkit
%{python3_sitearch}/PyQt5/QtWebKit.*
%{python3_sitearch}/PyQt5/QtWebKitWidgets.*
%changelog
smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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:
Re: systemd-resolved package overwrite /etc/resolv.conf again
Adam Williamson a écrit : > On Sat, 2023-01-21 at 10:06 -0600, Michael Catanzaro wrote: > > This is only supposed to happen if (a) upgrading from systemd < > > 246.1-1, which you're not doing, or (b) installing systemd for the > > first time, which you're not doing. Must be a bug in the package > > scriptlets. > > I think you're looking at the Rawhide version of the spec, Michael, not > the F36 one. In the Rawhide spec, the block in %posttrans is set to run > only on initial installation: > > https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_949 > > but on the f36 branch, it isn't: > > https://src.fedoraproject.org/rpms/systemd/blob/f36/f/systemd.spec#_946 > > so, I suppose backporting that change - > 4047e4fb7bb76f2578989e98de276e9ceb4e94b9 and then > bab6dfc23a915a4daee2dc6b215df8171a66f2a5 - to F36 would probably help > Casper's case. I don't know if there's any competing reason *not* to do > it. Any news on this topic?... -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der Jabber/XMPP Messaging: cas...@casperlefantom.net signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning lizardfs
I can pick this package up if you're stepping back. The lizards devs are planning on a new release sometime this year, but there's still a few things they're trying to finish up first before releasing v3.13. Last I heard they wanted it to be out before summer. JT On January 28, 2023 10:14:14 AM Jonathan Dieter wrote: 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On 2023-01-28 15:23, Fabio Valentini wrote: If I understand things correctly, this is not entirely true. RPM generates a dependency for the soname / soversion, and some projects include not only X, but all of X.Y.Z in that, which RPM will happily generate Provides / Requires for $ ls -l /lib64/libnghttp2.so.14* lrwxrwxrwx. 1 root root 21 Nov 21 05:45 /lib64/libnghttp2.so.14 -> libnghttp2.so.14.24.1* -rwxr-xr-x. 1 root root 173696 Nov 21 05:45 /lib64/libnghttp2.so.14.24.1* $ ldd /lib64/libsoup-3.0.so.0 | grep libnghttp libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x7f08fb366000) $ rpm -q libsoup3 --requires | grep libnghttp2 libnghttp2.so.14()(64bit) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote: ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the version of the package that provides libfoo.so.2 in the build root, which is an idea that's growing on me. This is indeed a shortcoming in the rpm symbol dependency generation scheme. But there's a problem with the proposed approach: versioning as major.minor.micro is just a convention, and not all upstream follow it. The version doesn't have to be major.minor.micro, though. The dependency generator only needs to get the version of the package that provides the .so, and use that version. As long as changes within a so version are always backward compatible, and the so version is bumped when breaking changes are made (which are already constraints on the existing system), then the proposed solution is reliable. It's sometimes too strict -- it might require 1.4.3 when 1.4.0 is compatible -- but it's reliable. There is an alternative scheme that is supported by our rpm tooling already: symbol versioning. Yes, the enhanced rpm dependencies would only be necessary for libraries that don't provide versioned symbols (which seems to be the vast majority of them). I don't think convincing hundreds or thousands of developers to add symbol versioning to their libraries is a viable solution. I'd love to see it happen, but rpm/dnf should be more reliable in the meantime. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
When is it better to just use containers?
On 1/28/23 18:43, Demi Marie Obenour wrote: > On 1/28/23 18:06, Nico Kadel-Garcia wrote: >> On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel >> wrote: >>> >>> Are there still some outstanding bugs preventing this from happening? >> >> Is there any one critical feature that justifies the update? Avoiding >> the requirement of python is... OK, maybe understandable, but I don't >> see it as a "must-have" improvement. And better modularity support >> My observation so far is that modularity simply destabilizes systems, >> because the authors of the "modularized" tools do not build up the >> full suites of likely necessary components. I'm running into that >> right now with python310 back in RHEL 8 for ansible, the results are >> not pretty. > > At this point it might be better to just containerize Ansible. > Containers may waste resources and require extra effort to keep > up-to-date, but they *work*, and that is important. They also > *massively* reduce the test burden. To elaborate: if I am an upstream developer for something like Ansible, my options are either: 1. Ship a whole bunch of packages for a whole bunch of distributions and make sure everything works across all of the various dependency versions. This also means that I have to restrict myself to the packages that e.g. RHEL 8 has, which might be quite old. 2. Ship a single container that only needs to be QA’d once, works everywhere, and has no dependencies except for the Linux kernel. I get to update dependencies when *I* want to, and don’t have to worry about breaking user’s systems. I can even ship a shell script wrapper so that the container can be invoked as a binary. 3. Something that I am not aware of (suggestions welcome). It’s pretty easy to see why someone would go with option 2. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is dnf5 going to replace dnf4?
On 1/28/23 18:06, Nico Kadel-Garcia wrote: > On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel > wrote: >> >> Are there still some outstanding bugs preventing this from happening? > > Is there any one critical feature that justifies the update? Avoiding > the requirement of python is... OK, maybe understandable, but I don't > see it as a "must-have" improvement. And better modularity support > My observation so far is that modularity simply destabilizes systems, > because the authors of the "modularized" tools do not build up the > full suites of likely necessary components. I'm running into that > right now with python310 back in RHEL 8 for ansible, the results are > not pretty. At this point it might be better to just containerize Ansible. Containers may waste resources and require extra effort to keep up-to-date, but they *work*, and that is important. They also *massively* reduce the test burden. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sun, Jan 29, 2023 at 12:03 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote: > > On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > This is indeed a shortcoming in the rpm symbol dependency generation > > > scheme. > > > > Is it though? I'm probibly reading this too quickly and missing > > something, but isn't the underlying problem here that nghttp2 changed > > abi and didn't change soname? If they had, soup would have kept the > > older version around, or asked to upgrade both libsoup and libnghttp2? > > No. libnghttp2 added one symbol, and (correctly, i.e. following the usual > practice), it changed the suffix from .so.14.23.0 to .so.14.24.1. (The last > number is bumped when the implementation of existing symbols changes, the > middle > one when when new symbols are added, and the first one when an incompatible > change happens, i.e. symbols are removed or changed incompatibly. Lower > numbers > are reset to zero whenever a higher one changes.) The SOVERSION corresponds > to > the major number and does not change in the case under discussion. > > As Gordon wrote, our rpm dependency generation logic does not care about the > minor or patch numbers. If I understand things correctly, this is not entirely true. RPM generates a dependency for the soname / soversion, and some projects include not only X, but all of X.Y.Z in that, which RPM will happily generate Provides / Requires for (whether that's a nice thing to do for an upstream project or whether that's a bug in their build systems I leave as an exercise to the reader). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is dnf5 going to replace dnf4?
On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel wrote: > > Are there still some outstanding bugs preventing this from happening? Is there any one critical feature that justifies the update? Avoiding the requirement of python is... OK, maybe understandable, but I don't see it as a "must-have" improvement. And better modularity support My observation so far is that modularity simply destabilizes systems, because the authors of the "modularized" tools do not build up the full suites of likely necessary components. I'm running into that right now with python310 back in RHEL 8 for ansible, the results are not pretty. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote: > On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > This is indeed a shortcoming in the rpm symbol dependency generation scheme. > > Is it though? I'm probibly reading this too quickly and missing > something, but isn't the underlying problem here that nghttp2 changed > abi and didn't change soname? If they had, soup would have kept the > older version around, or asked to upgrade both libsoup and libnghttp2? No. libnghttp2 added one symbol, and (correctly, i.e. following the usual practice), it changed the suffix from .so.14.23.0 to .so.14.24.1. (The last number is bumped when the implementation of existing symbols changes, the middle one when when new symbols are added, and the first one when an incompatible change happens, i.e. symbols are removed or changed incompatibly. Lower numbers are reset to zero whenever a higher one changes.) The SOVERSION corresponds to the major number and does not change in the case under discussion. As Gordon wrote, our rpm dependency generation logic does not care about the minor or patch numbers. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sat, Jan 28, 2023 at 1:23 PM Gordon Messmer wrote: > > On 2023-01-28 00:14, Bruno Wolff III wrote: > > If there is a problem with not uodating dependencies when you do an > > install or an update on selected packages, the packages dependencies > > are not properly defined. > > > By definition, yes. But rpm auto-detects dependencies, and rpm doesn't > do symbol-level dependency detection, so it doesn't capture > minor-version dependency creep. In order for rpm to do this, you'd > probably have to throw out the current implementation of dependency > resolution that provides "libfoo.so.2()(64bit)" and instead provide a > dependency like "(foo-libs >= 2.4 with foo-libs < 3)", at least for the > cases where libraries do not provide versioned symbols -- which I > believe includes the vast majority of them. (You'd also need to forbid > restructuring packages within a stable release.) The RPM build process tries to do so, but it can't possibly outsmart the morass of dependencies that "modularity" tends to create. It's why so many have given up on modularity since its introduction in Fedora, and one of the reasons I have trouble getting approval to do RHEL 8 and RHEL 9 updates. The various sets of "modularity" components are not tested against all the other versions of related packages: I'm running into this headlong with ansible collections and the morass of dependency chains weaving into and out of modularity deployed coponents, myself. The "modular" channels are almost invariably incomplete and require additional RPM builds to satisfy "test" or "doc" building steps from the same base software package. Modularity and its inevitable build-time and deployment inconsistencies have consistently hindered dependency management. > > I think the case where you don't want to keep the full system up to > > date, but a selective update or install causes problems as well is > > pretty rare. I think it might be reasonable to have an option that > > requests doing a recursive update. I would consider this to be a low > > priority feature request that has to compete with all of the other > > work being done on dnf, rather than a bug. I don't work on dnf and the > > people that do might feel differently. > > > Yeah, I agree, it's not super high priority. But it's also not really > well understood among the community that partial updates (such as `dnf > update --security`) and package installation without a contemporaneous > update are unreliable. Yeah. It's hard to predict exactly when it will break, but it *does* break. Unfortunately, so do fork list upgrades, such as using a base OS image that is three years old and then doing "dnf -y update" on it. It's very difficult to predict which update will break what, but updating 700 packages at once as I just saw on a base OS image of RHEL 8. It's one reason Fedora's frequent releases are useful: they provide a much fresher, smoke tested baseline image to apply changes to, rather than relying on upgrades in places. > I can work on some of those changes to documentation and to rpm or dnf, > but I'd like input from the developer community before starting. (And > at some point I think that Fedora, the org, should probably consider > whether `dnf update --security` is broken and unreliable.) It's popular. I'm remembering when the "dnf update -y --security" broke curl, because either "curl-libs" or "crypto-policies" was not listed in those updates, and hilarity ensued. It's why I try to schedule regular "dnf -y update" operations, and updating my base OS images to match. It can get a bit awkward when the base OS images at your favorite cloud vendor fall increasingly out of date over time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote: > > This is indeed a shortcoming in the rpm symbol dependency generation scheme. Is it though? I'm probibly reading this too quickly and missing something, but isn't the underlying problem here that nghttp2 changed abi and didn't change soname? If they had, soup would have kept the older version around, or asked to upgrade both libsoup and libnghttp2? Or did I miss some part of this? ...snip symbol versioning... symbol versioning does indeed sound like a better way to do things. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Polymake soname bump
Polymake 4.9 is out and includes an soname bump. In a week, I will build it in Rawhide, along with the sole consumer of its library interface, python-jupymake. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Sat, Jan 28, 2023 at 12:12:40PM -0800, Gordon Messmer wrote: > On 2023-01-28 10:22, Gordon Messmer wrote: > > In order for rpm to do this, you'd probably have to throw out the > > current implementation of dependency resolution that provides > > "libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs > > >= 2.4 with foo-libs < 3)", at least for the cases where libraries do > > not provide versioned symbols > > ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the > version of the package that provides libfoo.so.2 in the build root, which is > an idea that's growing on me. This is indeed a shortcoming in the rpm symbol dependency generation scheme. But there's a problem with the proposed approach: versioning as major.minor.micro is just a convention, and not all upstream follow it. There is an alternative scheme that is supported by our rpm tooling already: symbol versioning. This is ultimately more powerful, because it allows depending on specific versions of functions, and not just one monotonic version that tries to describe anything. (glibc makes extensive use of this to provide backwards comaptiblity…) Since symbol versioning is more powerful and pretty well handled by rpm, I think it's better to try to convince upstream to switch to that if they change symbols a lot. (Or even better, in my personal opinion, is to never change SOVERSION, i.e. to never remove symbols. It is surprisingly easy to provide backwards compat, for most project much less hassle than to deal with SOVERSION changes and forced rebuilds.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: firefox glxtest: VA-API test failed: no supported VAAPI profile found.
On Fri, 27 Jan 2023 23:31:21 - Reon Beon via devel wrote: > It seems to be this bug: > https://github.com/rpmfusion-infra/fedy/issues/110 Strictly speaking, it is not a bug. The fedora mesa rpm was deliberately changed to remove some va-api and vdpau support because of patent issues. When that new mesa stack hit fedora, I started seeing the same messages that you are. I then looked into it, and found the same information as you have. I ran the swap command recommended at the above link, which restored the removed functionality, and I no longer see the messages. I'm not even sure that I *need* that support. It might be that firefox just generically checks for the support, and reports when it is missing, whether it is needed or not. I certainly didn't notice any difference in my browsing experience when I was getting the messages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On 2023-01-28 10:22, Gordon Messmer wrote: In order for rpm to do this, you'd probably have to throw out the current implementation of dependency resolution that provides "libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs >= 2.4 with foo-libs < 3)", at least for the cases where libraries do not provide versioned symbols ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the version of the package that provides libfoo.so.2 in the build root, which is an idea that's growing on me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On 2023-01-28 00:14, Bruno Wolff III wrote: If there is a problem with not uodating dependencies when you do an install or an update on selected packages, the packages dependencies are not properly defined. By definition, yes. But rpm auto-detects dependencies, and rpm doesn't do symbol-level dependency detection, so it doesn't capture minor-version dependency creep. In order for rpm to do this, you'd probably have to throw out the current implementation of dependency resolution that provides "libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs >= 2.4 with foo-libs < 3)", at least for the cases where libraries do not provide versioned symbols -- which I believe includes the vast majority of them. (You'd also need to forbid restructuring packages within a stable release.) I think the case where you don't want to keep the full system up to date, but a selective update or install causes problems as well is pretty rare. I think it might be reasonable to have an option that requests doing a recursive update. I would consider this to be a low priority feature request that has to compete with all of the other work being done on dnf, rather than a bug. I don't work on dnf and the people that do might feel differently. Yeah, I agree, it's not super high priority. But it's also not really well understood among the community that partial updates (such as `dnf update --security`) and package installation without a contemporaneous update are unreliable. I can work on some of those changes to documentation and to rpm or dnf, but I'd like input from the developer community before starting. (And at some point I think that Fedora, the org, should probably consider whether `dnf update --security` is broken and unreliable.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
libsoup3 depends on libnghttp2.so.14 Apparantly, either libsoup3 should depend on the minor version (in addition to the major version), or libnghhttp2 should have bumped major, depending on the "history" of that symbol. Probably the former (API addition in a minor bump to the same major). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning lizardfs
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2165210] New: perl-PPIx-Regexp-0.087 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2165210 Bug ID: 2165210 Summary: perl-PPIx-Regexp-0.087 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PPIx-Regexp Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.087 Upstream release that is considered latest: 0.087 Current version/release in rawhide: 0.086-2.fc38 URL: http://search.cpan.org/dist/PPIx-Regexp/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3288/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-PPIx-Regexp -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2165210 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230128.n.0 changes
OLD: Fedora-Rawhide-20230127.n.0 NEW: Fedora-Rawhide-20230128.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 3 Dropped packages:2 Upgraded packages: 92 Downgraded packages: 0 Size of added packages: 6.47 MiB Size of dropped packages:53.81 KiB Size of upgraded packages: 9.79 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -9.92 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230128.n.0.iso = DROPPED IMAGES = Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230127.n.0.iso = ADDED PACKAGES = Package: draco-1.5.5-2.fc38 Summary: A library for compressing and decompressing 3D geometric meshes and point clouds RPMs:draco draco-devel Size:3.34 MiB Package: fancontrol-gui-0.8-1.20220606git5bfa8fa.fc38 Summary: GUI for fancontrol RPMs:fancontrol-gui fancontrol-gui-kcm fancontrol-gui-plasmoid Size:859.07 KiB Package: python-y-py-0.5.5-1.fc38 Summary: Python bindings for the Y-CRDT built from yrs (Rust) RPMs:python3-y-py Size:2.28 MiB = DROPPED PACKAGES = Package: rust-faccess-0.2.4-3.fc38 Summary: Simple file accessibility checks RPMs:rust-faccess+default-devel rust-faccess-devel Size:22.65 KiB Package: rust-simple-error-0.2.3-5.fc38 Summary: Simple error type backed by a string RPMs:rust-simple-error+default-devel rust-simple-error-devel Size:31.17 KiB = UPGRADED PACKAGES = Package: Io-language-20170906-10.fc38 Old package: Io-language-20170906-9.fc38 Summary: Io is a small, prototype-based programming language RPMs: Io-language Io-language-devel Io-language-extras Io-language-graphics-and-sound Io-language-mysql Io-language-postgresql Size: 6.62 MiB Size change: -1.67 KiB Changelog: * Fri Jan 27 2023 Nikita Popov - 20170906-10 - Port to C99 Package: QuantLib-1.29-1.fc38 Old package: QuantLib-1.16-12.fc38 Summary: A software framework for quantitative finance RPMs: QuantLib QuantLib-devel QuantLib-doc QuantLib-test Size: 62.38 MiB Size change: 4.75 MiB Changelog: * Fri Jan 27 2023 Tom Callaway - 1.29-1 - update to 1.29 Package: R-gert-1.9.0-4.fc38 Old package: R-gert-1.9.0-3.fc38 Summary: Simple Git Client for R RPMs: R-gert Size: 1.12 MiB Size change: -278 B Changelog: * Sat Jan 28 2023 Pete Walter - 1.9.0-4 - Rebuild for libgit2 1.5.x Package: R-git2r-0.30.1-4.fc38 Old package: R-git2r-0.30.1-3.fc38 Summary: Provides Access to Git Repositories RPMs: R-git2r Size: 1.98 MiB Size change: -281 B Changelog: * Sat Jan 28 2023 Pete Walter - 0.30.1-4 - Rebuild for libgit2 1.5.x Package: arch-test-0.20-1.fc38 Old package: arch-test-0.19-2.fc38 Summary: Tools to detect architectures runnable by your machine+kernel RPMs: arch-test Size: 33.81 KiB Size change: 1.08 KiB Changelog: * Fri Jan 27 2023 Robin Lee - 0.20-1 - New release 0.20 (RHBZ#2159564) Package: asymptote-2.84-1.fc38 Old package: asymptote-2.83-2.fc38 Summary: Descriptive vector graphics language RPMs: asymptote Size: 19.91 MiB Size change: 13.77 KiB Changelog: * Fri Jan 27 2023 Tom Callaway - 2.84-1 - update to 2.84 - add upstream patch to fix headless Xvfb use case Package: awscli-1.27.59-1.fc38 Old package: awscli-1.27.58-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.28 MiB Size change: -11 B Changelog: * Fri Jan 27 2023 Gwyn Ciesla - 1.27.59-1 - 1.27.59 Package: beep-1.4.12-7.fc38 Old package: beep-1.4.12-5.fc38 Summary: Beep the PC speaker any number of ways RPMs: beep Size: 179.49 KiB Size change: 405 B Changelog: * Fri Jan 27 2023 Hans Ulrich Niedermann - 1.4.12-6 - On EL7, Require: systemd instead of systemd-udev (#2157788) * Fri Jan 27 2023 Hans Ulrich Niedermann - 1.4.12-7 - Require: systemd only on EL7, not on Fedora (#2157788) Package: binwalk-2.3.3-3.fc38 Old package: binwalk-2.3.3-2.fc38 Summary: Firmware analysis tool RPMs: binwalk Size: 246.31 KiB Size change: -2 B Changelog: * Fri Jan 27 2023 Scott Talbert - 2.3.3-3 - Fix path traversal in PFS extractor script (#2165006) Package: bpftrace-0.16.0-6.fc38 Old package: bpftrace-0.16.0-4.fc38 Summary: High-level tracing language for Linux eBPF RPMs: bpftrace Size: 7.81 MiB Size change: -6.33 MiB Changelog: * Wed Jan 18 2023 Fedora Release Engineering - 0.16.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Fri Jan 27 2023 Augusto Caringi - 0.16.0-6 - Fix compile with GCC 13 Package: cantera-2.6.0-36.fc38 Old package: cantera-2.6.0-33.fc38
Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Fri, Jan 27, 2023 at 18:43:56 -0800, Gordon Messmer wrote: Second, I'd like to suggest that in the future, at least in Fedora, for any "install" or "update" operation that dnf performs, dnf's default behavior should be checking all of the direct and indirect dependencies of the packages being installed (or updated) and updating any dependencies which have updates available. Does anyone else have any opinions on the subject? Should I simply file a bug against dnf proposing this behavior? If there is a problem with not uodating dependencies when you do an install or an update on selected packages, the packages dependencies are not properly defined. I think the case where you don't want to keep the full system up to date, but a selective update or install causes problems as well is pretty rare. I think it might be reasonable to have an option that requests doing a recursive update. I would consider this to be a low priority feature request that has to compete with all of the other work being done on dnf, rather than a bug. I don't work on dnf and the people that do might feel differently. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
